Wie wird eine Disaster-Recovery-Strategie für globale Azure-Regionen unter Verwendung von Traffic Manager und Azure Site Recovery technisch orchestriert?

Die technische Orchestrierung ist im Grunde ein Zusammenspiel aus Daten-Synchronisation und DNS-Steuerung. Azure Site Recovery (ASR) übernimmt die schwere Arbeit im Backend, während der Traffic Manager (TM) an der Front entscheidet, wohin die Pakete fliegen.

Der Workflow ist simpel: ASR repliziert die VMs kontinuierlich von der Primary- in die Secondary-Region. Wenn die Primary-Region abraucht, triggert ihr den Failover. ASR startet die VMs in der Zielregion in einer definierten Reihenfolge (Recovery Plans), damit die Datenbank vor dem App-Server online ist. Parallel dazu merkt der Traffic Manager über Health Probes, dass der Primary-Endpunkt nicht mehr antwortet.

Hier ist die technische Aufteilung:

Damit das Ganze nicht nur in der Theorie funktioniert, muss das Routing auf "Priority" stehen. Die Primary-Region hat Priorität 1, die Secondary Priorität 2. Solange Primary lebt, geht alles dorthin. Erst bei einem Ausfall schwenkt der DNS-Eintrag um. Wer das Ganze nicht nur als Tool-Installation, sondern als Teil seiner IT-Consulting & Digitale Strategie sieht, vermeidet die typischen Architektur-Fehler.

Wichtig ist: ASR kümmert sich nur um die VMs. Eure Daten in SQL-Datenbanken oder Storage-Accounts müssen separat über Geo-Replikation oder Failover Groups gelöst werden. ASR allein rettet euch nicht die Datenkonsistenz in PaaS-Diensten.

Der teuerste Fehler ist ein zu hoher DNS-TTL-Wert (Time To Live). Wenn der TTL auf 3600 Sekunden steht, warten eure Kunden eine Stunde auf den Failover, obwohl die Server in der Secondary-Region längst laufen. Das ist ein technisches Versagen.

Wir empfehlen: Setzt den TTL auf 60 Sekunden oder weniger. Testet den Failover vierteljährlich unter realen Bedingungen. Wer nur hofft, dass es klappt, hat keine Strategie.