# ZUV 11 Wie lassen sich Workloads so gestalten, dass sie Komponentenausfälle verkraften?
Workloads, die eine hohe Verfügbarkeit und eine niedrige mittlere Wiederherstellungszeit (Mean Time To Recovery, MTTR) benötigen, müssen auf Resilienz ausgelegt sein.
**Topics**
+ [REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Failover zu fehlerfreien Ressourcen](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatisieren der Reparatur auf allen Ebenen](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Verhindern von bimodalem Verhalten mithilfe statischer Stabilität](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Senden von Benachrichtigungen, wenn sich Ereignisse auf die Verfügbarkeit auswirken](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler
Überwachen Sie den Zustand Ihrer Workload kontinuierlich, damit Sie und die automatisierten Systeme eine Verschlechterung oder einen Ausfall umgehend bemerken. Überwachen Sie Key Performance Indicators (KPIs, wichtige Leistungskennzahlen) auf Grundlage des geschäftlichen Wertes.
Alle Wiederherstellungs- und Reparaturmechanismen müssen auf eine schnelle Erkennung von Problemen ausgelegt sein. Technische Fehler sollten zuerst erkannt werden, damit sie behoben werden können. Die Verfügbarkeit basiert jedoch auf der Fähigkeit Ihrer Workload, einen Unternehmenswert zu liefern. Daher müssen wichtige Leistungskennzahlen (KPIs), die dies messen, in Ihre Erkennungs- und Behebungsstrategie integriert sein.
**Gängige Antimuster:**
+ Es sind keine Alarme konfiguriert, sodass Ausfälle ohne Benachrichtigung auftreten.
+ Alarme sind vorhanden, aber mit Schwellenwerten, die keine ausreichende Zeit für die Reaktion bieten.
+ Metriken werden nicht häufig genug erfasst, um das Recovery Time Objective (RTO, Wiederherstellungsdauer) zu erreichen.
+ Nur die kundenseitige Ebene der Workload wird aktiv überwacht.
+ Es werden nur technische Metriken erfasst, keine Metriken für Geschäftsfunktionen.
+ Es gibt keine Metriken, die die Benutzererfahrung der Workload messen.
**Vorteile der Einführung dieser bewährten Methode:** Wenn alle Ebenen entsprechend überwacht werden, können Sie die Wiederherstellungszeit durch eine schnellere Fehlererkennung verkürzen.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Bestimmen Sie das Erfassungsintervall für die Komponenten auf Grundlage Ihrer Wiederherstellungsziele.
+ Das Überwachungsintervall hängt davon ab, wie schnell Wiederherstellungen durchgeführt werden müssen. Die Wiederherstellungszeit hängt davon ab, wie viel Zeit für eine Wiederherstellung benötigt wird. Daher müssen Sie die Häufigkeit der Erfassung bestimmen, indem Sie diese Zeit und das RTO einkalkulieren.
+ Konfigurieren Sie eine detaillierte Überwachung für die Komponenten.
+ Legen Sie fest, ob eine detaillierte Überwachung für EC2-Instances und Auto Scaling erforderlich ist. Die detaillierte Überwachung stellt Metriken in 1-Minuten-Intervallen bereit; die Standardüberwachung stellt Metriken in 5-Minuten-Intervallen bereit.
+ [Aktivieren oder deaktivieren Sie die detaillierte Überwachung für Ihre Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Überwachen Ihrer Auto-Scaling-Gruppen und Instances mit Amazon CloudWatch.](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ Legen Sie fest, ob eine erweiterte Überwachung für RDS notwendig ist. Die erweiterte Überwachung verwendet einen Agenten in den RDS-Instances, um nützliche Informationen zu verschiedenen Prozessen oder Threads in einer RDS-Instance abzurufen.
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ Erstellen Sie benutzerdefinierte Metriken, um Leistungskennzahlen (KPIs) zu messen. Mit Workloads werden wichtige Geschäftsfunktionen implementiert. Diese Funktionen sollten als KPIs verwendet werden, um die Identifizierung indirekter Probleme zu unterstützen.
+ [Veröffentlichen benutzerdefinierter Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Überwachen Sie das Benutzererlebnis auf Fehler mithilfe von Benutzer-Canaries. Synthetische Transaktionstests (auch bekannt als „Canary-Tests“, die aber nicht mit Canary-Bereitstellungen zu verwechseln sind), mit denen das Kundenverhalten simuliert werden kann, gehören zu den wichtigsten Testprozessen. Führen Sie diese Tests für Ihre Workload-Endpunkte konstant von verschiedenen Remote-Standorten aus.
+ [Amazon CloudWatch Synthetics unterstützt Sie bei der Erstellung von Benutzer-Canaries.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ Erstellen Sie benutzerdefinierte Metriken zur Nachverfolgung des Benutzererlebnisses. Wenn Sie das Kundenerlebnis instrumentieren können, können Sie die Verschlechterung des Kundenerlebnisses feststellen.
+ [Veröffentlichen benutzerdefinierter Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Richten Sie Alarme ein, um zu erkennen, wenn ein Teil Ihrer Workload nicht ordnungsgemäß funktioniert, und um anzugeben, wann Ressourcen automatisch skaliert werden müssen. Alarme können visuell in Dashboards angezeigt werden, Warnungen per Amazon SNS oder E-Mail senden und mit Auto Scaling die Ressourcen für eine Workload auf- oder abzuskalieren.
+ [Verwenden von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ Erstellen Sie Dashboards, um Ihre Metriken zu visualisieren. Dashboards können verwendet werden, um Trends, Ausreißer und andere Indikatoren für potenzielle Probleme zu visualisieren, und auf Probleme hinweisen, die Sie untersuchen sollten.
+ [Verwenden von CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## Ressourcen
**Relevante Dokumente:**
+ [Amazon CloudWatch Synthetics unterstützt Sie bei der Erstellung von Benutzer-Canaries.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Aktivieren oder deaktivieren Sie die detaillierte Überwachung für Ihre Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Überwachen Ihrer Auto-Scaling-Gruppen und Instances mit Amazon CloudWatch.](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [Veröffentlichen benutzerdefinierter Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Verwenden von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Verwenden von CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**Ähnliche Beispiele:**
+ [Well-Architected Lab: Level 300: Implementieren von Zustandsprüfungen und Verwalten von Abhängigkeiten zur Verbesserung der Zuverlässigkeit](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 Failover zu fehlerfreien Ressourcen
Stellen Sie sicher, dass fehlerfreie Ressourcen weiterhin Anforderungen erfüllen können, wenn ein Ressourcenausfall auftritt. Stellen Sie bei Standortausfällen (z. B. einer Availability Zone oder AWS-Region) sicher, dass Sie Failover zu fehlerfreien Ressourcen an nicht beeinträchtigten Standorten eingerichtet haben.
AWS-Services wie Elastic Load Balancing und AWS Auto Scaling helfen dabei, Lasten über verschiedene Ressourcen und Availability Zones hinweg zu verteilen. Daher können der Ausfall einer einzelnen Ressource (wie etwa einer EC2-Instance) oder die Beeinträchtigung einer Availability Zone gemindert werden, indem Datenverkehr verlagert wird, um Ressourcen fehlerfrei zu halten. Bei Workloads mit mehreren Regionen ist dies komplizierter. Regionsübergreifende Lesereplikate ermöglichen Ihnen beispielsweise die Bereitstellung Ihrer Daten in mehreren AWS-Regionen. Sie müssen die Lesereplikate jedoch als primär hochstufen und Ihren Datenverkehr bei einem Failover darauf verweisen. Amazon Route 53 und AWS Global Accelerator können dabei helfen, Datenverkehr über AWS-Regionen zu leiten.
Wenn in Ihrer Workload AWS-Services wie Amazon S3 oder Amazon DynamoDB verwendet werden, werden diese automatisch in mehreren Availability Zones bereitgestellt. Bei einem Ausfall leitet die AWS-Steuerebene den Datenverkehr automatisch an fehlerfreie Standorte weiter. Die Daten werden redundant in mehreren Availability Zones gespeichert und bleiben verfügbar. Für Amazon RDS müssen Sie Multi-AZ als Konfigurationsoption auswählen. Bei einem Ausfall leitet AWS den Datenverkehr dann automatisch an die fehlerfreie Instance weiter. Für Amazon EC2-Instances, Amazon ECS-Aufgaben oder Amazon EKS-Pods wählen Sie aus, in welchen Availability Zones die Bereitstellung erfolgen soll. Elastic Load Balancing bietet dann die Lösung, um Instances in fehlerhaften Zonen zu erkennen und den Datenverkehr an die fehlerfreien Zonen weiterzuleiten. Elastic Load Balancing kann den Datenverkehr sogar an Komponenten in Ihrem On-Premises-Rechenzentrum weiterleiten.
Für multiregionale Ansätze (zu denen auch On-Premises-Rechenzentren gehören können) bietet Amazon Route 53 eine Möglichkeit, Internetdomänen zu definieren und Routing-Richtlinien zuzuweisen, die Zustandsprüfungen enthalten können. So wird sichergestellt, dass der Datenverkehr an fehlerfreie Regionen weitergeleitet wird. Alternativ stellt AWS Global Accelerator statische IP-Adressen bereit, die als fester Einstiegspunkt in Ihre Anwendung dienen, und sorgt für eine Weiterleitung an Endpunkte in AWS-Regionen Ihrer Wahl. Dabei wird anstelle des Internets das globale AWS-Netzwerk verwendet, das mehr Leistung und Zuverlässigkeit bietet.
Beim Design der Services berücksichtigt AWS immer die Wiederherstellung nach einem Fehler. Wir konzipieren Services mit dem Ziel, die Wiederherstellungszeit nach Ausfällen und die Auswirkungen auf Daten zu minimieren. Unsere Services verwenden primär Datenspeicher, die Anfragen erst akzeptieren, nachdem sie dauerhaft auf mehreren Replikaten in einer Region gespeichert wurden. Zu diesen Services und Ressourcen gehören Amazon Aurora, Amazon Relational Database Service (Amazon RDS) Multi-AZ-DB-Instances, Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service (Amazon SQS) und Amazon Elastic File System (Amazon EFS). 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. Außerdem optimieren wir unsere Funktionalität für Ersetzungsvorgänge und Neustarts, um nach Unterbrechungen eine schnelle Wiederherstellung zu ermöglichen.
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Failover zu fehlerfreien Ressourcen. Stellen Sie sicher, dass fehlerfreie Ressourcen weiterhin Anforderungen erfüllen können, wenn ein Ressourcenausfall auftritt. Stellen Sie bei Standortausfällen (z. B. einer Availability Zone oder AWS-Region) sicher, dass Sie Failover zu fehlerfreien Ressourcen an nicht beeinträchtigten Standorten eingerichtet haben.
+ Wenn in Ihrer Workload AWS-Services wie Amazon S3 oder Amazon DynamoDB verwendet werden, werden diese automatisch in mehreren Availability Zones bereitgestellt. Bei einem Ausfall leitet die AWS-Steuerebene den Datenverkehr automatisch an fehlerfreie Standorte weiter.
+ Für Amazon RDS müssen Sie Multi-AZ als Konfigurationsoption auswählen. Bei einem Ausfall leitet AWS den Datenverkehr dann automatisch an die fehlerfreie Instance weiter.
+ [Hochverfügbarkeit (Multi-AZ) für Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Für Amazon EC2-Instances oder Amazon ECS-Aufgaben wählen Sie aus, in welchen Availability Zones die Bereitstellung erfolgen soll. Elastic Load Balancing bietet dann die Lösung, um Instances in fehlerhaften Zonen zu erkennen und den Datenverkehr an die fehlerfreien Zonen weiterzuleiten. Elastic Load Balancing kann den Datenverkehr sogar an Komponenten in Ihrem On-Premise-Rechenzentrum weiterleiten.
+ Bei multiregionalen Ansätzen (die auch On-Premises-Rechenzentren einschließen können) sollten Sie sicherstellen, dass Daten und Ressourcen an fehlerfreien Standorten weiterhin Anforderungen erfüllen können.
+ Regionsübergreifende Lesereplikate ermöglichen Ihnen beispielsweise die Bereitstellung Ihrer Daten in mehreren AWS-Regionen. Sie müssen die Lesereplikate jedoch hochstufen, um den Datenverkehr zu steuern und weiterzuleiten, wenn der primäre Standort ausfüllt.
+ [Arbeiten mit Lesereplikaten](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ Amazon Route 53 ermöglicht die Definition von Internetdomänen und die Zuweisung von Routing-Richtlinien, die Zustandsprüfungen enthalten können. So wird sichergestellt, dass der Datenverkehr an fehlerfreie Regionen weitergeleitet wird. Alternativ stellt AWS Global Accelerator statische IP-Adressen bereit, die als fester Einstiegspunkt in Ihre Anwendung dienen, und sorgt für eine Weiterleitung an Endpunkte in AWS-Regionen Ihrer Wahl. Dabei wird anstelle des öffentlichen Internets das globale AWS-Netzwerk verwendet, das mehr Leistung und Zuverlässigkeit bietet.
+ [Amazon Route 53: Auswählen einer Routing-Richtlinie](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Was ist AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## Ressourcen
**Relevante Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Automatisierung der Fehlertoleranz unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: Zur Erzielung von Fehlertoleranz geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Verwenden von Auto Healing zum Austausch fehlgeschlagener Instances](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: Auswählen einer Routing-Richtlinie](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Hochverfügbarkeit (Multi-AZ) für Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Arbeiten mit Lesereplikaten](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Strategien für die Platzierung von Aufgaben in Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Creating Kubernetes Auto Scaling Groups for Multiple Availability Zones (Erstellen von Kubernetes-Auto-Scaling-Gruppen für mehrere Availability Zones)](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [Was ist AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**Ähnliche Beispiele:**
+ [Well-Architected Lab: Level 300: Implementieren von Zustandsprüfungen und Verwalten von Abhängigkeiten zur Verbesserung der Zuverlässigkeit](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 Automatisieren der Reparatur auf allen Ebenen
Verwenden Sie bei Erkennung eines Fehlers automatisierte Funktionen, um Maßnahmen zur Behebung durchzuführen.
*Die Möglichkeit zum Neustart* ist ein wichtiges Tool zur Behebung von Fehlern. Wie zuvor für verteilte Systeme beschrieben, besteht eine bewährte Methode darin, Services nach Möglichkeit zustandslos zu machen. Dadurch wird der Verlust von Daten oder Verfügbarkeit beim Neustart verhindert. In der Cloud können (und sollten) Sie die gesamte Ressource (z. B. eine EC2-Instance oder Lambda-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 sich auf Hardware, Software, Kommunikation und den Betrieb beziehen. Statt neue Mechanismen zu entwickeln, um die verschiedenen Fehlertypen zu erfassen, zu identifizieren und zu korrigieren, sollten Sie viele verschiedene Fehlerkategorien derselben Wiederherstellungsstrategie zuordnen. Instances können aufgrund von Hardware- oder Betriebssystemfehlern, aufgrund von unzureichendem Speicher oder aus anderen Gründen ausfallen. Anstatt eine benutzerdefinierte Fehlerbehebung für jede Situation zu entwickeln, sollten Sie alle Szenarios als Instance-Ausfälle behandeln. Beenden Sie die Instance und lassen Sie sie durch AWS Auto Scaling ersetzen. Die ausgefallene Ressource können Sie genauer untersuchen, nachdem sie außer Betrieb genommen wurde.
Ein weiteres Beispiel ist die Möglichkeit, eine Netzwerkanfrage neu zu starten. 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, einen exponentiellen Backoff mit Jitter durchzuführen.
*Die Möglichkeit zum Neustart* ist ein Wiederherstellungsmechanismus, der in Recovery Oriented Computing und Cluster-Architekturen mit hoher Verfügbarkeit verwendet wird.
Mit Amazon EventBridge lassen sich Ereignisse wie CloudWatch-Alarme oder Statusänderungen in anderen AWS-Services überwachen und filtern. Anhand der Ereignisinformationen kann der Service anschließend AWS Lambda, AWS Systems Manager-Automation oder andere Ziele auslösen, um für Ihre Workload eine benutzerdefinierte Korrekturlogik auszuführen.
Amazon EC2 Auto Scaling kann dafür konfiguriert werden, den Zustand der EC2-Instance zu prüfen. Wenn sich die Instance nicht im ausgeführten Status befindet oder der Systemstatus beeinträchtigt ist, betrachtet Amazon EC2 Auto Scaling die Instance als fehlerhaft und startet eine Ersatz-Instance. Wenn Sie AWS OpsWorks verwenden, können Sie Auto Healing für EC2-Instances auf der OpsWorks-Layer-Ebene konfigurieren.
Für umfangreiche Ersetzungen (z. B. beim Verlust einer gesamten Availability Zone) ist statische Stabilität die bevorzugte Methode, um für hohe Verfügbarkeit zu sorgen, statt mehrere neue Ressourcen gleichzeitig abzurufen.
**Gängige Antimuster:**
+ 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.
**Vorteile der Einführung dieser bewährten Methode:** Selbst wenn die Workload jeweils nur an einem Standort bereitgestellt werden kann, verkürzt die automatisierte Reparatur die durchschnittliche Zeit bis zur Wiederherstellung und stellt die Verfügbarkeit der Workload sicher.
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Stellen Sie die Ebenen in einer Workload mithilfe von Auto-Scaling-Gruppen bereit. Die automatische Skalierung kann Selbstreparaturen für zustandslose Anwendungen ausführen sowie Kapazitäten hinzufügen oder entfernen.
+ [Funktionsweise von Skalierungsplänen](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Implementieren Sie eine automatische Wiederherstellung für EC2-Instances, in denen Anwendungen bereitgestellt werden, die nicht an mehreren Standorten bereitgestellt werden können, und die einen Neustart nach Ausfällen tolerieren. 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 Metadaten der Instance und die zugehörigen IP-Adressen werden beibehalten, ebenso wie die Amazon EBS-Volumes und Bindungspunkte für Elastic File Systems oder Dateisysteme für Lustre und Windows.
+ [Automatische Wiederherstellung in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Was ist Amazon FSx für Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Was ist Amazon FSx für Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ Wenn Sie AWS OpsWorks verwenden, können Sie Auto Healing für EC2-Instances auf Layer-Ebene konfigurieren.
+ [AWS OpsWorks: Verwenden von Auto Healing zum Austausch fehlgeschlagener Instances](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ Implementieren Sie die automatisierte Wiederherstellung mit AWS Step Functions und AWS Lambda, wenn keine automatische Skalierung oder Wiederherstellung möglich ist oder die automatische Wiederherstellung fehlschlägt. Wenn Sie keine automatische Skalierung verwenden können und die automatische Wiederherstellung entweder nicht genutzt werden kann oder fehlschlägt, können Sie die Reparatur mithilfe von AWS Step Functions und AWS Lambda automatisieren.
+ [Was ist AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Was ist AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ Mit Amazon EventBridge lassen sich Ereignisse wie CloudWatch-Alarme oder Statusänderungen in anderen AWS-Services überwachen und filtern. Anhand der Ereignisinformationen kann der Service anschließend AWS Lambda (oder andere Ziele) auslösen, um eine benutzerdefinierte Korrekturlogik für die Workload auszuführen.
+ [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Verwenden von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Ressourcen
**Relevante Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Automatisierung der Fehlertoleranz unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: Zur Erzielung von Fehlertoleranz geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Verwenden von Auto Healing zum Austausch fehlgeschlagener Instances](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Automatische Wiederherstellung in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Funktionsweise von Skalierungsplänen](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Verwenden von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Was ist AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Was ist AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Was ist Amazon FSx für Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Was ist Amazon FSx für Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**Relevante Videos:**
+ [Statische Stabilität in AWS: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**Ähnliche Beispiele:**
+ [Well-Architected Lab: Level 300: Implementieren von Zustandsprüfungen und Verwalten von Abhängigkeiten zur Verbesserung der Zuverlässigkeit](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 Nutzen der Datenebene und nicht der Steuerebene während der Wiederherstellung
Die Steuerebene wird für die Konfigurierung von Ressourcen verwendet. Die Datenebene stellt Services bereit. Datenebenen besitzen in der Regel höhere Ziele in Bezug auf das Verfügbarkeitsdesign als Steuerebenen und sind in der Regel weniger komplex. Bei der Implementierung von Wiederherstellungs- oder Eingrenzungsantworten auf Ereignisse, die sich potenziell auf die Resilienz auswirken könnten, kann durch die Verwendung von Operationen auf Steuerebene die Gesamtresilienz Ihrer Architektur reduziert werden. Sie können beispielsweise die Amazon Route 53-Datenebene nutzen, um DNS-Abfragen auf der Basis von Zustandsprüfungen zuverlässig weiterzuleiten. Da bei der Aktualisierung von Route 53-Routing-Richtlinien jedoch die Steuerebene verwendet wird, sollten Sie diese nicht für Wiederherstellungen verwenden.
Die Route 53-Datenebenen beantworten DNS-Abfragen, führen Zustandsprüfungen durch und bewerten diese. Sie werden global für ein [100%-iges Service Level Agreement (SLA) verteilt und entworfen.](https://aws.amazon.com/route53/sla/) Die Route 53-Management-APIs und -Konsolen, in denen Sie Route 53-Ressourcen erstellen, aktualisieren und löschen können, werden auf Steuerebenen ausgeführt. Diese Ebenen sind darauf ausgelegt, die starke Konsistenz und Stabilität zu priorisieren, die Sie bei der Verwaltung von DNS benötigen. Zu diesem Zweck befinden sich die Steuerebenen in einer einzelnen Region, US East (N. Virginia). Beide Systeme sind zwar äußerst zuverlässig, aber die Steuerebenen sind nicht in der SLA enthalten. In seltenen Fällen kann es vorkommen, dass das ausfallsichere Design der Datenebene es ermöglicht, die Verfügbarkeit aufrechtzuerhalten, während die Steuerebene dies nicht tut. Verwenden Sie für die Notfallwiederherstellung und Failover-Mechanismen Datenebenen-Funktionen, um die bestmögliche Zuverlässigkeit bereitzustellen.
Weitere Informationen über Datenebenen, Steuerebenen und wie AWS Services aufbaut, um Hochverfügbarkeitsziele zu erfüllen, finden Sie im Dokument [Statische Stabilität mithilfe von Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) und in der [Amazon Builders’ Library.](https://aws.amazon.com/builders-library/)
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Nutzen Sie die Datenebene statt der Steuerebene, wenn Sie Amazon Route 53 für die Notfallwiederherstellung verwenden. Route 53 Application Recovery Controller hilft Ihnen, anhand von Bereitschaftsprüfungen und Routing-Steuerung Failover-Vorgänge zu verwalten und zu koordinieren. Diese Funktionen überwachen kontinuierlich die Fähigkeit Ihrer Anwendung, nach Fehlern wiederhergestellt zu werden, und ermöglichen Ihnen die Steuerung der Anwendungswiederherstellung über mehrere AWS-Regionen, Availability Zones und On-Premises.
+ [Was ist Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Erstellen von Mechanismen für die Notfallwiederherstellung mit Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Entwickeln hoch resilienter Anwendungen mit Amazon Route 53 Application Recovery Controller, Teil 1: Stack für eine einzelne Region](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Entwickeln hoch resilienter Anwendungen mit Amazon Route 53 Application Recovery Controller, Teil 2: Stack für eine mehrere Regionen](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ Erfahren Sie, welche Operationen auf der Datenebene und welche Operationen auf der Steuerebene ausgeführt werden.
+ [Amazon Builders' Library: Vermeiden von Überlastungen verteilter Systeme durch Übernahme der Steuerung durch den kleineren Service](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Amazon DynamoDB API (Steuerebene und Datenebene)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda-Ausführungen](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (in Steuerebene und Datenebene unterteilt)
+ [AWS Lambda-Ausführungen](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (in Steuerebene und Datenebene unterteilt)
## Ressourcen
**Relevante Dokumente:**
+ [APN-Partner: Partner, die Sie bei der Automatisierung der Fehlertoleranz unterstützen können](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: Zur Erzielung von Fehlertoleranz geeignete Produkte](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders' Library: Vermeiden von Überlastungen verteilter Systeme durch Übernahme der Steuerung durch den kleineren Service](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Amazon DynamoDB API (Steuerebene und Datenebene)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda-Ausführungen](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (in Steuerebene und Datenebene unterteilt)
+ [AWS-Elemental-MediaStore-Datenebene](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Entwickeln hoch resilienter Anwendungen mit Amazon Route 53 Application Recovery Controller, Teil 1: Stack für eine einzelne Region](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Entwickeln hoch resilienter Anwendungen mit Amazon Route 53 Application Recovery Controller, Teil 2: Stack für eine mehrere Regionen](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Erstellen von Mechanismen für die Notfallwiederherstellung mit Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Was ist Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**Ähnliche Beispiele:**
+ [What is Amazon Route 53 Application Recovery Controller? (Was ist Amazon Route 53 Application Recovery Controller?)](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 Verhindern von bimodalem Verhalten mithilfe statischer Stabilität
Bimodales Verhalten bedeutet, dass eine Workload im normalen Modus und im Fehlermodus unterschiedliche Verhaltensweisen zeigt, indem sie z. B. bei Ausfall einer Availability Zone neue Instances startet. Stattdessen sollten Sie Workloads erstellen, die statisch stabil sind und nur in einem Modus betrieben werden. In diesem Fall sollten Sie genügend Instances in jeder Availability Zone bereitstellen, damit die Verarbeitung der Workload auch beim Entfernen einer Availability Zone gewährleistet ist. Anschließend sollten Sie die beeinträchtigten Instances mithilfe von Elastic Load Balancing oder Amazon Route 53-Zustandsprüfungen entlasten.
Statische Stabilität für die Bereitstellung von Rechenleistung (z. B. EC2-Instances oder -Container) führt zu höchster Zuverlässigkeit. Dabei müssen Sie das Kosten-Nutzen-Verhältnis abwägen. Es ist kostengünstiger, weniger Rechenkapazität bereitzustellen und sich bei einem Ausfall auf das Starten neuer Instances zu verlassen. Bei großen Ausfällen (z. B. einem Ausfall einer Availability Zone) ist dieser Ansatz jedoch weniger effektiv, da er sich darauf stützt, auf bereits eingetretene Beeinträchtigungen zu reagieren, statt auf diese Beeinträchtigungen vorbereitet zu sein, bevor sie auftreten. Ihre Lösung sollte die Zuverlässigkeits- und Kostenanforderungen für Ihre Workload berücksichtigen. Wenn Sie eine größere Anzahl von Availability Zones verwenden, verringert sich die Menge der zusätzlichen Rechenleistung, die Sie für die statische Stabilität benötigen.
![\[Diagramm: Statische Stabilität von EC2-Instances in Availability Zones\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/static-stability.png)
Nachdem der Datenverkehr verlagert wurde, können Sie AWS Auto Scaling verwenden, um Instances in der ausgefallenen Zone asynchron zu ersetzen und sie in den fehlerfreien Zonen zu starten.
Ein weiteres Beispiel für bimodales Verhalten ist eine Netzwerk-Zeitüberschreitung, die dazu führen kann, dass ein System versucht, den Konfigurationsstatus des gesamten Systems zu aktualisieren. Dies kann zu einer unerwarteten Belastung einer anderen Komponente führen, die daraufhin ausfallen könnte und möglicherweise weitere unerwartete Konsequenzen nach sich zieht. Diese negative Feedback-Schleife wirkt sich auf die Verfügbarkeit Ihrer Workload aus. Deshalb sollten Sie Systeme erstellen, die statisch stabil sind und nur in einem Modus betrieben werden. Ein statisch stabiles Design besteht aus konstanter Arbeit und einer regelmäßigen Aktualisierung des Konfigurationsstatus. Wenn ein Aufruf fehlschlägt, verwendet die Workload den zuvor zwischengespeicherten Wert und löst einen Alarm aus.
Ein weiteres Beispiel für bimodales Verhalten: Sie lassen zu, dass Clients im Fehlerfall den Workload-Cache umgehen. Dies scheint eine Lösung zu sein, die Clientanforderungen erfüllt, sollte aber nicht zugelassen werden, da sie die Belastung Ihrer Workload erheblich ändert und wahrscheinlich zu Fehlern führt.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Nutzen Sie statische Stabilität, um bimodales Verhalten zu verhindern. Bimodales Verhalten bedeutet, dass eine Workload im normalen Modus und im Fehlermodus unterschiedliche Verhaltensweisen zeigt, indem sie z. B. bei Ausfall einer Availability Zone neue Instances startet.
+ [Minimierung der Abhängigkeiten bei der Planung der Notfallwiederherstellung](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Die Amazon Builders' Library: Statische Stabilität durch Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Statische Stabilität in AWS: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ Sie sollten stattdessen Systeme erstellen, die statisch stabil sind und nur in einem einzigen Modus ausgeführt werden. In diesem Fall sollten Sie genügend Instances in jeder Zone bereitstellen, damit die Verarbeitung der Workload auch beim Entfernen einer AZ gewährleistet ist, und verwenden Sie anschließend Elastic Load Balancing oder Amazon Route 53-Zustandsprüfungen, um die Last von den beeinträchtigten Instances wegzuverlagern.
+ Ein weiteres Beispiel für bimodales Verhalten: Sie lassen zu, dass Clients im Fehlerfall den Workload-Cache umgehen. Dies mag zwar wie eine praktikable Lösung zur Erfüllung der Clientanforderungen aussehen, sollte aber vermieden werden, da sie die Ansprüche an die Workload erheblich verändert und wahrscheinlich zu Fehlern führt.
## Ressourcen
**Relevante Dokumente:**
+ [Minimierung der Abhängigkeiten bei der Planung der Notfallwiederherstellung](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Die Amazon Builders' Library: Statische Stabilität durch Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**Relevante Videos:**
+ [Statische Stabilität in AWS: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Senden von Benachrichtigungen, wenn sich Ereignisse auf die Verfügbarkeit auswirken
Benachrichtigungen werden nach Erkennung wichtiger Ereignisse gesendet, auch wenn das durch das Ereignis verursachte Problem automatisch behoben wurde.
Auto Healing sorgt dafür, dass Ihre Workload zuverlässig ist. Allerdings können dadurch auch zugrunde liegende Probleme verschleiert werden, die behoben werden müssen. Implementieren Sie geeignete Überwachungsfunktionen und Ereignisse, damit Sie Problemmuster erkennen können, einschließlich solcher, die durch Auto Healing behoben werden. Auf diese Weise können Sie die Fehlerursachen beheben. Amazon CloudWatch-Alarme können basierend auf auftretenden Fehlern ausgelöst werden. Sie können auch basierend auf Aktionen der automatischen Fehlerbehebung ausgelöst werden. CloudWatch-Alarme können so konfiguriert werden, dass E-Mails gesendet oder Vorfälle mithilfe der Amazon SNS-Integration in Drittanbietersystemen zur Nachverfolgung von Vorfällen protokolliert werden.
**Gängige Antimuster:**
+ Senden von Alarmen, auf die niemand reagiert.
+ Durchführen automatischer Reparaturen ohne die Benachrichtigung, dass eine Reparatur erforderlich war.
**Vorteile der Einführung dieser bewährten Methode:** Benachrichtigungen zu Wiederherstellungen sorgen dafür, dass Sie selten auftretende Probleme nicht ignorieren.
**Risikostufe, falls diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Alarme für wichtige geschäftliche Leistungskennzahlen, wenn diese eine niedrige Schwelle überschreiten. Wenn Sie eine niedrige Alarmschwelle für Ihre geschäftlichen KPIs ansetzen, können Sie besser erkennen, wann Ihre Workload nicht verfügbar ist oder nicht funktioniert.
+ [Erstellen eines CloudWatch-Alarms auf der Basis eines statischen Schwellenwerts](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ Alarme für Ereignisse, die eine automatisierte Reparatur auslösen. Sie können eine SNS-API direkt aufrufen, um bei von Ihnen erstellten Automatisierungen Benachrichtigungen zu senden.
+ [Was ist Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## Ressourcen
**Relevante Dokumente:**
+ [Erstellen eines CloudWatch-Alarms auf der Basis eines statischen Schwellenwerts](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Was ist Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)