Bewährte Methoden für die Routingsteuerung in ARC

Halten Sie in einem Disaster Recovery-Szenario (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 langlebige IAM-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, bei denen es sich nicht um DR-Aufgaben handelt, empfehlen wir, weiterhin Verbundzugriff zu verwenden und AWS Dienste wie AWS Single Sign-On zu nutzen.

Um Failover-Aufgaben in ARC mit der Datenebene-API des Wiederherstellungsclusters auszuführen, können Sie Ihrem Benutzer eine ARC-IAM-Richtlinie hinzufügen. Weitere Informationen hierzu finden Sie unter Beispiele für identitätsbasierte Richtlinien in Amazon Application Recovery Controller (ARC).

Für DNS-Einträge, 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 die Verwendung niedrigerer TTL-Werte angemessen. Das Festlegen einer TTL von 60 oder 120 Sekunden ist eine übliche Wahl für dieses Szenario.

Die DNS-TTL-Einstellung (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 TTL entscheiden, gehen Sie einen Kompromiss zwischen Latenz und Zuverlässigkeit sowie der Reaktionsfähigkeit auf Änderungen ein. Bei einer kürzeren TTL für einen Datensatz bemerken DNS-Resolver Aktualisierungen des Eintrags schneller, da die TTL angibt, dass sie häufiger Abfragen durchführen müssen.

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

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 einer HTTP-Client-Keepalive-Dauer wählen, sollten Sie berücksichtigen, dass dieser Wert einen Kompromiss darstellt zwischen einer häufigeren Wiederherstellung der Verbindung 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 regionalen ARC-Cluster-Endpunkte in Form von Lesezeichen oder als Automatisierungscode speichern, den Sie verwenden, um Ihre Endpunkte erneut zu testen. Während eines Fehlers 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 der DescribeClusterAPI-Operation können Sie die Endpunkte für Ihre ARC-Cluster auflisten.

Die Routing-Kontrollen bieten fünf regionale Endpunkte, um selbst bei Ausfällen eine hohe Verfügbarkeit zu gewährleisten. Um ihre volle Resilienz zu erreichen, ist es wichtig, über eine Wiederholungslogik zu verfügen, die bei Bedarf alle fünf Endpunkte verwenden kann. 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 Routing-Steuerelemente und den Status des ListRoutingControlsVorgangs anzeigen und den Status der Routing-Steuerung 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. ARC bietet extreme Zuverlässigkeit mit der API in der Datenebene für den Failover-Verkehr. Wir empfehlen, die API zu verwenden, anstatt den Status der Routing-Steuerung in der zu ändern AWS Management Console.

Stellen Sie eine Connect zu einem Ihrer regionalen Cluster-Endpunkte her, damit ARC die Datenebene-API verwenden kann. 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 zu einem sekundären Anwendungsstapel durchzuführen. 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 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.