Funktionsweise eines kundenseitig verwalteten Speicherkontofailovers
Mit dem vom Kunden verwalteten Failover von Azure Storage-Konten können Sie einen Failover Ihres gesamten georedundanten Speicherkontos in die sekundäre Region vornehmen, wenn die Endpunkte des Speicherdiensts für die primäre Region nicht verfügbar sind. Während des Failovers wird die ursprüngliche sekundäre Region zur neuen primären und alle Speicherdienstendpunkte für Blobs, Tabellen, Warteschlangen und Dateien werden an die neue primäre Region umgeleitet. Nachdem der Ausfall des Speicherdienstendpunkts behoben wurde, können Sie einen weiteren Failovervorgang ausführen, um wieder zum ursprünglichen primären Bereich zurückzukehren.
In diesem Artikel wird beschrieben, was während eines vom Kunden verwalteten Speicherkontofailovers und eines Failbacks in jeder Phase des Prozesses geschieht.
Wichtig
Das Failover eines kundenverwalteten Kontos für Konten mit einem hierarchischen Namespace (Azure Data Lake Storage Gen2) befindet sich derzeit in der VORSCHAU und wird nur in den folgenden Regionen unterstützt:
- (Asien-Pazifik) Indien, Mitte
- (Asien-Pazifik) Asien, Südosten
- (Europa) Europa, Norden
- (Europa) Schweiz, Norden
- (Europa) Schweiz, Westen
- (Europa) Europa, Westen
- (Nordamerika) Kanada, Mitte
- (Nordamerika) USA, Osten 2
- (Nordamerika) USA, Süden-Mitte
Wenn Sie die Vorschauversion aktivieren möchten, informieren Sie sich unter Einrichten von Previewfunktionen im Azure-Abonnement, und geben Sie AllowHNSAccountFailover als Name des Features an.
Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.
Im Falle einer größeren Katastrophe, die sich auf die primäre Region auswirkt, verwaltet Microsoft das Failover für Konten mit einem hierarchischen Namespace. Weitere Informationen finden Sie unter Microsoft-verwaltetes Failover.
Redundanzverwaltung während des Failovers und Failbacks
Tipp
Informationen zu den verschiedenen Redundanzzuständen während des Failovers und Failbackprozesses des Speicherkontos finden Sie unter Azure Storage-Redundanz für Definitionen der einzelnen Zustände.
Wenn ein Speicherkonto für GRS- oder RA-GRS-Redundanz konfiguriert ist, werden Daten dreimal lokal innerhalb der primären und sekundären Regionen (LRS) repliziert. Wenn ein Speicherkonto für die GZRS- oder RA-GZRS-Replikation konfiguriert ist, sind Daten zonenredundant innerhalb der primären Region (ZRS) und dreimal lokal innerhalb der sekundären Region (LRS) repliziert. Wenn das Konto für den Lesezugriff (RA) konfiguriert ist, können Sie Daten aus der sekundären Region lesen, solange die Speicherdienstendpunkte für diese Region verfügbar sind.
Während des vom Kunden verwalteten Failoverprozesses werden die DNS-Einträge für die Speicherdienstendpunkte so geändert, dass die für die sekundäre Region zu den neuen primären Endpunkten für Ihr Speicherkonto werden. Nach dem Failover wird die Kopie Ihres Speicherkontos in der ursprünglichen primären Region gelöscht, und Ihr Speicherkonto wird weiterhin dreimal lokal innerhalb der ursprünglichen sekundären Region (die neue primäre Region) repliziert. Zu diesem Zeitpunkt wird Ihr Speicherkonto lokal redundant (LRS).
Die ursprünglichen und aktuellen Redundanzkonfigurationen werden in den Eigenschaften des Speicherkontos gespeichert, damit Sie schließlich zu Ihrer ursprünglichen Konfiguration zurückkehren können, wenn Sie einen Failback ausführen.
Um Georedundanz nach einem Failover wiederzuerlangen, müssen Sie Ihr Konto als GRS neu konfigurieren. (GZRS ist keine Option nach dem Failover, da die neue primäre Region nach dem Failover LRS ist). Nachdem das Konto für Georedundanz neu konfiguriert wurde, beginnt Azure sofort mit dem Kopieren von Daten aus der neuen primären Region in die neue sekundäre Region. Wenn Sie Ihr Speicherkonto für den Lesezugriff (Read Access, RA) für die sekundäre Region konfigurieren, ist dieser Zugriff verfügbar, es kann jedoch einige Zeit dauern, bis die Replikation von der primären Region erfolgt, um die sekundäre auf den aktuellen Stand zu bringen.
Warnung
Nachdem Ihr Konto für Georedundanz neu konfiguriert wurde, kann es eine erhebliche Zeit dauern, bis vorhandene Daten in der neuen primären Region vollständig in die neue sekundäre Region kopiert werden.
Um einen größeren Datenverlust zu vermeiden, überprüfen Sie vorher den Wert der Eigenschaft Letzte Synchronisierung. Vergleichen Sie die letzte Synchronisierung mit dem Zeitpunkt, an dem die Daten in die neue primäre Region geschrieben wurden, um den potenziellen Datenverlust zu bewerten.
Der Failbackprozess ist im Wesentlichen identisch mit dem Failoverprozess, mit Ausnahme davon, dass Azure die Replikationskonfiguration in den ursprünglichen Zustand wieder herstellt, bevor sie fehlgeschlagen ist (die Replikationskonfiguration, nicht die Daten). Wenn Ihr Speicherkonto also ursprünglich als GZRS konfiguriert wurde, wird die primäre Region nach dem Failback zu ZRS.
Nach einem Failback können Sie Ihr Speicherkonto so konfigurieren, dass es erneut georedundant ist. Wenn die ursprüngliche primäre Region für LRS konfiguriert wurde, können Sie sie als GRS oder RA-GRS konfigurieren. Wenn die ursprüngliche primäre Region für ZRS konfiguriert wurde, können Sie sie als GZRS oder RA-GZRS konfigurieren. Weitere Optionen finden Sie unter Ändern der Replikationsweise von Speicherkonten.
So initiieren Sie einen Failover
Weitere Informationen zum Initiieren eines Failovers finden Sie unter Initiieren eines Speicherkontofailovers.
Achtung
Ein Speicherkontofailover ist in der Regel mit einem gewissen Datenverlust und möglicherweise mit Datei- und Dateninkonsistenzen verbunden. Es ist wichtig zu verstehen, welche Auswirkungen ein Kontofailover auf Ihre Daten haben würde, bevor sie einen solchen initiieren.
Ausführliche Informationen zu potenziellen Datenverlusten und Inkonsistenzen finden Sie unter Antizipieren von Datenverlust und Inkonsistenzen.
Der Failover und der Failbackprozess
In diesem Abschnitt wird der Failoverprozess für einen vom Kunden verwalteten Failover zusammengefasst.
Zusammenfassung des Failoverübergangs
Nach einem vom Kunden verwalteten Failover:
- Die sekundäre Region wird zur neuen primären Region
- Die Kopie der Daten im ursprünglichen primären Bereich wird gelöscht
- Das Speicherkonto wird in LRS konvertiert
- Georedundanz geht verloren
Diese Tabelle fasst die resultierende Redundanzkonfiguration in jeder Phase eines vom Kunden verwalteten Failovers und Failbacks zusammen:
| Original Konfiguration |
Nach failover |
Nach der erneuten Aktivierung Georedundanz |
Nach Failback |
Nach der erneuten Aktivierung Georedundanz |
|---|---|---|---|---|
| GRS | LRS | GRS 1 | LRS | GRS 1 |
| GZRS | LRS | GRS 1 | ZRS | GZRS 1 |
1 Georedundanz geht während eines vom Kunden verwalteten Failovers verloren und muss manuell neu konfiguriert werden.
Details zum Failoverübergang
Die folgenden Diagramme zeigen, was während des vom Kunden verwalteten Failovers und Failbacks eines Speicherkontos geschieht, das für Georedundanz konfiguriert ist. Die Übergangsdetails für GZRS und RA-GZRS unterscheiden sich geringfügig von GRS und RA-GRS.
Normaler Betrieb (GRS/RA-GRS)
Unter normalen Umständen schreibt ein Client Daten über Speicherdienstendpunkte (1) in ein Speicherkonto in der primären Region. Die Daten werden dann asynchron aus dem primären Bereich in die sekundäre Region kopiert (2). Die folgende Abbildung zeigt den normalen Zustand eines Speicherkontos, das als GRS konfiguriert ist, wenn die primären Endpunkte verfügbar sind:
Die Speicherdienstendpunkte sind in der primären Region nicht verfügbar (GRS/RA-GRS)
Wenn die primären Speicherdienstendpunkte aus irgendeinem Grund (1) nicht mehr verfügbar sind, kann der Client nicht mehr in das Speicherkonto schreiben. Je nach der zugrunde liegenden Ursache des Ausfalls funktioniert die Replikation in die sekundäre Region möglicherweise nicht mehr (2), daher sollte mit einem gewissen Maß an Datenverlust gerechnet werden. Das folgende Bild zeigt das Szenario, bei dem die primären Endpunkte nicht mehr verfügbar sind, aber noch keine Wiederherstellung stattgefunden hat:
Der Failoverprozess (GRS/RA-GRS)
Zum Wiederherstellen des Schreibzugriffs auf Ihre Daten können Sie einen Failover initiieren. Die URIs des Speicherdienstendpunkts für Blobs, Tabellen, Warteschlangen und Dateien bleiben unverändert, aber ihre DNS-Einträge werden so geändert, dass sie auf die sekundäre Region (1) verweisen, wie in dieser Abbildung dargestellt:
Der vom Kunden verwaltete Failover dauert in der Regel etwa eine Stunde.
Nach Abschluss des Failovers wird die ursprüngliche sekundäre Region zur neuen primären (1) und die Kopie des Speicherkontos in der ursprünglichen primären Region wird gelöscht (2). Das Speicherkonto wird als LRS in der neuen primären Region konfiguriert und ist nicht mehr georedundant. Benutzer können das Schreiben von Daten in das Speicherkonto (3) fortsetzen, wie in dieser Abbildung gezeigt:
Um die Replikation in eine neue sekundäre Region fortzusetzen, konfigurieren Sie das Konto erneut für Georedundanz.
Wichtig
Beachten Sie, dass die Konvertierung eines lokal redundanten Speicherkontos zur Nutzung von Georedundanz sowohl mit Kosten als auch Zeit verbunden ist. Weitere Informationen finden Sie unter Die Zeit und Kosten eines Failovers.
Nachdem Sie das Konto als GRS neu konfiguriert haben, beginnt Azure mit dem asynchronen Kopieren Ihrer Daten in die neue sekundäre Region (1), wie in dieser Abbildung dargestellt:
Lesezugriff auf die neue sekundäre Region wird erst wieder verfügbar, nachdem das Problem behoben wurde, das den ursprünglichen Ausfall verursacht hat.
Der Failbackprozess (GRS/RA-GRS)
Warnung
Nachdem Ihr Konto für Georedundanz neu konfiguriert wurde, kann es eine erhebliche Zeit dauern, bis die Daten in der neuen primären Region vollständig in die neue sekundäre Region kopiert werden.
Um einen größeren Datenverlust zu vermeiden, überprüfen Sie vorher den Wert der Eigenschaft Letzte Synchronisierung. Vergleichen Sie die letzte Synchronisierung mit dem Zeitpunkt, an dem die Daten in die neue primäre Region geschrieben wurden, um den potenziellen Datenverlust zu bewerten.
Nachdem das Problem behoben wurde, das den ursprünglichen Ausfall verursacht hat, können Sie einen weiteren Failover initiieren, um zur ursprünglichen primären Region zurückzukehren, was zu folgendem Ergebnis führt:
- Die aktuelle primäre Region wird schreibgeschützt.
- Bei vom Kunden initiierten Failover- und Failback-Vorgängen dürfen Ihre Daten während des Failbackprozesses nicht die Replikation in die sekundäre Region abschließen. Daher ist es wichtig, den Wert der Eigenschaft Letzte Synchronisierung zu überprüfen, bevor ein Failback vorgenommen wird.
- Die DNS-Einträge für die Speicherdienstendpunkte werden so geändert, dass die für die sekundäre Region zu den neuen primären Endpunkten für Ihr Speicherkonto werden.
Nachdem der Failback abgeschlossen ist, wird die ursprüngliche primäre Region erneut zur aktuellen (1) und die Kopie des Speicherkontos in der ursprünglichen sekundären Region wird gelöscht (2). Das Speicherkonto ist in der primären Region als lokal redundant konfiguriert und nicht mehr georedundant. Benutzer können das Schreiben von Daten in das Speicherkonto (3) fortsetzen, wie in dieser Abbildung gezeigt:
Um die Replikation in die ursprüngliche sekundäre Region fortzusetzen, konfigurieren Sie das Konto erneut für Georedundanz.
Wichtig
Beachten Sie, dass die Konvertierung eines lokal redundanten Speicherkontos zur Nutzung von Georedundanz sowohl mit Kosten als auch Zeit verbunden ist. Weitere Informationen finden Sie unter Die Zeit und Kosten eines Failovers.
Nach der erneuten Konfiguration des Kontos als GRS wird die Replikation in die ursprüngliche sekundäre Region fortgesetzt, wie in dieser Abbildung dargestellt:
