Freigeben über

Verwalten von Azure Managed Redis (Vorschau)

  • Artikel

Dieser Artikel beschreibt, wie Verwaltungsaufgaben wie das Neustarten und Kanal aktualisieren und Updates planen für Ihre Azure Managed Redis (Vorschau)-Instanzen durchgeführt werden.

Neustart

Auf der linken Seite können Sie mit Neu starten einen oder mehrere Knoten Ihres Caches neu starten. Mit dieser Neustartfunktion können Sie Ihre Anwendung bei einem Ausfall eines Cacheknotens auf Resilienz testen.

Wichtig

„Neustart“ ist im Enterprise-Tarif noch nicht verfügbar. Für alle anderen Tarife ist „Neustart“ verfügbar.

Screenshot, auf dem die Menüoption „Neustart“ hervorgehoben ist

Wählen Sie die Knoten aus, die neu gestartet werden sollen, und klicken Sie auf Neu starten.

Screenshot: Knoten, die neu gestartet werden können

Wenn Sie über einen Premium-Cache mit aktiviertem Clustering verfügen, können Sie die Shards des Caches auswählen, die neu gestartet werden sollen.

Screenshot der Shardoptionen

Zum Neustarten eines oder mehrerer Knoten Ihres Caches wählen Sie die Knoten aus und klicken auf Neu starten. Wenn Sie über einen Premium-Cache mit aktiviertem Clustering verfügen, wählen Sie die neu zu startenden Shards aus, und wählen Sie dann Neu starten aus. Nach einigen Minuten werden die ausgewählten Knoten neu gestartet, die nur wenige Minuten später wieder online sind.

Die Auswirkungen auf Ihre Clientanwendungen hängen von den Knoten ab, die Sie neu starten.

  • Primär – Wenn der primäre Knoten neu gestartet wird, führt Azure Managed Redis ein Failover auf den Replikatknoten durch und stuft ihn zum primären Knoten hoch. Während dieses Failovers gibt es möglicherweise ein kurzes Intervall, in dem Verbindungsversuche mit dem Cache womöglich fehlschlagen.
  • Replikat: Wenn der Replikatknoten neu gestartet wird, hat dies in der Regel keine Auswirkungen auf Cacheclients.
  • Sowohl primär als auch Replikat – Wenn beide Cacheknoten neu gestartet werden, versucht Azure Managed Redis, beide Knoten ordnungsgemäß neu zu starten und wartet auf den Abschluss eines Knotens, bevor der andere neu gestartet wird. In der Regel tritt kein Datenverlust auf. Dennoch kann es aufgrund unerwarteter Wartungsereignisse oder Fehlern zu Datenverlusten kommen. Wenn Sie Ihren Cache mehrmals hintereinander neu starten, erhöht sich die Wahrscheinlichkeit eines Datenverlusts.
  • Knoten eines Premium-Caches mit aktiviertem Clustering: Wenn Sie einen oder mehrere Knoten eines Premium-Caches mit aktiviertem Clustering neu starten, entspricht das Verhalten für die ausgewählten Knoten dem Neustart des oder der entsprechenden Knoten eines nicht gruppierten Caches.

Häufig gestellte Fragen zum Neustart

Welche Knoten sollte ich neu starten, um meine Anwendung zu testen?

Um die Stabilität Ihrer Anwendung bei Ausfall des primären Knotens Ihres Caches zu testen, starten Sie den primären Knoten neu. Um die Stabilität Ihrer Anwendung bei Ausfall des Replikatknotens zu testen, starten Sie den Replikatknoten neu.

Kann ich den Cache neu starten, um Clientverbindungen zu löschen?

Ja, wenn Sie den Cache neu starten, werden alle Clientverbindungen gelöscht. Ein Neustart kann sinnvoll sein, wenn alle Clientverbindungen aufgrund eines Logikfehlers oder eines Fehlers in der Clientanwendung belegt sind. Jeder Tarif weist verschiedene Grenzwerte für Clientverbindungen für die verschiedenen Größen auf. Sobald diese Grenzwerte erreicht sind, werden keine weiteren Clientverbindungen akzeptiert. Das Neustarten des Caches bietet eine Möglichkeit, alle Clientverbindungen zu löschen.

Wichtig

Wenn Sie Ihren Cache neu starten, um Clientverbindungen zu löschen, stellt StackExchange.Redis automatisch wieder eine Verbindung her, sobald der Redis-Knoten wieder online ist. Wenn das zugrunde liegende Problem nicht behoben wird, kann es weiterhin passieren, dass die Clientverbindungen aufgebraucht werden.

Gehen beim Neustart Daten aus dem Cache verloren?

Wenn Sie sowohl den primären als auch den Replikatknoten neu starten, können alle Daten im Cache oder im jeweiligen Shard, wenn Sie einen Premium-Cache mit aktiviertem Clustering nutzen, beibehalten werden. Die Daten können jedoch in einigen Fällen verloren gehen. Ein Neustart beider Knoten sollte mit Vorsicht vorgenommen werden.

Wenn Sie nur einen der Knoten neu starten, gehen Daten in der Regel nicht verloren, möglicherweise aber doch. Wenn z. B. der primäre Knoten neu gestartet und ein Cacheschreibvorgang ausgeführt wird, gehen die Daten des Cacheschreibvorgangs verloren. Ein weiteres Szenario für Datenverlust ist der Fall, in dem Sie einen Knoten neu starten und der andere Knoten aufgrund eines Fehlers gleichzeitig ausfällt.

Sie sollten auch wissen, dass das Neustarten beider Knoten nicht dazu führt, dass Daten geleert werden. Wenn Sie Daten löschen möchten, verwenden Sie die Prozedur zum Leeren über die Portalkonsole.

Kann ich meinen Cache mithilfe von PowerShell, CLI oder anderen Verwaltungstools neu starten?

Ja. Anweisungen für PowerShell finden Sie unter So starten Sie einen Azure Cache for Redis neu.

Kann ich meinen Enterprise-Cache neu starten?

Nein. „Neustart“ ist im Enterprise-Tarif noch nicht verfügbar. Der Neustart ist in den Tarifen Basic, Standard und Premium verfügbar. Die Einstellungen, die im Menü „Ressource“ unter Verwaltung angezeigt werden, hängen von der Dienstebene Ihres Caches ab. So wird Neustart z. B. nicht angezeigt, wenn Sie einen Cache mit der Dienstebene „Enterprise“ verwenden.

Daten leeren

Wenn Sie die Tarife Basic, Standard oder Premium von Azure Managed Redis verwenden, wird im Ressourcenmenü die Option Daten leeren angezeigt. Mit dem Vorgang Daten leeren können Sie alle Daten in Ihrem Cache löschen oder leeren. Dieser Leerungsvorgang kann vor Skalierungsvorgängen verwendet werden, um möglicherweise die Zeit zum Abschließen des Skalierungsvorgangs in Ihrem Cache zu verkürzen. Sie können auch konfigurieren, dass der Leerungsvorgang in regelmäßigen Abständen für Ihre Dev/Test-Caches ausgeführt wird, um die Speicherauslastung gering zu halten.

Der Leerungsvorgang löscht bei Ausführung in einem gruppierten Cache Daten aus allen Shards gleichzeitig.

Wichtig

Bisher war der Leerungsvorgang nur für georeplizierte Caches im Enterprise-Tarif verfügbar. Jetzt ist er in den Tarifen Basic, Standard und Premium verfügbar.

Screenshot der ausgewählten Option „Daten leeren“ im Ressourcenmenü einer Cache-Instanz.

Updatekanal und Planen von Updates

Auf der linken Seite können Sie mit Updates planen einen Updatekanal und ein Wartungsfenster für Ihre Cache-Instanz auswählen.

Alle Cache-Instanzen, die den Updatekanal Stabil verwenden, erhalten Updates einige Wochen später als Cache-Instanzen, die den Updatekanal Vorschau verwenden. Es wird empfohlen, den Updatekanal Vorschau für Ihre nicht produktionsbezogenen und weniger kritischen Workloads auszuwählen. Wählen Sie den Updatekanal Stabil für Ihre kritischsten Produktionsworkloads aus. Standardmäßig wird für alle Caches Updatekanal Stabil verwendet.

Wichtig

Das Ändern des Updatekanals für Ihre Cache-Instanz führt dazu, dass der Cache ein Patchereignis durchläuft, um die richtigen Updates anzuwenden. Ziehen Sie in Erwägung, den Updatekanal während des Wartungsfensters zu ändern.

Mithilfe eines Wartungsfensters können Sie die Tage und Uhrzeiten einer Woche steuern, an denen die VMs, auf denen der Cache gehostet wird, aktualisiert werden können. Azure Managed Redis versucht nach Möglichkeit, die Redis-Serversoftware innerhalb des von Ihnen definierten Zeitfensters zu starten und zu beenden.

Wichtig

Der Updatekanal und das Wartungsfenster gelten für Redis-Serverupdates und Updates des Betriebssystems der VMs, die den Cache hosten. Der Updatekanal und das Wartungsfenster gelten nicht für Updates des Hostbetriebssystems auf den Hosts, welche die Cache-VMs oder andere Azure-Netzwerkkomponenten hosten. In seltenen Fällen, in denen Caches auf älteren Modellen gehostet werden, gilt das Wartungsfenster auch nicht für Updates des Gastbetriebssystems. Ihr Cache befindet sich auf einem älteren Modell, wenn der DNS-Name des Caches in eines der Suffixe cloudapp.net, chinacloudapp.cn, usgovcloudapi.net oder cloudapi.de aufgelöst wird.

Derzeit ist keine Option zum Konfigurieren eines Updatekanals oder von geplanten Updates für einen Cache im Enterprise-Tarif verfügbar.

Screenshot mit Zeitplanaktualisierungen

Aktivieren Sie zum Angeben eines Wartungsfensters die Kontrollkästchen der gewünschten Tage, und geben Sie jeweils die Startzeit des Wartungsfensters an. Wählen Sie anschließend OK aus. Die Wartungsfensterzeit ist in UTC und kann nur stundenweise konfiguriert werden.

Das Standardwartungsfenster für Updates beträgt fünf Stunden (Mindestdauer). Der Wert kann nicht über das Azure-Portal konfiguriert werden. Sie können ihn jedoch in PowerShell mithilfe des MaintenanceWindow-Parameters des Cmdlets New-AzRedisCacheScheduleEntry konfigurieren. Weitere Informationen finden Sie unter Kann ich geplante Updates mit PowerShell, der CLI oder anderen Verwaltungstools verwalten?.

Häufig gestellte Fragen zum Planen von Updates

Wann erfolgen Updates, wenn nicht das Feature zum Planen von Updates verwendet wird?

Wenn Sie kein Wartungsfenster angeben, können Updates jederzeit erfolgen.

Welche Art von Updates erfolgen während des geplanten Wartungsfensters?

Nur Updates des Redis-Servers erfolgen während des geplanten Wartungsfensters. Das Wartungsfenster gilt nicht für Azure-Updates oder Aktualisierungen des Host-Betriebssystems.

Kann ich geplante Updates mit PowerShell, der CLI oder anderen Verwaltungstools verwalten?

Ja, Sie können Ihre geplanten Updates mit den folgenden PowerShell-Cmdlets verwalten:

Kann ein Update, das vom Feature „Geplante Updates“ abgedeckt und verwaltet wird, außerhalb des Fensters „Geplante Updates“ erfolgen?

Ja. Im Allgemeinen werden Updates nicht außerhalb des konfigurierten Fensters „Geplante Updates“ angewendet. Seltene kritische Sicherheitsupdates können außerhalb des Patchzeitplans als Teil unserer Sicherheitsrichtlinie angewendet werden.

Zugehöriger Inhalt