Multi-Region Azure Architektur: Disaster-Recovery-Muster, die tatsaechlich funktionieren

Disaster-Recovery-Praesentationen sehen in Vorstandsvortraegen grossartig aus. Multi-Region-Architekturdiagramme mit Pfeilen zwischen gepaarten Regionen sind beruhigend. Dann faellt tatsaechlich eine Region aus, und Organisationen stellen fest, dass ihr DR-Plan nie getestet wurde, ihr Failover nicht funktioniert und ihr RTO-Ziel von "15 Minuten" tatsaechlich vier Stunden panischer manueller Intervention bedeutet.

Dieser Leitfaden behandelt DR-Muster, die tatsaechlich in der Produktion funktionieren. Wir haben jedes dieser Muster mit Enterprise-Kunden deployt und getestet. Wir werden spezifisch darueber sprechen, was jedes Muster liefert, was es kostet und wo es versagt.

RTO und RPO in der Praxis verstehen

Recovery Time Objective (RTO): Wie lange Ihre Anwendung ausfallen kann. Dies ist keine technische Metrik — es ist eine Geschaeftsentscheidung.

Recovery Point Objective (RPO): Wie viel Datenverlust akzeptabel ist. RPO nahe null bedeutet, dass keine Transaktionen verloren gehen duerfen.

Die unbequeme Wahrheit ueber RTO/RPO

Die meisten Unternehmen setzen RTO/RPO-Ziele, ohne die Kostenimplikationen zu verstehen:

Verhandeln Sie RTO/RPO mit dem Business, bevor Sie die Architektur entwerfen. "Alles muss Active-Active sein" ist eine Budgetentscheidung, keine technische.

Muster 1: Active-Active mit Azure Front Door

Der Goldstandard: Beide Regionen bedienen Produktionstraffic, und Benutzer werden zum naechsten gesunden Endpunkt geroutet. Wenn eine Region ausfaellt, absorbiert die andere allen Traffic mit minimaler Unterbrechung.

Architektur

Bicep-Template: Front Door mit Multi-Region Backends

resource frontDoor 'Microsoft.Cdn/profiles@2023-05-01' = {
  name: 'fd-dr-production'
  location: 'global'
  sku: {
    name: 'Premium_AzureFrontDoor'
  }
}

resource originGroupApp 'Microsoft.Cdn/profiles/originGroups@2023-05-01' = {
  parent: frontDoor
  name: 'app-origins'
  properties: {
    loadBalancingSettings: {
      sampleSize: 4
      successfulSamplesRequired: 3
      additionalLatencyInMilliseconds: 50
    }
    healthProbeSettings: {
      probePath: '/health'
      probeRequestType: 'GET'
      probeProtocol: 'Https'
      probeIntervalInSeconds: 10
    }
    sessionAffinityState: 'Disabled'
  }
}

Datenschicht fuer Active-Active

Der schwierige Teil von Active-Active ist die Datenschicht:

Cosmos DB mit Multi-Region Writes: Der einfachste Weg zu Active-Active-Daten. Cosmos DB unterstuetzt nativ Multi-Region Writes mit konfigurierbaren Consistency-Levels. Session Consistency ist der Sweet Spot fuer die meisten Anwendungen.

resource cosmosAccount 'Microsoft.DocumentDB/databaseAccounts@2023-04-15' = {
  name: 'cosmos-dr-production'
  location: 'westeurope'
  properties: {
    databaseAccountOfferType: 'Standard'
    enableMultipleWriteLocations: true
    consistencyPolicy: {
      defaultConsistencyLevel: 'Session'
    }
    locations: [
      { locationName: 'westeurope', failoverPriority: 0, isZoneRedundant: true }
      { locationName: 'northeurope', failoverPriority: 1, isZoneRedundant: true }
    ]
  }
}

Azure SQL mit Active Geo-Replication: SQL unterstuetzt keine Multi-Region Writes nativ. Die sekundaere Datenbank ist schreibgeschuetzt.

Erreichte RTO/RPO

• RTO: Unter 30 Sekunden (Front Door Health Probe Interval + DNS Propagation)
• RPO: Nahe null fuer Cosmos DB. Bis zu 5 Sekunden fuer SQL Geo-Replication.

Kostenrealitaet

Active-Active verdoppelt Ihre Compute-Kosten und annaehernd Ihre Datenbankkosten. Fuer eine typische Enterprise-Anwendung mit EUR 15.000/Monat in einer einzelnen Region: erwarten Sie EUR 28.000-32.000/Monat.

Muster 2: Active-Passive mit Warm Standby

Die sekundaere Region ist vollstaendig provisioniert, bedient aber keinen Produktionstraffic. Failover ist automatisiert, beinhaltet aber Replikat-Promotion und Traffic-Umschaltung.

Failover-Automatisierung

# Automatisiertes Failover-Runbook
param(
    [string]$ResourceGroupName = "rg-production",
    [string]$SqlServerName = "sql-prod-westeurope",
    [string]$FailoverGroupName = "fog-production"
)

# Schritt 1: SQL Failover
Write-Output "SQL Failover-Group-Umschaltung wird initiiert..."
Switch-AzSqlDatabaseFailoverGroup `
    -ResourceGroupName $ResourceGroupName `
    -ServerName $SqlServerName `
    -FailoverGroupName $FailoverGroupName

# Schritt 2: AKS in sekundaerer Region hochskalieren
Write-Output "AKS in sekundaerer Region wird skaliert..."
az aks nodepool scale --resource-group rg-production-northeurope `
    --cluster-name aks-prod-northeurope `
    --name systempool --node-count 5

Write-Output "Failover abgeschlossen."

Erreichte RTO/RPO

• RTO: 15-30 Minuten (SQL Failover: 5 Min, AKS Scale-up: 5-15 Min, DNS Propagation: 1-5 Min)
• RPO: Unter 5 Minuten (SQL Geo-Replication Lag)

Kostenrealitaet

Die sekundaere Region laeuft auf Minimalskalierung. Erwarten Sie 40-60 % Kostenaufschlag. Fuer das EUR-15.000/Monat-Beispiel: EUR 21.000-24.000/Monat.

Muster 3: Pilot Light

Nur die Datenschicht wird repliziert. Compute-Infrastruktur ist in IaC definiert, aber nicht deployt bis sie benoetigt wird.

Deployment-Pipeline fuer Pilot-Light-Aktivierung

# Azure DevOps Pipeline - DR-Region aktivieren
trigger: none  # Manuell oder Alert-ausgeloest

stages:
  - stage: ActivateDR
    displayName: 'DR-Region aktivieren'
    jobs:
      - job: DeployInfrastructure
        steps:
          - task: AzureCLI@2
            displayName: 'AKS in DR-Region deployen'
            inputs:
              azureSubscription: 'production-subscription'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                az deployment group create \
                  --resource-group rg-production-northeurope \
                  --template-file ./bicep/aks-dr.bicep \
                  --parameters environment=dr nodeCount=5

          - task: AzureCLI@2
            displayName: 'SQL Failover'
            inputs:
              azureSubscription: 'production-subscription'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                az sql failover-group set-primary \
                  --resource-group rg-production \
                  --server sql-prod-westeurope \
                  --name fog-production

Erreichte RTO/RPO

• RTO: 1-4 Stunden (Infrastruktur-Deployment: 30-90 Min, Anwendungs-Deployment: 15-30 Min, Validierung: 15-30 Min)
• RPO: Unter 5 Minuten (SQL Geo-Replication laeuft immer)

Kostenrealitaet

Nur Datenreplikationskosten im Normalbetrieb. 10-20 % Aufschlag. Fuer das EUR-15.000/Monat-Beispiel: EUR 16.500-18.000/Monat.

Dienstspezifische DR-Muster

AKS Multi-Cluster

resource aksWestEurope 'Microsoft.ContainerService/managedClusters@2024-01-01' = {
  name: 'aks-prod-westeurope'
  location: 'westeurope'
  properties: {
    kubernetesVersion: '1.29'
    agentPoolProfiles: [
      {
        name: 'systempool'
        count: 3
        vmSize: 'Standard_D4s_v5'
        availabilityZones: ['1', '2', '3']
        mode: 'System'
      }
    ]
  }
}

resource aksNorthEurope 'Microsoft.ContainerService/managedClusters@2024-01-01' = {
  name: 'aks-prod-northeurope'
  location: 'northeurope'
  properties: {
    kubernetesVersion: '1.29'
    agentPoolProfiles: [
      {
        name: 'systempool'
        count: 2  // Warm Standby
        vmSize: 'Standard_D4s_v5'
        availabilityZones: ['1', '2', '3']
        mode: 'System'
      }
    ]
  }
}

Azure SQL Geo-Replication mit Failover Groups

resource failoverGroup 'Microsoft.Sql/servers/failoverGroups@2023-05-01-preview' = {
  parent: sqlServerPrimary
  name: 'fog-production'
  properties: {
    readWriteEndpoint: {
      failoverPolicy: 'Automatic'
      failoverWithDataLossGracePeriodMinutes: 5
    }
    readOnlyEndpoint: {
      failoverPolicy: 'Enabled'
    }
    partnerServers: [
      { id: sqlServerSecondary.id }
    ]
    databases: [sqlDatabase.id]
  }
}

Azure Site Recovery fuer VMs

Fuer Legacy-Workloads auf VMs, die nicht containerisiert werden koennen, bietet Azure Site Recovery (ASR) kontinuierliche Replikation mit 15-Minuten-RPO und ca. 2-Stunden-RTO.

DR-Muster-Auswahl Entscheidungsfluss

Ihren DR-Plan testen

Ein DR-Plan, der nicht getestet wird, ist kein Plan — er ist eine Hoffnung.

Monatlich: Automatisierte Gesundheitschecks

#!/bin/bash
echo "=== DR-Bereitschaftsbericht ==="

# SQL-Replikations-Lag pruefen
az sql failover-group show \
  --resource-group rg-production \
  --server sql-prod-westeurope \
  --name fog-production \
  --query "replicationState"

# Bicep-Templates ueberpruefen
az bicep build --file ./bicep/dr-region.bicep

Vierteljaehrlich: Simuliertes Failover

Fuehren Sie ein vollstaendiges Failover in die sekundaere Region waehrend eines Wartungsfensters durch. Messen Sie die tatsaechliche RTO gegen die Ziele.

Jaehrlich: Vollstaendige Chaos-Uebung

Simulieren Sie einen kompletten Ausfall der primaeren Region, ohne das Operations-Team vorher zu warnen (Management informieren). Messen Sie Erkennungszeit, Eskalationszeit, Failover-Zeit und Datenintegritaet.

Haeufige Fehler

Fehler 1: Failover testen, aber nie Failback. Failover ist die halbe Herausforderung. Failback zur primaeren Region ist oft schwieriger und weniger getestet.

Fehler 2: Stateful-Komponenten vergessen. DNS-Eintraege, SSL-Zertifikate, Konfiguration in App Configuration oder Key Vault — alles muss in beiden Regionen verfuegbar sein.

Fehler 3: Kapazitaet nicht beruecksichtigen. Ihre DR-Region braucht genuegend Kapazitaet fuer Produktions-Workloads.

Fehler 4: Cross-Region-Latenz ignorieren. Wenn Ihre Anwendung synchrone Aufrufe zwischen Diensten hat und einige Dienste failovert werden, waehrend andere es nicht werden, kann Cross-Region-Latenz Timeout-Annahmen verletzen.

Das richtige Muster waehlen

Das richtige Muster haengt von den Ausfallkosten ab, nicht von den Infrastrukturkosten. Wenn eine Stunde Ausfall EUR 500.000 kostet, ist Active-Active mit EUR 15.000/Monat Aufschlag trivial gerechtfertigt.

Naechste Schritte

Disaster-Recovery-Architektur ist einer der Bereiche, in denen die Luecke zwischen "was wir geplant haben" und "was tatsaechlich funktioniert" am groessten ist. Die obigen Muster sind erprobt, muessen aber an Ihre spezifische Anwendungsarchitektur, Compliance-Anforderungen und Budgetbeschraenkungen angepasst werden.

Wenn Sie Hilfe beim Design oder Testen einer Multi-Region DR-Architektur auf Azure benoetigen, kontaktieren Sie uns unter mbrahim@conceptualise.de. Wir sind auf Architekturen spezialisiert, die unter Druck funktionieren, nicht nur in Praesentationen.