one picture, each day, for one year: November 21st, 2011

What a nice day abroad. Thanks!

Huch, irgendwie hab ich den ja voll verpasst:

SUNNYVALE, Calif.—September 9, 2010—NetApp (NASDAQ: NTAP) today announced that both parties have agreed to dismiss their pending patent litigation, which began in 2007 between Sun Microsystems and NetApp. Oracle and NetApp seek to have the lawsuits dismissed without prejudice. The terms of the agreement are confidential. (Quelle)

Klingt nach einem Nichtangriffspakt zweier Storage-Hersteller, die beide irgendwie sehr voneinander profitieren. Und in 4 Jahren verkauft Oracle seine SUN Storage Abteilung an NetApp… nur mal so völlig unernst in die Tüte gemutmaßt. Lustig wärs auf alle Fälle.

Ich wurde heute gefragt wieso es so lange dauert ein großes Verzeichnis mit vielen Dateien zu löschen, welches per NFS gemountet wurde. Angenommen ich habe die folgende Verzeichnisstruktur:

/fileserver/Vorratsdatenspeicherung/
/fileserver/Vorratsdatenspeicherung/2007/Januar/
/fileserver/Vorratsdatenspeicherung/2007/Januar/01/Server1/…
/fileserver/Vorratsdatenspeicherung/2007/Januar/01/Server2/…
[...]
/fileserver/Vorratsdatenspeicherung/2007/Januar/31/Server1/…
/fileserver/Vorratsdatenspeicherung/2007/Januar/31/Server2/…
[...]
/fileserver/Vorratsdatenspeicherung/2010/Januar/31/Server1/…
/fileserver/Vorratsdatenspeicherung/2010/Maerz/02/Server2/…

usw…

und möchte das aus gegebenen Anlass loswerden. Die Vermutung war, dass der Linux Client an den NFS Server nur den Befehl  ‘lösche das Verzeichnis “Vorratsdatenspeicherung”‘  schicken müsste, und den Rest würde der NFS Server dann automagisch tun. Ein Vorgang der innerhalb von 1-2 Sekunden also zumindest aus Client Sicht erledigt wäre. In der Realität sieht das ganze etwas anders aus, weshalb es schonmal eine Weile dauert, bis so ein großes Verzeichnis leer ist.

Warum?

Wenn ich den oben genannten Befehl (rm -rf /fileserver/Vorratsdatenspeicherung) absetze, muss der Linux Client das ersteinmal für das Linux Dateisystem übersetzen, denn der Benutzer spricht nicht direkt mit dem NFS Server, sondern über eine Dateisystem-Zwischenschicht, die im Hintergrund Dateisystem-Anfragen in NFS-Operationen umwandelt.

(Achtung: Es folgt eine abstrakte Übersicht über das, was im Hintergrund dabei passiert. Diese Übersicht ist nicht vollständig und in der Realität noch x-fach komplexer)

Der NFS Server kennt den Pfad /fileserver/Vorratsdatenspeicherung vermutlich gar nicht. Der Fileserver hat die Daten vielleicht unter /vol/datenschutzabteilung/Server/Vorratsdatenspeicherung/ liegen und muss nun mit Löschbefehlen gefüttert werden. Der Linux Client läuft also los und sagt ‘Hey Verzeichnis Vorratsdatenspeicherung/, ich lösch dich jetz!’. Das Linux Filesystem antwortet darauf und meinte “Nee, das ist ein Verzeichnis, das geht so nicht, das muss erstmal leer sein, bevor du das löschen kannst. Und dann geht der Spaß los:

- Das Verzeichnis wird geöffnet, openat(Vorratsdatenspeicherung)
- Die Verzeichnisattribute werden eingelesen, fstat()
- Die Verzeichnisinhalte werden abgefragt, getdents()

Die Ausgabe von getdents wird überprüft und oh schreck. Da sind ja noch mehr Verzeichnisse! Also geht das Spiel wieder los für das Verzeichnis Vorratsdatenspeicherung/2007/, dann für Vorratsdatenspeicherung/2007/Januar/, Vorratsdatenspeicherung/2007/Januar/01/ bis Vorratsdatenspeicherung/2007/Januar/01/Server01/ und dann meint der Server, ja, da sind momentan (z.B.) 8192 Dateien drin. Daraufhin holt sich der Linux Client die Liste der Dateien und fängt dann an nach und nach alle 8192 Dateien in dem Verzeichnis zu löschen:

unlinkat(Datei0)
unlinkat(Datei1)
unlinkat(Datei2)
[...]
unlinkat(Datei8191)

Jetzt ist das erste Unterverzeichnis leer. Dann schaut der Client zur Sicherheit mit getdents() nochmal nach ob alles weg ist und erst dann wird das erste Unterzeichnis Vorratsdatenspeicherung/2007/Januar/01/Server01/ entfernt – unlinkat(Server01, AT_REMOVEDIR).

Der Übersicht halber habe ich hier einige Systembefehle weggelassen. In der Realtität passiert da noch viel viel mehr. Bis das gesamte Verzeichnis Vorratsdatenspeicherung/ tatsächlich weg ist, wird der Linux Client mehrere zehntausende Dateisystem-Anfragen gestellt haben und bis zu dieser Stelle hab ich noch gar nicht über NFS(v3) Anfragen gesprochen.

Im Hintergrund wird jede herkömmliche Linux Filesystem-Anfrage in diesem Fall in NFS RPC Calls übersetzt und an den NFS Server übermittelt. Am Ende dieses Löschbefehls wird der NFS Server also vielleicht einige Millionen Befehle empfangen haben, bis das Verzeichnis tatsächlich auf dem Share gelöscht ist. Und genau deshalb dauert es manchmal ziemlich lang einen kleinen unscheinbaren Befehl auszuführen.

Weiterführende Doku:

• Linux NFS FAQ
• Wikipedia über das NFS Protokoll
• RFC1813 (NFS Version 3 Protocol Specification)
• Mike Eislers NFS Blog

Der Jörn sucht Leute in Oldenburg, die sich unter anderem mit NetApp auskennen:

Wer sich mit Linux/Solaris auskennt, zumindest Grundkenntnisse mit NetApp-Storage mitbringt und sich vorstellen könnte im Nordwesten zu arbeiten, kann sich mal bei mir melden. Das gleiche gilt für Leute mit Kenntnissen in allem was man im ISP-Bereich so braucht, als Radius, Loadbalancer, POP/IMAP, Mysql-Cluster usw.

Interesse? Nehmt Kontakt mit ihm auf!

Es verirren sich immer öfter Leute hierher oder schreiben mir, die nach Informationen zu NetApp und SNMP Abfragen suchen. Um in den NetApp MIBs zu suchen, habe ich schon einmal das Tool Mibble empfohlen. Es ist Java basiert und kann damit quasi überall eingesetzt werden. Sofern Mibble läuft, braucht man nur noch die MIB, die man auf NOW oder im ROOT auf dem Storage Controller findet. (z.B. /vol/vol0/etc/mib/netapp.mib)

Frage 1: Wie kann ich per SNMP eine Liste meiner LUNs abfragen?

NETWORK-APPLIANCE-MIB -> VALUES -> netapp -> netapp1 -> blocks -> lun -> lunTable -> lunEntry -> lunName

root@prudence:~# snmpwalk -On -c public -v 2c gundel 1.3.6.1.4.1.789.1.17.15.2.1.2
.1.3.6.1.4.1.789.1.17.15.2.1.2.1 = STRING: “/vol/NFSv4_SF/lunTEST”

Frage 2: Wie kann ich die Temperatur meiner Shelves auslesen?

Da gibt es mehrere Wege. Einer wäre die Temperatur per CLI abzufragen. Der Befehl dazu ist “environment”:

gundel> environment status shelf
[...]
Cooling Unit installed element list: 1, 2; with error: none
Temperature Sensor installed element list: 1, 2, 3; with error: none
Shelf temperatures by element:
[1] 21 C (69 F) (ambient)  Normal temperature range
[2] 24 C (75 F)  Normal temperature range
[3] 24 C (75 F)  Normal temperature range

Die Daten können natürlich auch per SNMP ausgelesen werden, um z.B. eine Überwachung in Nagios zu realisieren:

NETWORK-APPLIANCE-MIB -> VALUES -> netapp -> netapp1 -> storage -> enclosure -> enclTable -> enclEntry -> enclTempSensorsCurrentTemp

root@prudence:~# snmpwalk -On  -c public -v 2c gundel 1.3.6.1.4.1.789.1.21.1.2.1.25
.1.3.6.1.4.1.789.1.21.1.2.1.25.1 = STRING: “30C (86F), 24C (75F), 28C (82F)”
.1.3.6.1.4.1.789.1.21.1.2.1.25.2 = STRING: “21C (69F) ambient, 24C (75F), 24C (75F)”
.1.3.6.1.4.1.789.1.21.1.2.1.25.3 = STRING: “19C (66F) ambient, 28C (82F), 27C (80F)”
.1.3.6.1.4.1.789.1.21.1.2.1.25.4 = STRING: “20C (68F) ambient, 38C (100F), 43C (109F)”
.1.3.6.1.4.1.789.1.21.1.2.1.25.5 = STRING: “23C (73F) ambient, 39C (102F), 37C (98F)”

Frage 3: Wie kann ich per SNMP eine Liste meiner Volumes bekommen?

NETWORK-APPLIANCE-MIB -> VALUES -> netapp -> netapp1 -> filesys -> volTable -> volEntry -> volName

root@prudence:~# snmpwalk -On -c public -v 2c gundel 1.3.6.1.4.1.789.1.5.8.1.2
.1.3.6.1.4.1.789.1.5.8.1.2.1 = STRING: “vol0″
.1.3.6.1.4.1.789.1.5.8.1.2.2 = STRING: “vol1″
.1.3.6.1.4.1.789.1.5.8.1.2.3 = STRING: “sl_vol”
.1.3.6.1.4.1.789.1.5.8.1.2.4 = STRING: “NFSv4_SF”

Wenn der NetApp System Manager irgendwas von “… (502) Ungültiges Gateway” faselt:

Dann ist auf dem Windows System vermutlich ein Proxy konfiguriert, der die nötigen API Calls nicht per HTTPS Richtung Storage Controller loswerden kann. In meinem Fall half es den Proxy in den Windows-Einstellungen zu deaktivieren. Wer nicht ohne kann, wird die nötigen Infos im Proxy Logfile finden um das Problem zu beseitigen.

Eine Alternative zur NetApp Weboberfläche (WebGUI) ist der kostenlose NetApp System Manager, der mittlerweile für alle Kunden zum Download freigegeben ist ist:

Darüber hat man nicht nur einen schnellen Überblick darüber was auf den Maschinen momentan passiert, man kann die Controller damit auch komplett verwalten. In der momentanen Version gibt es zum Beispiel Wizzards um Volumes, Luns oder CIFS bzw. NFS Shares zu provisionieren, die einem viel Arbeit im Hintergrund abnehmen.

Beispiel: LUN Wizzard

Typische Aufgaben wie das verkleinern oder vergrößern von Volumen lassen sich mit dem System Manager genauso einfach erledigen wie die Konfiguration der Storage Controller an sich. Der System Manager benötigt die Microsoft  Management Console und spricht mit den NetApp Systemen per SNMP oder HTTP(s). Momentant unterstützt werden Systeme der Reihen FAS20XX, FAS30XX und FAS31XX. Wer nach einer alternative zur WebGUI sucht und sowieso irgendwo Windows Geräte laufen hat,  sollte den System Manager auf jeden Fall ausprobieren.

Ich liebe es ja den “alten Machern” zuzuschauen, wenn sie über die Stolpersteine und Geschichten aus der Vergangenheit reden. Warum? Weil mir persönlich solche Geschichten mehr geben als jedes Lehrbuch oder jede noch so gut gemeinte Liste von Vorschlägen oder Regeln.

Meistens nehme ich mir vor über diese für mich wertvollen Videos hier zu schreiben, aber ihr wisst ja wie das ist. Dieses mal habe ich es jedenfalls nicht vergessen und verlinke hiermit ein Video zum Talk von Dave Hitz (NetApp Mitgründer) an der Princeton University.

Er beschreibt in unterhaltsamen Geschichten aus der Vergangenheit seinen holprigen Weg vom technischen Entwickler zum leitenden Manager. (engineer to executive) Ich hätte eine Geschichte exemplarisch gerne übersetzt, aber sie verliert im Deutschen irgendwie ihre Witzigkeit. Wer kein Problem mit Englisch hat und schon immer wissen wollte wie man einen Bullen kastriert – einfach mal reinschauen oder reinhören. Viel Spaß! ;-)

Eine Mail an NetApp kommt zurück mit:

Wie ironisch. :)

Ich spare mir an dieser Stelle einen epischen Text über meine Kündigung bei Arcor und bringe ihn sobald der Tag X da ist. Ab dem 1. Januar 2009 werde ich unter neuer Flagge weiter segeln. Bis dahin bleibt noch viel Zeit für ein persönliches Gespräch. Ich habe meinen (alten) Arbeitsvertrag just passend zum Geburtstag gekündigt. Wer Interesse hat mich auch in Zukunft nicht aus den Augen zu verlieren, kann mich gern über Xing beobachten. Meinen Account dort habe ich reaktiviert.