Best Practices für Snapshots in vSphere: Lebensdauer, Performance, vMotion

    Architektur von Snapshots in VMwareSnapshots sind eine Standardfunktion aller modernen Hypervisor. Sie vereinfachen das Zurücksetzen von virtuellen Maschinen auf einen früheren Zustand und das Erstellen von Backups. Gleichzeitig kann die falsche Verwendung von solchen Prüfpunkten zu Problemen führen, insbesondere in Form von übermäßigem Speicherverbrauch und Performance-Einbußen.

    Ein Snapshot hält den gesamten Status einer VM fest, darunter den Zustand aller mit ihr verbundenen virtuellen Festplatten, die Konfiguration der VM sowie der Inhalt des Arbeitsspeichers. Anschließend speichert der Hypervisor alle Änderungen in separaten Dateien, die ursprüngliche VM oder ein übergeordneter Snapshot werden nun nicht mehr verändert.

    Alle Änderungen gehen in Delta-VMDKs

    Aufgrund der Abhängigkeit eines Snapshots von den übergeordneten virtuellen Laufwerken darf keine dieser Master-VMDKs verändert werden. Löscht man eine solche, dann wird der Snapshot unbrauchbar. Diese Gefahr droht aber auch, wenn man eine Eltern-VMDK vergrößert, die Folge wären auch hier Datenverluste.

    VMware ESXi unterstützt pro VM bis zu 32 verkettete Snapshots. Je mehr solcher Prüfpunkte man anlegt, umso größer wird der Verwaltungsaufwand für den Hypervisor, denn er muss aus der Eltern-VMDK und allen übergeordneten Snapshots den aktuellen Zustand der VM errechnen. VMware empfiehlt daher, nicht mehr als 2 bis 3 verkettete Snapshots zu verwenden.

    Verbrauch von Speicherplatz

    Laufen in einer VM Anwendungen, die viele Schreibzugriffe verursachen und daher zahlreiche Blöcke des Dateisystems verändern, dann wachsen die differenziellen Disks sehr schnell. Dies trifft etwa auf Datenbanken oder Mail-Server zu, die ein hohes Aufkommen an Transaktionen erzeugen. Ganz tabu sind daher Tools zur Defragmentierung von Dateien, die im Gastsystem laufen.

    Der Snapshot-Manager im vSphere Web Client

    Der Platzverbrauch von VMs kann durch Snapshots stark zunehmen, weil die Delta-VMDKs, in denen ESXi die Änderungen gegenüber der ursprünglichen Disk speichert, genauso groß werden können wie das konfigurierte Maximum des Master-Laufwerks. Entsprechend muss man diesen Wert mit der Zahl der Snapshots multiplizieren, um den möglichen Speicherbedarf einer VM abzuschätzen.

    Snapshots anzeigen mit PowerCLI

    Will man sich einen Überblick über den Speicherverbrauch aller Snapshots verschaffen, dann kann man dies relativ leicht mit PowerCLI tun. Dort verbindet man sich mittels Connect-VIServer mit vCenter oder einem ESXi-Host und gibt anschließend den Befehl

    Get-VM | Get-Snapshot| select Name, Created, SizeGB

    Ist man nur daran interessiert, wieviel Platz alle Snapshots insgesamt belegen, dann kann man dies mit

    Get-VM | Get-Snapshot | %{$Snaps += $_.SizeGB}

    erfragen, indem man anschließend den Wert der Variablen $Snaps ausgibt.

    Wachstum begrenzen durch kurze Nutzung

    Nachdem die Delta-Disks mit dem Alter des Snapshots wachsen, rät VMware dazu, einen solchen nicht länger als 24 bis 72 Stunden zu verwenden. In dieser Zeit sollte man herausfinden können, ob die Änderungen an einer VM unerwünschte Auswirkungen haben. Treten keine Probleme auf, dann kann man den Snapshot löschen (wobei "löschen" in der Terminologie von VMware nicht "entfernen" meint, sondern das Zusammenführen mit der übergeordneten VMDK).

    Große Snapshots belasten das System nicht nur durch den hohen Speicherverbrauch, sondern auch dann, wenn man die Änderungen wieder in die übergeordnete VMDK zurückschreibt. Dieser Vorgang kann bei großen Delta-VMDKs sehr lange dauern und den Host stark belasten.

    Probleme unter vSphere 4.x

    Wenn man noch eine Version von vCenter bzw. ESXi älter als 5.0 einsetzt, dann sollte man bedenken, dass VMs dort keinen Snaphot haben dürfen, wenn man sie mit Storage vMotion auf ein anderes Speichersystem verschieben möchte. Andernfalls könnte die VM beschädigt werden und die enthaltenen Daten verloren gehen.

    Ein weiteres Problem mit Snapshots besteht darin, dass diese häufig von Anwendungen, etwa von Backup-Programmen, über APIs erzeugt werden. Sie scheinen dann manchmal nicht im vSphere (Web) Client bzw. im dortigen Snapshot-Manager auf. In diesem Fall hilft ein Blick ins Dateisystem oder der Einsatz von externen Tools wie Snapwatcher.

    Keine Kommentare