Überlegungen zur Leistung von Azure VMware Solution-Datenspeichern für Azure NetApp Files

Artikel
03/28/2024

Dieser Artikel enthält Überlegungen zur Leistung beim Entwurf und der Dimensionierung von Azure VMware Solution-Datenspeichern, wenn sie mit Azure NetApp Files verwendet werden. Der Artikel richtet sich an Virtualisierungsadministratoren, Cloudarchitekten und Speicherarchitekten.

Die in diesem Artikel beschriebenen Überlegungen helfen Ihnen, die höchste Leistung Ihrer Anwendungen bei optimierter Kosteneffizienz zu erzielen.

Azure NetApp Files bietet einen sofort skalierbaren, leistungsstarken und äußerst zuverlässigen Speicherdienst für Azure VMware Solution. Die Tests enthielten verschiedene Konfigurationen zwischen Azure VMware Solution und Azure NetApp Files. Die Tests konnten über 10.500 MiB/s und über 585.000 Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) mit nur vier Azure VMware Solution-/ESXi-Hosts und einem einzigen Azure NetApp Files-Kapazitätspool erzielen.

Erzielen einer höheren Speicherleistung für Azure VMware Solution mit Azure NetApp Files

Die Bereitstellung mehrerer, potenziell größerer Datenspeicher auf einer Dienstebene kann weniger kosten und gleichzeitig eine höhere Leistung bieten. Der Grund hierfür ist die Verteilung der Last über mehrere TCP-Streams von Azure VMware Solution-Hosts auf mehrere Datenspeicher. Sie können den Rechner zum Abschätzen der Gesamtkosten für Azure NetApp Files-Datenspeicher mit Azure VMware Solution verwenden, um potenzielle Kosteneinsparungen zu berechnen. Laden Sie dazu einen RVTools-Bericht hoch, oder geben Sie manuell die durchschnittliche VM-Größe ein.

Wenn Sie bestimmen, wie Datenspeicher konfiguriert werden, besteht die einfachste Lösung aus Verwaltungsperspektive darin, einen einzelnen Azure NetApp Files-Datenspeicher zu erstellen, ihn bereitzustellen und ihm alle Ihre virtuellen Computer hinzuzufügen. Diese Strategie eignet sich gut für viele Situationen, bis mehr Durchsatz oder IOPS erforderlich ist. Um die verschiedenen Grenzen zu identifizieren, verwendeten die Tests einen synthetischen Workloadgenerator, das Programm fio, um eine Reihe von Workloads für jedes dieser Szenarien auszuwerten. Diese Analyse kann Ihnen helfen zu bestimmen, wie Azure NetApp Files-Volumes als Datenspeicher bereitgestellt werden können, um die Leistung zu maximieren und Kosten zu optimieren.

Voraussetzungen

Informationen zu Azure NetApp Files-Leistungsdaten finden Sie unter:

Azure NetApp Files: Optimale Nutzung Ihres Cloudspeichers

Auf einem Azure VMware Solution-Host wird pro NFS-Datenspeicher eine einzelne Netzwerkverbindung eingerichtet, vergleichbar mit der Verwendung von nconnect=1 für die Linux-Tests, auf die in Abschnitt 6 (Optimierungsoptionen) verwiesen wird. Diese Tatsache ist entscheidend, um zu verstehen, wie Azure VMware Solution die Leistung so gut auf mehrere Datenspeicher skalieren kann.
Leistungsbenchmarks des Azure NetApp Files-Datenspeichers für Azure VMware Solution

Testmethodik

In diesem Abschnitt wird die Methodik beschrieben, die für die Tests verwendet wurde.

Testszenarien und Iterationen

Dieser Test folgt der „vier Ecken“-Methodik, die sowohl Lesevorgänge als auch Schreibvorgänge für jede sequenzielle und zufällige Eingabe/Ausgabe (E/A) umfasst. Zu den Variablen der Tests gehören 1:n Azure VMware Solution-Hosts, Azure NetApp Files-Datenspeicher, VMs (pro Host) und VM-Datenträger (VMDKs) pro VM. Die folgenden Skalierungsdatenpunkte wurden ausgewählt, um den maximalen Durchsatz und IOPS für die angegebenen Szenarien zu ermitteln:

Skalieren von VMDKs, jeweils in ihrem eigenen Datenspeicher für einen einzelnen virtuellen Computer.
Skalierung der Anzahl von VMs pro Host in einem einzelnen Azure NetApp Files-Datenspeicher.
Skalierung der Anzahl von Azure VMware Solution-Hosts mit jeweils einer VM, die einen einzelnen Azure NetApp Files-Datenspeicher gemeinsam nutzen.
Skalierung der Anzahl von Azure NetApp Files-Datenspeichern, jeweils mit einem VMDK und gleichmäßig auf Azure VMware Solution-Hosts verteilt.

Das Testen von Vorgängen mit kleinen und großen Blöcken sowie das Durchlaufen sequenzieller und zufälliger Workloads stellen sicher, dass alle Komponenten in den Compute-, Speicher- und Netzwerkstapeln bis zum „Edge“ getestet werden. Um die vier Ecken mit Blockgröße und Randomisierung abzudecken, werden die folgenden häufigen Kombinationen verwendet:

Sequenzielle Tests (64 KB)
- Große Dateistreamingworkloads lesen und schreiben häufig in großen Blöcken, dies ist die standardmäßige MSSQL-Blockgröße.
- Tests mit großen Blöcken erzeugen in der Regel den höchsten Durchsatz (in MiB/s).
Zufällige Tests (8 KB)
- Diese Einstellung ist die normalerweise verwendete Blockgröße für Datenbanksoftware, u. a. Software von Microsoft, Oracle und PostgreSQL.
- Tests mit kleinen Blöcken erzeugen in der Regel die höchsten IOPS-Werte.

Hinweis

In diesem Artikel werden nur die Tests von Azure NetApp Files behandelt. Er deckt nicht den vSAN-Speicher ab, der in Azure VMware Solution enthalten ist.

Umgebungsdetails

Die Ergebnisse in diesem Artikel wurden mit der folgenden Umgebungskonfiguration erzielt:

Azure VMware Solution-Hosts:
- Größe: AV36
- Hostanzahl: 4
- VMware ESXi-Version 7u3
Konnektivität zwischen der privaten Cloud und Azure VMware Solution: UltraPerformance-Gateway mit FastPath
Gast-VMs:
- Betriebssystem: Ubuntu 20.04
- CPUs/Arbeitsspeicher: 16 vCPU / 64 GB Arbeitsspeicher
- Virtueller LSI SAS SCSI-Controller mit 16 GB Betriebssystemdatenträger und Azure VMware Solution-vSAN-Datenspeicher
- Paravirtual SCSI-Controller für Test-VMDKs
- LVM-/Datenträgerkonfigurationen:
  - Ein physisches Volume pro Datenträger
  - Eine Volumegruppe pro physischem Volume
  - Eine logische Partition pro Volumegruppe
  - Ein XFS-Dateisystem pro logischer Partition
Protokoll von Azure VMware Solution zu Azure NetApp Files: NFS Version 3
Workloadgenerator: fio Version 3.16
Fio-Skripts: fio-parser

Testergebnisse

In diesem Abschnitt werden die Ergebnisse der ausgeführten Tests beschrieben.

Skalierung einzelner VMs

Wenn Sie den als Datenspeicher dargestellten Speicher auf einem virtuellen Azure VMware Solution-Computer konfigurieren, sollten Sie die Auswirkungen des Dateisystemlayouts berücksichtigen. Das Konfigurieren mehrerer VMDKs, die über mehrere Datenspeicher verteilt sind, bietet die höchste verfügbare Bandbreite. Das Konfigurieren von 1:n VMDKs in einem einzelnen Datenspeicher sorgt für die größtmögliche Einfachheit bei Sicherungen und DR-Vorgängen, hat aber den Nachteil einer niedrigeren Leistungsobergrenze. Die in diesem Artikel enthaltenen empirischen Daten helfen Ihnen bei den Entscheidungen.

Um die Leistung zu maximieren, ist es üblich, einen einzelnen virtuellen Computer auf mehrere VMDKs zu skalieren und diese VMDKs in mehreren Datenspeichern zu platzieren. Ein einzelner virtueller Computer mit nur einem oder zwei VMDKs kann von einem NFS-Datenspeicher gedrosselt werden, da er über eine einzelne TCP-Verbindung zu einem bestimmten Azure VMware Solution-Host bereitgestellt wird.

Beispielsweise stellen Techniker häufig einen VMDK für ein Datenbankprotokoll bereit und stellen dann 1:n VMDKs für Datenbankdateien bereit. Bei mehreren VMDKs gibt es zwei Optionen. Die erste Option besteht darin, jeden VDMK als einzelnes Dateisystem zu verwenden. Die zweite Option besteht darin, ein Speicherverwaltungsprogramm wie LVM, MSSQL Filegroups oder Oracle ASM zu verwenden, um E/A durch Striping über VMDKs auszugleichen. Wenn VMDKs als einzelne Dateisysteme verwendet werden, muss die Verteilung von Workloads über mehrere Datenspeicher hinweg manuell erfolgen und kann umständlich sein. Die Verwendung von Speicherverwaltungs-Dienstprogrammen zum Verteilen der Dateien auf VMDKs ermöglicht eine Workloadskalierbarkeit.

Stellen Sie bei einem Striping der Volumes über mehrere Datenträger sicher, dass die Sicherungs- oder Notfallwiederherstellungssoftware das gleichzeitige Sichern mehrerer virtueller Datenträger unterstützt. Da für einzelne Schreibvorgänge ein Striping über mehrere Datenträger erfolgt, muss das Dateisystem sicherstellen, dass Datenträger während Momentaufnahme- oder Sicherungsvorgängen „fixiert“ werden. Die meisten modernen Dateisysteme umfassen einen Fixierungs- oder Momentaufnahmevorgang wie xfs (xfs_freeze) und NTFS (Volumeschattenkopien), die von Sicherungssoftware genutzt werden können.

Um zu verstehen, wie gut ein einzelner virtueller Azure VMware Solution-Computer skaliert wird, wenn mehr virtuelle Datenträger hinzugefügt werden, werden Tests mit einem, zwei, vier und acht Datenspeichern (jeweils mit einem einzelnen VMDK) durchgeführt. Das folgende Diagramm zeigt einen einzelnen Datenträger mit einem Durchschnitt von ungefähr 73.040 IOPS (Skalierung von 100 % Schreibzugriff / 0 % Lesezugriff auf 0 % Schreibzugriff / 100 % Lesezugriff). Als dieser Test auf zwei Datenträger erhöht wurde, stieg die Leistung um 75,8 % auf 128.420 IOPS. Beim Erweitern auf vier Datenträger zeigten sich schlechtere Ergebnisse im Hinblick auf die Leistung eines einzelnen virtuellen Computers in der getesteten Größe. Die beobachteten Spitzen-IOPS waren 147.000 IOPS mit 100 % zufälligen Lesevorgängen.

Single-Host-Skalierung – einzelner Datenspeicher

Die Skalierung ist schlecht, wenn die Anzahl der virtuellen Computer für E/A in einem einzelnen Datenspeicher von einem einzelnen Host erhöht wird. Diese Tatsache ist auf den einzelnen Netzwerkfluss zurückzuführen. Wenn die maximale Leistung für eine bestimmte Workload erreicht wird, ist dies häufig das Ergebnis einer einzelnen Warteschlange, die auf dem Weg zum einzelnen NFS-Datenspeicher des Hosts über eine einzelne TCP-Verbindung verwendet wird. Bei Verwendung einer Blockgröße von 8 KB erhöhte sich der IOPS-Gesamtwert um 3 % bis 16 %, wenn von einem virtuellen Computer mit einem einzelnen VMDK auf vier virtuelle Computer mit insgesamt 16 VMDKs (vier pro VM, alle in einem einzigen Datenspeicher) skaliert wurde.

Das Erhöhen der Blockgröße (auf 64 KB) für Workloads mit großen Blöcken hatte vergleichbare Ergebnisse und erreichte einen Höchstwert von 2148 MiB/s (einzelne VM, einzelner VMDK) und 2138 MiB/s (4 VMs, 16 VMDKs).

Single-Host-Skalierung – mehrere Datenspeicher

Aus dem Kontext eines einzelnen Azure VMware Solution-Hosts ermöglichte ein einzelner Datenspeicher den VMs etwa 76.000 IOPS, aber das Verteilen der Workloads über zwei Datenspeicher hinweg steigerte den Gesamtdurchsatz im Durchschnitt um 76 %. Der Wechsel von zwei Datenspeichern zu vier führte zu einer Steigerung von 163 % (gegenüber einem Datenspeicher, eine Steigerung von 49 % von zwei auf vier), wie im folgenden Diagramm dargestellt. Auch wenn es immer noch Leistungssteigerungen gab, zeigten sich bei mehr als acht Datenspeichern abnehmende Ergebnisse.

Multi-Host-Skalierung – einzelner Datenspeicher

Ein einzelner Datenspeicher von einem einzelnen Host erzeugte über 2000 MiB/s sequenziellem 64-KB-Durchsatz. Die Verteilung der gleichen Workload auf alle vier Hosts führte zu einem Spitzenzuwachs von 135 % mit über 5000 MiB/s. Dieses Ergebnis stellt wahrscheinlich die Obergrenze für die Durchsatzleistung eines einzelnen Azure NetApp Files-Volumes dar.

Das Verringern der Blockgröße von 64 KB auf 8 KB und die erneute Ausführung derselben Iterationen führte zu vier virtuellen Computern, die 195.000 IOPS erzeugen, wie im folgenden Diagramm dargestellt. Die Leistung wird sowohl bei einer Steigerung der Anzahl der Hosts als auch bei der Anzahl der Datenspeicher skaliert, da die Anzahl der Netzwerkdatenflüsse zunimmt. Die Leistung erhöht sich, indem die Anzahl der Hosts multipliziert mit der Anzahl der Datenspeicher skaliert wird, da die Anzahl der Netzwerkdatenflüsse das Produkt der Hosts multipliziert mit den Datenspeichern ist.

Multi-Host-Skalierung – mehrere Datenspeicher

Ein einzelner Datenspeicher mit vier virtuellen Computern, verteilt über vier Hosts, produzierte über 5000 MiB/s sequenzieller 64-KB-E/A. Für anspruchsvollere Workloads wird jeder virtuelle Computer in einen dedizierten Datenspeicher verschoben, was insgesamt mehr als 10.500 MiB/s erzeugt, wie im folgenden Diagramm dargestellt.

Bei zufälligen Workloads mit kleinen Blöcken erzeugte ein einzelner Datenspeicher 195.000 zufällige 8-KB-IOPS. Die Skalierung auf vier Datenspeicher erzeugte über 530.000 zufällige 8K-IOPS.

Auswirkungen und Empfehlungen

In diesem Abschnitt wird erläutert, warum die Verteilung Ihrer virtuellen Computer über mehrere Datenspeicher hinweg erhebliche Leistungsvorteile bietet.

Wie in den Testergebnissen gezeigt, gibt es in Azure NetApp Files eine Vielzahl von Leistungsfunktionen:

Tests zeigen, dass ein Datenspeicher mit einer Konfiguration mit vier Hosts durchschnittlich ~148.980 8 KB IOPS oder ~4147 MiB/s mit 64-KB-IOPS erreichen kann (Durchschnitt aller write%/read%-Tests).
Ein virtueller Computer in einem Datenspeicher:
- Wenn Sie über einzelne VMs verfügen, die möglicherweise mehr als ~75K 8-KB-IOPS oder über ca. 1700 MiB/sbenötigen, verteilen Sie die Dateisysteme über mehrere VMDKs, um die VMs-Speicherleistung zu skalieren.
Eine VM in mehreren Datenspeichern: Eine einzelne VM über 8 Datenspeicher erreichte bis zu ~147.000 8-KB-IOPS oder ~2786 MiB/s mit einer Blockgröße von 64 KB.
Ein Host: Jeder Host konnte durchschnittlich ~198.060 8-KB-IOPS oder ~2351 MiB/s unterstützen, wenn Sie mindestens 4 VMs pro Host mit mindestens 4 Azure NetApp Files-Datenspeichern verwenden. Sie haben also die Möglichkeit, die Bereitstellung von genügend Datenspeicher für maximale Leistung und potenziell Bursting gegen eine Komplikation der Verwaltung und Kosten abzuwägen.

Empfehlungen

Wenn die Leistungsfähigkeit eines einzelnen Datenspeichers unzureichend ist, verteilen Sie Ihre virtuellen Computer über mehrere Datenspeicher hinweg, um noch weiter zu skalieren. Einfachheit ist häufig am besten, Leistung und Skalierbarkeit können jedoch eine zusätzliche, aber begrenzte Komplexität rechtfertigen.

Vier Azure NetApp Files-Datenspeicher bieten bis zu 10 GB/s verwendbare Bandbreite für große sequenzielle E/A-Vorgänge oder die Möglichkeit für bis zu 500K zufällige 8K-IOPS. Auch wenn ein Datenspeicher für viele Leistungsanforderungen ausreichend sein kann, beginnen Sie für eine optimale Leistung mit mindestens vier Datenspeichern.

Zur präzisen Leistungsoptimierung ermöglichen sowohl Windows- als auch Linux-Gastbetriebssysteme das Striping auf mehrere Datenträgern. Daher sollten Sie für Dateisysteme ein Striping über mehrere VMDKs hinweg in mehreren Datenspeicher durchführen. Wenn die Konsistenz von Anwendungsmomentaufnahmen jedoch ein Problem darstellt und nicht mit LVM oder Speicherplätzen behoben werden kann, erwägen Sie das Einbinden von Azure NetApp Files über ein Gastbetriebssystem oder die Skalierung auf Anwendungsebene, für die Azure viele hervorragende Optionen bietet.

Stellen Sie bei einem Striping der Volumes über mehrere Datenträger sicher, dass die Sicherungs- oder Notfallwiederherstellungssoftware das gleichzeitige Sichern mehrerer virtueller Datenträger unterstützt. Da für einzelne Schreibvorgänge ein Striping über mehrere Datenträger erfolgt, muss das Dateisystem sicherstellen, dass Datenträger während Momentaufnahme- oder Sicherungsvorgängen „fixiert“ werden. Die meisten modernen Dateisysteme umfassen einen Fixierungs- oder Momentaufnahmevorgang wie xfs (xfs_freeze) und NTFS (Volumeschattenkopien), die von Sicherungssoftware genutzt werden können.

Da bei Azure NetApp Files die bereitgestellte Kapazität im Kapazitätspool und nicht die zugeordnete Kapazität (Datenspeicher) abgerechnet wird, zahlen Sie z. B. denselben Betrag für 4x20 TB-Datenspeicher und 20x4 TB-Datenspeicher. Wenn dies erforderlich ist, können Sie die Kapazität und Leistung von Datenspeichern nach Bedarf optimieren, dynamisch über die Azure-API/Konsole.

Beispiel: Sie nähern sich dem Ende eines Geschäftsjahres und stellen fest, dass Sie mehr Speicherleistung im Standarddatenspeicher benötigen. Sie können die Serviceebene der Datenspeicher für einen Monat erhöhen, um allen virtuellen Computern in diesen Datenspeichern mehr Leistung zur Verfügung zu stellen, während andere Datenspeicher auf einer niedrigeren Dienstebene verwaltet werden. Sie sparen nicht nur Kosten, sondern erzielen auch mehr Leistung, indem Workloads auf mehr TCP-Verbindungen zwischen den einzelnen Datenspeichern und jedem AVS-Host verteilt werden.

Sie können Ihre Datenspeichermetriken über vCenter Server oder über die Azure-API/Konsole überwachen. Von vCenter Server aus können Sie die durchschnittlichen IOPS eines Datenspeichers in den Leistungsdiagrammen/erweiterten Diagrammen überwachen, solange Sie das Erfassen von Speicher-E/A-Kontollmetriken im Datenspeicher aktivieren. Die Azure-API und -Konsole bieten u. a. Metriken für WriteIops, ReadIops, ReadThroughput und WriteThroughput, um Ihre Workloads auf Datenspeicherebene zu messen. Mit Azure-Metriken können Sie Warnungsregeln mit Aktionen festlegen, um die Größe eines Datenspeichers über eine Azure-Funktion, einen Webhook oder andere Aktionen automatisch zu ändern.

Freigeben über