Failover und Failback
Azure Site Recovery bietet Ihnen die Flexibilität, bei Auftreten eines Notfalls ein Failover zu Azure durchzuführen und nach Ende des Ereignisses ein Failback auf lokale Computer vorzunehmen.
Sie möchten nun ein vollständiges Failover für den Rest der geschützten Umgebung auf Azure durchführen. Sie führen ein vollständiges Failover aus, nachdem Sie erfolgreich ein Failoververfahren auf einem einzelnen virtuellen Testcomputer ausgeführt haben. Nachdem das Failover erfolgreich abgeschlossen wurde, führen Sie ein Failback durch.
In dieser Lerneinheit lernen Sie die Unterschiede zwischen Failover und Failback kennen. Außerdem erfahren Sie, wie eine Failbackrichtlinie automatisch erstellt wird, nachdem Sie eine Replikationsrichtlinie für Azure eingerichtet haben.
Failover und Failback
Ein Failover ist der Prozess, der stattfindet, wenn die Entscheidung getroffen wird, den BCDR-Plan für das Unternehmen aufzurufen. Ein Failover erfolgt, wenn die aktuelle Liveumgebung, die mithilfe von Site Recovery geschützt ist, in die Replikatumgebung verschoben wird. Diese Zielreplikatumgebung übernimmt die Rolle der Liveumgebung und wird zur primären Infrastruktur.
Ein Failback ist das Gegenteil eines Failovers. Die vorherige Liveumgebung (durch Auftreten eines Failovers jetzt die Replikatumgebung) übernimmt wieder ihre ursprüngliche Rolle und wird zur Liveumgebung. Nachdem das Failover zunächst einmal stattgefunden hat, muss eine Phase zum erneuten Schützen erfolgen. In dieser Phase wird die ursprüngliche Umgebung wieder mit der neuen Liveumgebung synchronisiert. Dieser Prozess ermöglicht das Failover und Failback ohne Datenverlust. Die Phase zum erneuten Schützen ist wahrscheinlich ein langwieriger Prozess, da sichergestellt werden muss, dass die alte Liveumgebung nach dem Notfall ordnungsgemäß funktioniert.
Nachfolgend sind die vier Phasen der Failover- und Failbackaktionen aufgelistet:
- Failover zu Azure: Wenn der lokale primäre Standort ausfällt, wird die Entscheidung für ein Failover zu Azure (oder zu Ihrem sekundären Standort) getroffen, wodurch virtuelle Computer aus den primären replizierten Daten erstellt werden.
- Erneutes Schützen virtueller Azure-Computer: Nach dem Failover müssen die virtuellen Azure-Computer erneut geschützt werden, damit sie Änderungen zurück an die lokale Umgebung replizieren können, sobald der Notfall behoben ist. Virtuelle Computer werden ausgeschaltet, um Datenkonsistenz zu gewährleisten.
- Failback zum lokalen Standort: Wenn der lokale Standort wieder einsatzbereit ist, kann ein Failover zurück zu dieser Umgebung erfolgen. Diese ist dann wieder die Liveumgebung. Ein Failback zu physischen Servern ist nicht möglich. Alle Systeme müssen ein Failback zu virtuellen Computern durchführen.
- Erneutes Schützen lokaler virtueller Computer: Das erneute Schützen der lokalen virtuellen Computer erfolgt, damit sie nach dem erfolgreichen Failback nach Azure repliziert werden können.
Failbackrichtlinien
Wenn Sie eine lokale Replikationsrichtlinie erstellen, um Ihre lokalen Computer nach Azure zu kopieren, wird automatisch eine zugehörige Failbackrichtlinie erstellt. Die Richtlinie verfügt über einige festgelegte Attribute, die nicht geändert werden können. Dies sind folgende Attribute:
- Die Replikation kann nur zurück auf den lokalen Konfigurationsserver erfolgen.
- RPO (Recovery Point Objective) ist auf 15 Minuten festgelegt.
- Der Aufbewahrungszeitraum des Wiederherstellungspunkts ist auf 24 Stunden festgelegt.
- Anwendungskonsistente Momentaufnahmen sind auf stündlich festgelegt.
Durch Ausführen des Failbacks werden die virtuellen Azure-Computer gestoppt. Sobald die Replikation abgeschlossen ist, starten Sie den lokalen virtuellen Computer, um die Workloads zu übernehmen. Da der Dienst unterbrochen wird, sollten Sie das Failback für einen Zeitpunkt planen, der sich nicht auf Ihr Unternehmen auswirkt.
Business Continuity & Disaster Recovery
BCDR-Pläne in Site Recovery ermöglichen die Anpassung und Sequenzierung des Failovers und Failbacks von virtuellen Computern und den darauf ausgeführten Anwendungen. Computer werden gruppiert, und Wiederherstellungsaktionen können mithilfe von Skripts während des Failovers oder Failbacks automatisiert werden. Sie können bei Bedarf auch zusätzliche manuelle Schritte für Aktionen hinzufügen. Wenn Sie den BCDR-Plan vor Eintreten eines Notfalls testen, können Sie eher darauf vertrauen, dass Sie ein positives Ergebnis erzielen. Sie müssen Ihre Infrastruktur am sekundären Standort schnell wieder einsatzbereit machen, um die RTO (Recovery Time Objective) des Unternehmens zu erfüllen.
Flexible Failover
Aufgrund der flexiblen Handhabung von Failovern kann Site Recovery bei Bedarf Failover zu Testzwecken durchführen. Durch Isolieren dieser Tests werden keine Livedienste unterbrochen. Diese Flexibilität ermöglicht auch das Ausführen eines Failovers während eines geplanten Ausfalls des Live-Diensts. Benutzer*innen des Systems bemerken keinerlei Unterbrechungen aufgrund des Ausfalls, da sie automatisch zur replizierten Umgebung umgeschaltet werden. Diese Flexibilität ist auch im umgekehrten Fall gegeben. Ein bedarfsgesteuertes Failback kann entweder im Rahmen eines geplanten Tests oder als Teil eines vollständig aufgerufenen Notfallwiederherstellungsszenarios erfolgen.