Auf dieser Seite wird erläutert, 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 Vorteile des Wartungsdesigns von Memorystore for Redis Cluster ohne Ausfallzeiten zu nutzen. 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 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 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 kontinuierlich neu identifizierte Sicherheitslücken im Betriebssystem. Sobald wir eine Sicherheitslücke entdecken, 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ässigkeitsmerkmale für Cluster über das hinaus zu verbessern, was Redis bietet.
Memorystore for Redis Cluster aktualisiert Cluster nicht automatisch für jedes Wartungsrelease. Um den besten Zeitpunkt für die Planung einer umfassenden Wartung zu ermitteln, wertet Google Cloud regelmäßig verfügbare Updates aus. Wenn Sie eine bestimmte Wartungsversion früher benötigen, können Sie die Self-Service-Wartung verwenden, sobald ein Update verfügbar ist. Weitere Informationen zu Wartungsversionen, einschließlich der Nummern und Details der Wartungsversionen, finden Sie in den Änderungslogs für die Memorystore for Redis Cluster-Wartung.
Clientanwendung konfigurieren
So konfigurieren Sie Ihre Clientanwendung für die bestmögliche Leistung und Verfügbarkeit während der Wartung:
- Verwenden und konfigurieren Sie Ihren OSS-Redis-Cluster-Client gemäß den Best Practices für Redis-Clients, um sicherzustellen, dass geplante Wartungsarbeiten keine Auswirkungen auf Ihre Clientanwendung haben. Mit unseren empfohlenen Clientkonfigurationen können Sie Verbindungsabbrüche durch regelmäßige Inline-Topologieaktualisierungen und Hintergrundverbindungsrotationen vermeiden.
- Testen Sie Ihre Clientanwendung mit einer Reihe von Aktualisierungsvorgängen (z. B. Skalierung, Ä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 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 dann gelöscht werden, nachdem neue erstellt wurden. So lassen sich Ausfallzeiten aufgrund von Wartungen vermeiden. Die Wartung ohne Ausfallzeiten wird durch die Anfrageumleitungsfunktionen des Redis-Protokolls mit den folgenden Memorystore-Mechanismen erreicht:
- Koordiniertes Failover ohne Datenverlust.
- Ordnungsgemäßes Entfernen von Knoten, damit Clients die Aktualisierungen der Clustertopologie ohne Auswirkungen auf die Verfügbarkeit nachvollziehen können.
- 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 Wartungen. Informationen zu den Auswirkungen ungeplanter Ereignisse wie Hardwarefehler finden Sie unter Clientverhalten während eines ungeplanten Failovers.
Strategie für die schrittweise Bereitstellung
Wartungsbereitstellungen für Memorystore for Redis Cluster werden mit schrittweise zunehmendem Umfang und in einer Geschwindigkeit durchgeführt, die eine frühzeitige Fehlererkennung ermöglicht, um die Auswirkungen zu minimieren und die Stabilität zu gewährleisten. Bake-Zeiten (Zeit, in der das Update angewendet und überwacht wird, bevor es als erfolgreich gilt und fortgesetzt wird) sind in der gesamten Memorystore-Clusterflotte auf Dienstebene integriert. Darüber hinaus sind Bake-Zeiten im Cluster über Zonen in einer Region (mehrere Fehlerdomains) hinweg integriert, um die Auswirkungen zu reduzieren.
Bei einem Cluster, der für Hochverfügbarkeit konfiguriert ist, wird jeweils höchstens eine Fehlerdomain/Zone aktualisiert, um sicherzustellen, dass ein Cluster-Shard, einschließlich Primär- und Replikatinstanzen, während des gesamten Updates hochverfügbar ist. Außerdem werden jeweils nur wenige Redis-Knoten aktualisiert. Bei Updates wird ein Lebenszyklusmechanismus verwendet, bei dem alte Versionen erst dann gelöscht werden, nachdem neue erstellt wurden. So wird die Clusterstabilität maximiert. 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-Schlüsselraums angewendet werden, wird die Datenverfügbarkeit maximiert.
Lebenszyklusstrategie „Erstellen vor Löschen“
Ein Redis-Cluster 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-Redis-Knoten in einem Shard zu aktualisieren:
- Memorystore for Redis Cluster fügt dem Shard zuerst ein vollständig neues Replikat mit dem neuesten Softwareupdate hinzu. 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 beibehalten wird.
- Wenn ein Knoten innerhalb des zu aktualisierenden Shards ein primärer Knoten ist, wird er vor dem Entfernen mithilfe eines koordinierten Failovers in ein Replikat umgewandelt.
- Als Nächstes entfernt Memorystore das Replikat, das die frühere Software verwendet.
- Der Vorgang wird für jeden Knoten im Cluster wiederholt.
Die Strategie „Erstellen vor Löschen“ hilft, die bereitgestellte Kapazität des Clusters beizubehalten, im Vergleich zu einer typischen Rolling Deployment, die direkt aktualisiert wird, aber zu einem Verfügbarkeitsausfall (und manchmal Datenverlust) für die Clientanwendung führt. 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 laufwerkslose Replikation zum Bootstrapping des Replikats verwendet. Memorystore for Redis Cluster unterstützt die festplattenlose Replikation. Wenn Sie die Persistenz nicht aktivieren, verwendet Memorystore for Redis Cluster während der Replikation keine Laufwerke.
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 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: Koordinierter primärer 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:
- 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.
- Das Replikat schließt den Auswahlprozess ab, um die primäre Rolle zu übernehmen.
- Der vorherige primäre Knoten, der jetzt ein Replikat ist, hebt die Blockierung der vorhandenen Anfragen auf 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.
- Ihr Redis-Cluster-kompatibler Client aktualisiert seine In-Memory-Topologie. Sie lernt die Adresse des neuen primären Endpunkts und benötigt keine Weiterleitungen mehr.
Koordinierte Failover sollten in der Regel einige Millisekunden dauern. Die Gesamtgröße des Clusters kann jedoch die Failover-Latenz erhöhen. Das gilt auch für Daten, die noch an Replikate übertragen 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 in der früheren Software zu entfernen. Ein abruptes Entfernen von Knoten würde sich auf Clientanwendungen auswirken, da Clients die Endpunktinformationen und die Clustertopologie im Cache speichern. Memorystore for Redis Cluster wurde so konzipiert, dass das Entfernen eines Redis-Replikats ordnungsgemäß erfolgt, damit Clientanwendungen ihre Topologie aktualisieren können, bevor ein harter Knoten-Shutdown erfolgt. Die Topologie wird angepasst, damit Clients das neue Replikat erkennen können. Die Topologie vergisst auch das Replikat, das entfernt wird, bevor es entfernt wird.
Der Replikatknoten, auf dem die frühere Software ausgeführt wird, wird für einen bestimmten Zeitraum (in der Regel einige Minuten) beibehalten. Während dieser Zeit werden die eingehenden Leseanfragen an den primären Knoten des Shards weitergeleitet. Der Clusterclient kann so die Clustertopologie aktualisieren und die neuen Replikatendpunkte ermitteln. Wenn der Client nach dem Drain-Zeitraum versucht, einen entfernten Knoten zu erreichen, schlägt der Versuch fehl. Dadurch wird eine Aktualisierung der Clustertopologie auf dem Clusterclient ausgelöst, sodass er über die Replikatänderung informiert wird. Bei neuen Aktualisierungen der Clustertopologie wird der zu entfernende Replikatknoten nicht mehr angezeigt.
Wartungseinstellungen
Mit Memorystore können Sie Wartungsplä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 ermöglichen 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 1 Stunde. Beachten Sie, dass die Wartung in einigen Fällen über das von Ihnen ausgewählte Zeitfenster hinausgehen kann.
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
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, sind Sie für die Überwachung einer Produktionsumgebung verantwortlich, die einen Cluster enthält. Um eine optimale Leistung während der Wartung zu gewährleisten, möchten Sie sie zu einem Zeitpunkt planen, zu dem der Cluster minimalen Traffic hat. Das ist normalerweise sonntags gegen Mitternacht der Fall.
In diesem Fall können Sie das Wartungsfenster des Produktionsclusters so 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 zu anstehenden Wartungen einrichten, die mindestens eine Woche vor dem geplanten Termin gesendet werden. Diese Benachrichtigungen haben die Betreffzeile "Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]".
Eine Benachrichtigung wird auch 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 abgebrochene Wartung informiert werden. Die Betreffzeile dieser E-Mail lautet "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]".
Sie müssen sich anmelden, um diese Wartungsbenachrichtigungen zu erhalten. So registrieren Sie sich für 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 anstehende Wartung zu benachrichtigen.
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 geplanter Wartungen finden Sie unter Geplante Wartungen finden.
Wartung verschieben
In diesem Abschnitt finden Sie Richtlinien zum Verschieben von Wartungsarbeiten, wenn Wartungsfenster für Ihren Cluster konfiguriert sind. Wenn Sie z. B. während des aktuellen Wartungsfensters einen neuen Dienst starten, sollten Sie das Wartungsfenster so verschieben, dass die Wartung einige Tage nach dem Start stattfindet.
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 Ihren Cluster anwenden.
- Benutzerdefinierter Tag und benutzerdefinierte Uhrzeit: Wählen Sie einen beliebigen Zeitpunkt innerhalb von 14 Tagen nach dem ursprünglich geplanten Wartungszeitpunkt aus.
Beim Verschieben von Wartungsarbeiten gelten die folgenden Einschränkungen:
- Wenn bis zum aktuell geplanten Wartungszeitpunkt weniger als eine Stunde verbleibt, können Sie die Wartung nicht verschieben.
- Nach erfolgreicher Terminverschiebung 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 der Wartung finden Sie unter Wartung verschieben.
FAQ
Dieser Abschnitt enthält häufig gestellte Fragen (FAQs) zur Wartung von Memorystore for Redis Cluster.
Woher weiß ich, wann eine Wartung für meinen Cluster geplant ist?
Wenn Sie wissen möchten, wann die Wartung für Ihren Cluster geplant ist, empfehlen wir, Benachrichtigungen zu abonnieren und ein Wartungsfenster zu konfigurieren. Sie können Ihren Cluster auch manuell prüfen, um festzustellen, ob der Parameter maintenanceSchedule in der Antwort angezeigt wird.
Wann werden Sie von Memorystore for Redis Cluster über anstehende 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 können Sie die 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 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 ein reibungsloses Wartungsupdate?
Damit das Wartungsupdate reibungslos verläuft, empfehlen wir Folgendes:
- Folgen Sie der Anleitung zum Konfigurieren Ihrer Clientanwendung.
- Legen Sie das Wartungsfenster auf einen Tag und eine Uhrzeit fest, an dem der Traffic im Cluster minimal ist (z. B. sonntags um Mitternacht).
- 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.
- 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 Geplante Wartung.
Wann empfehlen wir, ein Wartungsupdate sofort zu installieren?
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 dieses Updates beobachten. Wenn Probleme mit dem Update auftreten, können Sie die Wartung Ihrer Produktionscluster verschieben, bis die Probleme behoben sind.
Wenn der aktuelle Tag und die aktuelle Uhrzeit für Ihren Cluster geeignet sind und Sie in Zukunft eine hohe Last auf 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 in der Regel innerhalb des Zeitfensters ab, aber nicht immer.
Können Sie die Wartung deaktivieren oder die Wartung für bestimmte Cluster zuerst planen?
Sie können die Wartung nicht deaktivieren oder die Reihenfolge der Wartung für Ihre Cluster steuern. Nachdem Sie die erste Wartungsbenachrichtigung erhalten haben, können Sie die Wartung jedoch um bis zu zwei Wochen verschieben.
Nächste Schritte
- Sehen Sie sich die Berechtigungen an, die Sie zum Verwalten von Wartungsfenstern für Ihren Cluster benötigen.