Nebenläufigkeit von Linux-NFS

Auf dieser Seite wird beschrieben, wie Sie die Linux-NFS-Client-Nebenläufigkeit für NetApp Volumes optimieren.

Concurrency ist die Anzahl der ausstehenden NFS-Vorgänge zwischen einem Client und dem Volume zu einem bestimmten Zeitpunkt. Durch das Optimieren der Concurrency können Sie den Client an die Serverlimits anpassen und Leistungseinbußen durch eine zu hohe Warteschlangentiefe vermeiden.

Unter Linux wird die Concurrency nicht über Mount-Optionen, sondern über Slot-Tabelleneinträge (NFSv3) oder NFSv4.1-Sitzungsslots gesteuert. Konfigurieren Sie diese Einstellungen, bevor Sie NFS-Dateisysteme bereitstellen oder nach einer Änderung neu bereitstellen.

Informationen zu Mount-Optionen wie nconnect finden Sie unter Linux-NFS-Mount-Optionen. Weitere Informationen zur Konfigurationsreihenfolge finden Sie unter Linux-NFS-Clients optimieren.

Terminologie

Die folgenden wichtigen Begriffe beziehen sich auf die Linux-NFS-Nebenläufigkeit:

  • RPC-Slot-Tabelle: Limit pro TCP-Verbindung für ausstehende NFS-RPC-Vorgänge auf dem Client (NFSv3).

  • Sitzungsslots: NFSv4.1-Limit für ausstehende Befehle, die für eine Sitzung zwischen dem Client und dem Server ausgehandelt wurden.

  • Speicherendpunkt: Eine einzelne Volume-IP-Adresse, die von Clients bereitgestellt wird.

  • nconnect: Eine Mount-Option, mit der mehrere TCP-Verbindungen zum selben Endpunkt geöffnet werden. Sie multipliziert die Concurrency pro Verbindung.

Linux-Parameter

In der folgenden Tabelle sind die Parameter und Konfigurationsdateien aufgeführt, die zum Konfigurieren der NFS-Nebenläufigkeit für die einzelnen Protokollversionen verwendet werden:

Protokoll Parameter Konfiguration
NFSv3 sunrpc.tcp_max_slot_table_entries /etc/sysctl.conf, sysctl -p
NFSv3 sunrpc.tcp_slot_table_entries Einige Distributionen; siehe Dokumentation Ihrer Distribution
NFSv4.1 max_session_slots /etc/modprobe.d/ (z. B. nfsclient.conf), Neustart

NFSv3

In den folgenden Abschnitten werden die NFSv3-Client- und Serverlimits beschrieben, wie sich nconnect auf die Concurrency auswirkt, wie Sie die Concurrency-Anforderungen schätzen und wie Sie Slot-Limits konfigurieren.

Client- und Serverlimits

Bei NFSv3 wird die Concurrency nicht zwischen Client und Server ausgehandelt. Jede Seite wendet ihr eigenes Limit an.

  • NetApp Volumes-NFSv3-Server: Bis zu 128 Ausführungskontexte pro TCP-Verbindung.

  • Moderner Linux-Client (Standard): sunrpc.tcp_max_slot_table_entries = 65536.

Eine Standardanzahl von Client-Slots, die das Serverlimit überschreitet, ist nicht erforderlich. Wenn der Client mehr ausstehende Vorgänge sendet, als der Server effizient verarbeiten kann, kann der Server das TCP-Fenster verkleinern, was sich auf die Leistung auswirkt.

Empfehlung: Legen Sie für sunrpc.tcp_max_slot_table_entries 128 oder weniger pro Verbindung fest. In Umgebungen mit vielen Clients und Verbindungen sollte die Gesamtzahl der ausstehenden Slots pro Speicherendpunkt 10.000 nicht überschreiten.

Auswirkungen von „nconnect“ auf die NFSv3-Concurrency

Die ungefähre maximale Concurrency für einen Client wird so berechnet:

(sunrpc.tcp_max_slot_table_entries per connection) × (nconnect value)

Der Concurrency-Wert ist pro Verbindung durch den Server (128) und durch die Anforderungen Ihrer Arbeitslast begrenzt.

Beispiel 1: Standard-Slots, kein „nconnect“

  • Eine TCP-Verbindung.

  • Der Client kann bis zu 65.536 ausstehende Vorgänge versuchen, aber der Server akzeptiert nur bis zu 128 pro Verbindung.

  • Die effektive Concurrency ist durch das Serverlimit von 128 begrenzt.

Beispiel 2: 128 Slots, kein „nconnect“

  • sunrpc.tcp_max_slot_table_entries=128

  • Eine Verbindung.

  • Client und Server sind auf 128 ausstehende Vorgänge abgestimmt.

Beispiel 3: 100 Slots, „nconnect“ = 8

  • Acht TCP-Verbindungen.

  • Bis zu 100 ausstehende Vorgänge pro Verbindung.

  • Bis zu 800 ausstehende Vorgänge von einem Client (8 × 100), vorbehaltlich des Serverlimits von 128 pro Verbindung.

Beispiel 4: Viele Clients (EDA-Stil)

  • 250 Clients, jeweils mit sunrpc.tcp_max_slot_table_entries=8 und ohne nconnect.

  • Jeder Client hat bis zu acht ausstehende Vorgänge pro Verbindung.

  • Insgesamt über alle Clients hinweg: bis zu 2.000 ausstehende Vorgänge für eine Volume-IP (250 × 8), was innerhalb der Richtlinie für 10.000 Slots pro Endpunkt liegt.

Wenn Sie Clients horizontal skalieren, verwenden Sie niedrigere Slot-Werte pro Client. Verwenden Sie nconnect nur für einzelne Clients mit hohem Durchsatz und nicht als Ersatz für die farmweite Slot-Planung.

Erforderliche Concurrency mit dem Gesetz von Little schätzen

Verwenden Sie die folgende Formel, um die für Ihre Arbeitslast erforderliche Concurrency zu schätzen:

Concurrency = (Vorgangsrate) × (Latenz in Sekunden)

Beispiel: Viele Clients, ein Endpunkt

Ziel sind 4.000 MiB/s mit durchschnittlich 256 KiB E/A und einer Latenz von 10 ms:

  • Vorgangsrate: ca. 16.000 IOPS.

  • Concurrency: ca. 16.000 × 0,010 = 160.

  • Bei 1.250 Clients: 160 / 1.250 = ca. 0,13 Slots pro Client,wenn gleichmäßig aufgeteilt. Verwenden Sie eine kleine Ganzzahl pro Client, z. B. 2, 4 oder 8, um unter dem Limit von 10.000 Slots zu bleiben.

„sunrpc.tcp_max_slot_table_entries“ festlegen (NFSv3)

In vielen Linux-Distributionen wird systemd-sysctl ausgeführt, bevor das sunrpc-Kernelmodul geladen wird. Einträge in /etc/sysctl.conf oder /etc/sysctl.d/ für sunrpc.* werden beim Booten ignoriert. Die Ausführung von sysctl -p nach dem Booten funktioniert nur bis zum nächsten Neustart, wenn Sie keine der folgenden Methoden zur Persistenz verwenden.

Methode 1: Wenn Tests zeigen, dass ein Wert unter 128 ausreicht, verwenden Sie diesen Wert. Legen Sie für tcp_slot_table_entries und tcp_max_slot_table_entries denselben Wert fest, sofern in der Dokumentation Ihrer Distribution nichts anderes angegeben ist.

Stellen Sie NFS-Dateisysteme bereit oder stellen Sie sie neu bereit, nachdem Sie diese Einstellungen geändert haben. Slot-Einstellungen gelten für RPC-Transports, die nach dem Inkrafttreten der Einstellung erstellt werden.

Methode 2 (empfohlen): Moduloptionen in /etc/modprobe.d/

Modulparameter werden angewendet, wenn sunrpc bei der ersten NFS-Verwendung nach dem Booten geladen wird. Diese Einstellungen bleiben auch nach Neustarts erhalten, sodass keine sysctl-Konfiguration beim Booten erforderlich ist.

  1. Erstellen Sie /etc/modprobe.d/sunrpc.conf:

    options sunrpc tcp_slot_table_entries=128 tcp_max_slot_table_entries=128
    
  2. Erstellen Sie die initramfs neu, wenn dies nach Änderungen an modprobe für Ihre Distribution erforderlich ist. Das ist bei RHEL häufig der Fall, wenn sich das Modul in der initramfs befindet. Weitere Informationen finden Sie in der Dokumentation Ihres Linux-Anbieters.

  3. Starten Sie neu oder entladen und laden Sie sunrpc nur neu, wenn Sie keine aktiven NFS-Bereitstellungen haben und Ihr Runbook dies zulässt.

  4. Prüfen Sie, ob sunrpc geladen ist und die gewünschten Werte festgelegt sind:

    cat /proc/sys/sunrpc/tcp_slot_table_entries
    cat /proc/sys/sunrpc/tcp_max_slot_table_entries
    
  5. Stellen Sie die NetApp Volumes-Exporte bereit oder stellen Sie sie neu bereit.

NFSv4.1

In den folgenden Abschnitten wird beschrieben, wie die NFSv4.1-Sitzungsverhandlung funktioniert, Beispiele für die Leistungsoptimierung gegeben und erklärt, wie Sie Limits für Sitzungsslots konfigurieren.

Sitzungsverhandlung

Bei NFSv4.1 werden Sitzungen zwischen dem Client und dem Server eingerichtet. Client und Server verhandeln die maximale Anzahl ausstehender Befehle (max_reqs), indem sie den niedrigeren der beiden unterstützten Werte auswählen.

  • NetApp Volumes-NFSv4.1-Server: 180 Befehle pro Sitzung.

  • Linux-Client-Standard: 64 (max_session_slots).

  • Ausgehandelte Sitzung: Das Minimum der Client- und Serverwerte, das beim Standard-Client oft 64 beträgt.

Jede TCP-Verbindung zum Server unterstützt bis zu 128 ausstehende NFS-Befehle. Bei der Standardeinstellung von 64 Sitzungsslots und einer einzelnen Verbindung ist die Concurrency auf 64 begrenzt. Wenn Sie mehr Sitzungsslots über Verbindungen hinweg verwenden möchten, verwenden Sie nconnect=2 oder höher nur für Nicht-Kerberos-Bereitstellungen. Weitere Informationen zu Mount-Optionen finden Sie unter Linux-NFS-Mount-Optionen.

Beispiel 1: Standardmäßig 64 Sitzungsslots, kein „nconnect“

  • Eine Verbindung.

  • Bis zu 64 ausstehende Befehle für die Sitzung.

Beispiel 2: 64 Sitzungsslots, „nconnect“ = 2

  • Die Sitzung ist weiterhin auf insgesamt 64 Slots begrenzt, die auf zwei Verbindungen aufgeteilt sind, also ca. 32 pro Verbindung.

  • Diese Konfiguration verbessert die Latenz, indem die Warteschlangentiefe pro Verbindung verringert wird, ohne die Gesamt-Concurrency zu erhöhen.

Beispiel 3: max_session_slots=180, kein „nconnect“

  • Die Sitzung lässt 180 Befehle zu und eine Verbindung ist auf 128 ausstehende Vorgänge begrenzt.

  • Das effektive Limit beträgt 128.

Beispiel 4: max_session_slots=180, „nconnect“ = 2

  • Die Sitzung kann bis zu 180 Befehle über zwei Verbindungen hinweg verwenden, also ca. 90 pro Verbindung.

  • Diese Konfiguration ist erforderlich, um das Limit von 128 für eine einzelne Verbindung auf Sitzungsebene zu überschreiten.

Um die maximale NFSv4.1-Nebenläufigkeit für NetApp Volumes ohne Kerberos zu erreichen, legen Sie max_session_slots=180 fest und verwenden Sie nconnect=2 oder höher. Testen Sie diese Konfiguration mit Ihrer Arbeitslast.

Maximale Sitzungsslots für NFSv4.1 festlegen

  1. Erstellen Sie /etc/modprobe.d/nfsclient.conf:

    options nfs max_session_slots=180
    
  2. Starten Sie den Client neu.

  3. Prüfen Sie die Konfiguration, nachdem mindestens eine NFSv4.1-Bereitstellung vorhanden ist:

    systool -v -m nfs
    
  4. Prüfen Sie, ob max_session_slots in der Ausgabe angezeigt wird.

Diese Änderungen erfordern einen Neustart bei der Standardverpackung des Linux-NFS-Clients. Planen Sie die Wartung entsprechend.

Volumes mit mehreren Clients und großer Kapazität

  • Mehrere VMs, eine Volume-IP: Reduzieren Sie sunrpc.tcp_max_slot_table_entries pro Client.

  • Volumes mit großer Kapazität und mehreren IPs: Slot-Limits gelten pro Client-zu-IP-Verbindung. Verteilen Sie Clients nach Möglichkeit auf mehrere Endpunkte. Weitere Informationen finden Sie unter Volumes mit großer Kapazität mit mehreren Speicherendpunkten verbinden.

Nächste Schritte