Auf dieser Seite wird erläutert, wie die Memorystore for Redis Cluster-Architektur Hochverfügbarkeit unterstützt und bietet. Außerdem werden empfohlene Konfigurationen beschrieben, die zu einer verbesserten Instanzleistung und ‑stabilität beitragen.
Weitere Informationen zu regionsspezifischen Aspekten finden Sie unter Geografie und Regionen.
Hochverfügbarkeit
Memorystore for Redis Cluster basiert auf einer hochverfügbaren Architektur, bei der Ihre Clients direkt auf verwaltete Memorystore for Redis Cluster-VMs zugreifen. Dazu stellen Ihre Clients eine Verbindung zu den einzelnen Shard-Netzwerk adressen her, wie unter Verbindung zu einer Memorystore for Redis Cluster-Instanz herstellen beschrieben.
Die direkte Verbindung zu Shards bietet folgende Vorteile:
Durch die direkte Verbindung wird ein Single Point of Failure vermieden, da jeder Shard so konzipiert ist, dass er unabhängig ausfallen kann. Wenn beispielsweise der Traffic von mehreren Clients einen Slot (Keyspace-Chunk) überlastet, beschränkt ein Shard-Ausfall die Auswirkungen auf den Shard, der für die Bereitstellung des Slots verantwortlich ist.
Durch die direkte Verbindung werden Zwischen-Hops vermieden, wodurch die Umlaufzeit (Clientlatenz) zwischen Ihrem Client und der Redis-VM minimiert wird.
Empfohlene Konfigurationen
Wir empfehlen, hochverfügbare Instanzen mit mehreren Zonen anstelle von Instanzen mit einer einzelnen Zone zu erstellen, da sie eine bessere Zuverlässigkeit bieten. Wenn Sie jedoch eine Instanz ohne Replikate bereitstellen möchten, empfehlen wir eine Instanz mit einer einzelnen Zone. Weitere Informationen finden Sie unter Wann sollte ein Cluster mit einer einzelnen Zone verwendet werden?
Um die Hochverfügbarkeit für Ihre Instanz zu aktivieren, müssen Sie mindestens einen Replikatknoten für jeden Shard bereitstellen. Sie können dies beim Erstellen der Instanz tun oder die Anzahl der Replikate auf mindestens ein Replikat pro Shard skalieren. Replikate bieten automatische Failover während der geplanten Wartung und bei unerwarteten Shard-Ausfällen.
Sie sollten Ihren Client gemäß der Anleitung unter Best Practices für Redis-Clients konfigurieren. Wenn Sie die empfohlenen Best Practices verwenden, kann Ihr OSS Redis-Client die Änderungen der Rolle (automatische Failover) und der Slotzuweisung (Knotenaustausch, horizontale Skalierung von Consumern) für Ihren Cluster automatisch und reibungslos ohne Ausfallzeiten verarbeiten.
Replikate
Eine hochverfügbare Memorystore for Redis Cluster-Instanz ist eine regionale Ressource. Das bedeutet, dass die primären und die Replikat-VMs von Shards auf mehrere Zonen verteilt sind, um vor einem Zonenausfall zu schützen. Memorystore for Redis Cluster unterstützt Instanzen mit 0 bis 5 Replikaten pro Knoten.
Sie können Replikate verwenden, um den Lesedurchsatz durch Skalieren von Lesevorgängen zu erhöhen.
Dazu müssen Sie den Befehl READONLY verwenden, um eine Verbindung herzustellen, über die Ihr Client Daten aus Replikaten lesen kann. Weitere Informationen zum Lesen
aus Replikaten finden Sie unter Mit Redis Cluster skalieren.
Clusterform mit 0 Replikaten pro Knoten
Clusterform mit 1 Replikat pro Knoten
Clusterform mit mehreren Replikaten pro Knoten
Automatischen Failover
Automatische Failover innerhalb eines Shards können aufgrund von Wartungsarbeiten oder eines unerwarteten Ausfalls des primären Knotens auftreten. Während eines Failovers wird ein Replikat zur primären Instanz hochgestuft. Sie können Replikate explizit konfigurieren. Der Dienst kann während der internen Wartung auch vorübergehend zusätzliche Replikate bereitstellen, um Ausfallzeiten zu vermeiden.
Automatische Failover verhindern Datenverlust bei Wartungsupdates. Weitere Informationen zum Verhalten bei automatischen Failovern während der Wartung finden Sie unter Verhalten bei automatischen Failovern während der Wartung.
Dauer von Failover und Knotenreparatur
Automatische Failover können bei ungeplanten Ereignissen wie einem Absturz des primären Knotenprozesses oder einem Hardwarefehler einige Dutzend Sekunden dauern. Während dieser Zeit erkennt das System den Fehler und wählt ein Replikat als neue primäre Instanz aus.
Die Knotenreparatur kann einige Minuten dauern, bis der Dienst den ausgefallenen Knoten ersetzt hat. Dies gilt für alle primären und Replikatknoten. Bei Instanzen, die nicht hochverfügbar sind (keine Replikate bereitgestellt), dauert die Reparatur eines ausgefallenen primären Knotens ebenfalls einige Minuten.
Clientverhalten bei einem ungeplanten Failover
Clientverbindungen werden je nach Art des Fehlers wahrscheinlich zurückgesetzt. Nach der automatischen Wiederherstellung sollten Verbindungen mit exponentiellem Backoff wiederholt werden, um eine Überlastung der primären und Replikatknoten zu vermeiden.
Clients, die Replikate für den Lesedurchsatz verwenden, sollten sich auf eine vorübergehende Verringerung der Kapazität einstellen, bis der ausgefallene Knoten automatisch ersetzt wird.
Verlorene Schreibvorgänge
Bei einem Failover aufgrund eines unerwarteten Fehlers können aufgrund der Asynchronität des Replikationsprotokolls von Redis bestätigte Schreibvorgänge verloren gehen.
Clientanwendungen können den Redis-Befehl WAIT verwenden, um die Datensicherheit in der Praxis zu verbessern. Dies ist ein Best-Effort-Ansatz, der mit Kompromissen verbunden ist, wie in der Dokumentation zum Redis-Befehl WAIT erläutert.
Auswirkungen eines Ausfalls einer einzelnen Zone auf den Keyspace
In diesem Abschnitt werden die Auswirkungen eines Ausfalls einer einzelnen Zone auf eine Memorystore for Redis Cluster-Instanz beschrieben.
Instanzen mit mehreren Zonen
HA-Instanzen:Wenn eine Zone ausfällt, ist der gesamte Keyspace für Lese- und Schreibvorgänge verfügbar. Da jedoch einige Lesereplikate nicht verfügbar sind, wird die Lesekapazität reduziert. Wir empfehlen dringend, die Clusterkapazität zu überdimensionieren, damit die Instanz im seltenen Fall eines Ausfalls einer einzelnen Zone genügend Lesekapazität hat. Sobald der Ausfall behoben ist, werden die Replikate in der betroffenen Zone wiederhergestellt und die Lesekapazität des Clusters kehrt zum konfigurierten Wert zurück. Weitere Informationen finden Sie unter Muster für skalierbare und zuverlässige Anwendungen.
Nicht-HA-Instanzen (keine Replikate) : Wenn eine Zone ausfällt, wird der Teil des Keyspace, der in der betroffenen Zone bereitgestellt wird, geleert und ist für die Dauer des Ausfalls nicht für Schreib- oder Lesevorgänge verfügbar. Sobald der Ausfall behoben ist, werden die primären Instanzen in der betroffenen Zone wiederhergestellt und die Kapazität des Clusters kehrt zum konfigurierten Wert zurück.
Instanzen mit einer einzelnen Zone
- HA- und Nicht-HA-Instanzen:Wenn die Zone, in der die Instanz bereitgestellt wird, ausfällt, ist der Cluster nicht verfügbar und die Daten werden geleert. Wenn eine andere Zone ausfällt, verarbeitet der Cluster weiterhin Lese- und Schreibanfragen. Sobald der Ausfall behoben ist, wird die konfigurierte Kapazität des Clusters wiederhergestellt.
Best Practices
In diesem Abschnitt werden Best Practices für Hochverfügbarkeit und Replikate beschrieben.
Replikat hinzufügen
Zum Hinzufügen eines Replikats ist ein RDB-Snapshot erforderlich. RDB-Snapshots verwenden eine Prozessverzweigung und einen „Copy-on-Write“-Mechanismus, um einen Snapshot der Knotendaten zu erstellen. Je nach Muster der Schreibvorgänge in Knoten wächst der verwendete Speicher der Knoten, da die von den Schreibvorgängen betroffenen Seiten kopiert werden. Der Speicherbedarf kann bis zu doppelt so groß wie die Daten im Knoten sein.
Damit Knoten genügend Speicher für den Snapshot haben, behalten Sie oder
legen Sie maxmemory bei 80% der
Knotenkapazität fest, sodass 20% für den Overhead reserviert sind. Dieser Speicher-Overhead hilft Ihnen zusätzlich zur Überwachung von Snapshots, Ihre Arbeitslast zu verwalten, um erfolgreiche Snapshots zu erstellen. Außerdem sollten Sie beim Hinzufügen von Replikaten den Schreibtraffic so weit wie möglich reduzieren. Weitere Informationen finden Sie unter Cluster mit hoher Schreiblast beobachten.