Wartung

Auf dieser Seite wird beschrieben, wie Memorystore for Valkey Wartungsarbeiten an Instanzen ausführt. Außerdem enthält es Informationen und Konfigurationsempfehlungen, die Ihre Clientanwendungen berücksichtigen müssen, um die Wartung ohne Ausfallzeiten von Memorystore for Valkey nutzen zu können. Diese Empfehlungen gelten sowohl für hochverfügbare Instanzen als auch für Instanzen ohne Replikate. Für alle Produktionsanwendungsfälle empfehlen wir jedoch dringend, die Hochverfügbarkeitskonfiguration zu verwenden.

Memorystore for Valkey aktualisiert Instanzen regelmäßig, um dafür zu sorgen, 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 verursacht.

Wartungsarbeiten lassen sich in der Regel in die folgenden Kategorien einteilen:

  • 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 einer Instanz zu verbessern. Das geht über die Funktionen von OSS Valkey hinaus.

Clientanwendung konfigurieren

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

  1. Verwenden und konfigurieren Sie Ihren Drittanbieter-Client gemäß den Valkey-Client-Best Practices, damit geplante Wartungsarbeiten keine Auswirkungen auf die Clientanwendung haben. Mit unseren empfohlenen Clientkonfigurationen können Sie Verbindungsrücksetzungen durch regelmäßige Inline-Topologieaktualisierungen und Hintergrundverbindungsrotationen vermeiden.
  2. Testen Sie Ihre Clientanwendung mit einer Reihe von Aktualisierungsvorgängen (z. B. Skalieren oder Ändern der Anzahl von Replikaten), während Sie eine repräsentative Arbeitslast auf primären und Replikatknoten ausführen und die Auswirkungen auf den Client beobachten. Mit diesen Updates wird die Inline-Topologieaktualisierungslogik auf Clients, die Auswirkungen der vollständigen Synchronisierung, die Erkennung neuer Knoten und die Möglichkeit zum Entfernen vorhandener Knoten getestet. Durch Tests lässt sich sicherstellen, dass der Drittanbieterclient richtig konfiguriert ist, um negative Auswirkungen auf Ihre Anwendung zu vermeiden.

Planmäßige Wartung

Memorystore for Valkey nutzt eine schrittweise Bereitstellung und eine Lifecycle-Strategie vom Typ „create-before-destroy“, um Ausfallzeiten bei geplanten Wartungsarbeiten für Memorystore für Ihre Valkey-Instanzen zu vermeiden. Memorystore for Valkey ermöglicht die Wartung ohne Ausfallzeiten, indem die Funktionen zur Anforderungsweiterleitung des OSS-Valkey-Instanzprotokolls mit den folgenden Memorystore-Mechanismen verwendet werden:

  1. Ein koordinierter Failover ohne Datenverlust.
  2. Ein ordnungsgemäßes Entfernen von Knoten, damit Clients die Knoten-Topologie-Updates ohne Auswirkungen auf die Verfügbarkeit nachholen können.
  3. Die Private Service Connect-Endpunkte der Instanz, die nicht von der Wartung betroffen sind. Weitere Informationen zu diesen Endpunkten finden Sie unter Instanzendpunkte.

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

Standardwartungsfenster

Standardmäßig aktualisiert Memorystore Ihre Instanz in den folgenden Fenstern 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 der schrittweisen Bereitstellung

Bei Memorystore for Valkey werden Bereitstellungen mit einem schrittweise zunehmenden Umfang und in einer Geschwindigkeit ausgeführt, die eine frühzeitige Fehlererkennung ermöglicht, um Auswirkungen zu minimieren und die Stabilität zu gewährleisten. Die Bake-Zeiten (die Zeit, in der das Update angewendet und überwacht wird, bevor es als erfolgreich gilt und fortgefahren wird) sind über die gesamte Memorystore-Instanzflotte hinweg auf Dienstebene integriert. Außerdem sind die Bake-Zeiten in Instanzen in verschiedenen Zonen einer Region (mehrere Fehlerdomänen) integriert, um die Auswirkungen zu reduzieren.

Bei Ihrer für Hochverfügbarkeit konfigurierten Instanz aktualisiert Memorystore for Valkey jeweils nur eine Fehlerdomain oder Zone, um sicherzustellen, dass ein Instanzshard, einschließlich primärer Instanz und Replikaten, während des gesamten Updates hochverfügbar ist. Außerdem werden bei Memorystore for Valkey immer nur wenige Knoten gleichzeitig aktualisiert. Bei Updates wird ein Create-before-Destroy-Lebenszyklusmechanismus verwendet, um die Stabilität einer Instanz zu maximieren. Diese Strategie bietet die meisten Vorteile, wenn Sie eine Instanz mit vielen Shards aktualisieren. Wenn die Aktualisierungen jeweils nur auf einen kleinen Teil des gesamten Nutzer-Keyspace angewendet werden, wird die Datenverfügbarkeit maximiert.

„Create-before-destroy“-Lebenszyklusstrategie

Eine Valkey-Instanz hat mehrere Shards. Jeder Shard hat einen primären Knoten und null oder mehr 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 ein neues Replikat mit dem neuesten Softwareupdate hinzu. Memorystore erstellt einen neuen Knoten, anstatt einen vorhandenen Knoten zu aktualisieren. So wird sichergestellt, dass die bereitgestellte Kapazität beibehalten wird, falls ein unerwarteter Bootstrap-Fehler auftritt.
  2. Wenn ein Knoten im zu aktualisierenden Shard ein primärer Knoten ist, wird er zuerst in ein Replikat konvertiert, bevor er mit einem koordinierten Failover entfernt wird.
  3. Memorystore entfernt das Replikat, das die frühere Software verwendet.
  4. Memorystore wiederholt diesen Vorgang für jeden Knoten in der Instanz.

Mit der Strategie „Erstellen vor dem Löschen“ wird die bereitgestellte Kapazität der Instanz beibehalten. Bei einer typischen Rolling Deployment-Strategie, bei der die Aktualisierung direkt erfolgt, kommt es zu einem Ausfall der Verfügbarkeit (und manchmal zu Datenverlust) für die Clientanwendung. 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: Replikat hinzufügen

Im ersten Schritt des Create-Before-Destroy-Mechanismus wird ein Replikatknoten mit der neuesten Software hinzugefügt. Dabei wird der OSS-Valkey-Mechanismus für die vollständige Synchronisierung verwendet, um die Daten vom primären Knoten auf den Replikatknoten zu kopieren. Dazu wird ein untergeordneter Prozess geforkt und die Replikatinstanz wird mithilfe der replikatlosen Replikation gestartet. Memorystore for Valkey unterstützt die replikationslose Replikation. Sofern Sie Persistenz nicht aktivieren, werden bei der Replikation in Memorystore for Valkey keine Laufwerke verwendet.

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

Schritt 2: Koordiniertes primäres Failover ausführen

Wenn der Valkey-Knoten, der aktualisiert werden muss, ein primärer Knoten ist, führt Memorystore ein koordiniertes Failover auf den neu hinzugefügten Replikatknoten aus. Memorystore entfernt dann den Knoten. 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, sodass das vorhandene Replikat vollständig mit dem primären Knoten synchronisiert werden kann.
  2. Das Replikat schließt den Auswahlprozess ab, um die primäre Rolle zu übernehmen.
  3. Der bisherige primäre Knoten, der jetzt ein Replikatknoten ist, gibt die vorhandenen Anfragen frei und leitet sie mithilfe des OSS-Valkey-Instanzprotokolls an den neuen 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 gelernt und es sind keine Weiterleitungen mehr erforderlich.

Koordinierte Failovers dauern in der Regel nur wenige Millisekunden. „In-Flight“-Daten, die noch in Replikate geschrieben werden müssen, und die Gesamtgröße Ihrer Instanz können jedoch die Failover-Latenz erhöhen. Die Instanzgröße kann sich auf die Konvergenz zwischen primären Knoten auswirken, was sich wiederum auf die Entscheidungsfindung bei der Auswahl des neuen primären Knotens auswirkt.

Schritt 3: Replikat entfernen

Der letzte Schritt des Create-Before-Destroy-Mechanismus besteht darin, den Replikatknoten auf der früheren Software zu entfernen. Das plötzliche Entfernen eines Knotens hätte Auswirkungen auf Clientanwendungen, da Clients die Endpunktinformationen und die Instanztopologie im Cache speichern. Bei Memorystore for Valkey ist das Entfernen eines Valkey-Replikat so konzipiert, dass Clientanwendungen ihre Topologie aktualisieren können, bevor ein Knoten endgültig heruntergefahren wird. Die Topologie ist so angepasst, dass Clients die neue Replikat kennenlernen, aber auch das zu entfernende Replikat rechtzeitig vergessen.

Der Replikatknoten, auf dem die frühere Software ausgeführt wird, wird für einen bestimmten Zeitraum beibehalten, in der Regel einige Minuten. In dieser Zeit beginnt er, die eingehenden Leseanfragen an den primären Knoten seines Shards weiterzuleiten. So kann der Drittanbieterclient die Knotentopologie aktualisieren und die neuen Replikatendpunkte kennenlernen. Wenn der Client nach dem Drain-Zeitraum versucht, einen entfernten Knoten zu erreichen, schlägt der Versuch fehl. Dadurch wird eine Aktualisierung der Knotentopologie auf dem verbindenden Client ausgelöst, sodass er über die Replikatänderung informiert wird. Bei neuen Aktualisierungen der Knotentopologie wird der zu entfernende Replikatknoten nicht angezeigt.

Wartungseinstellungen

Mit Memorystore for Valkey können Sie Wartungszeitpläne an die Anforderungen Ihrer Anwendung anpassen und Unterbrechungen minimieren. Wenn Sie einen Wartungszeitplan anpassen möchten, konfigurieren Sie ein Wartungsfenster für Ihre Instanz.

Sie legen Wartungsfenster für jede Memorystore for Valkey-Instanz fest und haben die folgenden Konfigurationsoptionen:

  • Wochentag: Der Tag, an dem die Wartung stattfindet.
  • Startstunde: Die Stunde, in der die Wartung beginnt.

Das Wartungsfenster dauert eine Stunde. In einigen Fällen kann die Wartung über das von Ihnen ausgewählte Fenster hinausgehen.

Nachdem Sie ein Wartungsfenster für eine Instanz konfiguriert haben, plant Memorystore for Valkey zukünftige automatische Wartungen gemäß den von Ihnen festgelegten Einstellungen für Wartungsfenster.

Standardwartungsfenster

Wenn Sie kein Wartungsfenster festlegen, aktualisiert Memorystore for Valkey Ihre Instanz in einem der folgenden Fenster 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

Beispiel für die Wartung

Als Entwickler, der einen Einkaufswagendienst bei einem Einzelhändler verwaltet, sind Sie für eine Produktionsumgebung verantwortlich, die eine Memorystore for Valkey-Instanz umfasst. Um eine optimale Leistung während der Wartung zu gewährleisten, planen Sie sie für Zeiten, in denen die Instanz nur wenig Traffic hat. Das passiert in der Regel sonntags um Mitternacht.

In diesem Fall legen Sie das Wartungsfenster der Produktionsinstanz auf den folgenden Tag und die folgende Uhrzeit fest:

  • Wochentag: Sonntag
  • Beginn (Stunde): 1:00 Uhr

Benachrichtigungen über anstehende Wartungen

Damit Sie über Wartungsereignisse in Ihrer Instanz informiert bleiben, sollten Sie mindestens eine Woche vor der geplanten Wartung E-Mail-Benachrichtigungen über bevorstehende Wartungen einrichten. Diese Benachrichtigungen haben die Betreffzeile "Upcoming maintenance for your Cloud Memorystore instance [your-instance-name]".

Memorystore for Valkey sendet auch eine Benachrichtigung, wenn die Wartung für Ihre Instanz beginnt. Der Betreff der E-Mail lautet "Maintenance is undergoing for your Cloud Memorystore instance [your-instance-name]".

Nach Abschluss der Wartung von Memorystore for Valkey wird eine Benachrichtigung gesendet. Der Betreff der E-Mail lautet "Completed Maintenance for your Cloud Memorystore instance [your-instance-name]".

Wenn Memorystore for Valkey die Wartung verschiebt, erhalten Sie eine E‑Mail, in der Sie über die abgesagte Wartung informiert werden. Der Betreff dieser E‑Mail lautet "Canceled maintenance for your Cloud Memorystore instance [your-instance-name]".

Wenn Sie Wartungsbenachrichtigungen erhalten möchten, müssen Sie sie aktivieren. So registrieren Sie sich für Wartungsbenachrichtigungen:

  1. Legen Sie ein Wartungsfenster fest.
  2. Aktivieren Sie Wartungsbenachrichtigungen.

Wenn Sie Wartungsbenachrichtigungen von Memorystore for Valkey erhalten möchten, führen Sie diese Schritte mindestens eine Woche vor dem geplanten Wartungsupdate für Ihre Instanz aus. Andernfalls hat Memorystore for Valkey nicht genügend Zeit, Sie über die bevorstehende Wartung zu benachrichtigen.

Memorystore for Valkey sendet Benachrichtigungen an die E‑Mail-Adresse, die mit Ihrem Google-Konto verknüpft ist. Ein benutzerdefinierter E‑Mail-Alias wie ein Team-E‑Mail-Alias kann nicht konfiguriert werden. Außerdem können wir keine Benachrichtigungen an eine andere E-Mail-Adresse senden.

Wenn Sie Wartungsbenachrichtigungen abonnieren, erhalten Sie Benachrichtigungen für alle Memorystore for Valkey-Instanzen, für die in einem Google Cloud Projekt Wartungsarbeiten geplant sind. Sie erhalten für jede Instanz eine separate Benachrichtigung.

Weitere Informationen zum Suchen nach einer geplanten Wartung finden Sie unter Geplante Wartung suchen.

Wartung verschieben

In diesem Abschnitt finden Sie Richtlinien zum Verschieben von Wartungsarbeiten. Wenn beispielsweise ein neuer Dienst während des aktuellen Wartungsfensters gestartet werden soll, sollten Sie das Wartungsfenster auf einige Tage nach dem Start verschieben.

Sie können die Wartung innerhalb von 14 Tagen nach dem ursprünglich geplanten Zeitpunkt verschieben. Wählen Sie im Rahmen der Verschiebung der Wartung eine der folgenden Optionen aus:

  • Jetzt aktualisieren: Anstatt auf das geplante Wartungsfenster zu warten, können Sie die Updates sofort auf Ihre Instanz anwenden.
  • Benutzerdefinierter Tag und benutzerdefinierte Uhrzeit: Sie können einen beliebigen Zeitpunkt innerhalb von zwei Wochen nach dem ursprünglich geplanten Wartungszeitpunkt auswählen.

Wenn Sie die Wartung verschieben, gelten die folgenden Einschränkungen:

  • Wenn weniger als eine Stunde bis zur aktuell geplanten Wartungszeit verbleibt, können Sie die Wartung nicht verschieben.
  • Nachdem Sie die Wartung erfolgreich verschoben haben, erhalten Sie von Memorystore for Valkey eine E-Mail-Benachrichtigung, in der die Absage der vorherigen Wartung bestätigt wird. Außerdem erhalten Sie eine neue Wartungsbenachrichtigung mit dem aktualisierten Zeitplan.

Weitere Informationen zum Verschieben von Wartungen finden Sie unter Wartung verschieben.

FAQ

Dieser Abschnitt enthält häufig gestellte Fragen zur Wartung von Memorystore for Valkey.

Wie erfahre ich, wann für meine Instanz eine Wartung geplant ist?

Wenn Sie wissen möchten, wann Wartungsarbeiten für Ihre Instanz geplant sind, empfehlen wir Ihnen, Benachrichtigungen zu abonnieren und ein Wartungsfenster zu konfigurieren. Sie können auch manuell prüfen, ob der Parameter maintenanceSchedule in der Antwort enthalten ist.

Wann werden Sie von Memorystore for Valkey über bevorstehende Wartungen benachrichtigt?

Wenn Sie Wartungsbenachrichtigungen abonnieren und ein Wartungsfenster festlegen, werden Sie mindestens eine Woche vor einem Wartungsereignis per E-Mail von Memorystore for Valkey benachrichtigt.

Wie lange kann ich eine Wartung verschieben?

Nachdem Sie die Wartung für Ihre Instanz geplant haben, können Sie das Update für Ihre Instanz entweder sofort starten oder es um bis zu zwei Wochen nach dem ursprünglich geplanten Wartungstermin verschieben.

Wenn Sie die Wartung beispielsweise für den 11. Oktober um 23:15 Uhr planen, können Sie sie auf den 25. Oktober um 23:15 Uhr verschieben. Wenn Sie nichts unternehmen, wird die Wartung zum geplanten Datum und zur geplanten Uhrzeit ausgeführt.

Weitere Informationen finden Sie unter Wartung verschieben.

Welche Best Practices führen zu einem reibungslosen Wartungsupdate?

Damit Wartungsupdates reibungslos ablaufen, empfehlen wir Folgendes:

  1. Folgen Sie der Anleitung zum Konfigurieren Ihrer Clientanwendung.
  2. Legen Sie das Wartungsfenster auf einen Tag und eine Uhrzeit fest, zu der Ihre Instanz nur minimalen Traffic verarbeitet (z. B. sonntags um Mitternacht).
  3. Aktivieren Sie Wartungsbenachrichtigungen. Daher werden Sie von Memorystore for Valkey mindestens sieben Tage vor einem Wartungsupdate für Ihre Instanz per E-Mail benachrichtigt.
  4. Wenn Sie keine Stunde mit geringer oder keiner Auswirkung für die Nutzung Ihrer Anwendung haben, verwenden Sie die Standardeinstellung des Dienstes für die schrittweise Einführung. Diese Standardeinstellung enthält Best Practices für Wartungsupdates. Weitere Informationen finden Sie unter Transparente Wartung.

Wann können Sie eine Wartung sofort anwenden?

Sie können ein Wartungsupdate sofort auf eine Testinstanz anwenden, um zu sehen, wie sich das Update auf Ihre Anwendung auswirkt. Sie können die Auswirkungen dieser Änderung beobachten. Wenn Probleme mit dem Update auftreten, können Sie die Wartung Ihrer Produktionsinstanzen verschieben, bis Sie die Probleme behoben haben.

Wenn der aktuelle Tag und die aktuelle Uhrzeit für Ihre Instanz passen und Sie in Zukunft eine hohe Last auf Ihrer Instanz erwarten, können Sie das Wartungsupdate sofort ausführen.

Werden Wartungsupdates immer innerhalb des Wartungsfensters abgeschlossen?

Memorystore for Valkey startet ein Wartungsupdate innerhalb des von Ihnen angegebenen Wartungsfensters. Memorystore for Valkey schließt das Update normalerweise innerhalb des Zeitfensters ab, aber das ist nicht immer der Fall.

Kann ich Wartungen deaktivieren oder zuerst Wartungen für bestimmte Instanzen planen?

Sie können Wartungen für Ihre Instanzen nicht deaktivieren und die Reihenfolge der Wartungen nicht steuern. Nachdem Sie die erste Wartungsbenachrichtigung erhalten haben, können Sie die Wartung um bis zu zwei Wochen verschieben.

Nächste Schritte

  • Sehen Sie sich die Berechtigungen an, die zum Verwalten von Wartungsfenstern für Ihre Instanz erforderlich sind.