DR für PaaS-Dienste

Disaster Recovery für IaaS-Dienste (VMs) umfasst typischerweise Azure Site Recovery, um das gesamte Betriebssystem und die Datenträger in eine sekundäre Region zu replizieren. PaaS-Dienste verwenden andere DR-Modelle, da die zugrunde liegende Infrastruktur von Microsoft verwaltet wird. Bei PaaS wird DR normalerweise auf der Datenschicht konfiguriert: Die Daten werden in eine sekundäre Region repliziert, während die Plattform selbst automatisch gestartet wird.

Azure SQL Database bietet innerhalb einer einzelnen Region integrierte Hochverfügbarkeit auf Zonenebene. Für regionsübergreifendes DR stehen zwei zentrale Funktionen zur Verfügung: active geo-replication (lesbare sekundäre Datenbanken in bis zu vier weiteren Regionen) und auto-failover groups (automatisiertes Failover mit einem einzigen Listener-Endpunkt). Diese werden auf Datenbank- oder Serverebene konfiguriert, ohne dass Azure Site Recovery erforderlich ist.

Auto-failover groups ergänzen die Georeplikation um Automatisierung und einen einzigen Verbindungsendpunkt. Sie konfigurieren eine Gruppe auf dem primären Server, fügen den sekundären Server hinzu und definieren eine Gnadenfrist – den Zeitraum, den Azure auf die Wiederherstellung des primären Servers wartet, bevor ein automatisches Failover ausgelöst wird. Anwendungen verbinden sich mit dem Listener-Endpunkt (z. B. mygroup.database.windows.net) und werden nach dem Failover automatisch umgeleitet, ohne dass Verbindungszeichenfolgen geändert werden müssen.

Die Georeplikation von Azure SQL Database erfolgt asynchron: Transaktionen werden auf dem primären System festgeschrieben und anschließend auf das sekundäre System repliziert. Dadurch entsteht eine kleine Replikationsverzögerung, die unter normalen Bedingungen typischerweise weniger als 5 Sekunden beträgt. Das RPO für die SQL-Georeplikation liegt daher in den meisten Szenarien bei ungefähr 5 Sekunden. Damit eignet sie sich für Workloads der Stufen 1 und 2, die einen sehr geringen Datenverlust erfordern.

Alle Tarife von Azure SQL Database umfassen automatisierte Sicherungen: wöchentliche vollständige Sicherungen, differenzielle Sicherungen alle 12 Stunden und Sicherungen des Transaktionsprotokolls alle 5–12 Minuten. Dadurch wird Point-in-Time Restore (PITR) ermöglicht – die Wiederherstellung der Datenbank auf jede Sekunde innerhalb des Aufbewahrungszeitraums (7–35 Tage für Standard/General Purpose, bis zu 35 Tage für Business Critical). PITR eignet sich zur Wiederherstellung nach versehentlichem Löschen oder Beschädigen von Daten.

Azure Cosmos DB mit Schreibvorgängen in mehreren Regionen bietet für globale Anwendungen ein nahezu null betragendes RPO. Alle konfigurierten Regionen können gleichzeitig Schreibvorgänge akzeptieren, und Cosmos DB synchronisiert die Daten automatisch mithilfe seines proprietären Replikationsprotokolls. Wenn eine Region ausfällt, wird der Datenverkehr automatisch an die verbleibenden fehlerfreien Regionen weitergeleitet. Ein manuelles Failover ist nicht erforderlich – dadurch werden RTO und RPO nahe null erreicht.

Azure App Service ist selbst zustandslos (Anwendungscode wird aus der Quellcodeverwaltung oder einer ZIP-Datei bereitgestellt). Bei DR liegt der Schwerpunkt auf der Datenschicht (Datenbank und Blob Storage). App Service kann mithilfe einer CI/CD-Pipeline schnell in einer sekundären Region erneut bereitgestellt werden. Sie sollten jedoch sicherstellen, dass Ihre benutzerdefinierte Domäne, TLS-Zertifikate und App-Einstellungen repliziert oder per Skript erfasst werden, damit sie in der sekundären Region schnell wiederhergestellt werden können.

Azure Blob Storage mit Geo-Redundant Storage (GRS) repliziert Daten automatisch in eine Hunderte Kilometer entfernte sekundäre Region. Die Daten werden asynchron repliziert (das RPO beträgt typischerweise weniger als 15 Minuten). Read-Access GRS (RA-GRS) ermöglicht das Lesen vom sekundären Endpunkt, noch bevor ein Failover ausgelöst wird. Dies ist bei einem Ausfall der primären Region für Analyse- und Reporting-Workloads nützlich.

Azure Functions sind von Grund auf zustandslos und lassen sich daher einfach erneut bereitstellen. Für DR stellen Sie dieselbe Function App in einer sekundären Region bereit und verwenden Traffic Manager, um HTTP-Trigger zwischen den Regionen weiterzuleiten. Konfigurieren Sie bei nicht auf HTTP basierenden Triggern (Service Bus, Event Grid) die Nachrichtenquelle so, dass sie an beide Regionen verteilt, oder lassen Sie die sekundäre Region dieselbe Quelle abfragen. Der Zustand von Durable Functions wird in Azure Storage gespeichert. Stellen Sie daher sicher, dass dieser Speicher GRS verwendet.

Verwenden Sie die aktive Georeplikation, wenn Sie eine fein abgestufte Kontrolle benötigen – beispielsweise um Lesezugriffe zur Leistungssteigerung an ein sekundäres Replikat zu leiten oder mehrere sekundäre Replikate in verschiedenen Regionen unabhängig voneinander zu verwalten. Verwenden Sie automatische Failovergruppen, wenn Sie eine einfache Lösung bevorzugen: einen einzelnen Listener-Endpunkt, automatisches Failover nach einem Zeitplan und eine integrierte Orchestrierung des Failover-Prozesses ohne manuelles Eingreifen.

PaaS-DR ist aus mehreren Gründen häufig günstiger als DR auf Basis virtueller Computer. Bei der Georeplikation von SQL Database werden nur der Speicher und die Compute-Ressourcen des sekundären Replikats berechnet; eine vollständige Betriebssystemlizenz für einen virtuellen Computer entfällt. Azure Cosmos DB berechnet die bereitgestellten RUs in jeder Region. Azure Storage GRS erhöht die Speicherkosten um etwa das Doppelte. Im Gegensatz dazu erfordern mit ASR replizierte virtuelle Computer in der sekundären Region vollständige Kosten für Compute-Ressourcen, Speicher und Lizenzen.

Testen Sie Ihr Verständnis der Konzepte von Microsoft Azure Fundamentals (AZ-900) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: PaaS-DR konzentriert sich auf die Datenebene statt auf die Replikation virtueller Computer; automatische Failovergruppen für Azure SQL stellen einen einzelnen Listener-Endpunkt mit automatischem Failover bereit; und Schreibvorgänge in mehreren Regionen von Cosmos DB ermöglichen für globale Anwendungen eine RTO und RPO von nahezu null. Als Nächstes beschäftigen wir uns mit Azure-Compliance-Frameworks und dem Modell der geteilten Verantwortung.