Thoughts. Ideas. Photography.

Posts tagged “ZFS

Tipps für Roaming Profiles

Seit langem mal wieder ein Blogeintrag über die Technik statt über die Dinge und Obskuritäten auf OSI-Layer-8. Diesmal über eine Kombination, die mir immer mehr Freude macht.

Es geht um folgendes Problem: Für 16 mit Solaris-Zones virtualisierte Samba-Server muss eine Methode gefunden werden, dass Userfehler beim Umgang mit deren Profiles korrigiert werden können:

  1. Das Profil muss auf den letzten funktionierenden Stand vor dem letzten Einloggen, idealerweise aber auch zu Beginn der Woche etc. zurückgesetzt werden können.
  2. Das Profil muss vor unabsichtlichem Wachstum geschützt werden. Es muss möglich sein, dass User „aus Versehen“ 8 GB neue Filme oder ähnliche Dateimonster auf dem Desktop oder sonstwo im Profil liegen haben, ohne dass die Netzwerkstrippe beim Ausloggen glüht. Wichtig dabei ist, dass die User die großen Dateien während ihrer Arbeit ruhig innerhalb des Profils speichern können sollen, diese Dateien sollen halt nur bereits beim Ausloggen auf dem Server sein.
  3. Das Profil muss automatisch von überflüssigem Ballast wie uralten temporären Dateien gereinigt werden. Große Profile verlangsamen schließlich das Einloggen.

Die Lösung dafür setzt sich aus mehreren Teilen zusammen. Die Teile 1 und 3 sind schon gelöst, am Teil 2 arbeite ich noch, hier gibt es erste Ergebnisse.

Teil 1: „Instant Backup mit ZFS“

Das Zurücksetzen der Profile ist relativ einfach zu realisieren mit ZFS, vorausgesetzt die Profile, zumindest aber die Homeverzeichnisse der User liegen in eigenen ZFS-Filesystemen. Dann muss man Samba nur in der smb.conf anweisen, vor dem Ausliefern des Profiles schnell einen snapshot zu ziehen. Gefunden habe ich das Ganze bei Chris Gerhard. Das sieht dann folgendermaßen aus. In der smb.conf steht folgende Zeile:
root preexec = ksh -c '/usr/sbin/zfs snapshot smbexport/homes/%u@smb$(/usr/local/scripts/smbdate)'
Dabei ist smbdate ein kleines Skript, das ein mit dem Datum hilft. Rein theoretisch sollte es auch gehen, das direkt mit Samba zu erzeugen, doch leider wandelt Samba zunächst die Einträge um, die mit % beginnen (hier also das %u). Daher muss man den date-Befehl (der zur Formatierung des Datums auch ein paar % enthält), und der eigentlich zeitgleich oder kurz nach dem Auspacken der % laufen soll, in ein Skript einpacken.
Das Datumskript sieht so aus:
#!/bin/ksh -p
exec date +%F--%R
Das %F erzeugt das Datum in amerikanischer Schreibweise (die sortiert sich besser), die beiden „-“ trennen Datum und Uhrzeit, und %R erzeugt die Uhrzeit in 24-Stunden-Schreibweise.

Das kombiniert man dann noch mit automatischen Aufräumskripten, sodass nicht zu viele Snapshots aufgehoben werden (solche Skripte hat auch Chris Gehard vorrätig).

Teil 2: Kleine Roaming Profiles beim Client erzeugen

Für einige Dateimonster, beispielsweise Thunderbird-Profile, in denen per POP3 abgerufene Mails sich verbergen, oder OUTLOOK.PST-Dateien eines relativ bekannten PIM, bietet sich ein anderer Trick an: Die Programme greifen immer nur auf Teile der Riesendateien zu, man kann also diese Dateien dauerhaft auf ein Netzlaufwerk auszulagern, ohne dass diese dann beim Programmstart komplett auf den Client transferiert werden. Neben der (lässtigen) Methode, dass jeder User dies in seinem Mailprogramm/PIM selbst einstellen muss, kann man das auch Windows/Samba überlassen.

Dazu lege man sich im NETLOGON-Share eine Policy-Datei an, in der man Windows ein wenig zurechtweist. Unter

HKEY CURRENT USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell
Folders\

findet man folgende Werte:

AppData %USERPROFILE%\Anwendungsdaten
Cache %USERPROFILE%\Lokale Einstellungen\Temporary Internet Files
Cookies %USERPROFILE%\Cookies
Desktop %USERPROFILE%\Desktop
Favorites %USERPROFILE%\Favoriten
History %USERPROFILE%\Lokale Einstellungen\Verlauf
Local AppData %USERPROFILE%\Lokale Einstellungen\Anwendungsdaten
Local Settings %USERPROFILE%\Lokale Einstellungen
My Pictures %USERPROFILE%\Eigene Dokumente\Eigene Bilder
NetHood %USERPROFILE%\Netzwerkumgebung
Personal %USERPROFILE%\Eigene Dokumente
PrintHood %USERPROFILE%\Druckumgebung
Programs %USERPROFILE%\Startmenü\Programme
Recent %USERPROFILE%\Verlauf
SendTo %USERPROFILE%\SendTo
Start Menu %USERPROFILE%\Startmenü
Startup %USERPROFILE%\Startmenü\Programme\Autostart
Templates %USERPROFILE%\Vorlagen

Dabei ist %USERPROFILE% ein Verweis auf C:\Dokumente und Einstellungen\%USERNAME%. Und genau diesen Verweis kann man per Policy-Datei ändern. Man nehme also den NT4-Gruppenrichtlinien-Editor und ersetze in den Teilen des Profils, die zum Wachsen neigen und die nun nicht wirklich ständig hin- und hergeschoben werden müssen, das %USERPROFILE% durch

%LOGONSERVER%\%USERNAME%\ServerProfil

Und schon landet das jeweilige Teilverzeichnis direkt im Verzeichnis des jeweiligen Users auf dem Server, und zwar im Unterverzeichnis ServerProfil. Ideal für Desktop, Anwendungsdaten, Lokale Einstellungen und Eigene Dateien.

Wendet man das ganze sehr strikt an, kann man Profile von mehreren Gigabyte auf wenige Megabyte zusammenstauchen.

Teil 3: Serverseitiges Ausmisten der Profile

Das Aufräumen eines Windowsprofils ist auch relativ einfach: Es gibt Dateien, die man serverseitig löschen darf, und solche, von denen man den rm-Befehl fernhalten sollte. Das Problem sind dabei einige Spezialitäten, einfach mit find nach .tmp-Dateien zu suchen bringt nichts – schließlich benennt jeder Hersteller seine temporären Dateien, wie er will. Diese Varianten sind vor allem dann interessant, wenn es nicht möglich ist, die Tipps aus Teil 2 zu berücksichtigen. Daher hier mal einige exemplarische Löschvorschläge:

  • Viel Zeit kosten viele kleine Dateien, da relativ viel Overhead für relativ wenig Nutzlast erzeugt wird. Wo findet man sowas? Die Cookies zählen ebenso dazu wie die diversen Temporären Dateien unter Lokale Einstellungen/Temp. Insbesondere Adobe-Produkte neigen dazu, hier jede Menge Cleanup-Müll abzulegen, der dann noch Jahrzehnte später von den Abstürzen zeugt.
  • Ebenfalls relativ gut aufzuräumen sind die Temporary Internet Files: Der Internetexplorer ist ein guter Datensammler. Daher sollte man bei Roaming Profiles hier eine Bremse einbauen und die Cache-Größe beschränken. Auch per Skript hier auszumisten funktioniert.
  • Besonders Java neigt dazu, sich einen großen Cache zuzulegen. Wer viel mit Java arbeitet, sollte sich mal \Anwendungsdaten\Sun\Java\Deployment im Profil anschauen. Diesen Cache kann man auch verkleinern (oder lagert ihn mit Tipp 2 auf den Server aus).

Noch ein Tipp am Rande: Wenn man sich solche Datenmengen hübsch visualisiert anschauen möchte, dann empfehlen sich die Tools TreeSize und Sequoia View.


PDB – Private Distributed Backup

Als ich bei Sun in München war (Projekt Blackböxchen war im Heldenstudio), haben nach dem Interview Rolf, Constantin und ich noch über ein Backup-Netzwerk für die privaten Server der Systemhelden gesprochen. Die Idee am Ende war ein verschlüsseltes ZFS auf dem Server eines Freundes, welches per iSCSI über DSL angebunden werden sollte. Wir konnten uns alle vorstellen, dass sowas funktionieren könnte, doch habe ich die Idee erst einmal wieder vergraben.

Mittlerweile habe ich das Problem des Backup für den Heimserver jedoch wieder: Mein bisheriges Backup-System für verdammt wichtige Daten steht mir berufsbedingt nicht mehr lange zu Verfügung. Daher fange ich nun an, diese Idee mit dem Backup auf den Rechner eines Kollegen immer sympathischer zu finden. Den Standort für mein erstes Backup-System habe ich auch schon ausgemacht (Constantin, Dein Keller ist nicht gemeint! Du kannst Dich aber gerne an dem Backup-Netzwerk beteiligen, wenn wir damit anfangen!).

Allerdings habe ich nach ersten Versuchen keine Lust mehr auf Bacuda als Backup-Software: Zu viele Komponenten, die man regelmäßig überprüfen muss, und das Restore ist nicht wirklich bequem zu bedienen für die übrigen Familienmitglieder. Für große Sachen ist das Bacuda echt in Ordnung, aber nicht für „eben mal Backup“ zu Hause.

Einen genialen Einfall habe ich dann heute in einen Artikel von Jörg Möllenkamp gelesen. Das ganze mit einem hierarchischen Filesystem zu lösen, ist natürlich eine bestechende Idee. Den Cache so konfigurieren (und groß machen), dass er alles Wichtige vorrätig hält, und gleich auf die DSL-lahme zweite/dritte Platte im Backup-System kopieren (kann halt einen Moment dauern, aber dazu hat man ja den Cache). Die selten gebrauchten Sachen liegen dann irgendwann nur noch im Backup-System, bis sie ein Brenner, der wieder zu Hause rumsteht „wegbrennt“. Idealerweise kombiniert man das statt nur mit einem „Fremdsystem“ mit mehreren, eines vielleicht im gleichen LAN, eines per DSL…

Jörg wollte das ganze mit Managed Storage Services verbinden und dazu SamFS erweitern. Vielleicht geht das aber auch bequemer, falls SamFS mit iSCSI-Devices klarkommt.

Das ganze wäre auf jeden Fall sehr bequem, alle Daten wären immer schön zu sehen, manche wären nur sehr langsam da. Und wenn eine Platte „abraucht“, wäre dennoch alles immer noch da.

Schade, dass SamFS nicht frei verfügbar ist, ich habe aber auch noch nicht wirklich nach einem Open-Source-Konkurrenten gesucht. Vielleicht gibt’s das SamFS ja irgendwann in der „Systemhelden-Edition“ für den rein privaten Einsatz.


TSM und ZFS

ZFS ist cool, das Backup eines ZFS mit TSM erinnert an die Steinzeit. Warum kann IBM seinen Backup-Client nicht erweitern, sodass dieser auch in der Lage ist, ZFS zu backupen?

Der Fehler oder das Fehlen scheint länger bekannt zu sein, und seit zwei Versionen des Clients passiert nichts. Irgendwie ist es extrem merkwürdig, dass IBM zuerst ewig braucht, um den Backup-Client für Solaris 10 x64 zu portieren, und dann brauchen sie vergleichbar lange, um ein richtig nettes Dateisystem zu unterstützen.
Wirft man den TSM-Client für ein inkrementelles Backup an, so kann man dies mit „dsmc i“ oder „dsmc incremental“ tun. Der Client schaut darauf in seiner dsm.sys nach, was er so abarbeiten soll, verbindet sich mit dem Server und fängt an, die Daten der verschiedenen Dateisysteme zu senden.

Naja, fast. Er ignoriert dabei sämtliche ZFS-Dateisysteme. Selbst wenn man sie explizit in der dsm.sys drin stehen hat, weigert sich das Teil, auch nur eine einzige Datei ins Backup zu senden. IBM sagt dazu was sehr klares: ZFS wird nicht gebackupt, weil es nicht gebackupt werden soll. (LINK seit Mitte September nicht mehr funktionstüchtig, Dokument nicht mehr zu finden)

Kommt man allerdings auf die Idee, und probiert den Pfad, unter dem das ZFS eingehängt ist, direkt als Parameter an den dsmc zu übergeben, so funktioniert das ganze ohne Probleme. Auch der Restore-Prozess funktioniert so ausgezeichnet.

Also muss man das Backup der ZFS-Dateisysteme über einen Cronjob erledigen, in dem man die einzelnen Mountpoints der ZFS-Dateisysteme als Parameter übergibt – wenig elegant aber effektiv. Natürlich kann man auch ein kleines Skript schreiben, dass sich mittels zfs mount eine Liste der Dateisysteme zusammensucht, diese zusammenkürzt und daraus Parameter für dsmc bastelt.

for mount in `zfs mount | awk ‚$0 ~ /.*\/.*\/.*/ {print $2}’`; do

dsmc i ${mount} -subdir=yes

done

Gut, die paar Zeilen sorgen auch für ein funktionierendes Backup, aber man könnte es wahrlich einfacher haben!

Merkwürdig an der Sache ist, dass dies zum wiederholten Male Ärger mit dem Backup-Client unter Solaris ist. Zunächst brauchte IBM ewig, bis sie einen Client für Solaris 10 x64 (also die 64bit Intel-Variante) auf dem Markt hatten. Einige Admins behalfen sich mit einem historischen Stück Software, welches perfekt funktionierte. Und nun bringt die Konkurrenz ein nettes Dateisystem auf den Markt, dass IBM erstmal nicht verarbeitet. Die Bemerkung von IBM, ZFS können „planmäßig“ nicht gebackupt werden, stammt aus dem Dezember 2006, und im Februar wurde ein Rechtschreibungsfehler entfernt.

UPDATE 5. Oktober 2007:

IBM hat nicht nur den Hinweis entfernt, ZFS würde „planmäßig“ nicht gebackupt werden, sondern es scheint einen neuen Client zu geben, der mit ZFS klarkommt, so schreibt es zumindest mattdey in den Foren von Open Solaris und so kann ich es nach einem ersten Test auch bestätigen. Merkwürdig ist aber, dass IBM es in den Handbüchern zu dem Client nicht „zugibt“ .