Hochverfügbarkeit und Replikate

Auf dieser Seite wird erläutert, wie die Architektur von Memorystore for Valkey Hochverfügbarkeit unterstützt und bietet. Außerdem werden empfohlene Konfigurationen beschrieben, die zu einer verbesserten Instanzleistung und ‑stabilität beitragen.

Hochverfügbarkeit

Memorystore for Valkey basiert auf einer hochverfügbaren Architektur, bei der Ihre Clients direkt auf verwaltete Memorystore for Valkey-Knoten zugreifen. Dazu stellen Ihre Clients eine Verbindung zu einzelnen Endpunkten her, wie unter Verbindung zu einer Memorystore for Valkey-Instanz herstellen beschrieben.

Die direkte Verbindung zu Shards bietet folgende Vorteile:

  • Durch die direkte Verbindung werden Zwischen-Hops vermieden, wodurch die Umlaufzeit (Clientlatenz) zwischen Ihrem Client und dem Valkey-Knoten minimiert wird.

  • Wenn der Clustermodus aktiviert ist, werden durch die direkte Verbindung Single Points of Failure vermieden, da jeder Shard 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.

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 Gründe für die Verwendung einer Instanz mit einer einzelnen Zone.

Wenn Sie die Hochverfügbarkeit für Ihre Instanz aktivieren möchten, 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 automatisches Failover bei geplanter Wartung und unerwarteten Shard-Ausfällen.

Sie sollten Ihren Client gemäß den Best Practices für Clients in Client best practices konfigurieren. Wenn Sie die empfohlenen Best Practices verwenden, kann Ihr Client die folgenden Elemente für Ihre Instanz automatisch und ohne Ausfallzeiten verarbeiten:

  • Die Rolle (automatische Failover)

  • Der Endpunkt (Knotenaustausch)

  • Änderungen der Slotzuweisung im Zusammenhang mit dem aktivierten Clustermodus (horizontales Skalieren von Consumern)

Replikate

Eine hochverfügbare Memorystore for Valkey-Instanz ist eine regionale Ressource. Memorystore for Valkey verteilt die primären und Replikat-VMs von Shards auf mehrere Zonen, um sich vor einem Zonenausfall zu schützen. Memorystore for Valkey unterstützt Instanzen mit 0 bis 5 Replikaten pro Knoten.

Sie können Replikate verwenden, um den Lesedurchsatz zu erhöhen, wobei es zu potenziell veralteten Daten kommen kann.

  • Clustermodus aktiviert:Verwenden Sie den Befehl READONLY, um eine Verbindung herzustellen, über die Ihr Client Daten aus Replikaten lesen kann.
  • Clustermodus deaktiviert:Stellen Sie eine Verbindung zum Leseendpunkt her, um eine Verbindung zu einem der verfügbaren Replikate herzustellen.

Instanzformen mit aktiviertem Clustermodus

Die folgenden Diagramme zeigen Formen für Instanzen mit aktiviertem Clustermodus:

Instanzform mit drei Shards und null Replikaten pro Knoten

Eine Instanz im Memorystore for Valkey-Clustermodus ohne Replikate, deren Knoten gleichmäßig auf drei Zonen verteilt sind.

Instanzform mit drei Shards und einem Replikat pro Knoten

Eine Instanz im Memorystore for Valkey-Clustermodus mit einem Replikat pro Knoten und Knoten, die gleichmäßig auf drei Zonen verteilt sind.

Instanzform mit drei Shards und mehreren Replikaten pro Knoten

Eine Memorystore for Valkey-Instanz mit aktiviertem Clustermodus, mehreren Replikaten pro Knoten und Knoten, die gleichmäßig auf drei Zonen verteilt sind.

Instanzformen mit deaktiviertem Clustermodus

Das folgende Diagramm zeigt eine Form für Instanzen mit deaktiviertem Clustermodus:

Instanzform mit mehreren Replikaten

Eine Memorystore for Valkey-Instanz mit deaktiviertem Clustermodus mit mehreren Replikaten und Knoten, die gleichmäßig auf drei Zonen verteilt sind.

Automatisches 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 asynchronen Natur des Replikationsprotokolls von Valkey bestätigte Schreibvorgänge verloren gehen.

Clientanwendungen können den Befehl WAIT von Valkey nutzen, um die Datensicherheit in der Praxis zu verbessern.

Auswirkungen eines einzelnen Zonenausfalls auf den Keyspace

In diesem Abschnitt werden die Auswirkungen eines einzelnen Zonenausfalls auf eine Memorystore for Valkey-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, ist die Lesekapazität reduziert. Wir empfehlen dringend, die Clusterkapazität zu überdimensionieren, damit die Instanz im seltenen Fall eines einzelnen Zonenausfalls 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

  • Sowohl HA- als auch 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.

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 Arbeitsspeicher der Knoten, da die von den Schreibvorgängen betroffenen Seiten kopiert werden. Der Speicherbedarf kann bis zu doppelt so groß sein wie die Datenmenge im Knoten.

Damit Knoten genügend Arbeitsspeicher für den Snapshot haben, legen Sie maxmemory auf 80% der Knotenkapazität fest oder behalten Sie diesen Wert bei, sodass 20% für den Overhead reserviert sind. Dieser Speicher-Overhead hilft Ihnen zusätzlich zur Überwachung von Snapshots, Ihre Arbeitslast so zu verwalten, dass Snapshots erfolgreich erstellt werden. Reduzieren Sie außerdem den Schreibtraffic so weit wie möglich, wenn Sie Replikate hinzufügen. Weitere Informationen finden Sie unter Arbeitsspeichernutzung für eine Instanz überwachen.