Wiederherstellungspläne und automatisches Failover
Erstellen Sie einen ASR-Wiederherstellungsplan, der das VM-Failover über Anwendungsebenen hinweg sequenziert, fügen Sie manuelle Genehmigungsschritte hinzu und integrieren Sie Skripts vor und nach dem Failover.
Wiederherstellungspläne und automatisches Failover ist eine kostenlose Cloud & IT Cert Prep-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Cloud & IT Cert Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.
Was ist ein ASR-Wiederherstellungsplan?
Ein Recovery Plan in Azure Site Recovery ist eine strukturierte, geordnete Abfolge von Schritten, die das Failover mehrerer VMs gemeinsam orchestriert. Anstatt jede VM einzeln einem Failover zu unterziehen, gruppiert ein Wiederherstellungsplan sie in Gruppen, die nacheinander einem Failover unterzogen werden. So wird sichergestellt, dass die Infrastruktur (Datenbank, Middleware, Web) in der richtigen Reihenfolge gestartet wird – genau wie bei der ursprünglichen Bereitstellung.
Erstellen eines Wiederherstellungsplans
Zum Erstellen eines Wiederherstellungsplans wählen Sie den Quellstandort (primäre Region) und den Zielstandort (sekundäre Region) aus und fügen anschließend die gewünschten VMs hinzu. Der Assistent zum Erstellen des Plans legt automatisch eine Standardgruppe an. Sie können jedoch weitere Gruppen hinzufügen, um die Failover-Reihenfolge zu steuern. VMs in derselben Gruppe werden gleichzeitig einem Failover unterzogen; die Gruppen werden in nummerierter Reihenfolge ausgeführt.
# Create an ASR Recovery Plan via CLI:
az site-recovery recovery-plan create \
--resource-group myRG \
--vault-name myRecoveryVault \
--name myRecoveryPlan \
--primary-fabric-id '/subscriptions/.../replicationFabrics/eastus' \
--recovery-fabric-id '/subscriptions/.../replicationFabrics/westus' \
--groups '[{"groupType":"Boot","replicationProtectedItems":[...]}]'Sequenzierung von Gruppen für mehrschichtige Anwendungen
Für eine typische dreischichtige Anwendung sollte der Wiederherstellungsplan drei Gruppen enthalten:
- Gruppe 1 – VMs der Datenbankschicht (müssen zuerst gestartet werden)
- Gruppe 2 – VMs der Anwendungs- bzw. Middleware-Schicht
- Gruppe 3 – VMs des Web-Frontends (werden zuletzt gestartet)
Jede Gruppe wartet, bis das Failover der vorherigen Gruppe erfolgreich abgeschlossen ist, bevor sie gestartet wird. Dadurch wird die korrekte Startreihenfolge eingehalten und verhindert, dass VMs der Webschicht gestartet werden, bevor die Datenbank Verbindungen annehmen kann.
Hinzufügen manueller Aktionen und Skripts
Wiederherstellungspläne unterstützen an den Grenzen zwischen den einzelnen Gruppen Voraktionen und Nachaktionen. Dabei kann es sich um Folgendes handeln:
- Manuelle Aktionen – das Failover wird angehalten, bis eine Person es bestätigt (z. B. „Überprüfen, ob die Datenbank bereit ist“)
- Azure Automation-Runbooks – ein Skript wird automatisch ausgeführt (z. B. zum Aktualisieren von DNS-Einträgen oder Deaktivieren des Wartungsmodus)
Durch die Verwendung von Automation-Runbooks lässt sich das Failover für Arbeitslasten der Stufe 1 vollständig ohne menschliches Eingreifen automatisieren.
# Example Automation runbook action in a recovery plan:
# Pre-group-2 action: Run runbook 'UpdateConnectionStrings'
# This runbook updates app config to point to secondary DB endpoint
# before the application tier VMs startGeplantes und ungeplantes Failover
Azure Site Recovery unterstützt zwei Arten von Failover:
- Geplantes Failover – wird vor einem bekannten Ereignis eingeleitet (z. B. einer Wartung des Rechenzentrums). Die primäre VM wird ordnungsgemäß heruntergefahren, die Daten werden synchronisiert und anschließend wird die sekundäre VM gestartet. Es entsteht kein Datenverlust.
- Ungeplantes Failover – wird während eines tatsächlichen Notfalls ausgelöst. Die primäre VM ist möglicherweise nicht verfügbar, daher verwendet ASR den letzten Replikationsprüfpunkt. Abhängig vom RPO ist ein gewisser Datenverlust möglich.
# Trigger an unplanned failover via CLI:
az site-recovery recovery-plan failover-unplanned \
--resource-group myRG \
--vault-name myRecoveryVault \
--name myRecoveryPlan \
--failover-direction PrimaryToRecoveryCommit und Failback
Nach einem Failover befinden sich die wiederhergestellten VMs in der sekundären Region im Zustand Commit ausstehend. Sie müssen das Failover bestätigen, um zu bestätigen, dass der sekundäre Standort nun der aktive Standort ist und kein Rollback durchgeführt werden soll. Nach der Bestätigung können Sie eine umgekehrte Replikation einrichten, um den sekundären Standort zu schützen, und später ein Failback in die primäre Region durchführen, sobald diese wiederhergestellt ist.
# Commit the failover:
az site-recovery recovery-plan commit \
--resource-group myRG \
--vault-name myRecoveryVault \
--name myRecoveryPlan
# Then configure reverse replication to enable failback laterErneutes Schützen nach einem Failover
Nach der Bestätigung eines Failovers werden die replizierten Elemente in der ursprünglichen primären Region nicht mehr aktiv repliziert. Um den Schutz wiederherzustellen, müssen Sie die Elemente erneut schützen. Dadurch wird die Replikationsrichtung umgekehrt, sodass die neue primäre Region (zuvor die sekundäre Region) in die ursprüngliche primäre Region repliziert. Das erneute Schützen nimmt Zeit in Anspruch und sollte eingeleitet werden, sobald die ursprüngliche primäre Region wieder verfügbar ist.
RTO-Messung in Wiederherstellungsplänen
Jeder Schritt in einem Wiederherstellungsplan trägt zum gesamten RTO bei. Häufige Zeitaufwände sind:
- Startzeit der VMs (2–5 Minuten pro VM)
- Aufwärmzeit der Anwendung (Initialisierung des Datenbankverbindungspools, Aufwärmen des Caches)
- DNS-Propagation nach IP-Änderungen
- Wartezeiten auf manuelle Genehmigungen
Messen Sie jeden Schritt während Test-Failovers und addieren Sie die Zeiten, um Ihr tatsächliches RTO im Vergleich zu Ihrem Ziel zu berechnen.
DNS-Updates automatisieren
Nach einem Failover haben VMs in der sekundären Region andere IP-Adressen. Bei Anwendungen, die einen öffentlichen DNS-Namen bereitstellen, müssen Sie DNS aktualisieren, damit auf die neuen IPs verwiesen wird. Verwenden Sie ein Azure Automation runbook als Aktion nach dem Failover, um Azure DNS oder die Endpunktintegrität von Traffic Manager zu aktualisieren und den Datenverkehr automatisch umzuleiten – so vermeiden Sie einen manuellen Schritt, der Ihr RTO verlängern könnte.
# Example: Update Azure DNS record in a runbook after failover:
# az network dns record-set a update \
# --resource-group dnsRG \
# --zone-name myapp.com \
# --record-set-name '@' \
# --set 'ARecords[0].ipv4Address=<new-secondary-ip>'Ausführung des Wiederherstellungsplans überwachen
Während eines Failovers zeigt die Ansicht Azure portal Jobs im Recovery Services-Tresor den Fortschritt jedes Schritts im Wiederherstellungsplan in Echtzeit an. Sie sehen, welche Gruppe gerade ausgeführt wird, welche VMs erfolgreich gestartet wurden und ob Skripts oder manuelle Aktionen noch ausstehen. Durch die Überwachung dieser Ansicht kann das Wiederherstellungsteam schnell eingreifen, wenn ein Schritt fehlschlägt.
Bewährte Methoden für Wiederherstellungspläne
Wichtige bewährte Methoden für Wiederherstellungspläne:
- Halten Sie Gruppen klein (5–10 VMs), um den Auswirkungsbereich bei einem Gruppenfehler zu begrenzen
- Verwenden Sie nach Möglichkeit Automation runbooks anstelle manueller Aktionen, um das RTO zu reduzieren
- Dokumentieren Sie die erwartete Startzeit für jede Gruppe, damit das RTO berechnet werden kann
- Führen Sie mindestens vierteljährlich einen test failover durch, um den Plan zu überprüfen
- Überprüfen und aktualisieren Sie den Plan, sobald neue VMs hinzugefügt werden oder sich die Anwendungsarchitektur ändert
Schnelltest
Testen Sie Ihr Verständnis der Konzepte von Microsoft Azure Fundamentals (AZ-900) aus dieser Lektion.
Zusammenfassung der Lektion
In dieser Lektion haben Sie gelernt: Ein recovery plan orchestriert das geordnete Failover mehrerer VMs mit Vor- und Nachaktionen für jede Gruppe; ein unplanned failover verwendet den letzten Replikationsprüfpunkt, während ein geplantes Failover keinen Datenverlust verursacht; und nach einem Failover müssen Sie commit and reprotect ausführen, um den DR-Schutz wiederherzustellen. Als Nächstes sehen wir uns an, wie Sie DR-Pläne testen können, ohne die Produktion zu beeinträchtigen.
Häufig gestellte Fragen
Ist die Lektion „Wiederherstellungspläne und automatisches Failover“ kostenlos?
Ja — der vollständige Text von „Wiederherstellungspläne und automatisches Failover“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Cloud & IT Cert Prep-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Wiederherstellungspläne und automatisches Failover“?
Erstellen Sie einen ASR-Wiederherstellungsplan, der das VM-Failover über Anwendungsebenen hinweg sequenziert, fügen Sie manuelle Genehmigungsschritte hinzu und integrieren Sie Skripts vor und nach de… Du übst Cloud & IT Cert Prep mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Cloud & IT Cert Prep zu starten?
Keine Vorkenntnisse erforderlich. Cloud & IT Cert Prep auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.
Wie lange dauert die Lektion „Wiederherstellungspläne und automatisches Failover“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Cloud & IT Cert Prep-Lektion Code schreiben und ausführen?
Ja. Jede Cloud & IT Cert Prep-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- RTO, RPO und Wiederherstellungsebenen definieren
- Wiederherstellungspläne und automatisches Failover
- DR-Tests ohne Auswirkungen
- DR für PaaS-Dienste