Microsoft AZ-305: Hochverfügbarkeit, Notfallwiederherstellung und Geschäftskontinuität — Lernleitfaden

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Teil des Microsoft Azure Solutions Architect Expert AZ-305 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Hochverfügbarkeit (HA), Notfallwiederherstellung (DR) und Geschäftskontinuität (BC) in Azure erfordern ein gezieltes Design über die Compute-, Daten- und Netzwerkebenen hinweg. Resilienz beginnt mit klaren Zielen für die Wiederherstellungszeit (RTO) und den Wiederherstellungspunkt (RPO) und setzt dann Plattformfähigkeiten – Availability Zones, globales Routing, Datenreplikation, Backup und Failover-Orchestrierung – zu einer getesteten, automatisierten Strategie zusammen. Azure bietet Fehlerisolierung auf Zonen- und Regionsebene, DNS- und Anycast-basierte globale Verteilung, regionenübergreifende Datendauerhaftigkeit und richtliniengesteuerte Sicherung/Wiederherstellung, um strenge Ziele zu erreichen und gleichzeitig Kosten und betriebliche Komplexität zu kontrollieren.

RTO/RPO-gesteuerte Architektur und zonale/globale Resilienz

Das Design beginnt mit RTO und RPO. RTO gibt vor, wie schnell ein Dienst nach einem Ausfall wiederhergestellt sein muss; RPO gibt den maximal zulässigen Datenverlust vor. Die Einhaltung eines niedrigen RTO erfordert automatisiertes Failover und vorab bereitgestellte Kapazität; die Einhaltung eines niedrigen RPO erfordert synchrone oder quasi-synchrone Replikation und häufige, konsistente Wiederherstellungspunkte.

Availability Zones sind unabhängige Rechenzentrums-Fehlerdomänen innerhalb einer Region. Zonale Dienste (z. B. Virtual Machines, Managed Disks, öffentliche Standard-IPs) sind an eine einzelne Zone gebunden. Zonenredundante Dienste (z. B. zonenredundante Frontends von Azure Load Balancer Standard, zonenredundante Speicherangebote und zonenredundante Azure SQL-Tiers) erstrecken sich automatisch über Zonen. Ein typisches resilientes Muster stellt zonale VMs in mindestens zwei Zonen bereit, platziert sie in einem einzigen virtuellen Netzwerk und stellt ein zonenredundantes Load-Balancing-Frontend bereit. Dies eliminiert den Ausfall einer einzelnen Zone als Ursache für Ausfallzeiten.

Am globalen Edge wählen Sie zwischen DNS-basierter und Anycast-Proxy-Lastverteilung:

Azure Traffic Manager ist DNS-basiert. Er leitet Clients mithilfe von Routingmethoden an Endpunkte weiter: Leistung (niedrigste Latenz), Gewichtet (A/B-Tests und schrittweise Verkehrsverlagerungen), Priorität (Aktiv/Passiv-Failover), Geografisch (Bedienung von Benutzern von regional konformen Endpunkten), Mehrwertig (gibt mehrere fehlerfreie IPv4/IPv6-Einträge für einfache Clients zurück) und Subnetz (ordnet Client-IP-Bereiche bestimmten Endpunkten zu). Da er DNS-basiert ist, beschleunigt Traffic Manager weder Inhalte noch fungiert er als Proxy für den Datenverkehr; Clients verbinden sich direkt mit dem gewählten Endpunkt und unterliegen dem lokalen DNS-Caching-Verhalten.
Azure Front Door (Standard/Premium) ist ein globaler Anycast-HTTP/HTTPS-Reverse-Proxy mit intelligentem Routing, TLS-Offload und integrierter Web Application Firewall (WAF). Routingregeln gleichen Domäne, Pfad, Methode und Header ab und leiten dann an Ursprungsgruppen weiter; Aktionen der Regel-Engine können URLs/Header umschreiben und Weiterleitungen erzwingen. Integritätstests (Health Probes) bewerten kontinuierlich die Integrität des Ursprungs auf einem konfigurierbaren Pfad und Protokoll; fehlerhafte Ursprünge werden aus der Rotation entfernt. Ursprungsgruppen unterstützen Prioritäts- (Aktiv/Passiv) und gewichtete Verteilung über Regionen hinweg. WAF-Richtlinien werden am Endpunkt oder an der Route angehängt, mit verwalteten Regelsätzen, benutzerdefinierten Regeln und Ratenbegrenzung zur Abwehr von OWASP-Bedrohungen und missbräuchlichen Clients. Verwenden Sie Front Door, wenn Sie globales Load Balancing mit Beschleunigung, Edge-Sicherheit und anwendungsbezogenem Failover benötigen; kombinieren Sie es nur dann mit Traffic Manager, wenn Sie Nicht-HTTP-Endpunkte oder Kontrolle auf DNS-Ebene benötigen.

Auf Layer 4 bietet Azure Load Balancer eine Lastverteilung mit extrem niedriger Latenz für TCP/UDP. Standard Load Balancer unterstützt zonale und zonenredundante Frontends, HA-Ports, Ausgangsregeln und ein standardmäßig sicheres Verhalten (explizite Konfiguration von NSG und Backend-Pool). Integritätstests (Health Probes) (TCP/HTTP) ermitteln die Integrität des Backends; bei einem Ausfall werden Instanzen aus der Rotation entfernt. Dem Basic Load Balancer fehlen Zonenbewusstsein, erweiterte Funktionen und ein SLA – vermeiden Sie ihn für Produktionsumgebungen. Cross-region Load Balancer fügt ein globales Anycast-Frontend hinzu, das den Lastausgleich über regionale Standard Load Balancer durchführt, was Aktiv/Aktiv-Designs über mehrere Regionen für Nicht-HTTP-Workloads ermöglicht und ein schnelles regionales Failover basierend auf der Integrität bereitstellt.

Datenschutz und Notfallwiederherstellung: Azure Backup und Site Recovery

Azure Backup bietet Point-in-Time-Wiederherstellung; Azure Site Recovery (ASR) ermöglicht die Replikation von Workloads und ein orchestriertes Failover. Sie decken komplementäre Anforderungen ab und werden oft kombiniert.

Azure Backup-Tresoroptionen:

Der Recovery Services-Tresor schützt Azure VMs, SQL Server in Azure VMs, SAP HANA in Azure VMs, Azure Files und MARS/MABS-Agenten. Er lässt sich in Sicherungsrichtlinien integrieren, die Zeitpläne, Aufbewahrungsfristen und anwendungskonsistente Sicherungen definieren, sofern unterstützt.
Der Backup-Tresor ist der modernisierte Tresor für neuere Workloads wie die Sicherung von Azure Disks und Azure Blobs. Er bietet granulare RBAC und zonenredundanten Tresorspeicher in unterstützten Regionen. Wählen Sie den Tresortyp, der auf den Workload und das Governance-Modell abgestimmt ist.

Sicherungsrichtlinien steuern, wann Sicherungen ausgeführt werden, ihre Aufbewahrungsstufen (täglich/wöchentlich/monatlich/jährlich) und Konsistenzeinstellungen. Vorläufiges Löschen (Soft Delete) fügt ein Sicherheitsfenster hinzu, in dem gelöschte Sicherungselemente wiederhergestellt werden können, was vor versehentlichem oder böswilligem Löschen schützt. Die regionsübergreifende Wiederherstellung ermöglicht Wiederherstellungen aus der sekundären Region, wenn der Tresorspeicher georedundante Optionen verwendet; sie muss aktiviert werden und unterliegt der regionalen Feature-Unterstützung und der Bereitschaft der Datenebene.

Azure Site Recovery repliziert Workloads über Zonen oder Regionen hinweg und orchestriert eine End-to-End-Notfallwiederherstellung (DR):

Replikationsrichtlinien definieren die Häufigkeit von Snapshots, die Aufbewahrung von Wiederherstellungspunkten, die Frequenz anwendungskonsistenter Snapshots und RPO-Warnschwellenwerte. Die Richtlinien gleichen Replikationsbandbreite, Speicherkosten und Wiederherstellungspräzision aus.
Wiederherstellungspläne ermöglichen ein geordnetes Failover von mehrschichtigen Anwendungen mit Gruppen (z. B. Datenbank, API, Web), Pre-/Post-Schritten und Automatisierung über Azure Automation-Runbooks, Skripte oder manuelle Aktionen. Integrieren Sie DNS-Änderungen, Aktualisierungen von Traffic Manager/Front Door-Endpunkten und die Anwendungskonfiguration in den Plan.
Ein Testfailover führt eine isolierte Wiederherstellung unter Verwendung eines nicht-produktiven VNets oder eines Testnetzwerks durch, um Runbooks, die Startreihenfolge und den Zustand der Anwendung zu validieren, ohne die Produktion oder Replikation zu beeinträchtigen. Regelmäßige Tests sind unerlässlich, um das RTO zu validieren.
Failback bringt Workloads zum ursprünglichen Standort oder zur ursprünglichen Region zurück, wenn diese wieder fehlerfrei ist. Schützen Sie nach dem Failover den Workload in der neuen primären Richtung erneut, synchronisieren Sie Änderungen, planen Sie ein Failback-Fenster und überprüfen Sie die Replikation nach dem Failback. In Azure-zu-Azure-Szenarien führen Sie typischerweise ein Failover zwischen gekoppelten Regionen durch und kehren die Replikation um, um die ursprüngliche Topologie wiederherzustellen, wenn alles bereit ist.

Kontinuität der Datenebene: Azure SQL, Storage-Replikation und Cosmos DB

Jeder Datendienst bietet unterschiedliche Semantiken für Dauerhaftigkeit und Failover, die mit den Anforderungen an die Anwendungskonsistenz übereinstimmen müssen.

Azure SQL Database und Azure SQL Managed Instance:

Die aktive Georeplikation erstellt bis zu vier lesbare sekundäre Replikate für einzelne Datenbanken oder elastische Pools. Sie bietet Replikation auf Datenbankebene mit manuellem oder API-gesteuertem Failover und ermöglicht so Read-Scale und DR. Sie ist geeignet, wenn Sie eine datenbankbezogene Steuerung und eine benutzerdefinierte Orchestrierung benötigen.
Autofailover-Gruppen erstellen eine Gruppe von Datenbanken (oder eine gesamte Managed Instance), die gemeinsam mit einem Listener-Endpunkt ein Failover durchführen. Dies vereinfacht das regionsübergreifende Failover und die Verwaltung von Verbindungszeichenfolgen und unterstützt ein automatisches Failover nach einer Toleranzperiode. Verwenden Sie Failover-Gruppen für Anwendungen mit mehreren Datenbanken, die ein koordiniertes Failover und eine vereinfachte Client-Konnektivität erfordern.
Zonenredundanz platziert Replikate über Zonen in einer Region hinweg, um Zonenausfälle ohne regionsübergreifende Wiederherstellung zu überstehen. Aktivieren Sie sie für Tiers, die sie unterstützen, um die lokale Verfügbarkeit zu verbessern, ohne die Latenzprofile zu verändern.

Azure Storage-Replikationsoptionen:

GRS (georedundanter Speicher) repliziert Daten asynchron von der primären Region (drei Kopien) in eine gekoppelte sekundäre Region (drei Kopien). Im Normalbetrieb zielen Lese- und Schreibvorgänge auf die primäre Region.
RA-GRS fügt Lesezugriff auf den sekundären Endpunkt hinzu, für Szenarien wie Notfall-Reporting oder Analysen, wenn die primäre Region beeinträchtigt ist.
GZRS (geozonenredundanter Speicher) kombiniert ZRS in der primären Region für zonale Dauerhaftigkeit mit asynchroner Replikation in die sekundäre Region, was sowohl die lokale als auch die regionale Resilienz verbessert.
RA-GZRS fügt Lesezugriff auf die sekundäre Region für GZRS-Konten hinzu. Wenn die primäre Region nicht wiederherstellbar ist, können Sie ein Kontofailover zur sekundären Region initiieren. Nach dem Failover wird das Speicherkonto in der sekundären Region zum primären Konto und fällt typischerweise auf lokal redundant zurück (bis Sie es neu konfigurieren). Rechnen Sie mit einem gewissen RPO (asynchrone Replikation); Anwendungen sollten nach dem Failover Idempotenz und Abgleich (Reconciliation) handhaben.

Azure Cosmos DB:

Schreibvorgänge in mehreren Regionen (Multi-Region Writes) ermöglichen Schreibvorgänge in jede konfigurierte Region mit Konfliktlösungsrichtlinien (der letzte Schreibvorgang gewinnt über eine festgelegte Eigenschaft, benutzerdefinierte oder Multi-Master-Strategien). Dies reduziert die Schreiblatenz und erhöht die Verfügbarkeit.
Das automatische Failover verwendet eine priorisierte Regionsliste, um bei einem Ausfall eine neue Schreibregion zu bestimmen. In Kombination mit den gewählten Konsistenzebenen (von „Strong“ bis „Eventual“) steuern Sie den Kompromiss zwischen Verfügbarkeit und Konsistenz.
SLAs decken Verfügbarkeit, Durchsatz, Latenz und Konsistenz ab. Mit Schreibvorgängen in mehreren Regionen bietet Cosmos DB eine Verfügbarkeit von bis zu 99,999 % für Lese- und Schreibvorgänge, vorausgesetzt, die Konfiguration für mehrere Regionen ist korrekt. Entwickeln Sie Clients mit dem SDK unter Verwendung von Endpunkterkennung und Wiederholungsversuchen (Retries), um diese Garantien vollständig auszuschöpfen.

← Netzwerk und Konnektivität · Alle Domänen · Sicherheitsarchitektur und Zero Trust →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →