Wartung

Auf dieser Seite wird beschrieben, wie Memorystore for Redis Cluster Wartungsarbeiten an Instanzen durchführt. Außerdem enthält es Informationen und Konfigurationsempfehlungen, die Ihre Clientanwendungen berücksichtigen sollten, um die Wartung ohne Ausfallzeiten von Memorystore for Redis Cluster zu nutzen. Diese Empfehlungen gelten sowohl für hochverfügbare Cluster als auch für Cluster ohne Replikate. Wir empfehlen jedoch dringend, die Konfiguration für Hochverfügbarkeit für alle Produktionsanwendungsfälle zu verwenden.

Memorystore for Redis Cluster 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 es zu keinen Ausfallzeiten kommt.

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 Redis-Update umfassen, um die Sicherheits-, Leistungs- und Zuverlässigkeitseigenschaften der Instanz über die von OSS Redis bereitgestellten Eigenschaften hinaus zu verbessern.

Clientanwendung konfigurieren

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

  1. Verwenden und konfigurieren Sie Ihren OSS-Redis-Clusterclient gemäß den Best Practices für Redis-Clients, damit geplante Wartungsarbeiten keine Auswirkungen auf Ihre 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 nach oben oder unten, Änderungen der Anzahl der Replikate), 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 Logik für die Aktualisierung der Inline-Topologie auf Clients, die Auswirkungen der vollständigen Synchronisierung, die Erkennung neuer Knoten und die Möglichkeit zum Entfernen vorhandener Knoten getestet. Tests helfen, sicherzustellen, dass der OSS Redis-Clusterclient richtig konfiguriert ist, um negative Auswirkungen auf Ihre Anwendung zu vermeiden.

Planmäßige Wartung

Memorystore for Redis Cluster nutzt eine Lebenszyklusstrategie mit schrittweiser Bereitstellung, bei der alte Versionen erst gelöscht werden, nachdem neue erstellt wurden. So lassen sich Ausfallzeiten aufgrund von Wartungen vermeiden. Die Wartung ohne Ausfallzeiten wird durch die Verwendung der Anforderungsweiterleitungsfunktionen des OSS Redis-Clusterprotokolls in Verbindung mit den folgenden Memorystore-Mechanismen erreicht:

  1. Koordinierter Failover ohne Datenverlust.
  2. Schrittweises Entfernen von Knoten, damit Clients die Cluster-Topologie-Updates ohne Auswirkungen auf die Verfügbarkeit nachholen können.
  3. Die Private Service Connect-Endpunkte des Clusters sind von Wartungsarbeiten nicht betroffen. Weitere Informationen zu diesen Endpunkten finden Sie unter Clusterendpunkte.

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

Strategie der schrittweisen Bereitstellung

Wartungsbereitstellungen für Memorystore for Redis Cluster werden mit einem schrittweise zunehmenden Umfang und in einer Geschwindigkeit durchgeführt, die eine rechtzeitige Fehlererkennung ermöglicht, um Auswirkungen zu minimieren und die Stabilität zu gewährleisten. Die Bake-Zeiten (Zeit, in der das Update angewendet und überwacht wird, bevor es als erfolgreich gilt und fortgefahren wird) sind über die gesamte Memorystore-Clusterflotte hinweg auf Dienstebene integriert. Außerdem sind die Bake-Zeiten zonenübergreifend in den Cluster in einer Region (mehrere Fehlerdomänen) integriert, um den Umfang der Auswirkungen zu reduzieren.

Bei Clustern, die für Hochverfügbarkeit konfiguriert sind, wird jeweils nur eine Fehlerdomain bzw. Zone aktualisiert. So wird sichergestellt, dass ein Cluster-Shard, einschließlich primärer Instanz und Replikaten, während des gesamten Updates hochverfügbar ist. Außerdem werden jeweils nur wenige Redis-Knoten aktualisiert. Bei Updates wird ein „create-before-destroy“-Lebenszyklusmechanismus verwendet, um die Clusterstabilität zu maximieren. Diese Strategie bietet die meisten Vorteile, wenn Sie einen Cluster mit vielen Shards aktualisieren. Wenn die Updates jeweils nur auf einen kleinen Teil des gesamten Nutzer-Keyspace angewendet werden, wird die Datenverfügbarkeit maximiert.

Lebenszyklusstrategie mit Erstellen vor dem Löschen

Ein Redis-Cluster 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-Redis-Knoten in einem Shard zu aktualisieren:

  1. Bei Memorystore for Redis Cluster wird dem Shard zuerst ein völlig neues Replikat mit dem neuesten Softwareupdate hinzugefügt. Memorystore erstellt einen völlig neuen Knoten, anstatt einen vorhandenen Knoten zu aktualisieren. So wird sichergestellt, dass Ihre bereitgestellte Kapazität im Falle eines unerwarteten Bootstrap-Fehlers erhalten bleibt.
  2. Wenn ein Knoten im zu aktualisierenden Shard ein primärer Knoten ist, wird er vor dem Entfernen mithilfe eines koordinierten Failovers zuerst in ein Replikat konvertiert.
  3. Als Nächstes wird das Replikat entfernt, das die frühere Software verwendet.
  4. Der Vorgang wird für jeden Knoten im Cluster wiederholt.

Mit der Strategie „create-before-destroy“ wird die bereitgestellte Kapazität des Clusters beibehalten. Bei einer typischen Rolling-Bereitstellung, bei der ein In-Place-Update erfolgt, kommt es dagegen zu einem Ausfall der Verfügbarkeit (und manchmal zu Datenverlust) für die Clientanwendung. Bei Shards ohne Replikate stellt Memorystore for Redis Cluster zuerst ein neues Replikat bereit, koordiniert das Failover und ersetzt schließlich den vorhandenen primären Knoten des Shards.

Schritt 1: Redis-Replikat hinzufügen

Im ersten Schritt des Create-before-Destroy-Mechanismus wird ein Replikatknoten mit der neuesten Software hinzugefügt. Dabei wird der OSS-Redis-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 replikatlose Replikation genutzt, um das Replikat zu starten. Memorystore for Redis Cluster unterstützt die replikationslose Replikation. Sofern Sie Persistenz nicht aktivieren, werden in Memorystore for Redis-Clustern während der Replikation keine Festplatten verwendet.

Sie können die horizontale Skalierungsarchitektur des Clusters am besten nutzen, indem Sie eine höhere Anzahl von Shards bereitstellen, um die Keyspace-Größe innerhalb eines Knotens zu verringern. 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: Koordinierte primäre Failover

Wenn der Redis-Knoten, der aktualisiert werden muss, 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 Redis-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 genügend Zeit bleibt, um sicherzustellen, dass das vorhandene Replikat zu 100% mit dem primären Knoten synchronisiert ist.
  2. Das Replikat schließt den Auswahlprozess ab, um die primäre Rolle zu übernehmen.
  3. Der bisherige primäre Knoten, der jetzt ein Replikat ist, entblockiert die vorhandenen Anfragen und leitet sie mithilfe des OSS Redis-Clusterprotokolls an den neu ausgewä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 Redis-Cluster-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 sollten in der Regel nur wenige Millisekunden dauern. Die Gesamtzahl der Knoten in Ihrem Cluster kann jedoch die Failover-Latenz erhöhen. Das gilt auch für Daten, die noch in den Replikaten gespeichert werden müssen. Die Clustergröße kann die Konvergenz zwischen primären Knoten beeinflussen, was sich auf die Entscheidungsfindung bei der Auswahl des neuen primären Knotens auswirkt.

Schritt 3: Redis-Replikat entfernen

Der letzte Schritt des Create-Before-Destroy-Mechanismus besteht darin, den Replikatknoten auf der früheren Software zu entfernen. Das abrupte Entfernen eines Knotens hätte Auswirkungen auf Clientanwendungen, da Clients die Endpunktinformationen und die Clustertopologie im Cache speichern. In Memorystore for Redis Cluster ist das Entfernen eines Redis-Replikats so konzipiert, dass Clientanwendungen ihre Topologie aktualisieren können, bevor ein Knoten hart heruntergefahren wird. Die Topologie wird so angepasst, dass Clients die neue Replikat kennenlernen können. Die Topologie vergisst auch das zu entfernende Replikat, bevor es entfernt wird.

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 leitet er die eingehenden Leseanfragen an den primären Knoten seines Shards weiter. Dadurch kann der OSS Redis-Clusterclient die Clustertopologie aktualisieren und die neuen Replikatendpunkte kennenlernen. Wenn der Client nach dem Drain-Zeitraum versucht, einen entfernten Knoten zu erreichen, schlägt der Versuch fehl. Dies löst wiederum eine Aktualisierung der Clustertopologie auf dem Clusterclient aus, sodass er über die Replikatänderung informiert wird. Bei neuen Aktualisierungen der Clustertopologie wird der zu entfernende Replikatknoten nicht berücksichtigt.

Wartungseinstellungen

Mit Memorystore können Sie Wartungszeitpläne an die Anforderungen Ihrer Anwendung anpassen und Unterbrechungen minimieren. Dazu können Sie ein Wartungsfenster für Ihren Cluster konfigurieren.

Wartungsfenster werden pro Memorystore-Cluster festgelegt und bieten die folgenden Konfigurationsoptionen:

  • Wochentag Gibt den Tag an, an dem die Wartung stattfindet.
  • Startzeit (Stunde). Die Stunde, in der die Wartung beginnt.

Die Dauer des Wartungsfensters beträgt eine Stunde. In einigen Fällen kann es vorkommen, dass die Wartung über das von Ihnen ausgewählte Zeitfenster hinausgeht.

Nachdem Sie ein Wartungsfenster für einen Cluster konfiguriert haben, plant Memorystore for Redis Cluster die automatische Wartung in Zukunft gemäß den von Ihnen festgelegten Einstellungen für Wartungsfenster.

Standardwartungsfenster

Wenn Sie kein Wartungsfenster festlegen, aktualisiert Memorystore Ihren Cluster in einem der folgenden Zeitfenster entsprechend der Zeitzone Ihres Clusters:

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

  • Wochenendzeitraum: 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 die Überwachung einer Produktionsumgebung mit einer Memorystore for Redis Cluster-Instanz verantwortlich. Damit die Leistung während der Wartung optimal ist, möchten Sie sie für einen Zeitpunkt planen, zu dem der Cluster nur minimalen Traffic verarbeitet. Das ist in der Regel sonntags um Mitternacht der Fall.

In diesem Fall können Sie das Wartungsfenster Ihres Produktionsclusters auf Folgendes festlegen:

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

Benachrichtigungen über anstehende Wartungen

Damit Sie über Wartungsereignisse in Ihrem Cluster informiert bleiben, können Sie E-Mail-Benachrichtigungen über bevorstehende Wartungen mindestens eine Woche vor dem geplanten Termin einrichten. Diese Benachrichtigungen haben die Betreffzeile "Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]".

Außerdem wird eine Benachrichtigung gesendet, wenn die Wartung für Ihren Cluster beginnt. Die Betreffzeile der E‑Mail lautet "Maintenance is undergoing for your Cloud Memorystore instance [your-cluster-name]".

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

Wenn Memorystore die Wartung neu plant, 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-cluster-name]".

Sie müssen diese Wartungsbenachrichtigungen aktivieren, um sie zu erhalten. So registrieren Sie sich für Wartungsbenachrichtigungen:

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

Wenn Sie Wartungsbenachrichtigungen von Memorystore erhalten möchten, müssen Sie die oben genannten Schritte mindestens eine Woche vor dem geplanten Wartungsupdate für Ihre Instanz ausführen. Andernfalls hat das System nicht genügend Zeit, Sie über die bevorstehende Wartung zu informieren.

Benachrichtigungen werden an die E‑Mail-Adresse Ihres Google-Kontos gesendet. Ein benutzerdefinierter E-Mail-Alias wie ein Team-E-Mail-Alias kann nicht konfiguriert werden. Derzeit können Benachrichtigungen nicht an eine andere E‑Mail-Adresse gesendet werden.

Wenn Sie Wartungsbenachrichtigungen abonnieren, erhalten Sie Benachrichtigungen für alle Memorystore-Cluster mit geplanter Wartung in einem bestimmten Projekt. Wenn Sie abonniert sind, erhalten Sie für jeden Cluster eine separate Benachrichtigung.

Eine Anleitung zum Aufrufen geplanter Wartungsaufgaben finden Sie unter Geplante Wartung aufrufen.

Wartung verschieben

Wenn Wartungsfenster für Ihren Cluster konfiguriert sind, finden Sie in diesem Abschnitt 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 Ihren Cluster anwenden.
  • Benutzerdefinierter Tag und benutzerdefinierte Uhrzeit: Sie können einen beliebigen Zeitpunkt innerhalb von 14 Tagen nach dem ursprünglich geplanten Wartungszeitpunkt auswählen.

Beim Verschieben von Wartungen gelten die folgenden Einschränkungen:

  • Wenn die aktuell geplante Wartung in weniger als einer Stunde erfolgt, können Sie die Wartung nicht verschieben.
  • Nach einer erfolgreichen Terminänderung wird eine E‑Mail gesendet, in der die Stornierung der vorherigen Wartung bestätigt wird. Außerdem wird eine neue Benachrichtigung über die bevorstehende Wartung mit dem aktualisierten Zeitplan gesendet.

Eine Anleitung zum Verschieben von Wartungen finden Sie unter Wartung verschieben.

FAQ

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

Wie erfahre ich, wann für meinen Cluster eine Wartung geplant ist?

Wenn Sie wissen möchten, wann Wartungsarbeiten für Ihren Cluster geplant sind, empfehlen wir Ihnen, Benachrichtigungen zu abonnieren und ein Wartungsfenster zu konfigurieren. Sie können auch Ihren Cluster manuell prüfen, um zu sehen, ob der Parameter maintenanceSchedule in der Antwort angezeigt wird.

Wann werden Sie von Memorystore for Redis Cluster über bevorstehende Wartungsarbeiten benachrichtigt?

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

Wie lange kann ich eine Wartung verschieben?

Nachdem Sie die Wartung für Ihren Cluster geplant haben, können Sie das Update für Ihren Cluster 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 maximal 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 in Ihrem Cluster nur minimaler Traffic auftritt, z. B. sonntags um Mitternacht.
  3. Aktivieren Sie die Wartungsbenachrichtigungen. Daher werden Sie von Memorystore for Redis Cluster mindestens sieben Tage vor einem geplanten Wartungsupdate für Ihren Cluster 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 empfehlen wir, ein Wartungsupdate sofort anzuwenden?

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

Wenn der aktuelle Tag und die aktuelle Uhrzeit für Ihren Cluster geeignet sind und Sie in Zukunft eine hohe Last in Ihrem Cluster erwarten, können Sie das Wartungsupdate sofort ausführen.

Werden Wartungsupdates immer innerhalb des Wartungsfensters abgeschlossen?

Memorystore for Redis Cluster startet ein Wartungsupdate innerhalb des von Ihnen angegebenen Wartungsfensters. Memorystore for Redis Cluster 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 Cluster planen?

Sie können Wartungen für Ihre Cluster 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 Ihren Cluster erforderlich sind.