Att migrera en lokal SQL Server-instans till en Azure Virtual Machine (VM) är en vanlig metod för att migrera till Azure. IT-proffs är bekanta med att avgränsa storleken på virtuella datorer med avseende på vCPU, minne och lagringskapacitet. Microsoft erbjuder flera VM-typer och storlekar för en organisations behov. Du kommer att se typerna som refereras till som Family i Azure Portal när du ändrar storlek på en virtuell dator.
VM-typer och storlekar
Microsoft har hjälpt till att förenkla saker genom att skapa flera typer av virtuella maskiner. Typerna är inriktade på att definiera maskinerna efter syfte. De olika typerna är:
- Allmänt syfte – Balanserat CPU-till-minne-förhållande, små till medelstora databaser
- Beräkningsoptimerad – Hög CPU-till-minne-kvot, webbservrar och applikationsservrar med medelstor trafik
- Minnesoptimerat – Högt minne-till-CPU-förhållande, relationsdatabasservrar, medelstora till stora cachar och in-memory-analys
- Lagringsoptimerad – Hög diskgenomströmning och IO
- GPU – Tung grafisk rendering och videoredigering
- Högpresterande beräkning – snabbaste och mest kraftfulla virtuella CPU-maskiner
Inom varje typ/familj finns det många storlekar att välja mellan. Storlekarna ger dig alternativ för antalet vCPU:er, RAM och datadiskar. Antalet datadiskar kommer att avgöra maximal IOPS (IOPS står för input/output operations per second.) och den totala storleken avgör mängden tillgänglig tillfällig lagring. Vissa storlekar stöder även premiumlagring, vilket borde vara ett krav för en produktions-SQL-server.
VM-bildalternativ
När du väljer en bild för SQL Server har du flera alternativ. Du kan välja att bara välja OS, som Linux eller Windows, eller så kan du välja att välja en bild med OS och SQL Server redan installerade. För närvarande föredrar jag att välja bilden med bara OS så att jag kan installera SQL Server och konfigurera den som jag vill. När du väljer galleribilden med SQL Server förinstallerad installeras alla komponenter som ingår i ISO för den versionen, och jag behöver inte alltid Integration Services eller Analysis Services installerade.
VM-storleksöverväganden
Att välja en Azure VM kan tyckas vara okomplicerad, med att välja en storlek baserat på antalet vCPU, minne och tillräckligt med lagringsutrymme för att hålla dina databaser, men jag ser att kunder har prestandaproblem relaterade till lagring. Den vanliga trenden är att välja en virtuell dator baserad uteslutande på vCPU, minne och lagringskapacitet utan att jämföra nuvarande IO- och genomströmningskrav. När du skapar en Azure VM i Azure Portal kan du filtrera alternativen baserat på följande:
- Storlek
- Generation
- Familj
- RAM/minne
- Stöd för premiumlagring
- Antal vCPU
- Efemer OS-disk
När du har valt dina filteralternativ, om några, kommer du att se en lista över tillgängliga servrar. I listan visar den VM-storlek, erbjudande, familj, vCPU, RAM, antal datadiskar som stöds, max IOPS, temporär lagring (D:), om premiumdisk stöds och uppskattad kostnad. Jag har filtrerat följande på premiumdiskar som stöds och storlek börjar med bokstaven E för minnesoptimerat.
Det som däremot inte visas är mängden tillåten genomströmning per virtuell dator. Genomströmningen mäter dataöverföringshastigheten till och från lagringsmediet i megabyte per sekund.
Genomströmningen kan beräknas med följande formel
MB/s =IOPS * KB per IO / 1 024
Med denna formel skulle KB per IO vara din blockstorlek. Om du formaterar dina data och loggenheter vid 64k, då skulle formeln för virtuella datorer E2s_v3, E4-2s_v3 och E8-2s_v3 med 3 200, 6 400 och 12 800 IOPS vara:
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
Genomströmningsberäkningarna baserade på IOPS för varje virtuell dator med en blockstorlek på 64k är inte så dåliga. Dessa siffror tar inte hänsyn till eventuella skrivstraff för RAID. Jag testade var och en av dessa virtuella datorer med CrystalDiskMark. Siffrorna jag fick för genomströmning var inte i närheten av vad beräkningarna uppskattade.
Benchmark Test
Jag förberedde tre virtuella maskiner av samma familj, oavsett storlek, och var och en med 2 vCPU. Specifikationerna för de virtuella maskinerna var:
- E2s_v3 – 2 vCPU – 16 GB RAM – 3 200 IOPS – Stöd för upp till 4 datadiskar
- E4-2s_v3 – 2 vCPU – 32 GB RAM – 6 400 IOPS – Stöd för upp till 8 datadiskar
- E8-2s_v3 – 2 vCPU – 64 GB RAM – 12 800 IOPS – Stöd för upp till 16 datadiskar
- P60-datadisk – Premium SSD – 16 000 IOPS
På varje virtuell dator installerade jag en P60 premiumdisk med 8 TB kapacitet. Den här disken annonserade 16 000 IOPS som med en blockstorlek på 64 000 kunde stödja 1 000 MBps genomströmning, men Azure-dokumentationen säger att disken ger 500 MBps genomströmning.
CrystalDiskMark är ett benchmarkverktyg för diskenheter med öppen källkod för Windows, och det är baserat på Microsofts Diskspd-verktyg. Verktyget mäter sekventiell och slumpmässig prestanda för läsning och skrivning.
Överst på verktyget finns några rullgardinsmenyer. Siffran 5 är antalet iterationer av testet som kommer att köras. Nästa är 1GiB, detta är storleken på testfilen. För ett riktigt produktionstest bör detta vara tillräckligt stort för att undvika att träffa cache. Version 7.0 stöder upp till en 64 GiB fil. Sist är den enhet som du vill utföra testet mot.
När du har gjort ditt val kan du klicka på Alla för att påbörja testserien. Testet kommer att gå igenom olika sekventiella och slumpmässiga läs-/skrivoperationer. Var försiktig om du planerar att jämföra riktiga produktionsservrar. Detta test belastar din disk och kan drastiskt påverka en produktionsbelastning. Efter timmar eller under ett underhållsfönster är att föredra.
Jag valde att köra 5 iterationer av testet med en 32 GiB-fil på P60-disken som var enhet E:.
E2s_v3 VM maxade under 50 MBps, vilket är mycket mindre än de 200 MB som vi beräknade.
E4-2s_v3 VM maxade under 100 MBps istället för 400 MBps.
E8-2s_v3 VM maxade under 200 MBps istället för de uppskattade 800 MBps.
Varför lägre genomströmning?
Baserat på mina tidigare beräkningar borde 3 200 IOPS vid 64 000 blockstorlek producera 200 MB genomströmning, men jag såg inte siffror i närheten av det förrän jag hade en 16 000 IOPS-disk på en virtuell dator som stöder upp till 12 800 IOPS. Resonemanget är att varje VM-storlek har en gräns för genomströmning. Om du tittar på dokumentationen för den minnesoptimerade familjen av virtuella datorer, kommer du att upptäcka att E2s max ocachade diskgenomströmning är 3 200 IOPS /48 MBps, E4s max ocachad diskgenomströmning är 6 400 IOPS / 96 MBps och E8s max ocachad disk kapaciteten är 12 800 IOPS / 192 MBps. Dessa siffror sammanfaller med resultaten jag fick med CrystalDiskMark.
Även om du kan allokera mycket stora diskar som har massor av IOPS och som stöder höga genomströmningstal, kan VM-storleken mycket väl begränsa din genomströmning.
Benchmarking av dina nuvarande genomströmningsbehov bör vara en stor prioritet innan du migrerar någon SQL Server-arbetsbelastning till Azure.
Slutsats
Jag förstår att IOPS är en måttenhet som disktillverkare och lagringsleverantörer tillhandahåller, och det är ok. Men när det kommer till att testa lagring tenderar vi att fokusera mer på genomströmningssiffror. Det är bara ett matematiskt problem, men om du inte är i branschen för att benchmarka lagring och göra beräkningarna från IOPS till genomströmning baserat på blockstorlek, kan det vara förvirrande.
Det som oroar mig är det faktum att begränsningen av genomströmning inte är tydlig när du väljer en virtuell datorstorlek. Måttenheten för lagrings-IO är IOPS. Vid 3 200 IOPS med en blockstorlek på 64 000 kunde jag vara runt 200 MBps men min virtuella dator var begränsad till 48 MBps. Många IT-proffs har upptäckt att de har problem med diskprestanda och skalat sin lagring till en större och snabbare disk (mer IOPS) och förväntar sig bättre prestanda, bara för att upptäcka att det inte löste deras problem. Problemet är att storleken på den virtuella datorn begränsade deras genomströmning. Att skala upp till en virtuell dator med högre storlek skulle lösa problemet, men det kommer med en kostnad. I mitt exempel var E4 dubbelt så mycket som E2:an, men den fördubblade minnet och genomströmningen samtidigt som den behöll samma vCPU. E8 var dubbelt så mycket som E4:an och fördubblade genomströmningen och minnet, samtidigt som den behöll samma vCPU. Att behålla samma vCPU-antal innebär att jag inte skulle ha en ökning av kostnaden för kärnlicenser för SQL Server.
I slutändan måste du jämföra dina nuvarande genomströmningskrav och se till att du anpassar storleken på Azure VM eller vilken virtuell dator som helst för dina behov. Fokusera inte bara på ett riktmärke för din lokala lagring, analysera vad din arbetsbelastning behöver och storlek därefter.