Wartung

Auf dieser Seite wird beschrieben, wie Memorystore for Redis Cluster Wartungsarbeiten an Clustern durchführt. Außerdem finden Sie hier 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 Cluster regelmäßig, um sicherzustellen, dass der Dienst zuverlässig, leistungsstark, 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 von Clustern über die von Redis bereitgestellten Eigenschaften hinaus zu verbessern.

Clientanwendung konfigurieren

So konfigurieren Sie Ihre Clientanwendung für die bestmögliche 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 Verbindungsrücksetzungen durch regelmäßige Inline-Topologieaktualisierungen und Hintergrundverbindungsrotationen vermieden werden.
  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 Inline-Aktualisierungslogik für die Topologie auf Clients getestet. Außerdem werden 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 Client 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. Wartung ohne Ausfallzeiten wird durch die Verwendung der Anforderungsweiterleitungsfunktionen des Redis-Protokolls mit den folgenden Memorystore-Mechanismen erreicht:

  1. Koordinierter Failover ohne Datenverlust.
  2. Schrittweises Entfernen von Knoten, damit Clients die Cluster-Topologie aktualisieren können, ohne dass die Verfügbarkeit beeinträchtigt wird.
  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 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 in 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 Fehlerdomäne bzw. Zone aktualisiert, um sicherzustellen, dass ein Cluster-Shard, einschließlich primärer und Replikate, während des gesamten Updates eine hohe Verfügbarkeit aufweist. 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 Aktualisierungen 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 „Erstellen vor dem Löschen“ wird die bereitgestellte Kapazität des Clusters beibehalten. Bei einer typischen Rolling Deployment-Strategie, bei der ein In-Place-Update durchgeführt wird, 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 Replikat-Initialisierung erfolgt mithilfe der replikatlosen Replikation. 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 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: 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 die vorhandene Replikatinstanz 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 Replikat ist, entsperrt 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 Failover sollten in der Regel nur wenige Millisekunden dauern. Die Gesamtgröße Ihres Clusters 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 sich auf die Konvergenz zwischen primären Knoten auswirken, was wiederum die Entscheidungsfindung bei der Auswahl des neuen primären Knotens beeinflusst.

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 plötzliche 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 das neue Replikat erkennen. Die Topologie vergisst auch das Replikat, das entfernt werden soll, 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 beginnt er, die eingehenden Leseanfragen an den primären Knoten seines Shards weiterzuleiten. So kann der 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 Cluster-Topologie 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.

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 06: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 einen Cluster umfasst. Um eine optimale Leistung während der Wartung zu gewährleisten, 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.

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]".

Sie erhalten auch eine Benachrichtigung, 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 diese Schritte mindestens eine Woche vor dem geplanten Wartungsupdate für Ihren Cluster ausführen. Andernfalls hat Memorystore for Redis Cluster nicht genügend Zeit, Sie über die bevorstehende Wartung zu informieren.

Memorystore for Redis Cluster 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. Derzeit ist es nicht möglich, Benachrichtigungen an eine andere E-Mail-Adresse zu senden.

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 für Ihren Cluster Wartungsfenster 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 möglicherweise 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 weniger als eine Stunde bis zur aktuell geplanten Wartungszeit verbleibt, können Sie die Wartung nicht verschieben.
  • Nach einer erfolgreichen Neuplanung 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 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. 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 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.