Linux-NFS-Bereitstellungsoptionen

Auf dieser Seite werden Linux-NFS-Mount-Optionen beschrieben, die sich auf die Leistung und das Verhalten beim Mounten von NetApp Volumes-Exporten auswirken. Sie legen diese Optionen fest, wenn Sie den Befehl mount ausführen oder sie /etc/fstab hinzufügen.

Die empfohlene Einrichtungsreihenfolge und Informationen dazu, wie sich Bereitstellungsoptionen auf die Kernel-Nebenläufigkeit und das Read-Ahead auswirken, finden Sie unter Linux-NFS-Clients optimieren.

Beispiele für Bereitstellungsbefehle und Exportzugriff finden Sie unter NFS-Clients verbinden.

Hinweis

Erfüllen Sie die folgenden Voraussetzungen, bevor Sie NetApp-Volumes einbinden:

  • Verwenden Sie den Mount-Befehl aus der Google Cloud Mount-Anleitung für die Konsole, sofern für Ihre Arbeitslast keine anderen Optionen erforderlich sind.

  • Wenn Sie die Nebenläufigkeit mit den Einstellungen für die Slot-Tabelle oder die Sitzungsslots optimieren, konfigurieren Sie diese Einstellungen vor der Bereitstellung. Weitere Informationen finden Sie unter Linux – NFS-Nebenläufigkeit.

  • Testen Sie alle Änderungen in einer Nicht-Produktionsumgebung. Die Auswirkungen von Mount-Optionen können je nach Arbeitslast, Linux-Version und Netzwerklatenz variieren.

Kurzreferenz

Die folgende Tabelle enthält eine Übersicht über gängige Mount-Optionen basierend auf Ihren Arbeitslastzielen:

Ziel Mögliche Optionen Hinweise
Für allgemeine Zwecke Google Cloud Anleitung zur Konsolenmontage verwenden Enthält protokollgerechte Standardwerte
Höherer Durchsatz oder mehr IOPS von einer VM nconnect=8 bis nconnect=16, tune rsize und wsize Stellen Sie zuerst die Slot-Tabelle ein. Weitere Informationen finden Sie unter Linux NFS-Concurrency.
Geringere Latenz für Datenbanken rsize=262144: wsize=262144, hard, timeo=600, vers=4.1 Für Ihre spezielle Anwendung testen
NFS-Version angeben vers=3 oder vers=4.1 Unter Linux wird standardmäßig die höchste verfügbare Version gemountet.
NFSv3 ohne Advisory Locks vers=3, nolock Informationen zur Firewall und zum Lock Manager finden Sie unter NFS-Clients verbinden.
Kerberos NFSv4.1 sec=krb5, krb5i oder krb5p Nicht mit nconnect verwenden
Daten, die hauptsächlich gelesen werden, mit bekannten Kompromissen bei der Kohärenz nocto, actimeo= Erweitert; Cache-Verhalten muss bekannt sein

Geben Sie beim Bereitstellen von NFSv3 immer tcp an. Obwohl Linux standardmäßig TCP für NFS-Traffic verwendet, wird durch das explizite Hinzufügen von tcp sichergestellt, dass beim Mount-Vorgang TCP anstelle von UDP verwendet wird. Dies trägt dazu bei, die Leistung zu verbessern, wenn viele Systeme gleichzeitig versucht werden, einzubinden. Fügen Sie noatime ein, um die Anzahl der Metadatenvorgänge zu reduzieren.

Die folgenden Bereitstellungsprofile enthalten empfohlene Optionen basierend auf Ihren Leistungsanforderungen, Protokollversionen und der Clientgröße. Ersetzen Sie beim Ausführen dieser Befehle VOLUME_IP und /export_path durch die tatsächlichen Werte aus der Anleitung zum Einbinden in der Google Cloud Konsole.

Profil A: Standard (Konsole)

Führen Sie den in der Google Cloud -Konsole angegebenen Mount-Befehl ohne Änderungen aus.

Profil B: Leistungsorientiert (einzelner Linux-Client)

Beispiel für NFSv3, das an die Testkonfiguration für Leistungsbenchmarks angepasst ist:

 sudo mount -t nfs -o hard,tcp,vers=3,rsize=262144,wsize=262144,nconnect=16 \
 VOLUME_IP:/export_path /mnt/volume

Benchmarks verwenden nconnect=16 und 64 KiB rsize und wsize. Viele Arbeitslasten funktionieren gut mit nconnect=8. Testen Sie beide Werte.

Profil C: NFSv4.1 mit expliziter Version

 sudo mount -t nfs -o vers=4.1,hard,rsize=262144,wsize=262144 \
 VOLUME_IP:/export_path /mnt/volume

Wenn Sie verhindern möchten, dass NFSv4.2 automatisch bereitgestellt wird, wenn es für das Volume aktiviert ist, geben Sie vers=4.1 an. Weitere Informationen finden Sie unter NFS-Clients verbinden.

Profil D: NFSv3 für Compute-Farmen

Wenn Sie eine große Anzahl von Clients mit einem Volume verbinden (z. B. Hunderte), verwenden Sie nicht nconnect, um zu verhindern, dass die verfügbaren TCP-Sitzungen auf dem Volume erschöpft werden.

 sudo mount -t nfs -o vers=3,nolock,hard,tcp,rsize=262144,wsize=262144 \
 VOLUME_IP:/export_path /mnt/volume

In /etc/fstab beibehalten

Das folgende Beispiel zeigt eine /etc/fstab-Zeile für NFSv4.1:

 VOLUME_IP:/export_path  /mnt/volume  nfs  vers=4.1,hard,tcp,rsize=262144,wsize=262144,timeo=600,_netdev  0  0

Verwenden Sie die Option _netdev, damit das System vor dem Mounten auf die Netzwerkverbindung wartet.

nconnect

Mit der Bereitstellungsoption nconnect können Sie die Anzahl der TCP-Verbindungen steuern, die der NFS-Client zum selben Speicherendpunkt, also zur IP-Adresse des Volumes, öffnet. Über jede Verbindung können mehrere NFS-Vorgänge gleichzeitig ausgeführt werden, bis zu einem festgelegten Limit. Durch Erhöhen der Anzahl der Verbindungen werden die E/A-Nebenläufigkeit und der Durchsatz eines einzelnen Clients verbessert.

Empfehlungen

Beachten Sie beim Konfigurieren der Bereitstellungsoption nconnect die folgenden Empfehlungen:

  • Testen Sie nconnect=8 und nconnect=16. Es werden Werte bis zu 16 unterstützt.

  • Verwenden Sie nconnect nur für dedizierte leistungsstarke Clients. Wenn viele Clients, z. B. eine Compute-Farm, eine Verbindung zum selben Speicher herstellen, sollten Sie nconnect nicht verwenden.

  • Führen Sie den ersten Mount-Vorgang für eine bestimmte Volume-IP aus, um den nconnect-Wert für diese IP auf diesem Client festzulegen. Spätere Mounts auf dieselbe IP-Adresse verwenden denselben Wert, auch wenn ein anderer angegeben wird. Hängen Sie den Export zuerst mit dem ausgewählten nconnect-Wert ein oder verwenden Sie für alle Mounts für diese IP dieselbe Option.

  • Wenn Sie nconnect für eine Volume-IP festlegen, hat das keine Auswirkungen auf die Einbindung in eine andere Volume-IP.

  • Prüfen Sie, ob Ihre Linux-Distribution nconnect unterstützt, bevor Sie es verwenden.

Weitere Informationen zu Slotlimits pro Verbindung finden Sie unter Linux NFS-Concurrency.

rsize und wsize

Mit den Mount-Optionen rsize und wsize wird die maximale Übertragungsgröße für NFS-Lese- und ‑Schreibvorgänge festgelegt. Wenn Sie sie weglassen, handeln Client und Server die größte Größe aus, die beide unterstützen. Das sind bis zu 1 MiB auf Linux-Clients und NetApp-Volumes.

Empfehlungen

Beachten Sie beim Konfigurieren der Bereitstellungsoptionen rsize und wsize die folgenden Empfehlungen:

  • Testen Sie rsize=262144 und wsize=262144 (256 KiB), um Durchsatz und Latenz für latenzempfindliche Anwendungen zu optimieren.

  • Verwenden Sie Werte über 256 KiB mit Vorsicht, da sie die Latenz erhöhen oder den Durchsatz für einige Arbeitslasten verringern können. Messen Sie die Leistung vor der Bereitstellung.

  • Verwenden Sie rsize=65536 und wsize=65536 (64 KiB) für NFSv3-Tests, da diese Werte in Leistungsbenchmarks verwendet wurden.

Diese Einstellungen haben nur minimale Auswirkungen auf zufällige Arbeitslasten, bei denen in der Regel kleinere Vorgangsgrößen als rsize und wsize verwendet werden. Bei sequenziellen E/A-Vorgängen über den Seitencache werden häufig Vorgangsgrößen von bis zu rsize und wsize verwendet.

Die Bereitstellungsoption rsize wirkt sich auf das Read-Ahead-Verhalten aus. Weitere Informationen finden Sie unter Linux NFS read-ahead.

Protokollversion

In der folgenden Tabelle sind die vers-Optionswerte und die entsprechenden Protokollversionen aufgeführt:

Option Verwenden
vers=3 NFSv3
vers=4.1 NFSv4.1
vers=4.2 NFSv4.2

Wenn Sie vers nicht festlegen, verwendet der Linux-Befehl mount die höchste NFS-Version, die vom Client und Volume unterstützt wird. Flex Unified-, Standard-, Premium- und Extreme-Volumes mit aktiviertem NFSv4.1 unterstützen auch NFSv4.2. Sie können NFSv4.2 bereitstellen, sofern Sie vers=4.1 nicht angeben.

Weitere Informationen zur NFSv4.1-Identitätszuordnung, zu Kerberos und zu numerischen IDs finden Sie unter NFS-Clients verbinden.

hard, timeo und retrans

Die Bereitstellungsoptionen hard, timeo und retrans steuern das Clientverhalten und die Logik für Zeitüberschreitungsversuche bei Verbindungsproblemen:

  • hard: Wiederholt NFS-Anfragen, bis sie erfolgreich sind. Diese Option ist typisch für die Datenintegrität bei Produktionsarbeitslasten.

  • timeo: gibt das Zeitlimit in Zehntelsekunden an, bevor eine Anfrage noch einmal versucht wird. Datenbankorientierte Arbeitslasten verwenden häufig timeo=600 (60 Sekunden).

  • retrans: Gibt die Anzahl der Wiederholungen an.Die Standardwerte der Google Cloud console sind in der Regel ausreichend, sofern in Ihren Runbooks nichts anderes angegeben ist.

NFSv3-Option „nolock“

Für die beratende Sperrung in NFSv3 wird der Network Lock Manager (NLM) verwendet. Dazu sind clientseitige rpc.statd- und Firewallregeln für Callback-Ports erforderlich. Wenn Sie keine beratenden Sperren verwenden, können Sie die Einbindung mit nolock vornehmen, um Lock Manager-Traffic zu vermeiden.

NFSv4.1 implementiert die Sperrung im Protokoll auf Port 2049. Clients benötigen keine separaten Ingress-Regeln für den Lock Manager.

Weitere Informationen zur Verwendung von Advisory Locks mit NFSv3 und zu Firewallregeln für den Zugriff auf NFS-Volumes finden Sie unter NFS-Clients verbinden.

Cache und Konsistenz mit „nocto“ und „actimeo“

Der NFS-Client verwendet ein lockeres Konsistenzmodell. Attribute-Cache-Timer bestimmen, wie lange der Client Datei- und Verzeichnis-Metadaten vertraut, bevor er den Server kontaktiert. Die Standardeinstellung „Close-to-Open Consistency“ (cto) aktualisiert Dateidaten, wenn Sie eine Datei öffnen.

  • nocto: Der Client erzwingt beim Öffnen keine Serverkonsistenz. Dadurch werden weniger getattr-Aufrufe ausgeführt, aber das Risiko veralteter Daten steigt.

  • actimeo=N: Konfiguriert alle Attribute-Cache-Timer auf N Sekunden (acregmin, acregmax, acdirmin und acdirmax).

In den folgenden Szenarien sollten Sie nocto und höhere actimeo-Werte verwenden:

  • Ein einzelner Writer oder schreibgeschützte Consumer, die Updates über einen anderen Pfad erhalten.

  • Große statische Datasets wie EDA-Bibliotheken, Webinhalte oder Render-Texturen, wenn eine kurze Veralterung akzeptabel ist.

Verwenden Sie in den meisten Fällen die empfohlenen Linux-Standardeinstellungen für das Attribut-Caching:

  • Mindest- und Höchstwerte für reguläre Dateien: acregmin=3 Sekunden und acregmax=60 Sekunden

  • Mindest- und Höchstdauer von Verzeichnissen: acdirmin=30 Sekunden und acdirmax=60 Sekunden

Wenn Sie diese Werte verringern, erhöht sich die Last auf dem NFS-Server und die Leistung kann abnehmen. Vermeiden Sie actimeo=0, außer in sehr spezifischen Anwendungsfällen, in denen Sie die Auswirkungen kennen.

Weitere gängige Optionen

Für NFS-Clients sind die folgenden weiteren gängigen Mount-Optionen verfügbar:

  • rw oder ro: Bereitstellung mit Lese-/Schreibzugriff oder schreibgeschützt.

  • noatime: Die Zugriffszeit wird beim Lesen nicht aktualisiert, da dies die Anzahl der Metadatenvorgänge verringert und eine empfohlene Vorgehensweise ist.

  • sec=sys: AUTH_SYS, das ist die Standardeinstellung für Exporte, die nicht auf Kerberos basieren.

  • _netdev: Verwenden Sie dies in fstab, um das Laufwerk bereitzustellen, nachdem das Netzwerk verfügbar ist.

Nächste Schritte