Was sind VMware Snapshots?

VMware Snapshots bieten eine einfache und schnelle Möglichkeit, den aktuellen Zustand einer virtuellen Maschine zu speichern. Hierbei ist jedoch zu beachten, dass immer der komplette VM-Container mit all seinen Einstellungen und Geräten gesichert wird! Ein VMware Snapshot umfasst also folgende Komponenten:

• Hardware-Version des VM-Containers (i.d.R. abhängig von der vSphere-Version der Infrastruktur)
• Anzahl der virtuellen CPUs
• Größe des virtuellen Arbeitsspeichers
• Alle lokalen Festplatten und ihren Inhalt (Achtung: Der Inhalt der Festplatten wird nur inkrementell gesichert! Siehe Funktionsweise.)
• Alle virtuellen Netzwerkkarten und deren Konfiguration (VLAN, Verbindungsstatus, etc.)
• Einstellungen bzgl. der Platzierung der VM (Produktionsbereich / Testbereich) auf dem Storage
• Hotplugging Einstellungen
• Reservierungen (CPU / Memory)
• BIOS-Einstellungen
• und viele weitere erweiterte Einstellungen, die von Zeit zu Zeit von VMware-Administratoren angepasst wurden

Beim Erstellen eines Snapshots einer eingeschalteten VM hat man zusätzlich noch die Möglichkeit, den aktuellen RAM-Inhalt ebenfalls mitzusichern. Springt man später auf diesen Zustand zurück, so befindet sich das Betriebssystem im VM-Container in exakt dem selben Zustand wie bei Erstellung des Snapshots.

Wird die Option abgewählt und der Zustand wiederhergestellt, findet man einen ausgeschalteten VM-Container vor. Das Betriebssystem verhält sich dann so, als wäre es zuvor einfach hart abgeschaltet worden. Das Abwählen der Option ist daher mit Vorsicht zu genießen, denn eine 100%ige Datenkonsistenz kann so bei Wiederherstellung des Snapshots nicht garantiert werden, wenn zuvor noch Daten im RAM vorgehalten und noch nicht auf die Festplatte geschrieben wurden. Daher empfiehlt es sich, in diesem Fall die virtuelle Maschine zunächst sauber herunterzufahren, dann im ausgeschalteten Zustand einen Snapshot anzulegen und sie anschließend wieder zu starten.

Wofür sind VMware Snapshots geeignet?

VMware Snapshots eignen sich ideal, um den Zustand einer virtuellen Maschine z.B. direkt vor einem größeren Betriebssystem- und/oder Software-Update, oder einer größeren Konfigurationsänderung einer wichtigen Applikation für einen kurzen Zeitraum zu sichern, um im Fehlerfall schnell auf einen funktionsfähigen Zustand zurückkehren zu können. Wurde nach Abschluss der Prozedur die korrekte Funktionsweise der Änderungen festgestellt, so sollte man den Snapshot wieder entfernen (siehe Problematik).

Wofür sind VMware Snapshots ungeeignet?

VMware Snapshots sind keine Backups!

Beim Erstellen eines Snapshots wird keine Kopie der Festplatten erstellt! Vielmehr werden sämtliche Schreibzugriffe auf die Original-Festplatte eingestellt, eine sogenannte "Delta-Festplatte" angelegt, und alle folgenden Schreibvorgänge auf der Delta-Festplatte durchgeführt (siehe Funktionsweise)! Ohne Vorhandensein der Original-Festplatte sind sämtliche Delta-Festplatten (eine pro Snapshot) nutzlos!

Die langfristige Aufbewahrung von VMware Snapshots sollte unbedingt vermieden werden, da wie anfangs schon erwähnt nicht nur der Festplatteninhalt (so wie es der normale Benutzer gerne hätte) gesichert wird, sondern der komplette VM-Container mit all seinen Einstellungen, die sich im Laufe seines Lebenszyklus an verschiedensten Stellschrauben ändern können (siehe Funktionsweise). Des Weiteren hat die Anzahl, das Alter und die Größe der Snapshots teilweise erhebliche Auswirkungen auf die Gesamt-Performance (siehe Problematik).

Wird ein längerfristiges echtes Backup der Festplatteninhalte benötigt, so steht am LRZ - wie für pyhsische Maschinen auch - das TSM Backup zur Verfügung.

Funktionsweise

In obigem Diagramm ist entlang der x-Achse der Lebenszyklus einer virtuellen Maschine namens "VM1" beispielhaft dargestellt.

In ihrer Ursprungskonfiguration besitzt diese eine einzelne Festplatte (HDD 1) und eine Netzwerkkarte (NIC 1), die für den Zugriff auf das VLAN 79 konfiguriert ist.

Snapshot 1

Beim Anlegen des ersten Snapshots (dargestellt durch den ersten senkrechten roten Balken) für die VM passiert folgendes:

• Die Metainformationen aus den VM-Dateien "VM1.vmx" und "VM1.nvram" werden zusammen mit weiteren Snapshot-Informationen in eine VMware-Snapshot-Datei "VM1-Snapshot1.vmsn" gespeichert.
• Die erste Delta-Festplatte Delta-HDD 1 #1 "VM1-000001.vmdk" wird angelegt und ab sofort für sämtliche Schreibzugriffe verwendet, d.h. alle neuen und gegenüber der Original-Festplatte veränderten Daten landen hier.
• Lesezugriffe erfolgen zunächst auf der aktuellen Delta-Festplatte Delta-HDD 1 #1. Werden die angeforderten Daten darin nicht gefunden, so wird als nächstes in der Original-Festplatte danach gesucht.

Im Laufe der Zeit werden nun verschiedene Parameter verändert (rot markiert):

• Upgrade der VM Hardware-Version von 8 auf 9 (vSphere 5.0 -> vSphere 5.1)
• Erhöhung des virtuellen RAM auf 8 GB
• Änderung des Netzwerkzugriffs auf VLAN 18
• Aktivierung der CPU/Memory Hotplug Funktionalität
• Konfiguration einer CPU-Reservierung von 1000 MHz

Snapshot 2

Beim Anlegen des zweiten Snapshots (dargestellt durch den zweiten senkrechten roten Balken) für die VM passiert folgendes:

• Die jetzt gültigen Metainformationen aus den VM-Dateien "VM1.vmx" und "VM1.nvram" werden zusammen mit weiteren Snapshot-Informationen in eine VMware-Snapshot-Datei "VM1-Snapshot2.vmsn" gespeichert.
• Es wird eine zweite Delta-Festplatte Delta-HDD 1 #2 "VM1-000002.vmdk" angelegt und ab sofort für sämtliche Schreibzugriffe verwendet, d.h. alle neuen und gegenüber der Original-Festplatte bzw. der ersten Delta-Festplatte veränderten Daten landen hier.
• Lesezugriffe erfolgen zunächst auf der aktuellen Delta-Festplatte Delta-HDD 1 #2. Werden die angeforderten Daten darin nicht gefunden, so wird als nächstes in der ersten Delta-Festplatte danach gesucht. Sind die Daten auch hier nicht vorhanden, wird in der Original-Festplatte danach gesucht.

Im Laufe der Zeit werden nun weitere Parameter verändert (rot markiert):

• Upgrade der VM Hardware-Version von 9 auf 10 (vSphere 5.1 -> vSphere 5.5)
• Hinzufügen einer zweiten Festplatte mit 50 GB
• Konfiguration einer RAM-Reservierung von 2 GB

Snapshot 3

Beim Anlegen des dritten Snapshots (dargestellt durch den dritten senkrechten roten Balken) für die VM passiert folgendes:

• Die jetzt gültigen Metainformationen aus den VM-Dateien "VM1.vmx" und "VM1.nvram" werden zusammen mit weiteren Snapshot-Informationen in eine VMware-Snapshot-Datei "VM1-Snapshot3.vmsn" gespeichert.
• Es wird für die erste Festplatte eine dritte Delta-Festplatte Delta-HDD 1 #3 "VM1-000003.vmdk" angelegt und ab sofort für sämtliche Schreibzugriffe verwendet, d.h. alle neuen und gegenüber der Original-Festplatte bzw. der ersten und zweiten Delta-Festplatte veränderten Daten landen hier.
• Es wird für die zweite Festplatte die erste Delta-Festplatte Delta-HDD 2 #1 "VM1_1-000001.vmdk" angelegt und ab sofort für sämtliche Schreibzugriffe verwendet, d.h. alle neuen und gegenüber der Original-Festplatte veränderten Daten landen hier.
• Lesezugriffe auf die erste Festplatte erfolgen zunächst auf der aktuellen Delta-Festplatte Delta-HDD 1 #3. Werden die angeforderten Daten darin nicht gefunden, so wird als nächstes in der zweiten Delta-Festplatte danach gesucht. Sind die Daten auch hier nicht vorhanden, wird in der ersten Delta-Festplatte danach gesucht. Schlussendlich wird die Original-Festplatte zu Rate gezogen, falls die Daten noch immer nicht gefunden wurden.
• Lesezugriffe auf die zweite Festplatte erfolgen zunächst auf der aktuellen Delta-Festplatte Delta-HDD 2 #1. Werden die angeforderten Daten darin nicht gefunden, so wird als nächstes in der Original-Festplatte danach gesucht.

Im Laufe der Zeit werden erneut Parameter verändert (rot markiert):

• Änderung des Netzwerkzugriffs der ersten Netzwerkkarte auf VLAN 2
• Hinzufügen einer zweiten Netzwerkkarte mit Zugriff auf VLAN 6
• Änderung der Storage-Platzierungseinstellungen von Test auf Produktion

Problematik

Anhand der Funktionsweise der VMware Snapshots erkennt man relativ schnell, welche Problematiken sich bei deren Verwendung ergeben.

Alter

Werden VMware Snapshots entgegen den Empfehlungen über einen längeren Zeitraum aufbewahrt, besteht die große Gefahr, durch eine Wiederherstellung eines älteren Zustandes verschiedenste Einstellungen auf veraltete Werte zurückzusetzen. Da die Einstellungen von virtuellen Maschinen durch VMware-Administratoren relativ dynamisch geändert werden können, sollen und auch müssen, ändern sich über den Gesamt-Lebenszyklus eines VM-Containers auch ohne Beantragung durch einen Benutzer die Eigenschaften einer virtuellen Maschine von Zeit zu Zeit im Rahmen von Optimierungen und Infrastruktur-Updates.

Auch die vom Benutzer aktiv gewünschten Anpassungen an CPU-/RAM-Ressourcen, Festplatten und Netzwerkkarten werden gnadenlos auf alte Werte zurückgesetzt, ohne dass der Benutzer selbst die Möglichkeit hat, diese eigenständig wieder zu korrigieren.

An obigem Beispiel des Lebenszyklus der Maschine "VM1" lassen sich u.a. folgende "Horror-Szenarien" ableiten:

1. Die VM befindet sich aktuell im 4. Zustand (ganz rechts im Diagramm, also nach Snapshot 3).
   Wird die Maschine nun einfach auf Snapshot 3 zurückgesetzt, so gehen alle Änderungen, die seit der Erstellung von Snapshot 3 vorgenommen wurden, unwiederbringlich verloren! Inklusive aller veränderten Daten auf den Festplatten! Es sei denn, es wurde vor dem Zurücksetzen ein weiterer Snapshot angelegt, der wiederum den momentan aktuellen Zustand sichert.
   
   
2. Die VM befindet sich aktuell im 4. Zustand (ganz rechts im Diagramm, also nach Snapshot 3).
   Wird die Maschine auf Snapshot 3 zurückgesetzt, so verliert sie ihre zweite Netzwerkkarte (NIC 2) und die erste Netzwerkkarte (NIC 1) wird wieder von VLAN 2 auf VLAN 18 zurückgesetzt. Wurde nun in der Zwischenzeit die ehemals vom Betriebssystem benutzte IP-Adresse für NIC 1 bereits anderweitig vergeben, so entsteht ein IP-Adresskonflikt! Ganz abgesehen davon, dass nun die Informationen in der CMDB nicht mehr mit der aktuellen Konfiguration übereinstimmen.

Abgesehen von den eben angesprochenen "hochdramatischen" Situationen, die zu Datenverlusten oder IP-Adresskonflikten führen können, gibt es noch weitere mögliche Probleme. Wie man im Beispiel sieht, wurde insgesamt zwei mal ein VM Hardware-Upgrade durchgeführt (8 -> 9 -> 10). Dies geschieht in aller Regel transparent und ohne Interaktion des VM Benutzers und wird von den VMware-Administratoren bei Bedarf gescheduled. Die VM-Container führen dann beim nächsten Betriebssystem-Reboot das Upgrade automatisch durch. Für das Betriebssystem ändert sich an der sichtbaren Hardware nichts, jedoch werden bei solchen Upgrades in aller Regel vom Hersteller (VMware) diverse interne Optimierungen umgesetzt, die sich auch und vor allem in besserer Performance äußern.

Im allerschlimmsten Fall könnte es jedoch passieren, dass beim Zurücksetzen einer VM auf einen sehr sehr alten Snapshot eine Hardware-Version wiederhergestellt wird, die zwischenzeitlich nicht mehr kompatibel zu den Host-Systemen ist und damit die gesamte VM unbrauchbar macht.

Leider hat weder der Benutzer einer virtuellen Maschine, noch ein VMware-Administrator die Möglichkeit, die in einem Snapshot gespeicherten Zustandsdaten anzeigen zu lassen, d.h. man hat keinerlei Informationen über die durchgeführten Änderungen und welche Auswirkungen das Wiederherstellen eines alten Zustandes möglicherweise haben könnte.

Größe

Aufgrund der Delta-Festplatten Technik kann bei der Verwendung von VMware Snapshots der physikalische Speicherverbrauch auf dem Storage auf ein Vielfaches der eigentlich konfigurierten Plattengröße anwachsen. Jede einzelne Delta-Festplatte kann im schlimmsten Fall bis zur Größe der Original-Festplatte anwachsen, falls alle enthaltenen Daten einmal geändert wurden. Hat eine virtuelle Maschine beispielsweise eine Systemplatte mit 50 GB Größe, 3 Snapshots und zwischen jeder Snapshot-Erstellung wurden alle Daten der Festplatte einmal "durchgeschrubbt", so bedeutet dies eine maximale Festplatten-Snapshot-Größe von bis zu 3 * 50 GB = 150 GB zusätzlich zur Original-Festplatte!

Hinzu kommt dann noch der gespeicherte RAM-Inhalt, falls dieser ebenfalls mitgesichert wurde. Hierbei ist es unerheblich, wie viele Speicherseiten im RAM tatsächlich benutzt wurden, denn es wird immer der komplette konfigurierte und zur Verfügung gestellte RAM-Inhalt gespeichert. Bei einer VM mit 8 GB RAM bedeutet dies, dass ein Snapshot von Haus aus bereits mindestens 8 GB groß ist.

Jetzt mag sich der eine oder andere denken "Na und? WIr haben doch eh genug Storage.". Dies ist zwar bis zu einem gewissen Grad richtig, jedoch ist der reine Speicherplatzverbrauch nicht das größte Problem.

Wie bereits bei der Funktionsweise beschrieben, müssen beim Daten-Lesevorgang unter Umständen alle Delta-Festplatten in der Snapshot-Kette bis hin zur Original-Festplatte durchsucht werden. Dies bedeutet nicht nur eine erhöhte Lese-Latenz für die betroffene virtuelle Maschine, welche sich immer weiter erhöht, je größer und zahlreicher die Snapshots werden, sondern gleichzeitig auch ein erhöhtes Storage-Traffic Aufkommen auf dem Host-System und damit auch erhöhte Latenzen für alle anderen VMs auf diesem System. Diese Latenz steigt abermals weiter an, je mehr virtuelle Maschinen mit Snapshots gemeinsam auf einem Host-System laufen. Da der "Aufenthaltsort" der VM-Container jedoch hochdynamisch ist, kann die daraus resultierende Gesamt-Latenz nie genau vorhergesagt werden.

Auch das Entfernen von Snapshots eingeschalteter VMs kann mitunter zu einer recht langwierigen Aktion mit weiteren Latenzen bis hin zu kurzen "Aussetzern" ausarten, wenn diese zu groß geworden sind. Denn einen Snapshot entfernen bedeutet nicht, dass einfach nur irgendwelche Daten gelöscht werden müssen, sondern im Gegenteil vielmehr, dass die entsprechende Delta-Festplatte, die im Rahmen der Erstellung angelegt wurde, wieder in ihren "Vorgänger" reintegriert werden muss. Je größer die Delta-Festplatte also ist, desto länger dauert der Reintegrationsvorgang.

Im Falle von Delta-Festplatten, die derzeit nicht aktiv beschrieben werden (also alle bis auf die neueste) geschieht dies in der aktuellen vSphere Version (aktuelle VM Hardware-Version!) mittlerweile recht effizient und mit nur minimalen Latenzen. Muss jedoch die aktiv beschriebene Festplatte reintegriert werden (wenn also der neueste Snapshot gelöscht wird), so ist die Dauer des Vorgangs sowie die dadurch hervorgerufenen Latenzen zusätzlich stark abhängig von der aktuellen Festplatten-Schreibrate. Wenn also (z.B. bei Datenbanken mit extrem vielen Schreibzugriffen) mehr Daten aktiv auf die Festplatte geschrieben werden, als im Hintergrund reintegriert werden können, so könnte dies unter Umständen zu einem stundenlangen Prozess bis hin zum Abbruch wegen "Timeout" führen. Hier hilft zum Entfernen des Snapshots nur noch das Stoppen des Dienstes, der die exzessiven Schreibzugriffe durchführt, oder ein Herunterfahren der virtuellen Maschine. Im ausgeschalteten Zustand ist das Entfernen von Snapshots grundsätzlich kein Problem und funktioniert in 100% der Fälle reibungslos.

Management-Einschränkungen

Eine weitere Problematik, die bei der Verwendung von Snapshots auftritt ist, dass virtuelle Maschinen mit Snapshots gewissen Einschränkungen im Management (z.B. Konfigurations-Modifikationen) unterliegen. Einige davon sind für den Anwender nicht oder nicht unmittelbar sichtbar, andere hingegegen jedoch sehr wohl. Die beiden wichtigsten Einschränkungen sind:

1. Vorhandene virtuelle Festplatten lassen sich nicht vergrößern!
   Sollte aus irgendeinem Grund die Notwendigkeit einer Festplattenvergrößerung bestehen, so ist dies bei Vorhandensein von Snapshots technisch nicht möglich! Erst wenn alle Snapshots entfernt wurden, lässt sich die Konfiguration dementsprechend ändern.
   
   
2. VM-Container lassen sich auf Storage-Ebene nicht umbenennen.
   Muss der Name eines VM-Containers angepasst werden (was tunlichst vermieden werden sollte!), so lässt sich diese Änderung auf Storage-Ebene nicht umsetzen, d.h. sollte es aus einem managementtechnischen Grund notwendig sein, die VM im vCenter Server neu zu registrieren (Entfernen aus der Bestandsliste und erneutes Hinzufügen vom Storage), so ist es quasi unmöglich, die richtige virtuelle Maschine zweifelsfrei wiederzufinden, da sie im Management-Interface beim Deregistrieren bereits einen anderen Namen besaß und dieser so im Storage nicht zu finden ist.

Konsequenzen

• Am 01.12.2016 wurde ein Mechanismus zur Snapshot-Gleitlöschung eingeführt. Dieser wird einmal pro Tag automatisiert ausgeführt und löscht alle Snapshots, die ein gewisses Alter überschritten haben.
  Derzeit beträgt das maximale Standard-Höchstalter für VMware-Snapshots auf Kunden-VMs 3 Tage.

  Dieser Mechanismus ist keine Einladung bzw. kein Freifahrtschein für das unüberlegte Anlegen und Vergessen von Snapshots! Er soll lediglich dazu dienen einen maximalen Grenzwert zu definieren, den ein Snapshot keinesfalls überschreiten darf. Es gilt nach wie vor der Grundsatz, dass Snapshots nur so lange wie unbedingt erforderlich aufbewahrt werden sollten. Wird ein Snapshot vor Erreichen des maximalen Höchstalters nicht mehr benötigt, sollte dieser schnellstmöglich entfernt werden, um oben genannte Auswirkungen zu minimieren! Bei wiederholtem "Missbrauch" der VMware Snapshot-Funktion behalten sich die VMware-Administratoren vor, die zugehörige Berechtigung zu entziehen

• Am 06.08.2019 wurde die mögliche Anzahl an gleichzeitig vorhandenen Snapshots pro VM auf 2 limitiert.