Dass man in ONTAP die Volumes einer SVM in einem großen Namespace baumartig untereinanderhängt bzw. “mountet”, weiß vermutlich jeder, der schon mal NAS-Dienste im ONTAP konfiguriert hat.
Schließlich kennt man ein ähnliches Prinzip ja auch von Linux. Dort mountet man auch einzelne Disks, Partitionen oder Laufwerke an irgendeine Stelle im Verzeichnisbaum (den sogenannten “Mount-Punkt”), um darauf zuzugreifen.
Und selbst unter Windows ist das Konzept verbreitet, wenn auch vielleicht nicht so weitverbreitet. Denn auch dort kann man Partitionen oder Laufwerke in ein Verzeichnis (z.B. C:\Data) einhängen, anstatt ihnen klassisch einen eigenen Laufwerksbuchstaben zuzuweisen. Unter Windows heißt dieses Feature Reparse-Point oder Junction.
Sowohl unter Linux als auch unter Windows ist diesem “Mount”-Mechanismus gemein, dass man, sobald man den Mount wieder entfernt (unmountet), keinen Zugriff mehr auf die Disk bzw. das Laufwerk hat.
Ein kleines, aber feines Detail, was viele Admins nicht wissen, ist, dass das unter ONTAP so nicht der Fall ist: Dort kann auch auf ein nicht gemountetes Volume zugegriffen werden! Und das gilt sowohl für CIFS als auch für NFS-Zugriffe.
Kurz noch ein paar Worte zum Begriff “Fencing”. Damit ist gemeint, dass z.B. während einer Migration zu einem gewissen Zeitpunkt sämtliche Client-Zugriffe auf den Original-Datenbestand verhindert werden müssen: Die Daten werden durch einen “Zaun” (“Fence”) vor den Clients geschützt.
Das Problem
Stellt euch vor, ihr wollt ein Volume von einem ONTAP-Cluster auf ein anderes migrieren. Dazu benutzt ihr beispielsweise SnapMirror. Die Idee ist folgende:
- SnapMirror einrichten
- regelmäßige inkrementelle Updates (z.b. täglich) durchführen
- Für den Cutover:
- Client-Zugriffe unterbinden (Fencing)
- ein letztes SnapMirror-Update durchführen
- Zugriff auf das Zielvolume umbiegen (DNS-Alias, DFS-Redirect, IP umstellen o.Ä.)
Der kritische Schritt ist dabei das Fencing: Denn nur wenn sichergestellt ist, dass Clients keine weiteren Daten in das “alte” Volume schreiben können, kann man garantieren, dass alle Daten im Ziel landen und kein Datenverlust droht.
Das Problem dabei ist jetzt aber, dass ein volume unmount kein wirksames Fencing darstellt, sofern die Clients schon eine Verbindung auf das entsprechende Volume haben.
Wie sieht das in einer CIFS-Umgebung aus?
Um das Problem nachzustellen, nehmen wir unsere SVM namens svmcifs. Diese hat ein Volume namens data, welches unter dem Junction-Path /data gemountet ist. Weiterhin gibt es ein CIFS-Share namens Data, welches auf den Pfad /data verweist:
cl1::> volume show -vserver svmcifs -volume data -fields junction-path,junction-active
vserver volume junction-path junction-active
------- ------ ------------- ---------------
svmcifs data /data truecl1::> cifs share show -vserver svmcifs -share-name data -fields path
vserver share-name path
------- ---------- -----
svmcifs Data /dataNatürlich können wir unter Windows problemlos auf dieses Share zugreifen:
Nun unmounten wir das Volume im ONTAP:
cl1::> volume unmount -vserver svmcifs -volume data
cl1::> volume show -vserver svmcifs -volume data -fields junction-path,junction-active
vserver volume junction-path junction-active
------- ------ ------------- ---------------
svmcifs data - -Interessanterweise bleibt unter Windows das Explorer-Fenster auf dem Share aber offen, und wenn man eine Datei darin öffnet oder eine neue Datei anlegt, so funktioniert das ohne Probleme:
Erst wenn man das Explorer-Fenster schließt und wartet, bis die CIFS-Session geschlossen wird (nach ein paar Sekunden), kann man wie erwartet nicht mehr auf das Share zugreifen:
Fazit: Unmounten eines Volumes ist also kein wirksames Fencing gegen Client-Zugriffe.
Wie sieht das unter Linux mit NFS aus?
Auch unter Linux ist die Situation einfach nachzustellen. Dazu nehmen wir die SVM svmnfs, welche ein Volume data1 unter /data1 gemountet hat und welches NFS-Zugriff von unserer Linux-VM erlaubt:
cl1::> volume show -vserver svmnfs -volume data1 -fields junction-path,policy
vserver volume policy junction-path
------- ------ ------- -------------
svmnfs data1 default /data1cl1::> export-policy rule show -vserver svmnfs -policyname default
Policy Rule Access Client RO
Vserver Name Index Protocol Match Rule
--------- ---------- ------ -------- -------------- ---------
svmnfs default 1 nfs 0.0.0.0/0 sysWir können das Volume nun problemlos mounten und darauf zugreifen:
[md-linux1 /]# mount 10.92.4.53:/data1 /mnt -o nfsvers=3,sec=sys
[md-linux1 /]# ls -las /mnt
total 12
4 drwxr-xrwx 2 root root 4096 4. Apr 14:27 .
4 drwxr-xr-x 17 root root 4096 21. Feb 14:30 ..
4 drwxrwxrwx 12 root root 4096 24. Jun 11:05 .snapshot
0 -rw-r--r-- 1 user user 26 4. Apr 14:25 test-file-1.txt
0 -rw------- 1 root root 40 4. Apr 14:26 test-file-2.txt
0 -rw-r--r-- 1 root root 0 4. Apr 14:27 test-file-4.2.txt
Nun führen wir den Unmount im ONTAP durch:
cl1::> volume unmount -vserver svmnfs -volume data1
cl1::> volume show -vserver svmnfs -volume data1 -fields junction-path,policy
vserver volume policy junction-path
------- ------ ------- -------------
svmnfs data1 default -Der Zugriff unter Linux funktioniert aber auch hier weiterhin ohne Probleme:
[md-linux1 /]# ls -las /mnt
total 12
4 drwxr-xrwx 2 root root 4096 4. Apr 14:27 .
4 drwxr-xr-x 17 root root 4096 21. Feb 14:30 ..
4 drwxrwxrwx 12 root root 4096 24. Jun 11:05 .snapshot
0 -rw-r--r-- 1 user user 26 4. Apr 14:25 test-file-1.txt
0 -rw------- 1 root root 40 4. Apr 14:26 test-file-2.txt
0 -rw-r--r-- 1 root root 0 4. Apr 14:27 test-file-4.2.txt
[md-linux1 /]# cat /mnt/test-file-1.txt
Hello World!
from Linux
[md-linux1 /]# echo "foo" > /mnt/test-file-5.txt
[md-linux1 /]# cat /mnt/test-file-5.txt
fooEinzig ein neuer Mount führt zu einem Fehler:
[md-linux1 /]# umount /mnt
[md-linux1 /]# mount 10.92.4.53:/data1 /mnt -o nfsvers=3,sec=sys
mount.nfs: mounting 10.92.4.53:/data1 failed, reason given by server: No such file or directoryFazit: Unter NFS ist somit das Unmounten eines Volumes auch kein wirksames Fencing gegen Client-Zugriffe.
Warum ist das so?
Im NFS-Umfeld ist die Antwort dazu relativ einfach: Der einzige Punkt, an dem bei einem NFS-Zugriff ein Pfadname im Spiel ist, ist beim initialen Mount. Sobald dieser Mount einmal stattgefunden hat, passieren sämtliche Zugriffe (Lesen, Schreiben etc.) über zwei Zahlen: die Filesystem-ID und die File-ID. Im ONTAP entsprechen diese der MSID des Volumes und der Inode-Nummer der Datei1.
Dies kann man in einem Packet Trace sehr gut erkennen:
Die Nummer hinter “fsid” entspricht der MSID unseres Volumes:
cl1::> volume show -fields msid -msid 2155707342
vserver volume msid
-------- ------ ----------
svmnfs data1 2155707342Da ONTAP die MSID des Volumes auch findet, wenn das Volume nicht gemountet ist, wird der Zugriff ganz normal gewährt. Einzig ein neuer Mount würde fehlschlagen, da die Verbindung des Pfades /data1 zu dem gewünschten Volume nicht mehr existiert und ONTAP somit den Mount verweigert.
Im CIFS-Umfeld wird der Zugriff allerdings über eine Session geregelt, welche im ONTAP im RAM hinterlegt ist. Wie diese Session genau aussieht, ist nicht dokumentiert, aber es ist offensichtlich, dass auch hier Volume-MSIDs verwendet werden anstelle von Pfaden (was ja auch Sinn ergibt, da es deutlich effizienter ist). Somit wird auch hier der Zugriff weiter funktionieren, so lange, bis das Session-Objekt gelöscht wird.
Der korrekte Weg
Es gibt ein paar Möglichkeiten, ein Volume korrekt gegen Client-Zugriffe abzuschotten:
- Stoppen des CIFS bzw. NFS-Dienstes (beeinflusst natürlich auch alle anderen Volumes/Shares/Exports), oder der ganzen SVM („Holzhammer-Methode“)
- Deaktivieren der CIFS/NFS IP Adresse (setzen von
status-adminaufdown) … Auch davon sind natürlich alle Shares/Exports/Volumes betroffen - Für CIFS: Setzen einer Share-Level ACL
Everyone/No_accessauf dem Share (diese greift sofort) – aber Achtung, über ein anderes Share kommt man evtl. dann immernoch auf die Daten in dem betreffenden Volume. Also genau prüfen, welche Shares angepasst werden müssen. - Für NFS: Anpassen der Export-Policy und Ändern des Client-Matches (greift sofort und gibt “stale file handle” Fehlermeldung auf den Clients beim Zugriffsversuch)
- Fencing vom Client aus (alle Clients unmounten)
Bitte also genau aufpassen bei Migrationen von Daten. Im Zweifelsfall gerne auf eure Ansprechpartner bei der AU zugehen, wir unterstützen gerne!
- In der Praxis ist es etwas komplizierter: Die Filesystem-ID und die File-ID hängen sowohl vom Snapshot ab, auf den zugegriffen wird, als auch von den Einstellungen der NFS-Optionen
fsid-changeund64bit-identifiers, sowie dem Volume-Typ (FlexVol oder FlexGroup). Einfachheitshalber gehen wir hier aber von einem Zugriff auf das aktive Dateisystem eines FlexVols aus, wo die Annahme stimmt. ↩︎
Matthias Beller