Bewährte Methoden für die Routingsteuerung in Route 53 ARC - Amazon Route 53 Application Recovery-Controller

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 für die Routingsteuerung in Route 53 ARC

Wir empfehlen die folgenden bewährten Methoden für die Wiederherstellung und Failover-Vorbereitung für die Routing-Steuerung in Amazon Route 53 Application Recovery Controller.

Topics

Bewahren Sie speziell entwickelte, langlebige AWS Anmeldeinformationen sicher und jederzeit zugänglich auf

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 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 in Route 53 ARC mit der Datenebene des Wiederherstellungsclusters auszuführenAPI, können Sie Ihrem Benutzer eine Route 53 ARC IAM 53-Richtlinie zuordnen. Weitere Informationen hierzu finden Sie unter Beispiele für identitätsbasierte Richtlinien in Amazon Route 53 Application Recovery Controller.

Wählen Sie niedrigere TTL Werte für DNS Datensätze, die am Failover beteiligt sind

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.

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

Wenn Sie Routing-Steuerelemente verwenden, um von einem AWS-Region zum anderen zu wechseln, ist der Mechanismus, den Amazon Route 53 Application Recovery Controller verwendet, um Ihren Anwendungsdatenverkehr zu verschieben, 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.

Fügen Sie Ihren fünf regionalen Cluster-Endpunkten und der Routing-Steuerung ein Lesezeichen hinzu oder schreiben Sie sie fest ARNs

Wir empfehlen, dass Sie eine lokale Kopie Ihrer ARC regionalen Route 53 53-Cluster-Endpunkte in 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 Route 53 ARC API 53-Operationen, die nicht auf dem extrem zuverlässigen Datenebenen-Cluster gehostet werden. Sie können die Endpunkte für Ihre Route 53 ARC 53-Cluster auflisten, indem Sie den DescribeClusterAPIVorgang verwenden.

Wählen Sie nach dem Zufallsprinzip einen Ihrer Endpunkte aus, um den Status Ihrer Routing-Steuerung zu aktualisieren

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

Verwenden Sie die extrem zuverlässige DatenebeneAPI, um die Status der Routingsteuerung aufzulisten und zu aktualisieren, nicht die Konsole

Mithilfe der Route 53 ARC 53-Datenebene API können Sie Ihre Routingsteuerungen und Status während des ListRoutingControlsVorgangs anzeigen und den Status der Routingsteuerung aktualisieren, um den Verkehr für ein Failover während des UpdateRoutingControlStateVorgangs umzuleiten. Sie können den AWS CLI (wie in diesen Beispielen) oder den Code verwenden, den Sie mit einem der AWS SDKs geschrieben haben. Route 53 ARC bietet 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 her, damit Route 53 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 Failover mit Route 53 ARC

Testen Sie das Failover regelmäßig mit Route 53 ARC 53-Routing-Steuerung, um ein Failover von Ihrem primären Anwendungsstapel zu einem sekundären Anwendungsstapel durchzuführen. Es ist wichtig sicherzustellen, dass die Route ARC 53-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 Route 53 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.