Wartung

Auf dieser Seite wird erläutert, wie Wartungsarbeiten an Memorystore for Redis Cluster-Instanzen durchgeführt werden. Außerdem finden Sie Informationen und Konfigurationsempfehlungen, die für Ihre Clientanwendungen wichtig sind, damit Sie die Wartung ohne Ausfallzeiten von Memorystore for Redis Cluster nutzen können. Diese Empfehlungen gelten sowohl für hochverfügbare Cluster als auch für Cluster ohne Replikate. Wir empfehlen jedoch dringend die Hochverfügbarkeitskonfiguration für alle Produktionsanwendungsfälle.

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.
  • Datenbankpatches: 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 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 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. Durch Tests können Sie sicherstellen, 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 der Wartung nicht betroffen. Weitere Informationen zu diesen Endpunkten finden Sie unter Clusterendpunkte.

Das in den folgenden Abschnitten beschriebene Dienstverhalten 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 auf Dienstebene integriert. Außerdem sind die Bake-Zeiten im Cluster über Zonen in einer Region (mehrere Fehlerdomänen) hinweg integriert, um den Umfang der Auswirkungen zu reduzieren.

Bei Ihrem für Hochverfügbarkeit konfigurierten Cluster wird jeweils nur eine Fehlerdomain bzw. ‑zone aktualisiert. So wird sichergestellt, dass ein Cluster-Shard, einschließlich Primär- 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 ein Cluster mit vielen Shards aktualisiert wird. 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. Memorystore for Redis Cluster fügt dem Shard zuerst ein völlig neues Replikat mit dem neuesten Softwareupdate 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 im zu aktualisierenden Shard ein primärer Knoten ist, wird er zuerst mithilfe eines koordinierten Failovers in ein Replikat konvertiert, bevor er entfernt wird.
  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 „Erstellen vor dem Löschen“ wird die bereitgestellte Kapazität des Clusters beibehalten. Bei einem typischen Rolling Deployment, bei dem 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 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 zu aktualisierende Redis-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 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. So bleibt Zeit, 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, gibt die vorhandenen Anfragen frei und leitet sie mithilfe des OSS Redis-Clusterprotokolls an den neu ausgewählten primären Knoten weiter. Alle neuen Anfragen, die an den bisherigen 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 Failover-Latenz kann jedoch durch die Gesamtgröße des Clusters erhöht werden. Das gilt auch für Daten, die noch in Replikaten gespeichert werden müssen. Die Clustergröße kann sich auf die Konvergenz zwischen primären Knoten auswirken, was die Entscheidungsfindung bei der Auswahl des neuen primären Knotens beeinflusst.

Schritt 3: Redis-Replikat entfernen

Im letzten Schritt des „Create-before-destroy“-Mechanismus wird der Replikatknoten auf der früheren Software entfernt. Ein abruptes Entfernen des Knotens hätte Auswirkungen auf Clientanwendungen, da Clients die Endpunktinformationen und die Clustertopologie im Cache speichern. Bei Memorystore for Redis Cluster ist das Entfernen eines Redis-Replikats so konzipiert, dass Clientanwendungen ihre Topologie aktualisieren können, bevor ein harter Knoten heruntergefahren wird. Die Topologie wird so angepasst, dass Clients das neue Replikat kennenlernen können. Außerdem wird das Replikat, das entfernt werden soll, aus der Topologie entfernt, bevor es tatsächlich 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 beginnt er, die eingehenden Leseanfragen an den primären Knoten seines Shards weiterzuleiten. 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.
  • Stunde des Beginns: Die Stunde, in der die Wartung beginnt.

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

Nachdem Sie ein Wartungsfenster für einen Cluster konfiguriert haben, plant Memorystore for Redis Cluster die automatische Wartung in der 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 6:00 Uhr

  • Wochenendzeitfenster: 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 verantwortlich, die eine Memorystore for Redis Cluster-Instanz umfasst. Um eine optimale Leistung während der Wartung zu gewährleisten, möchten Sie sie für einen Zeitpunkt planen, an 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 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 verschiebt, erhalten Sie eine E-Mail, in der Sie über die abgesagte Wartung informiert werden. Die Betreffzeile dieser E-Mail lautet "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]".

Sie müssen diese Wartungsbenachrichtigungen aktivieren. 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 gesendet, die mit Ihrem Google-Konto verknüpft ist. Ein benutzerdefinierter E‑Mail-Alias wie ein Team-E‑Mail-Alias kann nicht konfiguriert werden. Derzeit unterstützen wir nicht das Senden von Benachrichtigungen an eine andere E‑Mail-Adresse.

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

Eine Anleitung zum Suchen nach geplanter Wartung finden Sie unter Geplante Wartung suchen.

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 dazu 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 die Wartung für Ihren Cluster geplant ist, 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 schrittweise Roll-outs. 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 es Probleme mit dem Update gibt, 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. Das Update wird normalerweise innerhalb des Zeitfensters abgeschlossen, aber dies kann nicht garantiert werden.

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

Sie können Wartungen für Ihre Cluster weder deaktivieren noch die Reihenfolge der Wartungen steuern. Nachdem Sie jedoch 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.