Behebung von Problemen mit der NAS-Konfiguration und NFS-Speicherzielen

Dieser Artikel bietet 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 zum Aktivieren des erforderlichen Zugriffs auf ein NAS-System. Es enthält auch detaillierte Informationen zu weniger häufig auftretenden Problemen, die dazu führen können, dass die Erstellung von NFS-Speicherzielen fehlschlägt.

Wenn die Lösung für Ihr Problem hier nicht enthalten ist, öffnen Sie bitte ein Supportticket , damit Der Microsoft-Dienst und -Support mit Ihnen zusammenarbeiten können, um das Problem zu untersuchen und zu lösen.

Bereitstellen ausreichender Verbindungsthreads

Große HPC-Cachesysteme stellen mehrere Verbindungsanforderungen an ein Speicherziel vor. Wenn Ihr Speicherziel beispielsweise das Ubuntu Linux-Modul nfs-kernel-server verwendet, kann die Standardanzahl von NFS-Daemon-Threads so niedrig wie acht sein. Erhöhen Sie die Anzahl der Threads auf 128 oder 256, die vernünftigere Zahlen sind, um einen mittleren oder großen HPC-Cache zu unterstützen.

Sie können die Anzahl der Threads in Ubuntu durch den RPCNFSDCOUNT-Wert 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 im Back-End-NAS-Speichersystem. Stellen Sie sicher, dass auf diese Ports im NAS-System zugegriffen werden kann und dass der Datenverkehr für diese Ports über alle Firewalls zwischen dem Speichersystem und dem Cachesubnetz zulässig ist. Möglicherweise müssen Sie mit Firewall- und Netzwerkadministratoren für Ihr Rechenzentrum arbeiten, um diese Konfiguration zu überprüfen.

Die Ports unterscheiden sich für Speichersysteme von verschiedenen Anbietern. Überprüfen Sie daher die Anforderungen Ihres Systems beim Einrichten eines Speicherziels.

Im Allgemeinen benötigt der Cache Zugriff auf diese Ports:

Um die spezifischen Ports zu erfahren, die für Ihr System erforderlich sind, verwenden Sie den folgenden rpcinfo Befehl. Dieser Befehl unten listet die Ports auf und formatiert die relevanten Ergebnisse in einer Tabelle. (Verwenden Sie die IP-Adresse Ihres Systems anstelle des <storage_IP> Begriffs.)

Sie können diesen Befehl von jedem Linux-Client aus ausgeben, auf dem DIE NFS-Infrastruktur installiert ist. Wenn Sie einen Client innerhalb des Clustersubnetz verwenden, kann er 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 Subnetz des Azure HPC-Caches zulassen.

Überprüfen Sie diese Einstellungen sowohl auf dem NAS selbst als auch auf allen Firewalls zwischen dem Speichersystem und dem Cache-Subnetz.

"Einstellungen für Root Squash überprüfen"

Stammeinstellungen können den Dateizugriff unterbrechen, wenn sie nicht ordnungsgemäß konfiguriert sind. Überprüfen Sie, ob die Einstellungen für jeden Speicherexport und für die entsprechenden HPC Cache-Clientzugriffsrichtlinien geeignet sind.

Root Squash verhindert, dass Anforderungen, die von einem lokalen Superuser root auf dem Client gesendet werden, als root an ein Back-End-Speichersystem gesendet werden. Anfragen werden vom Root-Benutzer zu einer nicht privilegierten Benutzer-ID (UID) wie 'nobody' umgeleitet.

Root-Squash kann in einem HPC-Cache-System an diesen Punkten konfiguriert werden:

• Im Azure HPC-Cache verwenden Sie Clientzugriffsrichtlinien, um Root-Squash für Clients zu konfigurieren, die bestimmten Filterregeln entsprechen. Eine Clientzugriffsrichtlinie ist Teil jedes NFS-Speicherziel-Namespacepfads.

  Die standardmäßige Clientzugriffsrichtlinie squasht nicht Root-Zugriff.

• Beim Speicherexport – Sie können Ihr Speichersystem so konfigurieren, dass eingehende Anforderungen vom Root-Benutzerkonto an eine nicht privilegierte Benutzer-ID (UID) umgeleitet werden.

Wenn Ihr Speichersystem den Root-Benutzer squashen exportiert, sollten Sie die HPC-Cache-Client-Zugriffsregel für dieses Speicherziel ebenfalls für den Root-Benutzer squashen. Andernfalls können Sie Zugriffsprobleme haben, wenn Sie versuchen, das Back-End-Speichersystem über den HPC-Cache zu lesen oder in das Back-End-Speichersystem zu schreiben.

In dieser Tabelle wird das Verhalten für unterschiedliche Root-Squash-Szenarien veranschaulicht, wenn eine Client-Anfrage als UID 0 (Root) gesendet wird. Das mit * markierte Szenario wird nicht empfohlen , da es Zugriffsprobleme verursachen kann.

(UID 65534 ist ein 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 der Azure HPC-Cache über einen geeigneten Zugriff auf jede Exportebene im Pfad zu den verwendeten Dateien verfügt.

Ein System kann z. B. drei Exporte wie folgt anzeigen:

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

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

Wenn Sie den payroll-Export als HPC-Cache-Speicherziel hinzufügen, wird der Cache tatsächlich bereitgestellt, indem er /ifs/ einhängt und von dort aus auf das Lohnbuchverzeichnis zugreift. Daher benötigt Azure HPC Cache ausreichenden Zugriff auf /ifs, um auf den /ifs/accounting/payroll-Export zuzugreifen.

Diese Anforderung bezieht sich auf die Art und Weise, wie dateien im Cache indiziert werden, und verhindert Dateikonflikte mithilfe von Dateihandles, die das Speichersystem bereitstellt.

Ein NAS-System mit hierarchischen Exporten kann unterschiedliche Dateihandles für dieselbe Datei bereitstellen, wenn die Datei aus verschiedenen Exporten abgerufen wird. Beispielsweise könnte ein Client /ifs/accounting einbinden und auf die Datei payroll/2011.txt zugreifen. Ein anderer Client bindet /ifs/accounting/payroll ein und greift auf die Datei 2011.txt zu. Je nachdem, wie das Speichersystem Dateihandles zuweist, erhalten diese beiden Clients möglicherweise dieselbe Datei mit unterschiedlichen Dateihandles (eins für <mount2>/payroll/2011.txt und eins für <mount3>/2011.txt).

Das Back-End-Speichersystem behält interne Aliase für Dateihandles bei, aber Azure HPC Cache kann nicht feststellen, welche Datei in seinem Indexverweis dasselbe Element behandelt. Es ist also möglich, dass der Cache unterschiedliche Schreibvorgänge für dieselbe Datei zwischenspeichert und die Änderungen falsch angewendet werden können, da er nicht weiß, dass es sich um dieselbe Datei handelt.

Um diese mögliche Dateikonflikte für Dateien in mehreren Exporten zu vermeiden, stellt Azure HPC Cache automatisch den flachsten verfügbaren Export im Pfad (/ifs im Beispiel) bereit und verwendet das vom Export angegebene 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 Sie über ein VPN zwischen dem Cache und Ihrem NAS-Gerät verfügen, blockiert das VPN möglicherweise 1500-Byte-Ethernet-Pakete in voller Größe. Möglicherweise haben Sie dieses Problem, wenn ein großer Austausch zwischen dem NAS und der Azure HPC-Cacheinstanz nicht abgeschlossen ist, aber kleinere Updates funktionieren wie erwartet.

Es gibt keine einfache Möglichkeit, festzustellen, ob Ihr System dieses Problem hat, es sei denn, Sie kennen die Details Ihrer VPN-Konfiguration. Hier sind einige Methoden, mit denen Sie nach diesem Problem suchen können.

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

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

  Führen Sie mit diesen Optionen einen Pingbefehl über das VPN an das NAS aus. (Verwenden Sie die IP-Adresse Ihres Speichersystems anstelle des <storage_IP> Werts.)

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

  Dies sind die Optionen im Befehl:

  • -M do - Nicht fragmentieren
  • -c 1 - Nur ein Paket senden
  • -s 1472 - Legen Sie die Größe der Nutzlast auf 1472 Bytes fest. Dies ist die maximale Nutzlast für ein 1500-Byte-Paket, nachdem der Ethernet-Overhead angegeben wurde.

  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 der Ping mit 1472 Bytes fehlschlägt, liegt wahrscheinlich ein Paketgrößenproblem vor.

Um das Problem zu beheben, müssen Sie möglicherweise MSS Clamping auf dem VPN konfigurieren, damit das Remotesystem die maximale Framegröße ordnungsgemäß erkennt. Lesen Sie die Dokumentation zu den PARAMETERn für VPN-Gateway-IPsec/IKE , um mehr zu erfahren.

In einigen Fällen kann das Ändern der MTU-Einstellung für den Azure HPC-Cache auf 1400 hilfreich sein. Wenn Sie jedoch die MTU im 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 unter "Konfigurieren zusätzlicher Azure HPC-Cacheeinstellungen ".

Überprüfung der ACL-Sicherheitskonfiguration

Einige NAS-Systeme verwenden einen hybriden Sicherheitsstil, der Zugriffssteuerungslisten (ACCESS Control Lists, ACLs) mit herkömmlicher POSIX- oder UNIX-Sicherheit kombiniert.

Wenn Ihr System seinen Sicherheitsstil als UNIX oder POSIX meldet, ohne das Akronym "ACL" einzuschließen, wirkt sich dieses Problem nicht auf Sie aus.

Für Systeme, die ACLs verwenden, muss Azure HPC Cache zusätzliche benutzerspezifische Werte nachverfolgen, um den Dateizugriff zu steuern. Dazu wird ein Zugriffscache aktiviert. Es gibt kein benutzerorientiertes Steuerelement, um den Zugriffscache zu aktivieren, aber Sie können ein Supportticket öffnen, um anzufordern, dass es für die betroffenen Speicherziele im Cachesystem aktiviert ist.

Nächste Schritte

Wenn Sie ein Problem haben, das in diesem Artikel nicht behoben wurde, wenden Sie sich an den Support , um Expertenhilfe zu erhalten.