Desaster Recovery bezieht sich auf Strategien und Aktionen, die der Wiederherstellung von IT-Systemen nach einem katastrophalen Ereignis dienen – sei es durch Naturkatastrophen, Hardwareausfälle oder Cyberangriffe. Ziel ist es, den Datenverlust zu minimieren und die Dienste so schnell wie möglich ins Laufen zu bekommen. Hyper-V ist Microsofts Servervirtualisierung, die es ermöglicht, mehrere virtuelle Maschinen (VMs) auf einem einzigen physischen Host auszuführen. Da VMs oft kritische Geschäftsanwendungen und Daten enthalten, ist ihre schnelle und zuverlässige Wiederherstellung nach einem Desaster von entscheidender Bedeutung.

Microsoft bietet dabei mit Azure eine robuste und skalierbare Cloudplattform, die sich ideal für DR-Szenarien eignet, insbesondere in Kombination mit Hyper-V, aber auch für andere Hypervisoren. In diesem Artikel beleuchten wir den Prozess des Hyper-V Desaster Recovery nach Azure. Azure Site Recovery (ASR) ist Microsofts Dienst für Desaster Recovery als Service (DRaaS). Mit ASR können Unternehmen ihre Hyper-V-VMs in Azure replizieren und bei Bedarf wiederherstellen. Dies bietet einen nahtlosen Übergang im Notfall und ermöglicht es Unternehmen, ihre Ressourcen schnell in der Cloud hochzufahren.

Für unseren Workshop haben wir auf einem Windows Server 2019 mittels Hyper-V einen virtuellen Server eingerichtet und diesen in eine Azure-Subscription repliziert. Dabei kam eine vorhandene Azure-Umgebung zum Einsatz. Es ist aber auch möglich, einen kostenloses Azure-Abonnement [1] abzuschließen und mit einem Startguthaben von 200 US-Dollar loszulegen.

Das Einrichten von ASR für Hyper-V erfordert mehrere Schritte und wir beginnen in Azure. Das Anmeldekonto in Azure muss eine VM in der ausgewählten Ressourcengruppe sowie im ausgewählten virtuellen Netzwerk erstellen können. Hierfür benötigt der Benutzer die Rechte "Mitwirkender von virtuellen Computern". Für die Verwaltung der Recovery-Vorgänge benötigen wir weiter "Site Recovery-Mitwirkender"-Rechte. Wir arbeiten mit dem Standardadministrator der Umgebung, wodurch wir automatisch über alle nötigen Rechte verfügen.

Zur Vorbereitung in Azure legen wir zunächst ein eigenes Speicherkonto, eine Ressourcengruppe, den Recovery-Services-Tresor sowie ein virtuelles Netzwerk an. Um die Abbilder der virtuellen Maschinen ablegen zu können, ist außerdem ein Speicherkonto in Azure nötig. Hierfür klicken wir im Azure-Startbildschirm auf "Ressource erstellen" und wählen in der Kategorie "Speicher" den Punkt "Speicherkonto erstellen". Ein Assistent führt im Folgenden durch die Einrichtung des Diensts. Neben dem Abonnement, dem Namen und der Region, müssen wir auch eine Ressourcengruppe auswählen. Hier erstellen wir eine neue Gruppe, in der wir ebenfalls alle weiteren Dienste anlegen. Für die Redundanz nutzen wir den "Georundanten Speicher". Anders als bei Redundanzen in der primären Region werden die Daten bei dieser Option in eine zweite Region über hunderte Kilometer entfernt von der primären Region asynchron kopiert.

Im nächsten Schritt erstellen wir den Recovery-Services-Tresor, in dem Metadaten und Konfigurationsinformationen für die VMs landen. Der Dienst wird über den Eintrag "Recovery Services-Tresor" auf der Startseite von Azure ins Leben gerufen. Hier sind wieder Subskription, Region, Ressourcengruppe sowie ein Name für den Tresor anzugeben. Der Tresor ist schnell eingerichtet und für unsere Umgebung legen wir noch eine Netzwerkumgebung über den Punkt "Virtuelles Netzwerk" an, mit dem die VM nach einem Failover verknüpft werden.

Neben den Standardparametern wie Name und Ressourcengruppen definieren wir auch den Netzwerkbereich, in dem die VM später läuft. In unserem Fall sind das lokale Netzwerk und das virtuelle Netzwerk in Azure nicht verknüpft, eine Verbindung über Azure-VPN lässt sich aber einrichten, sodass für Clients ein nahtloses Weiterarbeiten im lokalen Standort möglich ist. Damit sind die Vorbereitungen für Azure zunächst abgeschlossen und im nächsten Schritt bereiten wir den lokalen Hyper-V-Server vor.

Das Nutzen von Hyper-V-Server ist ab Windows Server 2012 R2 möglich. Als Gastbetriebssystem kommen für eine Replikation alle Betriebssysteme in Frage, die von Azure unterstützt und dort ausgeführt werden können. Darüber hinaus benötigt der Hyper-V-Server zur Replikation eine Internetverbindung zu verschiedenen Ressourcen. Dazu zählen unter anderem "*.hypervrecoverymanager.windowsazure.com" für die Replikation und "*.blob.core.windows.net" für den Speicher. Als Port kommt nur HTTPS (443) zum Einsatz. Informationen zu den Webseiten und zu den erweiterten Anforderungen finden Sie unter [2].

Neben dem Internetzugriff müssen Sie darauf achten, dass der Fernzugriff für die virtuellen Maschinen aktiviert ist, um auf die Server in Azure nach einem Fail­over zugreifen zu können. Auf unserem Windows-Testserver haben wir hierfür RDP aktiviert. Mehr ist in der lokalen Umgebung zunächst nicht zu berücksichtigen.

Im nächsten Schritt bereiten wir die Azure-Infrastruktur vor, bevor wir die Notfallwiederherstellung lokaler virtueller Hyper-V-Computer in Azure einrichten. Hierfür navigieren Sie in Azure zu Ihrem Recovery-Services-Tresor. Im Menüpunkt "Site Recovery" wählen Sie unter der Kachel "Hyper-V-Computer zu Azure" die Option "Infrastruktur vorbereiten" aus.

Im Assistenten wählen wir zunächst, dass die Bereitstellungsplanung "später durchgeführt" wird. Der Azure-Site-Recovery-Bereitstellungsplaner hilft grundsätzlich beim Ermitteln der benötigten Bandbreite und des benötigten Azure-Speichers. Im Rahmen unseres Workshops ist dies nicht relevant. In der Azure-Dokumentation ist dem Tool ein ausführlicher Beitrag gewidmet. Im nächsten Schritt wählen wir aus, dass wir System Center VMM zum Verwalten unserer Hyper-V-Hosts nicht verwenden. Hierdurch müssen wir nun einen Hyper-V-Standort eintragen. Da bisher keiner eingerichtet ist, erstellen wir einen neuen namens "itadministratorHyperVSite".

Bis zu diesem Schritt ist unserer lokaler Hyper-V-Host in Azure nicht bekannt. Über den Eintrag "Hyper-V-Server hinzufügen" öffnet sich ein kleines Fenster, über das sich der "Microsoft Azure Site Recovery-Anbieter" und der Tresorregistrierungsschlüssel herunterlegen lassen. Lokal führen wir den Installationsassistenten aus und binden die Registrierung ein. Die Einrichtung findet in wenigen Schritten statt und zukünftig kümmert sich unter anderem der "Microsoft Azure Site Recovery Service" um die Replikation. Der Server wird während der Installation in Azure unter "Site Recovery-Infrastruktur / Hyper-V-Hosts" hinzugefügt. Es kann etwas dauern, bis die neu hinzugefügten Server verfügbar sind.

Im Anschluss können Sie in den Quelleinstellungen des Einrichtungsassistenten den Hyper-V-Host eintragen. Im weiteren Verlauf des Assistenten folgen die Zieleinstellungen. Dabei wählen Sie das Abonnement und das Bereitstellungsmodell aus. Wir greifen beim Modell auf den "Ressource Manager" zurück. Dies ist das Standardmodell, die Alternative ist die "klassische" Bereitstellung. Um die Bereitstellung und Verwaltung zu vereinfachen, empfiehlt Microsoft die Verwendung des "Ressource Manager" für alle neuen Ressourcen. Auf der Registerkarte "Replikationsrichtlinie" erstellen wir eine neue Richtlinie. Diese definiert die Einstellungen für den Aufbewahrungsverlauf von Wiederherstellungspunkten und die Häufigkeit von anwendungskonsistenten Momentaufnahmen.

In der Policy definieren wir die Quelle "Hyper-V", das Ziel "Azure", die Kopierhäufigkeit von "5 Minuten" sowie die Aufbewahrung von Wiederherstellungspunkten in Stunden "2" und die Häufigkeit appkonsistenter Momentaufnahmen in Stunden "1". Als Startzeitpunkt der Replikation wählen wir "Sofort" aus. Die neue Richtlinie bestätigen wir mit "OK". Im nächsten Schritt des Einrichtungsassistenten wird die Gesamtkonfiguration noch einmal dargestellt und wir schließen diese mit "Erstellen" ab.

Nach Abschluss der Infrastrukturvorbereitung kann die Replikation der virtuellen Computer beginnen. Dies erfolgt über den Eintrag "Replikation aktivieren" wieder im Menüpunkt "Site Recovery". Im Aktivierungsassistent durchlaufen wir sechs Register. Im ersten Reiter wählen wir unseren erstellten Hyper-V-Quellstandort "itadministratorHyperVSite" aus. In der Zielumgebung werden erneut das Abonnement, die Ressourcengruppen und Bereitstellungsmodell nach einem Failover sowie ein Speicherkonto abgefragt. Die Einstellungen lassen sich später ebenfalls in der replizierten VM in Azure anpassen.

Im nächsten Schritt geben wir die zu replizierende VM der lokalen Umgebung an. Wir wählen hier unseren lokalen Testserver aus. Auf der Registerkarte "Replikationseinstellungen" teilen wir die Datenträgerdetails mit. Im nächsten Schritt wählen wir noch unsere Replikationsrichtlinie aus und schließen im Weiteren die Einrichtung über "Replikation aktivieren" ab. Die Einrichtung ist damit abgeschlossen und der Server wird in die Azure-Umgebung repliziert. Die erste Replikation nimmt etwas Zeit in Anspruch und die verschiedenen Status sind in Azure dargestellt.

Im Recovery-Service-Dashboard finden Sie alle Überwachungsinformationen zum Site Recovery an einem Ort zusammengefasst. Im Abschnitt "Replizierte Elemente" sehen Sie die Integrität aller Computer im Tresor, für die die Replikation aktiviert ist. Hierüber erkennen Sie schnell, ob es aktuell Probleme bei der Replikation gibt.

Die Failover-Integrität steht nach der ersten Replikation zunächst auf "Warnung", da bisher kein Failover-Test durchgeführt wurde. Auf diesen Test gehen wir im Laufe des Workshops noch ein. Im Bereich der Konfigurationsprobleme werden Fehler im Bereich der Konfiguration, des Abonnements oder der Ressourcen direkt ausgegeben. Im unteren Bereich sind in der Infrastrukturansicht die an der Replikation beteiligten Infrastrukturkomponenten und die Konnektivität zwischen Servern und Azure-Diensten visuell dargestellt.

Details zu den replizierten Elementen erhalten Sie über den gleichnamigen Menüeintrag auf der rechten Seite oder über den Link "Alle VMs anzeigen". In der Tabellenansicht lassen sich Spalten hinzufügen und entfernen sowie Einträge filtern. Mit dem Klick auf einen Computer erhalten Sie weitere Details zu einem Computer. Hierzu gehören Replikationsinformationen, die RPO (Recovery Point Objective), Wiederherstellungspunkte, die Failoverbereitschaft sowie Fehler und Ereignisse.

Die KPIs "Recovery Time Objective" (RTO) sowie RPO sind wichtige Punkte des Notfallmanagements. Die RPO bezieht sich auf den Zeitraum, für den es zu einem Datenverlust kommt. Die RTO definiert die Zeitspanne, die die Wiederherstellung des normalen Betriebs nach einem Ausfall dauern darf. Hier sind die Zeiten, die in Azure durch die Failovertests ermittelt werden, mit den eigenen Anforderungen in Deckung zu bringen. Mit dem Azure Traffic Manager lassen sich Zeiten weiter reduzieren.

Der Stand einer Replikation lässt sich ebenfalls im Hyper-V-Manager am lokalen Server nachvollziehen. Konfigurationsmöglichkeiten gibt es lokal nicht und auch Aktionen können von hier nicht gesteuert werden. Um im Fehlerfall auch eine Information zu erhalten, lässt sich im Bereich "Sicherheitswarnungen" im Azure-Tresor eine E-Mail-Benachrichtigung aktivieren.

In den Details einer gesicherten Maschine lassen sich verschiedene Aktionen durchführen, darunter "Testfailover", "Testfail-over bereinigen", "Commit ausführen", "Erneut synchronisieren" oder "Wiederherstellungspunkt ändern". Bestimmte Aktionen, wie "Testfailover bereinigen", lassen sich nur bei einem bestimmten Status des replizierten Elements durchführen. Die wichtigsten Aktionen sind die Failover-Szenarien. Zunächst werfen wir einen Blick auf den "Testfailover" und führen diesen in unserer Umgebung aus.

Der Test eines Failovers erstellt eine Kopie der gesicherten VM in Azure, ohne dass sich dies auf laufende Replikationsprozesse oder die Produktionsumgebung auswirkt. Auf diese Maschine kann, wie auf jeden anderen virtuellen Computer in Azure, zugegriffen werden und sie wird auch genauso verwaltet. Bei der Testwiederherstellung ist ein Netzwerk für den Failover auszuwählen. Dieses sollte zwingend separiert sein und keine Verbindung zur Produktion haben, damit das wiederhergestellte System in Ruhe geprüft werden kann. Da es in unserem Test keine Verbindungen zwischen den Netzen gibt, verwenden wir das Standardnetz in Azure und können uns nach der Wiederherstellung mit dem Server per RDP verbinden. Der produktive Server vollzog unterdessen weiterhin seinen Betrieb. Am Abschluss des Tests werden mit der Aktion "Testfailover bereinigen" automatisch alle VMs, die während der Übung in Azure erstellt wurden, entfernt.

Der "geplante Failover" kommt, wie der Name vermuten lässt, für geplante Ausfälle zum Einsatz. Die lokale VM wird dann heruntergefahren, die neusten Daten synchronisiert und die virtuelle Maschine in Azure gestartet. Zu einem Datenverlust kommt es dabei nicht, eine Downtime ist für den Failover aber einzuplanen. Nach dem Initialisieren und Ausführen des Failovers muss zunächst die virtuelle Maschine getestet werden. Ein "Commit" bestätigt dies, wodurch alle Wiederherstellungspunkte in Azure gelöscht werden. Die virtuelle Maschine arbeitet nun komplett in Azure.

Um wieder den Failback in die lokale Umgebung zu erreichen, muss nur erneut ein geplanter Failover in die andere Richtung stattfinden. Dabei wählen wir als Ziel die lokale Umgebung aus. Während das Failover von Azure an den lokalen Standort läuft, fährt Site Recovery die Azure-VM herunter, überträgt die Daten an die lokale VM und startet diese. Nach dem erfolgreichen Failback und der Prüfung der Maschinen ist wieder ein "Commit" für das Failover in Azure nötig, wodurch die Azure-VM gelöscht wird.

Der "Failover" findet in der Regel statt, wenn ein ungeplanter Ausfall auftritt oder der primäre Standort nicht verfügbar ist. Bei der Initialisierung lässt sich dabei festlegen, ob die lokale VM noch heruntergefahren und Daten repliziert werden sollen. Das ist natürlich davon abhängig, ob der Standort und die VM noch erreichbar sind. Sofern die Option zum Herunterfahren der VM nicht aktiviert ist oder Site Recovery die VM nicht herunterfahren kann, kommt der letzte Wiederherstellungspunkt in Azure zur Wiederherstellung zum Einsatz. Der Failover findet in jedem Fall statt, auch wenn sich die VM nicht herunterfahren lässt. Am Ende erfolgt wieder ein Commit und die virtuelle Maschine ist im Anschluss einsatzbereit. Das Vorgehen zum Failback entspricht dem Vorgehen bei einem geplanten Failover.

Neben der Wiederherstellung einzelner Elemente lassen sich mehrere hiervon in Wiederherstellungsplänen zusammenfassen. Ein solcher Plan definiert, wie ein Failover für mehrere Server auf einmal ausgeführt wird. Dabei gibt die Reihenfolge an, wie die Server nach dem Failover starten. Auf diesem Weg lassen sich Anwendungslandschaften darstellen und zum Beispiel ein Datenbankserver vor einem Applikationsserver starten. Die Wiederherstellungspläne können dabei für den Failover und für den Failback genutzt werden. Ein Plan fasst Maschinen in Gruppen zusammen. Server in einer Gruppe starten dabei parallel, während die Gruppen nacheinander starten.

Zwar ist ein Failover lokaler virtueller Server in Richtung Azure einfach möglich. Dies ist allerdings nicht als Migrationsweg zu empfehlen. Anstelle des Azure-Site-Recovery-Dienstes sollten Sie Azure Migrate verwenden, um VMs zu Azure zu migrieren. Ist ASR bereits im Einsatz, kann ein Failover mit der Aktion "Migration abschließen" und nicht mit "Commit" beendet werden. Weitere Informationen zu Azure Migrate finden Sie unter [3].

Eine gesicherte Hyper-V-Instanz schlägt mit 23 Euro im Monat zu Buche. Die Abrechnung erfolgt monatlich und es werden die durchschnittlichen täglich geschützten Instanzen berechnet. Dabei kommen auch Kosten für die Infrastruktur zum Tragen. Dazu gehören die Speichernutzung, die Datenübertragung und eine mögliche VPN-Verbindung. Nach einem Failover kommen noch die Kosten der virtuellen Maschine hinzu. Über den Azure-Preiserechner [4] können Sie alle genutzten Azure-Services angeben, um so zu einer Kostenschätzung zu gelangen.

Desaster Recovery für Hyper-V-Umgebungen erfordert immer eine sorgfältige Planung. Die Einbindung von Azure bietet einen einfachen Weg, lokales Hyper-V resilienter zu machen. Die Einrichtung geht sehr einfach und schnell vonstatten. Vergessen Sie die regelmäßigen Tests nicht, damit Sie im Falle eines Desasters schnell und effizient reagieren können. Daran erinnert aber auch Azure Site Recovery selbst und auch sonst wird die Umgebung stetig überwacht. Azure Site Recovery ersetzt nicht das regelmäßige Backup, es unterstützt Sie aber auf eine einfache Art und Weise dabei, Ihre Umgebung vor Datenverlust zu schützen.