Freigeben über

Failover und Patchen für Azure Managed Redis (Vorschau)

  • Artikel

Zum Erstellen resilienter und erfolgreicher Clientanwendungen ist es wichtig, zu verstehen, wie das Failover für den Azure Managed Redis (Vorschau)-Dienst funktioniert. Ein Failover kann Teil geplanter Verwaltungsvorgänge sein oder durch ungeplante Hardware- oder Netzwerkausfälle verursacht werden. Ein Cachefailover wird häufig durchgeführt, wenn der Verwaltungsdienst die Azure Managed 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?

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

Kurze Zusammenfassung der Cachearchitektur

Diagramm zeigt die Architektur des Azure Managed Redis-Angebots.

Ein Cache wird aus mehreren virtuellen Computern mit separaten und privaten IP-Adressen erstellt. Jeder virtuelle Computer (oder „Knoten“) führt mehrere Redis-Serverprozesse (sogenannte „Shards“) parallel aus. Mehrere Shards ermöglichen eine effizientere Nutzung von vCPUs auf jedem virtuellen Computer und eine höhere Leistung. Nicht alle primären Redis-Shards befinden sich auf demselben virtuellen Computer/Knoten. Stattdessen werden primäre und Replikatshards über beide Knoten verteilt. Da primäre Shards mehr CPU-Ressourcen als Replikatshards verwenden, ermöglicht dieser Ansatz die parallele Ausführung von mehr primären Shards. Jeder Knoten verfügt über einen leistungsfähigen Proxy-Prozess, um die Shards zu verwalten, die Verbindungsverwaltung durchzuführen und Self-healing auszulösen. Ein Shard kann ausgefallen sein, während die anderen verfügbar bleiben.

Ausführliche Informationen zur Azure Managed Redis-Architektur finden Sie hier.

Erläuterung eines Failovers

Ein Failover tritt auf, wenn ein oder mehrere Replikatshards sich selbst zu primären Shards heraufstufen und die alten primären Shards vorhandene Verbindungen schließen. 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 auf einem oder mehreren Knoten des Clusters erfolgen. Die Replikatshards auf dem/den verbleibenden Knoten werden sich selbst zu primär höherstufen, um die Verfügbarkeit aufrechtzuerhalten, der Prozess dauert jedoch länger. Ein Replikatshard muss zunächst erkennen, dass der zugehörige primäre Shard nicht verfügbar ist, bevor der Failoverprozess gestartet werden kann. Der Replikatshard 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 Managed Redis-Dienst aktualisiert den Cache regelmäßig mit den neuesten Plattformfeatures und Korrekturen. Zum Patchen eines Caches führt der Dienst die folgenden Schritte aus:

  1. Der Dienst erstellt neue aktuelle VMs, um alle VMs zu ersetzen, die gepatcht werden.
  2. Dann stuft er eine der neuen VMs als Cluster-Leader hoch.
  3. Alle Knoten, die gepatcht werden, werden einzeln aus dem Cluster entfernt. Alle Shards auf diesen VMs werden herabgestuft und zu einer der neuen VMs migriert.
  4. Schließlich werden alle ersetzten VMs gelöscht.

Jeder Shard eines gruppierten Caches wird separat gepatcht und schließt keine Verbindungen mit einem anderen Shard.

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 Synchronisierung vor der Wiederholung des Prozesses erfolgt, ist ein Datenverlust für Ihren Cache unwahrscheinlich. Sie können Datenverlusten weiter vorbeugen, indem Sie die Daten exportieren und die Datenpersistenz aktivieren.

Zusätzliche Cacheauslastung

Bei jedem Failover müssen die Caches Daten von einem Knoten auf den anderen replizieren. 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.

Wie wirkt sich ein Failover auf meine Clientanwendung aus?

Clientanwendungen könnten einige Fehler von ihrer Azure Managed 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.

Welche Updates sind unter Wartung enthalten?

Wartung umfasst folgende Updates:

  • Redis Server-Updates: Alle Updates oder Patches der Redis Server-Binärdateien.
  • Updates für den virtuellen Computer (Virtual Machine, VM): Alle Updates des virtuellen Computers, auf dem der Redis-Dienst gehostet wird. VM-Updates reichen von Patches für Softwarekomponenten in der Hostumgebung über Upgrades von Netzwerkkomponenten bis hin zur Außerbetriebnahme.

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

Nein. Die Wartung wird unter Dienststatus im Portal nicht angezeigt, noch an einem anderen Ort.

Ä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 in der Regel weniger als eine Minute dauert. Möglicherweise verliert Ihre Clientanwendung ihre Verbindung mit anderen externen Netzwerkressourcen, aber auch mit dem Azure Managed Redis-Dienst.

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:

Zugehöriger Inhalt