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.

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 den gleichen Dateipfad (Volumeerstellungstoken) für mehrere Volumes verwenden?

Ja, das ist möglich. Der Dateipfad muss jedoch innerhalb jedes Subnetzes eindeutig sein.

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 Lease nicht innerhalb des definierten Zeitraums verlängert, werden alle Zustände, die der Lease des Clients zugeordnet 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 auch das Brechen von Dateisperren.

Weitere Informationen zum Sperren von Dateien in Azure NetApp Files finden Sie unter Dateisperren.

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

Das SNAPSHOT-Verzeichnis ist für NFSv4.1-Clients entwurfsbedingt niemals sichtbar. Standardmäßig ist das .snapshot Verzeichnis für NFSv3-Clients 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 auf 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 beschädigt ein späteres Überschreiben desselben Blocks den beschädigten Block im Hintergrund. Andernfalls erkennen Oracle-Datenbankprozesse dies schließlich. 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 die unter "Gibt es für die Verwendung von Oracle dNFS mit NFSv4.1 erforderlichen Patches" aufgeführten Aktionen zu ergreifen.

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 zitieren, 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 potenzielle 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 Herunterfahrensprozess überwachen, werden Pausen angezeigt, die sich zu minutenlangen Verzögerungen summieren können, wenn dNFS-E/A-Zeitüberschreitungen auftreten.
  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 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 Trunking sessionID für NFSv4.1, um mit mehreren Pfaden zu arbeiten, was Azure NetApp Files nicht unterstützt. Daher wird beim Start von dNFS ein Hängenbleiben auftreten.

Nächste Schritte