Bewährte Methoden für die Routing-Steuerung in ARC

Halten Sie in einem Notfallwiederherstellungsszenario (DR) die Systemabhängigkeiten auf ein Minimum, indem Sie einen einfachen Ansatz für den Zugriff auf AWS und die Ausführung von Wiederherstellungsaufgaben verwenden. Erstellen Sie IAMlanglebige Anmeldeinformationen speziell für DR-Aufgaben und bewahren Sie die Anmeldeinformationen sicher in einem lokalen physischen Safe oder einem virtuellen Tresor auf, damit Sie bei Bedarf darauf zugreifen können. Mit IAM können Sie Sicherheitsanmeldedaten wie Zugriffsschlüssel und Berechtigungen für den Zugriff auf Ressourcen zentral verwalten. AWS Für Aufgaben, die nicht zur Notfallwiederherstellung gehören, empfehlen wir, weiterhin Verbundzugriff zu verwenden und AWS Dienste wie AWS Single Sign-On zu nutzen.

Um Failover-Aufgaben auf der ARC Datenebene des Wiederherstellungsclusters auszuführenAPI, können Sie Ihrem Benutzer eine ARC IAM Richtlinie zuordnen. Weitere Informationen hierzu finden Sie unter Beispiele für identitätsbasierte Richtlinien in .

Für DNS Datensätze, die Sie möglicherweise im Rahmen Ihres Failover-Mechanismus ändern müssen, insbesondere für Datensätze, die einer Integritätsprüfung unterzogen wurden, ist es angemessen, niedrigere TTL Werte zu verwenden. Die Einstellung TTL von 60 oder 120 Sekunden ist eine gängige Wahl für dieses Szenario.

Die Einstellung DNS TTL (Time to Live) teilt DNS Resolvern mit, wie lange ein Datensatz zwischengespeichert werden muss, bevor ein neuer angefordert wird. Wenn Sie sich für eine entscheidenTTL, gehen Sie einen Kompromiss zwischen Latenz und Zuverlässigkeit sowie der Reaktionsfähigkeit auf Änderungen ein. Bei einem kürzeren TTL Datensatz bemerken DNS Resolver Aktualisierungen des Datensatzes schneller, da der TTL angibt, dass sie häufiger Abfragen durchführen müssen.

Weitere Informationen finden Sie unter Auswählen von TTL Werten für DNS Datensätze in Best Practices für Amazon Route DNS 53.

Wenn Sie Routing-Steuerelemente verwenden, um von einem AWS-Region zum anderen zu wechseln, ist der Mechanismus, den Amazon Application Recovery Controller (ARC) verwendet, um Ihren Anwendungsdatenverkehr zu verlagern, ein DNS Update. Dieses Update bewirkt, 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. Weitere Informationen finden Sie unter Dauer der Keepalive-Dauer des HTTP Clients im Application Load Balancer Balancer-Benutzerhandbuch.

Standardmäßig legen Application Load Balancer den Wert für die Keepalive-Dauer des HTTP Clients auf 3600 Sekunden oder 1 Stunde fest. Wir empfehlen Ihnen, den Wert zu senken, um Ihrem Ziel für die Wiederherstellungszeit für Ihre Anwendung zu entsprechen, z. B. 300 Sekunden. Wenn Sie die Dauer der HTTP Client-Keepalive-Dauer 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.

Wir empfehlen, dass Sie eine lokale Kopie Ihrer ARC regionalen Cluster-Endpunkte in Form von Lesezeichen oder im Automatisierungscode speichern, den Sie verwenden, um Ihre Endpunkte erneut zu testen. Während eines Fehlereignisses können Sie möglicherweise nicht auf einige API Operationen zugreifen, einschließlich ARC API Operationen, die nicht auf dem extrem zuverlässigen Datenebenen-Cluster gehostet werden. Mithilfe des DescribeClusterAPIVorgangs können Sie die Endpunkte für Ihre ARC Cluster auflisten.

Wir empfehlen, dass Sie bei einem Failover die Status der Routing-Steuerung mithilfe eines zufälligen Endpunkts von Ihren fünf regionalen Cluster-Endpunkten aktualisieren (und abrufen). Wenn dieser Endpunkt ausfällt, versuchen Sie es erneut mit jedem Ihrer anderen regionalen Endpunkte. Informationen zur Verwendung von Codebeispielen mit dem AWS SDK, einschließlich Beispielen zum Testen von Cluster-Endpunkten, finden Sie unter. Codebeispiele für Application Recovery Controller mit AWS SDKs

Mithilfe der ARC Datenebene API können Sie Ihre Routingsteuerungen und den Status des ListRoutingControlsVorgangs anzeigen und den Status der Routingsteuerung aktualisieren, um den Datenverkehr umzuleiten, damit der Failover mit dem UpdateRoutingControlStateVorgang abgeschlossen werden kann. Sie können den AWS CLI (wie in diesen Beispielen) oder den Code verwenden, den Sie mit einem der AWS SDKs geschrieben haben. ARCbietet extreme Zuverlässigkeit, da der Datenverkehr API in der Datenebene ausfällt. Wir empfehlen, den zu verwenden, API anstatt den Status der Routing-Steuerung in zu ändern AWS Management Console.

Stellen Sie eine Connect zu einem Ihrer regionalen Cluster-Endpunkte herARC, um die Datenebene API zu verwenden. Wenn der Endpunkt nicht verfügbar ist, versuchen Sie, eine Verbindung zu einem anderen Cluster-Endpunkt herzustellen.

Wenn eine Sicherheitsregel eine Statusaktualisierung der Routingsteuerung blockiert, können Sie sie umgehen, um die Aktualisierung durchzuführen und den Datenverkehr zu überweisen. Weitere Informationen finden Sie unter Sicherheitsregeln außer Kraft setzen, um den Verkehr umzuleiten.

Testen Sie das Failover regelmäßig mit ARC Routing-Steuerung, um ein Failover von Ihrem primären Anwendungsstapel auf einen sekundären Anwendungsstapel umzuschalten. Es ist wichtig, sicherzustellen, dass die ARC Strukturen, die Sie hinzugefügt haben, auf die richtigen Ressourcen in Ihrem Stack abgestimmt sind und dass alles so funktioniert, wie Sie es erwarten. Sie sollten dies testen, nachdem Sie es ARC für Ihre Umgebung eingerichtet haben, und die Tests regelmäßig fortsetzen, damit Ihre Failover-Umgebung vorbereitet ist, bevor es zu einer Ausfallsituation kommt, in der Ihr sekundäres System schnell betriebsbereit sein muss, um Ausfallzeiten für Ihre Benutzer zu vermeiden.