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
Serverless-Caches minimieren Knotenausfälle automatisch mit einer replizierten Multi-AZ-Architektur, sodass Knotenausfälle für Ihre Anwendung transparent sind. Sie sollten Ihre Cache-Daten auf mehrere Knoten verteilen, um die Auswirkungen von Knotenausfällen möglichst gering zu halten. Da selbst entworfene Cluster die Replikation nicht unterstützen, führt ein Knotenausfall zwangsläufig zu Datenverlusten in Ihrem Cluster.
Wenn Sie Ihren Memcached-Cluster erstellen, können Sie ihn mit 1 bis 60 Knoten oder mehr auf Anfrage 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
Serverless-Caches minimieren Ausfälle von Availability Zones automatisch mit einer replizierten Multi-AZ-Architektur, sodass AZ-Ausfälle für Ihre Anwendung transparent sind.
Verteilen Sie Ihre Knoten auf möglichst viele Availability Zones, um die Auswirkungen von Ausfällen einer Availability Zone in einem selbst entworfenen Cluster möglichst gering zu halten Im unwahrscheinlichen Fall eines AZ-Fehlers verlieren Sie die Daten, die in dieser AZ zwischengespeichert sind, nicht die Daten, die in der anderen zwischengespeichert sind. 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 Regionen und Availability Zones.
Minimierung von Fehlern beim Ausführen von Valkey oder Redis OSS
Wenn Sie eine Valkey- oder OSS Redis-Engine ausführen, haben Sie die folgenden Optionen, um die Auswirkungen eines Knoten- oder Availability Zone-Ausfalls zu minimieren.
Minimieren von Knotenausfällen
Serverless-Caches minimieren Knotenausfälle automatisch mit einer Multi-AZ-Architektur, sodass Knotenausfälle für Ihre Anwendung transparent sind. Selbst entworfene Cluster müssen entsprechend konfiguriert werden, um Ausfälle eines einzelnen Knotens zu minimieren.
Um die Auswirkungen von Valkey- oder OSS Redis-Knotenausfällen auf selbst entworfene Cluster zu minimieren, haben Sie die folgenden Optionen:
Behebung von Ausfällen: Valkey- oder Redis-Replikationsgruppen OSS
Eine Valkey- oder OSS Redis-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 OSS Redis Multi-AZ
Sie können Multi-AZ in Ihren Valkey- oder Redis-Replikationsgruppen aktivieren. OSS Unabhängig davon, ob Sie Multi-AZ aktivieren oder nicht, werden Ausfälle des primären Knotens erkannt und dieser wird automatisch ersetzt. Der genaue Vorgang ist dabei abhängig davon, ob Multi-AZ aktiviert ist.
Wenn Multi-AZ aktiviert ist
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. Dadurch kann Ihre Anwendung schneller wieder auf den primären Knoten schreiben, als wenn Multi-AZ nicht aktiviert ist.
Weitere Informationen finden Sie unter Minimierung von Ausfallzeiten durch die Verwendung ElastiCache von Multi-AZ mit Valkey und Redis OSS.
Wenn Multi-AZ deaktiviert ist
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 empfehlen wir, die Knoten in Ihrer Replikationsgruppe in verschiedenen Availability Zones () AZs zu 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
Serverless-Caches minimieren Ausfälle von Availability Zones automatisch mit einer replizierten Multi-AZ-Architektur, sodass AZ-Ausfälle für Ihre Anwendung transparent sind.
Verteilen Sie Ihre Knoten für jeden Shard auf möglichst viele Availability Zones, um die Auswirkungen von Ausfällen einer Availability Zone in einem selbst entworfenen Cluster möglichst gering zu halten
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 Ihre Knoten jedoch in mehreren Zonen lokalisierenAZs, führt ein Ausfall einer beliebigen AZ dazu, dass Sie nur die Knoten in dieser AZ verlieren.
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 OSS Redis-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, Serverless-Caches über selbst entworfene Cluster zu erstellen, da Sie ohne zusätzliche Konfiguration automatisch eine bessere Fehlertoleranz erzielen. Beim Erstellen eines selbst entworfenen Clusters gibt es jedoch zwei Arten von Ausfällen, die es zu berücksichtigen gilt: Ausfälle einzelner Knoten und umfassendere Ausfälle einer 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 zu minimieren, empfehlen wirOSS, 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 selbst entworfene Cluster auf Valkey oder Redis empfehlen wirOSS, Multi-AZ in Ihrer Replikationsgruppe zu aktivieren, sodass bei einem Ausfall des primären Knotens automatisch ein Failover 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. Durch die gleichmäßige Verteilung Ihrer Knoten AZs werden die Auswirkungen im unwahrscheinlichen Fall eines AZ-Ausfalls minimiert. Dies erfolgt automatisch für Serverless-Caches.
Weitere Vorsichtsmaßnahmen
Wenn Sie Valkey oder Redis verwendenOSS, 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.
