Multi-AZ-Muster für zustandsbehaftete Services

Zustandsbehaftete Services — Datenbanken, Caches und Dateisysteme — sind am schwierigsten hochverfügbar zu machen, da sie Daten enthalten, die Ausfälle überstehen müssen. Wenn eine Datenbank in nur einer AZ ausfällt, verliert Ihre gesamte Anwendung ihren Datenspeicher. AWS begegnet diesem Problem mit Multi-AZ-Bereitstellungen, bei denen der Service ein synchrones oder nahezu synchrones Replikat in einer zweiten Availability Zone unterhält, das bei einem Ausfall des primären Systems schnell übernehmen kann.

RDS Multi-AZ unterhält ein synchrones Standby-Replikat in einer anderen AZ. Jeder Schreibvorgang auf dem primären System wird synchron repliziert, bevor der Erfolg bestätigt wird — dadurch entsteht kein Datenverlust (RPO=0), allerdings steigt die Schreib-Latenz geringfügig. Wenn das primäre System ausfällt, aktualisiert RDS den DNS-Endpunkt innerhalb von 60–120 Sekunden automatisch, sodass er auf die Standby-Instanz verweist. Ihre Anwendung muss lediglich erneut eine Verbindung mit demselben Endpunkt herstellen — Änderungen am Code sind nicht erforderlich.

Amazon Aurora geht bei Multi-AZ noch einen Schritt weiter: Eine gemeinsam genutzte verteilte Speicherschicht repliziert Daten automatisch über drei AZs hinweg in sechs Kopien. Aurora-Instanzen sind zustandslos – sie lesen aus diesem gemeinsam genutzten Speicher und schreiben in ihn. Wenn der primäre Aurora-Writer ausfällt, wird innerhalb von weniger als 30 Sekunden ein Lesereplikat in einer anderen AZ zum Writer hochgestuft. Dies ist schneller als ein RDS-Multi-AZ-Failover, und die Daten sind über alle AZs hinweg stets konsistent, ohne dass eine explizite Replikation auf eine Standby-Instanz erforderlich ist.

ElastiCache for Redis unterstützt Multi-AZ über Replikationsgruppen. Ein primärer Knoten nimmt Schreibvorgänge entgegen und repliziert sie asynchron auf Lesereplikate in anderen AZs. Wenn der primäre Knoten ausfällt, stuft ElastiCache automatisch ein Replikat zum primären Knoten hoch. Wenn der Cluster-Modus aktiviert ist, werden die Daten über mehrere Knotengruppen verteilt. Jede dieser Gruppen verfügt über einen eigenen primären Knoten und Replikate in verschiedenen AZs. Dies bietet sowohl hohe Verfügbarkeit als auch horizontale Skalierung.

Amazon Elastic File System (EFS) ist von Haus aus Multi-AZ-fähig: Es handelt sich um einen regionalen Service, der Daten redundant über mehrere AZs innerhalb einer Region speichert. Sie erstellen Mount Targets im Subnetz jeder AZ. EC2-Instanzen in jeder AZ können das Dateisystem dann über das lokale Mount Target einbinden. Eine manuelle Multi-AZ-Konfiguration ist nicht erforderlich. EFS stellt gemeinsam genutzten POSIX-Dateispeicher bereit, auf den mehrere Instanzen in verschiedenen AZs gleichzeitig zugreifen können.

Elastic Load Balancer sind selbst Multi-AZ-fähig: ALB und NLB stellen Load-Balancer-Knoten in jeder von Ihnen angegebenen AZ bereit. Bei aktiviertem zonenübergreifendem Load Balancing (Standardeinstellung für ALB) verteilt jeder Load-Balancer-Knoten den Datenverkehr gleichmäßig auf alle registrierten Ziele in sämtlichen AZs und nicht nur in seiner eigenen AZ. Dadurch stellt der Load Balancer den Datenverkehr auch dann weiterhin über Instanzen in den verbleibenden AZs bereit, wenn alle Instanzen in einer AZ ausfallen.

Ein häufiger Fehler besteht darin, ein einzelnes NAT Gateway in einer AZ bereitzustellen, während private Subnetze in anderen AZs den Datenverkehr darüber leiten. Fällt diese AZ aus, verlieren alle privaten Instanzen den Internetzugang. Das korrekte Multi-AZ-Muster besteht darin, ein NAT Gateway pro AZ bereitzustellen und die private Routing-Tabelle jeder AZ so zu konfigurieren, dass sie 0.0.0.0/0 über das eigene NAT Gateway leitet. Dadurch wird das NAT Gateway als Single Point of Failure (SPOF) zwischen AZs beseitigt und die Kosten für den Datenverkehr zwischen AZs werden reduziert.

DynamoDB ist ein vollständig verwalteter Service, der Daten innerhalb einer Region automatisch über drei AZs hinweg repliziert. Sie müssen Multi-AZ nicht manuell konfigurieren. Jeder Schreibvorgang wird dauerhaft in allen drei AZs gespeichert, bevor eine erfolgreiche Ausführung zurückgegeben wird. DynamoDB ist damit standardmäßig praktisch fehlertolerant auf AZ-Ebene. Deshalb wird DynamoDB in Prüfungsfragen, bei denen hohe Verfügbarkeit bei minimalem Betriebsaufwand im Mittelpunkt steht, häufig als bevorzugte Datenbank empfohlen.

Während eines RDS-Multi-AZ-Failovers können bei Anwendungen mit dauerhaft geöffneten Datenbankverbindungen Fehler auftreten, wenn sich der Endpunkt ändert. RDS Proxy befindet sich zwischen Ihrer Anwendung und RDS und verwaltet einen Pool von Datenbankverbindungen. Während eines Failovers leitet RDS Proxy die Verbindungen automatisch an den neuen primären Knoten weiter. Für Anwendungen, die den Proxy-Endpunkt verwenden, wird die Auswirkung des Failovers dadurch von 60–120 Sekunden auf weniger als 30 Sekunden reduziert. RDS Proxy ist außerdem hilfreich bei Lambda-Funktionen, die viele kurzlebige Verbindungen erstellen.

Für die Auswahl von Multi-AZ-Mustern ist es entscheidend, die Replikationsmodi zu verstehen. Synchrone Replikation (RDS Multi-AZ, EFS) gewährleistet RPO=0, da jeder Schreibvorgang in beiden AZs bestätigt wird, bevor der Erfolg zurückgegeben wird. Der Nachteil ist eine geringfügig höhere Latenz bei Schreibvorgängen. Asynchrone Replikation (ElastiCache-Redis-Replikate, RDS-Lesereplikate) bietet eine geringere Schreiblatenz, nimmt jedoch eine geringe Replikationsverzögerung in Kauf. Das bedeutet, dass Daten verloren gehen können, wenn der primäre Knoten ausfällt, bevor die Replikation abgeschlossen ist.

Sie sollten das Multi-AZ-Failover regelmäßig testen, um Ihre RTO-Annahmen zu überprüfen. Für RDS können Sie ein Failover über die Option Reboot with failover in der Konsole oder über die CLI auslösen. Überwachen Sie CloudWatch auf die Metrik FailedSQLServerAgentJobsCount und prüfen Sie die Anwendungsprotokolle, um zu verifizieren, dass die Anwendung erfolgreich wieder eine Verbindung herstellt. Dokumentieren Sie die tatsächliche Dauer des Failovers. Diese kann abhängig von Ihrer Instance-Klasse und Ihrer Workload von der AWS-Dokumentation abweichen.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: RDS Multi-AZ verwendet synchrone Replikation mit automatischem DNS-Failover, Aurora verwendet eine gemeinsam genutzte Speicherschicht über drei AZs hinweg für ein schnelleres Failover und EFS und DynamoDB sind ohne manuelle Konfiguration von Haus aus Multi-AZ-fähig. Stellen Sie ein NAT Gateway pro AZ bereit, um SPOFs zwischen AZs zu vermeiden. Als Nächstes betrachten wir Active-Active- und Active-Passive-Muster über mehrere Regionen hinweg.