Hochverfügbarkeit und Replikate

Auf dieser Seite wird erläutert, wie die Architektur 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 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 Redis-Instanz herstellen beschrieben.

Die direkte Verbindung zu Shards bietet folgende Vorteile:

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

  • Wenn der Clustermodus aktiviert ist, wird durch die direkte Verbindung ein Single Point of Failure vermieden, da jeder Shard unabhängig 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.

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 Repliken 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 Ihr Kunde die empfohlenen Best Practices befolgt, können die folgenden Elemente für Ihre Instanz automatisch und ohne Ausfallzeit verarbeitet werden:

  • Die Rolle (automatische Failover)

  • Endpunkt (Knotenersatz)

  • Änderungen bei der Slotzuweisung im Clustermodus (Skalierung von Verbrauchern)

Replikate

Eine hochverfügbare Memorystore for Valkey-Instanz ist eine regionale Ressource. Das bedeutet, dass Memorystore for Valkey Primär- und Replikknoten von Shards auf mehrere Zonen verteilt, um einen zonalen Ausfall zu vermeiden. Memorystore for Valkey unterstützt Instanzen mit 0, 1 oder 2 Replikaten pro Knoten.

Mit Replikaten können Sie den Lesedurchsatz erhöhen, was jedoch zu einer potenziellen Datenaktualitätsverzögerung führen 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.

Instanzenformen mit aktiviertem Clustermodus

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

Mit 3 Shards und 0 Replikaten pro Knoten

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

Mit 3 Shards und 1 Replikat pro Knoten

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

Mit 3 Shards und 2 Replikaten pro Knoten

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

Formen für Instanzen mit deaktiviertem Clustermodus

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

Mit 2 Replikaten

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

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 Ausfall 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 Replikknoten 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.

Auswirkungen eines Zonenausfalls auf den Schlüsselbereich

In diesem Abschnitt werden die Auswirkungen eines Ausfalls einer einzelnen Zone auf eine Memorystore for Redis-Instanz beschrieben.

Instanzen mit mehreren Zonen

  • HA-Instanzen: Bei einem Ausfall einer Zone ist der gesamte Schlüsselbereich für Lese- und Schreibvorgänge verfügbar. Da einige Lesereplikate jedoch nicht verfügbar sind, ist 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. Nach dem Ausfall 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 in der betroffenen Zone bereitgestellte Teil des Schlüsselbereichs geleert und ist für die Dauer des Ausfalls nicht zum Schreiben oder Lesen verfügbar. Nach dem Ausfall werden die Primärspeicher in der betroffenen Zone wiederhergestellt und die Kapazität des Clusters kehrt zum konfigurierten Wert zurück.

Single-Zone-Instanzen

  • Sowohl HA- als auch Nicht-HA-Instanzen:Wenn die Zone, in der die Instanz bereitgestellt ist, ausfällt, ist der Cluster nicht verfügbar und die Daten werden gelöscht. Wenn eine andere Zone ausfällt, verarbeitet der Cluster weiterhin Lese- und Schreibanfragen.