Azure-Architekturen optimieren: Zonenredundanz gezielt auf Komponentenebene festlegen

Die pauschale Annahme, dass ein Produktions-Workload auf Microsoft Azure standardmäßig über drei Verfügbarkeitszonen verteilt werden muss, führt häufig zu unnötiger operationaler Komplexität, gebundenen Kapazitäten und vermeidbaren Kosten. Ein neues Design-Framework zeigt auf, dass Zonentoleranz keine globale Eigenschaft eines gesamten Workloads ist, sondern durch gezielte Einzelentscheidungen für jede einzelne Komponente definiert werden sollte.

Ausfallbereiche und Ressourcen-Typen

Eine Azure-Verfügbarkeitszone schützt vor dem Ausfall einzelner Rechenzentren innerhalb einer Region, bietet jedoch keinen Schutz bei einem vollständigen Regionsausfall. Microsoft unterscheidet bei der Implementierung grundsätzlich zwei Ansätze:

• Zonenredundante Ressourcen: Die Verteilung, Replikation und das Failover werden automatisch von Azure verwaltet.
• Zonale Ressourcen: Diese sind fest an eine spezifische Zone gebunden. Architekten müssen Routing, Replikation sowie die Wiederherstellung bei der manuellen Bereitstellung über mehrere Zonen hinweg eigenständig konfigurieren.

Analyseschritte auf Komponentenebene

Um die passende Zonenarchitektur zu bestimmen, wird der Workload nach kritischen Abläufen und Komponenten zerlegt. Jedes Element wird anhand von drei Kriterien bewertet:

• Ressourcenverfügbarkeit: Prüfung, ob die verbleibenden Zonen bei Ausfall einer einzelnen Zone den notwendigen Betriebszustand aufrechterhalten können. Sowohl Zwei- als auch Drei-Zonen-Muster können dieses Ziel für den Einzelzonenausfall erfüllen.
• Datenkonsistenz und Datenbeständigkeit: Klärung, ob ein System auf Quorum, Konsens, Leader-Election oder erweiterte Durability-Vorgaben angewiesen ist.
• Kosten und Kapazität: Die Wiederherstellungskapazität verteilt sich bei Zwei-Zonen-Designs anders als bei Drei-Zonen-Designs. Höhere Zonenanzahlen können unter Umständen den Gesamtkapazitätsbedarf für Reserven reduzieren.

Einsatzbereiche von Zwei- und Drei-Zonen-Mustern

Ein Zwei-Zonen-Design reicht für zustandslose Komponenten, einfache Active-Active- oder Active-Passive-Paare sowie für Systeme aus, deren Performance- und Latenzanforderungen auf einem getesteten Zonenpaar erfüllt werden.

Drei-Zonen-Muster sind hingegen für Komponenten erforderlich, die eine dritte Ausfalldomäne benötigen. Dazu zählen zustandsbehfatete Systeme mit Quorum- oder Konsensmechanismen zur Vermeidung von Split-Brain-Zuständen sowie Daten-Stores mit höchsten Anforderungen an die Replikations-Durability. Sofern von Azure unterstützt, wird der Einsatz service-verwalteter zonenredundanter Ressourcen als primäre Option empfohlen.

Architekturentscheidungen fundiert begründen

Anstatt eine feste Zonenanzahl für gesamte Architekturen vorzugeben, ermöglicht das Framework eine gezielte Zuordnung nach spezifischen Systemanforderungen. Dies verhindert Überprovisionierung und stellt sicher, dass verbleibende Kapazitäten, Datenkonsistenz und Failover-Prozesse für jede Komponente explizit definiert und validiert sind.