Azure SQL Database Managed Instance blev generelt tilgængelig i slutningen af 2018. Siden da er mange organisationer begyndt at migrere til Managed Instance til fordel for et administreret miljø. Organisationer drager fordel af at have administrerede sikkerhedskopier, masser af indbyggede sikkerhedsfunktioner, en oppetid SLA på 99,99 % og et altid opdateret miljø, hvor de ikke længere er ansvarlige for at patche SQL Server eller operativsystemet.
En størrelse gør ikke passer altid til alle. Administreret forekomst giver to niveauer for ydeevne. Det generelle formål tier er designet til applikationer med typiske krav til ydeevne og I/O-latens og giver indbygget HA. Forretningskritiske tier er designet til applikationer, der kræver lav I/O-latens og højere HA-krav. Business Critical giver også to ikke-læsbare sekundære og en læsbar sekundær. Den læsbare sekundære er en fantastisk måde at fordele arbejdsbyrden på fra den primære, hvilket kan sænke det serviceniveau, der kræves for det primære - hvilket reducerer det samlede forbrug for forekomsten.
Da Managed Instance først blev udgivet, kunne du vælge mellem Gen4- og Gen5-processorer. Gen4 er stadig beskrevet i dokumentationen, men denne mulighed er for det meste ikke tilgængelig nu. Til denne artikel vil jeg kun dække konfigurationer ved hjælp af Gen5-processorer.
Hvert serviceniveau understøtter alt fra 4 til 80 logiske CPU'er - også kendt som virtuelle kerner eller vCores. Hukommelse er tildelt ca. 5,1 GB pr. vCore. General Purpose giver op til 8 TB højtydende Azure Blob-lagring, mens Business Critical giver op til 4 TB superhurtig lokal SSD-lagring.
Hukommelse
Med kun at have 5,1 GB hukommelse pr. vCore, kunne en instans med færre vCores kæmpe. Valgmulighederne for vCore-konfigurationer er 4, 8, 16, 24, 32, 40, 64 og 80 vCores. Hvis du regner på hver af vCore-indstillingerne ((number of vCores) × (5.1 GB) ), får du følgende kerne-/hukommelseskombinationer:
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 0.For mange organisationer, jeg har hjulpet med overgangen fra lokalt til administreret forekomst, har jeg set en betydelig reduktion i hukommelsen. Typiske konfigurationer på stedet vil være 4 vCores og 32 GB hukommelse eller 8 vCores og 64 GB. Begge tegner sig for mere end 30 % reduktion i hukommelsen. Hvis instansen allerede var under pres på hukommelsen, kan dette forårsage problemer. I de fleste tilfælde har vi været i stand til at optimere den lokale instans for at hjælpe med at afhjælpe hukommelsespresset, før vi flyttede til Managed Instance, men i nogle få tilfælde måtte kunden gå med en højere vCore-instans for at lette hukommelsespresset .
Lagring
Opbevaring er lidt sværere at planlægge og gøre sig overvejelser om, da der skal tages hensyn til flere faktorer. Til opbevaring skal du tage højde for det samlede lagerbehov for både lagerstørrelse og I/O-behov. Hvor mange GB'er eller TB'er er nødvendige for SQL Server-forekomsten, og hvor hurtigt skal lagringen være? Hvor mange IOPS og hvor meget gennemløb bruger den lokale instans? Til det skal du baseline din nuværende arbejdsbyrde ved at bruge perfmon til at fange gennemsnit og maks. MB/s og/eller tage snapshots af sys.dm_io_virtual_file_stats for at fange gennemstrømningsudnyttelse. Dette vil give dig en idé om, hvilken type I/O og gennemstrømning du har brug for i det nye miljø. Adskillige kunder, jeg har arbejdet med, er gået glip af denne vitale del af migrationsplanlægningen og er stødt på ydeevneproblemer på grund af valg af et instansniveau, der ikke understøttede deres arbejdsbyrde.
Dette er afgørende for baseline, fordi det med lokale servere er almindeligt at have lager leveret fra et superhurtigt SAN med høj gennemløbskapacitet til mindre virtuelle maskiner. I Azure bestemmes dine IOPS- og gennemløbsgrænser af størrelsen af compute node, og i tilfælde af Manage Instance bestemmes det af antallet af allokerede vCores. Til generelle formål er der en grænse på 30-40k IOPS pr. instans eller 500 op til 12.500 IOPS pr. fil afhængigt af filstørrelsen. Gennemstrømning pr. fil er også baseret på størrelser fra 100 MiB/s for op til 128 GB filer og op til 480 MiB/s for 4 TB og større filer. I Business Critical varierer IOPS fra 5,5K – 110K pr. instans eller 1.375 IOPS pr. vCore.
Forbrugerne skal også tage højde for logskrivningsgennemstrømning for forekomsten. General Purpose er 3 MB/s pr. vCore med maks. 22MB/s for instansen, og Business Critical er 4 MB/s pr. vCore med maks. 48 MB/s for hele instansen. I min erfaring med at arbejde med kunder har mange langt overskredet disse grænser for skrivegennemstrømning. For nogle har det været en showstopper, og for andre har de været i stand til at optimere og modificere deres system for at mindske belastningen.
Ud over at have behov for at kende overordnet gennemløb og I/O-krav, er lagerstørrelsen også bundet til antallet af valgte vCores. Til generelle formål:
4 vCores =2 TB maks. 8 - 80 vCores =8 TB maks.For forretningskritiske:
4 – 16 vCores =1 TB 24 vCores =2 TB 32 - 80 vCores =4 TBTil General Purpose, når du når til 8 vCores, kan du maksimalt ud af den tilgængelige lagerplads, hvilket fungerer godt for dem, der kun har brug for General Purpose. Men når du har brug for Business Critical, kan tingene være mere udfordrende. Jeg har arbejdet med mange kunder, der har flere TB'er allokeret til VM'er med 4, 8, 16 og 24 logiske processorer. For enhver af disse kunder ville de skulle rykke op med mindst 32 vCores bare for at opfylde deres lagerkrav, en kostbar mulighed. Azure SQL Database har et lignende problem med maksimal databasestørrelse, og Microsoft kom med en Hyperscale-indstilling. Vi forventer, at dette bliver en mulighed for Managed Instance på et tidspunkt for at adressere lagergrænserne på lignende måde.
Størrelsen af tempdb er også korreleret til antallet af vCores. I General Purpose-niveauet får du 24 GB pr. vCore (op til 1.920 GB) for datafilerne med en tempdb-logfilstørrelsesgrænse på 120 GB. For Business Critical-laget kan tempdb vokse helt op til den aktuelt tilgængelige instanslagerstørrelse.
OLTP i hukommelsen
For dem, der i øjeblikket drager fordel af In-Memory OLTP (eller planlægger at), skal du bemærke, at det kun understøttes i Business Critical-tjenesteniveauet. Mængden af ledig plads til In-Memory-tabeller er også begrænset af vCores:
4 vCores =3,14 GB 8 vCores =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 =90,30 GB 89,10 GBKonklusion
Når du planlægger en migrering til Azure SQL Managed Instance, er der flere overvejelser, der skal tages i betragtning, før du beslutter dig for at migrere. Først skal du fuldt ud forstå dine hukommelses-, CPU- og lagerkrav, da dette vil bestemme størrelsen af instansen. Lige så vigtigt er det at vide, hvad dine storage I/O-krav er. IOPS og gennemløb for General Purpose tier er direkte knyttet til vCores og størrelsen af databasefilerne. For Business Critical er det bundet til antallet af vCores. Hvis du har en meget I/O-intensiv arbejdsbyrde, er Business Critical det mere tiltalende serviceniveau, fordi det giver højere IOPS- og gennemstrømningstal. Udfordringen med Business Critical er den lavere lagerkapacitet og kun understøttelse af 1 TB for hele instansen op til 16 vCores.
Med ordentlig planlægning og mulig dekonsolidering af større instanser til mindre administrerede instanser kan dette tilbud være en meget levedygtig migreringsmulighed for mange organisationer. Appellen er fordelene ved at have administrerede sikkerhedskopier, indbygget HA med en SLA på 99,99%, tilføjede sikkerhedsfunktioner og muligheder og ikke at skulle bekymre sig om at patche en OS- eller SQL Server-instans.