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

    Produktionsprüfpunkte in Windows Server 2016 Hyper-VNeben den her­kömm­lichen Snap­shots bietet Hyper-V seit Windows Server 2016 auch Produk­tions­prüf­punkte. Diese Technik erlaubt anwen­dungs­kon­sistente Moment­auf­nahmen der virtu­ellen Maschinen. Im Bei­trag wird gezeigt, wofür sie sich eignen und wie man sie verwendet.

    Einer der vielen Vorteile virtualisierter Rechenzentren sind Checkpoints, vor Windows Server 2012 R2 "Snapshots" genannt, weil sie die unkomplizierte Rückkehr zu einem frühen Zustand von virtuellen Maschinen erlauben. Damit scheint der Einsatz­zweck dieser Technologie recht klar definiert. Bei diesem Thema gibt es jedoch immer wieder Raum für falsche Annahmen und Anwendung.

    Unterschiede zwischen Prüfpunkten und Backups

    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.

    Mit vssadmin lässt sich anzeigen, für welche Anwendungen ein VSS-Writer vorhanden ist.

    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.

    Die Optionen für Produktionsprüfpunkte lassen sich in den Einstellungen einer VM konfigurieren.

    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.

    Meldung nach dem erfolgreichen Erstellen eines Production Checkpoints.

    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"

    Produktionsprüfpunkte einer VM im Hyper-V Manager

    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.

    Die Verzeichnisstruktur zum Speichern der Snapshots hat sich bei den Production Checkpoints nicht geändert.

    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.

    Zu jedem Production Checkpoint gehören eine Konfigurationsdatei und ein Speicherabbild.

    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.

    Nach dem Anlegen eines Snapshots gehen alle Änderungen in eine differenzielle VHD(X).

    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.

    Keine Kommentare