Das Dilemma mit den Delta-Files, oder: To snapshot or NOT to snapshot?

Eines der Features am ESX-Server, das mich von Anfang an total begeistert hat war die möglichkeit, VM´s zu snapshotten. So einfach kann das Patchen eines Servers sonst nicht sein. Keine lästigen hantieren mit Backups mehr (warten, bis der Backupjob fertig ist oder Wartungsfenster definieren, usw…), einfach einen Snapshot erstellen und los legen. Geht etwas schief, wird zum letzten Punkt reverted.

Jedoch gibt es bei den Snapshots auch einiges zu wissen/beachten:
- Beim mergen von großen Snapshots gilt es, vor allem den Timeout des Virtual Centers zu beachten. Nach 15 Minuten wird der Task als abgebrochen angezeigt, er läuft im Hintergrund allerdings weiter. Es sollte tunlichst vermieden werden, einen weiteren Merge zu starten!

- Snapshots sollten mit Bedacht verwendet werden, und vor allem nur für kurze Zeit. Snapshots, die länger laufen (z.b. >2 Tage) beeinflußen die Systemperformance stark. Außerdem braucht es äußerst lange, bis die Snapshots wieder gemergt sind (lt. VMWare Support bis zu 8h, abhängig von der Auslastung der Virtuellen Maschine, der verwendeten Hardware, der Größe des Snapshots, uvm.). Seit ESX3.x dauert das mergen noch länger als in den Vorgängerversionen, da der verwendete Algorithmus geändert wurde.

- Virtual Center kennt noch keine Überwachung des verbleibenden Festplattenplatzes. Der/die Snapshots wachsen kontinuierlich an, bis die Partition/das LUN voll ist (es verbleiben nur wenige Mb. Meistens 11MB oder 4MB – zumindest in meiner Umgebung). Aus diesem Grund emfpielt es sich, eine Dummy-Datei im root des Storages zu erstellen, die man im Ernstfall schnell löschen kann. Diese kann mit dem Befehl: “dd if=/dev/zero of=./4000megs.zero bs=1M count=4000” erstellt werden. So werden aus dem Zero-Device 4000 Stücke mit jeweils 1 Megabyte in die Datei 4000megs.zero geschrieben. Dies sollte dann im Verzeichnis /vmfs/volumes/SID-DES-VOLUMES/ passieren, da dies die vmfs-Partition wiederspiegelt. Das ganze könnte dann so ausschauen:

4GB Dummyfile mit dd erstellen

4GB Dummyfile mit dd erstellen

Im Ernstfall, wenn also das Kind schon in den Brunnen gefallen ist und “nichts mehr geht”, kann diese Datei gefahrlos via SSH oder dem Storagebrowser gelöscht werden. Diese 4GB können dann vom ESX-Server genutzt werden, um die Delta-Files mit der VMDK zu mergen.

Es gibt noch ein Tool, welches die Snapshots und den Plattenplatz überwacht, und ggf. eine Warnung per E-Mail versendet. Snaphunter von xtravirt wird in vielen Foren als Lösung genannt, bis VMware in der nächsten Version diese Überprüfung selbst einbaut (info vom VMware Support). Ich habe das Tool allerdings noch nicht getestet, werde das aber demnächst nachholen und hier darüber berichten.

- Läuft schon ein Merge, kann man sich über den Status mit dem CLI-Tool “vimsh” informieren (detaillierte Informationen über “vimsh” gibt es hier). Dazu connected man sich auf den ESX-Host, auf dem der Merge läuft, und startet in der Shell “vimsh“.

VMware vimsh vimsvc/task_list

VMware vimsh vimsvc/task_list

Dann kann man sich eine Liste der Tasks via “vimsvc/task_list” anzeigen lassen, mit “vimsvc/task_info NAME_DES_TASKS” wird eine detaillierte Info ausgegeben:

VMware vimsvc/task_info

VMware vimsvc/task_info

Dort ist ersichtlich, ob der Task schon abgeschlossen ist oder nicht.

————————-

Da es jetzt 2.17 ist, werde ich diesen Beitrag morgen weiter schreiben….

Leave a Reply