Wartung

Auf dieser Seite wird beschrieben, wie Memorystore for Valkey Wartungsarbeiten an Instanzen durchführt. Außerdem finden Sie hier Informationen und Konfigurationsempfehlungen, die Ihre Clientanwendungen berücksichtigen müssen, um die Vorteile des Memorystore for Valkey-Designs für die Wartung ohne Ausfallzeiten zu nutzen. 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 sicherzustellen, dass 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 ist so konzipiert, dass keine Ausfallzeiten entstehen.

Wartungsarbeiten fallen 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 überwachen neu identifizierte Sicherheitslücken im Betriebssystem kontinuierlich. 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. Dies geht über das hinaus, was OSS Valkey bietet.

Clientanwendung konfigurieren

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

  1. Verwenden und konfigurieren Sie Ihren Drittanbieter-Client gemäß der Anleitung unter Best Practices für Valkey-Clients, um sicherzustellen, dass geplante Wartungsarbeiten keine Auswirkungen auf die Clientanwendung haben. Mit unseren empfohlenen Clientkonfigurationen können Sie Verbindungsabbrüche durch regelmäßige Inline-Topologieaktualisierungen und Hintergrundverbindungsrotationen vermeiden.
  2. Testen Sie Ihre Clientanwendung mit einer Reihe von Aktualisierungsvorgängen (z. B. Skalierung oder Änderung der Replikatanzahl), während Sie eine repräsentative Arbeitslast auf primären und Replikatknoten ausführen und die Auswirkungen auf den Client überwachen. Mit diesen Updates werden die Logik für die Inline-Topologieaktualisierung auf Clients, die Auswirkungen der 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.

Instanzen mit deaktiviertem Clustermodus

Während der Wartung wird für Instanzen mit deaktiviertem Clustermodus ein Failover durchgeführt, wodurch ihre Verbindungen zurückgesetzt werden. Dieses Failover dauert in der Regel 15 Sekunden. Wenn Sie Ihre Clientanwendungen nach dem Failover wieder mit der Instanz verbinden möchten, empfehlen wir, einen Wiederholungsmechanismus mit exponentiellem Backoff zu erstellen. Nachdem Sie eine E-Mail erhalten haben, in der Sie über eine anstehende Wartung informiert werden, können Sie eine simulierte Wartung auf einer Nicht-Produktionsinstanz ausführen, um die Auswirkungen der Wartung auf die Instanz zu testen. Weitere Informationen finden Sie unter Wartungssimulation auf einer Instanz ausführen.

Wir empfehlen außerdem, den Messwert /instance/memory/maximum_utilization bei Beginn der geplanten Wartung auf 50% oder weniger zu halten. Die Empfehlung für diesen Messwert bezieht sich auf einen Schwellenwert von 80% für die Speicherverwaltung. Wir empfehlen jedoch, während der Wartung ein Verhältnis von 50% oder weniger anzustreben. Weitere Informationen zum Messwert finden Sie unter Cloud Monitoring-Messwerte.

Sie können dieses Verhältnis auf eine der folgenden Arten sicherstellen:

  • Planen Sie Wartungen für Zeiten, in denen der Traffic für die Instanz gering ist.
  • Erhöhen Sie die Größe Ihrer Instanz während des Wartungsfensters vorübergehend.

Planmäßige Wartung

Memorystore for Valkey nutzt eine Lebenszyklusstrategie mit schrittweiser Bereitstellung, bei der alte Versionen erst gelöscht werden, nachdem neue erstellt wurden (Create-before-destroy). So lassen sich Ausfallzeiten aufgrund von geplanten Wartungen von Memorystore für Ihre Valkey-Instanzen vermeiden. Memorystore for Valkey erreicht eine Wartung ohne Ausfallzeiten, indem die Anfrageweiterleitungsfunktionen 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 Aktualisierungen der Knotentopologie ohne Auswirkungen auf die Verfügbarkeit nachvollziehen können.
  3. Die Private Service Connect-Endpunkte der Instanz, die von der Wartung nicht betroffen sind. Weitere Informationen zu diesen Endpunkten finden Sie unter Instanzendpunkte.

Das in den folgenden Abschnitten beschriebene Dienstverhalten gilt nur für geplante Wartungen. Weitere Informationen zu den Auswirkungen ungeplanter Ereignisse wie Hardwarefehler finden Sie unter Clientverhalten während eines ungeplanten Failovers.

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 für die schrittweise Bereitstellung

Memorystore for Valkey führt Bereitstellungen mit einem schrittweise zunehmenden Umfang und in einem Tempo durch, das eine frühzeitige Fehlererkennung ermöglicht, um die 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 fortgesetzt wird) sind in der gesamten Memorystore-Instanzflotte auf Dienstebene integriert. Außerdem werden die Bake-Zeiten in Instanzen über Zonen in einer Region (mehrere Fehlerdomains) hinweg integriert, um die Auswirkungen zu reduzieren.

Bei einer für Hochverfügbarkeit konfigurierten Instanz aktualisiert Memorystore for Valkey jeweils höchstens eine Fehlerdomain oder Zone, um sicherzustellen, dass ein Instanz-Shard, einschließlich primärer Instanz und Replikate, während des gesamten Updates hochverfügbar ist. Außerdem aktualisiert Memorystore for Valkey immer nur wenige Knoten gleichzeitig. Bei Updates wird ein Lebenszyklusmechanismus vom Typ „Erstellen vor Löschen“ 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-Schlüsselbereichs angewendet werden, 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 mehr Replikatknoten. Memorystore verwendet den folgenden Prozess, um vorhandene primäre 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, wenn ein unerwarteter Bootstrap-Fehler auftritt.
  2. Wenn ein Knoten innerhalb des zu aktualisierenden Shards ein primärer Knoten ist, wird er zuerst in ein Replikat umgewandelt, bevor er mithilfe eines koordinierten Failovers 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 Löschen“ wird die bereitgestellte Kapazität der Instanz beibehalten, im Gegensatz zu einer typischen Rolling Deployment, bei der die Aktualisierung direkt erfolgt, was jedoch zu einem Verfügbarkeitsausfall (und manchmal zu Datenverlust) 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: 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 Replikat-Bootstrapping-Funktion wird mithilfe der festplattenlosen Replikation ausgeführt. Memorystore for Valkey unterstützt die laufwerkslose Replikation. Wenn Sie die Persistenz nicht aktivieren, verwendet Memorystore for Valkey während der Replikation keine Laufwerke.

Sie können die horizontale Skalierungsarchitektur 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 kleineres Dataset 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: Koordiniertes primäres Failover ausführen

Wenn der zu aktualisierende Valkey-Knoten ein primärer Knoten ist, führt Memorystore ein koordiniertes Failover auf den neu hinzugefügten Replikatknoten aus. Anschließend entfernt Memorystore 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 zu 100% 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 vorherige primäre Knoten, der jetzt ein Replikatknoten ist, hebt die Blockierung der vorhandenen Anfragen auf und leitet die Anfragen 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. Sie lernt die Adresse des neuen primären Endpunkts und benötigt keine Weiterleitungen mehr.

Koordinierte Failover dauern in der Regel einige Millisekunden. In-Flight-Daten, die noch auf Replikate übertragen werden müssen, und die Gesamtgröße der Instanz können jedoch die Failover-Latenz erhöhen. Die Instanzgröße kann sich auf die Konvergenz zwischen primären Knoten auswirken, was wiederum die Entscheidungsfindung bei der Wahl des neuen primären Knotens beeinflusst.

Schritt 3: Replikat entfernen

Der letzte Schritt des „Create-before-destroy“-Mechanismus besteht darin, den Replikatknoten in der früheren Software zu entfernen. Das Entfernen von Knoten wirkt sich auf Clientanwendungen aus, da Memorystore for Valkey die Clients trennt. Da die Topologieaktualisierung für Instanzen mit deaktiviertem Clustermodus nicht anwendbar ist, empfehlen wir, einen Wiederholungsmechanismus mit exponentiellem Backoff zu verwenden, um Ihre Anwendung wieder mit den neuen Replikatendpunkten zu verbinden, sobald sie verfügbar sind.

Bei Instanzen mit aktiviertem Clustermodus ist das Entfernen eines Valkey-Replikats in Memorystore for Valkey so konzipiert, dass Clientanwendungen ihre Topologie aktualisieren können, bevor ein harter Knoten-Shutdown erfolgt. Die Topologie wird so angepasst, dass Clients das neue Replikat kennenlernen, aber auch das zu entfernende Replikat im Voraus vergessen können.

Memorystore for Valkey behält den Replikatknoten, auf dem die frühere Software ausgeführt wird, für einen bestimmten Zeitraum bei, in der Regel im Bereich von Minuten. Während dieser Zeit werden die eingehenden Leseanfragen an den primären Knoten des Shards weitergeleitet. Dadurch kann der Drittanbieter-Client die Knotentopologie aktualisieren und die neuen Replikatendpunkte ermitteln. Wenn der Client versucht, nach dem Ablaufzeitraum einen entfernten Knoten zu erreichen, schlägt der Versuch fehl. Dieser Fehler löst eine Aktualisierung der Knotentopologie auf dem verbindenden Client aus, damit 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 Wartungsplä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 durchgeführt wird
  • 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 Zeitfenster hinausgehen.

Nachdem Sie ein Wartungsfenster für eine Instanz konfiguriert haben, plant Memorystore for Valkey die automatische Wartung in der Zukunft 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 Einkaufswagenservice bei einem Einzelhändler verwaltet, betreuen Sie eine Produktionsumgebung, die eine Memorystore for Valkey-Instanz enthält. Um eine optimale Leistung während der Wartung zu gewährleisten, sollten Sie sie für einen Zeitraum planen, in dem die Instanz nur minimalen Traffic hat. Dies geschieht in der Regel sonntags gegen Mitternacht.

Legen Sie in diesem Fall das Wartungsfenster Ihrer Produktionsinstanz auf den folgenden Tag und die folgende Uhrzeit fest:

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

Benachrichtigungen über anstehende Wartungen

Damit Sie über Wartungsereignisse auf Ihrer Instanz informiert bleiben, richten Sie mindestens eine Woche vor der geplanten Wartung E-Mail-Benachrichtigungen über anstehende Wartungen ein. 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. Die Betreffzeile der E‑Mail lautet "Maintenance is undergoing for your Cloud Memorystore instance [your-instance-name]".

Nach Abschluss der Wartung sendet Memorystore for Valkey eine Benachrichtigung über den Abschluss. Die Betreffzeile 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 abgebrochene 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 diese aktivieren. So registrieren Sie sich für Wartungsbenachrichtigungen:

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

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 unterstützen wir das Senden von Benachrichtigungen an eine andere E-Mail-Adresse nicht.

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 einer geplanten Wartung finden Sie unter Geplante Wartung finden.

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, können 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 Neuplanung 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: Wählen Sie einen beliebigen Zeitpunkt innerhalb von 14 Tagen nach dem ursprünglich geplanten Wartungszeitpunkt aus.

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

  • Wenn bis zum aktuell geplanten Wartungszeitpunkt weniger als eine Stunde verbleibt, können Sie die Wartung nicht verschieben.
  • Nachdem Sie die Wartung erfolgreich verschoben haben, sendet Memorystore for Valkey Ihnen eine E-Mail-Benachrichtigung, in der die Stornierung 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.

Woher weiß ich, wann eine Wartung für meine Instanz geplant ist?

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

Wann werden Sie von Memorystore for Valkey über anstehende Wartungsarbeiten benachrichtigt?

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

Wie lange kann ich die 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 das Update um bis zu zwei Wochen ab dem ursprünglich geplanten Wartungsdatum und der ursprünglich geplanten Wartungszeit verschieben.

Wenn Sie beispielsweise eine Wartung für den 11. Oktober um 23:15 Uhr planen, können Sie die Wartung bis zum 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 sorgen für einen reibungslosen Ablauf von Wartungsupdates?

Damit das Wartungsupdate reibungslos verläuft, empfehlen wir Folgendes:

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

Wann empfehlen wir, ein Wartungsupdate sofort zu installieren?

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 dieses Updates beobachten. Wenn Probleme mit dem Update auftreten, können Sie die Wartung Ihrer Produktionsinstanzen verschieben, bis die Probleme behoben sind.

Wenn der aktuelle Tag und die aktuelle Uhrzeit für Ihre Instanz geeignet sind 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 in der Regel innerhalb des Zeitfensters ab, aber das ist nicht immer der Fall.

Können Sie die Wartung deaktivieren oder die Wartung für bestimmte Instanzen zuerst planen?

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

Nächste Schritte

  • Sehen Sie sich die Berechtigungen an, die Sie zum Verwalten von Wartungsfenstern für Ihre Instanz benötigen.