Failover und Patching für Azure Cache for Redis

  • Artikel

Zum Erstellen resilienter und erfolgreicher Clientanwendungen ist es wichtig, zu verstehen, wie das Failover für den Azure Cache for Redis-Dienst funktioniert. Ein Failover kann Teil geplanter Verwaltungsvorgänge sein oder durch ungeplante Hardware- oder Netzwerkausfälle verursacht werden. Ein Cachefailover erfolgt häufig, wenn der Verwaltungsdienst die Azure Cache for Redis-Binärdateien patcht.

Im vorliegenden Artikel finden Sie Antworten auf die folgenden Fragen:

  • Was ist ein Failover?
  • Wie erfolgt das Failover während eines Patchvorgangs?
  • Wie erstelle ich eine resiliente Clientanwendung?

Was ist ein Failover?

Wir beginnen mit einer Übersicht über das Failover für Azure Cache for Redis.

Kurze Zusammenfassung der Cachearchitektur

Ein Cache wird aus mehreren virtuellen Computern mit separaten und privaten IP-Adressen erstellt. Jeder virtuelle Computer, der auch als Knoten bezeichnet wird, ist mit einem freigegebenen Load Balancer mit einer einzelnen virtuellen IP-Adresse verbunden. Jeder Knoten führt den Redis-Serverprozess aus, und auf jeden Knoten kann über den Hostnamen und die Redis-Ports zugegriffen werden. Jeder Knoten gilt entweder als primärer oder Replikatknoten. Wenn eine Clientanwendung eine Verbindung mit einem Cache herstellt, durchläuft der zugehörige Datenverkehr diesen Load Balancer und wird automatisch an den primären Knoten weitergeleitet.

In einem Basic-Cache ist der einzelne Knoten immer auch der primäre. Ein Standard- oder Premium-Cache umfasst zwei Knoten: einen ausgewählten primären Knoten und einen Replikatknoten. Da Standard- und Premium-Caches mehrere Knoten umfassen, ist ein Knoten möglicherweise nicht verfügbar, während auf dem anderen weiterhin Anforderungen verarbeitet werden. Gruppierte Caches bestehen aus vielen Shards, die jeweils unterschiedliche primäre und Replikatknoten umfassen. Ein Shard kann ausgefallen sein, während die anderen verfügbar bleiben.

Hinweis

Ein Basic-Cache verfügt nicht über mehrere Knoten und für seine Verfügbarkeit gibt es keine Vereinbarung zum Service Level (SLA). Basic-Caches werden nur zu Entwicklungs- und Testzwecken 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 erfolgt, wenn sich ein Replikatknoten zum primären Knoten heraufstuft 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 stellt er eine Verbindung mit dem neuen primären Knoten her und synchronisiert Daten. Ein Failover kann geplant oder ungeplant sein.

Ein geplantes Failover kann zu zwei verschiedenen Zeitpunkten stattfinden:

  • Bei Systemupdates, wie z. B. dem Aufspielen von Redis-Patches oder Betriebssystemupgrades.
  • Bei Verwaltungsvorgängen, wie z. B. Skalierungen und Neustarts.

Da die Knoten eine Vorabbenachrichtigung zum Update erhalten, können die Rollen getauscht werden, und der Load Balancer kann schnell entsprechend der Änderung aktualisiert werden. Ein geplantes Failover wird normalerweise in weniger als einer Sekunde abgeschlossen.

Ein ungeplantes Failover kann aufgrund eines Hardwarefehlers, eines Netzwerkfehlers oder anderer unerwarteter Ausfälle des primären Knotens erfolgen. Der Replikatknoten stuft sich selbst zum primären Knoten herauf, der Prozess dauert jedoch länger. Ein Replikatknoten muss zunächst erkennen, dass der zugehörige primäre Knoten nicht verfügbar ist, bevor der Failoverprozess gestartet werden kann. Der Replikatknoten muss außerdem überprüfen, ob dieser ungeplante Ausfall nicht vorübergehend oder lokal ist, um ein unnötiges Failover zu vermeiden. Diese Verzögerung bei der Erkennung bedeutet, dass ein ungeplantes Failover normalerweise innerhalb von 10 bis 15 Sekunden abgeschlossen ist.

Wie erfolgt das Patchen?

Der Azure Cache for Redis-Dienst aktualisiert den Cache regelmäßig mit den neuesten Plattformfunktionen und Korrekturen. Zum Patchen eines Caches führt der Dienst die folgenden Schritte aus:

  1. Der Dienst patcht 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 vorherige primäre Knoten wird neu gestartet, um die neuen Änderungen zu übernehmen, und wird als Replikatknoten wieder verfügbar.
  4. Der Replikatknoten stellt eine Verbindung mit dem primären Knoten her und synchronisiert Daten.
  5. Wenn die Datensynchronisierung abgeschlossen ist, wird der Patchprozess 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 damit, Anforderungen zu verarbeiten und neue Verbindungen herzustellen. Basic-Caches verfügen über keinen Replikatknoten und sind bis zum Abschluss des Updates nicht verfügbar. Jeder Shard eines gruppierten Caches wird separat gepatcht und schließt keine Verbindungen mit einem anderen Shard.

Wichtig

Knoten werden einzeln gepatcht, um Datenverluste zu vermeiden. Bei Basic-Caches kommt es zu Datenverlust. Bei gruppierten Caches werden die Shards jeweils einzeln gepatcht.

Mehrere Caches in derselben Ressourcengruppe und Region werden ebenfalls einzeln gepatcht. Caches, die sich in unterschiedlichen Ressourcengruppen oder Regionen befinden, können gleichzeitig gepatcht werden.

Da die vollständige Datensynchronisierung ausgeführt wird, bevor der Prozess wiederholt wird, ist es unwahrscheinlich, dass bei der Verwendung eines Standard- oder Premium-Caches Datenverluste auftreten. Sie können Datenverlusten weiter vorbeugen, indem Sie die Daten exportieren und die Datenpersistenz aktivieren.

Zusätzliche Cacheauslastung

Bei jedem Failover müssen in den Standard- und Premium-Caches Daten von einem auf den anderen Knoten repliziert werden. Diese Replikation führt zu einer gewissen Erhöhung der Auslastung von Serverspeicher und Server-CPU. Wenn die Cache-Instanz bereits stark ausgelastet ist, können Clientanwendungen eine höhere Latenz aufweisen. Im Extremfall treten in Clientanwendungen möglicherweise Timeoutausnahmen auf. Um die Auswirkungen der höheren Auslastung zu minimieren, konfigurieren Sie die maxmemory-reserved-Einstellung des Caches.

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. Bei jeder Verbindung, die über den Knoten weitergeleitet wird, dessen Verbindungen geschlossen wurden, treten Fehler auf.

Viele Clientbibliotheken können bei Verbindungsabbrüchen verschiedene Arten von Fehlern auslösen, darunter:

  • Timeoutausnahmen
  • Verbindungsausnahmen
  • Socketausnahmen

Anzahl und Typ der Ausnahmen hängen davon ab, wo sich die Anforderung im Codepfad befindet, wenn der Cache die Verbindungen schließt. Beispielsweise tritt bei einem Vorgang, bei dem eine Anforderung gesendet wird, für die zum Zeitpunkt des Failovers jedoch noch keine Antwort zurückgegeben wurde, möglicherweise eine Timeoutausnahme auf. Bei neuen Anforderungen für das geschlossene Verbindungsobjekt treten Verbindungsausnahmen auf, bis die Verbindung erfolgreich wiederhergestellt wird.

Die meisten Clientbibliotheken versuchen, erneut eine Verbindung mit dem Cache herzustellen, wenn sie entsprechend konfiguriert sind. Durch unvorhergesehene Fehler können die Bibliotheksobjekte jedoch gelegentlich in einen nicht wiederherstellbaren Zustand gesetzt werden. Wenn Fehler länger als eine vorkonfigurierte Zeitspanne andauern, sollte das Verbindungsobjekt neu erstellt werden. In Microsoft .NET und anderen objektorientierten Sprachen kann die Neuerstellung der Verbindung ohne Neustart der Anwendung durch Verwendung eines ForceReconnect-Musters erreicht werden.

Kann ich im Voraus über eine geplante Wartung informiert 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 Ihrer Clientanwendung. Weitere Informationen zu Wartungsereignissen finden Sie unter AzureRedisEvents.

Hinweis

Der AzureRedisEvents-Kanal ist kein Mechanismus, der Sie Tage oder Stunden im Voraus benachrichtigen kann. Der Kanal kann Clients über anstehende geplante Serverwartungsereignisse benachrichtigen, die sich auf die Serververfügbarkeit auswirken können. AzureRedisEvents ist nur in den Tarifen Basic, Standard und Premium verfügbar.

Änderungen der Clientnetzwerkkonfiguration

Bestimmte Änderungen der clientseitigen Netzwerkkonfiguration können Fehler vom Typ „Keine Verbindung verfügbar“ auslösen. Dies betrifft beispielsweise folgende Änderungen:

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

Diese Änderungen können zu einem Verbindungsproblem führen, das weniger als eine Minute dauert. Möglicherweise wird dabei die Verbindung Ihrer Clientanwendung mit anderen externen Netzwerkressourcen sowie dem Azure Cache for Redis-Dienst getrennt.

Erstellen von Resilienz

Failover lassen sich nicht ganz vermeiden. Schreiben Sie Ihre Clientanwendungen daher so, dass sie gegenüber Verbindungsunterbrechungen und nicht erfolgreichen Anforderungen resilient sind. Von den meisten Clientbibliotheken wird zwar automatisch erneut eine Verbindung mit dem Cacheendpunkt hergestellt, aber nur wenige versuchen, nicht erfolgreiche Anforderungen zu wiederholen. Je nach Anwendungsszenario ist es möglicherweise sinnvoll, Wiederholungslogik mit Backoff zu verwenden.

Wie mache ich meine Anwendung resilient?

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

Verwenden Sie zum Testen der Resilienz einer Clientanwendung einen Neustart als manuellen Auslöser 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 Zeitfenstern handelt es sich normalerweise um Zeiträume, in denen der Datenverkehr der Clientanwendung gering ist. Weitere Informationen finden Sie unter „Updatekanal“ und „Planen von Updates“.

Weitere Informationen finden Sie unter Verbindungsresilienz.

Zugehöriger Inhalt