Ereignisse
31. März, 23 Uhr - 2. Apr., 23 Uhr
Das größte SQL-, Fabric- und Power BI-Lernereignis. 31. März – 2. April. Verwenden Sie Code FABINSIDER, um $400 zu sparen.
Jetzt registrierenDieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
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:
Beginnen wir mit einer Übersicht über das Failover für Azure Managed Redis.
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.
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:
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.
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:
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.
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.
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:
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.
Wartung umfasst folgende Updates:
Nein. Die Wartung wird unter Dienststatus im Portal nicht angezeigt, noch an einem anderen Ort.
Bestimmte Änderungen der clientseitigen Netzwerkkonfiguration können Fehler vom Typ Keine Verbindung verfügbar auslösen. Dies betrifft beispielsweise folgende Änderungen:
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.
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.
Die folgenden Entwurfsmustern helfen Ihnen bei der Erstellung robuster Clients. Das gilt insbesondere für die Trennschalter- und Wiederholungsmuster:
Ereignisse
31. März, 23 Uhr - 2. Apr., 23 Uhr
Das größte SQL-, Fabric- und Power BI-Lernereignis. 31. März – 2. April. Verwenden Sie Code FABINSIDER, um $400 zu sparen.
Jetzt registrierenTraining
Modul
Implementieren von Resilienz in cloudnative Microservices - Training
In diesem Modul wird die Implementierung von Resilienz in eine .NET-Microservices-App in einem Kubernetes-Dienst erläutert.
Zertifizierung
Microsoft Certified: Azure Cosmos DB Developer Specialty - Certifications
Schreiben Sie effiziente Abfragen, erstellen Sie Indizierungsrichtlinien, verwalten Sie und Sie Ressourcen in der SQL-API und im SDK mit Microsoft Azure Cosmos DB bereit.