REL11-BP02 Failover zu gesunden Ressourcen - Säule der Zuverlässigkeit
Implementierungsleitfaden Ressourcen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

REL11-BP02 Failover zu gesunden Ressourcen

Wenn ein Fehler bei einer Ressource auftritt, sollten intakte Ressourcen weiterhin Anfragen bedienen. Stellen Sie bei Standortbeeinträchtigungen (wie Availability Zone oder AWS-Region) sicher, dass Sie über Systeme verfügen, die ein Failover auf intakte Ressourcen an unbeeinträchtigten Standorten ermöglichen.

Wenn Sie einen Service entwerfen, verteilen Sie die Last auf Ressourcen, Availability Zones oder Regionen. So kann der Fehler einer einzelnen Ressource oder eine Beeinträchtigung durch die Verlagerung des Datenverkehrs auf die verbleibenden intakten Ressourcen aufgefangen werden. Überlegen Sie, wie Services im Falle eines Fehlers erkannt und geroutet werden.

Entwerfen Sie Ihre Services mit Blick auf die Fehlerbehebung. Wir bei entwickeln Services so AWS, dass die Zeit bis zur Wiederherstellung nach Ausfällen und Auswirkungen auf Daten minimiert wird. Unsere Services verwenden primär Datenspeicher, die Anfragen erst akzeptieren, nachdem sie dauerhaft auf mehreren Replikaten in einer Region gespeichert wurden. Sie sind so aufgebaut, dass sie eine zellenbasierte Isolation und die Fehlerisolierung von Availability Zones nutzen. In unseren betrieblichen Abläufen setzen wir sehr stark auf Automatisierung. Wir optimieren auch unsere replace-and-restart Funktionalität, um nach Unterbrechungen eine schnelle Wiederherstellung zu gewährleisten.

Die Muster und Entwürfe, die den Failover ermöglichen, variieren für jeden AWS -Plattform-Service. Viele AWS native verwaltete Dienste haben nativ mehrere Availability Zones (wie Lambda oder API Gateway). Andere AWS Dienste (wie EC2 undEKS) erfordern spezielle Best-Practice-Designs, um das Failover von Ressourcen oder Datenspeicher auf allen Ebenen zu unterstützen. AZs

Es sollte eine Überwachung eingerichtet werden, um zu überprüfen, ob die Failover-Ressource in Ordnung ist, den Fortschritt der Failover-Ressourcen zu verfolgen und die Wiederherstellung von Geschäftsprozessen zu überwachen.

Gewünschtes Ergebnis: Die Systeme sind in der Lage, automatisch oder manuell neue Ressourcen zu verwenden, um sich von Störungen zu erholen.

Typische Anti-Muster:

  • Die Planung für Fehler ist nicht Teil der Planungs- und Designphase.

  • RTOund RPO sind nicht etabliert.

  • Unzureichende Überwachung, um ausfallende Ressourcen zu erkennen.

  • Ordnungsgemäße Isolierung von fehlerhaften Domains.

  • Multi-Region-Failover wird nicht berücksichtigt.

  • Die Erkennung von Fehlern ist bei der Entscheidung für einen Failover zu empfindlich oder zu aggressiv.

  • Failover-Design wird nicht getestet oder validiert.

  • Durchführen automatischer Reparaturen ohne die Benachrichtigung, dass eine Reparatur erforderlich war.

  • Fehlender Ausgleichszeitraum, um einen zu frühen Failover zu vermeiden.

Vorteile der Nutzung dieser bewährten Methode: Sie können widerstandsfähigere Systeme aufbauen, die auch bei Fehlern zuverlässig bleiben, indem sie ordnungsgemäß reduziert werden und sich schnell erholen.

Risikostufe, wenn diese bewährte Methode nicht eingeführt wird: Hoch

Implementierungsleitfaden

AWS Dienste wie Elastic Load Balancing und Amazon EC2 Auto Scaling helfen dabei, die Last auf Ressourcen und Availability Zones zu verteilen. Daher kann der Ausfall einer einzelnen Ressource (z. B. einer EC2 Instance) oder die Beeinträchtigung einer Availability Zone gemildert werden, indem der Datenverkehr auf die verbleibenden intakten Ressourcen verlagert wird.

Bei Workloads, die mehrere Regionen umfassen, sind Designs etwas komplizierter. Mit regionsübergreifenden Read Replicas können Sie Ihre Daten beispielsweise mehreren Benutzern zur Verfügung stellen. AWS-Regionen Der Failover ist jedoch immer noch erforderlich, um das Lesereplikat zum primären Endpunkt zu machen und den Datenverkehr auf den neuen Endpunkt zu lenken. Amazon Route 53, Amazon Application Recovery Controller (ARC), Amazon und AWS Global Accelerator können dabei helfen CloudFront, den Datenverkehr weiterzuleiten AWS-Regionen.

AWS Dienste wie Amazon S3, Lambda, API Gateway, Amazon, Amazon, Amazon SQSSNS, Amazon PinpointSES, Amazon, ECR AWS Certificate Manager EventBridge, oder Amazon DynamoDB werden automatisch in mehreren Availability Zones von bereitgestellt. AWS Im Falle eines Fehlers leiten diese AWS Dienste den Datenverkehr automatisch an fehlerfreie Standorte weiter. Die Daten werden redundant in mehreren Availability Zones gespeichert und bleiben verfügbar.

Für AmazonRDS, Amazon Aurora, Amazon RedshiftEKS, Amazon oder Amazon ECS ist Multi-AZ eine Konfigurationsoption. AWS kann den Datenverkehr an die fehlerfreie Instance weiterleiten, wenn ein Failover initiiert wird. Diese Failover-Maßnahme kann vom Kunden AWS oder auf Wunsch des Kunden ergriffen werden

Für EC2 Amazon-Instances, Amazon Redshift, ECS Amazon-Aufgaben oder EKS Amazon-Pods wählen Sie aus, in welchen Availability Zones die Bereitstellung erfolgen soll. Bei einigen Designs bietet Elastic Load Balancing die Lösung, um Instances in fehlerhaften Zonen zu erkennen und den Datenverkehr an die fehlerfreien Zonen weiterzuleiten. Elastic Load Balancing kann den Datenverkehr auch an Komponenten in Ihrem On-Premises-Rechenzentrum weiterleiten.

Für den Failover des Datenverkehrs in mehreren Regionen kann die Umleitung Amazon Route 53, Amazon Application Recovery Controller AWS Global Accelerator, Route 53 Private DNS for nutzen oder eine Möglichkeit bietenVPCs, Internetdomänen CloudFront zu definieren und Routing-Richtlinien, einschließlich Zustandsprüfungen, zuzuweisen, um den Verkehr in fehlerfreie Regionen weiterzuleiten. AWS Global Accelerator stellt statische IP-Adressen bereit, die als fester Zugangspunkt für Ihre Anwendung dienen und dann zu Endpunkten Ihrer Wahl weiterleiten, wobei das AWS globale Netzwerk anstelle AWS-Regionen des Internets verwendet wird, um eine bessere Leistung und Zuverlässigkeit zu erzielen.

Implementierungsschritte

  • Erstellen Sie Failover-Designs für alle entsprechenden Anwendungen und Services. Isolieren Sie jede Architekturkomponente und erstellen Sie Failover-Designs, die den einzelnen Komponenten RPO entsprechen. RTO

  • Konfigurieren Sie weniger anspruchsvolle Umgebungen (wie Entwicklungs- oder Testumgebungen) mit allen Services, die für einen Failover-Plan erforderlich sind. Stellen Sie die Lösungen mit Infrastructure as Code (IaC) bereit, um die Reproduzierbarkeit sicherzustellen.

  • Konfigurieren Sie einen Wiederherstellungsstandort, z. B. eine zweite Region, um die Failover-Designs zu implementieren und zu testen. Falls erforderlich, können die Ressourcen für die Tests vorübergehend konfiguriert werden, um die zusätzlichen Kosten zu begrenzen.

  • Ermitteln Sie, welche Failover-Pläne automatisiert werden AWS, welche durch einen DevOps Prozess automatisiert werden können und welche möglicherweise manuell ausgeführt werden. Dokumentieren und messen Sie die Daten der RTO einzelnen Services. RPO

  • Erstellen Sie ein Failover-Playbook, das alle Schritte zum Failover jeder Ressource, Anwendung und jedes Services enthält.

  • Erstellen Sie ein Failback-Playbook, das alle Schritte zum Failback (mit Zeitangabe) für jede Ressource, jede Anwendung und jeden Service enthält.

  • Erstellen Sie einen Plan, um das Playbook zu initiieren und zu proben. Verwenden Sie Simulationen und Chaostests, um die Schritte des Playbooks und die Automatisierung zu testen.

  • Stellen Sie bei Standortbeeinträchtigungen (z. B. Availability Zone oder AWS-Region) sicher, dass Sie über Systeme verfügen, die ein Failover auf intakte Ressourcen an unbeeinträchtigten Standorten ermöglichen. Überprüfen Sie Kontingente, die automatische Skalierung und laufende Ressourcen vor dem Failover-Test.

Ressourcen

Zugehörige bewährte Methoden für Well-Architected:

Zugehörige Dokumente:

Zugehörige Beispiele: