Auf dieser Seite wird erläutert, wie die Architektur von Memorystore for Valkey Hochverfügbarkeit bietet und unterstützt. Auf dieser Seite wird auch erläutert, wie Sie die Leistung und Stabilität von Instanzen mit den von uns empfohlenen HA-Konfigurationen verbessern können.
Hochverfügbarkeit
Memorystore for Valkey basiert auf einer hochverfügbaren Architektur, bei der Ihre Clients direkt auf verwaltete Memorystore for Valkey-Knoten zugreifen. Ihre Clients stellen dazu 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, was die Umlaufzeit (Client-Latenz) zwischen Ihrem Client und dem Memorystore for Valkey-Knoten minimiert.
Im aktivierten Clustermodus wird durch eine direkte Verbindung ein Single Point of Failure vermieden, da jeder Shard so konzipiert ist, dass er unabhängig ausfällt. Wenn beispielsweise Traffic von mehreren Clients einen Slot (Keyspace-Chunk) überlastet, wird die Auswirkung durch den Shard-Fehler auf den Shard beschränkt, der für die Bereitstellung des Slots verantwortlich ist.
Empfohlene Konfigurationen
Wir empfehlen, hochverfügbare Multi-Zonen-Instanzen anstelle von Single-Zonen-Instanzen 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 auszuwählen. Weitere Informationen finden Sie unter Wann eine Einzelzoneninstanz verwendet werden sollte.
Wenn Sie die Hochverfügbarkeit für Ihre Instanz aktivieren möchten, müssen Sie mindestens ein Replikat für jeden Shard bereitstellen. Sie können dies beim Erstellen der Instanz tun oder die Replikatanzahl auf mindestens 1 Replikat pro Shard skalieren. Replikate bieten ein automatisches Failover während geplanter Wartungsarbeiten und unerwarteter Shard-Ausfälle.
Wir empfehlen, den Client gemäß der Anleitung unter Best Practices für Clients zu 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 Failovers)
- Der Endpunkt (Knotenersatz)
- Änderungen an der Slot-Zuweisung im Zusammenhang mit dem aktivierten Clustermodus (horizontales Skalieren des Nutzers)
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 zonalen Ausfall zu schützen. Memorystore for Valkey unterstützt Instanzen mit 0–5 Replikaten pro Shard.
Sie können Replikate verwenden, um den Lesedurchsatz zu erhöhen. Dies kann jedoch dazu führen, dass Daten veraltet sind.
- Clustermodus aktiviert: Verwenden Sie den Befehl
READONLY, um eine Verbindung herzustellen, über die Ihr Client aus Replikaten lesen kann. - Clustermodus deaktiviert: Stellen Sie eine Verbindung zum Reader-Endpunkt her, um eine Verbindung zu einem der verfügbaren Replikate herzustellen.
Beispiele für Instanzen mit aktiviertem Clustermodus
Die folgenden Diagramme zeigen Beispiele für Instanzen mit aktiviertem Clustermodus:
Beispielinstanz mit drei Shards und null Replikaten pro Shard
Instanzbeispiel mit drei Shards und einem Replikat pro Shard
Instanzbeispiel mit drei Shards und mehreren Replikaten pro Shard
Beispiele für Instanzen mit deaktiviertem Clustermodus
Das folgende Diagramm zeigt ein Beispiel für Instanzen mit deaktiviertem Clustermodus:
Instanzbeispiel mit mehreren Replikaten
Auswirkungen eines Failovers auf Ihre Anwendung
Wenn Memorystore for Valkey ein Replikat zur primären Instanz hochstuft, werden vorhandene Verbindungen zum primären Endpunkt der Instanz getrennt. Während automatisierter Reparaturen und Wartungsereignisse ist die Instanz durchschnittlich 30 Sekunden lang nicht verfügbar.
Sobald die Instanz verfügbar ist, verwendet Memorystore for Valkey denselben Verbindungsstring oder dieselbe IP-Adresse, um Ihre Anwendung automatisch an die neue primäre Instanz weiterzuleiten. Sie müssen Ihre Bewerbung nicht aktualisieren.
Wenn während eines Failovers Verbindungen zum Leseendpunkt bestehen, bricht Memorystore for Valkey die Verbindungen zum Replikat ab, das zur primären Instanz hochgestuft wird. Memorystore for Valkey bricht jedoch nicht die Verbindungen zu den anderen Replikaten ab. Nachdem das Failover abgeschlossen ist und das neue Replikat verfügbar ist, leitet Memorystore for Valkey Verbindungen an das neue Replikat weiter.
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 zum primären Replikat hochgestuft. Sie können Replikate explizit konfigurieren. Der Dienst kann während interner Wartungsarbeiten auch vorübergehend zusätzliche Replikate bereitstellen, um Ausfallzeiten zu vermeiden.
Automatische Failover verhindern Datenverlust während Wartungsupdates. Weitere Informationen zum automatischen Failover-Verhalten während der Wartung finden Sie unter Automatisches Failover-Verhalten während der Wartung.
Dauer von Failover und Knotenreparatur
Automatische Failover können bei ungeplanten Ereignissen wie dem Absturz eines primären Knotenprozesses oder einem Hardwarefehler einige Dutzend Sekunden dauern. In 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 fehlerhaften 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 fehlerhaften primären Knotens ebenfalls einige Minuten.
Clientverhalten während eines ungeplanten Failovers
Clientverbindungen werden je nach Art des Fehlers wahrscheinlich zurückgesetzt. Nach der automatischen Wiederherstellung können Sie Ihre Verbindungen mit exponentiellem Backoff wiederholen, um eine Überlastung der primären und Replikatknoten zu vermeiden.
Bei Clients, die Replikate für den Lesedurchsatz verwenden, kann es zu einer vorübergehenden Beeinträchtigung der Kapazität kommen, bis der fehlerhafte Knoten automatisch ersetzt wird.
Verlorene Schreibvorgänge
Bei einem Failover, das durch einen unerwarteten Fehler verursacht wird, 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 Ausfalls einer einzelnen Zone auf den Keyspace
In diesem Abschnitt werden die Auswirkungen eines Ausfalls einer einzelnen Zone auf eine Memorystore for Valkey-Instanz beschrieben.
Multizonale Instanzen
Hochverfügbarkeitsinstanzen: Wenn eine Zone ausfällt, ist der gesamte Schlüsselbereich 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 übermäßig bereitzustellen, 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 auf den 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 Schlüsselbereichs, 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ärinstanzen in der betroffenen Zone wiederhergestellt und die Kapazität des Clusters kehrt zu ihrem konfigurierten Wert zurück.
Single-Zone-Instanzen
- 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 gelöscht. 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 einen Prozess-Fork und einen Copy-on-Write-Mechanismus, um einen Snapshot von Knotendaten zu erstellen. Je nach Muster der Schreibvorgänge auf Knoten wächst der belegte Speicher der Knoten, da die von den Schreibvorgängen betroffenen Seiten kopiert werden. Der Speicherbedarf kann bis zu doppelt so groß sein wie die Daten im Knoten.
Damit die Knoten genügend Arbeitsspeicher haben, um den Snapshot abzuschließen, behalten Sie maxmemory bei 80% der Knotenkapazität bei oder legen Sie diesen Wert fest, sodass 20% für den Overhead reserviert sind. Dieser Speicher-Overhead hilft Ihnen zusätzlich zum Monitoring von Snapshots, Ihre Arbeitslast so zu verwalten, dass Snapshots erfolgreich erstellt werden. Außerdem sollten Sie beim Hinzufügen von Replikaten den Schreibtraffic so weit wie möglich reduzieren. Weitere Informationen finden Sie unter Arbeitsspeichernutzung für eine Instanz überwachen.