Das Migrieren einer lokalen SQL Server-Instanz zu einem virtuellen Azure-Computer (VM) ist eine gängige Methode zum Migrieren zu Azure. IT-Experten sind damit vertraut, die Größe von VMs in Bezug auf vCPU, Arbeitsspeicher und Speicherkapazität festzulegen. Microsoft bietet mehrere VM-Typen und -Größen für die Anforderungen eines Unternehmens an. Die Typen werden als Family bezeichnet im Azure-Portal bei der Dimensionierung einer VM.
VM-Typen und -Größen
Microsoft hat dazu beigetragen, die Dinge zu vereinfachen, indem es mehrere Arten von virtuellen Maschinen erstellt hat. Die Typen sind darauf ausgerichtet, die Maschinen nach Zweck zu definieren. Die verschiedenen Typen sind:
- Allgemeiner Zweck – Ausgewogenes CPU-Speicher-Verhältnis, kleine bis mittlere Datenbanken
- Computing-optimiert – Hohes CPU-zu-Speicher-Verhältnis, Webserver und Anwendungsserver mit mittlerem Datenverkehr
- Arbeitsspeicheroptimiert – Hohes Arbeitsspeicher-zu-CPU-Verhältnis, relationale Datenbankserver, mittlere bis große Caches und In-Memory-Analysen
- Speicheroptimiert – Hoher Festplattendurchsatz und E/A
- GPU – Schweres Grafik-Rendering und Videobearbeitung
- Hochleistungs-Computing – Schnellste und leistungsfähigste virtuelle CPU-Maschinen
Innerhalb jedes Typs/jeder Familie stehen zahlreiche Größen zur Auswahl. Die Größen bieten Ihnen Optionen für die Anzahl von vCPUs, RAM und Datenträgern. Die Anzahl der Datenträger bestimmt die maximalen IOPS (IOPS steht für Input/Output-Operationen pro Sekunde) und die Gesamtgröße bestimmt die Menge an verfügbarem temporärem Speicher. Bestimmte Größen unterstützen auch Premium-Speicher, was eine Voraussetzung für einen Produktions-SQL-Server sein sollte.
VM-Image-Optionen
Bei der Auswahl eines Images für SQL Server haben Sie mehrere Möglichkeiten. Sie können nur das Betriebssystem auswählen, z. B. Linux oder Windows, oder Sie können ein Image mit bereits installiertem Betriebssystem und SQL Server auswählen. Derzeit ziehe ich es vor, das Image nur mit dem Betriebssystem auszuwählen, damit ich SQL Server installieren und nach Belieben konfigurieren kann. Wenn Sie das Galerie-Image mit vorinstalliertem SQL Server auswählen, werden alle Komponenten installiert, die in der ISO für diese Version enthalten sind, und ich muss nicht immer Integration Services oder Analysis Services installieren.
Überlegungen zur VM-Größe
Die Auswahl einer Azure-VM scheint einfach zu sein, da die Größe auf der Anzahl der vCPUs, des Arbeitsspeichers und ausreichend Speicher für Ihre Datenbanken basiert, aber ich sehe, dass Kunden Leistungsprobleme im Zusammenhang mit der Speicherung haben. Der allgemeine Trend geht dahin, eine VM ausschließlich basierend auf vCPU, Arbeitsspeicher und Speicherkapazität auszuwählen, ohne die aktuellen IO- und Durchsatzanforderungen zu bewerten. Wenn Sie eine Azure-VM im Azure-Portal erstellen, können Sie die Optionen basierend auf Folgendem filtern:
- Größe
- Generation
- Familie
- RAM/Speicher
- Premium-Speicherunterstützung
- Anzahl der vCPU
- Flüchtiger Betriebssystemdatenträger
Sobald Sie Ihre Filteroptionen ausgewählt haben, sehen Sie eine Liste der verfügbaren Server. In der Liste werden die VM-Größe, das Angebot, die Familie, die vCPU, der RAM, die Anzahl der unterstützten Datenfestplatten, die maximalen IOPS, der temporäre Speicher (D:), wenn Premium-Datenträger unterstützt werden, und die geschätzten Kosten angezeigt. Ich habe Folgendes nach unterstützten Premium-Datenträgern und Größen, die mit dem Buchstaben E für speicheroptimiert beginnen, gefiltert.
Was jedoch nicht angezeigt wird, ist der zulässige Durchsatz pro VM. Der Durchsatz misst die Datenübertragungsrate zu und von den Speichermedien in Megabyte pro Sekunde.
Der Durchsatz kann anhand der folgenden Formel berechnet werden
MB/s =IOPS * KB pro IO / 1.024
Mit dieser Formel wäre KB pro IO Ihre Blockgröße. Wenn Sie Ihre Daten- und Protokolllaufwerke mit 64 KB formatieren, lautet die Formel für die VMs E2s_v3, E4-2s_v3 und E8-2s_v3 mit 3.200, 6.400 und 12.800 IOPS:
MB/s =3.200 * 64/1.024 oder 200 MB/s
MB/s =6.400 * 64/1.024 oder 400 MB/s
MB/s =12.800 * 64/1.024 oder 800 MB/s
Die Durchsatzberechnungen basierend auf den IOPS jeder VM mit einer Blockgröße von 64k sind nicht allzu schlecht. Diese Zahlen berücksichtigen keine Schreibstrafen für RAID. Ich habe jede dieser VMs mit CrystalDiskMark einem Test unterzogen. Die Zahlen, die ich für den Durchsatz erhielt, lagen bei weitem nicht in der Nähe dessen, was die Berechnungen geschätzt hatten.
Benchmark-Test
Ich habe drei virtuelle Maschinen derselben Familie bereitgestellt, jedoch mit unterschiedlichen Größen und jeweils mit 2 vCPUs. Die Spezifikationen der virtuellen Maschinen waren:
- E2s_v3 – 2 vCPU – 16 GB RAM – 3.200 IOPS – Unterstützt bis zu 4 Datenträger
- E4-2s_v3 – 2 vCPU – 32 GB RAM – 6.400 IOPS – Unterstützt bis zu 8 Datenträger
- E8-2s_v3 – 2 vCPU – 64 GB RAM – 12.800 IOPS – Unterstützt bis zu 16 Datenträger
- P60-Datenfestplatte – Premium-SSD – 16.000 IOPS
Auf jeder VM habe ich einen P60-Premium-Datenträger mit 8 TB Kapazität bereitgestellt. Dieser Datenträger hat 16.000 IOPS beworben, was bei einer Blockgröße von 64 KB einen Durchsatz von 1.000 MBit/s unterstützen könnte. Die Azure-Dokumentation gibt jedoch an, dass der Datenträger einen Durchsatz von 500 MBit/s bietet.
CrystalDiskMark ist ein Open-Source-Festplatten-Benchmark-Tool für Windows und basiert auf dem Diskspd-Tool von Microsoft. Das Tool misst die sequenzielle und zufällige Leistung von Lese- und Schreibvorgängen.
Am oberen Rand des Tools befinden sich einige Dropdown-Menüs. Die Zahl 5 ist die Anzahl der Iterationen des Tests, die ausgeführt werden. Als nächstes kommt 1 GiB, das ist die Größe der Testdatei. Für einen echten Produktionstest sollte dies groß genug sein, um zu vermeiden, dass der Cache getroffen wird. Version 7.0 unterstützt bis zu einer 64-GiB-Datei. Zuletzt ist das Laufwerk, für das Sie den Test durchführen möchten.
Nachdem Sie Ihre Auswahl getroffen haben, können Sie auf Alle klicken, um mit der Testreihe zu beginnen. Der Test durchläuft verschiedene sequentielle und zufällige Lese-/Schreiboperationen. Seien Sie vorsichtig, wenn Sie ein Benchmarking für echte Produktionsserver planen. Dieser Test belastet Ihre Festplatte und könnte sich drastisch auf eine Produktionsworkload auswirken. Nach Stunden oder während eines Wartungsfensters wäre bevorzugt.
Ich habe mich entschieden, 5 Iterationen des Tests mit einer 32-GiB-Datei auf der P60-Festplatte auszuführen, die Laufwerk E:war.
Die E2s_v3-VM erreichte das Maximum unter 50 MB/s, was weit unter den von uns berechneten 200 MB liegt.
Die E4-2s_v3-VM erreichte weniger als 100 MBit/s statt 400 MBit/s.
Die E8-2s_v3-VM erreichte weniger als 200 MBit/s statt der geschätzten 800 MBit/s.
Warum geringerer Durchsatz?
Basierend auf meinen früheren Berechnungen sollten 3.200 IOPS bei einer Blockgröße von 64.000 einen Durchsatz von 200 MB erzeugen, aber ich habe keine Zahlen in der Nähe davon gesehen, bis ich eine 16.000 IOPS-Festplatte auf einer VM hatte, die bis zu 12.800 IOPS unterstützt. Der Grund dafür ist, dass jede VM-Größe ein Limit für den Durchsatz hat. Wenn Sie sich die Dokumentation für die speicheroptimierte Familie von VMs ansehen, werden Sie feststellen, dass der maximale Durchsatz von nicht zwischengespeicherten Datenträgern des E2 3.200 IOPS / 48 MB/s, der maximale Durchsatz von nicht zwischengespeicherten Datenträgern des E4 6.400 IOPS / 96 MB/s und der maximale nicht zwischengespeicherte Datenträger des E8 beträgt Durchsatz beträgt 12.800 IOPS / 192 MBps. Diese Zahlen stimmen mit den Ergebnissen überein, die ich mit CrystalDiskMark erhalten habe.
Auch wenn Sie sehr große Laufwerke zuweisen können, die viele IOPS haben und hohe Durchsatzzahlen unterstützen, könnte die VM-Größe Ihren Durchsatz durchaus einschränken.
Das Benchmarking Ihres aktuellen Durchsatzbedarfs sollte eine große Priorität sein, bevor Sie eine SQL Server-Arbeitslast zu Azure migrieren.
Schlussfolgerung
Ich verstehe, dass IOPS eine Maßeinheit ist, die Festplattenhersteller und Speicheranbieter bereitstellen, und das ist in Ordnung. Beim Testen von Speicher konzentrieren wir uns jedoch eher auf die Durchsatzzahlen. Es ist nur ein mathematisches Problem, aber wenn Sie sich nicht mit dem Benchmarking von Speicher beschäftigen und die Berechnungen von IOPS bis zum Durchsatz basierend auf der Blockgröße durchführen, kann es verwirrend sein.
Was mich beunruhigt, ist die Tatsache, dass die Beschränkung des Durchsatzes nicht klar ist, wenn Sie eine VM-Größe auswählen. Die Maßeinheit für Speicher-IO ist IOPS. Bei 3.200 IOPS mit einer Blockgröße von 64.000 könnte ich etwa 200 MB/s erreichen, aber meine VM war auf 48 MB/s begrenzt. Viele IT-Experten haben festgestellt, dass sie Probleme mit der Festplattenleistung haben, und haben ihren Speicher auf größere und schnellere Festplatten (mehr IOPS) skaliert, in der Erwartung einer besseren Leistung, nur um festzustellen, dass ihr Problem dadurch nicht gelöst wurde. Das Problem ist, dass die Größe der VM ihren Durchsatz begrenzt hat. Das Hochskalieren auf eine größere VM würde das Problem lösen, aber das ist mit Kosten verbunden. In meinem Beispiel war der E4 doppelt so teuer wie der E2, verdoppelte jedoch den Arbeitsspeicher und den Durchsatz, während die gleiche vCPU beibehalten wurde. Der E8 war doppelt so teuer wie der E4 und verdoppelte den Durchsatz und den Arbeitsspeicher, während die gleiche vCPU beibehalten wurde. Die Beibehaltung der gleichen vCPU-Anzahl bedeutet, dass die Lizenzkosten für den Kern von SQL Server nicht steigen würden.
Letztendlich müssen Sie Ihre aktuellen Durchsatzanforderungen vergleichen und sicherstellen, dass Sie die Azure-VM oder jede andere VM entsprechend Ihren Anforderungen dimensionieren. Konzentrieren Sie sich nicht nur auf einen Benchmark Ihres lokalen Speichers, sondern analysieren Sie, was Ihre Workload benötigt und wie groß sie entsprechend ist.
