Migrering af en lokal SQL Server-instans til en Azure Virtual Machine (VM) er en almindelig metode til at migrere til Azure. IT-professionelle er bekendt med at måle størrelsen på VM'er med hensyn til vCPU, hukommelse og lagerkapacitet. Microsoft tilbyder flere VM-typer og -størrelser til en organisations behov. Du vil se de typer, der refereres til som Family i Azure Portal, når en VM skal dimensioneres.
VM-typer og -størrelser
Microsoft har hjulpet med at forenkle tingene ved at skabe flere typer virtuelle maskiner. Typerne er rettet mod at definere maskinerne efter formål. De forskellige typer er:
- Generelle formål – Balanceret CPU-til-hukommelse-forhold, små til mellemstore databaser
- Beregningsoptimeret – Høj CPU-til-hukommelse ration, medium trafik webservere og applikationsservere
- Hukommelsesoptimeret – Højt hukommelse-til-CPU-forhold, relationelle databaseservere, mellemstore til store caches og hukommelsesanalyse
- Lager optimeret – Høj diskgennemstrømning og IO
- GPU – Tung grafisk gengivelse og videoredigering
- Højtydende beregning – Hurtigste og mest kraftfulde CPU virtuelle maskiner
Inden for hver type/familie er der adskillige størrelser at vælge imellem. Størrelserne giver dig muligheder for antallet af vCPU'er, RAM og datadiske. Antallet af datadiske vil bestemme maksimal IOPS (IOPS står for input/output operations per second.), og den samlede størrelse vil bestemme mængden af midlertidig lagerplads, der er tilgængelig. Visse størrelser understøtter også premium-lagring, hvilket burde være et krav til en produktions-SQL-server.
VM-billedindstillinger
Når du vælger et billede til SQL Server, har du flere muligheder. Du kan vælge kun at vælge OS, såsom Linux eller Windows, eller du kan vælge at vælge et billede med OS og SQL Server allerede installeret. I øjeblikket foretrækker jeg at vælge billedet med kun OS, så jeg kan installere SQL Server og konfigurere det, som jeg kan lide. Når du vælger galleribilledet med SQL Server forudinstalleret, installeres alle komponenter, der er inkluderet i ISO for den pågældende version, og jeg har ikke altid brug for Integration Services eller Analysis Services installeret.
VM-størrelsesovervejelser
At vælge en Azure VM kan virke ligetil, med at vælge en størrelse baseret på antallet af vCPU, hukommelse og nok lagerplads til at opbevare dine databaser, men jeg kan se, at kunder har problemer med ydeevnen relateret til lager. Den almindelige tendens er at vælge en VM udelukkende baseret på vCPU, hukommelse og lagerkapacitet uden at benchmarke de nuværende IO- og gennemløbskrav. Når du opretter en Azure VM i Azure Portal, kan du filtrere indstillingerne baseret på følgende:
- Størrelse
- Generation
- Familie
- RAM/hukommelse
- Premium-lagerunderstøttelse
- Antal vCPU'er
- Ephemeral OS-disk
Når du har valgt dine filterindstillinger, hvis nogen, vil du se en liste over tilgængelige servere. På listen viser den VM-størrelse, tilbud, familie, vCPU, RAM, antal understøttede datadiske, max IOPS, midlertidig lagring (D:), hvis premium-disk understøttes, og anslåede omkostninger. Jeg har filtreret følgende på premium disk understøttet og størrelse startende med bogstavet E for hukommelsesoptimeret.
Hvad der dog ikke vises, er mængden af tilladte gennemløb pr. VM. Gennemstrømning måler dataoverførselshastigheden til og fra lagermediet i megabyte per sekund.
Gennemløbet kan beregnes ved hjælp af følgende formel
MB/s =IOPS * KB pr. IO / 1.024
Ved at bruge denne formel vil KB pr. IO være din blokstørrelse. Hvis du formaterer dine data og log-drev ved 64k, så ville formlen for E2s_v3, E4-2s_v3 og E8-2s_v3 VM'erne med 3.200, 6.400 og 12.800 IOPS være:
MB/s =3.200 * 64/1.024 eller 200 MB/s
MB/s =6.400 * 64/1.024 eller 400 MB/s
MB/s =12.800 * 64/1.024 eller 800 MB/s
Gennemløbsberegningerne baseret på IOPS for hver VM med en 64k blokstørrelse er ikke så dårlige. Disse tal tager ikke hensyn til eventuelle skrivestraffe for RAID. Jeg testede hver af disse VM'er ved hjælp af CrystalDiskMark. De tal, jeg fik for gennemstrømning, var ikke i nærheden af, hvad beregningerne estimerede.
Benchmark-test
Jeg klargjorde tre virtuelle maskiner af samme familie, dog forskellige størrelser, og hver med 2 vCPU'er. Specifikationerne for de virtuelle maskiner var:
- E2s_v3 – 2 vCPU – 16 GB RAM – 3.200 IOPS – Understøtter op til 4 datadiske
- E4-2s_v3 – 2 vCPU – 32 GB RAM – 6.400 IOPS – Understøtter op til 8 datadiske
- E8-2s_v3 – 2 vCPU – 64 GB RAM – 12.800 IOPS – Understøtter op til 16 datadiske
- P60-datadisk – Premium SSD – 16.000 IOPS
På hver VM leverede jeg en P60 premium-disk med 8 TB kapacitet. Denne disk annoncerede 16.000 IOPS, som med en blokstørrelse på 64k kunne understøtte 1.000 MBps gennemløb, men Azure-dokumentationen angiver, at disken giver 500 MBps gennemløb.
CrystalDiskMark er et benchmarkværktøj til open source diskdrev til Windows, og det er baseret på Microsofts Diskspd-værktøj. Værktøjet måler sekventiel og tilfældig ydelse af læsning og skrivning.
På tværs af toppen af værktøjet er nogle drop downs. Tallet 5 er antallet af iterationer af testen, der vil blive kørt. Næste er 1GiB, dette er størrelsen på testfilen. For en rigtig produktionstest bør denne være stor nok til at hjælpe med at undgå at ramme cache. Version 7.0 understøtter op til en 64 GiB fil. Sidst er det drev, som du vil udføre testen mod.
Når du har foretaget dit valg, kan du klikke på Alle for at starte testserien. Testen går gennem forskellige sekventielle og tilfældige læse/skrive-operationer. Vær forsigtig, hvis du planlægger at benchmarke rigtige produktionsservere. Denne test belaster din disk og kan drastisk påvirke en produktionsbelastning. Efter timer eller under et vedligeholdelsesvindue foretrækkes.
Jeg valgte at køre 5 iterationer af testen med en 32 GiB fil på P60-disken, som var drev E:.
E2s_v3 VM maxede under 50 MBps, hvilket er langt mindre end de 200 MB, vi beregnede.
E4-2s_v3 VM maxede under 100 MBps i stedet for 400 MBps.
E8-2s_v3 VM maxede under 200 MBps i stedet for de anslåede 800 MBps.
Hvorfor lavere gennemløb?
Baseret på mine tidligere beregninger skulle 3.200 IOPS ved 64.000 blokstørrelser producere 200 MB gennemløb, men jeg så ikke tal tæt på det, før jeg havde en 16.000 IOPS-disk på en VM, der understøtter op til 12.800 IOPS. Begrundelsen er, at hver VM-størrelse har en grænse for gennemløb. Hvis du ser på dokumentationen for den hukommelsesoptimerede familie af VM'er, vil du opdage, at E2s maks. uncached diskgennemstrømning er 3.200 IOPS /48 MBps, E4s maks. uncached diskgennemstrømning er 6.400 IOPS / 96 MBps, og E8s max uncached disk. gennemløbet er 12.800 IOPS / 192 MBps. Disse tal falder sammen med de resultater, jeg opnåede med CrystalDiskMark.
Selvom du kan tildele meget store diske, der har masser af IOPS, og som understøtter høje gennemløbstal, kan VM-størrelsen meget vel begrænse din gennemstrømning.
Benchmarking af dine nuværende gennemstrømningsbehov bør være en stor prioritet, før du migrerer en SQL Server-arbejdsbelastning til Azure.
Konklusion
Jeg forstår, at IOPS er en måleenhed, som diskproducenter og lagerleverandører leverer, og det er ok. Men når det kommer til at teste lagring, har vi en tendens til at fokusere mere på gennemløbstal. Det er kun et matematisk problem, men medmindre du er i gang med at benchmarke lagring og lave beregningerne fra IOPS til gennemløb baseret på blokstørrelse, kan det være forvirrende.
Det, der bekymrer mig, er det faktum, at begrænsningen på gennemløbet ikke er tydelig, når du vælger en VM-størrelse. Måleenheden for lager-IO er IOPS. Ved 3.200 IOPS med en blokstørrelse på 64k kunne jeg være omkring 200 MBps, men min VM var begrænset til 48 MBps. Mange it-professionelle har opdaget, at de har problemer med diskens ydeevne og skaleret deres lager til større og hurtigere diske (mere IOPS) og forventer bedre ydeevne, blot for at opdage, at det ikke løste deres problem. Problemet er, at størrelsen på VM'en begrænsede deres gennemstrømning. Opskalering til en højere størrelse VM ville løse problemet, men det kommer med en omkostning. I mit eksempel var E4 dobbelt så meget som E2, men den fordoblede hukommelsen og gennemløbet, mens den bibeholdt den samme vCPU. E8 var det dobbelte af prisen på E4 og fordoblede kapaciteten og hukommelsen, mens den beholdt den samme vCPU. At bevare det samme vCPU-antal betyder, at jeg ikke ville have en stigning i omkostningerne til kerne-SQL Server-licenser.
I sidste ende skal du benchmarke dine nuværende gennemløbskrav og sikre dig, at du dimensionerer Azure VM eller en hvilken som helst VM, der passer til dine behov. Fokuser ikke kun på et benchmark af din lokale lagerplads, analyser hvad din arbejdsbyrde har brug for og størrelse i overensstemmelse hermed.