Мигрирането на локален екземпляр на SQL Server към Azure Virtual Machine (VM) е често срещан метод за мигриране към Azure. ИТ специалистите са запознати с обхвата на размера на виртуалните машини по отношение на vCPU, паметта и капацитета за съхранение. Microsoft предлага множество типове и размери на VM за нуждите на организацията. Ще видите типовете, посочени като Family в Azure Portal при оразмеряване на VM.
Типове и размери на VM
Microsoft помогна за опростяване на нещата, като създаде множество видове виртуални машини. Типовете са насочени към дефиниране на машините по предназначение. Различните видове са:
- Общо предназначение – балансирано съотношение на процесора към паметта, малки до средни бази данни
- Оптимизиран за изчисления – Високо съотношение между процесор и памет, среден трафик уеб сървъри и сървъри за приложения
- Оптимизирана памет – Високо съотношение памет към процесор, сървъри за релационни бази данни, средни до големи кеш памети и анализи в паметта
- Оптимизирано съхранение – Висока дискова пропускателна способност и IO
- GPU – Тежко графично изобразяване и редактиране на видео
- Високопроизводителни изчисления – Най-бързите и най-мощни CPU виртуални машини
Във всеки тип/семейство има множество размери, от които да избирате. Размерите ви предлагат опции за броя на vCPU, RAM и дискове с данни. Броят на дисковете с данни ще определи максималния IOPS (IOPS означава входно/изходни операции в секунда.) и общият размер ще определи количеството налично временно съхранение. Някои размери също поддържат първокласно съхранение, което трябва да е изискване за производствен SQL сървър.
Опции за изображение на VM
Когато избирате изображение за SQL Server, имате няколко опции. Можете да изберете да изберете само ОС, като Linux или Windows, или можете да изберете да изберете изображение с вече инсталирана ОС и SQL Server. В момента предпочитам да избера изображението само с операционната система, за да мога да инсталирам SQL Server и да го конфигурирам както ми харесва. Когато изберете изображението на галерията с предварително инсталиран SQL Server, всички компоненти, включени в ISO за тази версия, се инсталират и не винаги се нуждая от инсталирани Integration Services или Analysis Services.
Съображения за оразмеряване на VM
Избирането на Azure VM може да изглежда лесно, с избора на размер въз основа на броя на vCPU, паметта и достатъчно място за съхранение, за да съхранявате вашите бази данни, но виждам, че клиентите имат проблеми с производителността, свързани със съхранението. Общата тенденция е да се избира виртуална машина, базирана изключително на vCPU, памет и капацитет за съхранение, без да се сравняват текущите изисквания за IO и пропускателна способност. Когато създавате Azure VM в Azure Portal, можете да филтрирате опциите въз основа на следното:
- Размер
- Генериране
- Семейство
- RAM/памет
- Премиум поддръжка за съхранение
- Брой vCPU
- Ефемерен OS диск
След като изберете опциите за филтриране, ако има такива, ще видите списък с наличните сървъри. В списъка той показва размера на VM, предлагането, семейството, vCPU, RAM, броя на поддържаните дискове с данни, максималния IOPS, временното съхранение (D:), ако се поддържа първокласен диск и приблизителната цена. Филтрирах следното на поддържан първокласен диск и размер, започващ с буквата E за оптимизирана памет.
Това, което не се показва обаче, е разрешената пропускателна способност на VM. Пропускателната способност измерва скоростта на трансфер на данни към и от носителя за съхранение в мегабайти в секунда.
Пропускателната способност може да се изчисли по следната формула
MB/s =IOPS * KB на IO / 1024
Използвайки тази формула, KB на IO ще бъде размерът на вашия блок. Ако форматирате вашите данни и регистрационни устройства на 64k, тогава формулата за E2s_v3, E4-2s_v3 и E8-2s_v3 VM с 3200, 6400 и 12 800 IOPS ще бъде:
MB/s =3200 * 64/1024 или 200 MB/s
MB/s =6400 * 64/1024 или 400 MB/s
MB/s =12 800 * 64/1024 или 800 MB
Изчисленията на пропускателната способност, базирани на IOPS на всяка виртуална машина с размер на блок 64k, не са твърде лоши. Тези числа не вземат предвид никакви санкции за запис за RAID. Подложих всяка от тези виртуальни машини на тест с помощта на CrystalDiskMark. Цифрите, които получих за пропускателна способност, не бяха близо до това, което изчисленията предвиждаха.
Сравнителен тест
Предоставих три виртуални машини от едно и също семейство, но с различни размери, и всяка с 2 vCPU. Спецификациите на виртуалните машини бяха:
- E2s_v3 – 2 vCPU – 16 GB RAM – 3200 IOPS – Поддържа до 4 диска с данни
- E4-2s_v3 – 2 vCPU – 32 GB RAM – 6400 IOPS – Поддържа до 8 диска с данни
- E8-2s_v3 – 2 vCPU – 64 GB RAM – 12 800 IOPS – Поддържа до 16 диска с данни
- P60 диск с данни – Premium SSD – 16 000 IOPS
На всяка виртуална машина осигурих P60 първокласен диск с капацитет 8TB. Този диск рекламира 16 000 IOPS, които с размер на блок от 64k могат да поддържат пропускателна способност от 1000 MBps, но документацията на Azure посочва, че дискът осигурява 500 MBps пропускателна способност.
CrystalDiskMark е инструмент за сравнителен анализ на дисково устройство с отворен код за Windows и се базира на инструмента Diskspd на Microsoft. Инструментът измерва последователната и произволна производителност на четене и запис.
В горната част на инструмента има някои падащи менюта. Числото 5 е броят на повторенията на теста, който ще се изпълнява. Следва 1GiB, това е размерът на тестовия файл. За реален производствен тест, това трябва да е достатъчно голямо, за да избегне удрянето в кеша. Версия 7.0 поддържа до 64 GiB файл. Последно е устройството, срещу което искате да извършите теста.
След като направите своя избор, можете да щракнете върху Всички, за да започнете поредицата от тестове. Тестът ще премине през различни последователни и произволни операции за четене/запис. Бъдете внимателни, ако планирате да сравните реални производствени сървъри. Този тест натоварва вашия диск и може драстично да повлияе на производственото натоварване. След часове или по време на прозорец за поддръжка би било за предпочитане.
Избрах да стартирам 5 повторения на теста с файл от 32 GiB на диска P60, който беше устройство E:.
E2s_v3 VM достигна максимална скорост под 50 MBps, което е много по-малко от 200MB, които изчислихме.
Виртуалната машина E4-2s_v3 достигна максимална скорост под 100 MBps вместо 400 MBps.
Виртуалната машина E8-2s_v3 достигна максимална скорост под 200 MBps, а не очакваните 800 MBps.
Защо по-ниска пропускателна способност?
Въз основа на моите по-ранни изчисления, 3200 IOPS при размер на блок от 64k трябва да произвеждат 200MB пропускателна способност, но не видях числа, близки до това, докато не разполагах с 16 000 IOPS диск на VM, който поддържа до 12 800 IOPS. Причината е, че всеки размер на VM има ограничение за пропускателна способност. Ако погледнете документацията за фамилията виртуални машини, оптимизирана за памет, ще откриете, че максималната пропускателна способност на некешириран диск на E2s е 3200 IOPS /48 MBps, максималната пропускателна способност на некешириран диск на E4s е 6400 IOPS / 96 MBps, а максималната пропускателна способност на некеширан диск на E8s пропускателната способност е 12 800 IOPS / 192 MBps. Тези числа съвпадат с резултатите, които получих с CrystalDiskMark.
Въпреки че можете да разпределите много големи дискове, които имат много IOPS и които поддържат високи числа на пропускателна способност, размерът на VM може да ограничи вашата пропускателна способност.
Сравнителен анализ на текущите ви нужди от пропускателна способност трябва да бъде голям приоритет, преди да мигрирате каквото и да е работно натоварване на SQL Server към Azure.
Заключение
Разбирам, че IOPS е мерна единица, която производителите на дискове и доставчиците за съхранение предоставят и това е добре. Въпреки това, когато става въпрос за тестване на съхранение, ние сме склонни да се фокусираме повече върху числата за пропускателна способност. Това е просто математически проблем, но освен ако не се занимавате с сравнителен анализ на съхранение и извършване на изчисления от IOPS до пропускателна способност въз основа на размера на блока, може да бъде объркващо.
Това, което ме притеснява, е фактът, че ограничението за пропускателна способност не е ясно, когато изберете размер на VM. Мерната единица за съхранение IO е IOPS. При 3200 IOPS с размер на блок от 64k, можех да съм около 200 MBps, но моята VM беше ограничена до 48 MBps. Много ИТ специалисти са открили, че имат проблеми с производителността на диска и са мащабирали съхранението си до по-голям и по-бърз диск (повече IOPS), очаквайки по-добра производителност, само за да открият, че това не е решило проблема им. Проблемът е, че размерът на виртуалната машина ограничава тяхната пропускателна способност. Увеличаването до по-висок размер VM ще реши проблема, но това идва с цена. В моя пример E4 беше два пъти по-висока от цената на E2, но удвои паметта и пропускателната способност, като същевременно запази същия vCPU. E8 беше двойно по-скъп от E4 и удвои пропускателната способност и паметта, като същевременно запази същия vCPU. Поддържането на същия брой vCPU означава, че няма да имам увеличение на цената на лиценза за основния SQL Server.
В крайна сметка трябва да сравните текущите си изисквания за пропускателна способност и да се уверите, че оразмерявате Azure VM или която и да е VM подходящо за вашите нужди. Не се фокусирайте само върху еталон на вашето локално хранилище, анализирайте от какво се нуждае вашето работно натоварване и съответно размера.
