REL11-BP03 Automatisieren Sie die Heilung auf allen Ebenen - 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-BP03 Automatisieren Sie die Heilung auf allen Ebenen

Verwenden Sie bei Erkennung eines Fehlers automatisierte Funktionen, um Maßnahmen zur Behebung durchzuführen. Beeinträchtigungen können automatisch durch interne Service-Mechanismen behoben werden. Es kann aber auch erforderlich sein, Ressourcen neu zu starten oder Abhilfemaßnahmen durchzuführen.

Für selbstverwaltete Anwendungen und regionenübergreifende Korrekturen können Wiederherstellungskonzepte und automatisierte Korrekturprozesse aus bestehenden bewährten Methoden verwendet werden.

Die Möglichkeit, eine Ressource neu zu starten oder zu entfernen, ist ein wichtiges Instrument zur Behebung von Fehlern. Eine bewährte Methode besteht darin, Services nach Möglichkeit zustandslos zu betreiben. Dies verhindert den Datenverlust oder den Verlust der Verfügbarkeit bei einem Neustart der Ressource. In der Cloud können Sie (und sollten Sie üblicherweise) die gesamte Ressource (z. B. eine Datenverarbeitungs-Instance oder eine Serverless-Funktion) im Rahmen des Neustarts ersetzen. Der Neustart selbst ist eine einfache und zuverlässige Methode zur Wiederherstellung nach einem Ausfall. Bei Workloads treten viele verschiedene Arten von Fehlern auf. Fehler können bei Hardware, Software, Kommunikation und Betrieb auftreten.

Der Neustart oder Wiederholungsversuch gilt auch für Netzwerkanfragen. Nutzen Sie denselben Wiederherstellungsansatz für eine Netzwerk-Zeitüberschreitung und einen Abhängigkeitsfehler, bei dem die Abhängigkeit einen Fehler ausgibt. Beide Ereignisse wirken sich in ähnlicher Weise auf das System aus. Statt also zu versuchen, aus den einzelnen Ereignissen einen „Sonderfall“ zu konstruieren, sollten Sie eine ähnliche Strategie anwenden und versuchen, ein exponentielles Backoff mit Jitter durchzuführen. Die Fähigkeit zum Neustart ist eine Funktion, die in wiederherstellungsorientierten Datenverarbeitungs- und Hochverfügbarkeits-Cluster-Architekturen empfohlen wird.

Gewünschtes Ergebnis: Automatisierte Aktionen werden durchgeführt, um die Erkennung eines Fehlers zu beheben.

Typische Anti-Muster:

  • Bereitstellung von Ressourcen ohne automatische Skalierung.

  • Einzelne Bereitstellung von Anwendungen in Instances oder Containern.

  • Bereitstellen von Anwendungen, die nicht ohne automatische Wiederherstellung an mehreren Standorten bereitgestellt werden können.

  • Manuelle Reparatur von Anwendungen, die sich mit Auto Scaling und einer automatischen Wiederherstellung nicht reparieren lassen.

  • Keine Automatisierung beim Failover von Datenbanken.

  • Keine automatisierten Methoden zur Umleitung des Datenverkehrs auf neue Endpunkte.

  • Keine Speicherreplikation.

Vorteile der Nutzung dieser bewährten Methode: Eine automatisierte Korrektur kann die mittlere Zeit bis zur Wiederherstellung verkürzen und Ihre Verfügbarkeit verbessern.

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

Implementierungsleitfaden

Designs für Amazon EKS oder andere Kubernetes-Dienste sollten sowohl minimale als auch maximale Replikat- oder Stateful-Sets sowie die minimale Cluster- und Knotengruppengröße beinhalten. Diese Mechanismen sorgen für ein Minimum an kontinuierlich verfügbaren Verarbeitungsressourcen und beheben gleichzeitig automatisch alle Fehler über die Steuerebene von Kubernetes.

Entwurfsmuster, auf die über einen Load Balancer mit Datenverarbeitungs-Clustern zugegriffen wird, sollten Auto-Scaling-Gruppen nutzen. Elastic Load Balancing (ELB) verteilt den eingehenden Anwendungsdatenverkehr automatisch auf mehrere Ziele und virtuelle Appliances in einer oder mehreren Availability Zones (AZs).

Bei Cluster-Datenverarbeitungs-Instances, die kein Load Balancing nutzen, sollte die Größe für den Verlust von mindestens einem Knoten ausgelegt sein. Auf diese Weise kann der Service mit möglicherweise reduzierter Kapazität weiterlaufen, während er einen neuen Knoten wiederherstellt. Beispieldienste sind Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon, CassandraEMR, Kafka, MSK -EC2, Couchbase und Amazon Service. ELK OpenSearch Viele dieser Services können mit zusätzlichen Features zur Selbstheilung ausgestattet werden. Einige Cluster-Technologien müssen beim Verlust eines Knotens einen Alarm generieren, der einen automatisierten oder manuellen Workflow zur Wiederherstellung eines neuen Knotens auslöst. Dieser Workflow kann automatisiert werden, um Probleme schnell zu beheben. AWS Systems Manager

Amazon EventBridge kann verwendet werden, um Ereignisse wie CloudWatch Alarme oder Statusänderungen in anderen AWS Diensten zu überwachen und zu filtern. Auf der Grundlage von Ereignisinformationen kann es dann Systems Manager Automation oder andere Ziele aufrufen AWS Lambda, um eine benutzerdefinierte Behebungslogik für Ihren Workload auszuführen. Amazon EC2 Auto Scaling kann so konfiguriert werden, dass es beispielsweise den Zustand der EC2 Instanz überprüft. Wenn sich die Instance in einem anderen Status als in Betrieb befindet oder wenn der Systemstatus beeinträchtigt ist, betrachtet Amazon EC2 Auto Scaling die Instance als fehlerhaft und startet eine Ersatz-Instance. Bei Large-Scale-Ersetzungen (z. B. dem Verlust einer ganzen Availability Zone) ist für eine Hochverfügbarkeit die statische Stabilität vorzuziehen.

Implementierungsschritte

  • Verwenden Sie Auto-Scaling-Gruppen, um Tiers in einem Workload bereitzustellen. Auto Scaling kann zustandslose Anwendungen selbst reparieren und Kapazitäten hinzufügen oder entfernen.

  • Verwenden Sie Load Balancing für die zuvor genannten Datenverarbeitungs-Instances und wählen Sie den entsprechenden Load Balancer-Typ aus.

  • Erwägen Sie Healing for AmazonRDS. Konfigurieren Sie bei Standby-Instances das automatische Failover zur Standby-Instance. Für Amazon RDS Read Replica ist ein automatisierter Workflow erforderlich, um eine Read Replica primär zu machen.

  • Implementieren Sie die automatische Wiederherstellung für EC2 Instances, auf denen Anwendungen bereitgestellt werden, die nicht an mehreren Standorten bereitgestellt werden können, und tolerieren Sie bei Fehlern einen Neustart. Mithilfe der automatischen Wiederherstellung kann ausgefallene Hardware ersetzt und die Instance neu gestartet werden, wenn die Anwendung sich nicht an mehreren Standorten bereitstellen lässt. Die Instance-Metadaten und die zugehörigen IP-Adressen sowie die EBSVolumes und Mount-Points für Amazon Elastic File System oder File Systems for Lustre und Windows werden beibehalten. Mithilfe AWS OpsWorkskönnen Sie die automatische Heilung von EC2 Instances auf Layer-Ebene konfigurieren.

  • Implementieren Sie die automatische Wiederherstellung mit AWS Step Functions und AWS Lambda, wenn Sie keine automatische Skalierung oder automatische Wiederherstellung verwenden können oder wenn die automatische Wiederherstellung fehlschlägt. Wenn Sie die automatische Skalierung nicht verwenden können und entweder die automatische Wiederherstellung nicht verwenden können oder die automatische Wiederherstellung fehlschlägt, können Sie die Wiederherstellung mit AWS Step Functions und automatisieren AWS Lambda.

  • Amazon EventBridge kann verwendet werden, um Ereignisse wie CloudWatchAlarme oder Statusänderungen in anderen AWS Diensten zu überwachen und zu filtern. Auf der Grundlage von Ereignisinformationen kann es dann AWS Lambda (oder andere Ziele) aufrufen, um eine angepasste Wiederherstellungslogik für Ihre Workload auszuführen.

Ressourcen

Zugehörige bewährte Methoden:

Zugehörige Dokumente:

Zugehörige Videos:

Zugehörige Beispiele:

Zugehörige Tools: