Behandeln von Problemen mit der NAS-Konfiguration und dem NFS-Speicherziel

  • Artikel

Dieser Artikel enthält Lösungen für einige häufige Konfigurationsfehler und andere Probleme, die verhindern können, dass Azure HPC Cache ein NFS-Speichersystem als Speicherziel hinzufügt.

Dieser Artikel enthält Details zum Überprüfen von Ports und Aktivieren des benötigten Zugriffs auf ein NAS-System. Er enthält außerdem ausführliche Informationen zu weniger häufigen Problemen, durch die beim Erstellen des NFS-Speicherziels Fehler auftreten können.

Tipp

Informieren Sie sich vor der Verwendung dieses Leitfadens über die Voraussetzungen für NFS-Speicherziele.

Wenn die Lösung für Ihr Problem hier nicht enthalten ist, öffnen Sie ein Supportticket, damit Microsoft Service and Support mit Ihnen zusammen das Problem untersuchen und beheben kann.

Bereitstellen ausreichender Verbindungsthreads

Große HPC Cache-Systeme stellen mehrere Verbindungsanforderungen an ein Speicherziel. Wenn Ihr Speicherziel beispielsweise das Ubuntu Linux-Modul nfs-kernel-server verwendet, kann die Standardanzahl der NFS-Daemonthreads so niedrig wie acht sein. Erhöhen Sie die Anzahl der Threads auf 128 oder 256, was sinnvollere Werte sind, um ein mittelgroßes oder großes HPC Cache-System zu unterstützen.

Sie können die Anzahl der Threads in Ubuntu mithilfe des RPCNFSDCOUNT-Werts in /etc/init.d/nfs-kernel-server überprüfen oder festlegen.

Überprüfen der Porteinstellungen

Azure HPC Cache benötigt Lese-/Schreibzugriff auf mehrere UDP/TCP-Ports auf dem Back-End-NAS-Speichersystem. Stellen Sie sicher, dass auf diese Ports auf dem NAS-System zugegriffen werden kann und dass der Datenverkehr für diese Ports durch alle Firewalls zwischen dem Speichersystem und dem Cachesubnetz zugelassen wird. Sie müssen möglicherweise mit Firewall- und Netzwerkadministratoren für Ihr Rechenzentrum zusammenarbeiten, um diese Konfiguration zu überprüfen.

Die Ports für Speichersysteme verschiedener Anbieter sind jeweils unterschiedlich. Überprüfen Sie daher die Anforderungen Ihres Systems beim Einrichten eines Speicherziels.

Im Allgemeinen benötigt der Cache Zugriff auf die folgenden Ports:

Protokoll Port Service
TCP/UDP 111 rpcbind
TCP/UDP 2049 NFS
TCP/UDP 4045 nlockmgr
TCP/UDP 4046 mountd
TCP/UDP 4047 status

Verwenden Sie den folgenden rpcinfo-Befehl, um Angaben zu den für Ihr System benötigten Ports zu erhalten. Mit dem Befehl unten werden die Ports aufgelistet und die relevanten Ergebnisse in einer Tabelle formatiert. (Ersetzen Sie den Platzhalter <storage_IP> durch die IP-Adresse Ihres Systems.)

Dieser Befehl kann über einen beliebigen Linux-Client mit installierter NFS-Infrastruktur ausgeführt werden. Wenn Sie einen Client innerhalb des Clustersubnetzes verwenden, können Sie damit auch die Konnektivität zwischen dem Subnetz und dem Speichersystem überprüfen.

rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t

Stellen Sie sicher, dass alle von der rpcinfo-Abfrage zurückgegebenen Ports uneingeschränkten Datenverkehr aus dem Azure HPC Cache-Subnetz zulassen.

Überprüfen Sie diese Einstellungen im NAS und auch auf allen Firewalls zwischen dem Speichersystem und dem Cachesubnetz.

Überprüfen der Root-Squash-Einstellungen

Die Root-Squash-Einstellungen können den Zugriff auf Dateien beeinträchtigen, wenn sie nicht ordnungsgemäß konfiguriert sind. Stellen Sie sicher, dass Sie geeignete Einstellungen für jeden Speicherexport und entsprechende HPC Cache-Clientzugriffsrichtlinien verwenden.

Durch Root-Squash wird verhindert, dass Anforderungen, die von einem lokalen Superuser-Stamm auf dem Client gesendet werden, als Stamm an ein Back-End-Speichersystem gesendet werden. Anforderungen werden vom Stamm an eine nicht privilegierten Benutzer-ID (UID) neu zugewiesen, z. B. „niemand“.

Tipp

Bei früheren Versionen von Azure HPC Cache waren NAS-Speichersysteme erforderlich, um den Stammzugriff über den HPC Cache zu ermöglichen. Nun müssen Sie den Stammzugriff auf einen Speicherzielexport nicht erlauben, es sei denn, Sie möchten, dass HPC Cache-Clients Stammzugriff auf den Export haben.

Root-Squash kann an folgenden Stellen in einem HPC Cache System konfiguriert werden:

  • Im Azure HPC Cache – Anhand von Clientzugriffsrichtlinien können Sie Root-Squash für Clients konfigurieren, die bestimmten Filterregeln entsprechen. Eine Clientzugriffsrichtlinie ist Teil jedes Namespacepfads eines NFS-Speicherziels.

    Bei der Standard-Clientzugriffsrichtlinie sind Squash-Root-Vorgänge nicht möglich.

  • Im Speicherexport – Sie können Ihr Speichersystem so konfigurieren, dass eingehende Anforderungen vom Stamm an eine nicht privilegierte Benutzer-ID (UID) neu zugewiesen werden.

Wenn Squash-Root-Vorgänge in Ihrem Speichersystemexport möglich sind, sollten Sie die HPC Cache-Clientzugriffsregel für dieses Speicherziel so aktualisieren, dass sie auch Squash-Root-Vorgänge durchführt. Wenn nicht, haben Sie möglicherweise Zugriffsprobleme, wenn Sie versuchen, das Back-End-Speichersystem über den HPC Cache zu lesen oder zu schreiben.

In dieser Tabelle wird das Verhalten verschiedener Root-Squash-Szenarien veranschaulicht, wenn eine Clientanforderung als UID 0 (Stamm) gesendet wird. Das mit * gekennzeichnete Szenario wird nicht empfohlen, da es Zugriffsprobleme verursachen kann.

Einstellung Vom Client gesendete UID Von HPC Cache gesendete UID Gültige UID im Back-End-Speicher
Kein Root-Squash 0 (Root) 0 (Root) 0 (Root)
Root-Squash nur bei HPC Cache 0 (Root) 65534 (niemand) 65534 (niemand)
*Root-Squash nur bei NAS-Speicher 0 (Root) 0 (Root) 65534 (niemand)
Root-Squash bei HPC Cache und NAS 0 (Root) 65534 (niemand) 65534 (niemand)

(Die UID 65534 dient als Beispiel. Wenn Sie Root-Squash in einer Clientzugriffsrichtlinie aktivieren, können Sie die UID anpassen.)

Überprüfen des Zugriffs auf Verzeichnispfade

Überprüfen Sie bei NAS-Systemen, die hierarchische Verzeichnisse exportieren, ob Azure HPC Cache über den entsprechenden Zugriff auf jede Exportebene im Pfad zu den verwendeten Dateien verfügt.

Ein System könnte beispielsweise drei Exporte wie die folgenden anzeigen:

  • /ifs
  • /ifs/accounting
  • /ifs/accounting/payroll

Der Export /ifs/accounting/payroll ist ein untergeordnetes Element von /ifs/accounting, und /ifs/accounting ist selbst ein untergeordnetes Element von /ifs.

Wenn Sie den payroll-Export als ein HPC Cache-Speicherziel hinzufügen, stellt der Cache tatsächlich /ifs/ bereit und greift von dort aus auf das payroll-Verzeichnis zu. Daher benötigt Azure HPC Cache ausreichende Berechtigungen für den Zugriff auf /ifs, um auf den /ifs/accounting/payroll-Export zuzugreifen.

Diese Anforderung steht im Bezug zu der Methode, mit der der Cache Dateien indiziert und Dateikonflikte vermeidet, wobei vom Speichersystem bereitstellte Dateihandles verwendet werden.

Ein NAS-System mit hierarchischen Exporten kann verschiedene Dateihandles für dieselbe Datei zur Verfügung stellen, wenn die Datei aus verschiedenen Exporten abgerufen wird. Beispielsweise kann ein Client /ifs/accounting bereitstellen und auf die Datei payroll/2011.txt zugreifen. Ein anderer Client stellt /ifs/accounting/payroll bereit und greift auf die Datei 2011.txt zu. Je nachdem, wie das Speichersystem Dateihandles zuweist, können diese beiden Clients die gleiche Datei mit unterschiedlichen Dateihandles (eines für <mount2>/payroll/2011.txt und eines für <mount3>/2011.txt) erhalten.

Das Back-End-Speichersystem speichert interne Aliase für Dateihandles, aber Azure HPC Cache kann nicht erkennen, welche Dateihandles im Index auf dasselbe Element verweisen. Daher ist es möglich, dass im Cache verschiedene Schreibvorgänge für dieselbe Datei zwischengespeichert sind und die Änderungen falsch angewendet werden, da nicht bekannt ist, dass es sich um dieselbe Datei handelt.

Um diesen möglichen Konflikt bei Dateien in mehreren Exporten zu vermeiden, stellt Azure HPC Cache automatisch den niedrigsten verfügbaren Export im Pfad bereit (/ifs im Beispiel) und verwendet das von diesem Export bereitgestellte Dateihandle. Wenn mehrere Exporte denselben Basispfad verwenden, benötigt Azure HPC Cache Zugriff auf diesen Pfad.

Anpassen der Größenbeschränkungen für VPN-Pakete

Wenn zwischen dem Cache und dem NAS-Gerät ein VPN vorhanden ist, kann es sein, dass 1500-Byte-Ethernet-Pakete in voller Größe vom VPN blockiert werden. Dieses Problem liegt möglicherweise vor, wenn große Austauschvorgänge zwischen NAS und der Azure HPC Cache-Instanz nicht beendet werden, kleinere Updates jedoch erwartungsgemäß funktionieren.

Es gibt keine einfache Möglichkeit, um festzustellen, ob Ihr System dieses Problem aufweist, es sei denn, Sie kennen die Details Ihrer VPN-Konfiguration. Nachfolgend sind einige Methoden aufgeführt, die Ihnen bei der Überprüfung dieses Problems helfen können.

  • Verwenden Sie Paketsniffer auf beiden Seiten des VPN, um zu ermitteln, welche Pakete erfolgreich übertragen werden.

  • Wenn Ihr VPN Ping-Befehle zulässt, können Sie das Senden eines Pakets in voller Größe testen.

    Führen Sie einen Ping-Befehl über das VPN an den NAS mit den folgenden Optionen aus. (Ersetzen Sie den Wert <storage_IP> durch die IP-Adresse Ihres Speichersystems.)

    ping -M do -s 1472 -c 1 <storage_IP>

    Diese Optionen werden im Befehl verwendet:

    • -M do: Nicht fragmentieren
    • -c 1: Nur ein Paket senden
    • -s 1472: Größe der Nutzlast auf 1472 Bytes festlegen. Dies ist die maximale Größe der Nutzlast für ein 1500-Byte-Paket nach Berücksichtigung des Ethernet-Aufwands.

    Eine erfolgreiche Antwort sieht wie folgt aus:

    PING 10.54.54.11 (10.54.54.11) 1472(1500) bytes of data.
1480 bytes from 10.54.54.11: icmp_seq=1 ttl=64 time=2.06 ms

    Wenn das Ping-Signal mit 1472 Bytes fehlschlägt, liegt wahrscheinlich ein Problem mit der Paketgröße vor.

Um dieses Problem zu beheben, müssen Sie möglicherweise MSS-Clamping für das VPN konfigurieren, damit das Remotesystem die maximale Framegröße ordnungsgemäß erkennt. Weitere Informationen finden Sie in der Dokumentation zu IPSec-/IKE-Parametern für VPN-Gateways.

In einigen Fällen kann es hilfreich sein, die MTU-Einstellung für Azure HPC Cache in 1400 zu ändern. Wenn Sie jedoch die MTU für den Cache einschränken, müssen Sie auch die MTU-Einstellungen für Clients und Back-End-Speichersysteme einschränken, die mit dem Cache interagieren. Weitere Informationen finden Sie Konfigurieren zusätzlicher Azure HPC Cache-Einstellungen.

Prüfen auf ACL-Sicherheitsstil

Einige NAS-Systeme verwenden einen Hybridsicherheitsstil, bei dem Zugriffssteuerungslisten (ACLs) mit herkömmlicher POSIX- oder UNIX-Sicherheit kombiniert werden.

Wenn Ihr System den Sicherheitsstil als UNIX oder POSIX ohne das Akronym „ACL“ angibt, sind Sie von diesem Problem nicht betroffen.

Bei Systemen, die ACLs verwenden, muss Azure HPC Cache zusätzliche benutzerspezifische Werte nachverfolgen, um den Dateizugriff zu steuern. Dies erfolgt durch Aktivieren eines Zugriffscaches. Es gibt benutzerseitig keine Möglichkeit, den Zugriffscache zu aktivieren, aber Sie können ein Supportticket öffnen, um die Aktivierung für die betroffenen Speicherziele auf Ihrem Cachesystem anzufordern.

Nächste Schritte

Wenn Sie ein Problem haben, das in diesem Artikel nicht behandelt wurde, kontaktieren Sie den Support, um Hilfe von Experten zu bekommen.