Leistungsbenchmarks für normale Azure NetApp Files-Volumes für Linux
In diesem Artikel werden Leistungsbenchmarks beschrieben, die von Azure NetApp Files mit einen normalen Volume für Linux bereitgestellt werden.
Streamingworkloads für ganze Dateien (Vergleichstests zur horizontalen Skalierung)
Ein Test zur horizontalen Skalierung soll die Leistung eines Azure NetApp File-Volumes bei der horizontalen Skalierung (oder Erhöhung) der Anzahl von Clients zeigen, die gleichzeitig Arbeitslast für dasselbe Volume generieren. Diese Tests sind in der Regel in der Lage, ein Volumen an die Grenze seiner Leistungsfähigkeit zu bringen und sind ein Indikator für Workloads wie Medienwiedergabe, KI/ML und andere Workloads, die große Rechenfarmen zur Ausführung von Aufgaben nutzen.
Konfiguration der Vergleichstests für die horizontale Skalierung für viele E/A-Operationen pro Sekunde
Für diese Vergleichstests wurde Folgendes verwendet:
- Ein einzelnes reguläres Azure NetApp Files 100-TiB-Volume mit einem 1-TiB-Dataset mit der Leistungsstufe „Ultra“
- FIO (mit und ohne Einstellung von „randrepeat=0“)
- 4-KiB- und 8-KiB-Blockgrößen
- 6 virtuelle Computer D32s_v5 mit RHEL 9.3
- NFSv3
- Manual QoS
- Optionen zum Einlegen: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Konfiguration der Vergleichstests für die horizontale Skalierung für hohen Durchsatz
Für diese Vergleichstests wurde Folgendes verwendet:
- Ein einzelnes reguläres Azure NetApp Files-Volume mit einem 1-TiB-Dataset mit der Leistungsstufe „Ultra“ FIO (mit und ohne Einstellung von „randrepeat=0“)
- FIO (mit und ohne Einstellung von „randrepeat=0“)
- 64-KiB und 256-KiB-Blockgröße
- 6 virtuelle Computer D32s_v5 mit RHEL 9.3
- NFSv3
- Manual QoS
- Optionen zum Einlegen: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Konfiguration des Vergleichstests für parallele Netzwerkverbindung (nconnect)
Für diese Vergleichstests wurde Folgendes verwendet:
- Ein einzelnes reguläres Azure NetApp Files-Volume mit einem 1-TiB-Dataset mit der Leistungsstufe „Ultra“
- FIO (mit und ohne Einstellung von „randrepeat=0“)
- 4-KiB und 64-KiB wsize/rsize
- Ein einzelner virtueller Computer D32s_v4 mit RHEL 9.3
- NFSv3 mit und ohne
nconnect - Optionen zum Einlegen: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Vergleichstests für Hochskalierung
Der Test zur Hochskalierung soll die Leistung eines Azure NetApp File-Volumes beim Hochskalieren (oder Erhöhen) der Anzahl von Aufträgen zeigen, die eine gleichzeitige Workload über mehrere TCP-Verbindungen auf einem einzelnen Client zum selben Volume erzeugen (z. B. mit nconnect).
Ohne nconnect können diese Workloads die maximale Leistung eines Volumes nicht ausreizen, da der Client nicht genügend E/A- oder Netzwerkdurchsatz generieren kann. Diese Tests sind im Allgemeinen ein Hinweis darauf, wie die Erfahrung einer einzelnen benutzenden Person bei Workloads wie Medienwiedergabe, Datenbanken, KI/ML und allgemeinen Dateifreigaben aussehen könnte.
Vergleichstests für die horizontale Skalierung für viele E/A-Operationen pro Sekunde
Die folgenden Benchmarks zeigen die Leistung, die für Azure NetApp Files mit einer Workload mit vielen E/A-Operationen pro Sekunde-Leistung erzielt wurde, unter Verwendung von:
- 32 Clients
- 4-KiB und 8-KiB zufällige Lese- und Schreibvorgänge
- 1-TiB-Dataset
- Lese-/Schreibverhältnisse wie folgt: 100%:0%, 90%:10%, 80%:20% usw.
- Mit und ohne Dateisystemzwischenspeichern (unter Verwendung von
randrepeat=0in FIO)
Weitere Informationen finden Sie unter Testmethodik.
Ergebnisse: 4 KiB, zufällig, Clientzwischenspeichern enthalten
In diesem Vergleichstest wurde FIO ohne die randrepeat-Option zum zufälligen Festlegen von Daten ausgeführt. Daher kam eine unbestimmte Menge an Zwischenspeichern ins Spiel. Diese Konfiguration führt zu etwas besseren Gesamtleistungszahlen als Tests, die ohne Zwischenspeichern mit Nutzung des gesamten E/A-Stacks durchgeführt werden.
In der folgenden Grafik zeigen Tests, dass ein reguläres Azure NetApp Files-Volume während dieses Benchmarks zwischen etwa 130 000 reinen zufälligen 4-KiB-Schreibvorgängen und etwa 460 000 reinen zufälligen 4-KiB-Lesevorgängen verarbeiten kann. Lese-/Schreibmischung für den Workload, der bei jedem Durchlauf um 10 % angepasst wird.
Wenn die Lese-/Schreibmischung für E/A-Operationen pro Sekunde in Richtung schreiblastig zunimmt, sinkt die Gesamtanzahl der E/A-Operationen pro Sekunde.
Ergebnisse: 4 KiB, zufällig, Clientzwischenspeichern ausgeschlossen
In diesem Vergleichstest wurde FIO mit der Einstellung randrepeat=0 ausgeführt, um Zufallsdaten zu generieren und den Einfluss des Zwischenspeicherns auf die Leistung zu reduzieren. Dies führte zu einer Reduzierung der Schreibvorgänge für E/A-Operationen pro Sekunde um ca. 8 % und einer Reduzierung der Lesevorgänge für E/A-Operationen pro Sekunde um ca. 17 %, zeigt jedoch Leistungszahlen an, die repräsentativer für die tatsächliche Leistung des Speichers sind.
Im folgenden Diagramm zeigen Tests, dass ein reguläres Azure NetApp Files-Volume zwischen etwa 120 000 reinen zufälligen 4-KiB-Schreibvorgängen und etwa 388 000 reinen zufälligen 4-KiB-Lesevorgängen verarbeiten kann. Lese-/Schreib-Mischung für den Workload, der bei jedem Durchlauf um 25 % angepasst wird.
Wenn die Lese-/Schreibmischung für E/A-Operationen pro Sekunde in Richtung schreiblastig zunimmt, sinkt die Gesamtanzahl der E/A-Operationen pro Sekunde.
Ergebnisse: 8 KiB, zufällig, Clientzwischenspeichern ausgeschlossen
Größere Lese- und Schreibgrößen führen zu weniger E/A-Operationen pro Sekunde insgesamt, da bei jedem Vorgang mehr Daten gesendet werden können. Es wurde eine Lese- und Schreibgröße von 8 KiB verwendet, um genauer zu simulieren, was die meisten modernen Anwendungen verwenden. Zum Beispiel verwenden viele EDA-Anwendungen 8-KiB-Lese- und Schreibvorgänge.
In diesem Vergleichstest wurde FIO mit randrepeat=0 ausgeführt, um die Daten zu randomisieren, sodass die Auswirkungen des Clientzwischenspeicherns reduziert wurden. Im folgenden Diagramm zeigen Tests, dass ein reguläres Azure NetApp Files-Volume zwischen etwa 111 000 reinen zufälligen 8-KiB-Schreibvorgängen und etwa 293 000 reinen zufälligen 8-KiB-Lesevorgängen verarbeiten kann. Lese-/Schreib-Mischung für den Workload, der bei jedem Durchlauf um 25 % angepasst wird.
Wenn die Lese-/Schreibmischung für E/A-Operationen pro Sekunde in Richtung schreiblastig zunimmt, sinkt die Gesamtanzahl der E/A-Operationen pro Sekunde.
Parallele Vergleiche
Um zu veranschaulichen, wie sich das Zwischenspeichern auf die Leistung von Vergleichstests auswirken kann, zeigt die folgende Grafik die Gesamtzahl der I/OPS für 4-KiB-Tests mit und ohne Mechanismen für das Zwischenspeichern. Wie dargestellt, bietet Zwischenspeichern eine leichte Leistungssteigerung für E/A-Operationen pro Sekunde bei einem recht konstanten Trend.
Spezifischer Ausgleich, Streaming zufälliger Lese-/Schreibworkloads: Skalierungstests mit parallelen Netzwerkverbindungen (nconnect)
Die folgenden Tests zeigen einen hohen Benchmark für E/A-Operationen pro Sekunde unter Verwendung eines einzelnen Clients mit 4-KiB zufälligen Workloads und einem 1-TiB-Dataset. Die generierte Workload-Mischung verwendet jedes Mal eine andere E/A-Tiefe. Um die Leistung für einen einzelnen Client-Workload zu steigern, wurde die Einhängeoption nconnect verwendet, um die Parallelität im Vergleich zu Client-Einhängungen ohne die Einhängeoption nconnect zu verbessern.
Bei Verwendung einer Standard-TCP-Verbindung, die nur einen einzigen Pfad zum Speicher bereitstellt, werden insgesamt weniger Vorgänge pro Sekunde gesendet als bei einer Bereitstellung, die mehrere TCP-Verbindungen (z. B. mit nconnect) pro Bereitstellungspunkt nutzen kann. Bei Verwendung von nconnect ist die Gesamtlatenz für die Vorgänge im Allgemeinen niedriger. Diese Tests werden auch ausgeführt randrepeat=0, um das Zwischenspeichern absichtlich zu vermeiden. Weitere Informationen zu dieser Option finden Sie unter Testmethodik.
Ergebnisse: 4 KiB, zufällig, mit und ohne nconnect, Zwischenspeichern ausgeschlossen
Die folgenden Diagramme zeigen einen direkten Vergleich von 4-KiB-Lese- und Schreibvorgängen mit und ohne nconnect, um die Leistungsverbesserungen hervorzuheben, die bei Verwendung von nconnect zu beobachten sind: höhere Gesamtanzahl der E/A-Operationen pro Sekunde, geringere Latenz.
Benchmarks für hohen Durchsatz
Die folgenden Benchmarks zeigen die Leistung, die für Azure NetApp Files mit einer Workload mit hoher Durchsatzleistung erzielt wurde.
Workloads mit hohem Durchsatz sind eher sequentieller Natur und weisen häufig eine hohe Lese-/Schreiblast mit wenigen Metadaten auf. Der Durchsatz ist im Allgemeinen wichtiger als E/A-Operationen pro Sekunde. Diese Workloads nutzen in der Regel größere Lese-/Schreibgrößen (64 KB bis 256 KB), die höhere Latenzen erzeugen als kleinere Lese-/Schreibgrößen, da die Verarbeitung größerer Nutzlasten naturgemäß länger dauert.
Beispiele für Workloads mit hohem Durchsatz sind:
- Medienrepositorys
- High Performance Computing
- AI/ML/LLP
Die folgenden Tests zeigen einen hohen Vergleichswert für den Durchsatz unter Verwendung von sequenziellen Workloads mit 64 KB und 256 KB sowie einem Dataset mit 1 TB. Die generierte Workload-Mischung verringert sich jeweils um einen festgelegten Prozentsatz und zeigt, was Sie bei Verwendung unterschiedlicher Lese-/Schreibverhältnisse erwarten können (z. B. 100 %:0 %, 90 %:10 %, 80 %:20 % usw.).
Ergebnisse: 64 KiB sequenzielle E/A, einschließlich Zwischenspeichern
In diesem Benchmark wurde FIO mit einer Schleifenlogik ausgeführt, die den Cache aggressiver füllte, sodass eine unbestimmte Menge an Zwischenspeichern die Ergebnisse beeinflusste. Dies führt zu etwas besseren Gesamtleistungszahlen als bei Tests ohne Zwischenspeichern.
Im folgenden Diagramm zeigen die Tests, dass ein reguläres Azure NetApp Files Volume ca. 4 500 MB/s rein sequentielle 64-KiB-Lesevorgänge und ca. 1 600 MB/s rein sequentielle 64-KiB-Schreibvorgänge verarbeiten kann. Die Lese-/Schreibmischung für den Workload wurde bei jedem Durchlauf um 10 % angepasst.
Ergebnisse: 64 KiB sequenzielle E/A, Zwischenspeichern ausgeschlossen
In diesem Vergleichstest wurde FIO mit einer Schleifenlogik ausgeführt, die den Cache weniger aggressiv füllte. Das Zwischenspeichern von Clients hatte keinen Einfluss auf die Ergebnisse. Diese Konfiguration führt zu etwas besseren Schreib- und schlechteren Leseleistungszahlen als Tests ohne Zwischenspeichern.
Im folgenden Diagramm zeigen Tests, dass ein reguläres Azure NetApp Files-Volume zwischen ca. 3 600 MiB/s reine sequenzielle 64-KiB-Lesevorgänge und ca. 2 400 MiB/s reine sequenzielle 64-KiB-Schreibvorgänge verarbeiten kann. Während der Tests zeigte eine 50/50-Mischung einen Gesamtdurchsatz, der mit einem reinen sequentiellen Leseworkload vergleichbar war.
Die Lese-/Schreibmischung für den Workload wurde bei jedem Durchlauf um 25 % angepasst.
Ergebnisse: 256 KiB sequenzielle E/A, Zwischenspeichern ausgeschlossen
In diesem Vergleichstest wurde FIO mit einer Schleifenlogik ausgeführt, die den Cache weniger aggressiv füllte. Das Zwischenspeichern hatte also keinen Einfluss auf die Ergebnisse. Diese Konfiguration führt zu etwas geringeren Schreibleistungszahlen als 64-KiB-Tests, aber zu höheren Lesezahlen als dieselben 64-KiB-Tests, die ohne Zwischenspeichern ausgeführt werden.
Im folgenden Diagramm zeigen die Tests, dass ein reguläres Azure NetApp Files Volume ca. 3 500 MB/s rein sequentielle 256-KiB-Lesevorgänge und ca. 2 600 MB/s rein sequentielle 256-KiB-Schreibvorgänge verarbeiten kann. Während der Tests zeigte eine 50/50-Mischung einen höheren Gesamtdurchsatz als ein reiner sequenzieller Leseworkload.
Die Lese-/Schreibmischung für den Workload wurde bei jedem Durchlauf in 25 %-Schritten angepasst.
Gegenüberstellung
Um genauer zu veranschaulichen, wie sich Caching auf die Leistung von Vergleichstests auswirken kann, zeigt die folgende Grafik die Gesamtzahl der MiB/s für 64-KiB-Tests mit und ohne Mechanismen für das Zwischenspeichern. Das Zwischenspeichern sorgt für eine anfängliche leichte Leistungssteigerung bei der Gesamt-MiB/s, da das Zwischenspeichern im Allgemeinen die Lesevorgänge stärker verbessert als die Schreibvorgänge. Wenn sich die Lese-/Schreibmischung ändert, überschreitet der Gesamtdurchsatz ohne Zwischenspeichern die Ergebnisse, die das Clientzwischenspeichern nutzen.
Parallele Netzwerkverbindungen (nconnect)
Die folgenden Tests zeigen einen hohen Benchmark für E/A-Operationen pro Sekunde unter Verwendung eines einzelnen Clients mit 64-KiB zufälligen Workloads und einem 1-TiB-Dataset. Die generierte Workload-Mischung verwendet jedes Mal eine andere E/A-Tiefe. Um die Leistung für einen einzelnen Client-Workload zu steigern, wurde die Einhängemethode nconnect für eine bessere Parallelität im Vergleich zu Client-Einhängemethoden ohne die Einhängemethode nconnect genutzt. Diese Tests wurden nur ohne Zwischenspeichern durchgeführt.
Ergebnisse: 64 KiB, sequenziell, zwischenspeichern ausgeschlossen, mit und ohne nconnect
Die folgenden Ergebnisse zeigen die Ergebnisse eines Skalierungstests beim Lesen und Schreiben in 4-KiB-Blöcken auf einer NFSv3-Einbindung auf einem einzelnen Client mit und ohne Parallelisierung von Vorgängen (nconnect). Die Diagramme zeigen, dass mit zunehmender E/A-Tiefe auch die E/A-Operationen pro Sekunde zunehmen. Doch bei Verwendung einer Standard-TCP-Verbindung, die nur einen einzigen Pfad zum Speicher bereitstellt, werden insgesamt weniger Vorgänge pro Sekunde gesendet als bei einer Bereitstellung, die mehrere TCP-Verbindungen pro Bereitstellungspunkt nutzen kann. Darüber hinaus ist die Gesamtlatenz für die Vorgänge in der Regel niedriger, wenn nconnect verwendet wird.
Paralleler Vergleich (mit und ohne nconnect)
Die folgenden Diagramme zeigen einen direkten Vergleich von sequenziellen 64-KiB-Lese- und Schreibvorgängen mit und ohne nconnect, um die Leistungsverbesserungen hervorzuheben, die bei Verwendung von nconnect zu beobachten sind: höherer Gesamtdurchsatz, geringere Latenz.
