Freigeben über

Verwaltungsaufgaben für Azure Cache für Redis

  • Gilt für:: ✅ Azure Cache for Redis

In diesem Artikel werden Aufgaben wie das Neustarten und das Leeren eines Caches und der Updatekanal und das Planen von Updates für Ihre Azure Cache for Redis-Instanzen beschrieben.

Neustart

Wenn Sie die Stufen "Basic", "Standard" oder "Premium" von Azure Cache für Redis verwenden, wird im Ressourcenmenü "Neustart" angezeigt. Verwenden Sie den Neustart , um einen oder mehrere Knoten des Caches neu zu starten. Durch das Neustarten können Sie Ihre Anwendung auf Resilienz testen, wenn ein Cacheknoten nicht erfolgreich ist.

Von Bedeutung

Der Neustart ist noch nicht für die Enterprise-Ebene 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, erfolgt ein Failover des Azure Cache für Redis auf den Replikatknoten und dieser wird zum primären Knoten befördert. 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 Cache for 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.

Von Bedeutung

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 gelöst wird, könnten die Clientverbindungen möglicherweise weiterhin erschöpft bleiben.

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 Stufen "Basic", "Standard" oder "Premium" von Azure Cache für Redis verwenden, sehen Sie im Ressourcenmenü "Daten löschen". Verwenden Sie Flush-Daten , um alle Daten im Cache zu löschen oder zu leeren . Durch Flushen vor Skalierungsvorgängen lässt sich die Zeit bis zum Abschluss des Skalierungsvorgangs im Cache möglicherweise 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.

Von Bedeutung

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

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

Updatekanal und Planung von Updates

Wenn Sie die Stufen "Basic", "Standard" oder "Premium" von Azure Cache für Redis verwenden, wird im Ressourcenmenü "Updates planen" angezeigt. Verwenden Sie "Planen von Updates", um einen Updatekanal und ein Wartungsfenster für Ihre Cacheinstanz auszuwä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.

Von Bedeutung

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 Cache for Redis bemüht sich am besten, die Aktualisierung der Redis-Serversoftware innerhalb des angegebenen Zeitfensters, das Sie definieren, zu starten und abzuschließen.

Von Bedeutung

Das Updatekanal- und Wartungsfenster gilt für Redis-Serverupdates und -Updates für das Betriebssystem der virtuellen Computer, die den Cache hosten. Das Updatekanal- und Wartungsfenster gilt nicht für Hostbetriebssystemupdates für Hosts, die 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 Gastbetriebssystemupdates. Sie können identifizieren, ob sich Ihr Cache in einem älteren Modell befindet, wenn der DNS-Name des Caches mit einem Suffix von cloudapp.net, chinacloudapp.cn, usgovcloudapi.net oder cloudapi.de endet.

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.

Verwandte Inhalte

Erfahren Sie mehr über Azure Cache for Redis-Features.