Grundlegendes zu Dateisperren und Sperrentypen in Azure NetApp Files
In NAS-Umgebungen greifen mehrere Clients auf Dateien auf demselben Volume zu. Das NAS-Volume ist nicht anwendungsorientiert. Wenn mehrere Clients gleichzeitig versuchen, in dieselbe Datei zu schreiben, senden Anwendungen daher zum Schutz von Daten vor potenzieller Beschädigung Sperranforderungen an den NAS-Server, um zu verhindern, dass andere Clients Änderungen vornehmen, während die Datei verwendet wird. Bei NFS sind die Dateisperrmechanismen von der verwendeten NFS-Version abhängig.
Sperrentypen
Es gibt mehrere Arten von NFS-Sperren, darunter:
Freigegebene Sperren: Freigegebene Sperren können von mehreren Prozessen gleichzeitig verwendet und nur ausgegeben werden, wenn keine exklusiven Sperren für eine Datei vorhanden sind. Diese Sperren sind für schreibgeschützte Arbeit vorgesehen, können aber für Schreibvorgänge (z. B. in einer Datenbank) verwendet werden.
Exklusive Sperren: Exklusive Sperren funktionieren wie exklusive Sperren in SMB: Nur ein Prozess kann die Datei verwenden, wenn eine exklusive Sperre vorhanden ist. Wenn andere Prozesse die Datei gesperrt haben, kann keine exklusive Sperre ausgegeben werden, es sei denn, dieser Vorgang wurde geforkt.
Delegierungen: Delegierungen werden nur bei NFSv4.x verwendet und werden zugewiesen, wenn die NFS-Serveroptionen aktiviert sind und der Client NFSv4.x-Delegierungen unterstützt. Delegierungen bieten eine Möglichkeit, Vorgänge auf Clientseite zwischenzuspeichern, indem eine „gemäßigte“ Sperre für die Datei erstellt wird, die von einem Client verwendet wird. Dadurch wird die Leistung bestimmter Workloads verbessert, indem die Anzahl der Aufrufe zwischen Client und Server reduziert wird. Sie ähneln opportunistischen SMB-Sperren. Azure NetApp Files unterstützt derzeit keine NFSv4.x-Delegierungen.
Bytebereichssperren: Statt eine gesamte Datei zu sperren, sperren Bytebereichssperren nur einen Teil einer Datei.
Das Sperrverhalten hängt vom Typ der Sperre, der Version des Clientbetriebssystems und der verwendeten NFS-Version ab. Testen Sie die Sperre in Ihrer Umgebung, um das erwartete Verhalten zu messen.
NFSv3-Sperre
NFSv3 verwendet zusätzliche Protokolle wie NLM (Network Lock Manager) und NSM (Network Status Monitor), um Dateisperren zwischen dem NFS-Client und dem Server zu koordinieren. Diese zusätzlichen Protokolle werden gemäß der Spezifikation RFC-1813 definiert, an die sich Azure NetApp Files hält.
NLM hilft beim Einrichten und Aufheben von Sperren, während NSM Peers über Serverneustarts benachrichtigt. Bei der NFSv3-Sperre muss der Server die Sperren aufheben, wenn ein Client neu gestartet wird. Wenn ein Server neu gestartet wird, erinnert der Client den Server an die Sperren, die er aufrechterhalten hat.
Hinweis
In einigen Fällen kommunizieren die NFS-Sperrmechanismen nicht ordnungsgemäß (z. B. bei einem Netzwerkausfall), und veraltete Sperren verbleiben auf dem Server und müssen manuell gelöscht werden. Weitere Informationen zu dieser Aufgabe finden Sie unter Problembehandlung bei Dateisperren.
NFSv4.x-Sperre
NFSv4.x verwendet ein leasebasiertes Sperrmodell, das in das NFS-Protokoll integriert ist. Das bedeutet, dass es keine zusätzlichen Dienste gibt, die gewartet oder behandelt werden müssen. Alle Sperren werden in der NFSv4.x-Kommunikation gekapselt.
Azure NetApp Files unterstützt den NFSv4.1-Mechanismus für die Dateisperrung, der den Status aller Dateisperren unter einem leasebasierten Modell aufrechterhält. Gemäß RFC 8881 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.
Das bedeutet, dass der Client seine Leasedauer explizit oder implizit erneuern kann, indem er einen Vorgang wie das Lesen einer Datei durchführt. Darüber hinaus definiert Azure NetApp Files eine Toleranzperiode. Dabei handelt es sich um einen Zeitraum für eine spezielle Verarbeitung, in dem Clients versuchen, ihren Sperrstatus während einer Serverwiederherstellung freizugeben.
| Begriff | Definition |
|---|---|
| Lease | Der Zeitraum, in dem Azure NetApp Files unwiderruflich eine Sperre für einen Client gewährt. |
| Kulanzzeitraum | Der Zeitraum, in dem Clients versuchen, ihren Sperrzustand während der Serverwiederherstellung im Falle eines Serverausfalls freizugeben. |
Behandeln von NFSv4.x-Sperren durch Azure NetApp Files
Sperren werden von Azure NetApp Files bei Clientanforderung auf Leasebasis ausgestellt. Der Azure NetApp Files-Server überprüft die Lease für jeden Client alle 30 Sekunden auf Änderungen. Im Falle eines Clientneustarts kann der Client alle gültigen Sperren vom Server freigeben, nachdem er neu gestartet wurde. Wenn der Azure NetApp Files-Server neu gestartet wird, werden beim Neustart für eine Toleranzperiode von 45 Sekunden keine neuen Sperren für die Clients ausgegeben. Nach diesem Zeitpunkt können Sperren für die anfordernden Clients ausgestellt werden. Wenn die Sperre während der angegebenen Toleranzperiode nicht erneut eingerichtet werden kann, läuft die Sperre von selbst ab. Dieses Verhalten unterscheidet sich von der NFSv3-Sperre, da es keine veralteten Sperren gibt, die manuell aufgehoben werden müssen.
Manuelles Einrichten von Sperren für einen Client
Um NFS-Sperren zu testen, muss der Client dem NFS-Server mitteilen, eine Sperre einzurichten. Allerdings verwenden nicht alle Anwendungen Sperren. Die Anwendung „vi“ sperrt z. B. keine Datei. Sie erstellt eine ausgeblendete Auslagerungsdatei unter Verwendung einer Punktnamenskonvention im selben Ordner und committet dann Schreibvorgänge in dieser Datei, wenn die Anwendung geschlossen ist. Anschließend wird die alte Datei gelöscht, und die Auslagerungsdatei wird mit dem Dateinamen umbenannt.
Es gibt jedoch Hilfsprogramme, um Sperren manuell einzurichten. Beispielsweise kann flock Dateien sperren.
Um eine Sperre für eine Datei einzurichten, führen Sie zuerst exec aus, um eine numerische ID zuzuweisen.
# exec 4<>v4user_file
Verwenden Sie flock, um eine freigegebene oder exklusive Sperre für die Datei zu erstellen.
# flock
Usage:
flock [options] <file|directory> <command> [command args]
flock [options] <file|directory> -c <command>
flock [options] <file descriptor number>
Options:
-s --shared get a shared lock
-x --exclusive get an exclusive lock (default)
-u --unlock remove a lock
-n --nonblock fail rather than wait
-w --timeout <secs> wait for a limited amount of time
-E --conflict-exit-code <number> exit code after conflict or timeout
-o --close close file descriptor before running command
-c --command <command> run a single command string through the shell
-h, --help display this help and exit
-V, --version output version information and exit
# flock -n 4
So heben Sie die Dateisperre auf:
# flock -u -n 4
Durch das manuelle Sperren von Dateien können Sie die Interaktionen zum Öffnen und Bearbeiten von Dateien sowie die Funktion zum Aufheben von Sperren in Azure NetApp Files testen.