Het migreren van een on-premises SQL Server-exemplaar naar een Azure Virtual Machine (VM) is een veelgebruikte methode om naar Azure te migreren. IT-professionals zijn bekend met het inschatten van de omvang van VM's met betrekking tot vCPU, geheugen en opslagcapaciteit. Microsoft biedt meerdere VM-typen en -groottes voor de behoeften van een organisatie. Je ziet de typen waarnaar wordt verwezen als Family in de Azure Portal bij het dimensioneren van een VM.
VM-typen en -formaten
Microsoft heeft geholpen om dingen te vereenvoudigen door meerdere soorten virtuele machines te maken. De typen zijn gericht op het doelbewust definiëren van de machines. De verschillende soorten zijn:
- Algemeen doel - Gebalanceerde CPU-geheugenverhouding, kleine tot middelgrote databases
- Compute-geoptimaliseerd - Hoge CPU-naar-geheugenverhouding, webservers en applicatieservers met gemiddeld verkeer
- Geoptimaliseerd geheugen - Hoge geheugen-tot-CPU-verhouding, relationele databaseservers, middelgrote tot grote caches en in-memory analyses
- Opslag geoptimaliseerd - Hoge schijfdoorvoer en IO
- GPU – zware grafische weergave en videobewerking
- Krachtige rekenkracht - Snelste en krachtigste virtuele CPU-machines
Binnen elk type/familie zijn er talloze maten om uit te kiezen. De formaten bieden u opties voor het aantal vCPU's, RAM en gegevensschijven. Het aantal gegevensschijven bepaalt de maximale IOPS (IOPS staat voor input/output-bewerkingen per seconde.) en de totale grootte bepaalt de hoeveelheid beschikbare tijdelijke opslagruimte. Bepaalde formaten ondersteunen ook premium-opslag, wat een vereiste zou moeten zijn voor een productie-SQL Server.
VM-afbeeldingsopties
Bij het selecteren van een afbeelding voor SQL Server heb je verschillende opties. U kunt ervoor kiezen om alleen het besturingssysteem te selecteren, zoals Linux of Windows, of u kunt ervoor kiezen om een afbeelding te selecteren waarop het besturingssysteem en SQL Server al zijn geïnstalleerd. Momenteel kies ik liever de afbeelding met alleen het besturingssysteem, zodat ik SQL Server kan installeren en configureren zoals ik wil. Wanneer u de galerijafbeelding kiest waarop SQL Server vooraf is geïnstalleerd, worden alle componenten geïnstalleerd die zijn opgenomen in de ISO voor die versie en heb ik niet altijd Integration Services of Analysis Services nodig.
Overwegingen voor VM-grootte
Het selecteren van een Azure-VM lijkt misschien eenvoudig, met het kiezen van een grootte op basis van het aantal vCPU, geheugen en voldoende opslag voor uw databases, maar ik zie dat klanten prestatieproblemen hebben met betrekking tot opslag. De algemene trend is om een VM te kiezen die uitsluitend is gebaseerd op vCPU, geheugen en opslagcapaciteit zonder de huidige IO- en doorvoervereisten te benchmarken. Wanneer u een Azure-VM maakt in de Azure Portal, kunt u de opties filteren op basis van het volgende:
- Maat
- Generatie
- Familie
- RAM/geheugen
- Premium opslagondersteuning
- Aantal vCPU's
- Kortstondige OS-schijf
Nadat u uw eventuele filteropties hebt geselecteerd, ziet u een lijst met beschikbare servers. In de lijst worden de VM-grootte, het aanbod, de familie, de vCPU, het RAM, het aantal ondersteunde gegevensschijven, de maximale IOPS, de tijdelijke opslag (D:), als premium schijf wordt ondersteund, en de geschatte kosten weergegeven. Ik heb het volgende gefilterd op premium ondersteunde schijf en grootte beginnend met de letter E voor geheugen geoptimaliseerd.
Wat echter niet wordt weergegeven, is de toegestane hoeveelheid doorvoer per VM. Doorvoer meet de gegevensoverdrachtsnelheid van en naar de opslagmedia in megabytes per seconde.
Doorvoer kan worden berekend met behulp van de volgende formule
MB/s =IOPS * KB per IO / 1.024
Met deze formule zou KB per IO uw blokgrootte zijn. Als u uw gegevens formatteert en schijven logt met 64k, is de formule voor de E2s_v3, E4-2s_v3 en E8-2s_v3 VM's met 3.200, 6.400 en 12.800 IOPS:
MB/s =3.200 * 64/1.024 of 200 MB/s
MB/s =6.400 * 64/1.024 of 400 MB/s
MB/s =12.800 * 64/1.024 of 800 MB/s
De doorvoerberekeningen op basis van de IOPS van elke VM met een blokgrootte van 64k vallen mee. Deze cijfers houden geen rekening met eventuele schrijfstraffen voor RAID. Ik heb elk van deze VM's getest met CrystalDiskMark. De cijfers die ik kreeg voor de doorvoer kwamen niet in de buurt van wat de berekeningen schatten.
Benchmarktest
Ik heb drie virtuele machines van dezelfde familie ingericht, maar van verschillende grootte, en elk met 2 vCPU's. De specificaties van de virtuele machines waren:
- E2s_v3 – 2 vCPU’s – 16GB RAM – 3.200 IOPS – Ondersteuning tot 4 dataschijven
- E4-2s_v3 – 2 vCPU’s – 32GB RAM – 6.400 IOPS – Ondersteuning tot 8 dataschijven
- E8-2s_v3 – 2 vCPU’s – 64GB RAM – 12.800 IOPS – Ondersteuning tot 16 dataschijven
- P60-gegevensschijf – Premium SSD – 16.000 IOPS
Op elke VM heb ik een P60 premium-schijf ingericht met een capaciteit van 8 TB. Deze schijf adverteerde met 16.000 IOPS die met een blokgrootte van 64k 1000 MBps doorvoer zou kunnen ondersteunen, maar Azure-documentatie stelt dat de schijf 500 MBps doorvoer biedt.
CrystalDiskMark is een open source benchmark-tool voor schijfstations voor Windows en is gebaseerd op de Diskspd-tool van Microsoft. De tool meet sequentiële en willekeurige prestaties van lezen en schrijven.
Aan de bovenkant van de tool bevinden zich enkele vervolgkeuzelijsten. Het getal 5 is het aantal iteraties van de test die zal worden uitgevoerd. De volgende is 1GiB, dit is de grootte van het testbestand. Voor een echte productietest zou dit groot genoeg moeten zijn om te voorkomen dat de cache wordt geraakt. Versie 7.0 ondersteunt maximaal 64 GiB-bestanden. De laatste is de schijf waarop u de test wilt uitvoeren.
Nadat u uw selectie heeft gemaakt, kunt u op Alles klikken om de reeks tests te starten. De test doorloopt verschillende opeenvolgende en willekeurige lees-/schrijfbewerkingen. Wees voorzichtig als u van plan bent om echte productieservers te benchmarken. Deze test belast uw schijf en kan drastische gevolgen hebben voor een productiewerkbelasting. Buiten kantooruren of tijdens een onderhoudsperiode heeft de voorkeur.
Ik koos ervoor om 5 iteraties van de test uit te voeren met een 32 GiB-bestand op de P60-schijf die drive E:was.
De E2s_v3 VM bereikte een maximum van minder dan 50 MBps, wat veel minder is dan de 200 MB die we hebben berekend.
De E4-2s_v3 VM bereikte een maximum van minder dan 100 MBps in plaats van 400 MBps.
De E8-2s_v3 VM bereikte een maximum van minder dan 200 MBps in plaats van de geschatte 800 MBps.
Waarom een lagere doorvoer?
Op basis van mijn eerdere berekeningen zouden 3.200 IOPS met een blokgrootte van 64k 200 MB doorvoer moeten produceren, maar ik zag geen cijfers die in de buurt kwamen totdat ik een 16.000 IOPS-schijf had op een VM die tot 12.800 IOPS ondersteunt. De redenering is dat elke VM-grootte een limiet voor doorvoer heeft. Als u de documentatie voor de geheugengeoptimaliseerde familie van VM's bekijkt, zult u zien dat de maximale niet-gecachete schijfdoorvoer van de E2s 3.200 IOPS /48 MBps is, de maximale niet-gecachete schijfdoorvoer van E4s 6.400 IOPS / 96 MBps en de maximale niet-gecachete schijf van de E8s doorvoer is 12.800 IOPS / 192 MBps. Deze cijfers komen overeen met de resultaten die ik heb verkregen met CrystalDiskMark.
Ook al kunt u zeer grote schijven toewijzen die veel IOPS hebben en die hoge doorvoercijfers ondersteunen, de VM-grootte zou uw doorvoer heel goed kunnen beperken.
Benchmarking van uw huidige doorvoerbehoeften zou een grote prioriteit moeten zijn voordat u een SQL Server-workload naar Azure migreert.
Conclusie
Ik begrijp dat IOPS een maateenheid is die schijffabrikanten en opslagverkopers bieden, en dat is oké. Als het echter gaat om het testen van opslag, hebben we de neiging om ons meer te concentreren op doorvoercijfers. Het is gewoon een wiskundig probleem, maar tenzij u zich bezighoudt met het benchmarken van opslag en het doen van de berekeningen van IOPS tot doorvoer op basis van blokgrootte, kan dit verwarrend zijn.
Wat mij verontrust is het feit dat de beperking van de doorvoer niet duidelijk is wanneer u een VM-grootte selecteert. De maateenheid voor opslag-IO is IOPS. Bij 3.200 IOPS met een blokgrootte van 64k zou ik rond de 200 MBps kunnen zijn, maar mijn VM was beperkt tot 48 MBps. Veel IT-professionals hebben ontdekt dat ze schijfprestatieproblemen hebben en hebben hun opslag geschaald naar een grotere en snellere schijf (meer IOPS) in de verwachting van betere prestaties, maar ontdekten dat het hun probleem niet oploste. Het probleem is dat de grootte van de VM hun doorvoer beperkte. Opschalen naar een grotere VM zou het probleem oplossen, maar daar zijn kosten aan verbonden. In mijn voorbeeld was de E4 twee keer zo duur als de E2, maar verdubbelde het geheugen en de doorvoer, terwijl dezelfde vCPU behouden bleef. De E8 was het dubbele van de kosten van de E4 en verdubbelde de doorvoer en het geheugen, met behoud van dezelfde vCPU. Als ik hetzelfde aantal vCPU's aanhoud, betekent dit dat ik geen verhoging van de kosten van de SQL Server-licentie voor de core heb.
Uiteindelijk moet u uw huidige doorvoervereisten benchmarken en ervoor zorgen dat de grootte van de Azure-VM, of een willekeurige virtuele machine, geschikt is voor uw behoeften. Concentreer u niet alleen op een benchmark van uw lokale opslag, analyseer wat uw werklast nodig heeft en de grootte dienovereenkomstig.