Bewährte Methoden bei der Konfiguration von Zonal Autoshift - Amazon Application Recovery Controller (ARC)

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.

Bewährte Methoden bei der Konfiguration von Zonal Autoshift

Beachten Sie die folgenden bewährten Methoden und Überlegungen, wenn Sie Zonal Autoshift in Amazon Application Recovery Controller () ARC aktivieren.

Zonal Autoshift umfasst zwei Arten von Verkehrsverschiebungen: automatische Verschiebungen und praxisorientierte Zonenverschiebungen.

  • Autoshift AWS trägt dazu bei, die Zeit bis zur Wiederherstellung zu verkürzen, indem der Datenverkehr von Anwendungsressourcen bei Ereignissen in Ihrem Namen aus einer Availability Zone verlagert wird.

  • ARCStartet bei Übungsläufen eine Zonenverschiebung in Ihrem Namen. Durch die Zonenverschiebung wird der Verkehr in wöchentlichem Rhythmus von einer Availability Zone für eine Ressource weg und wieder zurück verlagert. Mithilfe von Übungsläufen können Sie sicherstellen, dass Sie genügend Kapazität für Availability Zones in einer Region aufgebaut haben, sodass Ihre Anwendung den Verlust einer Availability Zone verkraften kann.

Es gibt mehrere bewährte Methoden und Überlegungen, die Sie bei Autoshifts und Übungsläufen beachten sollten. Lesen Sie sich die folgenden Themen durch, bevor Sie zonales Autoshift aktivieren oder Übungsläufe für eine Ressource konfigurieren.

Topics

Beschränken Sie die Zeit, in der Kunden mit Ihren Endpunkten verbunden bleiben

Wenn Amazon Application Recovery Controller (ARC) den Datenverkehr von einer Beeinträchtigung wegleitet, z. B. mithilfe von Zonal Shift oder Zonal Autoshift, ist der Mechanismus, ARC mit dem Ihr Anwendungsdatenverkehr verlagert wird, ein Update. DNS Ein DNS Update führt dazu, dass alle neuen Verbindungen vom beeinträchtigten Standort weggeleitet werden. Clients mit bereits bestehenden offenen Verbindungen können jedoch weiterhin Anfragen an den beeinträchtigten Standort stellen, bis die Clients wieder eine Verbindung herstellen. Um eine schnelle Wiederherstellung zu gewährleisten, empfehlen wir, die Dauer zu begrenzen, für die Clients mit Ihren Endpunkten verbunden bleiben.

Wenn Sie einen Application Load Balancer verwenden, können Sie mit dieser keepalive Option konfigurieren, wie lange Verbindungen bestehen bleiben. Wir empfehlen Ihnen, den keepalive Wert so zu senken, dass er Ihrem Ziel für die Wiederherstellungszeit Ihrer Anwendung entspricht, z. B. 300 Sekunden. Wenn Sie eine keepalive Zeit wählen, sollten Sie berücksichtigen, dass dieser Wert einen Kompromiss darstellt zwischen einer häufigeren Wiederverbindung im Allgemeinen, was sich auf die Latenz auswirken kann, und einer schnelleren Verlagerung aller Clients aus einer beeinträchtigten AZ oder Region.

Weitere Informationen zur Einstellung der keepalive Option für Application Load Balancer finden Sie im Application Load Balancer Balancer-Benutzerhandbuch unter der Keepalive-Dauer des HTTP Clients.

Skalieren Sie Ihre Ressourcenkapazität vorab und testen Sie die Verlagerung des Datenverkehrs

Bei der AWS Verlagerung des Datenverkehrs von einer Availability Zone für eine Zonenschicht oder eine automatische Verschiebung ist es wichtig, dass die verbleibenden Availability Zones die erhöhten Anforderungsraten für Ihre Ressource bewältigen können. Dieses Muster wird als statische Stabilität bezeichnet. Weitere Informationen finden Sie im Whitepaper Statische Stabilität mithilfe von Availability Zones in der Amazon Builder's Library.

Wenn Ihre Anwendung beispielsweise 30 Instances benötigt, um ihre Clients zu bedienen, sollten Sie 15 Instances in drei Availability Zones bereitstellen, also insgesamt 45 Instances. Auf diese Weise AWS können Sie bei der AWS Verlagerung des Datenverkehrs von einer Availability Zone weg — mit Autoshift oder während eines Übungslaufs — die Clients Ihrer Anwendung weiterhin mit den verbleibenden insgesamt 30 Instances in zwei Availability Zones bedienen.

Die zonale Autoshift-Funktion ARC hilft Ihnen dabei, sich schnell nach AWS Ereignissen in einer Availability Zone zu erholen, wenn Sie eine Anwendung mit Ressourcen haben, die so skaliert sind, dass sie bei Verlust einer Availability Zone normal funktionieren. Bevor Sie Zonal Autoshift für eine Ressource aktivieren, skalieren Sie Ihre Ressourcenkapazität in allen konfigurierten Availability Zones in einer. AWS-Region Starten Sie dann Zonenverschiebungen für die Ressource, um zu testen, ob Ihre Anwendung weiterhin normal läuft, wenn der Verkehr von einer Availability Zone weg verlagert wird.

Nachdem Sie mit Zonal Shifts getestet haben, aktivieren Sie Zonal Autoshift und konfigurieren Sie Übungsläufe für Anwendungsressourcen. Regelmäßige Testläufe mit zonalem Autoshift helfen Ihnen, kontinuierlich sicherzustellen, dass Ihre Kapazität weiterhin angemessen skaliert wird. Bei ausreichender Kapazität in allen Availability Zones kann Ihre Anwendung während einer automatischen Verschiebung weiterhin ohne Unterbrechung Clients bedienen.

Weitere Informationen zum Starten einer Zonenverschiebung für eine Ressource finden Sie unter. Zonale Verschiebung in ARC

Seien Sie sich der Ressourcentypen und Einschränkungen bewusst

Zonal Autoshift unterstützt die Verlagerung des Datenverkehrs aus einer Availability Zone für alle Ressourcen, die von Zonal Shift unterstützt werden. Im Allgemeinen werden Network Load Balancer und Application Load Balancer mit deaktiviertem zonenübergreifendem Load Balancing unterstützt. In einigen spezifischen Ressourcenszenarien verlagert Zonal Autoshift den Verkehr nicht von einer Availability Zone in eine Autoshift.

Wenn die Load Balancer-Zielgruppen in den Availability Zones beispielsweise keine Instances haben oder wenn alle Instances fehlerhaft sind, befindet sich der Load Balancer in einem Fail-Open-Status. Wenn in diesem Szenario ein Autoshift für einen Load Balancer AWS gestartet wird, ändert ein Autoshift nicht, welche Availability Zones der Load Balancer verwendet, da sich der Load Balancer bereits in einem Fail-Open-Status befindet. Dieses Verhalten wird erwartet. Autoshift kann nicht dazu führen, dass eine Availability Zone fehlerhaft ist, und den Verkehr in die anderen Availability Zones verlagern, AWS-Region wenn alle Availability Zones ausfallen (fehlerhaft).

Ein zweites Szenario ist, wenn ein Autoshift für einen Application Load Balancer AWS gestartet wird, der ein Endpunkt für einen Accelerator ist. AWS Global Accelerator Wie bei Zonal Shift wird Autoshift für Application Load Balancers, die Endpunkte von Acceleratoren in Global Accelerator sind, nicht unterstützt.

Einzelheiten zu den unterstützten Ressourcen, einschließlich aller Anforderungen und Ausnahmen, die Sie beachten sollten, finden Sie unter. Ressourcen und Szenarien, die für Zonal Shift und Zonal Autoshift unterstützt werden

Geben Sie Alarme für Übungsläufe an

Sie konfigurieren mindestens einen Alarm — den Ergebnisalarm — für Übungsläufe mit zonalem Autoshift. Optional können Sie auch einen zweiten Alarm — den Blockierungsalarm — konfigurieren.

Wenn Sie die CloudWatch Alarme berücksichtigen, die Sie für Übungsläufe für Ihre Ressource konfigurieren, sollten Sie Folgendes berücksichtigen:

  • Für den Ergebnisalarm, der erforderlich ist, empfehlen wir, einen CloudWatch Alarm so zu konfigurieren, dass er in einen ALARM Zustand übergeht, in dem die Metriken für die Ressource oder Ihre Anwendung darauf hinweisen, dass die Verlagerung des Datenverkehrs von der Availability Zone weg die Leistung beeinträchtigt. Sie können beispielsweise einen Schwellenwert für die Anforderungsraten für Ihre Ressource festlegen und dann einen Alarm so konfigurieren, dass er in einen ALARM Status wechselt, wenn der Schwellenwert überschritten wird. Sie sind dafür verantwortlich, einen geeigneten Alarm zu konfigurieren, der AWS dazu führt, dass der Übungslauf beendet und ein FAILED Ergebnis zurückgegeben wird.

  • Wir empfehlen Ihnen, das AWS Well Architected Framework zu befolgen, das Ihnen empfiehlt, wichtige Leistungsindikatoren (KPIs) als CloudWatch Alarme zu implementieren. Wenn Sie dies tun, können Sie diese Alarme verwenden, um einen zusammengesetzten Alarm zu erstellen, der als Sicherheitsauslöser verwendet werden kann, um zu verhindern, dass Übungsläufe gestartet werden, falls diese dazu führen könnten, dass Ihre Anwendung einen KPI Fehler verpasst. Wenn sich der Alarm nicht mehr in einem bestimmten ALARM Zustand befindet, werden die Übungsläufe ARC gestartet, wenn das nächste Mal ein Übungslauf für die Ressource geplant ist.

  • Wenn Sie den Alarm zum Sperren von Übungsläufen konfigurieren, können Sie sich dafür entscheiden, eine bestimmte Metrik nachzuverfolgen, anhand derer Sie angeben, dass Sie nicht möchten, dass ein Übungslauf gestartet wird.

  • Zum Üben von Alarmen geben Sie den Amazon-Ressourcennamen (ARN) für jeden Alarm an, den Sie zuerst in Amazon konfigurieren müssen CloudWatch. Bei den von Ihnen angegebenen CloudWatch Alarmen kann es sich um zusammengesetzte Alarme handeln, sodass Sie mehrere Messwerte und Prüfungen für Ihre Anwendung und Ressource einbeziehen können, die den Alarm in einen bestimmten ALARM Status versetzen können. Weitere Informationen finden Sie unter Kombinieren von Alarmen im CloudWatch Amazon-Benutzerhandbuch.

  • Stellen Sie sicher, dass sich die CloudWatch Alarme, die Sie für Übungsläufe angeben, in derselben Region befinden wie die Ressource, für die Sie einen Übungslauf konfigurieren.

Bewerten Sie die Ergebnisse von Übungsläufen

ARCmeldet für jeden Übungslauf ein Ergebnis. Bewerten Sie nach einem Übungslauf das Ergebnis und entscheiden Sie, ob Sie Maßnahmen ergreifen müssen. Beispielsweise müssen Sie möglicherweise die Kapazität skalieren oder die Konfiguration für einen Alarm anpassen.

Im Folgenden sind die möglichen Ergebnisse des Übungslaufs aufgeführt:

  • SUCCEEDED: Der Ergebnisalarm hat während des Übungslaufs keinen ALARM Status erreicht, und der Übungslauf hat den gesamten 30-minütigen Testzeitraum abgeschlossen.

  • FAILED: Der Ergebnisalarm ist während des Übungslaufs in einen ALARM Zustand übergegangen.

  • INTERRUPTED: Der Übungslauf wurde aus einem Grund beendet, der nicht darauf zurückzuführen war, dass der Ergebnisalarm in einen ALARM Status übergegangen ist. Ein Übungslauf kann aus einer Vielzahl von Gründen unterbrochen werden, unter anderem aus den folgenden Gründen:

    • Der Übungslauf wurde beendet, weil in der Region eine automatische Umschaltung AWS gestartet wurde AWS-Region oder weil in der Region ein Alarm aufgetreten ist.

    • Der Übungslauf wurde beendet, weil die Konfiguration des Übungslaufs für die Ressource gelöscht wurde.

    • Der Übungslauf wurde beendet, weil eine vom Kunden initiierte Zonenverschiebung für die Ressource in der Availability Zone gestartet wurde, von der der Übungslauf mit der Zonenschicht den Verkehr wegverlagerte.

    • Der Übungslauf wurde beendet, weil auf einen CloudWatch Alarm, der für die Konfiguration des Übungslaufs angegeben wurde, nicht mehr zugegriffen werden kann.

    • Der Übungslauf wurde beendet, weil der für den Übungslauf angegebene Blockierungsalarm in einen ALARM Status übergegangen ist.

    • Der Übungslauf wurde aus einem unbekannten Grund beendet.

  • PENDING: Der Übungslauf ist aktiv (läuft). Es gibt noch kein Ergebnis für eine Rückkehr.