Съображения за производителност на управляван екземпляр на Azure SQL

Azure SQL Database Managed Instance стана общодостъпен в края на 2018 г. Оттогава много организации започнаха да мигрират към Managed Instance за предимствата на управляваната среда. Организациите се възползват от това, че имат управлявани архиви, много вградени функции за сигурност, SLA от 99,99% и винаги актуална среда, в която вече не носят отговорност за корекцията на SQL Server или операционната система.

Управляваната инстанция предоставя две нива за производителност. Общата цел tier е проектиран за приложения с типични изисквания за производителност и I/O латентност и осигурява вградена HA. Критичен за бизнеса tier е проектиран за приложения, които изискват ниска I/O латентност и по-високи изисквания за HA. Business Critical също така предоставя два нечетими вторични и един вторичен за четене. Четимото вторично е чудесен начин за разпределяне на натоварването от основното, което може да понижи нивото на услугата, необходимо за основното – намалявайки общите разходи за екземпляра.

Когато Managed Instance беше пуснат за първи път, можете да избирате между процесори Gen4 и Gen5. Gen4 все още е описан в документацията, но тази опция е почти недостъпна сега. За тази статия ще разгледам само конфигурации, използващи процесори Gen5.

Всяко ниво на услугата поддържа от 4 до 80 логически CPU - известни също като виртуални ядра или vCores. Паметта се разпределя на приблизително 5,1 GB на vCore. General Purpose осигурява до 8 TB високопроизводително Azure Blob съхранение, докато Business Critical осигурява до 4 TB супер бързо локално SSD съхранение.

Памет

С наличието само на 5,1 GB памет на vCore, екземпляр с по-малко vCore може да се бори. Опциите за конфигурации на vCore са 4, 8, 16, 24, 32, 40, 64 и 80 vCore. Ако направите изчисленията за всяка от опциите vCore ((number of vCores) × (5.1 GB) ), ще получите следните комбинации ядро/памет:

 4 vCores =20,4 GB 8 vCores =40,8 GB 16 vCores =81,6 GB 24 vCores =122,4 GB 32 vCores =163,2 GB 40 vCores =204,0 GB 64 vCores =326,4 GB> 64 vCores =326,4 GB> 

 За много организации, за които помогнах да преминат от локален към управляван инстанция, забелязах значително намаляване на паметта. Типичните локални конфигурации биха били 4 vCore и 32 GB памет или 8 vCore и 64 GB. И двете представляват повече от 30% намаление на паметта. Ако инстанцията вече е била под натиск в паметта, това може да причини проблеми. В повечето случаи успяхме да оптимизираме локалния екземпляр, за да помогнем за облекчаване на напрежението в паметта, преди да преминем към управляван екземпляр, но в няколко случая клиентът трябваше да използва по-висок екземпляр vCore, за да облекчи натиска върху паметта . 
 
Съхранение 
 

 Съхранението е малко по-трудно за планиране и вземане под внимание, поради необходимостта да се вземат предвид множество фактори. За съхранение трябва да отчетете цялостното изискване за съхранение както за размера на съхранение, така и за нуждите от вход/изход. Колко GB или TB са необходими за екземпляра на SQL Server и колко бързо трябва да бъде съхранението? Колко IOPS и колко пропускателна способност използва локалният екземпляр? За това трябва да изчислите текущото си работно натоварване, като използвате perfmon за заснемане на средни и максимални MB/s и/или да направите моментни снимки на sys.dm_io_virtual_file_stats за улавяне на използването на пропускателната способност. Това ще ви даде представа какъв тип I/O и пропускателна способност са ви необходими в новата среда. Няколко клиенти, с които съм работил, са пропуснали тази жизненоважна част от планирането на миграцията и са се сблъскали с проблеми с производителността поради избор на ниво на екземпляр, което не поддържа тяхното работно натоварване. 
 

 Това е от решаващо значение за изходното ниво, тъй като при локалните сървъри е обичайно съхранението да се предоставя от супер бърза SAN с висока пропускателна способност до виртуални машини с по-малък размер. В Azure вашите IOPS и ограничения на пропускателната способност се определят от размера на изчислителния възел, а в случай на управление на инстанция, той се определя от броя на разпределените vCore. За общо предназначение има ограничение от 30-40k IOPS на екземпляр или от 500 до 12 500 IOPS на файл в зависимост от размера на файла. Пропускателната способност на файл също се основава на размер, започващ от 100 MiB/s за до 128 GB файлове и до 480 MiB/s за 4 TB и по-големи файлове. В Business Critical IOPS варират от 5,5K – 110K на екземпляр или 1375 IOPS на vCore.
 

 Потребителите трябва също да отчитат пропускателната способност на запис в регистрационни файлове за екземпляра. Общото предназначение е 3 MB/s на vCore с максимум 22 MB/s за екземпляра, а Business Critical е 4 MB/s на vCore с максимум 48 MB/s за целия екземпляр. Според моя опит в работата с клиенти, много от тях далеч надхвърлят тези граници за пропускателна способност на запис. За някои това е било показател, а за други те са успели да оптимизират и модифицират системата си, за да намалят натоварването. 
 

 В допълнение към необходимостта да се знае общата пропускателна способност и изискванията за I/O, размерът на съхранението също е обвързан с броя на избраните vCores. За общо предназначение:
 
 4 vCores =2 TB максимум 8 - 80 vCores =8 TB максимум
 

 За критични за бизнеса:
 
 4 – 16 vCores =1 TB 24 vCores =2 TB 32 - 80 vCores =4 TB
 

 За общо предназначение, след като стигнете до 8 vCore, можете да увеличите максимално наличното хранилище, което работи добре за тези, които се нуждаят само от общо предназначение. Но когато имате нужда от бизнес критичен, нещата могат да бъдат по-предизвикателни. Работил съм с много клиенти, които имат множество TB, разпределени на виртуални машини с 4, 8, 16 и 24 логически процесора. За всеки от тези клиенти те ще трябва да преместят най-малко 32 vCores, само за да отговорят на изискването си за съхранение, скъпа опция. Azure SQL Database има подобен проблем с максималния размер на базата данни и Microsoft излезе с опция за Hyperscale. Очакваме това да стане опция за управляван екземпляр в даден момент, за да адресира ограниченията за съхранение по подобен начин. 
 

 Размерът на tempdb също е свързан с броя vCores. В нивото с общо предназначение получавате 24 GB на vCore (до 1920 GB) за файловете с данни, с ограничение за размера на регистрационния файл tempdb от 120 GB. За ниво Business Critical, tempdb може да нарасне чак до наличния в момента размер за съхранение на екземпляра. 
 
OLTP в паметта
 

 За тези, които понастоящем се възползват от In-Memory OLTP (или планират да го), имайте предвид, че той се поддържа само в нивото на услугата Business Critical. Количеството налично пространство за таблици в паметта също е ограничено от vCores:
 
 4 vCores =3,14 GB 8 vCore =6,28 GB 16 vCores =15,77 GB 24 vCores =25,25 GB 32 vCores =37,94 GB 40 vCores =52,23 GB 64 vCores =99,90 GB  =99,90 GB>. 
Заключение
 

 Когато планирате миграция към Azure SQL Managed Instance, има множество съображения, които трябва да вземете предвид, преди да вземете решение за мигриране. Първо трябва да разберете напълно вашите изисквания за памет, процесор и съхранение, тъй като това ще определи размера на екземпляра. Също толкова важно е да знаете какви са вашите изисквания за вход/изход за съхранение. IOPS и пропускателната способност за ниво с общо предназначение са директно обвързани с vCores и размера на файловете на базата данни. За Business Critical тя е обвързана с броя vCore. Ако имате много интензивно I/O работно натоварване, Business Critical е по-привлекателното ниво на услугата, тъй като осигурява по-високи IOPS и номера на пропускателна способност. Предизвикателството с Business Critical е по-ниският капацитет за съхранение и поддръжка само на 1TB за целия екземпляр до 16 vCores. 
 

 С правилно планиране и възможно деконсолидиране на по-големи екземпляри към по-малки управлявани инстанции, това предложение може да бъде много жизнеспособна опция за миграция за много организации. Привлекателните са предимствата на притежаването на управлявани архиви, вградена HA със SLA от 99,99%, добавени функции и опции за сигурност и не се налага да се притеснявате за корекция на операционна система или екземпляр на SQL Server.