Leistungsbenchmarks für große Azure NetApp Files-Volumes für Linux
In diesem Artikel werden die getesteten Leistungsfunktionen eines einzelnen großen Azure NetApp Files-Volumes beschrieben, da es sich um Linux-Anwendungsfälle handelt. Die Tests untersuchten Szenarien sowohl für die horizontale Skalierung als auch für die Hochskalierung von Lese- und Schreib-Workloads mit einem und vielen virtuellen Computern (VMs). Wenn Sie den Leistungsumfang großer Volumes kennen, können Sie die Volumegröße vereinfachen.
Testzusammenfassung
Das Feature „Große Azure NetApp Files-Volumes“ bietet drei Dienstebenen, die jeweils Durchsatzgrenzwerte aufweisen. Die Dienstebenen können bei einer Änderung der Leistungsanforderungen hoch- oder herunterskaliert werden.
- Ultra-Dienstebene: 12.800 MiB/s
- Premium-Dienstebene: 6.400 MiB/s
- Standard-Dienstebene: 1.600 MiB/s
Die Ultra-Dienstebene wurde in diesen Tests verwendet.
Sequenzielle Schreibvorgänge: 100 % sequenzielle Schreibvorgänge erreichten bei diesen Benchmarks maximal ca. 8.500 MiB/Sekunde. (Der maximale Durchsatz eines einzelnen großen Volumes wird durch den Dienst auf 12.800 MiB/Sekunde begrenzt, daher ist ein größerer potenzieller Durchsatz möglich.)
Sequenzielle Lesevorgänge: 100 % sequenzielle Lesevorgänge erreichten bei diesen Benchmarks maximal ca. 12.761 MiB/Sekunde. (Der Durchsatz eines einzelnen großen Volumes wird auf 12.800 MiB/Sekunde begrenzt. Dieses Ergebnis liegt nahe dem derzeit maximal erreichbaren Durchsatz.)
Zufällige E/A: Das gleiche große Volume liefert über 700.000 Vorgänge pro Sekunde.
Metadatenintensive Workloads sind für große Azure NetApp File-Volumes aufgrund der erhöhten Parallelität des großen Volumes vorteilhaft. Leistungsvorteile sind in Workloads spürbar, die mit der Dateierstellung, Aufhebung von Verknüpfungen und Dateiumbenennungen, wie es bei VCS-Anwendungen üblich ist, und EDA-Workloads verbunden sind, bei denen eine hohe Dateianzahl vorhanden ist. Weitere Informationen zur Leistung von hohen Metadatenworkloads finden Sie unter Vorteile der Verwendung von Azure NetApp Files für Electronic Design Automation.
FIO, ein synthetischer Workload-Generator, der als Speicherstresstest konzipiert wurde, wurde verwendet, um diese Testergebnisse zu fördern. Es gibt grundsätzlich zwei Modelle von Speicherleistungstests:
- Horizontale Skalierungsberechnung bezieht sich auf die Verwendung mehrerer virtueller Computer, um die maximal mögliche Last in einem einzelnen Azure NetApp Files-Volume zu generieren.
- Hochskalierungsberechnung bezieht sich auf die Verwendung eines großen virtuellen Computers, um die oberen Grenzen eines einzelnen Clients in einem einzelnen Azure NetApp Files-Volume zu testen.
Test zur horizontalen Skalierung in Linux
Tests beobachteten Leistungsschwellenwerte für ein einzelnes großes Volume bei der horizontalen Skalierung und wurden mit der folgenden Konfiguration durchgeführt:
| Komponente | Konfiguration |
|---|---|
| Azure-VM-Größe | E32s_v5 |
| Bandbreitenlimit des ausgehenden Datenverkehrs für virtuelle Azure-Computer | 2.000 MiB/s (2 GiB/s) |
| Betriebssystem | RHEL 8.4 |
| Große Volumegröße | 101 TiB Ultra (12.800 MiB/s Durchsatz) |
| Einbindungsoptionen | hard,rsize=65536,wsize=65536,vers=3 HINWEIS: Die Verwendung von 262144 und 65536 hatte ähnliche Leistungsergebnisse. |
Sequenzielle Workloads von 256 KiB (MiB/s)
Das Diagramm stellt eine sequenzielle Workload von 256 KiB dar, in der 12 virtuelle Computer mit einem 1-TiB-Arbeitssatz aus einem einzelnen großen Volume lesen und in dieses schreiben. Das Diagramm veranschaulicht, dass ein einzelnes großes Azure NetApp Files-Volume zwischen etwa 8.518 MiB/s reine sequenzielle Schreibvorgänge und 12.761 MiB/s reine sequenzielle Lesevorgänge verarbeiten kann.
Zufällige Workload von 8 KiB (IOPS)
Im Diagramm sind eine zufällige Workload von 8 KiB und ein Arbeitssatz mit einer Größe von 1 TiB dargestellt. Das Diagramm veranschaulicht, dass ein großes Azure NetApp Files-Volume zwischen etwa 474.000 reine zufällige Schreibvorgänge und etwa 709.000 reine zufällige Lesevorgänge verarbeiten kann.
Test zur Hochskalierung in Linux
Während Tests zur horizontalen Skalierung darauf ausgelegt sind, die Grenzen eines einzelnen großen Volumens zu ermitteln, sind Tests zur Hochskalierung so konzipiert, dass sie die oberen Grenzwerte einer einzelnen Instanz anhand des großen Volume ermitteln. Azure platziert Netzwerkgrenzwerte für ausgehenden Datenverkehr für seine virtuellen Computer; für netzwerkgebundenen Speicher bedeutet dies, dass die Schreibbandbreite pro virtuellem Computer begrenzt ist. Diese Tests zur Hochskalierung veranschaulichen Funktionen angesichts der großen verfügbaren Bandbreitenobergrenze und mit ausreichenden Prozessoren, um diese Workload zu fördern.
Die Tests in diesem Abschnitt wurden mit der folgenden Konfiguration ausgeführt:
| Komponente | Konfiguration |
|---|---|
| Azure-VM-Größe | E104id_v5 |
| Bandbreitenlimit des ausgehenden Datenverkehrs für virtuelle Azure-Computer | 12.500 MiB/s (12.2 GiB/s) |
| Betriebssystem | RHEL 8.4 |
| Große Volumegröße | 101 TiB Ultra (12.800 MiB/s Durchsatz) |
| Einbindungsoptionen | hard,rsize=65536,wsize=65536,vers=3 HINWEIS: Die Verwendung von 262144 und 65536 hatte ähnliche Leistungsergebnisse |
Die Diagramme in diesem Abschnitt enthalten die Ergebnisse für die clientseitige Einbindungsoption von nconnect mit NFSv3. Weitere Informationen finden Sie unter Einbindungsoptionen für NFS unter Linux: bewährte Methoden für Azure NetApp File.
Die folgenden Diagramme vergleichen die Vorteile von nconnect mit einem in NFS eingebunden Volume ohne nconnect. In den Tests generierte FIO die Workload aus einer einzelnen E104id-v5-Instanz in der Azure-Region „USA, Osten“ unter Verwendung einer sequenziellen Workload von 64 KiB; die Verwendung einer E/A-Größe von 256, was die größte von Azure NetApp Files empfohlene E/A-Größe darstellt, führte zu vergleichbaren Leistungszahlen. Weitere Informationen finden Sie unter rsize und wsize.
Linux-Lesedurchsatz
Die folgenden Diagramme zeigen sequenzielle Lesevorgänge von 256 KiB von ca. 10.000 MiB/s mit nconnect, was ungefähr den zehnfachen Durchsatz darstellt, der ohne nconnect erreicht wurde.
Beachten Sie, dass 10.000 MiB/s ungefähr die Zeilenrate der an die E104id_v5 angeschlossenen Netzwerkschnittstellenkarte von 100 GBit/s ist.
Linux-Schreibdurchsatz
Die folgenden Diagramme zeigen sequenzielle Schreibvorgänge. Die Verwendung von nconnect bietet beobachtbare Vorteile für sequenzielle Schreibvorgänge bei 6.600 MiB/s, was etwa dem Vierfachen von Einbindungen ohne nconnect entspricht.
Linux-Lese-IOPS
In den folgenden Diagrammen sind zufällige Lesevorgänge von 8 KiB von ~426.000 Lese-IOPS mit nconnect dargestellt, was ungefähr dem Siebenfachen von dem entspricht, was ohne nconnect beobachtet wird.
Linux-Schreib-IOPS
In den folgenden Diagrammen sind zufällige Schreibvorgänge von 8 KiB von ~405.000 Schreib-IOPS mit nconnect dargestellt, was ungefähr dem 7,2-fachen von dem entspricht, was ohne nconnect beobachtet wird.
