Freigeben über


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

  • Anonymous
    January 01, 2003
    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
  • Anonymous
    January 01, 2003
    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
  • Anonymous
    November 11, 2014
    The comment has been removed