© Peter A. Carter 2019 — P. A. Carter, Pro SQL Server 2019 Administration — DOI متنی: doi.org/10.1007/978-1-4842-5089-1_1

فصل 1 — برنامه‌ریزی استقرار

برنامه‌ریزی برای استقرار SQL Server 2019 به‌گونه‌ای که بهترین پشتیبانی را از نیازهای کسب‌وکار فراهم کند، می‌تواند کاری پیچیده باشد. باید حوزه‌های متعددی را در نظر بگیرید؛ از جمله Edition، نیازمندی‌های Licensing، میزبانی درون‌سازمانی در برابر Cloud، ملاحظات سخت‌افزاری، پیکربندی نرم‌افزار و حتی این پرسش که آیا Windows بهترین پلتفرم است یا نه. برای نمونه، اگر Instance جدید شما قرار است از یک برنامه وب PHP که روی Linux میزبانی می‌شود پشتیبانی کند، شاید بهتر باشد خود Instance نیز روی Linux میزبانی شود. همه این تصمیم‌ها حتی پیش از آن مطرح می‌شوند که بررسی کنید برای پشتیبانی از برنامه به نصب کدام Featureهای SQL Server نیاز دارید.

این فصل شما را در تصمیم‌های کلیدی هنگام برنامه‌ریزی استقرار راهنمایی می‌کند. اگر تصمیم بگیرید Instance را روی Windows Server میزبانی کنید، همچنین با برخی پیکربندی‌های ضروری سیستم‌عامل آشنا می‌شوید. فصل حاضر نمایی کلی از Featureهای سطح بالایی که هنگام نصب قابل انتخاب‌اند ارائه می‌کند و توضیح می‌دهد چرا انتخاب Feature مناسب اهمیت دارد.

Editionها و مدل‌های مجوز

انتخاب Edition مناسب SQL Server 2019 برای پشتیبانی از برنامه لایه داده ممکن است در ظاهر ساده به نظر برسد، اما در عمل باید برای این تصمیم وقت بگذارید و نظر ذی‌نفعان کسب‌وکار و دیگر واحدهای IT را نیز وارد فرایند تصمیم‌گیری کنید. نخستین نکته این است که SQL Server پنج Edition دارد. این Editionها نه‌تنها سطوح متفاوتی از قابلیت‌ها ارائه می‌دهند، بلکه ملاحظات Licensing متفاوتی نیز دارند. افزون بر این، از منظر پشتیبانی عملیاتی، اگر اجازه دهید برنامه‌های لایه داده روی نسخه‌هایی از SQL Server میزبانی شوند که به‌صورت راهبردی در مجموعه سازمانی شما استقرار نیافته‌اند، ممکن است TCO یا هزینه کل مالکیت آن مجموعه افزایش یابد.

بحث کامل درباره Featureها و ملاحظات Licensing خارج از دامنه این کتاب است؛ بااین‌حال، جدول 1-1 مدل‌های Licensing موجود برای هر Edition از SQL Server را نشان می‌دهد و جدول 1-2 هدف اصلی هر Edition را برجسته می‌کند.

CAL مخفف Client Access License است و در اینجا Client می‌تواند یک User یا یک Device باشد. بر اساس اینکه کدام گزینه برای محیط شما کم‌هزینه‌تر است، می‌توانید User License یا Device License را انتخاب کنید.

برای مثال، اگر سازمان شما یک SQL Server داشته باشد که از Call Center شامل 100 کامپیوتر پشتیبانی می‌کند و آن Call Center به‌صورت 24/7 با سه شیفت 8 ساعته کار می‌کند، 100 Device و 300 User خواهید داشت؛ بنابراین Device CAL منطقی‌ترین انتخاب است.

در مقابل، اگر SQL Server از یک تیم فروش 25 نفره پشتیبانی کند و هر فرد علاوه بر Laptop از iPad نیز برای اتصال به برنامه فروش استفاده کند، 25 User ولی 50 Device خواهید داشت؛ بنابراین User CAL انتخاب منطقی‌تری است.

خلاصه اینکه اگر تعداد Userها بیشتر از Deviceها است، Device CAL را انتخاب کنید؛ و اگر تعداد Deviceها بیشتر از Userها است، User CAL گزینه مناسب‌تری خواهد بود. Microsoft ابزاری با نام Microsoft Assessment and Planning (MAP) Toolkit for SQL Server نیز ارائه می‌کند که برای برنامه‌ریزی نیازمندی‌های Licensing کمک می‌کند. نشانی متنی منبع: microsoft.com/en-gb/download/details.aspx?id=7826.

نسخه یا نسخه‌های SQL Server که برای برنامه‌های Enterprise پشتیبانی می‌کنید، با توجه به نیازمندی‌های پروژه، نیازمندی‌های سازمان و زیرساخت زیربنایی متفاوت خواهند بود. برای نمونه، اگر سازمان کل مجموعه SQL Server خود را در Private Cloud میزبانی کند، احتمالاً فقط Enterprise Edition را پشتیبانی خواهید کرد؛ زیرا مجوز زیرساخت پایه را تهیه می‌کنید.

در مقابل، اگر سازمان بیشتر از Serverهای فیزیکی استفاده کند، احتمالاً باید ترکیبی از Editionهای SQL Server، مانند Enterprise و Standard، را پشتیبانی کنید. این کار به پروژه‌ها انعطاف می‌دهد تا در صورت نیاز نداشتن به همه Featureها و نداشتن Workload حجیم، هزینه را کاهش دهند و محدودیت‌های RAM و CPU در Standard Edition را بپذیرند.

نکته بعدی پیش از انتخاب Edition این است که آیا از نصب SQL Server روی Windows Server Core استفاده می‌کنید یا نه. نصب روی Server Core با کاهش Attack Surface می‌تواند امنیت را افزایش دهد. Server Core یک نصب حداقلی است؛ بنابراین سطح کمتری برای حمله و آسیب‌پذیری‌های امنیتی کمتری وجود دارد. همچنین می‌تواند Performance را بهتر کند، زیرا سربار GUI وجود ندارد و بسیاری از برنامه‌های پرمصرف منابع را نمی‌توان نصب کرد. اگر Server Core را انتخاب می‌کنید، باید پیامدهای آن را نیز درک کنید.

از دید SQL Server، Featureهای زیر قابل استفاده نیستند:

• Reporting Services
• SQL Server Data Tools (SSDT)

فهرست Featureهایی که روی Server Core قابل استفاده نیستند ادامه دارد:

• Client Tools Backward Compatibility
• Client Tools SDK
• SQL Server Books Online
• Distributed Replay Controller
• Master Data Services (MDS)
• Data Quality Services (DQS)

Featureهای زیر قابل استفاده‌اند، اما فقط از یک Server راه‌دور:

• Management Tools
• Distributed Replay Client

از منظر گسترده‌تر پشتیبانی عملیاتی، باید مطمئن شوید تمام تیم‌های عملیاتی شما، از جمله DBAها و Windows Operations، توان پشتیبانی Server Core را دارند. برای مثال، اگر تیم DBA به‌شدت به یک ابزار گرافیکی Third-party برای بررسی Execution Planها وابسته است، آیا آن ابزار باید روی خود Server نصب شود؟ آیا ابزار جایگزینی وجود دارد؟ از دید Windows Operations نیز باید بررسی شود که آیا ابزارهای لازم برای Monitoring و مدیریت Remote Server در اختیار تیم قرار دارد و آیا ابزار Third-party وابسته‌ای باید جایگزین شود.

همچنین بررسی کنید آیا تیم Operations مهارت لازم برای مدیریت سامانه‌ها با فرایندهای عمدتاً Command-line را دارد. اگر چنین مهارتی وجود ندارد، باید Training یا Upskilling موردنیاز را در نظر بگیرید.

ملاحظات سخت‌افزاری

هنگام برنامه‌ریزی نیازمندی‌های سخت‌افزاری Server، در حالت ایده‌آل باید یک تمرین کامل Capacity Planning انجام دهید تا بتوانید نیازهای سخت‌افزاری برنامه‌هایی را که Server پشتیبانی می‌کند برآورد کنید. هنگام انجام این کار، Lifecycle استاندارد سخت‌افزار سازمان را در نظر بگیرید و فقط برای امروز برنامه‌ریزی نکنید. بسته به سازمان، این چرخه ممکن است بین 1 تا 5 سال باشد، اما معمولاً 3 سال است.

این موضوع برای جلوگیری از Undersizing یا Oversizing Server اهمیت دارد. تیم‌های پروژه معمولاً برای تضمین Performance تمایل دارند Server را بیش از نیاز واقعی بزرگ انتخاب کنند. این رویکرد در مقیاس Enterprise نه‌تنها پرهزینه است، بلکه در برخی محیط‌ها می‌تواند اثر منفی بر Performance داشته باشد.

برای نمونه، در زیرساخت Private Cloud با منابع اشتراکی، Oversizing Server می‌تواند کل محیط، از جمله همان Server بزرگ‌شده، را تحت تأثیر منفی قرار دهد.

تعیین حداقل نیازمندی‌های راهبردی

هنگام تعیین حداقل نیازمندی‌های سخت‌افزاری SQL Server در محیط خود، ممکن است همان حداقل لازم برای نصب SQL Server را تعیین کنید: 4GB RAM و یک CPU با فرکانس 2GHz، بر اساس Enterprise Edition. بااین‌حال، بهتر است پشتیبانی‌پذیری عملیاتی در سطح Enterprise را نیز در نظر بگیرید.

برای مثال، اگر محیط شما عمدتاً Private Cloud است، شاید بخواهید حداقل 2 vCore و 4GB RAM + (تعداد Core × 1GB) را تعیین کنید، زیرا ممکن است با Standardهای سازمانی شما هماهنگ باشد.

در سوی دیگر، اگر Enterprise بسیار پراکنده‌ای دارید که به‌صورت ارگانیک رشد کرده است و می‌خواهید پروژه‌ها را به استفاده از یک SQL Server Farm مشترک ترغیب کنید، می‌توانید حداقل بسیار بالاتری مانند 32GB RAM و 2 Socket/4 Core را اجباری کنید. منطق این است که پروژه‌هایی که Throughput بالایی نیاز ندارند، برای اجتناب از هزینه سنگین یک سامانه بیش‌ازحد بزرگ، عملاً به استفاده از Farm اشتراکی سوق داده شوند.

ذخیره‌سازی

Storage یکی از ملاحظات بسیار مهم در هر نصب SQL Server است. بخش‌های بعدی درباره Locally Attached Storage و SAN یا Storage Area Network و نیز ملاحظات File Placement بحث می‌کنند.

Locally Attached Storage

اگر Server از Storage متصل محلی استفاده می‌کند، باید چیدمان Fileها را با دقت بررسی کنید. SQL Server ذاتاً اغلب IO-bound است؛ بنابراین پیکربندی IO Subsystem یکی از جنبه‌های حیاتی Performance است. در ابتدا باید Data Fileها و Log Fileهای User Databaseها را روی Disk یا Arrayهای جداگانه قرار دهید و TempDB، که پرمصرف‌ترین System Database است، نیز جدا شود. اگر همه این Fileها روی یک Volume باشند، هنگامی که SQL Server هم‌زمان در آن‌ها Write انجام می‌دهد احتمال Disk Contention وجود دارد.

Locally Attached Storage معمولاً به‌صورت آرایه‌های RAID یا Redundant Array of Inexpensive Disks به Server ارائه می‌شود و Levelهای مختلف RAID وجود دارند. در ادامه رایج‌ترین Levelها همراه با مزایا و معایب آن‌ها توضیح داده می‌شوند تا بتوانید مناسب‌ترین تعادل میان Performance و Fault Tolerance را انتخاب کنید.

RAID 0

یک Volume از نوع RAID 0 از دو تا n دیسک تشکیل می‌شود و Bitهای داده در تمام Diskهای Array به‌صورت Stripe پخش می‌شوند. این روش Performance بسیار خوبی ارائه می‌کند، اما هیچ Fault Tolerance ندارد. از دست رفتن هر Disk در Array باعث از کار افتادن کل Array می‌شود؛ همان‌طور که در شکل 1-1 نشان داده شده است.

RAID 1

یک Volume از نوع RAID 1 شامل دو Disk است که با هم به‌صورت یک Mirrored Pair کار می‌کنند. اگر یکی از Diskها خراب شود، Redundancy فراهم است؛ اما این مزیت به بهای کاهش Write Performance به دست می‌آید، زیرا هر Write روی Volume باید دو بار انجام شود. این شیوه Redundancy در شکل 1-2 نمایش داده شده است.

RAID 5

یک Volume از نوع RAID 5 از سه تا n Disk تشکیل می‌شود و دقیقاً به اندازه یک Disk در Array Redundancy فراهم می‌کند. چون Blockهای داده روی چند Disk Stripe می‌شوند، Read Performance بسیار خوب است، اما مانند قبل این موضوع به بهای Write Performance تمام می‌شود. Write Performance کاهش می‌یابد، زیرا Redundancy با توزیع Bitهای Parity در تمام Diskهای Array فراهم می‌شود. در نتیجه به ازای هر یک Write روی Volume، جریمه Performance معادل چهار Write وجود دارد؛ مستقل از تعداد Diskهای Array.

دلیل این جریمه ثابت آن است که Bitهای Parity همانند داده Stripe می‌شوند. Controller ابتدا داده اصلی و Parity اصلی را می‌خواند و سپس داده جدید و Parity جدید را می‌نویسد، بدون آنکه لازم باشد همه Diskهای دیگر Array را بخواند. این روش Redundancy در شکل 1-3 نشان داده شده است.

باید توجه داشت که اگر یک Disk در Array خراب شود، Performance به‌طور محسوسی افت می‌کند. همچنین Rebuild کردن یک Disk از Bitهای Parity موجود روی Diskهای دیگر، به‌ویژه برای Disk با ظرفیت بالا، ممکن است زمان زیادی طول بکشد.

RAID 10

یک Volume از نوع RAID 10 از چهار تا n Disk تشکیل می‌شود و تعداد Diskها همیشه زوج است. این Level بهترین ترکیب Redundancy و Performance را فراهم می‌کند. روش کار آن ایجاد یک Stripe of Mirrors است. Bitها بدون Parity روی نیمی از Diskهای Array، مشابه RAID 0، Stripe می‌شوند و سپس روی نیمه دیگر Diskها Mirror می‌شوند.

این روش Nested یا Hybrid RAID Level نامیده می‌شود و به این معنا است که می‌توان نیمی از Diskهای Array را از دست داد، به شرط آنکه هیچ دو Disk خراب‌شده‌ای عضو یک Mirrored Pair نباشند. شکل 1-4 این ساختار را نشان می‌دهد.

File Placement

به‌طور کلی پذیرفته شده است که RAID 0 نباید برای هیچ‌یک از Fileهای SQL Server استفاده شود. برخی پیشنهاد می‌کنند RAID 0 برای TempDB قابل قبول است؛ استدلال آن‌ها این است که TempDB پرمصرف به Performance بسیار بالا نیاز دارد و چون با هر Restart شدن Instance دوباره ایجاد می‌شود، به Redundancy نیاز ندارد. این استدلال در ظاهر منطقی است، اما اگر موضوع Uptime را در نظر بگیرید، دلیل مخالفت نویسنده روشن می‌شود.

Instance SQL Server برای کارکردن به TempDB نیاز دارد. اگر TempDB از دست برود، Instance Down می‌شود و اگر TempDB دوباره ایجاد نشود، امکان بالا آوردن Instance وجود ندارد. بنابراین اگر TempDB روی RAID 0 قرار داشته باشد و یکی از Diskها خراب شود، تا انجام یکی از اقدامات زیر Instance بالا نمی‌آید:

1. منتظر بمانید تیم Storage آرایه RAID 0 را دوباره Online کند.
2. Instance را در «minimal configuration mode» راه‌اندازی کنید و با SQLCMD محل TempDB را تغییر دهید.

تا پایان هر یک از این مراحل، احتمالاً ذی‌نفعان به‌شدت معترض خواهند بود؛ بنابراین بهتر است این گزینه را کنار بگذارید. به همین دلیل، هر زمان ممکن باشد TempDB بهتر است روی RAID 10 قرار گیرد. این کار بهترین سطح Performance را برای Database فراهم می‌کند و چون اندازه TempDB معمولاً بسیار کمتر از Data Fileهای User Database است، هزینه آن به همان اندازه سنگین نیست.

در دنیای ایده‌آل که پول محدودیت ایجاد نمی‌کند، Data Fileهای User Database روی RAID 10 قرار می‌گیرند، زیرا RAID 10 بهترین ترکیب Redundancy و Performance را دارد. اما در دنیای واقعی، اگر برنامه‌های شما Mission-critical نباشند، شاید این هزینه قابل توجیه نباشد. در چنین وضعی RAID 5 می‌تواند انتخاب خوبی باشد، به شرط آنکه نسبت Read به Write برنامه‌ها نسبتاً بالا باشد.

نویسنده معمولاً نسبت سه Read به یک Write را Baseline مناسبی می‌داند، هرچند این نسبت در هر سناریو می‌تواند متفاوت باشد.

اگر Databaseها فقط از Featureهای پایه SQL Server استفاده می‌کنند، RAID 1 احتمالاً برای Log Fileها انتخاب مناسبی است. RAID 5 معمولاً مناسب نیست، زیرا Transaction Log ماهیتی Write-intensive دارد. در برخی موارد، نویسنده حتی مشاهده کرده است RAID 1 برای Transaction Log بهتر از RAID 10 عمل کند؛ علت، ماهیت Sequential عملیات Write است.

بااین‌حال، برخی Featureهای SQL Server می‌توانند Read قابل‌توجهی از Transaction Log ایجاد کنند. در این حالت، ممکن است RAID 10 برای Transaction Log نیز همانند Data Fileها لازم باشد. Featureهایی که باعث Transaction Log Read می‌شوند عبارت‌اند از:

• AlwaysOn Availability Groups
• Database mirroring
• Snapshot creation
• Backups
• DBCC CHECKDB
• Change data capture
• Log shipping؛ هم Backupها و هم زمانی که Logها با WITH STANDBY Restore می‌شوند

Solid-State Drives (SSDها)

یکی از دلایل رایج استفاده از Locally Attached Storage به‌جای SAN، بهینه‌سازی Performance اجزای SQL Server است که IO بسیار سریع می‌خواهند؛ از جمله TempDB و Buffer Cache Extension. غیرمعمول نیست که Data و Log Fileهای یک Database روی SAN باشند اما TempDB و Buffer Cache Extension روی Storage محلی قرار گیرند.

در چنین مثالی استفاده از SSD در Array محلی منطقی است. SSDها می‌توانند IO Rate بسیار بالایی ارائه کنند، اما نسبت به Diskهای سنتی گران‌ترند. SSD نیز «راه‌حل جادویی» نیست. با وجود IOPS بسیار بالا برای Random Disk Access، در Sequential Scanهایی که در برخی Workloadها مانند Data Warehouse رایج‌اند می‌تواند کارایی کمتری داشته باشد. SSDها همچنین در مقایسه با افت تدریجی Diskهای سنتی، مستعد خرابی ناگهانی‌اند. بنابراین استفاده از RAID Level دارای Fault Tolerance و Hot Spare در Array ایده بسیار خوبی است.

کار با SAN

عبارت Storage Area Network یا SAN می‌تواند برای یک DBA ترسناک باشد. DBA مدرن باید مفاهیمی مانند SAN و Virtualization را بپذیرد؛ هرچند این فناوری‌ها تغییرات بنیادی ایجاد می‌کنند، در عین حال مدیریت‌پذیری کل مجموعه را ساده‌تر کرده و TCO را کاهش می‌دهند.

مهم‌ترین نکته برای DBA درباره SAN این است که SAN اصول بنیادی IO Subsystem را تغییر می‌دهد و DBA نیز باید شیوه فکر کردن خود را تغییر دهد. برای مثال، در دنیای Locally Attached Storage، اصل پایه این است که Data File، Log File و TempDB از هم جدا شوند و هرکدام روی مناسب‌ترین RAID Level قرار گیرند.

اما در دنیای SAN ممکن است در ابتدا تعجب کنید که SAN Administratorها انتخاب RAID Level ارائه نمی‌کنند یا حتی RAID 10 در دسترس نیست. اگر چنین است، احتمالاً SAN در پشت صحنه داده را روی همه Diskهای Array Stripe می‌کند. بنابراین، هرچند RAID Level هنوز می‌تواند روی Throughput اثر داشته باشد، انتخاب Storage Tier اهمیت بیشتری پیدا می‌کند.

بسیاری از سازمان‌ها Storage را در SAN به سه یا چند Tier تقسیم می‌کنند. Tier 1 بالاترین سطح است و ممکن است ترکیبی از SSD و Fiber Channel Driveهای کوچک و پرسرعت باشد. Tier 2 معمولاً از Driveهای بزرگ‌تر، احتمالاً SATA، تشکیل می‌شود و Tier 3 اغلب Near-line Storage است. Near-line Storage شامل تعداد زیادی Disk ارزان مانند SATA است که معمولاً متوقف هستند و فقط هنگام نیاز به دسترسی به داده Spin Up می‌شوند. برنامه‌هایی که Performance خوبی می‌خواهند باید روی Tier 1 باشند. Tier 2 شاید برای Databaseهای کوچک، کم‌استفاده و با Concurrency اندک مناسب باشد و Tier 3 به‌ندرت، اگر اصلاً، باید برای Database یا Logهای SQL Server استفاده شود.

Throughput واقعی علاوه بر این عوامل به موارد زیادی مانند تعداد Network Pathها میان Server و SAN و تعداد Serverهایی که هم‌زمان به SAN دسترسی دارند وابسته است. یک ویژگی جالب دیگر برخی SANها این است که Write Performance می‌تواند بسیار بهتر از Read Performance باشد؛ زیرا برخی SANها از Battery-backed Write Cache استفاده می‌کنند، ولی برای Read باید داده را از Diskهای فیزیکی بازیابی کنند.

همچنین در نظر بگیرید که اگر همه داده‌ها روی تمام Diskهای Array Stripe شده باشند — و حتی اگر چنین نباشد، احتمالاً همه Fileهای یک Server روی یک CPG یا Common Provisioning Group قرار دارند — نباید انتظار داشته باشید صرفاً با جداکردن Data، Log و TempDB فوراً Performance بهتر شود. بااین‌حال بسیاری از DBAها همچنان این Fileها را روی Volumeهای جدا قرار می‌دهند تا جداسازی منطقی و سازگاری با Serverهای دارای Locally Attached Storage حفظ شود. در برخی موارد، اگر برای Redundancy از SAN Snapshot یا SAN Replication استفاده می‌کنید، ممکن است لازم باشد Data و Log Fileهای یک Database روی همان Volume باشند؛ این موضوع باید با تیم Storage بررسی شود.

Disk Block Size

یکی دیگر از ملاحظات پیکربندی Disk، چه در Storage محلی و چه SAN، اندازه Block است. بسته به Storage، احتمالاً اندازه پیش‌فرض Allocation Unit در NTFS یا New Technology File System برابر 4KB است. مسئله اینجاست که SQL Server داده را در مجموعه‌های هشت‌تایی از Pageهای پیوسته 8KB سازمان‌دهی می‌کند که Extent نام دارند. برای Performance بهینه SQL Server، Block Size در Volumeهای میزبان Data، Log و TempDB باید با این ساختار هماهنگ و روی 64KB تنظیم شود.

برای بررسی Disk Block Size می‌توان Script مربوط به Windows PowerShell در Listing 1-1 را اجرا کرد. این Script با استفاده از fsutil ویژگی‌های NTFS Volume را دریافت می‌کند. Script فرض می‌کند Volume مورد بررسی f: است؛ آن را با Drive Letter موردنظر خود جایگزین کنید و Script را با دسترسی Administrator اجرا نمایید.

Listing 1-1 — Determine Disk Block Size

# Populate the drive letter you want to check
$drive = "f:"
# Initialize outputarray
$outputarray = new-object PSObject
$outputarray | add-member NoteProperty Drive $drive
# Initialize output
$output = (fsutil fsinfo ntfsinfo $drive)
# Split each line of fsutil into a seperate array value
foreach ($line in $output) {
    $info = $line.split(':')
    $outputarray | add-member NoteProperty $info[0].trim().Replace(' ','_') $info[1].trim()
    $info = $null
}
# Format and display results
$results = 'Disk Block Size for ' + $drive + ' ' + $outputarray.Bytes_Per_Cluster/1024 + 'KB'
$results

ملاحظات سیستم‌عامل

SQL Server از سیستم‌عامل‌های متعددی، از جمله نسخه‌های گوناگون Windows، پشتیبانی می‌کند. بااین‌حال بعید است بخواهید نصب SQL Server روی هر نسخه‌ای از هر سیستم‌عامل پشتیبانی‌شده را مجاز کنید. برای نمونه، در مجموعه Windows سازمان بهتر است یک نسخه SQL Server را با یک نسخه مشخص Windows هماهنگ کنید. این رویکرد دو مزیت دارد.

نخست، حجم Testing لازم برای Sign-off کردن Build را به‌شدت کاهش می‌دهد. فرض کنید تصمیم بگیرید فقط Enterprise Edition را در محیط مجاز کنید؛ در تئوری همچنان باید برای بیش از یک دوجین نسخه Windows تأیید عملیاتی بگیرید. اما اگر Enterprise و Standard Editionهای SQL Server را مجاز کنید و هر دو را با Windows Server 2019 Standard Edition هماهنگ نمایید، فقط برای هر یک از Editionهای SQL Server پشتیبانی‌شده یک‌بار Sign-off نیاز خواهید داشت.

مزیت دوم به End-of-Life Cycle یا EOL پلتفرم‌ها مربوط است. اگر SQL Server 2017 را روی Windows Server 2012 مجاز کنید، پایان Mainstream Support برای Windows در January 2015 است، در حالی که برای SQL در July 2021 است. در بهترین حالت این اختلاف هنگام Upgrade کردن Windows پیچیدگی و Outage ایجاد می‌کند و در بدترین حالت می‌تواند باعث هزینه Extended Support شود که امکان اجتناب از آن وجود داشت.

RAID 5 — ادامه

RAID 5 برای Redundancy از Parity توزیع‌شده استفاده می‌کند. فرمول IOPS و شکل منبع در این صفحه، هزینه Write و نحوه توزیع Parity را نشان می‌دهند.

Note  The formula for calculating total IOPS against a RAID 5 array is as follows:
IOPS = Read + (Writes * 4). To calculate the expected IOPS per spindle, you can
divide this value for IOPS by the number of disks in the array. This can help you
calculate the minimum number of disks that should be in the array to achieve your
performance goals.
Figure 1-3.  RAID 5 provides redundancy through parity bits
Chapter 1  Planning the Deployment

RAID 10 و File Placement

این صفحه محاسبه IOPS در RAID 10 و ملاحظات File Placement را پوشش می‌دهد. TempDB برای Availability به Storage مقاوم نیاز دارد و RAID 0 با وجود سرعت بالا برای Production توصیه نمی‌شود.

Note  The formula for calculating total IOPS against a RAID 10 array is as follows:
IOPS = Read + (Writes * 2). In the same way as for RAID 5, in order to calculate
the expected IOPS per spindle, you can divide the value for IOPS by the number of
disks in the array. This can help you calculate the minimum number of disks that
should be in the array to achieve your performance goals.
File Placement
It is generally accepted that RAID 0 should not be used for any SQL Server files. I have
known people to suggest that RAID 0 may be acceptable for TempDB files. The rationale
here is that a heavily used TempDB often requires very fast performance, and because
it is re-created every time the instance restarts, it does not require redundancy. This
sounds perfectly reasonable, but if you think in terms of uptime, you may realize why I
disagree with this opinion.
Your SQL Server instance requires TempDB in order to function. If you lose TempDB,
then your instance will go down, and if TempDB cannot be re-created, then you will not
be able to bring your instance back up. Therefore, if you host TempDB on a RAID 0 array
and one of the disks within that array fails, you will not be able to bring the instance back
up until you have performed one of the following actions:
	 1.	 Wait for the storage team to bring the RAID 0 array back online.
	 2.	 Start the instance in “minimal configuration mode” and use
SQLCMD to change the location of TempDB.
By the time either of these steps is complete, you may find that stakeholders are
jumping up and down, so you may find it best to avoid this option. For this reason,
TempDB is generally best placed on a RAID 10 array, whenever possible. This
will provide the best level of performance for the database, and because its size is
significantly smaller than the user database files, you do not have the same level of cost
implication.
In an ideal world, where money is no object, the data files of your user databases
will be stored on RAID 10 arrays, since RAID 10 provides the best combination of
redundancy and performance. In the real world, however, if the applications you are
supporting are not mission critical, this may not be justifiable. If this is the situation,
then RAID 5 can be a good choice, as long as your applications have a fairly high ratio of
Chapter 1  Planning the Deployment

تکمیل Disk Block Size و ملاحظات سیستم‌عامل

Listing 1-1 در این صفحه تکمیل می‌شود و سپس ملاحظات سیستم‌عامل مطرح می‌گردد. هم‌راستا کردن نسخه SQL Server با نسخه استاندارد Windows می‌تواند تعداد ترکیب‌های قابل پشتیبانی و پیچیدگی چرخه عمر را کاهش دهد.

# Split each line of fsutil into a seperate array value
foreach ($line in $output) {
    $info = $line.split(':')
    $outputarray | add-member NoteProperty $info[0].trim().Replace(' ','_')
$info[1].trim()
    $info = $null
}
# Format and display results
$results = 'Disk Block Size for ' + $drive + ' ' + $outputarray.Bytes_Per_
Cluster/1024 + 'KB'
$results
Operating Systems Considerations
SQL Server has support for many operating systems, including many versions of
Windows. It is unlikely, however, that you will want to allow SQL Server to be installed
on any version of any operating system that is supported. For example, within your
Windows estate, it is advisable to align a version of SQL Server with a specific version of
Windows. This gives you two benefits.
First, it drastically reduces the amount of testing that you need to perform to sign
off your build. For example, imagine that you decide you will only allow Enterprise
edition within your environment. In theory, you would still need to gain operational
sign-off on more than a dozen versions of Windows. In contrast, if you allow both SQL
Server Enterprise and Standard editions of SQL Server, but you align both editions with
Windows Server 2019 Standard edition, then you would only require sign-off once for
each of your supported editions of SQL Server.
The second benefit is related to end-of-life cycle (EOL) for your platforms. If you
allow SQL Server 2017 to be installed on Windows Server 2012, the end of mainstream
support for Windows is January 2015, as opposed to July 2021 for SQL. At best, this will
cause complexity and outage while you upgrade Windows, and at worst, it could lead to
extended support costs that you could have avoided.
Chapter 1  Planning the Deployment