Informationen zur Wartung

Auf dieser Seite wird erläutert, wie Memorystore for Valkey die Wartung von Instanzen durchführt. Außerdem enthält er Informationen und Konfigurationsempfehlungen, die Ihre Client-Anwendungen kennen sollten, um die Memorystore for Valkeys Wartungsdesign ohne Ausfallzeiten. Diese Empfehlungen gelten sowohl für hochverfügbare Instanzen als auch für Instanzen ohne Replikate. Wir empfehlen jedoch dringend die Konfiguration mit Hochverfügbarkeit für alle Produktionsanwendungsfälle.

Memorystore for Valkey aktualisiert regelmäßig Instanzen, um sicherzustellen, dass der Dienst zuverlässig, leistungsfähig, sicher und aktuell ist. Diese Updates werden als Wartung bezeichnet. Die Wartung wird vollständig vom Dienst verwaltet und ist so konzipiert, dass sie keine Ausfallzeiten hat.

Die Wartung fällt normalerweise in die folgenden Kategorien:

  • Memorystore-Funktionen: Für die Einführung einiger Funktionen ist ein Wartungsupdate für Memorystore erforderlich.
  • Betriebssystem-Patches: Wir halten kontinuierlich Ausschau nach neuen Sicherheitslücken im Betriebssystem. Sobald wir feststellen, dass wir ein Patch für das Betriebssystem durchführen, um Sie vor neuen Risiken zu schützen.
  • Datenbank-Patches Die Wartung kann ein Valkey-Update umfassen, um die Sicherheit, Leistung und Zuverlässigkeit der Instanz über das hinaus zu verbessern, was OSS Valkey bietet.

Clientanwendung konfigurieren

So konfigurieren Sie Ihre Clientanwendung für eine optimale Leistung und Verfügbarkeit während der Wartung:

  1. Verwenden und konfigurieren Sie den Drittanbieter-Client gemäß den Best Practices für Clients, damit geplante Wartungsarbeiten keine Auswirkungen auf die Clientanwendung haben. Mit unseren empfohlenen Clientkonfigurationen können Sie Verbindungsrücksetzungen durch regelmäßige Aktualisierungen der Inline-Topologie und Hintergrundverbindungsrotationen vermeiden.
  2. Testen Sie Ihre Clientanwendung mit einer Reihe von Aktualisierungsvorgängen (z. B. Skalierung nach oben oder unten, Änderungen der Anzahl der Replikate), während Sie eine repräsentative Arbeitslast auf primären und Replikationsknoten ausführen und die Auswirkungen auf die Clients überwachen. Bei diesen Updates wird die Logik für die Aktualisierung der Inline-Topologie auf Clients, die Auswirkungen einer vollständigen Synchronisierung, die Erkennung neuer Knoten und die Möglichkeit zum Entfernen vorhandener Knoten getestet. Durch Tests wird sichergestellt, dass der Drittanbieter-Client richtig konfiguriert ist, um negative Auswirkungen auf Ihre Anwendung zu vermeiden.

Planmäßige Wartung

Memorystore for Valkey nutzt eine graduelle Bereitstellungs- und eine Lebenszyklusstrategie vom Typ „Erstellen vor dem Löschen“, um Ausfallzeiten der geplanten Wartung von Memorystore auf Ihre Valkey-Instanzen zu vermeiden. Die Wartung ohne Ausfallzeit wird durch die Weiterleitungsfunktionen des OSS Valkey-Clusterprotokolls in Verbindung mit den folgenden Memorystore-Mechanismen erreicht:

  1. Koordiniertes Failover ohne Datenverlust
  2. Ordnungsgemäße Knotenentfernung, damit Clients die Knotentopologie-Updates ohne Auswirkungen auf die Verfügbarkeit auf dem Laufenden halten können
  3. Die PSC-Endpunkte der Instanz sind von der Wartung nicht betroffen. Weitere Informationen zu PSC-Endpunkten finden Sie unter Instanzendpunkte.

Das in den folgenden Abschnitten beschriebene Dienstverhalten gilt nur für geplante Wartungsarbeiten. Informationen zu den Auswirkungen ungeplanter Ereignisse wie Hardwareausfällen finden Sie unter Clientverhalten bei einem ungeplanten Failover.

Standardwartungsfenster

Standardmäßig aktualisiert Memorystore Ihre Instanz in den folgenden Zeitfenstern entsprechend der Zeitzone Ihrer Instanz:

  • Wochentagsfenster (Montag bis Freitag): 22:00 bis 6:00 Uhr

  • Wochenendfenster: Freitag, 22:00 Uhr bis Montag, 6:00 Uhr

Strategie für schrittweise Bereitstellungen

Memorystore for Valkey-Bereitstellungen werden mit zunehmendem Umfang und mit einer Geschwindigkeit ausgeführt, die eine frühzeitige Fehlererkennung ermöglicht, um die Auswirkungen abzuschwächen und die Stabilität zu erhöhen. Verankerungszeiten (die Zeit, während der das Update angewendet und überwacht wird, bevor es als Erfolg gilt und in Zukunft) wird in die Memorystore-Instanzflotte im Dienstmaßstab eingebunden. Außerdem werden die Aushärtezeiten in Instanzen in Zonen in einer Region (mehrere Fehlerdomänen) integriert, um die Auswirkungen gegebenenfalls zu reduzieren.

Bei einer Instanz, die für Hochverfügbarkeit konfiguriert ist, wird immer nur eine Fehlerdomain/Zone aktualisiert, damit ein Instanz-Shard, einschließlich primärer Instanz und Replikaten, während des Updates eine hohe Verfügbarkeit hat. Außerdem werden immer nur wenige Valkey-Knoten aktualisiert. Bei Updates wird ein Lebenszyklusmechanismus vom Typ „Erstellen vor Löschen“ verwendet, um die Stabilität der Instanz zu maximieren. Diese Strategie bietet die meisten Vorteile bei der Aktualisierung einer Instanz mit vielen Shards. Die Datenverfügbarkeit wird maximiert, wenn die Updates jeweils nur auf einen kleinen Teil des gesamten Schlüsselraums des Nutzers angewendet werden.

Lebenszyklusstrategie „Vor dem Löschen erstellen und löschen“

Eine Valkey-Instanz hat mehrere Shards. Jeder Shard hat einen primären Knoten und null oder mehrere Replikatknoten. Memorystore verwendet das folgende Verfahren, um einen vorhandenen primären oder Replikat-Valkey-Knoten in einem Shard zu aktualisieren:

  1. Memorystore for Valkey fügt dem Shard zuerst ein komplett neues Replikat mit dem neuesten Softwareupdate hinzu. Anstatt einen vorhandenen Knoten zu aktualisieren, erstellt Memorystore einen komplett neuen Knoten, um sicherzustellen, dass die bereitgestellte Kapazität auch bei einem unerwarteten Bootstrap-Fehler erhalten bleibt.
  2. Wenn ein Knoten innerhalb des zu aktualisierenden Shards ein primärer Knoten ist, wird er vor dem Entfernen mithilfe eines koordinierten Failovers in ein Replikat konvertiert.
  3. Als Nächstes wird von Memorystore das Replikat entfernt, das die ältere Software verwendet.
  4. Dieser Vorgang wird für jeden Knoten in der Instanz wiederholt.

Mit der Strategie „Erstellen vor Löschen“ wird die bereitgestellte Kapazität der Instanz beibehalten, im Gegensatz zu einer typischen schrittweisen Bereitstellung, bei der die Aktualisierung vor Ort erfolgt, was jedoch zu einer Verfügbarkeitsstörung (und manchmal zu Datenverlusten) für die Clientanwendung führt. Bei Shards ohne Replikate stellt Memorystore for Valkey zuerst ein neues Replikat bereit, koordiniert das Failover und ersetzt schließlich den vorhandenen primären Knoten des Shards.

Schritt 1: Valkey-Replik hinzufügen

Der erste Schritt des Erstellungs- und Löschmechanismus besteht darin, einen Replikatknoten mit der neuesten Software unter Verwendung des OSS Valkey-Mechanismus zur vollständigen Synchronisierung hinzuzufügen, um die Daten vom primären zum Replikatknoten zu kopieren. Dazu wird ein untergeordneter Prozess geforkt und die diskless-Replikation wird verwendet, um das Replikativ zu starten.

Sie können die horizontal skalierende Architektur der Instanz am besten nutzen, indem Sie eine größere Anzahl von Shards bereitstellen, um die Größe des Schlüsselbereichs innerhalb eines Knotens zu verringern. Ein kleinerer Datensatz pro Knoten trägt dazu bei, die Auswirkungen der Fork-Latenz bei einer vollständigen Synchronisierung zu reduzieren. Außerdem wird das Kopieren von Daten zwischen den Knoten beschleunigt.

Schritt 2: Koordinierter primärer Failover

Wenn der zu aktualisierende Valkey-Knoten ein primärer Knoten ist, führt Memorystore zuerst ein koordiniertes Failover für den neu hinzugefügten Replikatknoten aus und fährt dann mit der Knotenentfernung fort. Während des koordinierten Failovers arbeiten der Client und die Valkey-Knoten zusammen und verwenden die folgenden Strategien, um Ausfallzeiten für die Anwendung zu vermeiden:

  1. Eingehende Clientanfragen werden auf dem primären Knoten vorübergehend blockiert. Dies bietet ein Fenster, in dem Sie sicherstellen können, dass das vorhandene Replikat zu 100% mit dem primären Knoten synchronisiert wird.
  2. Das Replikat schließt den Wahlprozess ab und übernimmt die primäre Rolle.
  3. Der bisherige primäre Knoten, jetzt ein Replikat, hebt die Blockierung der vorhandenen Anfragen auf und leitet sie über das OSS Valkey-Clusterprotokoll an den neu gewählten primären Knoten weiter. Alle neuen Anfragen, die an den vorherigen Replikatknoten gesendet werden, werden weiterhin an den neuen primären Knoten weitergeleitet.
  4. Ihr Valkey-kompatibler Client aktualisiert seine In-Memory-Topologie. Die Adresse des neuen primären Endpunkts wird erkannt und es sind keine Weiterleitungen mehr erforderlich.

Koordinierte Failovers sollten in der Regel nur wenige Millisekunden dauern. Die Failover-Latenz kann jedoch durch In-Flight-Daten, die noch an die Replikate gesendet werden müssen, und durch die Gesamtgröße der Instanz erhöht werden. Die Instanzgröße kann sich auf die Konvergenz der primären Knoten auswirken, was sich auf die Entscheidungsfindung zur Auswahl der neuen primären Instanz auswirkt.

Schritt 3: Valkey-Replikat entfernen

Der letzte Schritt des Mechanismus „Erstellen vor Löschen“ besteht darin, den Replikknoten in der älteren Software zu entfernen. Ein plötzliches Entfernen von Knoten hätte Auswirkungen auf Clientanwendungen, da Clients die Endpunktinformationen und die Instanztopologie im Cache speichern. Bei Memorystore for Valkey wird das Entfernen eines Valkey-Repliks reibungslos durchgeführt, damit Clientanwendungen ihre Topologie aktualisieren können, bevor ein Knoten hart heruntergefahren wird. Die Topologie ist so angepasst, dass Clients das neue Replikat kennenlernen, aber auch das zu entfernende Replikat im Voraus vergessen können.

Der Replikatknoten, auf dem die ältere Software ausgeführt wird, wird für einen bestimmten Zeitraum beibehalten, in der Regel einige Minuten, während der er die eingehenden Leseanfragen an den primären Knoten seines Shards weiterleitet. Dadurch kann der Drittanbieterclient die Knotentopologie aktualisieren und mehr über die neuen Replikatendpunkte erfahren. Wenn der Client nach Ablauf der Zeitspanne versucht, einen entfernten Knoten zu erreichen, schlägt der Versuch fehl. Dies löst wiederum eine Aktualisierung der Knotentopologie auf dem Client aus, der eine Verbindung herstellt, damit er über die Replikaänderung informiert wird. Bei neuen Aktualisierungen der Knotentopologie wird der Replikatknoten nicht entfernt.