Hochverfügbarkeit und Notfallwiederherstellung mit Azure Managed Redis (Vorschau)
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.
In diesem Artikel werden der Kundschaft die Informationen für zum Erstellen eines Business Continuity & Disaster Recovery-Plans für die Implementierung von Azure Managed Redis (Vorschau) erläutert.
Optionen für Hochverfügbarkeit:
| Option | BESCHREIBUNG | Verfügbarkeit |
|---|---|---|
| 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,99 % (siehe Details) |
| Georeplikation | Verknüpfte Cacheinstanzen in zwei Regionen mit benutzergesteuertem Failover | Aktiv (siehe Details) |
| 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) |
Standardreplikation für Hochverfügbarkeit
Empfohlen für: Hochverfügbarkeit
Azure Managed 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 Managed Redis höhere prozentuale Verfügbarkeitsraten als diejenigen, die durch das Hosten von Redis auf einer einzelnen VM erzielt werden können. Ein Azure Managed Redis-Setup wird standardmäßig auf einem Redis-Serverpaar ausgeführt. Die beiden Server werden auf dedizierten virtuellen Computern gehostet.
Bei Azure Managed Redis ist ein Server der primäre Knoten, während der andere das Replikat ist. Nach dem Bereitstellen der Serverknoten weist Azure Managed 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.
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 Managed Redis bietet eine ausführliche Erläuterung zu verschiedenen Typen von Failovers. Eine Azure Managed 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.
Zonenredundanz
Empfohlen für: Hochverfügbarkeit, Notfallwiederherstellung – innerhalb der Region
Azure Managed Redis unterstützt standardmäßig eine zonenredundante Konfiguration. Ein zonenredundanten Cache platziert seine Knoten automatisch in unterschiedliche Azure-Verfügbarkeitszonen in der gleichen Region. Wenn eine Zone ausfällt, sind Cacheknoten in anderen Zonen verfügbar, damit der Cache wie gewohnt funktioniert. Ausfälle im Rechenzentrum oder in einer Verfügbarkeitszone werden als Single Point of Failure behoben und erhöhen die Gesamtverfügbarkeit des Caches.
Erfahrung „Zonenausfall“
Wenn ein Datenknoten ausfällt oder ein Netzwerk aufgeteilt wird, kommt es zu einem Failover. Dieses ähnelt dem unter Standardreplikation beschriebenen Failover. Der Cluster verwendet ein Quorum-basiertes Modell, um zu bestimmen, welche verbleibenden Knoten in einem neuen Quorum teilnehmen. Außerdem werden Replikatpartitionen innerhalb dieser Knoten nach Bedarf zu primären Partitionen heraufgestuft.
Regionale Verfügbarkeit
Zonenredundante 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 |
Persistenz
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, ermöglicht die Redis-Persistenz es Ihnen, regelmäßige Momentaufnahmen von In-Memory-Daten zu erstellen und auf einem verwalteten Datenträger zu speichern, der direkt an die Cache-Instanz angefügt ist. Bei Datenverlusten werden die Cachedaten automatisch mithilfe der Momentaufnahme auf dem verwalteten Datenträger wiederhergestellt. Weitere Informationen finden Sie unter Konfigurieren der Datenpersistenz für eine Azure Managed Redis-Instanz.
Import/Export
Empfohlen für: Notfallwiederherstellung
Azure Managed Redis unterstützt die Option zum Importieren und Exportieren von Redis Database (RDB)-Dateien, um die Datenportabilität bereitzustellen. Es ermöglicht Ihnen, Daten in Azure Managed Redis zu importieren oder Daten aus Azure Managed Redis mithilfe einer RDB-Momentaufnahme zu exportieren. Die RDB-Momentaufnahme aus einem Cache wird in ein Blob in einem Azure Storage-Konto exportiert. Sie können ein Skript erstellen, um den Export in regelmäßigen Abständen in Ihr Speicherkonto auszulösen. Weitere Informationen finden Sie unter Importieren und Exportieren von Daten in Azure Managed 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.
Aktive Georeplikation
Empfohlen für: Hochverfügbarkeit, Notfallwiederherstellung – in mehreren Regionen
Die Georeplikation ist ein Mechanismus zum Verknüpfen von Azure Managed Redis-Instanzen über mehrere Azure-Regionen hinweg. Azure Managed Redis unterstützt eine erweiterte Form der Georeplikation namens aktive Georeplikation, die sowohl eine höhere Verfügbarkeit als auch regionsübergreifende Notfallwiederherstellung über mehrere Regionen hinweg bietet. Die Azure Managed Redis-Software verwendet konfliktfreie replizierte Datentypen, um Schreibvorgänge in mehrere Cache-Instanzen zu unterstützen, Änderungen zusammenzuführen und Konflikte aufzulösen. Sie können bis zu fünf 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 Managed 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
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 verloren gehen, es sei denn, Sie verwenden die aktive Georeplikation. Ihr Anwendungscode sollte gegenüber Datenverlusten resilient sein.
Sobald die betroffene Region wiederhergestellt ist, wird Ihre nicht verfügbarer Azure Managed Redis-Instanz automatisch wiederhergestellt und wieder zur Verwendung verfügbar. Weitere Strategien zum Verschieben Ihres Caches in eine andere Region finden Sie unter Verschieben von Azure Managed Redis-Instanzen in verschiedene Regionen.