vNext: Production Checkpoints


Im ersten Release von Hyper-V wurden Snapshots zur Zustandssicherung von virtuellen Maschinen eingeführt. Dieser auf Saved-States basierte Schutz ermöglichte es von einzelnen virtuellen Maschinen durch das Setzen von Snapshots Punkte zu erzeugen, auf die man später zurück kehren konnte (Point-in-Time Recovery). Die technischen Details dazu sind schnell erklärt:

Jedes Mal, wenn ein Snapshot einer virtuellen Maschine erstellt wird, wird eine neue differenzielle Festplatten-Datei (.avhdx) zur Original-Festplatte der VM erzeugt. Alle Änderungen an der VM werden ab sofort in diese neue differenzielle Festplatten-Datei geschrieben. Möchte man zum Ursprungszustand zurückkehren wurden erstellte Snapshots angewendet, was nichts anderes bedeutet, als dass die erstellte Änderungsdatei gelöscht wurde und die VM "nur" mit der Original-Festplatte gestartet wurde.

Wurde der Snapshot gelöscht, wurde die differenzielle Disk mit der Original-Disk zusammengeführt und eine Rückkehr zum Snapshot war nicht mehr möglich.

Snapshots haben im Laufe der Zeit und Hyper-V Versionen zwar einige Verbesserungen erfahren, so können Sie mittlerweile online zusammengeführt werden und sie wurden aus Konsistenzzwecken umbenannt zu Checkpoints, für produktive Workloads waren sie aber nie richtig empfohlen.

Der Grund dafür ist ein relativ simpler:

Die Workloads in der virtuellen Maschine haben von den an der virtuellen Maschine vorgenommenen Checkpoint-Operationen fast nichts mitbekommen. Dies lässt insbesondere für Anwendungen wie Exchange Server und co einige Risiken offen. Für Active Directory Domain-Controller wurde daher mit Windows Server 2012 zusätzliche Maßnahmen zur Konsistenzsicherung getroffen.

Die mit der Technical Preview eingeführten Production Checkpoints bietet nun workloadunabhängigen Schutz, in dem sie nicht auf Saved-States sondern auf VSS setzen. Production Checkpoints nutzen daher die gleichen Mechanismen wie Backup-Software (Bei Linux-Systemen wird der Dateisystem-Cache geleert). Jeder Workload, der VSS Backups unterstützt, sollte damit auch Production-Checkpoints unterstützen können.

Die Konfiguration für Checkpoints ist sehr granular geworden. Sie können vollständig deaktiviert werden und die Art des Checkpoints kann ausgewählt werden, die bisherigen Checkpoints heißen nun Standard-Checkpoints.

In der Standard-Konfiguration sind Checkpoints aktiv, primär werden Production Checkpoints erstellt und im Fehlerfall wird versucht einen Standard-Checkpoint zu erstellen (z.B. bei VSS Fehlern).

Nach einem Restore eines Production-Checkpoints sieht eine VM genauso aus, wie aus einem Backup wiederhergestellt, sie ist also im Gegensatz zum Standard-Checkpoint ausgeschaltet.

Achtung: Auch wenn Checkpoints nun "Backup-Technologie" nutzen, können Sie den Einsatz einer ganzheitlichen Backupstrategie und deren Produkte nicht ersetzen.


Comments (3)
  1. Hallo,
    um den Status für lange Zeit einzufrieren eignen sich Backups besser als Checkpoints.
    Es werden weiterhin ab dem Erstellungszeitpunkt des Checkpoints alle Schreibzugriffe in eine neue, differenzielle virtuelle Festplatte umgeleitet, das ist streng genommen kein Problem, sondern die Funktionsweise des Features. Daher auch die Zielsetzung Checkpoints
    nicht zu lange aufzubewahren, sie sind eher für eine kurzfristige Zustandssicherung geeignet.

    Beste Grüße,
    Benedict Berger

  2. Hallo,
    um den Status für lange Zeit einzufrieren eignen sich Backups besser als Checkpoints.
    Es werden weiterhin ab dem Erstellungszeitpunkt des Checkpoints alle Schreibzugriffe in eine neue, differenzielle virtuelle Festplatte umgeleitet, das ist streng genommen kein Problem, sondern die Funktionsweise des Features. Daher auch die Zielsetzung Checkpoints
    nicht zu lange aufzubewahren, sie sind eher für eine kurzfristige Zustandssicherung geeignet.

    Beste Grüße,
    Benedict Berger

  3. Markus Rödel says:

    Frage: Das mit den Checkpoints verbundene Problem, dass die differenzierenden Platten stetig anwachsen ist damit aber doch nicht behoben, oder? Bei uns würden Entwickler gerne den Status einer VM über lange Zeit einfrieren, was aber dazu führt, dass wir
    dann mit sehr großen .avhdx zu kämpfen haben, die die Größe der eigentlich VM weit überschreiten. Bisher ist die Alternative nur, von der VM einen Klon zu erstellen und den dann ‘auf die Seite’ zu legen.

    Viele Grüße,
    Markus

Comments are closed.

Skip to main content