Verfügbarkeit über Zonen und Regionen planen

Beginnen Sie mit dem Nutzervorgang

Hochverfügbarkeit (HA) soll einen Dienst trotz Komponentenausfällen nutzbar halten. Definieren Sie Nutzbarkeit, bevor Sie die Architektur wählen. Eine erfolgreich geladene Buchungsseite, bei der alle Buchungsanfragen scheitern, ist kein verfügbarer Buchungsdienst.

Setzen Sie ein Service Level Objective (SLO) für den wichtigen Vorgang. Definieren Sie die gezählten Anfragen, Erfolg und Messzeitraum. Das SLA eines Clouddienstes beschreibt die Zusage dieses Anbieters. Es belegt nicht die gemessene Verfügbarkeit Ihrer Anwendung.

Zur Veranschaulichung: Eine zeitbasierte Verfügbarkeit von 99,9 % erlaubt 43,2 Minuten Nichtverfügbarkeit in einem Monat mit 30 Tagen. Ein anfragebasiertes SLO hat einen anderen Nenner. Keine der beiden Messgrößen sagt, wie viele Daten verloren gehen dürfen, oder garantiert eine maximale einzelne Ausfalldauer.

Verstehen Sie die Ausfallgrenzen

Eine AWS Availability Zone (AZ) ist ein isolierter Infrastrukturstandort innerhalb einer Region. Eine Region enthält mehrere AZs. Ein Multi-Region-Entwurf verteilt Workload-Komponenten über Regionen. Andere Anbieter haben eigene Grenzen und Dienstverhalten. Prüfen Sie den ausgewählten Dienst.

Dies sind Entwurfsmöglichkeiten und keine Verfügbarkeitsgarantien. Eine Bezeichnung beweist nicht, dass jede benötigte Komponente die vorgesehene Grenze nutzt.

Verfolgen Sie den gesamten Anfragepfad

Betrachten Sie einen fiktiven Buchungsdienst. Webreplikate laufen in zwei AZs. Beide nutzen eine Datenbank und ein ausgehendes Gateway in AZ A. Das Gateway wird für Aufrufe des Zahlungsanbieters benötigt.

Fällt AZ A aus, kann das Webreplikat in AZ B funktionsfähig bleiben, während Buchungen trotzdem scheitern. Das Team muss Datenbank, Netzwerkpfad, Identitätsanbieter, Zahlungsabhängigkeit und Routing bewerten. Prüfen Sie den tatsächlichen Modus der verwalteten Datenbank: Replikation, Failover und Leseverhalten unterscheiden sich nach Produkt und Konfiguration.

Prüfen Sie auch die Kapazität. Die verbleibenden Ressourcen müssen die erforderliche Last tragen. Ein Entwurf, der erst während eines Incidents Kapazität erstellt, hängt von Quoten, verfügbaren Ressourcen und Control-Plane-Vorgängen ab.

Führen Sie eine kontrollierte Übung mit definiertem Umfang, Stoppbedingungen und einer verantwortlichen Person durch. Prüfen Sie eine vollständige Buchung einschließlich Zahlungsabgleich. Erfassen Sie fehlgeschlagene Anfragen und die Zeit bis zur Wiederherstellung eines nutzbaren Betriebs.

Entscheiden Sie, ob eine weitere Region das Problem löst

Multi-Region-Betrieb schafft Datenübertragung, doppelte Ressourcen, Deployment-Abstimmung und Betriebsarbeit. Aktiv/passiv hält eine Umgebung für die Übernahme des Verkehrs bereit. Aktiv/aktiv verarbeitet Verkehr in mehr als einer Umgebung. Erforderlicher Bereitschaftsgrad und Datenverhalten unterscheiden sich.

Beim Buchungsdienst entsteht durch gleichzeitige Schreibvorgänge eine Frage: Können zwei Regionen denselben Sitzplatz verkaufen? Definieren Sie, welche Instanz für eine Buchung maßgeblich ist und was bei unterbrochener Replikation passiert. „Die Datenbank replizieren“ ist keine vollständige Antwort.

Prüfen Sie erlaubte Datenstandorte, Verschlüsselungsschlüssel, Zertifikate, DNS, Secrets und externe Dienste. Ein gemeinsamer Identitätsausfall oder eine fehlerhafte Veröffentlichung kann mehrere Regionen betreffen. Mehr Standorte beseitigen nicht jede gemeinsame Ursache.

Verbinden Sie Verfügbarkeit und Wiederherstellung

HA behandelt festgelegte Ausfälle im Betrieb. Disaster Recovery stellt nach einem störenden Ereignis einen nutzbaren Dienst und seine Daten wieder her. Auch ein Multi-Region-Dienst braucht einen Wiederherstellungsplan für Löschung oder beschädigte Daten.

Dokumentieren Sie die gewählten Ausfallszenarien und jene, die das Unternehmen akzeptiert. Halten Sie Tests und Infrastrukturdefinitionen bei Anwendungsänderungen aufeinander abgestimmt. Lesen Sie weiter über RTO, RPO und Disaster Recovery.