OneFS: Best Practices für NFS-Clienteinstellungen (Network File System)

Unterstützte Protokollversionen

PowerScale OneFS unterstützt derzeit die NFS-Versionen 3 und 4 (Network File System). NFS Version 2 wird nicht unterstützt.

NFSv3

NFS Version 3 ist die derzeit am weitesten verbreitete Version des NFS-Protokolls und gilt als die umfassendste Client- und Filer-Variante. Hier sind einige 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.
• 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. Dell Technologies empfiehlt immer die Verwendung von TCP.

NFSv4

NFS Version 4 ist die neueste Hauptversion des NFS-Protokolls und wird immer mehr eingesetzt.  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 erfolgt in Band: Version 4 verwendet kein separates Protokoll mehr für das Sperren von Dateien, sondern macht es zu einer Art von Aufruf, der mit OPENs, 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:

PowerScale OneFS Info Hubs
 

Einhängeoptionen

Dell Technologies stellt zwar keine festen Anforderungen an Mount-Optionen, dennoch gibt Dell Technologies einige Empfehlungen für die Verbindungsweise von Clients. Dell Technologies hat keine spezifischen Mount-Zeichenfolgen bereitgestellt, da die Syntax, die zum Definieren dieser Optionen verwendet wird, je nach verwendetem Betriebssystem variiert. Sie müssen sich an die Dokumentation der Distributionsbetreuer halten, um eine bestimmte Einhängesyntax zu erhalten.

Der PowerScale-Support empfiehlt außerdem das folgende Whitepaper als primäre Referenz für die NFS-Clientkonfiguration mit PowerScale, einschließlich der empfohlenen Optionen für wsize/rize, Attribut-Caching und mehr:

Überlegungen und Best Practices
für das NFS-Design von PowerScale OneFShttps://infohub.delltechnologies.com/en-us/t/powerscale-onefs-nfs-design-considerations-and-best-practices-3/

Lese- und Schreibgröße (rsize / wsize)

In Bezug auf die "wsize/rsize"-Optionen empfiehlt der PowerScale-Support "wsize" und "rsize" von mindestens 128 KB, basierend auf unserer nativen Blockgröße.

Für die meisten modernen Linux-Distributionen empfiehlt der PowerScale-Support jedoch, eine Einstellung nicht explizit zu konfigurieren (d. h. keine Lese-/Schreibgröße in den Client-Mount-Optionen anzugeben) und die Tunings vom Client neu verhandeln zu lassen. Moderne Linux-Distributionen unterstützen NFS-Lese-/Schreibblockgrößen von bis zu 1 MB und verhandeln automatisch die optimale Blockgröße mit dem PowerScale-NFS-Server. Die ausgehandelten Werte sind ideal für die am besten konfigurierten Hochleistungsnetzwerke mit niedriger Latenz. Die Ausnahme wäre, es sei denn, Sie haben eine Anwendung oder einen Anbieter, der speziell die kleinere Größe erfordert.

Wenn dies nicht explizit festgelegt ist, verwendet der NFS-Client die FSINFO-Daten des PowerScale-NFS-Servers, wie im auf dem PowerScale-Cluster konfigurierten NFS-Export definiert.

PowerScale bietet die folgenden Standardeinstellungen:

NFSv3: 512KB writes / 1MB reads
NFSv4: 1MB writes/ 1MB reads

Ausführlichere Informationen zu "rsize" und "wsize" finden Sie auf den Seiten 12 und 19 des folgenden Whitepapers:

Überlegungen und Best Practices
für das NFS-Design von PowerScale OneFShttps://infohub.delltechnologies.com/en-us/t/powerscale-onefs-nfs-design-considerations-and-best-practices-3/ 

Definition von Wiederholungen und Timeouts

Während PowerScale in der Regel schnell auf Clientkommunikation reagiert, kann es in Fällen, in denen ein Node die Stromversorgung oder Netzwerkverbindung verloren hat, einige Sekunden dauern, bis seine IP-Adressen auf einen funktionsfähigen Node verschoben werden. Daher ist es wichtig, korrekt definierte Timeout- und Wiederholungswerte zu haben. PowerScale empfiehlt in der Regel ein Timeout von 60 Sekunden, um ein Worst-Case-Failover-Szenario zu berücksichtigen, und zwei Wiederholungsversuche, bevor ein Fehler gemeldet wird.

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 ist es bei den meisten Clients nicht möglich, eine Eingabe-/Ausgangs- oder I/O-Wartezeit zu unterbrechen, d. h., Sie können keine ctrl+c , um den Warteprozess zu beenden, wenn das Cluster nicht mehr reagiert, einschließlich der interrupt mount-Option können diese Signale stattdessen normal passieren.

Lokale vs. Remote-Sperrung

Beim Mounten eines NFS-Exports können Sie angeben, ob ein Client seine Sperren lokal oder mithilfe des Sperrkoordinators auf dem Cluster erzeugt. Die meisten Clients verwenden standardmäßig eine Remotesperre. Dies ist in der Regel die beste Option, wenn mehrere Clients auf dasselbe Verzeichnis zugreifen. Es kann jedoch Leistungsvorteile bei der Durchführung einer lokalen Sperre geben, wenn ein Client den Zugriff auf das Verzeichnis, mit dem er arbeitet, nicht gemeinsam nutzen muss. Darüber hinaus fordern einige Datenbanken und Software die Verwendung lokaler Sperren an, da sie über einen eigenen Koordinator verfügen.

Zwischenspeichern von Attributen (ac/noac)

In Bezug auf "aktive Cache-Timeouts" wird dies als clientseitiges Verhalten betrachtet. Daher gibt der PowerScale-Support keine Empfehlungen zu diesen Einstellungen, da dies von Ihren Anforderungen abhängt. Kunden finden jedoch auf Seite 22 des folgenden Whitepapers einige allgemeine Anleitungen zu diesen Einstellungen:

Überlegungen und Best Practices
für das NFS-Design von PowerScale OneFShttps://infohub.delltechnologies.com/en-us/t/powerscale-onefs-nfs-design-considerations-and-best-practices-3/ 

Pro Seite 22 von oben:

Zwischenspeichern von Attributen (ac/noac)

Verwenden Sie die noac-Mount-Option, um die Attributcachekohärenz zwischen mehreren Clients zu erreichen. Bei fast jedem Dateisystemvorgang werden Dateiattributinformationen geprüft. Der Client speichert diese Informationen für einen bestimmten Zeitraum, um die Netzwerk- und Serverlast zu reduzieren. Wenn noac wirksam ist, wird der Dateiattributcache eines Clients deaktiviert, sodass jeder Vorgang, der die Attribute einer Datei überprüfen muss, gezwungen ist, zurück zum Server zu gehen. Außerdem erzwingt die noac-Option, dass die Schreibvorgänge von Anwendungen synchron werden, sodass ein Client Änderungen an einer Datei beim Öffnen sieht, was jedoch viele zusätzliche Netzwerkvorgänge verursacht. Standardmäßig ist das Attribut-Caching beim Mounten des NFS aktiviert. Aktivieren Sie die Zwischenspeicherung von Attributen, um die Performance der Attributprüfung zu verbessern und die Latenz des NFS-Vorgangs zu reduzieren.

Performance von NFSv3 im Vergleich zu NFSv4

Basierend auf Labortests hat der PowerScale-Support keine erkennbaren Leistungsunterschiede zwischen verschiedenen Versionen von NFS in den neuesten, unterstützten Versionen von OneFS gefunden. 

Um die wsize/rsize-Werte eines bestimmten NFS-Exports anzuzeigen, können Sie die folgenden Befehle auf einem beliebigen PowerScale-Node ausführen:

# isi nfs exports ls -v  --zone <zone name>

 Um nach einer bestimmten Export-ID zu suchen, können Kunden auch Folgendes ausführen:

# isi nfs export view <export id>

 Beispiel:

Read Transfer Max Size: 1.00M
     Read Transfer Size: 128.00k
Write Transfer Max Size: 1.00M
 Write Transfer Size: 512.00k