Auf dieser Seite wird erläutert, wie die Clusterarchitektur von Memorystore for Redis Hochverfügbarkeit (HA) unterstützt und bietet. Auf dieser Seite werden auch empfohlene Konfigurationen erläutert, die dazu beitragen, verbesserte Instanzleistung und -stabilität.
Hochverfügbarkeit
Memorystore for Valkey basiert auf einer hochverfügbaren Architektur, in der Ihre Clients 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.
Eine direkte Verbindung zu Shards bietet folgende Vorteile:
Die direkte Verbindung vermeidet einen Single Point of Failure, da jeder Shard für einen unabhängigen Ausfall ausgelegt ist. 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 Replikatanzahl auf mindestens 1 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/aus) für Ihre Instanz automatisch und ohne Ausfallzeit verwalten.
Replikate
Eine hoch verfügbare Memorystore for Valkey-Instanz ist eine regionale Ressource. Dies bedeutet, dass primäre und Replikat-VMs von Shards auf mehrere Zonen verteilt sind, um sie vor einem zonalen Ausfall 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 den Befehl READONLY verwenden, um eine Verbindung herzustellen
mit der Ihr Client
Replikate lesen kann.
Instanzform mit 0 Replikaten pro Knoten
Instanzform mit einem Replikat pro Knoten
Instanzform mit 2 Replikaten pro Knoten
Automatische Ausfallsicherung
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 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.
Failover und Knotenreparatur
Automatische Failovers können bei ungeplanten Ereignissen wie einem Absturz des primären Knotenprozesses oder eines Hardwarefehlers mehrere Sekunden dauern. Während dieser Zeit erkennt das System den Ausfall und wählt ein Replikat als neue primäre Instanz aus.
Die Knotenreparatur kann einige Minuten dauern, bis der Dienst fehlgeschlagenen Knoten ersetzen. Das gilt für alle primären und Replikknoten. Bei Instanzen, die nicht hochverfügbar sind (keine Replikate bereitgestellt), dauert die Reparatur eines ausgefallenen primären Knotens ebenfalls einige Minuten.
Clientverhalten während eines ungeplanten Failovers
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.
Verloren gegangene Schreibvorgänge
Während eines Failovers, der aus einem unerwarteten Fehler resultiert, können bestätigte Schreibvorgänge aufgrund der asynchronen Natur des Replikationsprotokolls von Valkey verloren gehen.
Clientanwendungen können den Valkey WAIT-Befehl nutzen, um die Datensicherheit in der realen Welt zu verbessern.