Wie befolge ich die bewährte Methoden für Failover- und Wiederherstellungsereignisse für selbst entworfene ElastiCache für Valkey- oder ElastiCache für Redis OSS-Cluster?

Kurzbeschreibung

Failover- und Wiederherstellungsereignisse sind wichtige Bestandteile von Amazon ElastiCache, die es ElastiCache ermöglichen, widerstandsfähig zu sein. Wenn jedoch Failover- und Wiederherstellungsreignisse auftreten, können diese Ereignisse die Leistung und Verfügbarkeit der Anwendung beeinträchtigen.

Es ist eine bewährte Methode, Probleme aufgrund von Failover- und Wiederherstellungsereignissen, die sich auf den Cluster auswirken, zu reduzieren, indem du die folgenden Maßnahmen ergreifst:

• Überprüfe die Ereignisse.
• Verstehe die Ursache für diese Ereignisse.
• Bereite dich auf die Ereignisse vor.
• Konfiguriere Ereignisbenachrichtigungen.

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Ereignisse überprüfen

ElastiCache protokolliert verschiedene Ereignisse im Zusammenhang mit dem Cluster, den Sicherheitsgruppen und Parametergruppen.

Zu den Ereignissen gehören unter anderem das Erstellen und Löschen von Ressourcen, Skalierungsvorgänge, Failovers, Knotenneustarts und Snapshot-Erstellungen. Um Ereignisse in dem ElastiCache-Cluster besser zu verstehen und zu analysieren, überprüfe die ElastiCache-Ereignisse.

Beispiele für Failover-Ereignisse in den ElastiCache-Ereignisprotokollen:

December 5, 2024, 10:12:20 Finished recovery for cache nodes 0001
December 5, 2024, 10:10:48 Recovering cache nodes 0001
December 5, 2024, 10:05:45 Recovering cache nodes 0001
December 5, 2024, 10:04:24 Failover from master node <node name> to replica node <node name> completed

Beispiele für Wiederherstellungsereignisse in den ElastiCache-Ereignisprotokollen:

2022-10-05 19:20 Finished recovery for cache nodes 0001
2022-10-05 19:18 Recovering cache nodes 0001
2022-10-05 19:14 Recovering cache nodes 0001

Hinweis: Amazon ElastiCache für Memcached unterstützt kein Failover, aber möglicherweise werden in den Ereignisprotokollen für ein Wiederherstellungsereignis ähnliche Meldungen angezeigt.

Ursache des Ereignisses verstehen

Während eines Failover-Ereignisses ersetzt ElastiCache einen nicht verfügbaren Primärknoten durch einen Replikatknoten. ElastiCache ersetzt auch Primärknoten für vom Benutzer angeforderte Aktionen oder geplante Ereignisse. Weitere Informationen findest du unter Häufig gestellte Fragen zu Amazon ElastiCache.

Beispiele für Ereignisse:

• Um die Failover-Funktionalität zu testen
• Um geplante Wartungsarbeiten durchzuführen
• Um Probleme mit der Availability Zone zu lösen

Wenn bei einem Replikatknoten Verfügbarkeitsprobleme auftreten, ersetzt ElastiCache das Replikat durch einen neuen Replikatknoten.

Hinweis: Dieser Ersatz löst kein Failover-Ereignis aus.

Wenn ElastiCache in diesen Situationen versucht, den Cluster wiederherzustellen, protokolliert ElastiCache diese Wiederherstellungsereignisse.

Hinweis: Verwende die Amazon CloudWatch-Metrik IsMaster, um zu ermitteln, ob ein Knoten primär ist oder nicht. Weitere Informationen findest du unter Metriken für Valkey und Redis OSS.

Ungeplante Failover- und Wiederherstellungsereignisse

In ElastiCache kommt es zu einem ungeplanten Failover, wenn der Primärknoten unerwartet ausfällt und der Service aufgefordert wird, einen Replikatknoten in die primäre Rolle hochzustufen. Ebenso stellt ElastiCache automatisch einen neuen Replikatknoten bereit, wenn ein Replikatknoten ersetzt werden muss, weil ein Replikat ausfällt. Beide Prozesse minimieren Ausfallzeiten und sorgen für eine hohe Verfügbarkeit. Im Folgenden sind häufige Ursachen für ungeplante Failover und Ersatz aufgeführt:

• Bei grundlegenden Problemen im Zusammenhang mit dem ElastiCache-Host wie Hardwarefehler, Netzwerkprobleme oder Ausfall der Availability Zone führt ElastiCache eine Wiederherstellung durch. Für die AWS-Infrastruktur ermöglichen automatisierte Prozesse im seltenen Fall eines Ausfalls eine hohe Verfügbarkeit des Clusters.
• Für eine hohe Workload verwenden Amazon ElastiCache für Redis OSS und Amazon ElastiCache für Valkey einen einzigen Thread. Aus diesem Grund können Befehle mit langer Laufzeit andere Operationen blockieren. Eine übermäßige Workload im Cluster kann zu Überbelastung und Erschöpfung der Ressourcen sowie zu Failover und Wiederherstellung führen. Beispielsweise können komplexe Befehle, ineffiziente Lua-Skripte und umfangreiche schlüsselbasierte Operationen den Cluster überfordern und die Leistung beeinträchtigen.

Hinweis: Wenn ein primäres Replikat aufgrund einer vorübergehenden Störung der Availability Zone ausfällt, startet ElastiCache das neue Replikat, nachdem die Availability Zone wiederhergestellt ist.

Geplante Failover- und Wiederherstellungsreignisse

Geplante Failover- und Wiederherstellungsereignisse können bei geplanten Wartungsarbeiten oder benutzerinitiierten Operationen auftreten.

Für geplante Wartungsarbeiten aktualisiert AWS regelmäßig die ElastiCache-Flotte, um die Sicherheit, Zuverlässigkeit und operative Leistung der ElastiCache-Cluster zu erhöhen. Geplante Wartungsereignisse, z. B. für den Austausch von Knoten und Service-Updates im Rahmen einer kontinuierlichen verwalteten Wartung, können Failover- und Wiederherstellungsereignisse auslösen. Weitere Informationen findest du auf der Hilfeseite für verwaltete Wartung und Service-Updates von Amazon ElastiCache.

Bei benutzerinitiierten Operationen initiiert der Benutzer TestFailover über die TestFailover-API, den AWS-CLI-Befehl test-failover oder die ElastiCache-Konsole. Um ein Lesereplikat auf einen Cluster mit deaktiviertem primären Cluster-Modus hochzustufen, starte einen Hochstufen. Weitere Informationen findest du unter Hochstufen eines Lesereplikats zur primären Replikation für Valkey- oder Redis OSS-Replikationsgruppen (Cluster-Modus deaktiviert).

Hinweis: Unter bestimmten Bedingungen, z. B. bei großen operativen Ereignissen, blockiert AWS diese API möglicherweise. Wenn AWS die API blockiert, wird in den Ereignisprotokollen die folgende Meldung angezeigt: „Test Failover API called for node group 0001.“

Auf Ereignisse vorbereiten

Bei geplanten Failover-Ereignissen, z. B. für Wartungs- oder Service-Updates, ersetzt ElastiCache die Knoten, wenn der Cluster eingehende Schreibanforderungen bedient. Um Probleme zu vermeiden, folge den bewährten Methoden für geplante Failover-Ereignisse. Weitere Informationen findest du auf der Hilfeseite für verwaltete Wartung und Service-Updates von Amazon ElastiCache.

Bei ungeplanten Failover-Ereignissen erfolgt das ElastiCache-Failover automatisch, wenn du Multi-AZ für den Cluster aktivierst.

Hinweis: Wenn auf einem Replikat ein Failover auftritt, wenn du auf einen Knoten schreibst, der den Replikatendpunkt verwendet, ist der Knoten möglicherweise nicht verfügbar. Nachdem du das Replikat ersetzt hast, ist der Knoten für Leseanforderungen verfügbar.

Halte dich an die bewährten Methoden für Konnektivität und Konfiguration, um Probleme bei geplanten und ungeplanten Ereignissen zu vermeiden.

Ereignisbenachrichtigungen konfigurieren

Um schnell auf Ereignisse und deren Ursachen zu reagieren, konfiguriere ElastiCache so, dass Benachrichtigungen gesendet werden, wenn es in einem Cluster zu einem Failover oder einer Wiederherstellung kommt. Weitere Informationen findest du unter Verwalten von ElastiCache Amazon Simple Notification Service (Amazon SNS)-Benachrichtigungen.

Wenn du ElastiCache so konfigurierst, dass Amazon SNS für Benachrichtigungen verwendet wird, erhältst du Benachrichtigungen, die den folgenden Beispielen ähneln:

Beispiele für Wiederherstellungsereignisse:

Recovery reason : Recovery completed for node as ElastiCache monitoring detected a
 network reachability failure on the node, ElastiCache:CacheNodeReplaceComplete : <node>

Recovery reason : Recovery completed for node as ElastiCache monitoring detected
 software issues on the node, ElastiCache:CacheNodeReplaceComplete : <node>

Recovery reason : Recovery completed for node as ElastiCache monitoring detected
 unresponsive engine on the node, ElastiCache:CacheNodeReplaceComplete : <node>

Recovery reason : Recovery completed for node as ElastiCache monitoring detected
busy and unresponsive engine on the node, ElastiCache:CacheNodeReplaceComplete : <node>

Beispiele für Failover-Ereignisse:

Failover reason : Failover completed for node as ElastiCache monitoring detected a
network reachability failure on the node, ElastiCache:FailoverComplete : <node>

Failover reason : Failover completed for node as ElastiCache monitoring
detected software issues on the node, ElastiCache:FailoverComplete : <node>

Failover reason : Failover completed for node as ElastiCache monitoring
detected unresponsive engine on the node, ElastiCache:FailoverComplete : <node>

Failover reason : Failover completed for node as ElastiCache monitoring detected busy
 and unresponsive engine on the node, ElastiCache:FailoverComplete : <node>

Hinweis: ElastiCache für Memcached unterstützt keine erweiterten Meldungen für Wiederherstellungsereignisse.

Ähnliche Informationen

Überwachung bewährter Methoden mit Amazon ElastiCache für Redis mithilfe von Amazon CloudWatch

Wie behebe ich Probleme mit hoher Latenz in ElastiCache für Redis?

Wie behebe ich die erhöhte CPU-Auslastung in meinem selbst entworfenen Cluster in ElastiCache für Redis?