Zuverlässigkeit in azure Managed Redis

Azure Managed Redis bietet voll integriertes und verwaltetes Redis Enterprise auf Azure und stellt leistungsstarken In-Memory-Datenspeicher für Anwendungen bereit. Dieser Dienst wurde für Unternehmensarbeitslasten entwickelt, die extrem niedrige Latenz, hohen Durchsatz und erweiterte Datenstrukturen erfordern.

Wenn Sie Azure verwenden, ist Zuverlässigkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.

In diesem Artikel wird die Zuverlässigkeit in Azure Managed Redis beschrieben, einschließlich der Ausfallsicherheit bei vorübergehenden Fehlern, Fehlern in Verfügbarkeitszonen und Fehlern, die ganze Regionen betreffen. Der Artikel beschreibt auch Backup-Strategien und den Servicelevelvertrag (SLA).

Bereitstellungsempfehlungen für die Produktion

Um eine hohe Zuverlässigkeit für Ihre Azure Managed Redis-Instanzen in Ihrer Produktionsumgebung zu gewährleisten, empfehlen wir Ihnen Folgendes:

Übersicht über die Zuverlässigkeitsarchitektur

In diesem Abschnitt werden einige der wichtigen Aspekte der Funktionsweise des Diensts beschrieben, die aus Zuverlässigkeitsperspektive am relevantesten sind. Im Abschnitt wird die logische Architektur vorgestellt, die einige der Ressourcen und Features enthält, die Sie bereitstellen und verwenden. Außerdem wird die physische Architektur erläutert, die Details zur Funktionsweise des Diensts unter den Deckeln bereitstellt.

Logische Architektur

Azure Managed Redis basiert auf Redis Enterprise und bietet Zuverlässigkeit durch Hochverfügbarkeitskonfigurationen und Replikationsfunktionen.

Sie stellen eine Instanz von Azure Managed Redis bereit, die auch als Cacheinstanz oder Cache bezeichnet wird. Ihre Clientanwendungen speichern und interagieren mit Daten im Cache mithilfe von Redis-APIs.

Physische Architektur

Es gibt zwei wichtige Konzepte, die Sie beim Planen der Resilienz für Azure Managed Redis verstehen müssen: Knoten und Shards.

• Knoten: Jede Cacheinstanz besteht aus Knoten, die virtuelle Computer (VMs) sind. Jede VM dient als unabhängige Computeeinheit im Cluster. Die virtuellen Computer werden nicht direkt angezeigt oder verwaltet. Die Plattform verwaltet automatisch die Instanzerstellung, Systemüberwachung und den Austausch von fehlerhaften Instanzen. Die Gruppe von virtuellen Computern, die zusammengenommen werden, wird auch als Cluster bezeichnet.

  Sie können Ihre Instanz für hohe Verfügbarkeit konfigurieren. Wenn Sie dies tun, stellt Azure Managed Redis sicher, dass mindestens zwei Knoten vorhanden sind, und es repliziert Daten automatisch zwischen den Knoten. In Regionen mit Verfügbarkeitszonen werden die Knoten in verschiedene Verfügbarkeitszonen platziert. Weitere Informationen finden Sie unter Resilienz bei Ausfällen von Verfügbarkeitszonen.

  Der Dienst abstrahiert die spezifische Anzahl von Knoten, die in jeder Konfiguration verwendet werden, um Komplexität zu vermeiden und optimale Konfigurationen sicherzustellen.

• Fragmente: Jeder Knoten führt mehrere Redis-Serverprozesse aus, die als Fragmente bezeichnet werden und eine Teilmenge der Cachedaten verwalten. Wenn Ihr Cache für hohe Verfügbarkeit konfiguriert ist, werden Shards automatisch verteilt und über Knoten repliziert. Sie geben eine Clusterrichtlinie an, die bestimmt, wie Shards über Knoten verteilt werden.

Weitere Informationen finden Sie unter Azure Managed Redis-Architektur und Failover und Patching für Azure Managed Redis.

Resilienz für vorübergehende Fehler

Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können, in der Regel durch Wiederholen betroffener Anforderungen.

Alle in der Cloud gehosteten Anwendungen sollten die Anleitung zur vorübergehenden Fehlerbehandlung von Azure befolgen, wenn sie mit cloudgehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zum Umgang mit vorübergehenden Fehlern.

Befolgen Sie die folgenden Empfehlungen zum Verwalten vorübergehender Fehler bei Verwendung von Azure Managed Redis:

• Verwenden Sie SDK-Konfigurationen , die beim Auftreten vorübergehender Fehler automatisch wiederholen und entsprechende Backoff- und Timeoutperioden verwenden. Erwägen Sie die Verwendung des Wiederholungsmusters und des Circuit Breaker-Musters in Ihren Anwendungen.
• Entwerfen Sie Cache-Aside-Muster, bei denen Ihre Anwendung auch mit eingeschränkter Leistung weiterarbeiten kann, wenn Redis vorübergehend nicht verfügbar ist, indem auf den primären Datenspeicher zurückgegriffen wird.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb einer Azure-Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.

Azure Managed Redis-Cache-Instanzen können zonenübergreifend redundant gemacht werden, was die Cache-Nodes automatisch auf mehrere Verfügbarkeitszonen innerhalb einer Region verteilt. Die Zonenredundanz verringert das Risiko von Ausfallen von Rechenzentren oder Verfügbarkeitszonen, sodass Der Cache nicht verfügbar ist.

Um eine Cachezone redundant zu machen, müssen Sie sie in einer unterstützten Region bereitstellen und die Konfiguration für hohe Verfügbarkeit aktivieren. In Regionen ohne Verfügbarkeitszonen erstellt die Hochverfügbarkeitskonfiguration weiterhin mindestens zwei Knoten, sie befinden sich jedoch nicht in separaten Zonen.

Das folgende Diagramm zeigt einen zonenredundanten Cache mit zwei Knoten in einer separaten Zone:

Anforderungen

• Regionsunterstützung: Zonenredundante, verwaltete Azure Redis Caches können in allen Regionen bereitgestellt werden, die Verfügbarkeitszonen unterstützen und in denen der Dienst verfügbar ist. Die aktuellste Liste der Regionen, die Verfügbarkeitszonen unterstützen, finden Sie in Azure-Regionen mit Verfügbarkeitszonen. Eine Liste der Regionen, die Azure Managed Redis unterstützen, finden Sie unter Produktverfügbarkeit nach Region.

• Konfiguration für hohe Verfügbarkeit: Sie müssen die Konfiguration für hohe Verfügbarkeit im Cache aktivieren, damit sie zonenredundant ist.

• Ebenen: Alle Azure Managed Redis-Ebenen unterstützen Verfügbarkeitszonen.

Kosten

Zonenredundanz erfordert, dass Ihr Cache für hohe Verfügbarkeit konfiguriert ist, wodurch mindestens zwei Knoten für Den Cache bereitgestellt werden. Die Konfiguration für hohe Verfügbarkeit wird zu einem höheren Satz als die Konfiguration ohne hohe Verfügbarkeit in Rechnung gestellt. Weitere Informationen finden Sie unter Azure Managed Redis-Preise

Konfigurieren der Unterstützung von Verfügbarkeitszonen

• Erstellen Einer neuen zonenredundanten Instanz: Wenn Sie eine neue Azure Managed Redis-Instanz erstellen, aktivieren Sie die Konfiguration für hohe Verfügbarkeit und stellen sie in einer Region mit Verfügbarkeitszonen bereit. Anschließend enthält sie standardmäßig Zonenredundanz. Sie müssen keine weitere Konfiguration durchführen.

  Ausführliche Schritte finden Sie in der Schnellstartanleitung: Erstellen einer azure managed Redis-Instanz.

• Zonenredundanz für eine vorhandene Instanz aktivieren: Um eine vorhandene Azure Managed Redis-Instanz so zu konfigurieren, dass sie zonenredundant ist, stellen Sie sicher, dass sie in einer Region bereitgestellt wird, die Verfügbarkeitszonen unterstützt, und aktivieren Sie hohe Verfügbarkeit im Cache.

• Zonenredundanz deaktivieren: Zonenredundanz kann für vorhandene Instanzen nicht deaktiviert werden, da Sie hohe Verfügbarkeit nicht deaktivieren können, sobald sie in einer Cacheinstanz aktiviert ist.

Kapazitätsplanung und -verwaltung

Während eines Zonen-Down-Ereignisses steht Ihrer Instanz möglicherweise weniger Ressourcen zur Verfügung, um Ihre Workload zu bedienen. Wenn Ihre Instanz häufig unter Ressourcendruck steht und Sie sich auf ausfallende Verfügbarkeitszonen vorbereiten müssen, sollten Sie einen der folgenden Ansätze berücksichtigen:

• Überprovisionieren Sie Ihre Instanz: Beim Überprovisionieren wählen Sie eine höhere Leistungsstufe als erforderlich. Es ermöglicht Ihrer Instanz, einige Kapazitätsverluste zu tolerieren und ohne beeinträchtigte Leistung weiter zu funktionieren. Weitere Informationen zum Prinzip der Überprovisionierung finden Sie unter Manage capacity by overprovisioning. Informationen zum Skalieren Ihrer Instanz finden Sie unter Skalieren einer Azure Managed Redis-Instanz.

• Aktive Georeplikation verwenden: Sie können mehrere Instanzen in verschiedenen Regionen bereitstellen und die aktive Georeplikation so konfigurieren, dass ihre Last über diese separaten Instanzen verteilt wird.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein verwalteter Redis-Cache zonenredundant ist und alle Verfügbarkeitszonen betriebsbereit sind:

• Verkehrsrouting zwischen Zonen: Shards werden entsprechend Ihrer Clusterrichtlinie über Knoten verteilt. Ihre Clusterrichtlinie bestimmt auch, wie Datenverkehr an jeden Knoten weitergeleitet wird. Die Zonenredundanz ändert nicht, wie Datenverkehr weitergeleitet wird.

• Datenreplikation zwischen Zonen: Shards werden automatisch über Knoten repliziert und verwenden asynchrone Replikation. In der Regel wird die Replikationsverzögerung zwischen Shards in Sekunden gemessen. Dies kann jedoch abhängig von der Arbeitsauslastung des Caches variieren, wobei schreibintensive und netzwerkintensive Szenarien in der Regel eine höhere Replikationsverzögerung aufweisen.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein verwalteter Redis-Cache zonenredundant ist und mindestens eine Verfügbarkeitszone nicht verfügbar ist:

• Erkennung und Reaktion: Azure Managed Redis ist dafür verantwortlich, einen Fehler in einer Verfügbarkeitszone zu erkennen. Sie müssen keine Maßnahmen ergreifen, um ein Zonenfailover zu initiieren.

• Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone deaktiviert ist. Sie können jedoch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich aller Zonenfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

• Aktive Anforderungen: In-Flight-Anforderungen werden möglicherweise verworfen und sollten wiederholt werden. Anwendungen sollten Wiederholungslogik implementieren , um diese temporären Unterbrechungen zu behandeln.

• Erwarteter Datenverlust: Daten, die nicht in Shards einer anderen Zone repliziert wurden, können bei einer Zonenstörung verloren gehen. Normalerweise wird die Menge des Datenverlusts in Sekunden gemessen, hängt jedoch von der Replikationsverzögerung ab.

• Erwartete Ausfallzeit: Eine kurze Ausfallzeit von 10 bis 15 Sekunden kann typischerweise auftreten, während Shards auf Knoten in fehlerfreien Zonen umgeschaltet werden. Informationen zum ungeplanten Failoverprozess finden Sie in der Erläuterung eines Failovers beim Entwerfen von Anwendungen, befolgen Sie die Methoden für die vorübergehende Fehlerbehandlung.

• Datenverkehrsumleitung: Azure Managed Redis leitet automatisch Datenverkehr zu Knoten in fehlerfreien Zonen um.

Zonenwiederherstellung

Wenn die betroffene Verfügbarkeitszone wiederhergestellt wird, stellt Azure Managed Redis Vorgänge automatisch in dieser Zone wieder her. Die Azure-Plattform verwaltet diesen Prozess vollständig und erfordert keine Kundeneingriffe.

Test auf Zonenfehler

Da Azure Managed Redis das Datenverkehrsrouting, das Failover und das Failback bei Ausfall von Verfügbarkeitszonen vollständig verwaltet, müssen Sie dazu keine Prozesse überprüfen oder weitere Eingaben bereitstellen.

Widerstandsfähigkeit bei regionalen Ausfällen

Azure Managed Redis bietet native Unterstützung für mehrere Regionen über die aktive Georeplikation, mit der Sie mehrere Azure Managed Redis-Instanzen in verschiedenen Azure-Regionen mit einer einzelnen Replikationsgruppe verknüpfen können. Anschließend können Sie ihren eigenen Failoveransatz zwischen den Instanzen konfigurieren.

Aktive Georeplikation

Wenn Sie die aktive Georeplikation verwenden, können Anwendungen aus einer beliebigen Cacheinstanz in der Gruppe lesen und schreiben, wobei Änderungen automatisch in allen Regionen synchronisiert werden. Der Dienst unterstützt aktiv-aktive Replikationsmuster, in denen jede Region Lese- und Schreibvorgänge gleichzeitig verarbeiten kann. Wenn Konflikte aufgrund gleichzeitiger Schreibvorgänge in verschiedenen Regionen auftreten, löst der Dienst sie automatisch mithilfe von vordefinierten Konfliktlösungsalgorithmen ohne manuelle Eingriffe auf. Dieser Ansatz bietet Ausfallsicherheit bei Regionsfehlern bei gleichzeitiger Beibehaltung des Zugriffs mit geringer Latenz für global verteilte Anwendungen.

Das folgende Diagramm zeigt zwei Cacheinstanzen in verschiedenen Regionen innerhalb derselben aktiven Georeplikationsgruppe mit Clientanwendungen, die eine Verbindung mit jeder Cacheinstanz herstellen:

Sie sind für die Konfiguration Ihrer Clientanwendungen verantwortlich, damit sie, wenn eine regionale Instanz fehlschlägt, ihre Anforderungen an eine fehlerfreie Instanz umleiten können. Das folgende Diagramm zeigt, wie eine Anwendung ihre Anforderungen an eine fehlerfreie Cacheinstanz umleiten kann, wenn die Instanz, die sie verwenden, fehlschlägt:

Anforderungen

• Regionsunterstützung Azure Managed Redis active Geo-Replikation kann zwischen allen Azure-Regionen konfiguriert werden, in denen der Dienst verfügbar ist.

• Instanzkonfiguration: Für die aktive Georeplikation sind Azure Managed Redis-Instanzen derselben Ebene und Größe in allen teilnehmenden Regionen erforderlich. Alle Cacheinstanzen in einer Replikationsgruppe müssen mit identischen Einstellungen konfiguriert werden, einschließlich Persistenzoptionen, Modulen und Clusteringrichtlinien.

• Weitere Anforderungen: Ihre Cacheinstanzen müssen andere Anforderungen erfüllen, einschließlich der verwendeten Module, und sie wirkt sich darauf aus, wie Ihre Cacheinstanzen skaliert werden können. Weitere Informationen finden Sie unter Voraussetzungen für die aktive Georeplikation.

Überlegungen

• Failoververantwortung: Wenn Sie die aktive Georeplikation verwenden, sind Sie für das Failover zwischen Cacheinstanzen verantwortlich. Sie sollten Ihre Anwendung für die Behandlung des Failovers vorbereiten und konfigurieren. Failover beinhaltet die Vorbereitung und erfordert möglicherweise, dass Sie mehrere Schritte ausführen. Weitere Informationen finden Sie unter "Force-unlink", wenn ein Regionsausfall vorhanden ist.

• Schlussendliche Konsistenz: Anwendungen sollten so konzipiert sein, dass sie schlussendliche Konsistenzszenarien verarbeiten können, da Änderungen je nach Netzwerkbedingungen und geografischer Entfernung Zeit benötigen können, um sich über alle Regionen hinweg zu verbreiten. Während Regionsausfällen können mehr Dateninkonsistenzen auftreten, bis die Verbindung wiederhergestellt und die Synchronisierung abgeschlossen ist.

Kosten

Wenn Sie die aktive Georeplikation aktivieren, werden Sie für jede Azure Managed Redis-Instanz in jeder Region innerhalb der Replikationsgruppe in Rechnung gestellt. Darüber hinaus fallen möglicherweise Gebühren für die Datenübertragung bei regionsübergreifendem Replikationsverkehr zwischen Regionen an. Weitere Informationen zu preisen finden Sie unter Azure Managed Redis pricing and Bandwidth pricing details.

Konfigurieren der Unterstützung für mehrere Regionen

• Erstellen Sie eine neue georeplizierte Cacheinstanz: Konfigurieren Sie die aktive Georeplikation während der Cachebereitstellung, indem Sie eine Replikationsgruppe angeben und mehrere Instanzen verknüpfen. Weitere Informationen finden Sie unter Erstellen oder Beitreten zu einer aktiven Georeplikationsgruppe.

• Aktivieren Sie eine vorhandene Cacheinstanz für die Georeplikation: Sie können einer aktiven Georeplikationsgruppe eine vorhandene Cacheinstanz hinzufügen.

  Wenn jedoch einer aktiven Georeplikationsgruppe eine vorhandene Instanz hinzugefügt wird, müssen die Daten in der Instanz geleert werden, und es gibt eine geringe Anzahl von Ausfallzeiten. Planen Sie nach Möglichkeit, die aktive Georeplikation zu aktivieren, wenn Sie Cacheinstanzen erstellen.

  Weitere Informationen finden Sie unter Hinzufügen einer vorhandenen Instanz zu einer aktiven Georeplikationsgruppe.

• Deaktivieren Sie die Georeplikation für eine Cacheinstanz: Entfernen Sie eine Instanz aus einer Georeplikationsgruppe, indem Sie die Cacheinstanz löschen. Die verbleibenden Instanzen konfigurieren sich automatisch neu.

Kapazitätsplanung und -verwaltung

Bei einem Regions-Down-Ereignis können die anderen Instanzen unter höherem Druck stehen. Wenn eine Instanz häufig bereits unter Ressourcendruck steht und Sie sich auf die erhöhten Kapazitätsanforderungen während eines Regionsausfalls vorbereiten müssen, sollten Sie die Instanz überprovisionieren. Informationen zum Skalieren einer Instanz finden Sie unter Skalieren einer Azure Managed Redis-Instanz.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Instanzen für die Verwendung der aktiven Georeplikation konfiguriert sind und alle Regionen betriebsbereit sind.

• Datenverkehrsrouting zwischen Regionen: Sie sind für die Konfiguration Ihrer Anwendungen für die Verbindung mit einer bestimmten Cacheinstanz verantwortlich. Anwendungen können eine Verbindung mit einer beliebigen Cacheinstanz in der Replikationsgruppe herstellen und Lese- und Schreibvorgänge ausführen. Das Datenverkehrsrouting wird von der Anwendung verarbeitet, sodass Sie Clients für minimale Latenz an die nächste Region weiterleiten können. Azure Managed Redis bietet kein automatisches Datenverkehrsrouting zwischen Regionen.

• Datenreplikation zwischen Regionen: Der Dienst verwendet die asynchrone Replikation zwischen Regionen, um die spätere Konsistenz aufrechtzuerhalten. Schreibvorgänge werden sofort in der lokalen Region festgeschrieben und dann im Hintergrund in andere Regionen verbreitet. Konfliktfreie replizierte Datentypen (CRDTs) stellen sicher, dass gleichzeitige Schreibvorgänge in verschiedenen Regionen automatisch zusammengeführt werden.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Instanzen für die Verwendung der aktiven Georeplikation konfiguriert sind und es einen Ausfall in einer Region gibt:

• Erkennung und Reaktion: Sie sind dafür verantwortlich, den Ausfall einer Cacheinstanz zu erkennen und zu entscheiden, wann ein Failover durchgeführt wird. Sie können die Integrität eines geo-replizierten Clusters überwachen, was Ihnen dabei helfen kann, zu entscheiden, wann ein Failover initiiert werden sollte. Weitere Informationen finden Sie unter Georeplikationsmetrik.

  Failover erfordert, dass Sie mehrere Schritte ausführen. Weitere Details finden Sie unter Erzwungenes Entkoppeln bei einem Regionenausfall.

• Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Sie können jedoch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich aller Regionsfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

  Sie können auch den Gesundheitszustand jeder Instanz überwachen.

  Um den Status der Georeplikationsbeziehung zu überwachen, können Sie die Metrik "Georeplikation fehlerfrei " verwenden. Die Metrik weist immer einen Wert von 1 (fehlerfrei) oder 0 (ungesund) auf. Sie können Azure Monitor-Warnungen für diese Metrik konfigurieren, um zu verstehen, wann die Instanzen möglicherweise nicht synchronisiert sind.

• Aktive Anforderungen: Anforderungen an den fehlgeschlagenen Bereich werden beendet und müssen von der Failoverlogik Ihrer Anwendung behandelt werden. Anwendungen sollten Wiederholungsrichtlinien implementieren, die Datenverkehr zu fehlerfreien Caches umleiten können.

• Erwarteter Datenverlust: Aufgrund der asynchronen Replikation zwischen Regionen gehen einige kürzlich vorgenommene Schreibvorgänge in die fehlgeschlagene Region möglicherweise verloren, wenn sie noch nicht in andere Regionen repliziert wurden. Die Menge potenzieller Datenverluste hängt von der Replikationsverzögerung zum Zeitpunkt des Ausfalls ab. Weitere Informationen finden Sie unter Active-Active geo-verteiltem Redis und Überlegungen zu Konsistenz und Datenverlust bei einem regionalen CRDB-Ausfall.

• Erwartete Ausfallzeiten: Anwendungen erleben Ausfallzeiten nur für die Dauer, die erforderlich ist, um den Fehler zu erkennen und den Datenverkehr an gesunde Regionen umzuleiten. Dies reicht in der Regel von Sekunden bis zu einigen Minuten, je nachdem, wie Sie die Integritätsprüfung und Failoverkonfiguration Ihrer Anwendung konfiguriert haben.

• Datenverkehrsumleitung: Sie sind für die Implementierung von Logik in Ihren Anwendungen verantwortlich, um Regionsfehler zu erkennen und Datenverkehr an gesunde Regionen weiterzuleiten. Dies kann durch Integritätsprüfungen, Schaltkreistrennmuster oder externe Lastenausgleichslösungen erreicht werden.

Region-Wiederherstellung

Wenn eine fehlgeschlagene Region wiederhergestellt wird, integriert Azure Managed Redis Instanzen in dieser Region automatisch in die aktive Georeplikationsgruppe, ohne dass Ihre Intervention erforderlich ist. Der Dienst synchronisiert automatisch Daten aus fehlerfreien Instanzen. Während dieses Prozesses erfasst die wiederhergestellte Instanz schrittweise Änderungen, die während des Ausfalls aufgetreten sind. Nach Abschluss der Synchronisierung werden die wiederhergestellten Instanzen vollständig aktiv und können lese- und schreibvorgänge verarbeiten.

Sie sind für die Neukonfiguration Ihrer Anwendung verantwortlich, um den Datenverkehr zurück zur wiederhergestellten Regionsinstanz weiterzuleiten.

Test auf Regionsfehler

Sie sollten die Failoverprozeduren Ihrer Anwendung regelmäßig testen. Es ist wichtig, dass Ihre Anwendung zwischen Instanzen übergehen kann und dass sie dabei innerhalb Ihrer geschäftlichen Anforderungen an Ausfallzeiten bleibt. Es ist auch wichtig, dass Sie Ihre gesamten Antwortprozesse testen, einschließlich der Neukonfiguration von Firewalls und anderer Infrastruktur sowie Ihres Wiederherstellungsprozesses.

Resilienz gegenüber Wartungsarbeiten an Diensten

Azure Managed Redis führt regelmäßige Dienstupgrades und andere Wartungsaufgaben aus.

Wenn die Wartung ausgeführt wird, erstellt Azure Managed Redis automatisch neue Knoten und führt automatisch Failover durch. Clientanwendungen können Verbindungsunterbrechungen und andere vorübergehende Fehler sehen. Anwendungen sollten Wiederholungslogik implementieren , um diese temporären Unterbrechungen zu behandeln.

Weitere Informationen zu den Wartungsprozessen für Azure Managed Redis finden Sie unter Failover und Patching für Azure Managed Redis.

Sichern und Wiederherstellen

Azure Managed Redis bietet sowohl Datenpersistenz- als auch Sicherungsfunktionen zum Schutz vor Datenverlustszenarien, die andere Zuverlässigkeitsfeatures möglicherweise nicht adressieren. Sicherungen können Schutz vor Szenarien wie Datenbeschädigung, versehentlichem Löschen oder Konfigurationsfehlern bieten.

• Datenpersistenz: Standardmäßig speichert Azure Managed Redis alle Cachedaten im Arbeitsspeicher. Es kann optional Momentaufnahmen Ihrer Daten mithilfe der Datenpersistenz auf die Festplatte schreiben. Wenn ein Hardwarefehler auftritt, der sich auf den Knoten auswirkt, stellt Azure Managed Redis die Daten automatisch wieder her. Es gibt verschiedene Arten von Datenpersistenz, aus denen Sie auswählen können, die unterschiedliche Kompromisse zwischen Der Momentaufnahmehäufigkeit und den Leistungseffekten im Cache bieten.

  Datendateien können jedoch nicht in einer anderen Instanz wiederhergestellt werden, und Sie können nicht auf die Dateien zugreifen. Die Datenpersistenz schützt Sie nicht vor Datenbeschädigung oder versehentlichem Löschen.

• Importieren und Exportieren: Azure Managed Redis unterstützt die Sicherung Ihrer Daten mithilfe der Import- und Exportfunktion, die Sicherungsdateien in Azure Blob Storage speichert. Sie können georedundanten Speicher für Ihr Azure Storage-Konto konfigurieren, oder Sie können die Sicherungs-BLOBs zum weiteren Schutz kopieren oder auf andere Speicherorte verschieben.

  Exportierte Dateien können in derselben Cacheinstanz oder einer anderen Cacheinstanz wiederhergestellt werden.

  Es gibt keinen integrierten Import- oder Exportplaner, aber Sie können eigene Automatisierungsprozesse entwickeln, die die Azure CLI oder Azure PowerShell verwenden, um Exportvorgänge zu initiieren.

Service-Level-Vereinbarung

Der Service level agreement (SLA) für Azure-Dienste beschreibt die erwartete Verfügbarkeit jedes Diensts und die Bedingungen, die Ihre Lösung erfüllen muss, um diese Verfügbarkeitserwartungen zu erreichen. Weitere Informationen finden Sie unter SLAs für Onlinedienste.

Die SLA für azure Managed Redis deckt die Konnektivität mit den Cacheendpunkten ab. Der SLA deckt den Schutz vor Datenverlust nicht ab.

Um für Verfügbarkeits-SLAs für Azure Managed Redis infrage zu kommen,

• Sie müssen die Konfiguration für hohe Verfügbarkeit aktivieren.
• Sie dürfen keine Produktfunktionen oder Verwaltungsmaßnahmen initiieren, die durch Dokumentation belegt sind, zeitweise Nichtverfügbarkeit zu erzeugen.

SlAs für höhere Verfügbarkeit gelten, wenn Ihre Instanz zonenredundant ist. In einigen Ebenen können Sie für eine SLA mit höherer Verfügbarkeit berechtigt sein, wenn Sie zonenredundante Instanzen in mindestens drei Regionen mit aktiver Georeplikation bereitgestellt haben.