Freigeben über

Failover und Patching für Azure Cache für Redis

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

Von Bedeutung

Azure Cache for Redis hat den Auslaufzeitplan für alle SKUs angekündigt. Es wird empfohlen, Ihren vorhandenen Azure-Cache für Redis-Instanzen in Azure Managed Redis zu verschieben, sobald Möglich.

Weitere Informationen zur Einstellung finden Sie unter:

Um robuste und erfolgreiche Clientanwendungen zu erstellen, ist es wichtig, das Failover im Azure-Cache für Redis-Dienst zu verstehen. Ein Failover kann Teil geplanter Verwaltungsvorgänge sein, oder es kann durch ungeplante Hardware- oder Netzwerkfehler verursacht werden. Ein Cachefailover erfolgt häufig, wenn der Verwaltungsdienst die Azure Cache for Redis-Binärdateien patcht.

In diesem Artikel finden Sie diese Informationen:

  • Was ist ein Failover?
  • Wie Failover während des Patchings auftritt.
  • So erstellen Sie eine robuste Clientanwendung.

Was ist ein Failover?

Beginnen wir mit einer Übersicht über das Failover für Azure Cache für Redis.

Eine kurze Zusammenfassung der Cachearchitektur

Ein Cache wird von mehreren virtuellen Computern mit separaten und privaten IP-Adressen erstellt. Jede virtuelle Maschine, auch als Knoten bezeichnet, ist mit einem gemeinsamen Lastverteiler mit einer einzigen virtuellen IP-Adresse verbunden. Jeder Knoten führt den Redis-Serverprozess aus und kann mit dem Hostnamen und den Redis-Ports zugegriffen werden. Jeder Knoten wird entweder als primärer knoten oder als Replikatknoten betrachtet. Wenn eine Clientanwendung eine Verbindung mit einem Cache herstellt, durchläuft der Datenverkehr dieses Lastenausgleichsmodul und wird automatisch an den primären Knoten weitergeleitet.

In einem Einfachen Cache ist der einzelne Knoten immer ein primärer Knoten. In einem Standard- oder Premium-Cache gibt es zwei Knoten: eine wird als primär ausgewählt, und das andere ist das Replikat. Da Standard- und Premium-Caches mehrere Knoten aufweisen, ist möglicherweise ein Knoten nicht verfügbar, während die andere weiterhin Anforderungen verarbeitet. Gruppierte Caches bestehen aus vielen Shards, jeweils mit unterschiedlichen primären und Replikatknoten. Ein Shard kann ausgefallen sein, während die anderen verfügbar bleiben.

Hinweis

Ein Einfacher Cache verfügt nicht über mehrere Knoten und bietet keinen Sla (Service Level Agreement) für seine Verfügbarkeit an. Grundlegende Caches werden nur für Entwicklungs- und Testzwecke empfohlen. Verwenden Sie einen Standard- oder Premium-Cache für eine Bereitstellung mit mehreren Knoten, um die Verfügbarkeit zu erhöhen.

Erläuterung eines Failovers

Ein Failover tritt auf, wenn ein Replikatknoten sich selbst zu einem primären Knoten macht und der alte primäre Knoten vorhandene Verbindungen schließt. Nachdem der primäre Knoten wieder verfügbar ist, erkennt er den Rollenwechsel und stuft sich selbst zum Replikatknoten herab. Anschließend wird eine Verbindung mit den neuen primären Daten hergestellt und synchronisiert. Ein Failover kann geplant oder ungeplant sein.

Ein geplantes Failover findet in zwei verschiedenen Zeiten statt:

  • Systemupdates, z. B. Redis-Patching oder Betriebssystemupgrades.
  • Verwaltungsvorgänge, z. B. Skalierung und Neustart.

Da die Knoten vorab über das Update benachrichtigt werden, können sie Rollen kooperativ austauschen und das Lastenausgleichsmodul der Änderung schnell aktualisieren. Ein geplantes Failover endet in der Regel in weniger als 1 Sekunde.

Ein ungeplantes Failover kann aufgrund von Hardwarefehlern, Netzwerkfehlern oder anderen unerwarteten Ausfallen am primären Knoten auftreten. Der Replikatknoten fördert sich selbst in den primären Bereich, aber der Prozess dauert länger. Ein Replikatknoten muss zuerst erkennen, dass sein primärer Knoten nicht verfügbar ist, bevor er den Failoverprozess starten kann. Der Replikatknoten muss auch überprüfen, ob dieser ungeplante Fehler nicht vorübergehend oder lokal ist, um ein unnötiges Failover zu vermeiden. Diese Verzögerung bei der Erkennung bedeutet, dass ein ungeplantes Failover in der Regel innerhalb von 10 bis 15 Sekunden endet.

Wie erfolgt das Patchen?

Der Azure-Cache für Redis-Dienst aktualisiert Ihren Cache regelmäßig mit den neuesten Plattformfeatures und -fixes. Um einen Cache zu patchen, führt der Dienst die folgenden Schritte aus:

  1. Der Dienst aktualisiert zuerst den Replikatknoten.
  2. Das gepatchte Replikat stuft sich selbst kooperativ zum primären Replikat höher. Diese Höherstufung gilt als geplantes Failover.
  3. Der frühere primäre Knoten startet neu, um die neuen Änderungen zu übernehmen und wird als Replikatknoten wieder angezeigt.
  4. Der Replikatknoten stellt eine Verbindung mit dem primären Knoten und synchronisiert Daten.
  5. Wenn die Datensynchronisierung abgeschlossen ist, wird der Patchvorgang für die verbleibenden Knoten wiederholt.

Da das Patchen ein geplanter Failovervorgang ist, stuft sich der Replikatknoten schnell selbst hoch, um zum primären Knoten zu werden. Dann beginnt der Knoten, Anfragen zu bearbeiten und neue Verbindungen herzustellen. Grundlegende Caches verfügen nicht über einen Replikatknoten und sind erst verfügbar, wenn das Update abgeschlossen ist. Jeder Shard eines gruppierten Caches wird separat gepatcht und schließt keine Verbindungen mit einem anderen Shard.

Von Bedeutung

Knoten werden einzeln gepatcht, um Datenverluste zu verhindern. Grundlegende Caches haben Datenverlust. Bei gruppierten Caches werden die Shards jeweils einzeln gepatcht.

Mehrere Caches in derselben Ressourcengruppe und -region werden gleichzeitig gepatcht. Caches, die sich in verschiedenen Ressourcengruppen oder verschiedenen Regionen befinden, können gleichzeitig gepatcht werden.

Da die vollständige Datensynchronisierung erfolgt, bevor der Prozess wiederholt wird, ist der Datenverlust unwahrscheinlich, wenn Sie einen Standard- oder Premium-Cache verwenden. Sie können den Schutz vor Datenverlust weiter schützen, indem Sie Daten exportieren und Persistenz ermöglichen.

Zusätzliches Laden des Caches

Wenn ein Failover auftritt, müssen die Standard- und Premium-Caches Daten von einem Knoten auf den anderen replizieren. Diese Replikation führt zu einer Laststeigerung sowohl im Serverspeicher als auch in der CPU. Wenn die Cacheinstanz bereits stark geladen ist, können Clientanwendungen eine höhere Latenz aufweisen. In extremen Fällen könnten Clientanwendungen Timeout-Ausnahmen erhalten. Konfigurieren Sie die Einstellung des Caches maxmemory-reserved , um die Auswirkungen von mehr Last zu verringern.

Wie wirkt sich ein Failover auf meine Clientanwendung aus?

Clientanwendungen können einige Fehler von ihrer Azure Cache For Redis-Anwendung erhalten. Die Anzahl der Fehler, die eine Clientanwendung verzeichnet, hängt davon ab, wie viele Vorgänge zum Zeitpunkt des Failovers in dieser Verbindung ausstanden. Jede Verbindung, die über den Knoten geleitet wird, der seine Verbindungen geschlossen hat, verursacht Fehler.

Viele Clientbibliotheken können verschiedene Arten von Fehlern auslösen, wenn Verbindungen unterbrechen, einschließlich:

  • Time-Out-Ausnahmen
  • Verbindungsausnahmen
  • Socket-Ausnahmen

Die Anzahl und der Typ von Ausnahmen hängen davon ab, wo sich die Anforderung im Codepfad befindet, wenn der Cache seine Verbindungen schließt. Beispielsweise kann ein Vorgang, der eine Anforderung sendet, aber keine Antwort erhalten hat, wenn das Failover auftritt, eine Timeoutausnahme erhalten. Neue Anforderungen am geschlossenen Verbindungsobjekt führen zu Verbindungsausnahmen, bis die Verbindung erfolgreich wiederhergestellt wird.

Die meisten Clientbibliotheken versuchen, eine erneute Verbindung mit dem Cache herzustellen, wenn sie dafür konfiguriert sind. Unvorhergesehene Fehler können jedoch gelegentlich die Bibliotheksobjekte in einen nicht behebbaren Zustand versetzen. Wenn Fehler länger als eine vorkonfigurierte Zeitspanne beibehalten werden, sollte das Verbindungsobjekt neu erstellt werden. In Microsoft.NET und anderen objektorientierten Sprachen können Sie die Verbindung neu erstellen, ohne die Anwendung neu zu starten, mithilfe eines ForceReconnect-Musters.

Kann ich vor der Wartung benachrichtigt werden?

Azure Cache for Redis veröffentlicht Benachrichtigungen zur Laufzeitwartung auf einem Kanal mit Veröffentlichungs- und Abonnementarchitektur (pub/sub) namens AzureRedisEvents. Viele beliebte Redis-Clientbibliotheken unterstützen das Abonnieren von Pub/Sub-Kanälen. Das Empfangen von Benachrichtigungen vom AzureRedisEvents-Kanal ist in der Regel eine einfache Ergänzung zu Ihrer Client-Anwendung. Weitere Informationen zu Wartungsereignissen finden Sie unter AzureRedisEvents.

Hinweis

Der AzureRedisEvents Kanal ist kein Mechanismus, mit dem Sie Tage oder Stunden im Voraus benachrichtigen können. Der Kanal kann Clients über bevorstehende Serverwartungsereignisse benachrichtigen, die sich auf die Serververfügbarkeit auswirken können. AzureRedisEvents ist nur für die Stufen "Basic", "Standard" und "Premium" verfügbar.

Was sind die Updates, die unter Wartung enthalten sind?

Die Wartung umfasst die folgenden Updates:

  • Redis Server-Updates: Alle Updates oder Patches der Redis-Server-Binärdateien.
  • Updates für virtuelle Computer (VM): Alle Updates des virtuellen Computers, auf dem der Redis-Dienst gehostet wird. VM-Updates umfassen das Patchen von Softwarekomponenten in der Hostingumgebung sowie das Aktualisieren oder Außerbetriebnehmen von Netzwerkkomponenten.

Wird die Wartung im Dienststatus im Azure-Portal vor einem Patch angezeigt?

Nein, Die Wartung wird nicht an irgendeiner Stelle unter dem Dienststatus im Portal oder an einem anderen Ort angezeigt.

Wie viel Zeit im Voraus kann ich eine Benachrichtigung vor der geplanten Wartung erhalten?

Wenn Sie den AzureRedisEvents Kanal verwenden, werden Sie 15 Minuten vor der Wartung benachrichtigt.

Clientnetzwerkkonfigurationsänderungen

Bestimmte clientseitige Änderungen an der Netzwerkkonfiguration können Verbindungsfehler: Keine Verbindung verfügbar auslösen. Solche Änderungen können folgendes umfassen:

  • Wechseln der virtuellen IP-Adresse einer Clientanwendung zwischen Staging- und Produktionsslots.
  • Skalieren der Größe oder Anzahl von Instanzen Ihrer Anwendung.

Solche Änderungen können zu einem Verbindungsproblem führen, das in der Regel weniger als eine Minute dauert. Ihre Clientanwendung verliert wahrscheinlich die Verbindung mit anderen externen Netzwerkressourcen, aber auch mit dem Azure-Cache für Redis-Dienst.

Aufbau von Resilienz

Sie können Failover nicht vollständig vermeiden. Schreiben Sie stattdessen Ihre Clientanwendungen so, dass sie robust gegen Verbindungsabbrüche und fehlgeschlagene Anforderungen sind. Die meisten Clientbibliotheken stellen automatisch eine Erneute Verbindung mit dem Cacheendpunkt her, aber nur wenige versuchen, fehlgeschlagene Anforderungen erneut auszuführen. Je nach Anwendungsszenario kann es sinnvoll sein, die Wiederholungslogik mit Backoff zu verwenden.

Wie kann ich meine Anwendung widerstandsfähig machen?

Die folgenden Entwurfsmustern helfen Ihnen bei der Erstellung robuster Clients. Das gilt insbesondere für die Trennschalter- und Wiederholungsmuster:

Um die Resilienz einer Clientanwendung zu testen, verwenden Sie einen Neustart als manuellen Trigger für Verbindungsunterbrechungen.

Darüber hinaus wird empfohlen, geplante Updates zum Auswählen eines Updatekanals und eines Wartungsfensters für Ihren Cache zu verwenden, um Redis-Laufzeitpatches während bestimmter wöchentlicher Fenster anzuwenden. Bei diesen Fenstern handelt es sich in der Regel um Zeiträume, in denen der Datenverkehr der Clientanwendung niedrig ist, um potenzielle Vorfälle zu vermeiden. Weitere Informationen finden Sie unter "Updatekanal" und "Planen von Updates".

Weitere Informationen finden Sie unter Verbindungsresilienz.

Verwandte Inhalte

  • Last updated on