Freigeben über

Leistungsbenchmarks für normale Azure NetApp Files-Volumes für Linux

  • Artikel

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=0 in 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.

Diagramm der Vergleichstests mit 4 KiB, zufällig, einschließlich Clientzwischenspeichern.

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.

Diagramm der Vergleichstests mit 4 KiB, zufällig, Clientzwischenspeichern ausgeschlossen.

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.

Diagramm der Vergleichstests mit 8 KiB, zufällig, Clientzwischenspeichern ausgeschlossen.

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.

Diagramm zum Wertevergleich von 4 KiB-Vergleichstests.

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.

Diagramm der 4-KiB-Leseleistung.

Diagramm der 4-KiB-Schreibleistung.

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.

Diagramm von Vergleichstests mit 64 KiB, einschließlich sequentieller E/A und Zwischenspeichern.

Ergebnisse: 64 KiB sequenzielle E/A, Lese- und Schreibvorgänge, Baseline ohne Zwischenspeicherung

In dieser Baseline-Benchmark 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.

Im Hinblick auf reines Lesen war die 64-KiB-Baseline etwas besser als die 256-KiB-Baseline. Bei reinen Schreibvorgängen und allen gemischten Lese-/Schreibworkloads übertrifft die 256-KiB-Baseline jedoch 64 KiB, sodass eine größere Blockgröße von 256 KiB für Workloads mit hohem Durchsatz insgesamt effektiver ist.

Die Lese-/Schreibmischung für den Workload wurde bei jedem Durchlauf um 25 % angepasst.

Diagramm von Vergleichstests mit 64 KiB, sequentieller E/A und Zwischenspeichern ausgeschlossen.

Ergebnisse: 256 KiB sequenzielle E/A ohne Zwischenspeicherung

In den folgenden beiden Baseline-Benchmarks wurde FIO verwendet, um die Anzahl der sequenziellen E/A (Lese- und Schreibvorgänge) eines einzelnen regulären Volumes in Azure NetApp Files zu messen. Um eine Baseline zu erzeugen, die die tatsächliche Bandbreite widerspiegelt, die eine vollständig nicht zwischengespeicherte Leseworkload erreichen kann, wurde FIO so konfiguriert, dass es mit dem Parameter randrepeat=0 für die Generierung von Datasets ausgeführt wird. Jede Testiteration wurde durch das Lesen eines vollständig separaten großen Datasets versetzt, das nicht Teil der Benchmark ist, um die Zwischenspeicherung zu löschen, die möglicherweise mit dem Benchmark-Dataset aufgetreten ist.

In diesem Graph zeigen die Tests, dass ein reguläres Azure NetApp Files-Volume ca. 3.500 MiB/s rein sequenzielle 256-KiB-Lesevorgänge und ca. 2.500 MiB/s rein sequenzielle 256-KiB-Schreibvorgänge verarbeiten kann. Während der Tests zeigte eine 50/50-Mischung einen höheren Gesamtdurchsatz als ein reiner sequenzieller Leseworkload.

Diagramm der 256-KiB-Sequenzvergleichstests.

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 sequenzielle E/A, Vergleich von Lesedurchsatz-Cache

Um zu veranschaulichen, wie die Zwischenspeicherung die Leistungsergebnisse beeinflusst, wurde FIO im folgenden Mikro-Benchmark-Vergleich verwendet, um die Anzahl der sequenziellen E/A (Lese- und Schreibvorgänge) eines einzelnen regulären Volumes in Azure NetApp Files zu messen. Dieser Test vergleicht die Vorteile, die eine in Teilen zwischenspeicherbare Workload bieten kann.

Im Ergebnis ohne Zwischenspeicherung wurden die Tests so konzipiert, dass Zwischenspeicherungen wie in den oben beschriebenen Baseline-Benchmarks abgemildert werden. Im anderen Ergebnis wurde FIO für reguläre Azure NetApp Files-Volumes ohne den Parameter randrepeat=0 und mit Verwendung einer Iterationslogik für Schleifentests verwendet, die den Cache im Laufe der Zeit langsam aufgefüllt hat. Die Kombination dieser Faktoren erzeugte eine unbestimmte Zwischenspeicherungsmenge, wodurch der allgemeine Durchsatz erhöht wird. Diese Konfiguration führte zu einer insgesamt etwas besseren Leseleistung als Tests ohne Zwischenspeicherung.

Die im Diagramm gezeigten Testergebnisse zeigen den Nebeneinandervergleich der Leseleistung mit und ohne Zwischenspeicherung, wobei mit Zwischenspeicherung bis zu ca. 4.500 MiB/Sekunde für den Lesedurchsatz erreicht wurden, während ohne Zwischenspeicherung ca. 3.600 MiB/Sekunde erreicht wurden.

Diagramm für den Vergleich von sequenziellen 64-KiB-Lesedurchsätzen basierend auf der Zwischenspeicherung.

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.

Diagramm zum Vergleichen von sequenziellen 64-KiB-Lese- und Schreibvorgängen.

Weitere Informationen