Funktionsweise kundenseitig verwalteter (ungeplanter) Failover
Mit dem kundenseitig verwalteten (ungeplanten) Failover 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 Region. Alle Speicherdienstendpunkte werden dann an die neue primäre Region umgeleitet. Nachdem der Ausfall des Speicherdienstendpunkts behoben ist, 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 kundenseitig verwalteten (ungeplanten) Failovers und eines Failbacks in jeder Phase des Prozesses geschieht.
Wichtig
Das kundenseitig verwaltete (ungeplante) Failover für Konten, für die Azure Data Lake Storage Gen2 aktiviert ist, befindet sich derzeit in der PREVIEW und wird in allen öffentlichen GRS/GZRS-Regionen unterstützt.
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.
Wichtig
Das kundenseitig verwaltete (ungeplante) Failover für Konten, für die das SSH-Dateiübertragungsprotokoll (SSH File Transfer Protocol, SFTP) aktiviert ist, befindet sich derzeit in der VORSCHAUPHASE und wird lediglich 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
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 ungeplanten Failovers und Failbacks
Tipp
Informationen zu den verschiedenen Redundanzzuständen während des ungeplanten Failovers und Failbackprozesses finden Sie unter Azure Storage-Redundanz für Definitionen der einzelnen Zustände.
Wenn ein Speicherkonto für georedundanten Speicher (GRS) oder georedundanten Speicher mit Lesezugriff (RA-GRS) konfiguriert ist, werden Daten dreimal innerhalb der primären und sekundären Regionen des lokalen redundanten Speichers (LRS) repliziert. Wenn ein Speicherkonto für die Replikation im geozonenredundanten Speicher (GZRS) oder im geozonenredundanten Speicher mit Lesezugriff (RA-GZRS) konfiguriert ist, sind Daten in der primären Region des zonenredundanten Speichers (ZRS) zonenredundant und werden innerhalb der sekundären LRS-Region dreimal 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 (ungeplanten) Failoverprozesses werden die DNS-Einträge (Domain Name System) für die Speicherdienstendpunkte gewechselt. Die sekundären Endpunkte Ihres Speicherkontos werden zu den neuen primären Endpunkten und die ursprünglichen primären Endpunkte werden zu den neuen sekundären. 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 neuen primären Region repliziert. Zu diesem Zeitpunkt wird Ihr Speicherkonto lokal redundant und verwendet LRS.
Die ursprünglichen und aktuellen Redundanzkonfigurationen werden innerhalb der Eigenschaften des Speicherkontos gespeichert. Dank dieser Funktion können Sie zu Ihrer ursprünglichen Konfiguration zurückkehren, wenn Sie einen Fehler gemacht haben. Eine vollständige Liste der resultierenden Redundanzkonfigurationen finden Sie unter Wiederherstellungsplanung und Failover.
Um Georedundanz nach einem Failover wiederzuerlangen, müssen Sie Ihr Konto als GRS neu konfigurieren. 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 auf die sekundäre Region konfigurieren, ist dieser Zugriff verfügbar. Die Replikation von der primären in die sekundäre Region kann jedoch einige Zeit in Anspruch nehmen.
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. Um potenzielle Datenverluste auszuwerten, vergleichen Sie die letzte Synchronisierungszeit mit dem letzten Zeitpunkt, zu dem Daten in die neue Primäre geschrieben wurden.
Der Failbackprozess ist im Wesentlichen identisch mit dem Failoverprozess, abgesehen davon, dass die Replikationskonfiguration im ursprünglichen Zustand vor dem Failover wiederhergestellt wird.
Nach einem Failback können Sie Ihr Speicherkonto neu konfigurieren, um die Georedundanz zu nutzen. 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.
Wie Sie ein ungeplantes Failover initiieren
Weitere Informationen zum Initiieren eines Failovers finden Sie unter Initiieren eines ungeplanten Failovers.
Achtung
Ein ungeplanter Failover 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 diese Art von Failover initiieren.
Ausführliche Informationen zu potenziellen Datenverlusten und Inkonsistenzen finden Sie unter Antizipieren von Datenverlust und Inkonsistenzen.
Der ungeplante Failover- und Failbackprozess
In diesem Abschnitt wird der Failoverprozess für einen kundenseitig verwalteten (ungeplanten) Failover zusammengefasst.
Zusammenfassung des ungeplanten Failoverübergangs
Nach einem kundenseitig verwalteten (ungeplanten) 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 kundenseitig verwalteten (ungeplanten) 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 (ungeplanten) Failovers verloren und muss manuell neu konfiguriert werden.
Details zum ungeplanten Failoverübergang
Die folgenden Diagramme zeigen den kundenseitig verwalteten (ungeplanten) Failover- und Failbackprozess eines Speicherkontos, 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. Die folgende Abbildung zeigt das Szenario, in dem die primären Endpunkte nicht verfügbar sind, aber bevor die Wiederherstellung eintritt:
Der ungeplante 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 den sekundären Bereich verweisen, wie gezeigt:
Der kundenseitig verwaltete (ungeplante) Failover dauert in der Regel etwa eine Stunde.
Nach Abschluss des Failovers wird die ursprüngliche sekundäre Region zur neuen primären (1) Region, 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 zur Verwendung von GRS neu konfiguriert haben, beginnt Azure mit dem asynchronen Kopieren Ihrer Daten in die neue sekundäre Region (1), wie in dieser Abbildung dargestellt:
Der Lesezugriff auf den neuen sekundären Bereich ist erst wieder verfügbar, wenn das Problem behoben wurde, das den ursprünglichen Ausfall verursacht.
Der ungeplante Failbackprozess (GRS/RA-GRS)
Warnung
Nachdem Ihr Konto für die 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 Failback in den ursprünglichen primären Bereich initiieren. Dieser Prozess wird in den folgenden Bildern beschrieben:
- 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 umgeschaltet. Die Endpunkte innerhalb der sekundären Region werden zu den neuen primären Endpunkten für Ihr Speicherkonto.
Nachdem das 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 für die 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:
