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-BP04 Verlassen Sie sich bei der Wiederherstellung auf die Datenebene und nicht auf die Steuerebene

Kontrollebenen stellen die administrativen APIs Funktionen bereit, die zum Erstellen, Lesen und Beschreiben, Aktualisieren, Löschen und Auflisten (CRUDL) von Ressourcen verwendet werden, während Datenebenen den day-to-day Dienstverkehr regeln. Konzentrieren Sie sich bei der Implementierung von Wiederherstellungs- oder Abhilfemaßnahmen für Ereignisse, die sich möglicherweise auf die Ausfallsicherheit auswirken, auf eine minimale Anzahl von Operationen auf der Steuerebene, um den Service wiederherzustellen, zu skalieren, zu reparieren oder einen Failover durchzuführen. Aktionen auf der Datenebene sollten während dieser Beeinträchtigungen Vorrang vor allen anderen Aktivitäten haben.

Die folgenden Aktionen gehören beispielsweise alle zur Steuerebene: Starten einer neuen Datenverarbeitungs-Instance, Erstellen von Block-Speicher und Beschreiben von Warteschlangen-Services. Wenn Sie Datenverarbeitungs-Instances starten, muss die Steuerebene mehrere Aufgaben erfüllen, z. B. einen physischen Host mit Kapazität finden, Netzwerkschnittstellen zuweisen, lokale Block-Speicher-Volumes vorbereiten, Anmeldeinformationen generieren und Sicherheitsregeln hinzufügen. Steuerebenen neigen zu einer komplizierten Orchestrierung.

Gewünschtes Ergebnis: Wenn bei einer Ressource eine Störung auftritt, ist das System in der Lage, diese automatisch oder manuell zu beheben, indem es den Datenverkehr von gestörten auf intakte Ressourcen umleitet.

Typische Anti-Muster:

Vorteile der Nutzung dieser bewährten Methode: Eine höhere Erfolgsquote bei der automatisierten Behebung kann Ihre mittlere Zeit bis zur Wiederherstellung verkürzen und die Verfügbarkeit des Workloads verbessern.

Risikostufe, wenn diese bewährte Methode nicht eingeführt wird: Mittel: Bei bestimmten Arten von Service-Einschränkungen sind Steuerebenen betroffen. Abhängigkeiten von der umfassenden Nutzung der Kontrollebene zur Behebung können die Wiederherstellungszeit (RTO) und die durchschnittliche Zeit bis zur Wiederherstellung (MTTR) verlängern.

Implementierungsleitfaden

Um die Aktionen auf der Datenebene zu begrenzen, bewerten Sie für jeden Service, welche Aktionen zur Wiederherstellung des Services erforderlich sind.

Nutzen Sie Amazon Application Recovery Controller, um den DNS Datenverkehr zu verlagern. Diese Funktionen überwachen kontinuierlich die Fähigkeit Ihrer Anwendung, sich nach Ausfällen zu erholen, und ermöglichen es Ihnen AWS-Regionen, Ihre Anwendungswiederherstellung in mehreren Availability Zones und vor Ort zu kontrollieren.

Route 53-Routingrichtlinien verwenden die Steuerebene. Verlassen Sie sich also bei der Wiederherstellung nicht auf diese Ebene. Die Route 53-Datenebenen beantworten DNS Anfragen und führen Integritätsprüfungen durch und werten diese aus. Sie werden weltweit vertrieben und sind für ein Service Level Agreement (SLA) mit 100-prozentiger Verfügbarkeit konzipiert.

Die Route 53-Verwaltung APIs und die Konsolen, in denen Sie Route 53-Ressourcen erstellen, aktualisieren und löschen, werden auf Steuerungsebenen ausgeführt, die darauf ausgelegt sind, die hohe Konsistenz und Beständigkeit zu gewährleisten, die Sie bei der Verwaltung DNS benötigen. Zu diesem Zweck befinden sich die Steuerebenen in einer einzelnen Region, USA Ost (Nord-Virginia). Beide Systeme sind zwar auf hohe Zuverlässigkeit ausgelegt, die Steuerungsebenen sind jedoch 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.

Gestalten Sie Ihre Recheninfrastruktur so, dass sie statisch stabil ist, um zu vermeiden, dass die Steuerungsebene während eines Vorfalls verwendet wird. Wenn Sie beispielsweise EC2 Amazon-Instances verwenden, vermeiden Sie es, neue Instances manuell bereitzustellen oder Auto Scaling Groups anzuweisen, als Reaktion darauf Instances hinzuzufügen. Für ein Höchstmaß an Ausfallsicherheit stellen Sie ausreichende Kapazitäten in dem für den Failover verwendeten Cluster bereit. Wenn dieser Kapazitätsschwellenwert begrenzt werden muss, richten Sie Drosselungen für das gesamte end-to-end System ein, um den Gesamtverkehr, der die begrenzten Ressourcen erreicht, sicher zu begrenzen.

Für Dienste wie Amazon DynamoDB, Amazon API Gateway, Load Balancer und AWS Lambda Serverless nutzt die Nutzung dieser Dienste die Datenebene. Das Erstellen neuer Funktionen, Load Balancer, API Gateways oder DynamoDB-Tabellen ist jedoch eine Aktion auf der Kontrollebene und sollte vor der Degradation abgeschlossen werden, um ein Ereignis vorzubereiten und Failover-Aktionen zu proben. Für Amazon RDS ermöglichen Aktionen auf Datenebene den Zugriff auf Daten.

Weitere Informationen zu Datenebenen, Kontrollebenen und dazu, wie Services AWS entwickelt werden, um Hochverfügbarkeitsziele zu erreichen, finden Sie unter Statische Stabilität mithilfe von Availability Zones.

Erfahren Sie, welche Operationen auf der Datenebene und welche Operationen auf der Steuerebene ausgeführt werden.

Implementierungsschritte

Bewerten Sie für jede Workload, die nach einem Störfall wiederhergestellt werden muss, das Failover-Runbook, das Hochverfügbarkeitsdesign, das Auto Healing Design oder den Plan zur Wiederherstellung von HA-Ressourcen. Identifizieren Sie jede Aktion, die als Aktion auf der Steuerebene in Frage kommt.

Ziehen Sie in Erwägung, eine Aktion auf der Steuerebene in eine Aktion auf der Datenebene umzuwandeln:

Ziehen Sie alternative Ansätze in Betracht, bei denen Aktionen auf der Datenebene dieselbe Maßnahme bewirken können.

Ziehen Sie einige Services in einer sekundären Region in Betracht, wenn der Service geschäftskritisch ist, um mehr Aktionen auf der Steuerebene und Datenebene in einer nicht betroffenen Region zu ermöglichen.

Ressourcen

Zugehörige bewährte Methoden:

Zugehörige Dokumente:

Zugehörige Videos:

Zugehörige Beispiele:

Zugehörige Tools: