Einbindungsoptionen für NFS unter Linux: bewährte Methoden für Azure NetApp Files

Dieser Artikel enthält Informationen zum besseren Verständnis von Einbindungsoptionen sowie bewährte Methoden für deren Verwendung mit Azure NetApp Files.

Nconnect

Verwenden Sie die nconnect Mount-Option, um die Anzahl der Verbindungen (Netzwerkflüsse) zwischen dem NFS-Client und dem NFS-Endpunkt mit maximal 16 anzugeben. In der Regel verwendet ein NFS-Client eine einzelne Verbindung zwischen sich selbst und dem Endpunkt. Eine Erhöhung der Anzahl der Netzwerkflüsse erhöht die oberen Grenzen von I/O und Durchsatz erheblich. Um die optimale Einstellung für Ihre spezifische Umgebung für nconnect zu finden, testen Sie, wenn möglich, verschiedene Einstellungen, bevor Sie Ihre Anwendung in Produktion bringen. In den meisten Umgebungen ist nconnect=4das optimale Ergebnis .

Wenn Sie eine SAS-GRID-Umgebung mit mehreren Knoten für die Produktion vorbereiten, können Sie eine wiederholbare Verkürzung der Laufzeit um 30  %feststellen, von 8 Stunden auf 5,5 Stunden:

Einbindungsoption Ausführungszeiten von Jobs
Ohne nconnect 8 Stunden
nconnect=8 5,5 Stunden

Bei beiden Testreihen wurden der gleiche virtuelle Computer (E32-8_v4) und RHEL 8.3 verwendet, wobei Read-Ahead auf 15 MiB festgelegt war.

Beachten Sie bei Verwenden von nconnect die folgenden Regeln:

  • nconnect wird von Azure NetApp Files für alle wichtigen Linux-Distributionen unterstützt, allerdings nur für neuere Releases:

    Linux-Release NFSv3 (Mindestversion) NFSv4.1 (Mindestrelease)
    Red Hat Enterprise Linux RHEL8.3 RHEL 8.3
    SUSE SLES 12 SP4 oder SLES 15 SP1 SLES15SP2
    Ubuntu Ubuntu18.04

    Hinweis

    SLES15SP2 ist das SUSE-Mindestrelease, in dem nconnect von Azure NetApp Files für NFSv4.1 unterstützt wird. Alle anderen aufgeführten Releases sind die ersten Releases, die das Feature nconnect eingeführt haben.

  • Alle Einbindungen über einen einzelnen Endpunkt übernehmen die nconnect-Einstellung des ersten eingebundenen Exports, wie in den folgenden Szenarien gezeigt:

    Szenario 1: nconnect wird vom ersten Mount verwendet. Daher verwenden alle Einbindungen gegen denselben Endpunkt nconnect=8.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.10.10.10:/volume2 /mnt/volume2
    • mount 10.10.10.10:/volume3 /mnt/volume3

    Szenario 2: nconnect wird nicht von der ersten Einbindung verwendet. Daher verwenden keine Einbindungen über denselben Endpunkt nconnect, obwohl nconnect darauf angegeben sein kann.

    • mount 10.10.10.10:/volume1 /mnt/volume1
    • mount 10.10.10.10:/volume2 /mnt/volume2 -o nconnect=8
    • mount 10.10.10.10:/volume3 /mnt/volume3 -o nconnect=8

    Szenario 3: nconnect-Einstellungen werden nicht über separate Speicherendpunkte weitergegeben. nconnect wird von dem Mount verwendet, der von 10.10.10.10 kommt, aber nicht von dem Mount, der von 10.12.12.12 kommt.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.12.12.12:/volume2 /mnt/volume2

  • nconnect kann verwendet werden, um die Speicherkonkurrenz von einem beliebigen Client zu erhöhen.

Weitere Informationen finden Sie unter Bewährte Methoden für die Nebenläufigkeit unter Linux für Azure NetApp Files.

Nconnect-Überlegungen

Es wird nicht empfohlen, die Einbindungsoptionen nconnect und sec=krb5* gemeinsam zu verwenden. Die Verwendung dieser Optionen kann zu Leistungsbeeinträchtigungen führen.

Die GSS-API (Generic Security Standard Application Programming Interface) bietet Anwendungen eine Möglichkeit zum Schutz von Daten, die an Peeranwendungen gesendet werden. Diese Daten könnten von einem Client auf einem Computer an einen Server auf einem anderen Computer gesendet werden. 

Bei Verwendung von nconnect unter Linux wird der GSS-Sicherheitskontext zwischen allen nconnect-Verbindungen mit einem bestimmten Server gemeinsam genutzt. TCP ist ein zuverlässiger Transport, der ein Gleitfenster von Sequenznummern verwendet, um Pakete in falscher Reihenfolge in einem GSS-Stream zu behandeln. Wenn Pakete empfangen werden, die sich nicht im Sequenzfenster befinden, wird der Sicherheitskontext verworfen, und ein neuer Sicherheitskontext wird ausgehandelt. Alle Nachrichten, die in dem nun verworfenen Kontext gesendet wurden, sind nicht mehr gültig, weshalb die Nachrichten erneut gesendet werden müssen. Eine größere Anzahl von Paketen in einer nconnect-Konfiguration führt zu häufigen Paketen außerhalb des Fensters, wodurch das beschriebene Verhalten ausgelöst wird. Für dieses Verhalten können keine spezifischen Beeinträchtigungsprozentsätze angegeben werden.

Rsize und Wsize

Die Beispiele in diesem Abschnitt geben Aufschluss über die Vorgehensweise bei der Leistungsoptimierung. Möglicherweise müssen Sie Anpassungen vornehmen, um Ihren spezifischen Anwendungsanforderungen gerecht zu werden.

Die Flags rsize und wsize legen die maximale Übertragungsgröße eines NFS-Vorgangs fest. Wenn rsize oder wsize beim Einbinden nicht angegeben werden, handeln Client und Server die größte von Client und Server unterstützte Größe aus. Derzeit unterstützen sowohl Azure NetApp Files als auch moderne Linux-Distributionen Lese- und Schreibgrößen von bis zu 1.048.576 Bytes (1 MiB). Zur Optimierung von Gesamtdurchsatz und Latenz empfiehlt Azure NetApp Files jedoch, sowohl rsize als auch wsize auf nicht mehr als 262.144 Bytes (256 KiB) festzulegen. Sie werden feststellen, dass sowohl die Latenz steigt als auch der Durchsatz sinkt, wenn rsize und wsize auf mehr als 256 KiB festgelegt sind.

Zum Beispiel zeigt Bereitstellen eines Systems für horizontale SAP HANA-Skalierung mit Standbyknoten auf Azure-VMs mithilfe von Azure NetApp Files unter SUSE Linux Enterprise Server den Höchstwert von 256 KiB für rsize und wsize wie folgt:

sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001  nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-shared/shared /hana/shared  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0

Für SAS Viya wird beispielsweise eine Lese- und Schreibgröße von 256 KiB empfohlen. SAS GRID beschränkt die r/wsize Lese- und Schreibgrößen auf 64 KiB, während die Leseleistung durch Erhöhen von Read-Ahead für die NFS-Einbindungen verbessert wird. Ausführliche Informationen finden Sie unter Bewährte Methoden für NFS-Read-Ahead für Azure NetApp Files.

Die folgenden Überlegungen gelten für die Verwendung von rsize und wsize:

  • Zufällige E/A-Vorgangsgrößen sind häufig kleiner als die Werte der Einbindungsoptionen rsize und wsize. Daher sind sie keine Einschränkungen.
  • Bei Verwendung des Dateisystemcaches erfolgen sequenzielle E/A-Vorgänge mit der durch die Einbindungsoptionen rsize und wsize vorgegebenen Größe, es sei denn, die Dateigröße ist kleiner als rsize und wsize.
  • Vorgänge, die den Dateisystemcache umgehen, sind, obwohl sie immer noch durch die Einbindungsoptionen rsize und wsize eingeschränkt sind, nicht so groß wie der durch rsize oder wsize angegebene Höchstwert. Dieser Aspekt ist wichtig, wenn Sie Workload-Generatoren einsetzen, die über die Option directio verfügen.

Als bewährte Methode für Azure NetApp Files sollten Sie zur Optimierung von Gesamtdurchsatz und Latenz rsize und wsize nicht größer als auf 262.144 Bytes festlegen.

Close-to-Open-Konsistenz und Cacheattributtimer

NFS verwendet ein loses Konsistenzmodell. Die Konsistenz ist weniger streng, da die Anwendung nicht jedes Mal auf den gemeinsamen Speicher zugreifen und Daten abrufen muss, um sie zu verwenden – ein Szenario, das enorme Auswirkungen auf die Anwendungsleistung haben würde. Es gibt zwei Mechanismen zum Verwalten dieses Prozesses: Cacheattributtimer und Close-to-Open-Konsistenz.

Wenn der Client vollständige Datenhoheit über die Daten hat, d. h. sie nicht von mehreren Knoten oder Systemen gemeinsam genutzt werden, ist Konsistenz gewährleistet. In diesem Fall können Sie die getattr-Zugriffsvorgänge auf das Speichersystem reduzieren und die Anwendung beschleunigen, indem Sie Close-to-Open-Konsistenz (cto) deaktivieren (nocto als Einbindungsoption) und die Timeouts für die Verwaltung des Attributcaches erhöhen (actimeo=600 als Einbindungsoption ändert den Zeitgeber auf 10 Minuten gegenüber den Standardeinstellungen acregmin=3,acregmax=30,acdirmin=30,acdirmax=60). Bei einigen Tests reduziert nocto etwa 65-70 % der getattr-Zugriffsaufrufe, und die Anpassung von actimeo reduziert diese Aufrufe um weitere 20-25 %.

Funktionsweise von Attributcachetimern

Die Attribute acregmin, acregmax, acdirmin und acdirmax steuern die Kohärenz des Caches. Die ersten beiden Attribute steuern, wie lange die Attribute von Dateien als vertrauenswürdig eingestuft werden. Die beiden letztgenannten Attribute steuern, wie lange die Attribute des Verzeichnisses selbst vertrauenswürdig sind (Größe, Besitz und Berechtigungen von Verzeichnissen). Die Attribute min und max definieren die Mindest- bzw. Höchstdauer, für die die Attribute eines Verzeichnisses, die Attribute einer Datei sowie der Cacheinhalt einer Datei als vertrauenswürdig gelten. Zwischen min und max wird ein Algorithmus verwendet, um die Zeitspanne zu definieren, für die einem Eintrag im Cache vertraut wird.

Betrachten Sie zum Beispiel die Standardwerte für acregmin und acregmax, 3 bzw. 30 Sekunden. Die Attribute werden z. B. für die Dateien in einem Verzeichnis wiederholt ausgewertet. Nach 3 Sekunden wird der NFS-Dienst auf Aktualität abgefragt. Wenn die Attribute als gültig erachtet werden, verdoppelt der Client die vertrauenswürdige Zeitspanne auf 6 Sekunden, 12 Sekunden, 24 Sekunden und dann, da das Maximum auf 30 gesetzt ist, auf 30 Sekunden. Von diesem Zeitpunkt an, bis die zwischengespeicherten Attribute als veraltet gelten (dann beginnt der Zyklus von vorne), ist die Vertrauenswürdigkeit als 30 Sekunden definiert, wobei 30 Sekunden dem von acregmax angegebenen Wert entsprechen.

Es gibt andere Fälle, die von ähnlichen Einbindungsoptionen profitieren können, auch wenn die Clients nicht die vollständige Eigentümerschaft haben, z. B. wenn die Clients die Daten schreibgeschützt nutzen und die Datenaktualisierung über einen anderen Pfad verwaltet wird. Bei Anwendungen, die Client-Grids verwenden, wie z. B. EDA, Webhosting und Filmrendering, und relativ statische Datensätze haben (EDA-Tools oder -Bibliotheken, Webinhalte, Texturdaten), ist das typische Verhalten, dass der Datensatz weitgehend auf den Clients zwischengespeichert wird. Es gibt nur wenige Lese- und keine Schreibvorgänge. Zahlreiche getattr- und Zugriffsaufrufe werden an den Speicher zurückgegeben. Diese Datasets werden in der Regel durch einen anderen Client aktualisiert, der die Dateisysteme einbindet und Inhaltsupdates in regelmäßigen Abständen per Push überträgt.

In diesen Fällen gibt es eine bekannte Verzögerung bei der Erfassung neuer Inhalte, weshalb die Anwendung möglicherweise mit veralteten Daten arbeitet. In diesen Fällen können nocto und actimeo angegeben werden, um die Zeitspanne zu steuern, in der ein abgelaufenes Datum verwaltet werden kann. Bei EDA-Tools und -Bibliotheken beispielsweise funktioniert actimeo=600 gut, da diese Daten in der Regel nur selten aktualisiert werden. Für das Hosting kleiner Websites, bei dem Kunden ihre Datenaktualisierungen zeitnah sehen müssen, während sie ihre Websites bearbeiten, dürfte actimeo=10 akzeptabel sein. Für große Websites, deren Inhalte per Push in mehrere Dateisysteme übertragen werden, kann actimeo=60 akzeptabel sein.

Durch die Verwendung dieser Mount-Optionen wird die Workload für den Speicher in diesen Fällen erheblich reduziert. (Beispielsweise wurden bei einem kürzlich durchgeführten EDA-Test die IOPs für das Tool-Volume von 150 K auf ca. 6 K reduziert.) Anwendungen können erheblich schneller ausgeführt werden, da sie den Daten im Arbeitsspeicher vertrauen können. (Die Zugriffszeit auf den Arbeitsspeicher beträgt Nanosekunden im Vergleich zu Hunderten von Mikrosekunden pro getattr-Zugriff in einem schnellen Netzwerk.)

Close-to-open-Konsistenz

Close-to-Open-Konsistenz (die Einbindungsoption cto) stellt sicher, dass der Anwendung beim Öffnen einer Datei unabhängig vom Zustand des Caches stets die neuesten Daten für diese Datei präsentiert werden.

  • Wenn ein Verzeichnis durchforstet wird (z. B. ls, ls -l), wird ein bestimmter Satz von Remoteprozeduraufrufen (RPC) abgesetzt. Der NFS-Server gibt seine Sicht auf das Dateisystem frei. Solange cto von allen NFS-Clients verwendet wird, die auf einen bestimmten NFS-Export zugreifen, sehen alle Clients dieselbe Liste der darin enthaltenen Dateien und Verzeichnisse. Die Aktualität der Attribute der Dateien im Verzeichnis wird durch die Attributcachetimer gesteuert. Das heißt, solange cto verwendet wird, sind Dateien für entfernte Clients sichtbar, sobald die Datei erstellt wurde und auf dem Storage geschrieben ist.
  • Wenn eine Datei geöffnet wird, ist der Inhalt der Datei aus Sicht des NFS-Servers garantiert aktuell. Wenn eine Race Condition vorliegt, bei der der Inhalt von Computer 1 noch nicht vollständig auf den Server geschrieben wurde, sobald eine Datei auf Computer 2 geöffnet wird, erhält Computer 2 nur die Daten, die zum Zeitpunkt des Öffnens auf dem Server vorhanden sind. In diesem Fall ruft Computer 2 keine weiteren Daten aus der Datei ab, bis der acreg-Timer abläuft und Computer 2 die Kohärenz seines Caches erneut mit dem Server abgleicht. Dieses Szenario kann auf Computer 2 mithilfe von tail -f beobachtet werden, wenn auf Computer 1 weiter in die Datei geschrieben wird.

Keine Konsistenz zwischen Schließen und Öffnen

Ohne Close-to-Open-Konsistenz (nocto) vertraut der Client auf die Aktualität seiner aktuellen Sicht auf Datei und Verzeichnis, bis die Zeitgeber für Cache-Attribute abgelaufen sind.

  • Wenn ein Verzeichnis durchforstet wird (z. B. ls, ls -l), wird ein bestimmter Satz von Remoteprozeduraufrufen (RPC) abgesetzt. Der Client sendet nur dann eine Anfrage an den Server für eine aktuelle Auflistung der Dateien, wenn der Zeitgeberwert acdir des Caches überschritten wurde. In diesem Fall werden zuletzt erstellte Dateien und Verzeichnisse nicht angezeigt. Zuletzt entfernte Dateien und Verzeichnisse erscheinen durchaus.

  • Beim Öffnen einer Datei wird, solange sich die Datei noch im Cache befindet, ihr zwischengespeicherter Inhalt (falls vorhanden) zurückgegeben, ohne auf Konsistenz mit dem NFS-Server zu prüfen.

Nächste Schritte

  • Zuletzt aktualisiert um