22.7 Erweiterte Möglichkeiten

Eine virtuelle Umgebung bietet gegenüber direkt auf Hardware installierten Betriebssystemen zahlreiche Vorteile, die das Admin-Leben unter Umständen signifikant einfacher machen.

22.7.1 Snapshots

Ganz weit vorn in der Liste der meistgewünschten Features landen Snapshots. Hierbei handelt es sich um zumeist im laufenden Betrieb erstellte Abbilder einer VM. Naheliegender Verwendungsfall ist das Erstellen eines Snapshots vor dem Einspielen von Patches bzw. ganz allgemein vor Updates.

Snapshot erstellen

Das Erstellen eines Snapshots ist geradezu trivial: Im Kontextmenü der VM klicken Sie auf Snapshot (Abbildung 22.64) und können dann in der Spalte Status die Erstellung verfolgen (Abbildung 22.65).

Abbildung 22.64 Hier wird ein Snapshot erstellt.

Abbildung 22.65 Während der Snapshot erstellt wird, sehen Sie hier den Fortschrittsbericht.

Zu überlegen ist, ob es genügt, einen Snapshot der laufenden Maschine zu machen, oder ob Sie sie zunächst herunterfahren und somit den Snapshot von der ausgeschalteten Maschine aufnehmen.

Hier die Vorteile und Nachteile:

• Der wichtigste Punkt ist, dass der Snapshot einer laufenden Maschine nicht wirklich konsistent ist. Schön, da auch der Arbeitsspeicher gesnapshottet wird, ist es in gewisser Hinsicht schon irgendwie ein wenig mehr als »crash consistent«, so wirklich perfekt und hundertprozentig konsistent ist aber nur ein Snapshot, bei dem die VM ausgeschaltet war.
• Bei verteilten Systemen werden Sie zum Einfrieren eines bestimmten Zustands (zum Beispiel »vor dem Update«) alle Systeme snapshotten müssen. Der »Gesamtsnapshot« ist notwendigerweise nur dadurch konsistent zu bekommen, dass Sie zunächst alle VMs herunterfahren und ausschalten.
• Snapshots können, trotz aller Konsistenzbedenken, vom laufenden System gemacht werden – ohne Betriebsunterbrechung. Und ganz ehrlich: lieber einen »nicht ganz konsistenten« Snapshot als gar keinen. Das soll natürlich kein Aufruf zur Schlamperei sein: Wenn Sie sich aber über die Konsistenzproblematik im Klaren sind und bewusst damit leben können, ist es besser, überhaupt Snapshots von einem bestimmten Zustand zu haben.

Snapshot anwenden

Nun wollen wir den schönen Snapshot ja auch anwenden, also die virtuelle Maschine in den Zustand zum Zeitpunkt des Snapshots zurückversetzen. Erfreulicherweise ist das mit einem Mausklick erledigt: Sie wählen den entsprechenden Snapshot aus und rufen in dessen Kontextmenü den Menüpunkt Anwenden auf (Abbildung 22.66).

Abbildung 22.66 Das Anwenden eines Snapshots wird im jeweiligen Kontextmenü initiiert.

Dann kommt eine wichtige Frage auf Sie zu (Abbildung 22.67), nämlich ob vor dem Anwenden des Snapshots noch ein Snapshot vom aktuellen Zustand erstellt werden soll. Das ist häufig gar keine schlechte Idee – Sie lassen sich so die Möglichkeit offen, nochmals zu dem jetzigen Zustand zurückzukehren. Mir hat das schon mal deutlich geholfen.

Abbildung 22.67 Vor dem Anwenden des Snapshots kann ein Snapshot vom aktuellen Zustand erstellt werden – man weiß ja nie, ob man vielleicht noch mal »zurück« muss.

Nun ist es so, dass sich beim Testen und Experimentieren komplexere Snapshot-Strukturen ergeben können. Wenn Sie einen Snapshot wiederherstellen und von diesem Zustand wieder einen Snapshot erstellen, ergibt sich, wenn Sie das ein paar Mal gemacht haben, beispielsweise eine Struktur wie die auf Abbildung 22.68 gezeigte. Und was wirklich großartig ist: Sie können jeden Snapshot-Zustand wiederherstellen.

Zu einem Szenario wie dem aus Abbildung 22.68 sind zwei Aspekte zu bedenken:

• Ja, es klappt. Es geht auch noch komplizierter.
• Sie verbraten jede Menge Festplattenplatz. Das ist erst mal nicht schlimm, nur auf die Dauer frisst es Sie auf. Denken Sie daran, nicht mehr benötigte Snapshots zu löschen.

Abbildung 22.68 Auch komplexere Snapshot-Strukturen sind möglich.

Wie im Kontextmenü des Snapshots auf Abbildung 22.66 zu sehen, gibt es Funktionen zum Löschen eines einzelnen Snapshots und einer kompletten Snapshot-Unterstruktur. Die inhaltliche Bedeutung der Menüpunkte dürfte so weit einleuchten. Dass es vor dem Löschen eines Snapshots eine Sicherheitsabfrage gibt, ist auch nicht so dramatisch überraschend (Abbildung 22.69).

Abbildung 22.69 Die Sicherheitsabfrage vor dem Löschen des Snapshots

Interessanter ist die Frage, was Hyper-V macht, um den Snapshot zu löschen. Vereinfacht gesagt, werden Änderungen in die Snapshot-Dateien geschrieben, nicht in das Original-Diskfile. Insofern bauen Originaldatei und Snapshot-Dateien aufeinander auf. Mit anderen Worten: So einfach mal eben schnell die Snapshot-Dateien löschen ist nicht. Vielmehr muss eine Zusammenführung durchgeführt werden. Das Ergebnis der Zusammenführung ist, dass die Snapshot-Dateien in die Disk-Datei integriert und dann gelöscht werden. In Abbildung 22.70 sehen Sie, dass gerade eine Zusammenführung durchgeführt wird. Wenn Sie genau hinsehen, erfolgt der Vorgang im laufenden Betrieb. Das ist deshalb bemerkenswert, da die Hyper-V-Vorgängerversion es erforderte, die virtuellen Maschinen für die Zusammenführung zu beenden. Wie Sie sehen, kann Hyper-V 2012 das im laufenden Betrieb erledigen – ein ziemlicher Fortschritt.

Abbildung 22.70 Die Zusammenführung geschieht im laufenden Betrieb.

22.7.2 VMs verschieben

Im Leben einer virtuellen Maschine wird es hin und wieder den Moment geben, in dem sie verschoben werden soll bzw. muss – zum Beispiel wenn ein Server zu Wartungszwecken »leer geräumt« werden soll, wenn die VMs anders aufgeteilt werden müssen oder wenn Ressourcenprobleme ein Verschieben nötig machen. Das Verschieben von laufenden VMs war lange Zeit eine Spezialität von VMware, Microsoft hat aber aufgeholt:

• Hyper-V 2008 R2 beherrscht Livemigration (der Name ist Programm), sofern die VMs auf SAN-Storage liegen.
• Hyper-V 2012 kann Livemigrationen auch ausführen, wenn sich die VM auf lokalen Festplatten befindet (beide beteiligten Hyper-V-Server müssen 2012er sein).

Das Verschieben einer VM im laufenden Betrieb ist nun sicherlich nicht das allein selig machende Feature – man muss aber zugeben, dass es nicht nur ganz beeindruckend, sondern sogar ziemlich beeindruckend ist. Schauen wir uns das also einmal genauer an:

• Im Kontextmenü der virtuellen Maschine findet sich der Menüpunkt Verschieben. Der war übrigens in der Vorgängerversion noch nicht da.

Die erste Dialogseite (abgesehen von der Willkommensseite) ist auf Abbildung 22.72 zu sehen. Hier geht es darum, ob der komplette virtuelle Computer zu einem anderen Server oder nur die Festplattendateien lokal auf dem Hyper-V-Server verschoben werden sollen. Letztgenannte Option ist beispielsweise sinnvoll, wenn Sie neue Laufwerke auf dem Hyper-V-Server eingerichtet haben und die VMs darauf »verteilen« möchten.

Abbildung 22.71 Im Kontextmenü der VM beginnt der Verschiebevorgang.

Abbildung 22.72 Erste Frage: Ganze VM auf einen anderen Server oder nur lokal den Speicher der VM verschieben?

Sofern Sie sich für das Verschieben der VM zwischen zwei Hyper-V-Hosts entscheiden, werden Sie auf der nächsten Seite des Dialogs nach dem Namen des Zielhosts gefragt (Abbildung 22.73). Auf dem Zielcomputer muss das Livemigration-Feature aktiviert sein – Anmerkungen dazu im Kasten weiter unten.

Abbildung 22.73 Der Zielcomputer

Der dann folgende Dialog (Abbildung 22.74) erfragt die Verschiebeoptionen. Im Grunde genommen geht es darum, festzulegen, ob die virtuellen Festplatten (VHDX-Dateien) an einen gemeinsamen Speicherort oder an individuelle Orte verschoben werden sollen. Wenn die Daten auf einem SAN-Storage-System liegen, wählen Sie die dritte Option, bei der die Plattendateien nicht bewegt werden. Bei den beiden erstgenannten Optionen werden die Dateien im laufenden Betrieb über das LAN transportiert.

Abbildung 22.74 Die Verschiebeoptionen

Bei der in Abbildung 22.74 gezeigten Auswahl müssen Sie nun noch den Speicherort auf dem neuen Hyper-V-Host angeben – das war’s (Abbildung 22.75). Der Dialog, der über den Schalter Durchsuchen aufgerufen wird, zeigt übrigens tatsächlich das Dateisystem des Zielservers. Zur Information wird die benötigte Speichergröße (in diesem Fall 20,47 GByte) angezeigt. Die Kapazitätsanzeige ist ganz praktisch, da man häufig nicht so genau abschätzen kann, wie viel Speicherplatz wirklich benötigt wird. Durch bestehende Snapshots beispielsweise wird das schnell ein wenig unübersichtlich.

Abbildung 22.75 Auswahl des Speicherorts, an dem die verschobene VM auf dem neuen System gespeichert wird.

Abbildung 22.76 zeigt, dass Microsoft den Begriff Livemigration wirklich mit Leben gefüllt hat: Während des Verschiebevorgangs ist die virtuelle Maschine erreichbar. Das ging bei Hyper-V 2008 R2 bereits beim Einsatz von SAN-Storage, bei Hyper-V 2012 funktioniert das auch beim Verschieben übers Netz, also zwischen zwei Hyper-V-Hosts mit lokalem Plattenspeicher.

Abbildung 22.76 Kleiner Beweis gefällig? Während des Verschiebevorgangs ist die VM erreichbar.

Wenn Sie mein 2008 R2-Buch genau gelesen haben, wird Ihnen vielleicht noch die Passage in Erinnerung sein, in der ich gesagt/geschrieben habe, dass das Verschieben von VMs im laufenden Betrieb nun nicht wirklich vordringlich wichtig ist. Da es nun aber auch bei Einsatz von lokalem Storage geht, ist es schon ganz nett!

22.7.3 Exportieren/Importieren

Da sich die Fragestellung immer wieder ergibt: Wenn Sie eine virtuelle Maschine exportieren möchten, geht das nur über die Exportfunktion (Abbildung 22.78). Einfach die VHDX-Dateien zu kopieren, genügt nicht. Wenn Sie beispielsweise aktive Snapshots haben, sind die VHDX-Dateien recht wertlos.

Leider ist der Export einer virtuellen Maschine nur möglich, wenn diese ausgeschaltet ist – eigentlich aber auch ganz sinnvoll, denn sonst wäre der Export nicht konsistent. Bei laufenden VMs steht die auf Abbildung 22.78 gezeigte Option gar nicht erst zur Verfügung.

Abbildung 22.78 Virtuelle Maschinen exportieren? Nur über diese Option!

Beim Exportieren müssen Sie nur das Exportverzeichnis angeben – der wirklich wenig spektakuläre Dialog ist in Abbildung 22.79 zu sehen. Anzumerken ist, dass unterhalb des dort ausgewählten Verzeichnisses ein Unterverzeichnis mit dem Namen der VM erstellt wird. Falls dieses schon vorhanden ist, erscheint eine Fehlermeldung.

Abbildung 22.79 Mehr, als das Exportverzeichnis anzugeben, brauchen Sie nicht zu tun.

22.7.4 Einfache Sicherung/Wiederherstellung

Ein wesentlicher Vorteil der Virtualisierung ist die recht einfache Sicherung und Rücksicherung von VMs. Eine VHDX-Datei zu sichern und vor allem wiederherzustellen, ist wesentlich einfacher zu bewerkstelligen als die Komplettwiederherstellung einer direkt auf Hardware basierenden Betriebssysteminstanz. Jeder, der schon einmal »unter Druck« komplett ein System auf anderer Hardware aus der Datensicherung wiederherstellen musste, weiß, was ich meine.

Nun könnten Sie natürlich die virtuellen Maschinen, wie im vorherigen Abschnitt gezeigt, einfach exportieren. Der Haken ist aber, dass die VM dazu beendet sein muss. Zur Sicherung komplett die Maschine herunterfahren? Geht ja gar nicht! Wir haben 2013 und nicht 1987!

Wir brauchen also ein Stück Software, das eine VM im laufenden Betrieb sichern kann. Gute Nachrichten, denn Windows Server 2012 hat eine solche Software in Form der Windows Server-Sicherung als nachinstallierbares Feature an Bord.

Wie auf Abbildung 22.80 zu sehen ist, kann die Funktion über den Assistenten zum Hinzufügen von Rollen und Features, der wie üblich über den Server-Manager zu erreichen ist, unter Features installiert werden.

Abbildung 22.80 Mit dem Server-Manager kann die »Windows Server-Sicherung« installiert werden – ein Feature.

Die Sicherungssoftware ist mit einer grafischen Konsole, alternativ natürlich mit der PowerShell, zu bedienen. In Abbildung 22.81 ist zu erkennen, dass man sowohl eine Einmalsicherung als auch eine wiederkehrende Sicherung (Sicherungszeitplan) durchführen kann. Die Möglichkeit, einen Sicherungszeitplan zu erstellen, ersetzt nun zwar nicht eine »richtige« Backup-Software, die dann auch Kataloge verwaltet, auf Band sichern kann und dergleichen mehr, wenn Sie jedoch einigermaßen geringe Ansprüche an das Management der Sicherungslösung haben, kann man mit dem Tool durchaus einiges anfangen – zumindest gezielt Hyper-V-VMs sichern.

Abbildung 22.81 Die grafische Verwaltung der Windows Server-Sicherung

Der Assistent für die Sicherung kann zum einen eine vollständige Sicherung initiieren, alternativ können auch einzelne Elemente, unter anderem Hyper-V-VMs, ausgewählt werden. Dazu aktivieren Sie dann in dem auf Abbildung 22.82 gezeigten Dialog die Option Benutzerdefiniert.

Abbildung 22.82 Sie können den kompletten Server sichern. Wir wollen hier aber nur eine VM sichern.

Die Auswahl für die zu sichernden Elemente sehen Sie auf Abbildung 22.83. Im Grunde genommen gibt es dazu nichts Aufregendes zu sagen – Sie können eine oder mehrere virtuelle Maschinen zur Sicherung auswählen. Erfreulicherweise können sowohl angehaltene als auch laufende VMs gesichert werden. Das ist bei regelmäßigen Sicherungsaufträgen natürlich einigermaßen wichtig – kein Problem, es klappt!

Abbildung 22.83 Gezielte Auswahl der Sicherung einer einzelnen virtuellen Maschine

Auf der nächsten Seite des Assistenten (Abbildung 22.84) können Sie entscheiden, wohin gesichert werden soll. Erste Feststellung: Eine Sicherung auf Tape ist nicht möglich. Sie können entscheiden, ob Sie auf ein lokales Laufwerk oder auf eine Dateifreigabe sichern möchten. Da Server wohl in den seltensten Fällen lokale (USB-)Sicherungsplatten haben werden, dürfte die Sicherung auf eine Netzwerk-Share die Methode der Wahl sein.

Abbildung 22.85 zeigt den Dialog, der bei Auswahl des Sicherungsziels Netzwerkfreigabe erscheint. Angegeben wird ein UNC-Pfad. Sie müssen sicherstellen, dass die Berechtigungen »passen«, und zwar sowohl bei den NTFS- als auch bei den Freigabeeinstellungen. Das zu verwendende Konto wird übrigens im nächsten Schritt abgefragt.

Abbildung 22.84 Es ist sinnvoll, auf eine Netzwerk-Share zu sichern.

Interessant ist die Einstellung zur Zugriffssteuerung auf dieser Dialogseite: Wenn Nicht vererben gewählt wird, werden die NTFS-Berechtigungen so gesetzt, dass nur das die Sicherung durchführende Konto berechtigt ist.

Abbildung 22.85 Eingabe des UNC-Pfads und der Berechtigung

Das Ergebnis der auf Abbildung 22.86 gezeigten Kontoabfrage dient zwei Zwecken:

• Dieses Konto wird für die Durchführung der Sicherung verwendet.
• Wenn die zuvor gezeigte Einstellung auf Nicht vererben gesetzt ist, wird diese Identität berechtigt.

Abbildung 22.86 Eingabe des Benutzerkontos, mit dem auf die File-Share zugegriffen wird

Im Hyper-V-Manager kann man übrigens während des Sicherungsvorgangs mitverfolgen, was gerade passiert (siehe Abbildung 22.87 und Abbildung 22.88):

• Zunächst wird ein VSS-Snapshot erstellt (Abbildung 22.87). Diesen Snapshot, der dann hinterher gesichert wird, erstellt die laufende virtuelle Maschine – um es deutlich zu sagen: Keine Downtime! Sollte die VM nicht laufen, wird der Snapshot eben von der heruntergefahrenen Maschine erstellt.
• Nach dem Erstellen des Snapshots wird dieser dann gesichert (Abbildung 22.88) – natürlich auch bei aktiver VM.

Abbildung 22.87 Zunächst sieht man, dass ein VSS-Snapshot erstellt wird ...

Abbildung 22.88 ... der dann gesichert wird.

Hyper-V-Sicherung genügt unter Umständen nicht

Ganz dringend möchte ich darauf hinweisen, dass es bei vielen Servern nicht genügt, nur die Hyper-V-Sicherung zu machen.

Bei Applikationsservern, die keine Daten speichern, dürfte es genügen, die Hyper-V-Sicherung durchzuführen.

Bei datentragenden Servern ergibt aus Gründen der einfachen und schnellen Wiederherstellung die Durchführung der Hyper-V-Sicherung durchaus Sinn. Allerdings werden Sie zusätzlich die Daten »in der virtuellen Maschine« sichern wollen/müssen. Dafür gibt es im Wesentlichen diese Gründe:

• Wenn einzelne Dateien wiederhergestellt werden sollen, wäre es sehr unbequem, wenn zuerst die komplette VM hergestellt werden müsste.
• Viele datentragende Server (SQL, Exchange etc.) müssen speziellen Sicherungsprozeduren unterzogen werden, um beispielsweise Logfiles abzuschneiden. Wenn Sie das beispielsweise bei SQL Server nicht tun, werden die LDF-Dateien unbegrenzt groß werden – zumindest so lange, bis die Platten voll sind.

Fazit: Es ist also durchaus sinnvoll, sowohl die Hyper-V- als auch die Sicherung der Daten in der virtuellen Maschine durchzuführen.

Andere Backup-Software

In einer größeren Umgebung würden Sie vermutlich wenig begeistert sein, wenn auf jedem Hyper-V-Host die Sicherung individuell verwaltet werden müsste. In diesem Fall werden Sie also mit Sicherheit nicht mit Bordmitteln sichern, sondern eines der zahlreichen Backup-Softwareprodukte einsetzen. Jede ernst zu nehmende Backup-Lösung kann heute Hyper-V-Hosts sichern. Eine Möglichkeit wäre beispielsweise Microsofts Data Protection Manager – vermutlich kann aber auch Ihre vorhandene Sicherungssoftware diese Aufgabe übernehmen.

---

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular