Optionen für die Einbindung und Client-VM-Konfigurationen

In diesem Modul werden Einbindungsoptionen sowie Client-VM-Konfigurationen zum Steigern der Leistung untersucht, wenn Sie HPC- oder EDA-Anwendungen in Azure NetApp Files ausführen.

Verwenden der Einbindungsoptionen actimeo und nocto zur Verbesserung der Leistung

Sie können die folgenden Einbindungsoptionen verwenden, um die Leistung in relativ statischen Datasets und umfangreichen Leseszenarios zu verbessern:

• actimeo: Diese Option steuert die Cacheattribute eines NFS-Client für ein Verzeichnis. Wenn Sie für diese Option keine Angabe machen, verwendet der NFS-Client einen Standard-Maximalwert von 60 Sekunden.
• nocto: Diese Option steht für „no close-to-open“, was bedeutet, dass eine Datei geschlossen werden kann, bevor ein Schreibvorgang abgeschlossen ist, um Zeit zu sparen. Standardmäßig ist nocto in den NFS-Bereitstellungsoptionen nicht festgelegt. Das heißt, alle Dateien warten, bis die Schreibvorgänge abgeschlossen sind, bevor sie geschlossen werden können.

Die meisten HPC-Anwendungen, einschließlich EDA in unserem Szenario, haben relativ statische Datasets (d. h. die Daten ändern sich nicht häufig). In diesem Fall können Sie nocto und actimeo verwenden, um getattr zu senken, oder Sie verwenden Zugriffsvorgänge auf den Speicher, was die Anwendung beschleunigen kann.

Es wird beispielsweise empfohlen, "nocto,actimeo=600" (600 Sekunden oder 10 Minuten) für EDA-Tools und Bibliotheksvolumes festzulegen. Da sich diese Dateien nicht ändern, gibt es keine Cachekohärenz, die beibehalten werden muss. Wenn diese Einbindungsoptionen festgelegt werden, werden Metadatenaufrufe reduziert, was die Gesamtleistung verbessert.

Optimieren von Systemparametern für optimale Leistung

Tuned ist ein Daemon, mit dem verbundene Geräte auf Linux-Clients überwacht und konfiguriert werden können. In den meisten Fällen ist standardmäßig tuned installiert. Wenn es nicht installiert ist, kann es hinzugefügt und aktiviert werden, um clientseitige Optimierungsparameter mit integrierten Standardvorlagen zu vereinfachen.

Führen Sie die folgenden Befehle aus, um die grundlegende Serveroptimierung und die typische Latenzoptimierung für Ihre Client-VMs anzuwenden:

sudo systemctl enable --now tuned
sudo tuned-adm profile latency-performance

Einige oder alle der folgenden Systemparameter (/etc/sysctl.conf) können auf Linux-Client-VMs dazu beitragen, eine optimale Leistung zu erzielen. Wenn Sie über Client-VMs mit hoher RAM-Kapazität oder höherer Netzwerkbandbreite wie InfiniBand verfügen, sollten Sie einige Werte noch höher festlegen als unten im Beispiel gezeigt.

#
# Recommended client tuning 
#
# For more information, see sysctl.conf(5) and sysctl.d(5)
# Network parameters, in units of bytes
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048576 8388608 16777216
net.ipv4.tcp_wmem = 1048576 8388608 16777216
net.core.optmem_max = 2048000
net.core.somaxconn = 65535
#
# These settings are in 4-KiB chunks, in bytes:
# Min=16MiB, Def=350MiB, Max=16GiB
# In units of 4K pages
net.ipv4.tcp_mem = 4096 89600 4194304
#
# Miscellaneous network options and flags
#
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_slow_start_after_idle = 0
net.core.netdev_max_backlog = 300000
#
# Various file system and page cache options
#
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
#
# Recommended by: https://cromwell-intl.com/open-source/performance-tuning/tcp.html
#
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

So sorgen Sie dafür, dass diese Optimierungen dauerhaft sind:

sudo sysctl -P

Verwenden der nconnect-Einbindungsoptionen zum Erweitern von Netzwerkverbindungen (sofern anwendbar)

Die NFS-Einbindungsoption nconnect ist bei Linux-Kernel 5.3 und höher allgemein verfügbar. So überprüfen Sie den Linux-Kernel Ihrer Client-VM:

uname -r

Der Zweck von nconnect ist, mehrere Transportverbindungen pro TCP-Verbindung oder Bereitstellungspunkte auf einem Client bereitzustellen. Diese Methode trägt zur Steigerung von Parallelität und Leistung für NFS-Einbindungen bei.

Je weniger Clients, desto mehr kann der Wert nconnect dazu beitragen, die Leistung zu steigern, da potenziell die gesamte verfügbare Netzwerkbandbreite genutzt werden kann. Der Wert nimmt allmählich ab, wenn die Anzahl der Clients zunimmt. Insgesamt steht nur eine bestimmte Bandbreite zur Verfügung, und die maximale Anzahl der TCP-Verbindungen kann schneller erschöpft sein, was zu einem Denial-of-Service führen kann, bis die TCP-Verbindungen freigegeben werden.

Da Azure NetApp Files maximal 128 gleichzeitige Anforderungen pro TCP-Verbindung zulässt, bevor es zu einer Drosselung kommt (bei der neue Anforderungen in die Warteschlange gestellt werden, bis Ressourcen verfügbar sind), kann nconnect dazu beitragen, die Anzahl der zulässigen Anforderungen zu erhöhen, indem die verfügbaren TCP-Verbindungen pro Bereitstellungspunkt erhöht werden. Wenn z. B. nconnect auf acht TCP-Verbindungen festgelegt ist, sind potenziell 1.024 (8x128) Anforderungen für den Client verfügbar.

Moderne Linux-Clients ermöglichen bis zu 65.535 Anforderungen pro Verbindung (ein dynamischer Wert). Dies kann dazu führen, dass die verfügbare Warteschlange für dynamische Anforderungen eines Azure NetApp Files-Volumes überläuft und unerwünschte Leistungsergebnisse erzielt werden, da die Clients mehr Anforderungen senden, als zu einem bestimmten Zeitpunkt bewältigen werden können. Um das Risiko für leistungsbedingte Auswirkungen aufgrund dieses Verhaltens zu verringern, sollten Sie sunrpc.tpc_max_slot_table_entries=256 oder 512 auf einen niedrigeren, statischen Wert festlegen, wenn Sie nconnect=8 oder 16 verwenden. Verwenden Sie die folgende Tabelle als Leitfaden.

Verwenden von NFSv3 anstelle von NFSv4.1 bei ausschließlicher Berücksichtigung der Leistung

NFSv3 ist ein zustandsloses Protokoll, d. h. Client und Server kommunizieren nicht miteinander über verwendete Dateien. Die Sperre erfolgt außerhalb des Protokollstapels durch den Network Lock Manager (NLM), was einige Herausforderungen mit sich bringt, wenn die Sperren verfallen und manuell gelöscht werden müssen. Sperren werden nur auf Anforderung durch die Anwendung eingerichtet, so dass es Szenarien geben kann, in denen Sperren nicht verhandelt werden müssen. Da es keine Client-IDs, Status-IDs, Sitzungs-IDs, Sperrzustände usw. gibt, die Sie im Auge behalten müssen, schneidet NFSv3 bei einigen Workloads tendenziell etwas besser ab als NFSv4.1 – insbesondere bei Workloads mit hoher Dateianzahl/hohem Metadatenanteil, wie z. B. EDA und Softwareentwicklung.

NFSv4.1 verfolgt den Status von Dateien, einschließlich Sperren, nach. Wenn in NFSv4.1 viele Dateien gleichzeitig verwendet werden, wird jeder Datei eine Status-ID zugewiesen und sie erhält eine Sperre. Durch die Zustandsabhängigkeit wird die Leistung des Workloads erhöht, da jeder Zustand und jede Sperre vom NFS-Server verarbeitet werden muss. Bei einigen Workloads (z. B. EDA) kann die Leistung von NFSv4.1 zwischen 25 und 75 % beeinträchtigt werden. Andere Workloads wie große Dateien, Streaming-E/A oder Datenbanken weisen bei der Verwendung von NFSv4.1 keine Leistungseinbußen auf und können sogar von den zusammengesetzten Vorgängen profitieren, die das Protokoll verwendet.

Azure NetApp Files unterstützt sowohl NFSv3 als auch NFSv4.1. Sie sollten überprüfen, welche Version Ihre Anwendung benötigt, indem Sie die Gemeinsamkeiten und Unterschiede zwischen den NFS-Versionen vergleichen (sowie Tests durchführen) und Ihr Volume unter Verwendung der entsprechenden Version erstellen. Falls erforderlich, können Azure NetApp Files Volumes nach der Erstellung auf eine andere Protokollversion konfiguriert werden.

Auswählen der geeigneten Größe der Einbindungsoptionen rsize und wsize

Die Einbindungsoptionen rsize (Lesegröße) und wsize (Schreibgröße) bestimmen, wie viele Daten für jedes gesendete Paket zwischen NFS-Client und Server gesendet werden. Das Festlegen von rsize oder wsize auf 65.536 bedeutet beispielsweise, dass bis zu 64 K Daten pro Paket gesendet werden können. Wenn eine Anwendung Daten in kleineren Blöcken (z. B. 8 K) sendet, hängt die Menge der gesendeten Daten von den verwendeten Bereitstellungsoptionen ab (z. B. sync).

Die Best Practice für Azure NetApp Files ist, für rsize und wsize den gleichen Wert festzulegen. Es wird allgemein empfohlen, dass Sie die Werte rsize und wsize jeweils in den Einbindungsoptionen als 262144 (256 K) festlegen.

Grundlegendes zu synchronen und asynchronen Bereitstellungsoptionen

Wenn sync verwendet wird, wird jeder Aufruf von WRITE mit einem FILE_SYNC-Befehl gesendet. Dies bedeutet, dass jedes WRITE vom Server bestätigt und auf den Datenträger festgelegt werden muss, bevor das nächste WRITE erfolgen kann. Sync wird verwendet, wenn eine Anwendung sicherstellen muss, dass alle Daten auf den Datenträger committet werden. Aufrufe von WRITE senden nur die Datenmenge, die durch die Blockgröße der Anwendung angegeben wird. Dies bedeutet, dass kleinere Blockgrößen unabhängig von den Werten wsize und rsize der Bereitstellung mehr NFS-Datenverkehr generieren, was zu Leistungseinbußen führt.

Wenn Sie den (Standard)-Bereitstellungsvorgang async verwenden, kann ein Client über NFS mehrere Aufrufe von WRITE mit dem Befehl UNSTABLE senden. In diesem Szenario werden die Daten auf dem Datenträger nach einer Zeitüberschreitung geleert. Da der NFS-Client nicht immer auf den Server wartet, um Daten auf den Datenträger zu übertragen, bevor der nächste WRITE gestartet wird, sind die Abschlusszeiten für Schreibvorgänge in asynchrone Bereitstellungen wesentlich niedriger als bei der Synchronisierung. Wenn kleinere Blockgrößen mit größeren rsize und wsize Werten verwendet werden, senden die WRITE Anrufe so viele Daten wie in einem einzelnen NFS-Aufruf zulässig. Wenn beispielsweise 8 K-Blockgrößen mit einem 64 K-wsize/rsize verwendet werden, sendet jeder NFS WRITE-Aufruf acht Blöcke pro Paket (64 K/8 K). Wenn der Schreibvorgang auf den Datenträger geleert wird, sendet der NFS-Server eine FILE_SYNC-Antwort an den NFS-Client zurück. Dadurch verringert sich die Gesamtzahl der Aufrufe von WRITE und der zugehörigen Antworten über ein Netzwerk, die zum Ausführen eines Auftrags erforderlich sind, wodurch die Leistung verbessert wird.

Bei einem Test, bei dem eine 1-GiB-Datei mit einer Blockgröße von 8 K erstellt wurde, wurden beispielsweise 262.144 WRITE-Aufrufe und Antworten generiert und in 70 Sekunden abgeschlossen, wenn die Bereitstellungsoption sync verwendet wurde. Bei der gleichen Dateierstellung mit einer Blockgröße von 8 K und der Bereitstellungsoption async wurden nur 16.384 WRITE-Aufrufe und -Antworten gesendet, die in sechs Sekunden abgeschlossen waren.

Azure NetApp Files nutzt batteriegestützten NVRAM-Speicher als Puffercache für eingehende NFS-Schreibvorgänge. Die Daten im NVRAM werden alle 10 Sekunden oder bis der Puffercache voll ist (je nachdem, was zuerst eintritt) auf die Festplatte geleert. Da der NVRAM durch eine Batterie betrieben wird, kann er unerwartete Ausfälle mindestens 72 Stunden lang überstehen und dabei Daten aufbewahren, z. B. im unwahrscheinlichen Fall eines Stromausfalls im Azure-Rechenzentrum. Durch die Kombination aus der Datenausfallsicherheit von Azure NetApp Files und den Leistungseinbußen bei der Verwendung der Bereitstellungsoption sync ist die asynchrone Übertragung in fast allen Anwendungsfällen die erste Wahl.

Verstehen der Auswirkungen von wsize- und rsize-Werten

Beim Einbinden über NFS bestimmen die Werte wsize und rsize, wie viele Daten pro NFS-Aufruf an einen NFS-Server gesendet werden können. Wenn in den Bereitstellungsoptionen keine Angaben gemacht werden, werden die Werte auf die Werte gesetzt, mit denen der NFS-Server konfiguriert wurde. Azure NetApp Files verwendet eine maximale Übertragungsgröße für wsize und rsize von 1 MB (1048576). Dieser Wert kann in Azure NetApp Files nicht geändert werden. Das heißt, wenn bei NFS-Bereitstellungen keine wsize- und rsize-Werte angegeben sind, werden die Bereitstellungen standardmäßig auf 1 MB festgelegt. Der empfohlene wsize- und rsize-Wert für NFS-Bereitstellungen in EDA-Workloads ist 256 K.

Wenn eine Anwendung eine 1-GiB-Datei auf einer Azure NetApp Files NFS-Bereitstellung erstellen muss, muss sie 1048.576 KiB in den Speicher schreiben. Eine mathematische Übung kann zeigen, warum sich die Leistung mit effizienteren wsize- oder rsize-Werten verbessern könnte.

• Wenn wsize auf 64 K festgelegt ist, beträgt die Anzahl der Vorgänge/Pakete, die zum Schreiben der 1-GiB-Datei erforderlich sind, 1048576/64 = 16384.
• Wenn wsize auf 256 K festgelegt ist, beträgt die Anzahl der Vorgänge/Pakete, die zum Schreiben der 1-GiB-Datei erforderlich sind, 1048576/256 = 4096.

Weniger Pakete/Vorgänge bedeuten eine geringere Netzwerklatenz (die sich auf die RTT auswirkt) und weniger Auswirkungen auf Workloads, was bei der Bereitstellung von Clouds entscheidend sein kann. Wenn die Anwendung jedoch Dateien schreibt, die kleiner sind als die wsize/rsize-Werte, dann haben die größeren wsize/rsize-Werte keine Auswirkungen auf die Leistung.

Größere Datenpakete bedeuten mehr Verarbeitungszyklen auf dem Client und dem Server, aber die meisten modernen CPUs sind ausreichend ausgestattet, um diese Anforderungen effizient zu verarbeiten.

Die Best Practice für Azure NetApp Files ist, für rsize und wsize den gleichen Wert festzulegen. Es wird empfohlen, in den Bereitstellungsoptionen sowohl den rsize- als auch den wsize-Wert auf 262144 (256 K) zu setzen. Diese Einstellung umfasst eine Reihe von Werten für die Lese- und Schreibgröße von Anwendungen.

Auswählen passender Einstellungen für die Einbindungsoptionen hard, soft und intr

Die Einbindungsoptionen hard und soft geben an, ob das Programm, das eine Datei nutzt, für die NFS genutzt wird, eine der folgenden Aktionen durchführen sollte:

• Es wird gestoppt und gewartet(hard), bis der Server wieder online ist, wenn der NFS-Server nicht verfügbar ist. Diese Option erscheint als Bereitstellungsoption auf dem Client, stellt aber sicher, dass laufende Vorgänge im Falle von Netzwerkausfällen nicht verloren gehen. Stattdessen versucht der Client die Anforderung so lange zu wiederholen, bis der Server verfügbar ist oder bis die Anwendung eine Zeitüberschreitung aufweist.
• Ein Fehler wird gemeldet (soft). Die Bereitstellungen bleiben nicht hängen, aber die laufenden Vorgänge können beeinträchtigt werden.

Die Bereitstellungsoption intr ermöglicht die Unterbrechung von NFS-Prozessen, wenn eine Einhängung als hard-Bereitstellung (z. B. CTRL+C) angegeben ist. Wir empfehlen die Verwendung von intr mit hard-Bereitstellungen, um die beste Kombination aus Datensicherheit und Verwaltbarkeit zu erreichen.

Keine Änderung von MTUs

Der Standardwert für MTUs (Maximum Transmission Units) für Azure-VMs beträgt 1.500 Byte. Kunden sollten die Anzahl der VM-MTUs für Jumboframes nicht erhöhen.

Einbindungsbeispiel

Im folgenden Beispielcode wird ein Azure NetApp Files-Volume mithilfe der zuvor genannten Best Practices für actimeo, nocto, NFSv3, nconnect, rsize, wsize, hard, intr, tcp und Standard-MTUs (1.500) eingebunden:

sudo mount -t nfs -o rw,nconnect=16,nocto,actimeo=600,hard,intr,rsize=262144,wsize=262144,vers=3,tcp 10.1.x.x:/ultravol ultravol