OneFS: Best Practices für NFS-Clienteinstellungen

Unterstützte Protokollversionen

Zu diesem Zeitpunkt unterstützt PowerScale OneFS die NFS-Versionen 3 und 4. NFS Version 2 wird nicht unterstützt.

NFSv3

NFS-Version 3 ist die derzeit am häufigsten verwendete Version des NFS-Protokolls und wird im Allgemeinen als die umfassendste Client- und Filer-Variante betrachtet. Hier sind die Kernkomponenten dieser Version:

• Statuslos – Ein Client stellt technisch keine neue Sitzung her, wenn er über die richtigen Informationen verfügt, um nach Dateien zu fragen usw. Dies ermöglicht ein einfaches Failover zwischen OneFS-Nodes mit dynamischen IP-Pools.
• Nutzer- und Gruppeninformationen werden numerisch dargestellt: Client und Server kommunizieren Nutzerinformationen durch numerische Kennungen, sodass derselbe Nutzer möglicherweise mit unterschiedlichen Namen zwischen Client und Server angezeigt werden kann.
• File Locking wird out of band ausgeführt: Version 3 von NFS verwendet ein Hilfsprotokoll namens NLM, um Sperren durchzuführen. Dies erfordert, dass der Client auf RPC-Meldungen vom Server reagiert, um zu bestätigen, dass Sperren gewährt wurden usw.
• Kann über TCP oder UDP ausgeführt werden: Diese Version des Protokolls kann über UDP anstelle von TCP ausgeführt werden, sodass die Handhabung von Verlust und erneuter Übertragung von der Software anstelle des Betriebssystems vorgenommen wird. Wir empfehlen immer die Verwendung von TCP.

NFSv4

NFS Version 4 ist die neueste Hauptversion des NFS-Protokolls und wird immer mehr eingesetzt. Aktuell ist NFSv4 aufgrund der größeren Anzahl an Identitätszuordnungen und für die Antwort erforderlichen Sitzungsnachverfolgungsaufgaben in der Regel langsamer als v3 im selben Workflow. Hier sind einige der wichtigsten Unterschiede zwischen v3 und v4.

• Zustandsbehaftet: NFSv4 verwendet Sitzungen, um die Kommunikation zu verarbeiten. Daher müssen Client und Server den Sitzungsstatus nachverfolgen, um mit der Kommunikation fortzufahren.
  • Vor OneFS 8.X erforderten NFSv4-Clients statische IP-Pools auf dem PowerScale oder es traten Probleme auf.
• Nutzer- und Gruppeninformationen werden als Zeichenfolgen dargestellt: Sowohl der Client als auch der Server müssen die Namen der gespeicherten numerischen Informationen auflösen. Der Server muss nach Namen suchen, um diese anzugeben, während der Client seinerseits diese den Zahlen neu zuordnen muss.
• File Locking wird in band ausgeführt: Version 4 verwendet kein separates Protokoll mehr für das File Locking, sondern macht es zu einer Art von Aufruf, der in der Regel mit OPEN, CREATE oder WRITE kombiniert wird.
• Zusammengesetzte Aufrufe: Version 4 kann eine Reihe von Anrufen in einem einzigen Paket bündeln, sodass der Server sie alle verarbeiten und am Ende antworten kann. Dies wird verwendet, um die Anzahl der Aufrufe zu reduzieren, die an gängigen Vorgängen beteiligt sind.
• Unterstützt nur TCP: Version 4 von NFS überlässt Verlust und Erneute Übertragung dem zugrunde liegenden Betriebssystem.

NFSv4.1 und darüber hinaus

NFSv4.1 und v4.2 sind ab OneFS Version 9.3 verfügbar.

Hier sind die offiziellen Versionsinformationen für 9.3:

https://dl.dell.com/content/docu105998_powerscale-onefs-9-3-0-0-release-notes.pdf?language=en_us
 

Einhängeoptionen

Es gibt zwar keine strikten Anforderungen an Einhängeoptionen, aber einige Empfehlungen zu Client-Verbindung. Es gibt keine spezifischen Einhängezeichenfolgen, da die Syntax, die zum Definieren dieser Optionen verwendet wird, je nach verwendeten Betriebssystem variiert. Sie müssen die Dokumentation für Verteilungs-Maintainer für eine bestimmte Mount-Syntax aufbewahren.

Definition von Wiederholungen und Timeouts

Während PowerScale in der Regel sehr schnell auf die Clientkommunikation antwortet, kann es in Fällen, in denen ein Node keine Stromversorgung oder Netzwerkverbindung mehr hat, einige Sekunden dauern, bis seine IP-Adressen zu einem funktionsfähigen Node verschoben wurden. Daher ist es wichtig, die Werte für „timeout“ und „retry“ korrekt definiert zu haben. PowerScale empfiehlt in der Regel ein Timeout von 60 Sekunden, um ein Worst-Case-Failover-Szenario zu berücksichtigen, und zwei Wiederholungen vor dem Melden eines Fehlers.

Flexibles und striktes Einhängen

Striktes Einhängen führt dazu, dass der Client seine Vorgänge auf unbestimmte Zeit bei Timeout oder Fehler wiederholt. Dadurch wird sichergestellt, dass der Client das Einhängen nicht unterbricht, wenn der PowerScale Cluster IP-Adressen von einem Node auf einen anderen verschiebt. Bei einem flexiblen Einhängen wird ein Fehler ausgegeben und das Einhängen läuft ab, sodass ein erneutes Einhängen erforderlich ist, um den Zugriff wiederherzustellen, nachdem die IP-Adresse verschoben wurde.

Interrupt zulassen

Standardmäßig erlauben die meisten Clients nicht, eine I/O-Wartezeit (Eingabe/Ausgabe) zu unterbrechen, d. h. Sie können nicht ctrl+c usw. verwenden, um den Wartevorgang zu beenden, wenn das Cluster nicht mehr reagiert, einschließlich der Einhängeoption interrupt, sodass diese Signale stattdessen normal übertragen werden können.

Lokaler Vergleich mit Remote-Sperrung

Beim Einhängen eines NFS-Exports können Sie angeben, ob ein Like die Sperre lokal durchführt oder den Sperrkoordinator auf dem Cluster verwendet. Die meisten Clients verwenden standardmäßig Remote-Sperren. Dies ist in der Regel die beste Option, wenn mehrere Clients auf dasselbe Verzeichnis zugreifen. Es kann jedoch Leistungsvorteile durch das lokale Durchführen von Sperren geben, wenn ein Client keinen gemeinsamen Zugriff auf das Verzeichnis benötigt, mit dem er arbeitet. Darüber hinaus fordern einige Datenbanken und Software die Verwendung von lokalen Sperren, da sie einen eigenen Koordinator haben.