Hochverfügbarkeit und Notfallwiederherstellung

Wie bei allen Cloud-Systemen können ungeplante Ausfälle auftreten, die dazu führen, dass eine virtuelle Computer (VM)-Instanz, eine Verfügbarkeitszone oder eine vollständige Azure-Region ausfällt. Es wird empfohlen, dass Kunden über einen Plan für die Behandlung von Zonen- oder Regionalausfällen verfügen.

Dieser Artikel enthält Informationen für Kunden zum Erstellen eines Plans für Geschäftskontinuität und Notfallwiederherstellung für ihre Azure Cache for Redis oder Azure Cache for Redis Enterprise Implementierung.

In den Tarifen „Standard“, „Premium“ und „Enterprise“ sind verschiedene Hochverfügbarkeitsoptionen verfügbar:

Option BESCHREIBUNG Verfügbarkeit Standard Premium Enterprise
Standardreplikation Replizierte Konfiguration mit zwei Knoten in einem einzelnen Rechenzentrum mit automatischem Failover 99,9 % (siehe Details)
Zonenredundanz Replizierte Konfiguration mit mehreren Knoten in allen Verfügbarkeitszonen mit automatischem Failover 99,9 % in Premium; 99,99 % in Enterprise (siehe SLA für Azure Cache for Redis) -
Georeplikation Verknüpfte Cacheinstanzen in zwei Regionen mit benutzergesteuertem Failover Premium; Enterprise (siehe Details) - Passiv Aktiv
Import/Export Point-in-Time-Momentaufnahme der Daten im Cache. 99,9 % (siehe Details) -
Persistenz Regelmäßiges Speichern von Daten im Speicherkonto. 99,9 % (siehe Details) - Vorschau

Standardreplikation für Hochverfügbarkeit

Anwendbare Ebenen: Standard, Premium, Enterprise, Enterprise Flash

Empfohlen für: Hochverfügbarkeit

Azure Cache for Redis verfügt über eine Hochverfügbarkeitsarchitektur, die sicherstellt, dass Ihre verwaltete Instanz funktioniert, auch wenn sich Ausfälle auf die zugrunde liegenden virtuellen Computer (VMs) auswirken. Unabhängig davon, ob der Ausfall geplant oder ungeplant ist, bietet Azure Cache for Redis höhere prozentuale Verfügbarkeitsraten als die, die durch das Hosten von Redis auf einem einzelnen virtuellen Computer erzielt werden.

Eine Azure Cache for Redis-Instanz im entsprechenden Tarif wird standardmäßig auf zwei Redis-Servern ausgeführt. Die beiden Server werden auf dedizierten virtuellen Computern gehostet. Bei Open-Source-Redis können Anforderungen zum Schreiben von Daten nur auf einem Server verarbeitet werden.

Bei Azure Cache for Redis ist ein Server der primäre Knoten, der andere das Replikat. Nach dem Bereitstellen der Serverknoten weist Azure Cache for Redis diesen die primäre und die Replikatrolle zu. Der primäre Knoten ist normalerweise für die Verarbeitung von Schreib- und Leseanforderungen von Redis-Clients verantwortlich. Bei einem Schreibvorgang wird ein neuer Schlüssel und eine Schlüsselaktualisierung in den internen Speicher des Knotens übertragen und sofort eine Antwort an den Client gesendet. Der Vorgang wird asynchron an das Replikat weitergeleitet.

Data replication setup

Hinweis

Normalerweise kommuniziert der Client in einem Redis-Cache bei allen Lese- und Schreibanforderungen mit dem primären Knoten in einem Cache. Bestimmte Clients können so konfiguriert werden, dass sie vom Replikatknoten lesen.

Wenn der primäre Knoten in einem Redis-Cache nicht verfügbar ist, stuft das Replikat sich automatisch selbst zum primären Knoten hoch. Dieser Prozess wird als Failover bezeichnet. Ein Failover umfasst nur zwei Knoten (primärer Knoten/Replikat, Rollentausch, Replikat/primärer Knoten), wobei einer der Knoten möglicherweise einige Minuten offline geht. Bei den meisten Failovern koordinieren der primäre Knoten und der Replikatknoten die Übergabe so, dass die Zeit ohne primären Knoten sehr kurz ist.

Der ehemalige primäre Knoten geht kurz offline, um Updates vom neuen primären Knoten zu erhalten. Anschließend wird das jetzige Replikat wieder online geschaltet und wieder mit dem vollständig synchronisierten Cache vereint. Wesentlich dabei ist, dass der Zustand ohne verfügbaren Knoten nur vorübergehend ist und der Knoten wieder online geschaltet wird.

Eine typische Failoversequenz sieht wie folgt aus, wenn ein primärer Knoten für die Wartung offline geschaltet werden muss:

  1. Primärer Knoten und Replikatknoten verhandeln einen koordinierten Failover und Rollentausch.
  2. Das Replikat (vorher der primäre Knoten) geht für einen Neustart offline.
  3. Ein paar Sekunden oder Minuten später geht das Replikat wieder online.
  4. Das Replikat synchronisiert die Daten vom primären Knoten.

Ein primärer Knoten kann als Teil einer geplanten Wartungsaktivität wie etwa Redis-Softwareupdate oder Betriebssystemupdate außer Betrieb genommen werden. Er kann auch aufgrund ungeplanter Ereignisse wie z. B. Fehlern in der zugrunde liegenden Hardware, Software oder im Netzwerk ausfallen. Failover und Patchen für Azure Cache for Redis bietet eine ausführliche Erläuterung zu verschiedenen Typen von Failovers. Eine Azure Cache for Redis-Instanz durchläuft während ihrer Lebensdauer viele Failover. Das Design der Hochverfügbarkeitsarchitektur macht diese Änderungen innerhalb eines Caches für seine Kunden so transparent wie möglich.

Azure Cache for Redis bietet außerdem im Tarif „Premium“ zusätzliche Replikatknoten. Ein Cache mit mehreren Replikaten kann mit bis zu drei Replikatknoten konfiguriert werden. Durch mehrere Replikate verbessert sich im Allgemeinen die Resilienz, da der primäre Knoten durch Knoten abgesichert wird. Auch mit mehreren Replikaten kann eine Azure Cache for Redis-Instanz immer noch ernstlich durch einen Ausfall eines Rechenzentrums oder einen Ausfall auf Verfügbarkeitszone beeinträchtigt werden. Sie können die Cacheverfügbarkeit erhöhen, indem Sie mehrere Replikate mit Zonenredundanz verwenden.

Zonenredundanz

Anwendbare Ebenen: Premium, Enterprise, Enterprise Flash

Empfohlen für: Hochverfügbarkeit, Notfallwiederherstellung – innerhalb der Region

Zonenredundante Konfigurationen werden von Azure Cache for Redis in den Tarifen „Premium“ und „Enterprise“ unterstützt. Bei einem zonenredundanten Cache können die zugehörigen Knoten in unterschiedlichen Azure-Verfügbarkeitszonen derselben Region platziert werden. Ausfälle im Rechenzentrum oder in einer Verfügbarkeitszone werden als Single Point of Failure behoben. Damit wird die Gesamtverfügbarkeit des Caches erhöht. Weitere Informationen zur Einrichtung finden Sie in diesem Artikel.

Wenn ein Cache für die Verwendung von zwei oder mehr Zonen konfiguriert ist, so wie weiter oben im Artikel beschrieben, werden die Cacheknoten in verschiedenen Zonen erstellt. Wenn eine Zone ausfällt, sind Cacheknoten in anderen Zonen verfügbar, damit der Cache wie gewohnt funktioniert.

Zonenredundante Konfigurationen werden von Azure Cache for Redis in den Tarifen „Premium“ und „Enterprise“ unterstützt. Bei einem zonenredundanten Cache können die zugehörigen Knoten in unterschiedlichen Azure-Verfügbarkeitszonen derselben Region platziert werden. Ausfälle im Rechenzentrum oder in einer Verfügbarkeitszone werden als Single Point of Failure behoben und erhöhen die Gesamtverfügbarkeit des Caches.

Premium-Tarif

Das folgende Diagramm veranschaulicht die zonenredundante Konfiguration für den Premium-Tarif:

Zone redundancy setup

Azure Cache for Redis verteilt Knoten in einem zonenredundanten Cache im Rundlaufverfahren auf die ausgewählten Verfügbarkeitszonen. Außerdem wird der Knoten bestimmt, der anfänglich als primärer Knoten fungiert.

Zonenausfall für den Premium-Tarif

Ein zonenredundanter Cache ermöglicht ein automatisches Failover. Wenn der aktuelle primäre Knoten nicht verfügbar ist, wird er durch einen der Replikatknoten ersetzt. Wenn sich der neue primäre Knoten in einer anderen Verfügbarkeitszone befindet, bedeutet dies für die Anwendung möglicherweise eine längere Cacheantwortzeit. Verfügbarkeitszonen sind geografisch getrennt. Durch den Wechsel zwischen Verfügbarkeitszonen ändert sich die physische Entfernung zwischen den Orten, an denen die Anwendung und der Cache gehostet werden. Diese Änderung wirkt sich auf Roundtrip-Netzwerklatenzen zwischen Anwendung und Cache aus. Bei den meisten Anwendungen wird davon ausgegangen, dass die zusätzliche Latenz innerhalb eines akzeptablen Bereichs liegt. Es wird empfohlen, Ihre Anwendung zu testen, um sicherzustellen, dass sie mit einem zonenredundanten Cache ordnungsgemäß ausgeführt wird.

Enterprise- und Enterprise Flash-Tarife

Ein Cache in einem der Enterprise-Tarife basiert auf einem Redis Enterprise-Cluster. Zur Bildung eines Quorums muss immer eine ungerade Anzahl von Serverknoten vorhanden sein. Standardmäßig umfasst es drei Knoten, die jeweils auf einem dedizierten virtuellen Computer gehostet werden.

  • Ein Enterprise-Cache verfügt über zwei gleich große Datenknoten und über einen kleineren Quorumknoten.
  • Ein Enterprise Flash-Cache verfügt über drei gleich große Datenknoten.

Der Enterprise-Cluster unterteilt den Azure-Cache intern für Redis-Daten. Jede Partition verfügt über ein primäres Element und über mindestens ein Replikat. Jeder Datenknoten enthält mindestens eine Partition. Der Enterprise-Cluster stellt sicher, dass sich das primäre Element und die Replikate einer Partition nie auf dem gleichen Datenknoten befinden. Partitionsdaten von primären Elementen werden asynchron in zugehörigen Replikaten repliziert.

Zonenausfall für Enterprise-Tarife

Wenn ein Datenknoten ausfällt oder ein Netzwerk aufgeteilt wird, kommt es zu einem Failover. Dieses ähnelt dem unter Standardreplikation beschriebenen Failover. Der Enterprise-Cluster verwendet ein quorumbasiertes Modell, um zu bestimmen, welche verbleibenden Knoten ein neues Quorum bilden. Außerdem werden Replikatpartitionen innerhalb dieser Knoten nach Bedarf zu primären Partitionen heraufgestuft.

Regionale Verfügbarkeit

Zonenredundante Premium-Tarif-Caches sind in den folgenden Regionen verfügbar:

Amerika Europa Naher Osten Afrika Asien-Pazifik
Brasilien Süd Frankreich, Mitte Katar, Mitte Südafrika, Norden Australien (Osten)
Kanada, Mitte Deutschland, Westen-Mitte Indien, Mitte
USA (Mitte) Nordeuropa Japan, Osten
East US Norwegen, Osten Korea, Mitte
USA (Ost) 2 UK, Süden Asien, Südosten
USA Süd Mitte Europa, Westen Asien, Osten
US Government, Virginia Schweden, Mitte China, Norden 3
USA, Westen 2 Schweiz, Norden
USA, Westen 3

Zonenredundante Enterprise- und Enterprise Flash-Tarif-Caches sind in den folgenden Regionen verfügbar:

Amerika Europa Naher Osten Afrika Asien-Pazifik
Kanada, Mitte* Nordeuropa Australien (Osten)
USA, Mitte* UK, Süden Indien, Mitte
East US Europa, Westen Asien, Südosten
USA (Ost) 2 Japan Ost*
USA Süd Mitte Asien (Osten)*
USA, Westen 2
USA, Westen 3
Brasilien, Süden

* Enterprise Flash-Tarif in dieser Region nicht verfügbar.

Erneute Bereitstellung und Migration von Verfügbarkeitszonen

Derzeit besteht die einzige Möglichkeit zum Konvertieren ihres Caches aus einer Nicht-AZ-Konfiguration in eine AZ-Konfiguration darin, den Cache erneut bereitzustellen. Informationen zum erneuten Bereitstellen Ihres aktuellen Caches finden Sie unter Migrieren einer Azure Cache for Redis-Instanz zur Unterstützung von Verfügbarkeitszonen.

Persistenz

Anwendbare Ebenen: Premium, Enterprise (Vorschau), Enterprise Flash (Vorschau)

Empfohlen für: Datenbeständigkeit

Weil Ihre Cachedaten im Arbeitsspeicher gespeichert werden, kann ein seltener und ungeplanter Ausfall mehrerer Knoten dazu führen, dass alle Daten gelöscht werden. Um den vollständigen Verlust von Daten zu vermeiden, können Sie mit Redis-Persistenz regelmäßige Momentaufnahmen von In-Memory-Daten erstellen und in Ihrem Speicherkonto speichern. Wenn ein Fehler auf mehreren Knoten zu Datenverlusten führt, lädt Ihr Cache die Momentaufnahme aus dem Speicherkonto. Weitere Informationen finden Sie unter Konfigurieren von Datenpersistenz für ein Premium Azure Cache für die Redis-Instanz.

Speicherkonto für Persistenz

Erwägen Sie die Auswahl eines georedundanten Speicherkontos, um die Hochverfügbarkeit persistenter Daten sicherzustellen. Weitere Informationen finden Sie unter Azure Storage-Redundanz.

Importieren/Exportieren

Anwendbare Ebenen: Premium, Enterprise, Enterprise Flash

Empfohlen für: Notfallwiederherstellung

Azure Cache for Redis unterstützt die Option zum Importieren und Exportieren von Dateien aus Redis Database (RDB), um Datenportabilität bereitzustellen. Es ermöglicht Ihnen, Daten im Azure Cache for Redis zu importieren oder Daten aus dem Azur Cache für Redis mithilfe einer RDB-Momentaufnahme zu exportieren. Die RDB-Momentaufnahme aus einem Premium-Cache wird in ein Blob in einem Azure Speicherkonto exportiert. Sie können ein Skript erstellen, um den Export in regelmäßigen Abständen in Ihr Speicherkonto auszulösen. Weitere Informationen und Anweisungen finden Sie unter Importieren und Exportieren von Daten im Azure Cache für Redis.

Speicherkonto für den Export

Erwägen Sie die Auswahl eines georedundanten Speicherkontos, um die Hochverfügbarkeit Ihrer exportierten Daten sicherzustellen. Weitere Informationen finden Sie unter Azure Storage-Redundanz.

Passive Georeplikation

Anwendbare Ebenen: Premium

Empfohlen für: Notfallwiederherstellung – einzelne Region

Georeplikation ist ein Mechanismus zum Verknüpfen von zwei oder mehr Azure Cache for Redis-Instanzen, die in der Regel zwei Azure-Regionen umfassen. Die Georeplikation ist im Wesentlichen für die regionsübergreifende Notfallwiederherstellung konzipiert. Zwei Premium-Cache-Instanzen sind per Georeplikation verbunden, die Lese- und Schreibvorgänge in Ihren primären Cache bereitstellt, und diese Daten werden in den sekundären Cache repliziert.

Weitere Informationen zur Einrichtung finden Sie unter Konfigurieren der Georeplikation für Premium Azure Cache für Redis-Instanzen.

Wenn die Region, in der der primäre Cache gehostet wird, ausfällt, müssen Sie das Failover starten, indem Sie zuerst die Verknüpfung des sekundären Caches aufheben und dann Ihre Anwendung aktualisieren, um auf den sekundären Cache für Lese- und Schreibvorgänge zu verweisen.

Aktive Georeplikation

Anwendbare Ebenen: Enterprise, Enterprise Flash

Empfohlen für: Hochverfügbarkeit, Notfallwiederherstellung – in mehreren Regionen

Die Enterprise-Tarife unterstützen eine erweiterte Form der Georeplikation namens aktive Georeplikation, die sowohl eine höhere Verfügbarkeit als auch regionsübergreifende Notfallwiederherstellung über mehrere Regionen bietet. Die Azure Cache for Redis Enterprise Software verwendet konfliktfreie replizierte Datentypen, um Schreibvorgänge in mehrere Cache-Instanzen zu unterstützen, Änderungen zusammenzuführen und Konflikte zu lösen. Sie können bis zu fünf Enterprise-Ebenen mit Cache-Instanzen in verschiedenen Azure-Regionen verbinden, um eine Georeplikationsgruppe zu bilden.

Eine Anwendung, die einen solchen Cache verwendet, kann über entsprechende Endpunkte in allen geografisch verteilten Cache-Instanzen lesen und schreiben. Der Anwendung sollte dabei immer den zur jeweiligen Anwendungsinstanz nächstgelegenen Cache verwenden, um Ihnen die niedrigsten Wartezeiten zu liefern. Weitere Informationen finden Sie unter Konfigurieren der aktiven Georeplikation für Azure Cache für Redis-Instanzen.

Wenn eine Region eines der Caches in Ihrer Replikationsgruppe ausfällt, muss Ihre Anwendung zu einer anderen verfügbaren Region wechseln.

Wenn ein Cache in Ihrer Replikationsgruppe nicht verfügbar ist, wird empfohlen, die Speicherauslastung für andere Caches in derselben Replikationsgruppe zu überwachen. Während einer der Caches ausgefallen ist, beginnen alle anderen Caches in der Replikationsgruppe damit, Metadaten zu speichern, die sie nicht für den Cache freigeben konnten, der ausgefallen ist. Wenn die Arbeitsspeicherauslastung für die verfügbaren Caches mit einer hohen Rate anwächst, nachdem einer der Caches ausfällt, sollten Sie die Verknüpfung des Caches aufheben, der in der Replikationsgruppe nicht verfügbar ist.

Weitere Informationen zum Aufheben der Verknüpfung finden Sie unter Force-Unlink bei regionalem Ausfall .

Löschen und Neuerstellen des Caches

Anwendbare Ebenen: Standard, Premium, Enterprise, Enterprise Flash

Wenn es zu einem regionalen Ausfall kommt, sollten Sie den Cache in einer anderen Region neu erstellen und Ihre Anwendung aktualisieren, um stattdessen eine Verbindung mit dem neuen Cache herzustellen. Es ist wichtig zu verstehen, dass Daten während eines regionalen Ausfalls verlorengehen. Ihr Anwendungscode sollte gegenüber Datenverlusten resilient sein.

Nachdem die betroffene Region wiederhergestellt wurde, wird Ihr nicht verfügbarer Azure Cache for Redis automatisch wiederhergestellt und wieder zur Verwendung verfügbar. Weitere Strategien zum Verschieben Ihres Caches in eine andere Region finden Sie unter Verschieben von Azure Cache für Redis-Instanzen in verschiedene Regionen.

Nächste Schritte

Weitere Informationen zum Konfigurieren von Hochverfügbarkeitsoptionen von Azure Cache for Redis: