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) | Ja | Ja | Ja |
| 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) | Ja | Ja | Ja |
| Georeplikation | Verknüpfte Cacheinstanzen in zwei Regionen mit benutzergesteuertem Failover | Premium; Enterprise (siehe Details) | No | Passiv | Aktiv |
| Import/Export | Point-in-Time-Momentaufnahme der Daten im Cache. | 99,9 % (siehe Details) | No | Ja | Ja |
| Persistenz | Regelmäßiges Speichern von Daten im Speicherkonto. | 99,9 % (siehe Details) | No | Ja | 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.
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:
- Primärer Knoten und Replikatknoten verhandeln einen koordinierten Failover und Rollentausch.
- Das Replikat (vorher der primäre Knoten) geht für einen Neustart offline.
- Ein paar Sekunden oder Minuten später geht das Replikat wieder online.
- 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: Standard, Premium, Enterprise, Enterprise Flash
Empfohlen für: Hochverfügbarkeit, Notfallwiederherstellung – innerhalb der Region
Azure Cache for Redis unterstützt zonenredundante Konfigurationen auf den Dienstebenen „Standard“ „Premium“ und „Enterprise“. 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.
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.
Wichtig
Azure Cache for Redis erstellt standardmäßig zonenredundante Caches für die Dienstebenen Premium und Standard mit Automatic_Zonal_Allocation in Regionen, die Zonen unterstützen. Weitere Informationen finden Sie unter Aktivieren der Zonenredundanz für Azure Cache for Redis.
Premium-Tarif
Das folgende Diagramm veranschaulicht die zonenredundante Konfiguration für den Premium-Tarif:
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 Caches auf den Dienstebenen Premium und Standard 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 | Italien, Norden | Vereinigte Arabische Emirate, Norden | Indien, Mitte | |
| USA (Mitte) | Deutschland, Westen-Mitte | Israel, Mitte | Japan, Osten | |
| East US | Norwegen, Osten | |||
| USA (Ost) 2 | Nordeuropa | Asien, Südosten | ||
| USA Süd Mitte | UK, Süden | Asien, Osten | ||
| US Government, Virginia | Europa, Westen | China, Norden 3 | ||
| USA, Westen 2 | Schweden, Mitte | Korea, Mitte | ||
| USA, Westen 3 | Schweiz, Norden | Neuseeland, Norden | ||
| Mexiko, Mitte | Polen, Mitte | |||
| Spanien, Mitte |
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, Osten* | |||
| 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: