Най-добри практики за SQL Server, Част II: Виртуализирани среди

2016 г. е и някои хора все още смятат, че SQL Server не може да се изпълнява на виртуална машина. SQL Server може успешно да работи във виртуална машина, но SQL изисква много ресурси по природа и така че, ако ще виртуализирате SQL, просто трябва да се придържате към най-добрите практики. Неспазването на най-добрите практики може да бъде разликата между лошата и изключителната производителност на виртуалния SQL Server. Моля, вижте предишната ми публикация в блога относно общите най-добри практики за SQL сървър, тъй като те се прилагат и във виртуализирана среда.

Управление на захранването

Физическият VM хост трябва да бъде настроен на висока производителност в BIOS, за да се гарантира, че работи на всички цилиндри, което от своя страна ще позволи на хипервайзора да разпредели абстрахираните ресурси, както намери за добре .

Управлението на захранването винаги трябва да бъде настроено на висока производителност в Windows VM. Balanced е настройка за лаптопи, които трябва да резервират мощност. VM могат да имат сериозни проблеми с производителността, ако не са конфигурирани правилно. В някои среди настройките за управление на захранването на VM могат да се контролират от хипервайзора, но когато се използват приложения с интензивно използване на ресурси като SQL сървър, уверете се, че управлението на захранването на Windows е настроено на висока производителност.

Винаги използвайте SLAT съвместим сървърен хардуер

Въпреки че може да не е така с по-стария хардуер, повечето съвременни сървъри имат x64 процесори, които поддържат SLAT (превод на адреси от второ ниво).

Хостовете на VMware и Hyper-V трябва да работят с 64-битови x64 процесори (AMD или Intel). Абсолютно жизненоважно е хост процесорът да поддържа SLAT. SLAT има няколко псевдонима.

SLAT позволява на процесора да поддържа съпоставянето между виртуалната памет, използвана от VM, и физическата памет на хоста на хипервизора. Ако процесорът не може да изпълни това картографиране на паметта, това ще бъде на хипервайзора. И производителността, и мащабируемостта се подобряват, като CPU извършва картографирането на паметта.

Проучвания на Microsoft са доказали, че SLAT:

Не мислете много за това – просто се уверете, че хардуерът на основния VM хост поддържа SLAT.

Не прекалявайте с процесора на VM хост

Не мога да подчертая достатъчно тази точка. Ако прекалите с VM хоста и имате ресурсоемки приложения като SQL сървър, работещи на VM на този VM хост, тогава ще срещнете проблеми с производителността рано или късно. Не е проблем, ако имате куп сървъри за уеб/приложения с ниско използване на ресурси, които споделят ресурси, тъй като хипервайзорът може лесно да следи коя виртуална машина от кои ресурси се нуждае, но когато включите ресурсоемки приложения в микса, това е рецепта за катастрофа.

Ако вашето виртуализирано работно натоварване на SQL Server е много интензивно, тогава се уверете, че използвате най-новата версия на Hyper-V или vSphere, тъй като всяка итерация идва с нови максимуми за скалируемост.

Най-добрата практика за първоначално оразмеряване на виртуална машина, особено такава, която ще хоства приложение с интензивно използване на ресурси като SQL сървър, е да се уверите, че общият брой виртуални процесори, присвоени на виртуалната машина, не надвишава броя на физическите процесори гнезда (за разлика от логическите ядра), налични на хост машината.

Готовност на процесора

Това не е нещо, което искате да срещнете, тъй като е показателно за свръхобезпечена виртуална машина и/или хост. Готовността на процесора е времето, през което една виртуална машина е готова (има нужда) от тактови цикли на процесора на физическия хост, но трябва да изчака, за да получи време, защото други виртуални машини вече използват ресурсите.

Изчисляването на времето за готовност може да бъде трудно, защото зависи от интервала на запитване за показателя, представен на VM хоста, напр. 20 секунди (20 000 милисекунди):

(Стойност на готовност на процесора / 20 000 ms) x 100% = Процентно въздействие върху производителността за интервал от 20 секунди.

Ако екстраполирате във времето, можете бързо да видите как това би причинило влошаване на производителността, особено ако се изпълняват приложения с висока производителност като SQL сървър.

Стойностите на готовност <5% за vCPU обикновено са ОК. Готови стойности >5% за vCPU са предупреждение и вероятно вече изпитвате влошаване на производителността.

Без каквато и да е неправилна конфигурация, изобщо не е трудно да се намерят стойности за готовност на CPU от >=10% поради някои големи виртуални машини с няколко vCPU, работещи на няколко физически ядра, или подобна диспропорция между vCPU и pCPU.

Ако самата виртуална машина е свръхобезпечена, напр. VM с 8 vCPU трябва да изчака всичките 8 pCPU на базовия VM хост да бъдат свободни, преди да получи каквито и да е тактови цикли. Това е мястото, където правилният размер идва в сила. Ако виртуалната машина наистина се нуждае от голям брой vCPU, тогава непременно ги добавете. Ако оразмерявате ново приложение, добавете само vCPU, докато наблюдавате производителността. Диспечерът на задачите на Windows не е чудесен показател за производителност във виртуализирана среда и затова наблюдавайте от страната на VM хоста. Ако всички vCPU са максимизирани, вероятно има нужда от повече vCPU. Ако не, тогава оставете достатъчно добре. Виждал съм ситуации, при които премахването на vCPU от VM всъщност подобрява производителността на приложенията с бази данни, хоствани на този виртуален SQL сървър.

Ако VM хостът е свръхобезпечен, тогава има няколко VM, работещи на този хост, които се конкурират за ресурси. Ако случаят е такъв, трябва да мигрирате някои виртуални машини към други хостове, за да облекчите проблемите с конкуренцията за ресурси.

Еквивалентът на CPU ready на Hyper-V е броячът на Perfmon Hyper-V Hypervisor Virtual Processor\CPU Wait Time Per Dispatch, който е наличен от Windows Server 2012.

Hyper-threading

Hyper-threading е технология на Intel, която разкрива два хардуерни контекста (нишки) от едно физическо ядро. Тези нишки се наричат ​​логически процесори. Често срещано погрешно схващане е, че хипернишковостта удвоява броя на процесорите или ядрата. Това просто не е така. Hyper-threading подобрява общата пропускателна способност на хоста от 10-30%, като поддържа конвейера на процесора по-натоварен и позволява на хипервайзора да планира повече тактови цикли на процесора, така че определено трябва да се възползвате от Hyper-threading, като го активирате в BIOS на VM хост машина.

Ядра на гнездо

NUMA (неравномерен достъп до паметта) разпределя на всеки процесор собствена локална памет. Комбинацията от процесор и памет е известна като NUMA възел. Предимствата на NUMA са, че позволява на процесора да осъществява достъп до собствената си локална памет по-бързо, отколкото би могъл да осъществява достъп до нелокалната памет. И Windows, и SQL са напълно запознати с NUMA и вземат решения за планиране на нишки въз основа на топологията NUMA.

vNUMA представя NUMA архитектурата на физическия VM хост директно на гост OS на VM. vNUMA топологията на VM може да обхваща множество физически NUMA възли. След като VM с активиран vNUMA се включи, архитектурата, представена на ОС, не може да бъде променена. Това всъщност е положително нещо, защото промяната на vNUMA архитектурата може да причини нестабилност в операционната система. Това ограничение обаче може да причини проблеми, ако се направи опит за мигриране на VM към друг VM хост, който има различна NUMA архитектура.

vNUMA е активирана по подразбиране за виртуални машини, които имат повече от 8 vCPU (независимо от комбинацията от сокети и ядра, която съставлява броя на vCPU в игра).

Най-добра практика:

Броят на виртуалните гнезда трябва да е равен на броя vCPU, които искате (едно ядро ​​на гнездо).

Това е настройката по подразбиране при създаване на виртуална машина. Тази конфигурация е известна като широка и плоска и vNUMA ще представи оптималната vNUMA топология на гост операционната система, базирана на NUMA топологията на основния физически VM хост сървър. Ако конфигурацията на VM не е широка и плоска, тогава vNUMA няма да може автоматично да избере най-добрата NUMA конфигурация и вместо това просто ще съвпадне с въведената от вас конфигурация, което може да доведе до несъответствие на NUMA топология, което се отразява пагубно на производителността.

Лицензионните ограничения са най-честата причина, поради която администраторите избират да се противопоставят на тези най-добри практики. Ако трябва да използвате, направете го, уверете се, че отразявате най-малко NUMA топологията на физическия VM хост.

Горещо добавяне на процесора

Тази настройка може да бъде малко уловка 22 – активирането и деактивирането има плюсове и минуси.

Плюсове

CPU hot plug позволява на VM администраторите да добавят CPU в движение към VM, без да е необходимо първо да изключват VM. CPU hot plug позволява динамично управление на ресурсите и възможност за добавяне на процесори, когато vNUMA не се изисква (обикновено по-малки виртуални машини).

Против

Когато горещото добавяне на CPU е активирано на VM, това автоматично деактивира vNUMA. SQL сървърите, които са по-широки от NUMA архитектурата на физическия сървър, на който се намират, не могат да видят основната NUMA архитектура, което води до влошаване на производителността.

Дали да активирате горещо добавяне на процесора или не се свежда до въпроса колко широка ще бъде вашата виртуална машина. Моята препоръка е да деактивирате горещото добавяне на процесора за по-големи виртуални машини, които изискват vNUMA. Предотвратяването винаги е по-добро от лечението и затова отделете време за правилното оразмеряване на процесора на виртуалната машина на SQL сървъра, вместо да разчитате на горещо добавяне на процесора като резервен вариант.

CPU афинитет

Не препоръчвам използването на CPU афинитет на производствени машини, защото ограничава способността на хипервайзора да планира ефективно vCPU на физическия сървър.

Не прекалявайте с паметта на хоста на VM

Отново не мога да наблегна на това достатъчно. Когато първоначално оразмерявате SQL VM, уверете се, че хостът не е и няма да бъде претоварен, когато SQL VM е включена. Не забравяйте, че VM хост машината има собствена памет, за да работи и с операционната система на хипервизора!

Резервиране на памет

SQL сървърът е прасе за памет и така каквато и памет да му хвърлите, ще бъде използвана, а не освободена. Поради това може да има смисъл да настроите резервацията на паметта за SQL VM да се равнява на предоставената памет минус 4-6GB, за да функционира Windows. Това значително ще намали вероятността от балониране и размяна и ще гарантира, че виртуалната машина получава паметта, от която се нуждае за оптимална производителност. Резервациите на памет обаче могат да предотвратят миграцията на виртуални машини между хостове, ако целевият хост няма незапазена памет, равна или по-голяма от размера на резервацията на паметта.

За да изчислите количеството памет за предоставяне на виртуална машина:

Специализирана срещу динамична памет

Да , това противоречи на основите на виртуализацията и така може да загубите битката с вашия администратор за виртуализация, но си струва да спорите. Специализираните ресурси означават, че можете да изключите битката за ресурси на VM хоста от уравнението.

Паметта е един от най-важните фактори, когато става въпрос за производителността на SQL Server. SQL използва памет за своя вътрешен буфер (наскоро използвани данни) и кешове на процедури (наскоро изпълнени T-SQL команди). Тези буфери означават, че SQL Server може да получи данните и командите, които изисква от кеш паметта, вместо да се налага да отива на диска и да поема свързаните I/O разходи. SQL Server може автоматично да управлява и увеличава своя буфер и кешове за процедури въз основа на изискванията на работното натоварване и наличната памет. Ако няма налична памет, производителността ще бъде засегната.

Ако вашият администратор за виртуализация е изключил специалната памет, тогава попитайте за Hyper-V Dynamic Memory или VMware конфигурации на overcommit памет.

VMware третира паметта като споделен ресурс и всеки мегабайт памет се счита за индивидуален дял. Memory overcommit е автоматизиран динамичен процес, който взема дялове от виртуални машини, които не ги използват, и разпределя тези дялове към други виртуални машини според изискванията.

Паметта се възстановява от VM, които имат по-малко пропорционални дялове, за да се даде на VM с повече пропорционални дялове и затова се уверете, че SQL VM има достатъчно високо тегло на дяловете.

Динамичната памет Hyper-V също динамично разпределя неизползваната памет. И в двете технологии виртуалните машини запазват 25% от неизползваната памет като възглавница, в случай че внезапно се нуждае от повече памет.

Заслужава да се отбележи, че изданията Datacenter или Enterprise на SQL 2008 или по-нови се изискват, за да поддържат RAM с горещо добавяне. Сървърните операционни системи на Microsoft са съвместими с горещо добавяне от W2K3r2sp2.

Не съхранявайте файлове на един и същи диск

OS файлове, SQL файлове с данни, SQL регистрационни файлове, SQL резервни копия и т.н... всички ще завършат на един и същ VHD, ако изградите VM със стандартния настройки и инсталирайте SQL с настройките по подразбиране.

Двоичните файлове на SQL Server, файловете с данни трябва да бъдат поставени на отделни VMDK.

Използвайте RAID 10 за потребителски данни, регистрационни файлове и TempDB файлове за най-добра производителност и наличност.

Вижте предишната ми публикация за най-добрите практики на SQL сървъра във връзка с оразмеряването на tempdb.

Заключение

Виртуализираният SQL Server може да осигури производителност и мащабируемост за поддръжка на производствени приложения за бази данни, при условие че се следват най-добрите практики.

Това е поредица от няколко части за най-добрите практики на SQL Server. Прочетете част I тук.

Източници:

http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf

http://download.microsoft.com/download/6/1/d/61dde9b6-ab46-48ca-8380-d7714c9cb1ab/best_practices_for_virtualizing_and_managing_sql_server_2012.pdf