Häufig gestellte Fragen zu NFS in Azure NetApp Files

  • Artikel

In diesem Artikel werden häufig gestellte Fragen (FAQs) zum NFS-Protokoll in Azure NetApp Files beantwortet.

Ich möchte, dass automatisch ein Volume eingebunden wird, wenn eine Azure-VM gestartet oder neu gestartet wird. Wie konfiguriere ich meinen Host für persistente NFS-Volumes?

Damit beim Starten oder Neustarten einer VM automatisch ein NFS-Volume eingebunden wird, fügen Sie einen Eintrag für die Datei /etc/fstab zum Host hinzu.

Weitere Informationen finden Sie unter Einbinden eines Volumes auf virtuellen Windows- oder Linux-Computern.

Welche NFS-Version wird von Azure NetApp Files unterstützt?

Azure NetApp Files unterstützt NFSv3 und NFSv4.1. Für die Volumeerstellung können beide NFS-Versionen verwendet werden.

Unterstützt Azure NetApp Files offiziell NFSv4.2?

Azure NetApp Files bietet keine Unterstützung für NFSv4.2 oder seine zusätzlichen Features (einschließlich der Vorgänge für platzsparende Dateien, erweiterter Attribute und Sicherheitsbezeichnungen). Obwohl Sie ein NFS4.1-Volume auf Azure NetApp Files mit NFSv4.2-Protokoll einbinden können, wird die Verwendung von NFSv4.2 nicht unterstützt.

Azure NetApp Files-Volumes können mithilfe des NFSv4.2-Protokolls auf eine von zwei Arten eingebunden werden:

  • Explizites Angeben von vers=4.2, nfsvers=4.2 oder nfsvers=4,minorversion=2 in den Einbindungsoptionen.
  • Keine Angabe einer NFS-Version in den Einbindungsoptionen und Erlauben, dass der NFS-Klient mit der höchsten unterstützten NFS-Version verhandelt. Je nach Linux-Distribution kann dies dazu führen, dass NFSv4.2 als das höchste verfügbare NFS-Protokoll verwendet wird.

Viele Clients können jedoch Probleme haben, wenn sie NFSv4.2 oder die erweiterte Attributfunktionalität von NFSv4.2 nicht vollständig unterstützen. Da NFSv4.2 nicht mit Azure NetApp Files unterstützt wird, liegen alle Probleme mit NFSv4.2 außerhalb des Supportumfangs. Um Probleme mit Klienten zu vermeiden, die NFSv4.2 einbinden, und um die Unterstützung zu gewährleisten, stellen Sie sicher, dass die NFSv4.1-Version in den Einbindungsoptionen angegeben ist oder die NFS-Clientkonfiguration des Client so eingestellt ist, dass die NFS-Version auf NFSv4.1 begrenzt ist.

Weitere Informationen finden Sie unter Grundlegendes zu NAS-Protokollen in Azure NetApp Files.

Wie aktiviere ich das Root Squashing?

Sie können angeben, ob für das Stammkonto (Root) Zugriff auf das Volume besteht, indem Sie die Exportrichtlinie des Volumes verwenden. Weitere Informationen finden Sie unter Konfigurieren der Exportrichtlinie für ein NFS-Volume.

Kann ich denselben Dateipfad für mehrere Volumes verwenden?

Derselbe Dateipfad kann verwendet werden für

  • In verschiedenen Regionen bereitgestellte Volumes
  • Volumes, die in verschiedenen Verfügbarkeitszonen innerhalb derselben Region bereitgestellt werden

Je nachdem, welches Verbundprotokoll Sie verwenden, gehen Sie wie folgt vor:

  • regionale Volumes (ohne Verfügbarkeitszonen) oder
  • Volumes innerhalb derselben Verfügbarkeitszone.

Der Dateipfad muss jedoch innerhalb jedes delegierten Subnetzes eindeutig sein oder verschiedenen delegierten Subnetzen zugewiesen werden.

Weitere Informationen finden Sie unter Erstellen eines NFS-Volumes für Azure NetApp Files oder Erstellen eines Volumes mit dualem Protokoll für Azure NetApp Files.

Warum nimmt der Client für das Durchsuchen von Ordnern und Unterordnern viel Zeit in Anspruch, wenn ich versuche, über einen Windows-Client auf NFS-Volumes zuzugreifen?

Stellen Sie sicher, dass CaseSensitiveLookup auf dem Windows-Client aktiviert ist, um die Suche nach Ordnern und Unterordnern zu beschleunigen:

  1. Verwenden Sie den folgenden PowerShell-Befehl, um „CaseSensitiveLookup“ aktivieren:
    Set-NfsClientConfiguration -CaseSensitiveLookup 1
  2. Binden Sie das Volume auf dem Windows-Server ein.
    Beispiel:
    Mount -o rsize=1024 -o wsize=1024 -o mtype=hard \\10.x.x.x\testvol X:*

Wie unterstützt Azure NetApp Files die Dateisperrung von NFSv4.1?

Für NFSv4.1-Clients unterstützt Azure NetApp Files den NFSv4.1-Mechanismus für die Dateisperrung, der den Status aller Dateisperren unter einem leasebasierten Modell aufrechterhält.

Gemäß RFC 3530 definiert Azure NetApp Files eine einzelne Leasedauer für alle Zustände, die ein NFS-Client annimmt. Wenn der Client seine Leasedauer nicht innerhalb des definierten Zeitraums erneuert, werden alle Zustände, die mit der Leasedauer des Clients verbunden sind, vom Server freigegeben.

Wenn z. B. ein Client, der ein Volume einbinden will, nicht mehr reagiert oder nach Ablauf des Timeouts abstürzt, werden die Sperren freigegeben. Der Client kann seine Leasedauer explizit oder implizit erneuern, indem er Vorgänge wie das Lesen einer Datei durchführt.

Eine Toleranzperiode definiert einen Zeitraum für eine spezielle Verarbeitung, in dem Clients versuchen können, ihren Sperrstatus während einer Serverwiederherstellung freizugeben. Der Standardtimeout für die Leasedauer beträgt 30 Sekunden mit einer Toleranzperiode von 45 Sekunden. Nach dieser Zeit wird die Leasedauer des Clients freigegeben.

Azure NetApp Files unterstützt außerdem das Aufheben von Dateisperren.

Weitere Informationen zu Dateisperren in Azure NetApp Files finden Sie unter Dateisperren.

Warum ist das Verzeichnis .snapshot auf einem NFSv4.1-Volume nicht sichtbar, auf einem NFSv3-Volume jedoch schon?

Das SNAPSHOT-Verzeichnis ist für NFSv4.1-Clients entwurfsbedingt niemals sichtbar. Für NFSv3-Clients ist das Verzeichnis .snapshot standardmäßig sichtbar. Wenn Sie das Verzeichnis .snapshot für NFSv3-Clients ausblenden möchten, bearbeiten Sie die Volumeeigenschaften zum Ausblenden des Momentaufnahmepfads.

Oracle dNFS

Sind für dNFS Oracle-Patches erforderlich?

Wichtig

Kunden, die Oracle 19c und höher verwenden, müssen sicherstellen, dass sie den Patch für Oracle-Fehler 32931941 installiert haben. Die meisten Patchbündel, die aktuell von Oracle-Kunden verwendet werden, enthalten diesen Patch *nicht*. Der Patch wurde nur in eine Teilmenge der jüngsten Patchbündel aufgenommen.

Wenn eine Datenbank diesem Fehler ausgesetzt ist, führen Netzwerkunterbrechungen höchstwahrscheinlich zu Beschädigungen durch gebrochene Blöcke. Netzwerkunterbrechungen umfassen Ereignisse wie Speicherendpunktverschiebung, Volumeverschiebung und Ereignisse der Speicherdienstwartung. Die Beschädigung wird notwendigerweise nicht unbedingt sofort erkannt.

Diese Beschädigung ist weder ein Fehler auf ONTAP noch dem Azure NetApp Files-Dienst selbst, sondern das Ergebnis eines Oracle dNFS-Fehlers. Die Reaktion auf eine NFS E/A während einer bestimmten Netzwerkunterbrechung oder während Neukonfigurationsereignisse wird falsch behandelt. Die Datenbank schreibt fälschlicherweise einen Block, der gerade aktualisiert wurde, als er geschrieben wurde. In einigen Fällen wird der beschädigte Block durch eine spätere Überschreibung desselben Blocks im Hintergrund beschädigt. Wenn nicht, werden Oracle-Datenbankprozesse ihn schließlich erkennen. Ein Fehler sollte in den Warnungsprotokollen protokolliert werden, und die Oracle-Instanz wird wahrscheinlich beendet. Darüber hinaus können dbv- und RMAN-Vorgänge die Beschädigung erkennen.

Oracle veröffentlicht das Dokument 1495104.1, das kontinuierlich mit empfohlenen dNFS-Patches aktualisiert wird. Wenn Ihre Datenbank dNFS verwendet, stellen Sie sicher, dass das DBA-Team in diesem Dokument nach Updates sucht.

Wichtig

Kunden, die Oracle dNFS mit NFSv4.1 auf Azure NetApp Files-Volumes verwenden, müssen sicherstellen, dass sie Maßnahmen ergreifen, die unter Gibt es Patches, die für die Verwendung von Oracle dNFS mit NFSv4.1 erforderlich sind? erwähnt sind.

Gibt es Patches, die für die Verwendung von Oracle dNFS mit NFSv4.1 erforderlich sind?

Wichtig

Wenn Ihre Datenbanken Oracle dNFS mit NFSv4.1 verwenden, müssen Patches für Oracle-Fehler 33132050 und 33676296 installiert sein. Möglicherweise müssen Sie einen Backport für andere Versionen von Oracle anfordern. Zum Zeitpunkt der Erstellung dieses Artikels sind diese Patches beispielsweise für 19.11 verfügbar, aber noch nicht für 19.3. Wenn Sie diese Fehlernummern im Supportfall angeben, wissen die Supporttechniker von Oracle, was zu tun ist.

Diese Anforderung gilt für ONTAP-basierte Systeme und Dienste im Allgemeinen, die sowohl lokales ONTAP als auch Azure NetApp Files umfassen.

Beispiele für die möglichen Probleme, wenn diese Patches nicht angewendet werden:

  1. Datenbank hängt sich bei Verschiebungen des Back-End-Speicherendpunkts auf.
  2. Datenbank hängt sich bei Wartungsereignissen des Azure NetApp Files-Diensts auf.
  3. Kurzes Aufhängen von Oracle während des normalen Betriebs, das eventuell merklich ist oder auch nicht.
  4. Langsames Herunterfahren von Oracle: Wenn Sie den Prozess des Herunterfahrens überwachen, stellen Sie Pausen fest, die sich zu minutenlangen Verzögerungen addieren können, wenn es zu Timeouts von dNFS E/A kommt.
  5. Fehlerhaftes Verhalten der dNFS-Antwortzwischenspeicherung bei Lesevorgängen, wodurch sich eine Datenbank aufhängt.

Die Patches umfassen eine Änderung bei der dNFS-Sitzungsverwaltung und NFS-Antwortzwischenspeicherung, die diese Probleme löst.

Wenn Sie die Patches für diese beiden Fehler nicht installieren können, dürfen Sie dNFS nicht mit NFSv4.1 verwenden. Sie können dNFS entweder deaktivieren oder zu NFSv3 wechseln.

Kann ich Multipfade mit Oracle dNFS und NFSv4.1 verwenden?

Bei der Verwendung von NFSv4.1 funktioniert dNFS nicht mit mehreren Pfaden. Wenn Sie mehrere Pfade benötigen, müssen Sie NFSv3 verwenden. dNFS erfordert clusterweites clientID- und sessionID-Trunking für NFSv4.1, um mit mehreren Pfaden arbeiten zu können, was Azure NetApp Files nicht unterstützt. Das Ergebnis ist ein Aufhängen beim dNFS-Startup.

Nächste Schritte