Wartung

Auf dieser Seite wird beschrieben, wie Memorystore for Redis Wartungen an Instanzen durchführt. Außerdem enthält es Informationen und Konfigurationsempfehlungen, die Sie bei Ihren Clientanwendungen beachten sollten, um das Wartungsdesign ohne Ausfallzeit von Memorystore for Valkey zu nutzen. 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 Instanzen regelmäßig, damit der Dienst zuverlässig, leistungsfähig, sicher und auf dem neuesten Stand ist. Diese Updates werden als Wartung bezeichnet. Die Wartung wird vollständig vom Dienst verwaltet und soll keine Ausfallzeiten verursachen.

Wartung fällt in der Regel 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. Bei der Erkennung patchen wir das Betriebssystem, 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 lässt sich feststellen, ob der Drittanbieter-Client richtig konfiguriert ist, um negative Auswirkungen auf Ihre Anwendung zu vermeiden.

Planmäßige Wartung

Memorystore for Valkey nutzt eine schrittweise Bereitstellung und eine Lebenszyklusstrategie vom Typ „Erstellen vor Löschen“, um Ausfallzeiten durch die geplante Wartung von Memorystore auf Ihren 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. Störungsfreies Entfernen von Knoten, damit Clients die Knotentopologie-Updates ohne Auswirkungen auf die Verfügbarkeit abrufen 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 Wartungen. 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 zunehmender Reichweite und in einem Tempo durchgeführt, das eine frühzeitige Fehlererkennung ermöglicht, um Auswirkungen zu minimieren und die Stabilität zu gewährleisten. Die Aushärtezeit (die Zeit, in der das Update angewendet und überwacht wird, bevor es als erfolgreich betrachtet und fortgesetzt wird) wird in der gesamten Memorystore-Instanzflotte auf Dienstebene integriert. Außerdem werden die Aushärtezeiten in Instanzen in Zonen 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 gesamten Updates hochverfügbar ist. 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 größten Vorteile beim Aktualisieren einer Instanz mit vielen Shards. Durch die Aktualisierung nur eines kleinen Teils des gesamten Nutzer-Schlüsselbereichs zu einem bestimmten Zeitpunkt wird die Datenverfügbarkeit maximiert.

Lebenszyklusstrategie „Erstellen vor 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 der neuesten Softwareaktualisierung hinzu. Memorystore erstellt einen völlig neuen Knoten, anstatt einen vorhandenen Knoten zu aktualisieren, damit die bereitgestellte Kapazität im Falle eines unerwarteten Bootstrap-Fehlers erhalten bleibt.
  2. Wenn ein Knoten innerhalb des zu aktualisierenden Shards ein primärer Knoten ist, wird er zuerst in ein Replikat konvertiert und dann mithilfe eines koordinierten Failovers entfernt.
  3. Next Memorystore entfernt das Replikat, das die ältere Software verwendet.
  4. Der 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ügbarkeitsunterbrechung (und manchmal zu Datenverlusten) für die Clientanwendung führt. Bei Shards ohne Replikate stellt Memorystore for Redis zuerst ein neues Replikat bereit, koordiniert den Failover und ersetzt zuletzt den vorhandenen primären Knoten des Shards.

Schritt 1: Valkey-Replik hinzufügen

Der erste Schritt des Mechanismus „Erstellen vor Löschen“ besteht darin, einen Replikatknoten mit der neuesten Software hinzuzufügen und die Daten mithilfe des OSS-Valkey-Mechanismus für die vollständige Synchronisierung vom primären Knoten in den Replikatknoten zu kopieren. Dazu wird ein untergeordneter Prozess geforkt und die laufwerklose Replikation für das Bootstrapping des Replikats verwendet.

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 auf den neu hinzugefügten Replikatknoten aus und fährt dann mit dem Entfernen des Knotens 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 vorübergehend auf dem primären Knoten blockiert. So kann sichergestellt werden, dass das vorhandene Replikat zu 100% mit dem primären synchronisiert ist.
  2. Das Replikat führt den Auswahlvorgang durch, um die primäre Rolle zu übernehmen.
  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. Er lernt die Adresse des neuen primären Endpunkts und Umleitungen sind nicht mehr erforderlich.

Koordinierte Failover 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 zwischen primären Knoten auswirken, was sich auf die Entscheidung zur Wahl des neuen Primärknotens 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 dasjenige vergessen, das entfernt werden soll.

Der Replikknoten, 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. So kann der Drittanbieter-Client die Knotentopologie aktualisieren und die neuen Replikationsendpunkte abrufen. 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 zu entfernende Replikknoten nicht angezeigt.