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 sie keine Ausfallzeiten verursacht.
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:
- 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.
- 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-Topologieaktualisierungslogik 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 Strategie für die schrittweise Bereitstellung und den Lebenszyklus „Erstellen vor dem Löschen“, um Ausfallzeiten aufgrund von Wartungsarbeiten zu vermeiden. Die Wartung ohne Ausfallzeiten wird durch die Verwendung der Anforderungsweiterleitungsfunktionen des OSS Redis-Clusterprotokolls in Verbindung mit den folgenden Memorystore-Mechanismen erreicht:
- Koordinierter Failover ohne Datenverlust.
- Schrittweises Entfernen von Knoten, damit Clients die Cluster-Topologie-Updates ohne Auswirkungen auf die Verfügbarkeit nachholen 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 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 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 Aktualisierungen jeweils nur auf einen kleinen Teil des gesamten Nutzer-Keyspace angewendet werden, wird die Datenverfügbarkeit maximiert.
„Create-before-destroy“-Lebenszyklusstrategie
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:
- 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.
- 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.
- Als Nächstes wird das Replikat entfernt, das die frühere Software verwendet.
- 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 verwendet, um das Replikat zu booten.
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:
- Eingehende Clientanfragen werden auf dem primären Knoten vorübergehend blockiert, sodass das vorhandene Replikat vollständig mit dem primären Knoten synchronisiert werden kann.
- Das Replikat schließt den Auswahlprozess ab, um die primäre Rolle zu übernehmen.
- 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.
- 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 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 abrupte Entfernen eines 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 Knoten hart heruntergefahren wird. Die Topologie wird so angepasst, dass Clients die neue Replikat kennenlernen können. 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. 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.
Sobald ein Wartungsfenster für eine Clusterinstanz konfiguriert ist, wird die zukünftige automatische Wartung gemäß den für Wartungsfenster festgelegten Einstellungen geplant.
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 eine Memorystore for Redis-Clusterinstanz 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]".
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. Die Betreffzeile 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:
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 wir keine Benachrichtigungen an eine andere E‑Mail-Adresse senden.
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 zwei Wochen nach dem ursprünglich geplanten Zeitpunkt beliebig oft verschieben. Beim Verschieben können Sie eine der folgenden Optionen auswählen:
- Jetzt aktualisieren Anstatt auf das geplante Wartungsfenster zu warten, können Sie die Updates sofort auf Ihren Cluster anwenden.
- Tag und Uhrzeit (benutzerdefiniert): So können Sie einen beliebigen spezifischen Zeitpunkt innerhalb von zwei Wochen 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 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
Im Folgenden finden Sie einige häufig gestellte Fragen zur Wartungsrichtlinie für Memorystore for Redis Cluster:
Wie erfahre ich, wann für meinen Cluster eine Wartung geplant ist?
Wir empfehlen, Benachrichtigungen zu abonnieren und ein Wartungsfenster zu konfigurieren, um zu erfahren, wann die Wartung für Ihre Instanz geplant ist. Sie können auch manuell prüfen, ob das Feld maintenance_schedule in der Antwort festgelegt ist. Verwenden Sie dazu Find Scheduled Maintenance.
Wann werde ich über eine bevorstehende Wartung benachrichtigt?
Wenn Sie Wartungsbenachrichtigungen abonniert und ein Wartungsfenster festgelegt haben, werden Sie mindestens eine Woche vor einem Wartungsereignis per E-Mail benachrichtigt.
Wie lange kann ich eine Wartung verschieben?
Sobald die Wartung für Ihren Cluster geplant wurde, können Sie das Update für Ihre Instanz sofort starten oder um bis zu zwei Wochen nach der ursprünglich geplanten Wartung verschieben. Wenn die Wartung beispielsweise für den 11. Oktober um 23:15 Uhr geplant ist, können Sie die Wartung maximal auf den 25. Oktober um 23:15 Uhr verschieben. Wenn Sie keine Aktion ausführen, wird die Wartung zum geplanten Zeitpunkt angewendet.
Weitere Informationen finden Sie unter Wartungen verschieben.
Welche Best Practices sollte ich für ein reibungsloses Wartungsupdate beachten?
Gehen Sie folgendermaßen vor, um für einen reibungslosen Ablauf von Wartungsupdates zu sorgen:
- Folgen Sie der Anleitung zum Konfigurieren Ihrer Clientanwendung.
- Sie sollten das Wartungsfenster so festlegen, dass die Wartung nicht zu Spitzenzeiten der Redis-Nutzung erfolgt.
- Sie sollten Wartungsbenachrichtigungen aktivieren, damit Sie mindestens sieben Tage, bevor ein Wartungsupdate für Ihre Instanz geplant ist, per E-Mail benachrichtigt werden.
- Wenn Sie keine Stunde mit geringer oder keiner Auswirkung für die Nutzung Ihrer Anwendung haben, empfehlen wir, die Standardeinstellung des Dienstes für die schrittweise Einführung zu verwenden, die Best Practices enthält. Weitere Informationen finden Sie unter Transparente Wartung.
Wann sollte ich eine Wartung sofort anwenden?
Ein Szenario, in dem Sie das Wartungsupdate sofort anwenden könnten, ist ein Testcluster. So können Sie sehen, wie sich das Update auf Ihre Anwendung auswirkt. So können Sie die relevanten Auswirkungen beobachten und die Wartung von Produktionsclustern nach Bedarf/Möglichkeit verschieben.
Sie können die Wartung auch sofort planen, wenn die aktuelle Uhrzeit für Ihren Cluster passt und Sie in Zukunft eine hohe Last auf Ihrem Cluster erwarten.
Werden Wartungsupdates immer innerhalb des Wartungsfensters abgeschlossen?
Ein Update beginnt innerhalb des von Ihnen angegebenen Wartungsfensters. Das Update wird normalerweise innerhalb des Fensters abgeschlossen, aber dies kann nicht garantiert werden.
Kann ich Wartungen deaktivieren oder zuerst Wartungen für bestimmte Cluster planen?
Nein, Sie können Wartungen nicht deaktivieren oder die Reihenfolge der Wartung für Ihre Cluster 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 Redis-Cluster erforderlich sind.