Auf dieser Seite wird erläutert, wie die Clusterarchitektur von Memorystore for Redis Hochverfügbarkeit (High Availability, HA) unterstützt und bietet. Auf dieser Seite werden auch empfohlene Konfigurationen erläutert, die zu einer besseren Instanzleistung und -stabilität beitragen.
Hochverfügbarkeit
Memorystore for Valkey basiert auf einer hochverfügbaren Architektur, bei der Ihre Kunden direkt auf verwaltete Memorystore for Valkey-VMs zugreifen. Dazu stellen Ihre Clients eine Verbindung zu einzelnen Shard-Netzwerkadressen her, wie unter Verbindung zu einer Memorystore for Valkey-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 unabhängig voneinander ausfallen kann. Wenn beispielsweise ein Slot (Schlüsselbereichs-Chunk) durch Traffic von mehreren Clients überlastet wird, wird durch den Shard-Fehler die Auswirkung auf den Shard begrenzt, der für die Bereitstellung des Slots verantwortlich ist.
Durch eine direkte Verbindung werden Zwischen-Hops vermieden, wodurch die Laufzeit (Clientlatenz) zwischen Ihrem Client und der Valkey-VM minimiert wird.
Empfohlene Konfigurationen
Wir empfehlen, hochverfügbare Multi-Zonen-Instanzen anstelle von Ein-Zonen-Instanzen zu erstellen, da sie eine höhere 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 Instanz mit einer einzelnen Zone auswählen, wenn Ihre Instanz keine Replikate verwendet.
Wenn Sie die Hochverfügbarkeit für Ihre Instanz aktivieren möchten, müssen Sie für jeden Shard mindestens einen Replikatknoten bereitstellen. Sie können dies beim Erstellen der Instanz tun oder die Anzahl der Replikats auf mindestens ein Replikat pro Shard skalieren. Replikate bieten einen automatischen Failover bei geplanter Wartung und unerwartetem Shard-Ausfall.
Sie sollten Ihren Client gemäß den Best Practices für Clients konfigurieren. Wenn Sie die empfohlenen Best Practices verwenden, kann Ihr Kunde die Rolle (automatische Failover) und Änderungen der Slotzuweisung (Knotenersatz, Nutzer skalieren/ausweiten) für Ihre Instanz automatisch und ohne Ausfallzeit verwalten.
Replikate
Eine hochverfügbare Memorystore for Valkey-Instanz ist eine regionale Ressource. Das bedeutet, dass primäre und Replika-VMs von Shards auf mehrere Zonen verteilt werden, um vor Zonenausfällen zu schützen. Memorystore for Valkey unterstützt Instanzen mit 0, 1 oder 2 Replikaten pro Knoten.
Mithilfe von Replikaten können Sie den Lesedurchsatz durch Skalierung von Lesevorgängen erhöhen.
Dazu müssen Sie mit dem Befehl READONLY eine Verbindung herstellen, über die Ihr Client Daten aus Replikaten lesen kann.
Instanzform mit 0 Replikaten pro Knoten
Instanzform mit einem Replikat pro Knoten
Instanzform mit zwei Replikaten pro Knoten
Automatische Ausfallsicherung
Automatische Failover innerhalb eines Shards können aufgrund von Wartungsarbeiten oder eines unerwarteten Ausfalls des primären Knotens auftreten. Bei einem Failover wird ein Replikat zum primären Replikat hochgestuft. Sie können Replikate explizit konfigurieren. Der Dienst kann auch während der internen Wartung vorübergehend zusätzliche Replikate bereitstellen, um Ausfallzeiten zu vermeiden.
Automatische Failover verhindern Datenverluste bei Wartungsupdates. Weitere Informationen zum automatischen Failover während der Wartung finden Sie unter Automatisches Failover während der Wartung.
Dauer des Failover und der Knotenreparatur
Bei ungeplanten Ereignissen wie einem Absturz des primären Knotenprozesses oder einem Hardwarefehler kann ein automatischer Failover einige Sekunden dauern. Während dieser Zeit erkennt das System den Fehler und wählt ein Replikat als neue primäre Instanz aus.
Die Reparatur eines Knotens kann einige Minuten dauern, bis der Dienst den ausgefallenen Knoten ersetzt hat. Das 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
Je nach Art des Fehlers werden Clientverbindungen wahrscheinlich zurückgesetzt. Nach der automatischen Wiederherstellung sollten Verbindungen mit exponentiellem Backoff wiederholt werden, um eine Überlastung der primären und Replikationsknoten zu vermeiden.
Clients, die Replikas für den Lesedurchsatz verwenden, sollten mit einer vorübergehenden Kapazitätsminderung rechnen, bis der ausgefallene Knoten automatisch ersetzt wird.
Verlorene Schreibvorgänge
Bei einem Failover aufgrund eines unerwarteten Fehlers können bestätigte Schreibvorgänge aufgrund der asynchronen Natur des Replikationsprotokolls von Valkey verloren gehen.
Clientanwendungen können den Valkey-Befehl „WAIT“ nutzen, um die Datensicherheit in der Praxis zu verbessern.