Azure Site Recovery: Virtuelles Netzwerk und Schutzgruppe einrichten, Replica aktivieren

    Azure Site RecoveryMit der Kombi­nation aus Hyper-V Replica und Azure Site Recovery bleiben Firmen im Kata­stro­phen­fall einsatzfähig, indem sie kritische Anwen­dungen aus der Cloud bereit­stellen. Damit VMs nach einem Fail­over erreichbar sind, muss man virtuelle Netze in Azure konfigurieren.

    Mit einem Azure-Konto richtet man, wie im vorangegangen Artikel beschrieben, zuerst einen Tresor (Vault) für die Hybrid Cloud ein. Anschließend muss man den Agent für Microsoft Azure Recovery Services (MARS) und den Provider für Microsoft Azure Site Recovery (MASR) auf die Hyper-V Hosts im eigenen Rechenzentrum verteilen. Bevor nun virtuelle Maschinen für Hyper-V Replica aus dem Azure Portal aktiviert werden können, sind noch weitere Vorarbeiten nötig.

    ASR-Ressourcen vorbereiten: Speicherkonto und virtuelles Netzwerk

    Nachdem die Hyper-V Hosts mit Agenten ausgestattet sind und sie einer Site zugeordnet wurden, können die Ressourcen für ein georedundantes Speicherkonto (Punkt 3 im Wizard), falls noch nicht vorhanden, für die Blob-Container und ein virtuelles Netzwerk konfiguriert werden.

    Durch Georedundanz werden die Daten an einen zweiten Speicherort repliziert, um bei einem Ausfall des primären Azure-Rechenzentrums weiter verfügbar zu bleiben. Im Fall von West Europe wird der sekundäre Standort automatisch North Europe.

    Speicherkonto mit Georedundanz und gleichem Standort wie des Vaults.

    Für die schnelle Einrichtung des virtuellen Netzwerkes vergibt man einen Namen, legt einen vordefinierten IP-Adressraum samt der Anzahl möglicher VMs fest und bestimmt wieder die geographische Lage. Ein DNS-Server lässt sich auch später über Netzwerke => Virtual Networks hinzufügen.

    Bei der benutzerdefinierten Variante fragt der Wizard zusätzliche Parameter ab und auch das nötige Site-to-Site-VPN evtl. inklusive ExpressRoute lässt sich hier definieren. Der Adressraum und Bits für die Netzmaske können später, genau wie der DNS, modifiziert werden.

    Virtuelles Netzwerk für die spätere Erreichbarkeit beim Failover.

    Schutzgruppe und Replikations­einstellungen festlegen

    Anschließend wird unter Punkt 4 eine Schutzgruppe erstellt, welche die später zu schützenden VMs beinhaltet. Hier legt man einen Namen fest, wählt den primären Standort aus und gibt das Speicherkonto an.

    Schutzgruppe definieren

    Schließlich wird die Replikationseinstellung für die ent­sprechende Gruppe angepasst. Von hier aus lässt sich schon die Replikations­häufigkeit der späteren Deltas bestimmen (30 Sekunden, 5 oder 15 Minuten), sie bestimmt den erreichbaren RPO (Recovery Point Objective) für ein Disaster Recovery.

    Hinzu kommen die Aufbewahrungszeit für die Wieder­herstellungs­punkte, das Intervall für die zusätzlichen konsistenten Anwendungs-Snapshots sowie die Startzeit für die initiale Erst­replikation (siehe dazu: Hyper-V Replica: Virtuelle Maschinen an andere Standorte übertragen).

    Replikation nach Azure Site aktivieren

    Unterhalb der Schutzgruppe fügt man nun die virtuellen Maschinen der eingetragenen Hosts hinzu, um die Replikation aus Azure Site zu aktivieren. Beobachtet man jetzt seinen lokalen Host über den Hyper-V Manager, dann erkennt man sofort, dass sich der Status der aktivierten VM ändert in Erste Replikation wird gesendet…. Zuvor wird noch der Checkpoint erstellt, um anschließend die initiale Kopie der VHD(X) via https zu senden.

    Replikation nach Azure Site aktivieren

    Auf beiden Seiten, on-prem und off-prem, lassen sich von nun an die Statusanzeigen verfolgen. Primärer Server ist hier der lokale Hyper-V Host und als Replikat­server dient Microsoft Azure, gut zu erkennen anhand des Replica-Status in der GUI. Nach erfolgreicher Beendigung des Replikations­prozesses lassen sich zuvor festgelegte Konfigurationen überarbeiten, und zwar direkt aus dem Azure Portal, notfalls von jedem Notebook mit Internetzugang.

    Replica wird aus der Cloud heraus aktiviert und der Host sendet die VHDX.

    Wiederherstellungspläne erstellen und Test-Failover

    Wie von Hyper-V Replica zwischen Hosts bereits bekannt, lassen sich Failover-Szenarien wie beispielsweise geplanter Failover oder Test-Failover auch mit Azure Site Recovery durchspielen, um die Gewissheit zu erlangen, dass ein Failover im Disaster-Fall auch funktioniert. Für das Test-Failover kommen einzelne VMs in Frage oder ein Test des Wieder­herstellungs­plans.

    Test für den Ernstfall mit geplantem Failover

    Brisant bei einem Disaster Failover ist immer die Anschalt­reihen­folge im sekundären RZ, soll heißen, oft ist es nötig, die Domänen Controller inkl. DNS zuerst zu booten um anschließend den SQL Server hochzufahren. ASR kommt dieser Anforderung nach und ermöglicht mit Wieder­herstellungs­plänen (Recovery Plans) einen Start in Reihe und kann manuelle Vorgänge automa­tisieren, das mindert zusätzlich die RTO.

    Keine Kommentare