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.
Resilienz bei Amazon ElastiCache
Die AWS globale Infrastruktur basiert auf AWS Regionen und Availability Zones. AWS Regionen bieten mehrere physisch getrennte und isolierte Availability Zones, die über Netzwerke mit niedriger Latenz, hohem Durchsatz und hoher Redundanz miteinander verbunden sind. Mithilfe von Availability Zones können Sie Anwendungen und Datenbanken erstellen und ausführen, die automatisch Failover zwischen Availability Zones ausführen, ohne dass es zu Unterbrechungen kommt. Availability Zones sind besser hoch verfügbar, fehlertoleranter und skalierbarer als herkömmliche Infrastrukturen mit einem oder mehreren Rechenzentren.
Weitere Informationen zu AWS Regionen und Availability Zones finden Sie unter AWS Globale
Zusätzlich zur AWS globalen Infrastruktur ElastiCache bietet Amazon mehrere Funktionen, um Ihre Datenstabilität und Backup-Anforderungen zu erfüllen.
Themen
Minimieren von Ausfällen
Bei der Planung Ihrer ElastiCache Amazon-Implementierung sollten Sie so planen, dass Ausfälle nur minimale Auswirkungen auf Ihre Anwendung und Daten haben. In diesem Abschnitt werden verschiedene Ansätze vorgestellt, mit denen Sie Ihre Anwendung und Ihre Daten vor Ausfällen schützen können.
Themen
Minimieren von Ausfällen mit Memcached
Wenn Sie die Memcached-Engine verwenden, haben Sie folgende Möglichkeiten, um die Auswirkungen von Ausfällen möglichst gering zu halten. Es gibt zwei Arten von Ausfällen, die es zu berücksichtigen gilt: Knotenausfälle und Ausfälle einzelner Availability Zones.
Minimieren von Knotenausfällen
Serverlose Caches minimieren Knotenausfälle automatisch mit einer replizierten Multi-AZ Architektur, sodass Knotenausfälle für Ihre Anwendung transparent sind. Um die Auswirkungen eines Knotenausfalls in einem knotenbasierten Cluster zu minimieren, verteilen Sie Ihre zwischengespeicherten Daten auf mehrere Knoten. Da knotenbasierte Cluster die Replikation nicht unterstützen, führt ein Knotenausfall immer zu einem gewissen Datenverlust in Ihrem Cluster.
Wenn Sie Ihren Memcached-Cluster erstellen, können Sie ihn mit 1 bis 60 Knoten oder auf Anfrage auch mit mehr Knoten erstellen. Wenn Sie Ihre Daten über mehrere Knoten partitionieren, gehen bei einem Knotenausfall weniger Daten verloren. Angenommen, Sie partitionieren Ihre Daten über 10 Knoten und ein einzelner Knoten speichert daher etwa 10 % der Cache-Daten. Bei einem Knotenausfall gehen in diesem Fall etwa 10 % Ihres Caches verloren und muss ersetzt werden, wenn ein neuer Knoten erstellt und bereitgestellt wird. Wenn dieselben Daten auf drei größere Knoten verteilt werden, gehen dagegen bei einem Knotenausfall etwa 33 % Ihrer Cache-Daten verloren.
Weitere Informationen zum Festlegen der Knotenanzahl in einem Memcached-Cluster erhalten Sie unter Erstellen eines Memcached-Clusters (Konsole).
Minimieren von Ausfällen einer Availability Zone
Serverlose Caches minimieren Ausfälle in der Availability Zone automatisch mit einer replizierten Multi-AZ Architektur, sodass AZ-Ausfälle für Ihre Anwendung transparent sind.
Um die Auswirkungen eines Ausfalls der Availability Zone in einem knotenbasierten Cluster zu minimieren, platzieren Sie Ihre Knoten in so vielen Availability Zones wie möglich. Sollte tatsächlich eine AZ ausfallen, verlieren Sie die Cache-Daten dieser AZ, nicht aber die Cache-Daten der anderen AZs.
Warum so viele Knoten?
Wenn meine Region nur 3 Availability Zones bereitstellt, warum sollte ich dann mehr als 3 Knoten erstellen, da im Fall eines AZ-Ausfalls sowieso etwa ein Drittel meiner Daten verloren geht?
Das ist eine sehr gute Frage. Dabei gilt es zu bedenken, dass wir zwei unterschiedliche Ausfalltypen minimieren wollen, Ausfälle einzelner Knoten und Availability Zones. Wenn Daten auf mehrere Availability Zones verteilt werden und eine der Zonen ausfällt, gehen nur die Cache-Daten dieser AZ verloren, unabhängig von der Anzahl der Knoten. Wenn jedoch ein Knoten ausfällt, gehen weniger Daten verloren, je mehr Knoten Sie verwenden.
Es gibt keine "Zauberformel", anhand derer sich die beste Anzahl an Knoten pro Cluster bestimmen lässt. Wägen Sie die Auswirkungen von Datenverlusten gegen die Wahrscheinlichkeit eines Ausfalls und die Kosten ab und treffen Sie anhand dieser Faktoren eine Entscheidung.
Weitere Informationen zum Festlegen der Knotenanzahl in einem Memcached-Cluster erhalten Sie unter Erstellen eines Memcached-Clusters (Konsole).
Weitere Informationen zu Regionen und Availability Zones finden Sie unter Auswahl von Regionen und Verfügbarkeitszonen für ElastiCache.
Minimierung von Ausfällen beim Ausführen von Valkey oder Redis OSS
Wenn Sie eine Valkey- oder Redis OSS-Engine ausführen, haben Sie die folgenden Optionen, um die Auswirkungen eines Knoten- oder Availability Zone-Ausfalls zu minimieren.
Minimieren von Knotenausfällen
Serverlose Caches minimieren Knotenausfälle automatisch mithilfe einer Multi-AZ Architektur, sodass Knotenausfälle für Ihre Anwendung transparent sind. Node-based Cluster müssen entsprechend konfiguriert werden, um den Ausfall eines einzelnen Knotens zu minimieren.
Um die Auswirkungen von Valkey- oder Redis OSS-Knotenausfällen auf knotenbasierte Cluster zu minimieren, haben Sie die folgenden Optionen:
Behebung von Ausfällen: Valkey- oder Redis OSS-Replikationsgruppen
Eine Valkey- oder Redis OSS-Replikationsgruppe besteht aus einem einzigen primären Knoten, von dem Ihre Anwendung sowohl lesen als auch schreiben kann, sowie aus 1 bis 5 schreibgeschützten Replikatknoten. Wenn Daten in den Primärknoten geschrieben werden, werden diese asynchron auf die Lesereplikat-Knoten aktualisiert.
Wenn ein Lesereplikat ausfällt,
ElastiCache erkennt das fehlgeschlagene Lesereplikat.
ElastiCache schaltet den ausgefallenen Knoten aus.
ElastiCache startet und stellt einen Ersatzknoten in derselben AZ bereit.
Der neue Knoten wird mit dem primären Knoten synchronisiert.
Währenddessen kann die Anwendung weiterhin Lese- und Schreibvorgänge auf den anderen Knoten ausführen.
Valkey oder Redis OSS Multi-AZ
Sie können die Replikationsgruppen Multi-AZ auf Ihren Valkey- oder Redis OSS-Replikationsgruppen aktivieren. Unabhängig davon, ob Sie die Aktivierung aktivieren Multi-AZ oder nicht, wird ein ausgefallener Primärserver automatisch erkannt und ersetzt. Wie dies geschieht, hängt davon ab, ob es aktiviert Multi-AZ ist oder nicht.
Wann Multi-AZ ist aktiviert
ElastiCache erkennt den Ausfall des Primärknotens.
ElastiCache stuft den Read-Replica-Knoten mit der geringsten Replikationsverzögerung zum Primärknoten hoch.
Die anderen Replikate synchronisieren sich mit dem neuen primären Knoten.
ElastiCache erstellt eine Read Replica in der AZ des ausgefallenen Primärservers.
Der neue Knoten synchronisiert sich mit dem neu ernannten primären Knoten.
Das Failover zu einem Replikationsknoten erfolgt in der Regel schneller als das Erstellen und Bereitstellen eines neuen primären Knotens. Das bedeutet, dass Ihre Anwendung das Schreiben auf Ihren primären Knoten früher fortsetzen kann, als wenn dies nicht aktiviert Multi-AZ wäre.
Weitere Informationen finden Sie unter Minimierung von Ausfallzeiten ElastiCache durch die Verwendung Multi-AZ mit Valkey und Redis OSS.
Wann Multi-AZ ist deaktiviert
ElastiCache erkennt einen primären Fehler.
ElastiCache schaltet den Primärserver offline.
ElastiCache erstellt einen neuen Primärknoten und stellt ihn bereit, um den ausgefallenen Primärknoten zu ersetzen.
ElastiCache synchronisiert den neuen Primärserver mit einem der vorhandenen Replikate.
Nach der Synchronisierung dient der neue Knoten als primärer Knoten des Clusters.
Während der Ausführung der Schritte 1 bis 4 dieses Vorgangs können keine Daten in den primären Knoten geschrieben werden. Die Anwendung kann jedoch weiterhin Lesezugriffe auf den Replikationsknoten ausführen.
Für zusätzlichen Schutz sollten Sie die Knoten in Ihrer Replikationsgruppe in verschiedenen Availability Zones (AZs) starten. Dadurch wirken sich Ausfälle einer AZ nur auf die Knoten in dieser AZ aus.
Weitere Informationen finden Sie unter Hohe Verfügbarkeit mit Replikationsgruppen.
Minimieren von Ausfällen einer Availability Zone
Serverlose Caches minimieren Ausfälle in der Availability Zone automatisch mit einer replizierten Multi-AZ Architektur, sodass AZ-Ausfälle für Ihre Anwendung transparent sind.
Um die Auswirkungen eines Ausfalls der Availability Zone in einem knotenbasierten Cluster zu minimieren, suchen Sie Ihre Knoten für jeden Shard in so vielen Availability Zones wie möglich.
Unabhängig von der Anzahl der Knoten in einem Shard führt ein katastrophaler Ausfall einer Availability Zone zu einem vollständigen Datenverlust Ihres Shards, wenn Sie Ihre Daten in nur einer Availability Zone speichern. Wenn Sie die Knoten jedoch auf mehrere AZs verteilen, führt ein AZ-Ausfall nur zum Verlust der Daten in den Knoten dieser AZ.
Bei einem Knotenausfall kann es zu einem Leistungsabfall kommen, da sich die Lesevorgänge nun auf weniger Knoten verteilen. Dieser Leistungsabfall bleibt bestehen, bis der ausgefallene Knoten ersetzt wurde.
Informationen zur Angabe der Availability Zones für Valkey- oder Redis-OSS-Knoten finden Sie unter. Erstellen eines Valkey-Clusters (Cluster-Modus deaktiviert) (Konsole)
Weitere Informationen zu Regionen und Availability Zones finden Sie unter Auswahl von Regionen und Verfügbarkeitszonen für ElastiCache.
Empfehlungen
Wir empfehlen, serverlose Caches über knotenbasierten Clustern zu erstellen, da Sie ohne zusätzliche Konfiguration automatisch eine bessere Fehlertoleranz erzielen. Bei der Erstellung eines knotenbasierten Clusters müssen Sie jedoch zwei Arten von Ausfällen einplanen: Ausfälle einzelner Knoten und Ausfälle in der breiten Availability Zone. Um Datenverluste durch Ausfälle möglichst gering zu halten, sollten Sie beiden Arten von Ausfällen vorbeugen.
Minimieren der Auswirkungen von Knotenausfällen
Um die Auswirkungen eines Knotenausfalls bei der Verwendung von Valkey oder Redis OSS zu minimieren, empfehlen wir, dass Ihre Implementierung mehrere Knoten in jedem Shard verwendet und die Knoten auf mehrere Availability Zones verteilt. Dies erfolgt automatisch für Serverless-Caches.
Für knotenbasierte Cluster auf Valkey oder Redis OSS empfehlen wir, dass Sie die Option in Ihrer Replikationsgruppe aktivieren, sodass bei einem Ausfall des primären Knotens automatisch ein Failover Multi-AZ auf ein Replikat durchgeführt ElastiCache wird.
Wenn Sie Memcached ausführen und die Daten über mehrere Knoten partitionieren, sinkt die Größe des Datenverlustes beim Ausfall eines Knotens mit steigender Anzahl verwendeter Knoten.
Minimieren der Auswirkungen von Ausfällen einer Availability Zone
Knoten sollten auf möglichst viele Availability Zones verteilt werden, um die Auswirkungen von Ausfällen einer Availability Zone gering zu halten. Wenn Sie die Knoten gleichmäßig auf Ihre AZs verteilen, halten Sie die Auswirkungen im unwahrscheinlichen Fall eines AZ-Ausfalls möglichst gering. Dies erfolgt automatisch für Serverless-Caches.
Weitere Vorsichtsmaßnahmen
Wenn Sie Valkey oder Redis OSS ausführen, empfehlen wir Ihnen zusätzlich zu den oben genannten, regelmäßige Backups Ihres Clusters zu planen. Bei Backups (Snapshots) wird eine RDB-Datei erstellt, die Sie im Fall eines Ausfalls oder von Datenbeschädigungen zur Wiederherstellung Ihres Caches verwenden können. Weitere Informationen finden Sie unter Snapshot und Wiederherstellung.
