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.
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.
Minimierung von Ausfällen beim Ausführen von Redis OSS
Wenn Sie die 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
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 Redis OSS-Knotenausfällen auf selbst entworfene Cluster zu minimieren, haben Sie die folgenden Optionen:
Minderung von Ausfällen: Redis OSS-Replikationsgruppen
Eine 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.
Redis OSS Multi-AZ
Sie können Multi-AZ in Ihren Redis OSS-Replikationsgruppen aktivieren. 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 in ElastiCache (Redis OSS) mit Multi-AZ.
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 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
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 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 Redis OSS-Knoten finden Sie unter. Erstellen eines Redis OSS-Clusters (Cluster-Modus deaktiviert) (Konsole)
Weitere Informationen zu Regionen und Availability Zones finden Sie unter Auswahl von Regionen und Availability Zones.
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
Sie sollten mehrere Knoten pro Shard implementieren und diese Knoten auf mehrere Availability Zones verteilen, um die Auswirkungen eines Knotenausfalls möglichst gering zu halten. Dies erfolgt automatisch für Serverless-Caches.
Für selbst entworfene Cluster empfehlen wir, Multi-AZ in Ihrer Replikationsgruppe zu aktivieren, sodass bei einem Ausfall des primären ElastiCache Knotens automatisch ein Failover auf ein Replikat durchgeführt wird.
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 Redis OSS verwenden, 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.
