Produktionsprüfpunkte unter Hyper-V 2016: Funktionsweise und Anwendung

Checkpoints, im Speziellen beim Standardverfahren, ersetzen generell keine Backups. Letztere sollen die Daten mindestens einmal verdoppeln, um einen defekten primären Datenbestand durch die Rücksicherung eines sekundären wieder in einen intakten Zustand zu versetzen.

Aber Checkpoints (Prüfpunkte) verdoppeln den Datenbestand naturgemäß nicht, sondern erzeugen eine Momentaufnahme (Point-in-time), zu der man im Worst Case einfach wieder zurückspringen kann. Alle Delta-Daten, welche bis dahin erzeugt wurden, gehen (leicht) verloren (außer ein neuer Prüfpunkt wurde beim Anwenden erstellt, es besteht auch die Möglichkeit Prüfpunkte zu exportieren).

Es gibt dabei keinen Backup-Planer, keine automatisch getrennte Datenhaltung oder Logfile-Kürzung, keine Deduplizierung, kein Change Tracking, keine Verschlüsselung, keinerlei Konsistenzprüfung und auch keine geeignete granulare Wiederherstellung.

Herkömmliche Snapshots im Vergleich zu Produktionsprüfpunkten

Prüfpunkte von virtuellen Maschinen können online (VM eingeschaltet) oder offline erstellt werden. Sie erlauben uns im Fall eines Fehlverhaltens oder Tests eine Rolle rückwärts. Zu diesem Zweck halten Standard­prüfpunkte eben eine Moment­aufnahme der Online-VM samt Arbeitsspeicher von außen fest. Doch genau das kann im Fall einer Rückwärts­rolle bei verteilten Anwendungen wie Active Directory, SQL oder Exchange zu Problemen führen.

Standardprüfpunkte sind sinnvoll in Lab- und Testumgebungen, in den meisten Fällen aber nicht im produktiven Umfeld! Werden Prüfpunkte online erstellt, dann speichern sie den Zustand des virtuellen Computers inklusive Konfiguration und seiner Daten, die sich aktuell im Arbeitsspeicher befinden. Bei einem Rücksprung zu einem Punkt in der Vergangenheit wird genau dieser Zustand wiederhergestellt.

Diese VM und deren Anwendung, welche die Daten zum entsprechenden Zeitpunkt im Arbeitsspeicher gehalten hat, weiß nichts von diesem Rücksprung und erwartet die gleichen Bedingungen wie in der Vergangenheit. Unerwartete Fehler und Inkonsistenzen können die Folge sein.

Produktions­prüfpunkte (Production Checkpoints) gehen einen Schritt weiter und interagieren über die Integrationsdienste mit dem Volume Shadow Copy Service (VSS) im Gast-OS, bewahren also wie anwendungs­konsistente Backups den konsistenten Zustand einer VM zum Zeitpunkt ihrer Erstellung. Es werden nur der Status der virtuellen Festplatte plus die Konfiguration zur virtuellen Maschine festgehalten, nicht aber deren Arbeitsspeicherinhalt.

Voraussetzung für Anwendungskonsistenz ist, dass ein VSS-Writer für die jeweilige Applikation in der virtuellen Maschine existiert und dementsprechend ausgelöst werden kann. Die VM-Konfigurationsversion muss zudem größer 6.2 sein und speziell bei migrierten Maschinen nötigenfalls angehoben werden.

Ein Rücksprung, also das Anwenden (apply) eines Prüfpunktes, bewirkt immer einen Kaltstart der VM vom ausgeschalteten Zustand heraus. Somit erreicht man durch Production Checkpoints einen konsistenten Zustand des virtuellen Computers samt Dateisystem und Anwendung. Microsoft akzeptiert diese Technik auch beim Support.

Erzeugen eines Produktionsprüfpunktes

Prüfpunkte können allgemein aus dem Hyper-V Manager pro VM oder mit PowerShell erstellt und konfiguriert werden. Stehen wir im Failovercluster-Manager, dann erreicht man diese auch über einen VMConnect. In den Einstellungen für den virtuellen Computer befinden sich dann die Optionen für die Prüfpunkte.

Standardmäßig sind diese aktiv und der Radio-Button steht auf Produktions­prüfpunkte. Können Produktions­prüfpunkte nicht erzeugt werden und die Checkbox zum alternativen Erstellen von Standard­prüfpunkten ist gesetzt, werden diese anstelle von Production Checkpoints generiert. Dieses Verhalten möchte ich verhindern und deaktiviere die Checkbox.

Um einen Prüfpunkt zu erzeugen, klicke ich in meine Liste der virtuellen Computer mit der rechten Maustaste auf die betreffende VM, und im folgenden Kontextmenü kann ich ihn über den Eintrag Prüfpunkt erzeugen.

Die oben beschriebenen Einstellungen lassen sich alternativ mit PowerShell so konfigurieren:

Set-VM -Name "VM-NAME" -CheckpointType ProductionOnly

Den Prüfpunkt erstellt man dann folgendermaßen:

Checkpoint-VM -Name "VM-NAME" -SnapshotName "CHECKPOINT-NAME"

Im Konfigurations­fenster für die Prüfpunkte lässt sich auch der Speicherort ablesen. Da ich dieses Fenster über den Hyper-V Manager anstatt mit der obersten Instanz des Failovercluster-Manager geöffnet habe, erhalte ich den Hinweis, dass sich der Speicherort nicht anpassen lässt. Da die VM eingeschaltet ist und schon Checkpoints vorhanden sind, kann dieser Ort aber ohnehin nicht unmittelbar geändert werden.

Welche Dateien werden bei einem Produktionsprüfpunkt erzeugt?

Werfen wir einen Blick in den VM-Ordner auf einem Cluster Shared Volume. Auch wenn Windows Server 2016 bei Checkpoints strukturelle Änderungen mit sich bringt, hat der Name Snapshots hier weiterhin Bestand und beherbergt unsere Checkpoint-Dateien.

Nachdem ein Prüfpunkt erstellt wurde, befinden sich im Snapshots-Ordner eine zugehörige VMCX- und VMRS-Datei. Diese ersetzen jetzt bisherige XML-, BIN- und VSV-Dateien von Windows Server 2012 R2. Eine VMCX beinhaltet die Informationen zur VM-Konfiguration und zu den Dateien des Checkpoints.

Das VMRS-File nimmt den Speicherinhalt und den Gerätestatus auf. Wenn ein Produktions­prüfpunkt erzeugt wird, dann bleibt die Datei relativ klein. Diese Tatsache dient mir auch als Indikator für das mögliche Vorhandensein eines Production Checkpoints.

Im Ordner der Virtual Hard Disks gesellt sich zur ursprünglichen VHDX (Parent) nach Erstellung eines Checkpoints nun auch eine dynamische AVHDX-Datei. Diese Vorgehens­weise hat sich mit Server 2016 nicht geändert, die VHDX wird zum Zeitpunkt des Checkpoints eingefroren und später nur noch lesend verwendet.

Alle Änderungen nach dem Checkpoint fließen in die AVHDX-Datei. Kommt noch ein Checkpoint hinzu, wird zur vorhandenen AVHDX eine weitere erstellt, welche von nun an alle Änderungen aufnimmt.

Parent VHDX-Daten und folgende Differenzdaten gehören somit eng zusammen und ergeben den Gesamtdatenbestand. Werden die Checkpoints aufgelöst und gelöscht, wird die AVHDX mit der VHDX online verschmolzen (merging). Die Geschwindigkeit mit der dieser Prozess ausgeführt wird, ist abhängig vom Dateisystem (siehe dazu: NTFS versus REFS).

Springt man zum Zustand vor dem Checkpoint, dann gehen alle Änderungen verloren und die AVHDX wird zurückgesetzt, bleibt aber aktiv. Kam die Technik zur Erstellung eines Production Checkpoints zum Einsatz, muss die VM anschließend manuell gestartet werden. Ihr Zustand ist ähnlich eines Clean Shutdowns.