Grundlegendes zu Dateisperren und Sperrtypen in Azure NetApp-Dateien
In NAS-Umgebungen greifen mehrere Clients auf Dateien im selben Volume zu. Das NAS-Volume ist nicht anwendungsfähig. Um Daten vor potenzieller Beschädigung zu schützen, wenn mehrere Clients gleichzeitig versuchen, in dieselbe Datei zu schreiben, senden Anwendungen 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 werden und können nur ausgegeben werden, wenn keine exklusiven Sperren für eine Datei vorhanden sind. Diese Sperren sind für schreibgeschützte Arbeiten vorgesehen, können aber für Schreibvorgänge (z. B. mit einer Datenbank) verwendet werden.
Exklusive Sperren: Exklusive Sperren funktionieren mit exklusiven Sperren in CIFS/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 verzweigt.
Delegationen: Delegationen werden nur mit 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 clientseitiger Seite zwischenzuspeichern, indem eine "weiche" 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 und ähnlich wie die opportunistischen SMB-Sperren sind. Azure NetApp Files unterstützt derzeit keine NFSv4.x-Delegierungen.
Bytebereichssperren: Anstatt eine gesamte Datei zu sperren, sperrt bytebereich nur einen Teil einer Datei.
Das Sperrverhalten hängt vom Typ der Sperre, der Clientbetriebssystemversion und der verwendeten NFS-Version ab. Testen Sie die Sperrung in Ihrer Umgebung, um das erwartete Verhalten zu messen.
NFSv3-Sperrung
NFSv3 verwendet zusätzliche Protokolle wie Network Lock Manager (NLM) und Network Status Monitor (NSM), um Dateisperren zwischen dem NFS-Client und dem Server zu koordinieren. Diese zusätzlichen Protokolle werden in RFC-1813 definiert, die Azure NetApp Files einhalten.
NLM hilft beim Einrichten und Freigeben von Sperren, während NSM Peers von Serverneustarts benachrichtigt. Bei der NFSv3-Sperre muss der Server die Sperren freigeben, wenn ein Client neu gestartet wird. Wenn ein Server neu gestartet wird, erinnert der Client den Server an die sperren, die er gehalten hat.
Hinweis
In einigen Fällen kommunizieren die NFS-Sperrmechanismen nicht ordnungsgemäß (z. B. im Falle eines Netzwerkausfalls), und veraltete Sperren bleiben auf dem Server übrig und müssen manuell gelöscht werden. Weitere Informationen zu dieser Aufgabe finden Sie bei der Problembehandlung bei Dateisperren.
NFSv4.x-Sperrung
NFSv4.x verwendet ein leasebasiertes Sperrmodell, das in das NFS-Protokoll integriert ist. Dies bedeutet, dass es keine Nebendienste gibt, um Standard zu Standard zu sorgen; alle Sperren werden in der NFSv4.x-Kommunikation gekapselt.
Azure NetApp Files unterstützt den NFSv4.x-Dateisperrmechanismus, Standard den Zustand aller Dateisperren unter einem leasebasierten Modell enthalten. Gemäß RFC 8881 definiert Azure NetApp Files "einen einzelnen Leasezeitraum für den gesamten Zustand, der von einem NFS-Client gehalten wird. Wenn der Kunde seine Lease nicht innerhalb des definierten Zeitraums verlängert, kann der gesamte Zustand, der dem Lease des Clients zugeordnet ist, vom Server freigegeben werden."
Dies bedeutet, dass der Client seine Lease explizit oder implizit verlängern kann, indem er einen Vorgang ausführt, z. B. das Lesen einer Datei. Darüber hinaus definiert Azure NetApp Files eine Nachfrist, bei der es sich um eine bestimmte Verarbeitung handelt, in der Clients versuchen, ihren Sperrstatus während einer Serverwiederherstellung zurückzugeben.
| 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 zurückzufordern. |
So behandelt Azure NetApp Files NFSv4.x-Sperren
Sperren werden von Azure NetApp Files auf 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 zurückfordern, nachdem er neu gestartet wurde. Wenn der Azure NetApp Files-Server neu gestartet wird, gibt es beim Neustart keine neuen Sperren für eine Nachfrist von 45 Sekunden an den Clients aus. Nach diesem Zeitpunkt können Sperren für die anfordernden Clients ausgestellt werden. Wenn die Sperre während der angegebenen Nachfrist nicht erneut eingerichtet werden kann, läuft die Sperre eigenständig ab. Dieses Verhalten unterscheidet sich von der NFSv3-Sperre, da es keine veralteten Sperren gibt, die manuell beschädigt werden müssen.
Manuelles Einrichten von Sperren auf einem 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 Punktbenennungskonvention im selben Ordner und führt dann Schreibvorgänge in diese Datei durch, wenn die Anwendung geschlossen wird. Anschließend wird die alte Datei gelöscht, und die Auslagerungsdatei wird in den 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 entsperren Sie die Datei.
# flock -u -n 4
Durch das manuelle Sperren von Dateien können Sie Die Geöffnet- und Bearbeitungsinteraktionen der Datei testen und die Sperrunterbrechungsfunktion in Azure NetApp-Dateien testen.