Verbessern der Leistung für NFS Azure-Dateifreigaben

Gilt für: ✔️ NFS-Dateifreigaben

Dieser Artikel bietet verschiedene Möglichkeiten zur Verbesserung der Leistung für Azure-Dateifreigaben mit Network File System (NFS). Themen umfassen die Konfiguration des Linux-Kernelparameters read_ahead_kb für einen höheren sequentiellen Lesedurchsatz, die Verwendung der Einhängeoption nconnect zur Skalierung des Durchsatzes mit weniger Clientcomputern sowie die Platzierung Ihres Speicherkontos in derselben Verfügbarkeitszone wie Ihre Clients, um die Latenz zu verringern.

Erhöhen der Vorauslesegröße zur Verbesserung des Lesedurchsatzes

Der Kernelparameter read_ahead_kb in Linux steht für die Datenmenge, die während eines sequenziellen Lesevorgangs „vorausgelesen“ oder vorab abgerufen werden soll. Linux-Kernelversionen vor 5.4 legen den Vorauslesewert auf das Äquivalent von 15 Mal der rsize des bereitgestellten Dateisystems fest, was der clientseitigen Bereitstellungsoption für die Größe des Lesepuffers entspricht. Dadurch wird der Vorauslesewert hoch genug festgelegt, um den sequenziellen Lesedurchsatz des Clients in den meisten Fällen zu verbessern.

Ab Linux Kernel Version 5.4 verwendet der Linux NFS-Client jedoch einen Standardwert von 128 KiB für read_ahead_kb. Dieser geringere Wert könnte die Lesedurchsatzmenge für große Dateien verringern. Nutzer, die von Linux-Versionen mit höherem Vorlesewert auf Versionen mit 128 KiB Standard umsteigen, könnten eine Verringerung der sequentiellen Leseleistung erleben.

Für Linux-Kernel ab 5.4 sollte man die Geschwindigkeit read_ahead_kb dauerhaft auf 15 MiB setzen, um die Leistung zu verbessern.

Um diesen Wert zu ändern, legen Sie die Vorauslesegröße fest, indem Sie eine Regel in udev, einem Linux-Kernelgerätemanager, hinzufügen. Folgen Sie diesen Schritten:

1. Erstellen Sie in einem Text-Editor die Datei /etc/udev/rules.d/99-nfs.rules, indem Sie den folgenden Text eingeben und speichern:

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. Wenden Sie in einer Konsole die udev-Regel an, indem Sie den Befehl udevadm als Superuser ausführen und die Regeldateien und andere Datenbanken neu laden. Du musst diesen Befehl nur einmal ausführen, um Udev auf die neue Datei aufmerksam zu machen.

   sudo udevadm control --reload
   

NFS nconnect

NFS nconnect ist eine clientseitige Mount-Option für NFS-Dateifreigaben, die Sie verwenden, um mehrere TCP-Verbindungen zwischen dem Client und Ihrer NFS-Dateifreigabe herzustellen. Es ist besonders nützlich für groß angelegte Arbeitslasten, bei denen eine einzelne TCP-Verbindung zum Engpass wird.

nconnect-Vorteile

Mit nconnect können Sie die Leistung im großen Maßstab erhöhen, indem Sie weniger Clientcomputer verwenden, um die Gesamtbetriebskosten (TCO) zu reduzieren. Das nconnect-Feature erhöht die Leistung, indem mehrere TCP-Kanäle auf einem oder mehreren NICs mit einem oder mehreren Clients verwendet werden. Ohne nconnect benötigen Sie etwa 20 Clientcomputer, um die Bandbreitengrenzen (10 GiB/s) zu erreichen, die mit der größten Bereitstellungsgröße der SSD-Dateifreigabe möglich sind. Mit nconnect können Sie diese Grenzwerte nur mit 6 bis 7 Clients erreichen, die Berechnungskosten um fast 70 % reduzieren und gleichzeitig erhebliche Verbesserungen bei E/A-Vorgängen pro Sekunde (IOPS) und Durchsatz im großen Stil erzielen. Siehe hierzu die folgende Tabelle.

nconnect-Voraussetzungen

• Die neuesten Linux-Distributionen unterstützen nconnect vollständig. Stellen Sie bei älteren Linux-Distributionen sicher, dass die Linux-Kernelversion 5.3 oder höher ist.
• Die Konfiguration pro Einbindung wird nur unterstützt, wenn eine einzelne Dateifreigabe pro Speicherkonto über einen privaten Endpunkt verwendet wird.

Auswirkungen auf die Leistung

Die folgenden Leistungsergebnisse wurden mithilfe der nconnect-Einbindungsoption mit NFS-Azure-Dateifreigaben auf Linux-Clients im großen Maßstab gemessen. Weitere Informationen darüber, wie diese Ergebnisse erzielt wurden, finden Sie unter Leistungstestkonfiguration.

nconnect-Empfehlungen

Befolgen Sie diese Empfehlungen, um die besten Ergebnisse mit nconnect zu erzielen.

Festlegen von nconnect=4

Während Azure Files unterstützt, nconnect auf die maximale Einstellung von 16 zu setzen, konfigurieren Sie die Mount-Optionen mit der optimalen Einstellung nconnect=4. Derzeit gibt es keine Vorteile jenseits von vier Kanälen für die Azure Files-Implementierung von nconnect. Werden mehr als vier Kanäle zu einer einzelnen Azure-Dateifreigabe von einem einzelnen Client verwendet, kann sich dies aufgrund der Überlastung des TCP-Netzwerks sogar negativ auf die Leistung auswirken.

Sorgfältige Dimensionierung von VMs

Je nach Ihren Workloadanforderungen ist es wichtig, die Größe der virtuellen Clientcomputer (VMs) korrekt zu vergrößern, um zu vermeiden, dass sie von der erwarteten Netzwerkbandbreite eingeschränkt werden. Sie benötigen nicht mehrere NICs (Network Interface Controller), um den erwarteten Netzwerkdurchsatz zu erreichen. Obwohl es üblich ist, universelle VMs mit Azure Files zu verwenden, stehen je nach Workloadanforderungen und regionaler Verfügbarkeit verschiedene VM-Typen zur Auswahl. Weitere Informationen finden Sie unter Azure-VM-Auswahl.

Beschränken der Warteschlangentiefe auf maximal 64

Die Warteschlangentiefe ist die Anzahl ausstehender E/A-Anforderungen, die eine Speicherressource verarbeiten kann. Es wird nicht empfohlen, die optimale Warteschlangentiefe von 64 zu überschreiten, da Sie dadurch keine weiteren Leistungsgewinne erzielen. Weitere Informationen finden Sie unter Warteschlangentiefe.

Konfiguration pro Einbindung

Wenn eine Workload das Einbinden mehrerer Freigaben mit einem oder mehreren Speicherkonten mit unterschiedlichen nconnect-Einstellungen von einem einzelnen Client erfordert, ist nicht garantiert, dass die Einstellungen beim Einbinden über den öffentlichen Endpunkt beibehalten werden. Die Konfiguration pro Mount unterstützt nur eine einzige Azure-Dateifreigabe pro Speicherkonto über den privaten Endpunkt, wie in Szenario 1 beschrieben.

Szenario 1: Konfiguration pro Einbindung über einen privaten Endpunkt mit mehreren Speicherkonten (unterstützt)

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Szenario 2: Konfiguration pro Einbindung über einen öffentlichen Endpunkt (nicht unterstützt)

• StorageAccount.file.core.windows.net = 52.239.238.8
• StorageAccount2.file.core.windows.net = 52.239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Szenario 3: Konfiguration pro Einbindung über einen privaten Endpunkt mit mehreren Freigaben in einem einzelnen Speicherkonto (nicht unterstützt)

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Leistungstestkonfiguration

Um die in diesem Artikel beschriebenen Ergebnisse zu erzielen und zu messen, nutzen Sie die folgenden Ressourcen und Benchmarking-Tools.

• Einzelner Client: Azure-VM (DSv4-Serie) mit einer einzelnen NIC
• Betriebssystem: Linux (Ubuntu 20.04)
• NFS-Speicher: SSD-Dateifreigabe (30 TiB bereitgestellt, nconnect=4 festgelegt)

Benchmarktools und -tests

Diese Tests verwenden den Flexible I/O Tester (FIO), ein kostenloses, quelloffenes Disk-I/O-Tool, das sowohl für Benchmarking als auch für Stress- oder Hardware-Verifikation eingesetzt wird. Um FIO zu installieren, sehen Sie sich den Abschnitt Binärpakete in der FIO README-Datei an und folgen Sie den Anweisungen für die von Ihnen gewählte Plattform.

Diese Tests konzentrieren sich auf zufällige E/A-Zugriffsmuster, bei sequenziellen E/A-Zugriffen erhalten Sie jedoch ähnliche Ergebnisse.

Hohe IOPS-Rate: 100 % Lesevorgänge

E/A-Größe 4 KB – zufälliger Lesevorgang – Warteschlangentiefe 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

E/A-Größe 8 KB – zufälliger Lesevorgang – Warteschlangentiefe 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Hoher Durchsatz: 100 % Lesevorgänge

64 KiB-E/A-Größe - zufälliges Lesen - 64 Warteschlangentiefe

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

E/A-Größe 1.024 KB – zufälliger Lesevorgang (100 %) – Warteschlangentiefe 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Hohe IOPS-Rate: 100 % Schreibvorgänge

E/A-Größe 4 KiB – zufälliger Schreibvorgang (100 %) – Warteschlangentiefe 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

E/A-Größe 8 KiB – zufälliger Schreibvorgang (100 %) – Warteschlangentiefe 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Hoher Durchsatz: 100 % Schreibvorgänge

E/A-Größe 64 KiB – zufälliger Schreibvorgang (100 %) – Warteschlangentiefe 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

E/A-Größe 1.024 KiB – zufälliger Schreibvorgang (100 %) – Warteschlangentiefe 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Leistungsüberlegungen für nconnect

Wenn Sie die Einbindungsoption nconnect verwenden, sollten Sie Workloads mit den folgenden Eigenschaften genau bewerten:

• Latenzempfindliche Schreibworkloads mit einem einzelnen Thread und/oder einer geringen Warteschlangentiefe (kleiner als 16)
• Latenzempfindliche Leseworkloads mit einem einzelnen Thread und/oder einer geringen Warteschlangentiefe in Kombination mit kleinen E/A-Größen

Nicht alle Workloads erfordern hochskalierte IOPS oder Durchsatzleistung. Für kleinere Workloads könnte das nconnect nicht vorteilhaft sein. Verwenden Sie die folgende Tabelle, um zu entscheiden, ob nconnect für Ihre Workload von Vorteil ist. Empfohlene Szenarien sind grün hervorgehoben, nicht empfohlene Szenarien rot. Szenarien mit gelber Hervorhebung sind neutral.

Verwende die Zonenplatzierung

Für klassische Dateifreigaben, die mit dem Microsoft.Storage-Ressourcenanbieter erstellt wurden, empfehlen wir die Verwendung der Zonenplatzierung, um die spezifische Verfügbarkeitszone auszuwählen, in der sich Ihr Speicherkonto befindet. Auf diese Weise können Sie Ihre virtuellen Computer in derselben Verfügbarkeitszone wie Ihr Speicher platzieren, wodurch die Latenz um bis zu 30 Prozent reduziert werden kann. Dieses Feature ist derzeit nur für SSD-Speicherkonten verfügbar, die lokal redundanten Speicher (LRS) in unterstützten Regionen verwenden.

Weitere Informationen

• Bereitstellen der NFS-Dateifreigabe auf Linux
• Liste der Einbindungsoptionen
• Grundlegendes zur Leistung für Azure Files