Freigeben über

Zuverlässigkeit in azure Managed Redis

Azure Managed Redis ist ein vollständig verwalteter Azure-Dienst, der auf Redis Enterprise basiert. Es bietet leistungsstarke, speicherinterne Datenspeicher für Anwendungen und ist für Unternehmensworkloads konzipiert, 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 beschrieben, wie Sie Azure Managed Redis für eine Vielzahl potenzieller Ausfälle und Probleme widerstandsfähig machen, einschließlich vorübergehender Fehler, Ausfall von Verfügbarkeitszonen und Regionsausfällen. Außerdem werden Backup-Strategien und das Service-Level-Agreement (SLA) beschrieben.

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:

  • Nutzen Sie Hochverfügbarkeit, die mehrere Knoten für den Cache bereitstellt.

  • Verwenden Sie Zonenredundanz , indem Sie einen hoch verfügbaren Cache in einer Region mit Verfügbarkeitszonen bereitstellen.

  • Erwägen Sie die Implementierung einer aktiven Georeplikation für unternehmenskritische Workloads, die ein regionsübergreifendes Failover erfordern.

Ü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

Wenn Sie die Resilienz in Azure Managed Redis planen, müssen Sie die wichtigsten Konzepte von Knoten und Shards verstehen.

  • 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 erstellt automatisch Instanzen, überwacht den Instanzenstatus und ersetzt alle Instanzen, die fehlerhaft werden. Diese Gruppe von virtuellen Computern bildet einen Cluster.

    Sie können Ihre Instanz für hohe Verfügbarkeit einrichten. Wenn Sie hohe Verfügbarkeit verwenden, stellt Azure Managed Redis sicher, dass die Instanz mindestens zwei Knoten aufweist und automatisch Daten zwischen ihnen repliziert. In Regionen mit Verfügbarkeitszonen platziert der Dienst die Knoten in verschiedenen Verfügbarkeitszonen. Weitere Informationen finden Sie unter Resilienz bei Ausfällen von Verfügbarkeitszonen.

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

  • Fragmente: Jeder Knoten führt mehrere Redis-Serverprozesse aus, die als Shards bezeichnet werden. Jeder Shard verwaltet eine Teilmenge der Cachedaten. Wenn Sie den Cache für hohe Verfügbarkeit festlegen, werden Shards automatisch über Knoten verteilt und 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 zur Behandlung vorübergehender Fehler.

Befolgen Sie die folgenden Empfehlungen zum Verwalten vorübergehender Fehler, wenn Sie Azure Managed Redis verwenden:

  • Verwenden Sie SDK-Konfigurationen , die automatisch versuchen, wenn vorübergehende Fehler auftreten, und wenden Sie entsprechende Backoff- und Timeoutperioden an. Erwägen Sie die Verwendung des Wiederholungsmusters und des Circuit Breaker-Musters in Ihren Anwendungen.

  • Entwerfen Sie Cache-aside-Muster, bei denen Ihre Anwendung weiterhin mit leistungsbeeinträchtigter Systemleistung arbeiten kann, indem sie auf den primären Datenspeicher zurückgreift, wenn Redis vorübergehend nicht verfügbar ist.

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.

Sie können azure Managed Redis cache instances zone redundant machen, wodurch die Cacheknoten automatisch über mehrere Verfügbarkeitszonen innerhalb einer Region verteilt werden. Die Zonenredundanz verringert das Risiko, dass ein Ausfall eines Rechenzentrums oder einer Verfügbarkeitszone ihren Cache nicht verfügbar macht.

Um eine Cachezone redundant zu machen, müssen Sie sie in einer unterstützten Region bereitstellen und für die Verwendung der Hochverfügbarkeitskonfiguration festlegen. In Regionen ohne Verfügbarkeitszonen erstellt die Hochverfügbarkeitskonfiguration weiterhin mindestens zwei Knoten, aber sie werden nicht in separaten Zonen platziert.

Das folgende Diagramm zeigt einen zonenredundanten Cache mit zwei Knoten, jeweils in einer separaten Zone.

Diagramm, das einen Cache mit zwei Knoten zeigt, die über separate Verfügbarkeitszonen verteilt sind, um Zonenredundanz zu ermöglichen.

Anforderungen

  • Regionsunterstützung: Sie können zonenredundante Azure Managed Redis-Caches in jeder Region bereitstellen, die Verfügbarkeitszonen unterstützt und wo der Dienst verfügbar ist. Eine Liste der Regionen, die Verfügbarkeitszonen unterstützen, finden Sie unter 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 verwenden, damit sie zonenredundant ist.

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

Kosten

Zonenredundanz erfordert, dass Sie Ihren Cache für hohe Verfügbarkeit einrichten, wodurch mindestens zwei Knoten für den Cache bereitgestellt werden. Die Konfiguration mit hoher Verfügbarkeit kostet mehr als eine Nichtverfügbarkeitskonfiguration. Weitere Informationen finden Sie unter Azure Managed Redis-Preise.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

  • Erstellen Sie eine neue zonenredundante Instanz. Wenn Sie eine neue Azure Managed Redis-Instanz erstellen, verwenden Sie die Konfiguration für hohe Verfügbarkeit, und stellen Sie sie in einer Region bereit, die Verfügbarkeitszonen unterstützt. Die Instanz enthält standardmäßig Zonenredundanz, ohne dass eine zusätzliche Konfiguration erforderlich ist.

    Weitere Informationen finden Sie unter Erstellen einer Azure Managed Redis-Instanz.

  • Machen Sie einen bestehenden Instanz-Standort redundant. Um eine vorhandene Azure Managed Redis-Instanz in einer Zone redundant zu machen, stellen Sie sie in einer Region bereit, die Verfügbarkeitszonen unterstützt, und richten Sie eine hohe Verfügbarkeit für den Cache ein.

  • Deaktivieren Sie Zonenredundanz. Sie können die Zonenredundanz für vorhandene Instanzen nicht deaktivieren, da Sie die hohe Verfügbarkeit nicht rückgängig machen können, nachdem Sie sie auf einen Cache angewendet haben.

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 In Ihrer Instanz häufig Ressourcendruck auftritt und Sie sich auf ausfallende Verfügbarkeitszonen vorbereiten müssen, sollten Sie einen der folgenden Ansätze berücksichtigen:

  • Überprovisionieren Sie Ihre Instanz. Wählen Sie eine höhere Leistungsstufe aus, als Sie benötigen, damit Ihre Instanz einige Kapazitätsverluste tolerieren und ohne beeinträchtigte Leistung weiterhin funktionieren kann. Weitere Informationen finden Sie unter Kapazität durch Überprovisionierung verwalten und eine Azure Managed Redis-Instanz skalieren.

  • Verwenden Sie die aktive Georeplikation. Sie können mehrere Instanzen in verschiedenen Regionen bereitstellen und die aktive Georeplikation einrichten, um Ihre Last auf diese separaten Instanzen zu verteilen.

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 normal funktionieren:

  • Datenverkehrsrouten zwischen Zonen: Azure Managed Redis verteilt Shards basierend auf Ihrer Cluster-Richtlinie auf Knoten. Ihre Clusterrichtlinie bestimmt auch, wie Datenverkehr zu jedem Knoten weitergeleitet wird. Die Zonenredundanz ändert nicht, wie der Dienst Datenverkehr leitet.

  • Datenreplikation zwischen Zonen: Azure Managed Redis repliziert automatisch Shards über Knoten mithilfe der asynchronen Replikation. Normalerweise messen Sie die Replikationsverzögerung zwischen Shards in Sekunden, aber die genaue Dauer hängt von der Arbeitsauslastung Ihres Caches ab. Schreibintensive und netzwerkintensive Szenarien erleben in der Regel eine höhere Replikationsverzögerung.

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 mehr 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: Der Dienst kann In-Flight-Anforderungen ablegen, und Anwendungen sollten sie erneut versuchen. 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 messen Sie die Menge des Datenverlusts in Sekunden, hängt jedoch von der Replikationsverzögerung ab.

  • Erwartete Ausfallzeiten: Eine kurze Ausfallzeit, in der Regel 10 bis 15 Sekunden, kann auftreten, während Shards auf Knoten in stabilen Zonen umgeschaltet werden. Weitere Informationen zum ungeplanten Failoverprozess finden Sie in der Erläuterung eines Failovers. Folgen Sie beim Entwerfen von Anwendungen den 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

Azure Managed Redis verwaltet Datenverkehrsrouting, Failover und Failback für Zonenfehler vollständig, sodass Sie keine Prozesse für Verfügbarkeitszonenfehler überprüfen oder weitere Eingaben bereitstellen müssen.

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 einrichten.

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 vordefinierter 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 sowie Clientanwendungen, die eine Verbindung mit jeder Cacheinstanz herstellen.

Diagramm, das zwei Caches in verschiedenen Regionen innerhalb derselben aktiven Georeplikationsgruppe zeigt. Anwendungen stellen eine Verbindung zu jeder Instanz her.

Sie sind dafür verantwortlich, Ihre Clientanwendungen so einzurichten, dass Anforderungen an eine fehlerfreie Instanz umgeleitet werden, wenn eine regionale Instanz fehlschlägt. Das folgende Diagramm zeigt, wie eine Anwendung ihre Anforderungen an eine fehlerfreie Cacheinstanz umleiten kann, wenn die Von ihnen in der Regel verwendete Instanz fehlschlägt.

Diagramm, das zwei Caches in verschiedenen Regionen zeigt. Ein Cache ist fehlgeschlagen, und Anwendungen stellen eine Verbindung mit der fehlerfreien Instanz her.

Anforderungen

  • Regionsunterstützung: Sie können die aktive Georeplikation von Azure Managed Redis zwischen allen Azure-Regionen einrichten, in denen der Dienst verfügbar ist.

  • Instanzkonfiguration: Für die aktive Georeplikation sind Azure Managed Redis-Instanzen erforderlich, die die gleiche Ebene und Größe in jeder teilnehmenden Region verwenden. Alle Cacheinstanzen in einer Replikationsgruppe müssen identische Einstellungen verwenden, einschließlich Persistenzoptionen, Module und Clusteringrichtlinien.

  • Weitere Anforderungen: Ihre Cacheinstanzen müssen andere Anforderungen erfüllen, einschließlich der module, die Sie verwenden. Diese Anforderungen wirken sich darauf aus, wie Sie Ihre Cacheinstanzen skalieren 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. Bereiten Sie Ihre Anwendung auf das Failover vor. Failover besteht aus der Vorbereitung und erfordert möglicherweise, dass Sie mehrere Schritte ausführen. Weitere Informationen finden Sie unter Erzwungenes Trennen während eines Regionsausfalls.

  • Schlussendliche Konsistenz: Entwerfen Sie Anwendungen, um Szenarien mit schlussendlicher Konsistenz zu behandeln, da Änderungen je nach Netzwerkbedingungen und geografischer Entfernung Zeit benötigen können, um sich in allen Regionen zu verbreiten. Während Regionsausfällen treten möglicherweise mehr Dateninkonsistenzen auf, bis die Konnektivität wiederhergestellt und die Synchronisierung abgeschlossen ist.

Kosten

Wenn Sie die aktive Georeplikation einrichten, bezahlen Sie für jede Azure Managed Redis-Instanz in jeder Region innerhalb der Replikationsgruppe. Möglicherweise entstehen auch Datenübertragungsgebühren für den regionsübergreifenden Replikationsverkehr zwischen Regionen. Weitere Informationen finden Sie unter Azure Managed Redis Preisinformationen und Bandbreiten-Preisinformationen.

Konfigurieren der Unterstützung für mehrere Regionen

  • Erstellen Sie eine neue geo-replizierte Cacheinstanz. Richten Sie die aktive Georeplikation ein, wenn Sie den Cache bereitstellen, indem Sie eine Replikationsgruppe angeben und mehrere Instanzen verknüpfen. Weitere Informationen finden Sie unter Erstellen oder Beitreten zu einer aktiven Georeplikationsgruppe.

  • Fügen Sie einer Georeplikationsgruppe eine vorhandene Cacheinstanz hinzu. Sie können einer aktiven Georeplikationsgruppe eine vorhandene Cacheinstanz hinzufügen.

    Wenn Sie einer aktiven Georeplikationsgruppe eine vorhandene Instanz hinzufügen, muss die Plattform die Daten in der Instanz löschen, und Sie erleben eine geringe Anzahl von Ausfallzeiten. Planen Sie nach Möglichkeit das Einrichten der aktiven Georeplikation, 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 übrigen Instanzen passen ihre Einstellungen automatisch an.

Kapazitätsplanung und -verwaltung

Während eines regionalen Ausfallereignisses könnten die anderen Instanzen eine höhere Auslastung aufweisen. Wenn eine Instanz häufig in der Nähe der Ressourcengrenzwerte ausgeführt wird und Sie sich auf die erhöhten Kapazitätsanforderungen bei einem Ausfall in der Region vorbereiten müssen, sollten Sie die Instanz überdimensionieren. Weitere Informationen 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 Sie Instanzen für die Verwendung der aktiven Georeplikation einrichten und alle Regionen normal funktionieren.

  • Datenverkehrsrouting zwischen Regionen: Sie sind dafür verantwortlich, Ihre Anwendungen einzurichten, um eine Verbindung mit einer bestimmten Cacheinstanz herzustellen. Anwendungen können eine Verbindung mit einer beliebigen Cacheinstanz in der Replikationsgruppe herstellen und Lese- und Schreibvorgänge ausführen. Die Anwendung behandelt das Datenverkehrsrouting, mit dem Sie Clients für minimale Latenz an die nächste Region weiterleiten können. Azure Managed Redis leitet den Datenverkehr nicht automatisch zwischen Regionen weiter.

  • 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 anschließend im Hintergrund an andere Regionen weitergeleitet. Konfliktfreie replizierte Datentypen (CRDTs) stellen sicher, dass der Dienst automatisch gleichzeitige Schreibvorgänge in verschiedenen Regionen zusammenführt.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie Instanzen für die Verwendung der aktiven Georeplikation einrichten und ein Ausfall in einer Region auftritt.

  • Erkennung und Reaktion: Sie sind dafür verantwortlich, den Ausfall einer Cacheinstanz zu erkennen und zu entscheiden, wann ein Failover durchgeführt werden soll. Sie können den Zustand eines geo-replizierten Clusters überwachen, was Ihnen helfen kann, zu entscheiden, wann das Failover gestartet werden soll. Weitere Informationen finden Sie unter Georeplikationsmetrik.

    Failover erfordert, dass Sie mehrere Schritte ausführen. Weitere Informationen finden Sie unter Erzwungenes Trennen während eines Regionsausfalls.

  • 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, verwenden Sie die Metrik "Fehlerfreie Georeplikation ". Die Metrik weist immer einen Wert von 1 (fehlerfrei) oder 0 (ungesund) auf. Richten Sie Azure Monitor-Warnungen für diese Metrik ein, um zu ermitteln, wann die Instanzen möglicherweise nicht synchronisiert sind.

  • Aktive Anforderungen: Der Dienst beendet Anforderungen an den fehlgeschlagenen Bereich, und die Failoverlogik Ihrer Anwendung muss sie behandeln. Anwendungen sollten Wiederholungsrichtlinien implementieren, die Datenverkehr zu fehlerfreien Caches umleiten können.

  • Erwarteter Datenverlust: Die asynchrone Replikation zwischen Regionen kann zu einem Verlust der letzten Schreibvorgänge in den fehlgeschlagenen Bereich führen, wenn diese Schreibvorgänge 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-distributed Redis und Überlegungen zu Konsistenz und Datenverlust bei einem regionalen Ausfall in einer konfliktfreien replizierten Datenbank (CRDB).

  • 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. Diese Ausfallzeit reicht in der Regel von Sekunden bis zu einigen Minuten und hängt davon ab, wie Sie die Integritätsprüfung und Failoverkonfiguration Ihrer Anwendung einrichten.

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

Region-Wiederherstellung

Wenn eine fehlgeschlagene Region wiederhergestellt wird, integriert Azure Managed Redis Instanzen in dieser Region automatisch ohne Ihre Intervention in die aktive Georeplikationsgruppe. Der Dienst synchronisiert automatisch Daten aus fehlerfreien Instanzen. Während dieses Vorgangs synchronisieren die wiederhergestellten Instanzen schrittweise die Ä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

Testen Sie regelmäßig die Failoverprozeduren Ihrer Anwendung. Ihre Anwendung muss failover-fähig zwischen Instanzen sein und Ihre geschäftlichen Anforderungen an Ausfallzeiten während der Übergangsphase erfüllen. Testen Sie außerdem ihre gesamten Antwortprozesse, einschließlich der Neukonfiguration von Firewalls und anderer Infrastruktur sowie Ihres Wiederherstellungsprozesses.

Resilienz gegenüber Wartungsarbeiten an Diensten

Azure Managed Redis behandelt regelmäßige Dienstupgrades und andere Wartungsaufgaben.

Während der Wartung erstellt Azure Managed Redis automatisch neue Knoten und führt ein Failover durch. Clientanwendungen können unter Verbindungsunterbrechungen und anderen vorübergehenden Fehlern leiden. Anwendungen sollten Wiederholungslogik implementieren , um diese temporären Unterbrechungen zu behandeln.

Weitere Informationen zu verwalteten Redis-Wartungsprozessen in Azure 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, auf die andere Zuverlässigkeitsfeatures möglicherweise nicht abzielen. Sicherungen schützen vor Szenarien wie Datenbeschädigung, versehentlichem Löschen oder Konfigurationsfehlern.

  • Datenpersistenz: Standardmäßig speichert Azure Managed Redis alle Cachedaten im Arbeitsspeicher. Der Dienst kann optional Momentaufnahmen Ihrer Daten mithilfe der Datenpersistenz auf den Datenträger schreiben. Wenn sich ein Hardwarefehler auf den Knoten auswirkt, stellt Azure Managed Redis die Daten automatisch wieder her. Sie können zwischen verschiedenen Arten von Datenpersistenz wählen, die unterschiedliche Kompromisse zwischen Momentaufnahmehäufigkeit und Leistungseffekten für Den Cache bieten.

    Sie können Datendateien nicht in einer anderen Instanz wiederherstellen, 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, wenn Sie die Import- und Exportfunktion verwenden, wodurch Sicherungsdateien in Azure Blob Storage gespeichert werden. Sie können georedundanten Speicher (GRS) in Ihrem Azure Storage-Konto in unterstützten Regionen einrichten, oder Sie können die Sicherungs-BLOBs zum weiteren Schutz kopieren oder auf andere Speicherorte verschieben.

    Sie können exportierte Dateien in derselben Cacheinstanz oder einer anderen Cacheinstanz wiederherstellen.

    Der Dienst enthält keinen integrierten Import- oder Exportplaner, Sie können jedoch eigene Automatisierungsprozesse entwickeln, die die Azure CLI oder Azure PowerShell zum Starten von Exportvorgängen verwenden.

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. Es deckt nicht den Schutz vor Datenverlust ab.

Um für verfügbarkeitsfähige SLAs für Azure Managed Redis berechtigt zu sein, müssen Sie die folgenden Anforderungen erfüllen:

  • Sie müssen eine Hochverfügbarkeitskonfiguration verwenden.

  • 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 werden, wenn Sie zonenredundante Instanzen mithilfe der aktiven Georeplikation in mindestens drei Regionen bereitstellen.

Verwandte Inhalte

  • Last updated on