گزارش عملکرد سرویس SQL Server در محیط مجازی

مقدمه گزارش عملکرد سرویس SQL Server در محیط مجازی

وبینار عملکرد سرویس SQL Server در محیط مجازی در تاریخ ۱۱ شهریور ماه ۱۳۹۷ برگزار شد. هدف از این وبینار آشنایی دوستان با شرایط مختلف پیاده سازی سرویس MS SQL در محیط مجازی vSphere بود. با توجه به تفاوت‌های بسیاری که این محیط با محیط‌های فیزیکی دارد، الزامات مشخص و مهمی در پیاده سازی سرویس‌هایی که حساسیت زیادی در بحث استفاده از منابع پردازشی و ذخیره سازی دارند وجود دارد. در این وبینار موارد زیر پوشش داده شد:

• مدیریت توان سرور – Power Management
•  پشتیبانی CPU ازSLAT Compatible Server Hardware – SLAT
•  پیکربندی CPU Configuration – CPU
•  پیکربندی Memory Configuration – Memory
• وضعیت فایل ها بر روی یک دیسک – Files on the Same Disk
•  تعیین اندازه TempDB Sizing – TempDB

مدیریت توان سرور

زمانیکه می‌خواهیم یک سرور را جهت پیاده سازی راهکار مجازی سازی مهیا سازیم، از ابتدای امر باید نکات متعددی را مدنظر داشته باشیم. یکی از نکات مهم در این خصوص، بخش مدیریت توان مصرفی سرور می‌باشد. سرورها براساس نوع و تولید کننده، دارای گزینه‌های متعددی در زمینه پیکربندی مصرف برق مورد نیاز خود می‌باشند. این گزینه بعضا به منظور حفظ سلامت محیط زیست تعبیه شده است. در این بین گزینه مشترکی که بین تمام سرورها وجود دارد، گزینه مربوط به high performance می‌‍باشد. این گزینه در دو بخش قابل تنظیم است:
– در بخش BIOS سرور
– در بخش تنظیمات مربوط به توان مصرفی در محیط vSphere
– در بخش تنظیمات سیستم عامل ویندوز
نکته: برای اینکه بتوانید این فرآیند را در هاست ESXi خود انجام دهید، می‌بایست در تنظیمات BIOS از گزینه OS Controlled استفاده نمایید.
انتخاب این گزینه برای پیاده سازی ماشین های مجازی از نوع ویندوز به نوعی الزام محسوب می شود که در صورت عدم رعایت این الزام، می توان احتمال داد که ماشین‌های مجازی در طول سرویس دهی خود با مشکل روبرو شوند. اثر مستقیم این تنظیمات بر روی پردازنده هاست مشاهده می‌شود. زمانیکه ماشین‌های مجازی شما به صورت idle درآمده (مانند ساعاتی که فعالیتی برای انجام ندارند) به صورت اتوماتیک، پردازنده به حالت C-states می رود. این حالت باعث Halt شدن پردازنده می شود تا در مصرف برق صرفه جویی شود. اما مشکل اینجاست زمانیکه CPU توسط ماشین مجازی فراخوانی می شود، مدت زمان زیادی طول میکشد تا پردازنده از آن حالت خارج شود و نتیجه این امر اختلال طولانی مدت بر روی سرویس‌های شماست. این اختلال را I/O Latency در سطح CPU می‌نامند.
از طرفی در صورتیکه در سطح سیستم عامل ویندوز، اقدام به تغییر شرایط مدیریت توان مصرفی نکنیم، به صورت پیش فرض زمانیکه سیستم عامل به تعداد CPUهای تخصیص داده شده به خود نیازی نداشته باشید آنها را وارد حالت Parked می‌نماید. در این حالت هسته‌های CPU به صورت Halt درآمده و در صورت نیاز سرویس مدت زمان زیادی طول میکشد تا سیستم عامل آنها را در اختیار سرویس قرار دهد.
نکته: برای تمام اپلیکیشن‌هایی که نسبت به مصرف منابع حساسیت دارند، الزامات مصرف منابع را لحاظ نمایید.

پشتیبانی CPU از SLAT

امروزه اکثر CPUهایی که براساس معماری x64 تولید می‌شوند از ویژگی SLAT یا Second Level Address Translation پشتیبانی می‌کنند. این ویژگی هم در پردازنده های سری Intel و هم در پردازنده‌های سری AMD وجود دارد اما نامگذاری متفاوتی را در نظر گرفته‌اند. در پردازنده های Intel این ویژگی با نام Extended Page Tables و در پردازنده‌های AMD با نام Rapid Virtualization Indexing معرفی می‌شوند.
اما این ویژگی چه کمکی می‌کند؟ در صورتیکه پردازنده شما از این ویژگی پشتیبانی کند، از سربار حافظه کاسته شده و در نتیجه سیستم عامل شما به فضای Memory بیشتری دسترسی دارد. این فرآیند از طریق کاهش میزان CPU Time صورت می‌پذیرد. نحوه عملکرد این ویژگی نیز به این صورت می‌باشد که زمانیکه درخواستی برای تبدیل مسیر حافظه مجازی به فیزیکی برای CPU ارسال می‌شود، ابتدا به سراغ بخشی می‌رود که به آن TLB یا Translation Lookaside Buffer گفته می‌شود. این بخش در واقع یک بافر برای نگهداری اطلاعات مربوط به Mapping آدرس های مجازی به فیزیکی در سطح Memory برای دسترسی سریع به اطلاعات است. حال زمانیکه سیستم عامل درخواست خود را ارسال می‌کند، ابتدا این بافر چک می‌شود که نتیجه آن دو حالت زیر خواهد بود:

•  وجود اطلاعات مربوط به آدرس‌های فیزیکی برای آدرس های مجازی درخواستی در بافر
• عدم وجود اطلاعات

در صورتیکه اطلاعات وجود داشته باشد، فرآیند Mapping آدرس فیزیکی به مجازی صورت می‌پذیرد و در غیر اینصورت سیستم عامل با پیغام خطای Page Error مواجه شده و در نتیجه به سراغ Page Table می‌رود تا فرآیند Mapping را طی نماید. به صورت کلی می‌توان گفت در صورت عدم توانای CPU در پاسخ دهی به این درخواست‌ها، سربار پاسخ دهی در سمت Hypervisor خواهد بود.
در صورتیکه اطلاعات در Page Table پیدا شود، توسط سیستم عامل در TLB نوشته می‌شود تا در رجوع بعدی این اطلاعات از طریق بافر در اختیار سیستم عامل قرار داده شود. نتیجه این فرآیند کاهش سربار Hypervisor می‌باشد.
این کاهش سربار و دسترسی سریع به آدرس دهی فیزیکی Memory اثر مستقیم بر روی سرویس هایی که وابستگی زیادی به حافظه اصلی دارند خواهد داشت. یکی از این سرویس‌ها قطعا SQL Server می‌باشد که نیاز مبرم به حافظه اصلی خواهد داشت و فرآیند Mapping حافظه مجازی به اصلی می‌بایست در بهترین و سریعترین حالت ممکن انجام شود.

پیکربندی CPU

در خصوص پیکربندی بخش پردازنده ماشین‌های مجازی که هدف از ایجاد آنها، پیاده سازی سرویس SQL Server می‌باشد، الزامات متعددی وجود دارد. از بررسی مقادیر Counter‌های مربوط به CPU جهت بهینه کردن سرویس تا تعداد vCPUهایی که به ماشین مجازی اختصاص می‌دهید.
به صورت کلی برای سرویس‌هایی که وابستگی زیادی به CPU دارند، باید در نظر داشته باشید که تعداد vCPU هایی که به ماشین مجازی تخصیص می‌دهید، از تعداد هسته‌های موجود بر روی یک سوکت فیزیکی CPU روی سرور شما بیشتر نباشد. باید توجه داشته باشید که ماشین‌های مجازی که بیش از یک vCPU دارند را SMP VM می‌نامند. کاربرد SMP بر روی ماشین مجازی این است که ماشین مجازی بتواند از قابلیت چند پردازنده بودن استفاده نماید. این ویژگی یک ویژگی مجازی است که ملاحظات خاص خودش را دارد. به طور مثال در صورتیکه وضعیت vCPU ها در سطح SMP از شرایط تعادل خارج شود، دستوری از سمت ESXi برای آن ماشین مجازی ارسال می شود که اصطلاحا به آن Co-Scheduling گفته می‌شود.
یکی دیگر از الزامات بخش CPU فعالسازی Hyper-threading برای پردازنده‌های سری اینتل در BIOS سرور می‌باشد. این ویژگی هر هسته را به دو بخش تقسیم می‌کند که به هر بخش یک Thread گفته می‌شود. به مجموع این Threadها هسته‌های Logical گفته می‌ شود. باید بدانید که بر خلاف باور عموم، این تقسیم بندی به معنای افزایش تعداد هسته‌های CPU نیست و تنها کمک می‌کند تا Hypervisor با فعال نگه داشتن Pipelineهای CPU با رشد کارآیی بین ۱۰ تا ۳۰ درصدی مواجه شود.
در خصوص تخصیص متناسب vCPU و vCore همانطور که می‌دانید، سرویس SQL Server براساس تعداد هسته‌های CPU لایسنس می‌شود. بنابراین یکی از دلایل مهمی که این ویژگی به محیط vSphere اضافه شده است، رفع مشکلات در خصوص خرید لایسنس‌ها می‌ باشد. از طرفی باید تناسب بین vCPU و vCore را رعایت نمایید. این تناسب با در نظر گرفتن شرایط NUMA لحاظ می شود.
ویژگی CPU Hot Plug نیز یکی از بخش‌های پیکربندی مربوط به CPU بر روی ماشین مجازی می‌باشد. باید توجه داشته باشید که در صورت فعال کردن این ویژگی برای یک ماشین مجازی، ویژگی vNUMA برای آن ماشین مجازی غیرفعال می‌شود. نتیجه این امر این است که سرویس SQL Server امکان بهره مندی از vNUMA را نداشته و در نتیجه افت کارآیی کاملا مشهود خواهد بود.
ویژگی CPU Affinity نیز برای محیط‌هایی که از DRS استفاده نمی‌کنند به ازای هر ماشین مجازی قابل تنظیم خواهد بود. این ویژگی به شما این امکان را می‌دهد تا یک محدوده مشخصی از هسته‌های CPU را برای ماشین مجازی در نظر بگیرید. البته باید توجه داشته باشید که این کار باعث کاهش کارآیی ESXi در زمینه Scheduling پردازنده می‌شود.

پیکربندی Memory

در زمینه پیکربندی Memory نیز باید توجه داشته باشید که الزامات مهم و بسیاری در این بخش وجود دارد. سرویسی مانند SQL Server که وابستگی زیادی به Memory دارد، باید در بهینه ترین حالت ممکن یک ماشین مجازی از نظر Memory نصب و راه اندازی شود. باید بدانید که کمبود میزان Memory مورد نیاز سرویس SQL Server منجر می‌شود تا سیستم عامل به صورت مداوم، اطلاعات موجود بر روی Memory را بر روی دیسک Flush کند که نتیجه این اتفاق، کاهش شدید افت کارآیی در بخش Disk خواهد بود.
الزامات این بخش را می توان به ۳ دسته کلی زیر تقسیم بندی کرد:

•  تخصیص میزان Memory براساس آنچه که مورد نیاز سرویس است. به صورت کلی باید در نظر داشته باشید که تخصیص میزان Memory بیش از آنچه که به صورت فیزیکی بر روی سرور ESXi نصب شده است سبب ایجاد سربار روی Memory شده و نتیجه آن اختلالات شدید در سطح سرویس است.
•  سرویس SQL Server به مانند ESXi از ویژگی NUMA پشتیبانی می کند. به صورت پیش فرض اگر میزان Memory که به ماشین مجازی خود تخصیص می‌دهید کمتر از آنچه که در یک NUMA Node نصب شده است باشد، ESXi تا آنجا که امکان داشته باشد از قابلیت Remote Memory استفاده نخواهد کرد در غیر اینصورت ویژگی vNUMA به سیستم عامل مجازی معرفی شده تا سرویس SQL بتواند از آن بهره مند شود.
•  زمانیکه یک ماشین مجازی روشن می‌شود، براساس میزان vCPU که به آن تخصیص داده شده است، سربار Memory خواهد داشت. این میزان سربار باید در دسترس ماشین مجازی باشد. تصویر زیر بخشی از این سربار را نشان می‌دهد.

در برخی موارد نیاز است تا بخشی از حافظه اصلی را به صورت تضمین شده در اختیار ماشین مجازی قرار دهید. این فرآیند از طریق Reserve کردن Memory روی ماشین مجازی صورت می‌پذیرد. مقداری که به عنوان Min Server Memory بر روی SQL Server تعریف می‌شود از این مزیت برخوردار شده و این مقدار به صورت تضمینی در اختیار سرویس قرار دارد.
ویژگی Memory Hot Plug مشابه با این ویژگی در CPU می‌تواند این قدرت را به شما بدهد تا بتوانید به صورت زنده میزان Memory ماشین مجازی را افزایش دهید. تا نسخه ۶ محصول vSphere زمانیکه شما اقدام به افزایش Memory به صورت زنده می‌کردید، این فضا تماما از NUMA Node 0 تخصیص داده می‌شد که این امر سبب بهم ریختن تعادل در سطح NUMA می‌شد. اما از نسخه ۶ به بعد این مشکل مرتفع شده و بین نودهای مختلف NUMA توزیع بار صورت می‌گیرد. پیشنهاد VMWare برای افزایش میزان Memory ماشین مجازی به صورت زنده تنها برای مواردی است که روند استفاده Memory در آنها قابل پیش بینی نیست. اگر چنین موردی برای سرویس SQL Server باشد، با افزایش میزان Memory ماشین مجازی به صورت زنده، می‌توانید بدون اقدام به ریست کردن ماشین مجازی یا سرویس SQL از آن مقدار افزایش یافته بهره‌مند شوید.

وضعیت فایل‌ها بر روی یک دیسک

سرویس SQL Server براساس الگوریتم های مختلفی به فایل های مورد نیاز خود دسترسی پیدا می کند. بدین معنا که روند ارسال و دریافت درخواست ها به سمت دیسک براساس نوع فایل متفاوت است. به صورت کلی دو نوع الگوریتم برای دسترسی به فایل وجود دارد:

• ارسال درخواست I/O به صورت Sequential
• ارسال درخواست I/O به صورت Random

در خصوص فایل مرتبط با دیتا یا همان MDF فایل، این دسترسی به صورت Random اتفاق می افتد. با توجه به این شرایط می بایست دیسکی را به ماشین مجازی خود تخصیص دهید که حداقل میزان تاخیر در پاسخگویی به درخواست های Random را داشته باشد. این موضوع در خصوص لاگ فایل کاملا برعکس است. روند دسترسی به این فایل توسط سرویس SQL Server یک روند Sequential است که براساس این روند می بایست دیسکی با قابلیت مدیریت درخواست های Sequential در اختیار ماشین مجازی قرار دهید.

این موارد در خصوص فضاهای ذخیره سازی می‌باشد که از دیسک‌های چرخشی و موتور دار استفاده می‌کنند. زمانیکه شما دسترسی Random به فضای دیسک نیاز داشته باشید، میزان فعالیت Head بر روی دیسک‌ها بالاتر از آن چیزی است که در دسترسی Sequential است. در نتیجه فایل هایی که روند رفتار با آنها به صورت Sequential است کارآیی بالاتری خواهند داشت. جداسازی این فایل‌ها در سطح دیسک باعث جلوگیری از تاثیرپذیری هر کدام از فایل ها بر روی یکدیگر می‌شوند.

تعیین اندازه TempDB

همانطور که می‌دانید TempDB به عنوان یک فضای مشترک برای تمام بانک‌های اطلاعاتی شما بر روی یک SQL Instance می‌باشد که با هر بار راه اندازی سرویس SQL این فایل ایجاد می‌گردد. در خصوص این فایل می‌بایست ابتدا اقدام به جداسازی آن از سایر فایل‌‎های مرتبط با این سرویس نمایید. بدین معنا که یک دیسک مستقل برای این فایل در نظر بگیرید.
در خصوص تعداد این فایل‌ها، ارتباط مستقیمی با تعداد vCPU های ماشین مجازی وجود دارد. این ارتباط بدین صورت است که به ازای هر vCPU می‌بایست یک Temp فایل (از نوع دیتا) داشته باشید. این شرایط برای تعداد vCPU ها تا عدد ۸ صدق می‌کند و برای ماشین‌های مجازی با vCPUهای بالاتر از ۸ عدد می‌بایست همان ۸ فایل TempDB را در نظر بگیرید و در صورت عدم رفع Contention می‌توانید با توجه به تعداد vCPU های ماشین مجازی و در نظر گرفتن ضریب ۴ اقدام به افزایش تعداد TempDBها نمایید تا در نهایت Contention به وجود آمده مرتفع گردد. این Contention برای PFS/GAM/SGAM رخ می‌دهد.
نکته: به صورت پیش فرض زمانیکه سرویس ۲۰۱۶ SQL Server نصب می‌شود، با بررسی تعداد vCPU های تخصیص داده شده به ماشین مجازی اقدام به ایجاد TempDB ها می‌نماید.
برای رسیدن به این نتیجه که چه تعداد TempDB برای ماشین مجازی شما نیاز است، می‌بایست اقدام به انجام فرآیند تست استرس نمایید. ابزار ostress.exe برای اینکار مناسب می‌باشد.