Notfallwiederherstellung und Speicherkontofailover

Microsoft möcht sicherstellen, dass Azure-Dienste immer verfügbar sind. Es kann jedoch zu ungeplanten Dienstausfällen kommen. Wenn für Ihre Anwendung Resilienz erforderlich ist, empfiehlt Microsoft die Verwendung eines georedundanten Speichers, damit Ihre Daten in eine zweite Region kopiert werden. Darüber hinaus müssen Kunden einen Notfallwiederherstellungsplan haben, um einen regionalen Dienstausfall handhaben zu können. Ein wichtiger Teil eines Notfallwiederherstellungsplans ist die Vorbereitung auf den Ausfall des sekundären Endpunkts, falls der primäre Endpunkt nicht mehr verfügbar ist.

Azure Storage unterstützt Kontofailover für georedundante Speicherkonten. Mit Kontofailover können Sie den Failoverprozess für Ihr Speicherkonto einleiten, wenn der primäre Endpunkt nicht mehr verfügbar ist. Bei einem Failover wird der sekundäre Endpunkt so aktualisiert, dass er zum primären Endpunkt für das Speicherkonto wird. Nach Abschluss des Failovers können Clients in den neuen primären Endpunkt schreiben.

Kontofailover ist für die Kontotypen „Universell V1“, „Universell V2“ und Blobspeicher mit Azure Resource Manager-Bereitstellungen verfügbar. Ein Kontofailover wird derzeit für Speicherkonten nicht unterstützt, bei denen ein hierarchischer Namespace aktiviert ist.

Dieser Artikel beschreibt die Konzepte und Prozesse, die mit einem Kontofailover verbunden sind, und erläutert, wie Sie Ihr Speicherkonto auf die Wiederherstellung mit dem geringstmöglichen Einfluss auf den Kunden vorbereiten können. Weitere Informationen zum Initiieren eines Kontofailovers im Azure-Portal oder mit PowerShell finden Sie unter Initiieren eines Kontofailovers.

Hinweis

Es wird empfohlen, das Azure Az PowerShell-Modul für die Interaktion mit Azure zu verwenden. Informationen zu den ersten Schritten finden Sie unter Installieren des Azure Az PowerShell-Moduls. Informationen zum Migrieren zum Az PowerShell-Modul finden Sie unter Migrieren von Azure PowerShell von AzureRM zum Az-Modul.

Auswählen der richtigen Redundanzoption

Von Azure Storage werden mehrere Kopien Ihres Speicherkontos geführt, um für Dauerhaftigkeit und Hochverfügbarkeit zu sorgen. Welche Redundanzoption Sie für Ihr Konto wählen, hängt vom Grad der Ausfallsicherheit ab, den Sie benötigen. Zum Schutz vor regionalen Ausfällen konfigurieren Sie Ihr Konto für georedundanten Speicher mit oder ohne die Möglichkeit des Lesezugriffs aus der sekundären Region:

Bei georedundantem Speicher (GRS) bzw. geozonenredundantem Speicher (GZRS) werden Ihre Daten asynchron in zwei geografische Regionen kopiert, die mindestens mehrere Hundert Kilometer voneinander entfernt sind. Wenn es in der primären Region zu einem Ausfall kommt, dann dient die sekundäre Region als redundante Quelle für Ihre Daten. Sie können ein Failover initiieren, um den sekundären Endpunkt in den primären Endpunkt zu transformieren.

Bei georedundantem Speicher mit Lesezugriff (RA-GRS) bzw. geozonenredundantem Speicher mit Lesezugriff (RA-GZRS) verfügen Sie über georedundanten Speicher mit dem zusätzlichen Vorteil des Lesezugriffs auf den sekundären Endpunkt. Tritt ein Ausfall im primären Endpunkt auf, können für Lesezugriff auf den sekundären Endpunkt konfigurierte und auf Hochverfügbarkeit ausgelegte Anwendungen weiterhin vom sekundären Endpunkt aus lesen. Microsoft empfiehlt RA-GZRS, um maximale Verfügbarkeit und Dauerhaftigkeit für Ihre Anwendungen zu gewährleisten.

Weitere Informationen zur Redundanz in Azure Storage finden Sie unter Azure Storage-Redundanz.

Warnung

Bei einem georedundanten Speicher besteht das Risiko eines Datenverlusts. Die Daten werden asynchron in die sekundäre Region kopiert. Dies bedeutet, dass es zu einer Verzögerung zwischen den beiden Zeitpunkten kommt, zu denen die Daten in die primäre bzw. die sekundäre Region geschrieben werden. Bei einem Ausfall gehen Schreibvorgänge auf den primären Endpunkt, die noch nicht auf den sekundären Endpunkt kopiert wurden, verloren.

Entwurf für Hochverfügbarkeit

Es ist wichtig, Ihre Anwendung von Anfang an auf Hochverfügbarkeit auszurichten. Anleitungen zum Entwerfen Ihrer Anwendung und zum Planen der Notfallwiederherstellung finden Sie in diesen Azure-Ressourcen:

Beachten Sie außerdem diese Best Practices zur Aufrechterhaltung der Hochverfügbarkeit Ihrer Azure Storage-Daten:

  • Datenträger: Verwenden Sie den Azure Backup, um die von Ihrem virtuellen Computer verwendeten VM-Datenträger zu sichern. Erwägen Sie auch, Azure Site Recovery zu verwenden, um Ihre VMs im Falle eines regionalen Ausfalls zu schützen.
  • Blockblobs: Aktivieren Sie Vorläufiges Löschen, um das versehentliche Löschen und Überschreiben von Objekten zu verhindern, oder kopieren Sie die Blockblobs in ein anderes Speicherkonto in einer andere Region mithilfe von AzCopy, Azure PowerShell oder Azure Data Movement Library.
  • Dateien: Verwenden Sie Azure Backup, um Ihre Dateifreigaben zu sichern. Aktivieren Sie außerdem die Funktion für vorläufiges Löschen zum Schutz vor versehentlichem Löschen von Dateifreigaben. Um die Georedundanz bei nicht vorhandenem GRS zu erreichen, können Sie AzCopy oder Azure PowerShell verwenden, um die Dateien in ein anderes Speicherkonto in einer anderen Region zu kopieren.
  • Tabellen: Verwenden Sie AzCopy, um die Tabellendaten in ein anderes Speicherkonto in einer anderen Region zu exportieren.

Nachverfolgen von Ausfällen

Kunden können das Azure Service Health-Dashboard abonnieren, um den Zustand und den Status von Azure Storage und von anderen Azure-Diensten zu verfolgen.

Microsoft empfiehlt Ihnen auch, Ihre Anwendung so zu gestalten, dass sie sich auf die Möglichkeit von Schreibfehlern vorbereitet. Ihre Anwendung sollte Schreibfehler so erkennen, dass Sie auf die Möglichkeit eines Ausfalls in der primären Region aufmerksam gemacht werden.

Verstehen des Kontofailoverprozesses

Mit einem von Kunden verwalteten Failover können Sie ein Failover für das gesamte Speicherkonto zur sekundären Region ausführen, wenn die primäre Region aus irgendeinem Grund nicht verfügbar ist. Wenn Sie ein Failover in der sekundären Region erzwingen, können Clients nach Abschluss des Failovers mit dem Schreiben von Daten in den sekundären Endpunkt beginnen. Das Failover dauert i. d. r. etwa eine Stunde.

Hinweis

Kundenverwaltetes Kontofailover wird in Konten mit einem hierarchischen Namespace (Azure Data Lake Storage Gen2) noch nicht unterstützt. Weitere Informationen finden Sie unter Verfügbare Blob Storage-Features in Azure Data Lake Storage Gen2.

Im Falle eines Notfalls, der 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.

Funktionsweise eines Kontofailovers

Unter normalen Umständen schreibt ein Client Daten in ein Azure Storage-Konto in der primären Region, und diese Daten werden asynchron in die sekundäre Region kopiert. Die folgende Abbildung zeigt das Szenario, wenn die primäre Region verfügbar ist:

Clients schreiben Daten in das Speicherkonto in der primären Region

Wenn der primäre Endpunkt aus irgendeinem Grund nicht verfügbar ist, kann der Client nicht mehr in das Speicherkonto schreiben. Das folgende Bild zeigt das Szenario, bei dem das primäre Gerät nicht mehr verfügbar ist, aber noch keine Wiederherstellung stattgefunden hat:

Die primäre Region ist nicht verfügbar, sodass Clients keine Daten schreiben können

Der Kunde initiiert das Kontofailover zum sekundären Endpunkt. Der Failoverprozess aktualisiert den von Azure Storage bereitgestellten DNS-Eintrag, sodass der sekundäre Endpunkt zum neuen primären Endpunkt für Ihr Speicherkonto wird, wie in der folgenden Abbildung dargestellt:

Der Kunde initiiert das Kontofailover zum sekundären Endpunkt

Der Schreibzugriff für georedundante Konten wird wiederhergestellt, sobald der DNS-Eintrag aktualisiert wurde und Anforderungen an den neuen primären Endpunkt geleitet werden. Bestehende Speicherdienstendpunkte für Blobs, Tabellen, Warteschlangen und Dateien bleiben nach dem Failover unverändert.

Wichtig

Nach Abschluss des Failover ist das Speicherkonto so konfiguriert, dass es im neuen primären Endpunkt lokal redundant ist. Um die Replikation zum neuen sekundären Endpunkt fortzusetzen, konfigurieren Sie das Konto erneut für Georedundanz.

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 Wichtige Auswirkungen eines Kontofailoovers.

Vorhersehen von Datenverlust

Achtung

Bei einem Kontofailover kommt es in der Regel zu Datenverlust. Es ist wichtig, die Auswirkungen der Einleitung eines Kontofailover zu verstehen.

Da Daten asynchron von der primären Region in die sekundäre Region geschrieben werden, kommt es immer zu einer Verzögerung, bevor ein Schreibvorgang, der in die primäre Region erfolgt, in die sekundäre Region kopiert wird. Wenn die primäre Region nicht verfügbar ist, wurden die letzten Schreibvorgänge unter Umständen noch nicht in die sekundäre Region kopiert.

Wenn Sie ein Failover erzwingen, gehen alle Daten in der primären Region verloren, da die sekundäre Region zur neuen primären Region wird. Die neue primäre Region ist nach dem Failover als lokal redundant konfiguriert.

Alle bereits in die sekundäre Region kopierten Daten werden beibehalten, wenn das Failover durchgeführt wird. Alle Daten, die in die primäre Region geschrieben und nicht zusätzlich in die sekundäre Region kopiert wurden, gehen aber dauerhaft verloren.

Die Eigenschaft Letzte Synchronisierung gibt an, wann die Daten aus der primären Region garantiert in die sekundäre Region geschrieben wurden. Alle Daten, die vor der letzte Synchronisierung geschrieben wurden, sind in der sekundären Region verfügbar, während Daten, die nach der letzten Synchronisierung geschrieben wurden, möglicherweise nicht in die sekundären Region geschrieben wurden und verloren gehen können. Verwenden Sie diese Eigenschaft im Falle eines Ausfalls, um die Höhe des Datenverlustes abzuschätzen, der Ihnen durch die Einleitung eines Kontofailovers entstehen kann.

Als Best Practice sollten Sie Ihre Anwendung so entwerfen, dass Sie anhand der letzten Synchronisierung den zu erwartenden Datenverlust bewerten können. Wenn Sie beispielsweise alle Schreibvorgänge protokollieren, können Sie die Zeit Ihrer letzten Schreibvorgänge mit der letzten Synchronisierung vergleichen, um festzustellen, welche Schreibvorgänge nicht mit der sekundären Region synchronisiert wurden.

Weitere Informationen zum Überprüfen der Eigenschaft Letzte Synchronisierung finden Sie unter Überprüfen der Eigenschaft „Letzte Synchronisierung“ für ein Speicherkonto.

Seien Sie vorsichtig, wenn Sie ein Failover zur ursprünglichen primären Region durchführen.

Nachdem Sie das Failover von der primären zur sekundären Region durchgeführt haben, ist Ihr Speicherkonto so konfiguriert, dass es in der neuen primären Region lokal redundant ist. Anschließend können Sie das Konto in der neuen primären Region für Georedundanz konfigurieren. Wenn das Konto nach einem Failover für Georedundanz konfiguriert ist, beginnt die neue primäre Region sofort mit dem Kopieren der Daten in die neue sekundäre Region, die vor dem ursprünglichen Failover die primäre war. Es kann aber einige Zeit dauern, bis bestehende Daten in der neuen primären Region vollständig in die neue sekundäre Region kopiert wurden.

Nachdem das Speicherkonto für die Georedundanz neu konfiguriert wurde, ist es möglich, ein Failback von der neuen primären Region zur neuen sekundären Region zu initiieren. In diesem Fall wird die ursprüngliche primäre Region vor dem Failover wieder zur primären Region und ist so konfiguriert, dass sie entweder lokal redundant oder zonenredundant ist, je nachdem, ob die ursprüngliche primäre Konfiguration GRS/RA-GRS oder GZRS/RA-GZRS war. Alle Daten in der primären Region nach dem Failover (die ursprüngliche sekundäre Region) gehen beim Failback verloren. Wenn die meisten Daten im Speicherkonto vor dem Failover nicht in die neue sekundäre Region kopiert wurden, kann es zu einem größeren Datenverlust kommen.

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 erwarteten Datenverlust zu bewerten.

Nach einem Failbackvorgang können Sie die neue primäre Region erneut als georedundant konfigurieren. Wenn der ursprüngliche primäre Server für LRS konfiguriert wurde, können Sie ihn als GRS oder RA-GRS konfigurieren. Wenn der ursprüngliche primäre Server für ZRS konfiguriert wurde, können Sie ihn als GZRS oder RA-GZRS konfigurieren. Weitere Optionen finden Sie unter Ändern der Replikationsweise von Speicherkonten.

Initiieren eines Kontofailovers

Sie können ein Kontofailover über das Azure-Portal, PowerShell, Azure CLI oder die Azure Storage Resource Provider-API initiieren. Weitere Informationen zum Initiieren eines Failovers finden Sie unter Initiieren eines Kontofailovers.

Weitere Überlegungen

Lesen Sie die Erläuterungen in diesem Abschnitt, um zu verstehen, welche Auswirkungen es auf Ihre Anwendungen und Dienste haben kann, wenn Sie ein Failover erzwingen.

Speicherkonto mit archivierten Blobs

Speicherkonten mit archivierten Blobs unterstützen ein Kontofailover. Nachdem das Failover durchgeführt wurde, müssen alle archivierten Blobs auf einer Onlineebene reaktiviert werden, bevor das Konto für Georedundanz konfiguriert werden kann.

Speicherressourcenanbieter

Microsoft stellt zwei REST-APIs für das Arbeiten mit Azure Storage-Ressourcen bereit. Diese APIs bilden die Grundlage für alle Aktionen, die Sie für Azure Storage ausführen können. Die Azure Storage-REST-API ermöglicht Ihnen das Arbeiten mit Daten in Ihrem Speicherkonto, einschließlich Blob-, Warteschlangen-, Datei- und Tabellendaten. Die REST-API des Azure Storage-Ressourcenanbieters ermöglicht Ihnen das Verwalten des Speicherkontos und der zugehörigen Ressourcen.

Nachdem ein Failover abgeschlossen ist, können Clients wieder Azure Storage-Daten lesen und in die neue primäre Region schreiben. Für den Azure Storage-Ressourcenanbieter wird aber kein Failover ausgeführt, sodass die Vorgänge für die Ressourcenverwaltung weiterhin in der primären Region erfolgen müssen. Wenn die primäre Region nicht verfügbar ist, können Sie keine Verwaltungsvorgänge für das Speicherkonto durchführen.

Da für den Azure Storage-Ressourcenanbieter kein Failover ausgeführt wird, gibt die Location-Eigenschaft nach Abschluss des Failovers den ursprünglichen primären Speicherort zurück.

Virtuelle Azure-Computer

Ein Failover wird für Azure-VMs im Rahmen eines Kontofailovers nicht durchgeführt. Wenn die primäre Region nicht verfügbar ist und Sie ein Failover zur primären Region durchführen, müssen Sie nach dem Failover alle VMs neu erstellen. Außerdem ist mit dem Kontofailover ein potenzieller Datenverlust verbunden. Microsoft empfiehlt Ihnen, die spezifischen Informationen zur Hochverfügbarkeit und Notfallwiederherstellung für virtuelle Computer in Azure zu lesen.

Nicht verwaltete Azure-Datenträger

Als Best Practice empfiehlt Microsoft die Konvertierung von nicht verwalteten Datenträgern in verwaltete Datenträger. Wenn Sie jedoch ein Failover für ein Konto ausführen müssen, das nicht verwaltete Datenträger enthält, die an Azure-VMs gekoppelt sind, müssen Sie die VM herunterfahren, bevor Sie das Failover starten.

Nicht verwaltete Datenträger werden als Seitenblobs in Azure Storage gespeichert. Wenn eine VM in Azure ausgeführt wird, werden alle nicht verwalteten, an die VM angeschlossenen Datenträger geleast. Ein Kontofailover kann nicht fortgesetzt werden, wenn für ein Blob eine Lease vorhanden ist. Führen Sie das Failover in folgenden Schritten aus:

  1. Bevor Sie beginnen, notieren Sie sich die Namen aller nicht verwalteten Datenträger, ihre logischen Gerätenummern (LUN) und die VM, an die sie angehängt sind. So können sie die Datenträger nach dem Failover leichter wieder anfügen.
  2. Fahren Sie die VM herunter.
  3. Löschen Sie die VM, behalten Sie aber die VHD-Dateien für den nicht verwalteten Datenträger. Notieren Sie die Zeit, zu der Sie die VM gelöscht haben.
  4. Warten Sie, bis die Letzte Synchronisierung aktualisiert wurde und hinter der Zeit liegt, zu der Sie die VM gelöscht haben. Dieser Schritt ist wichtig. Denn wenn der sekundäre Endpunkt bei Auftreten des Failovers nicht vollständig mit den VHD-Dateien aktualisiert wurde, funktioniert die VM in der neuen primären Region möglicherweise nicht.
  5. Initiieren Sie das Kontofailover.
  6. Warten Sie, bis das Kontofailover abgeschlossen ist und die sekundäre Region zur neuen primären Region geworden ist.
  7. Erstellen Sie eine neue VM in der neuen primären Region, und hängen Sie die VHDs wieder an.
  8. Starten Sie die neue VM.

Beachten Sie, dass alle auf einem temporären Datenträger gespeicherten Daten verloren gehen, wenn die VM heruntergefahren wird.

Nicht unterstützte Features und Dienste

Die folgenden Funktionen und Dienste werden für Kontofailover nicht unterstützt:

  • Speicherkonten mit aktiviertem Änderungsfeed werden für Failover-Vorgänge nicht unterstützt. Beispielsweise ist für die betriebsbezogene Sicherung von Azure Blob Storage der Änderungsfeed erforderlich. Aus diesem Grund unterstützen Speicherkonten, für die die betriebsbezogene Sicherung konfiguriert ist, keine Failover-Vorgänge. Vor dem Initiieren eines Failover-Vorgangs müssen Sie die betriebsbereite Sicherung und alle anderen Features deaktivieren, für die der Änderungsfeed erforderlich ist.
  • Das Speicherkontofailover wird von der Azure-Dateisynchronisierung nicht unterstützt. Für Speicherkonten, die Azure-Dateifreigaben enthalten, die als Cloud-Endpunkte in der Azure-Dateisynchronisierung verwendet werden, sollte kein Failover durchgeführt werden. Dies würde das Funktionieren der Synchronisierung beenden und könnte außerdem bei neu einbezogenen Dateien zu unerwartetem Datenverlust führen.
  • Speicherkonten mit aktiviertem hierarchischem Namespace (z. B. für Data Lake Storage Gen2) werden zurzeit nicht unterstützt.
  • Für ein Speicherkonto mit Premium-Blockblobs kann kein Failover durchgeführt werden. Speicherkonten, die Premium-Blockblobs unterstützen, unterstützen derzeit keine Georedundanz.
  • Für ein Speicherkonto mit Containern mit aktivierter WORM-Unveränderlichkeitsrichtlinie kann kein Failover durchgeführt werden. Entsperrte/gesperrte Richtlinien für die zeitbasierte Aufbewahrung oder die gesetzliche Aufbewahrungspflicht verhindern ein Failover zur Einhaltung der Richtlinien.

Kopieren von Daten als Alternative zum Failover

Wenn Ihr Speicherkonto für Lesezugriff auf den sekundären Endpunkt konfiguriert ist, können Sie die Anwendung so entwerfen, dass Sie vom sekundären Endpunkt liest. Wenn Sie bei einem Ausfall in der primären Region kein Failover ausführen möchten, können Sie Werkzeuge wie AzCopy, Azure PowerShell oder die Azure Data Movement Library verwenden, um Daten von Ihrem Speicherkonto in der sekundären Region in ein anderes Speicherkonto in einer nicht betroffenen Region zu kopieren. Sie können Ihre Anwendungen dann auf dieses Speicherkonto verweisen, sowohl für die Lese- als auch für die Schreibverfügbarkeit.

Achtung

Ein Kontofailover sollte im Rahmen Ihrer Migrationsstrategie für Daten nicht verwendet werden.

Von Microsoft verwaltetes Failover

In extremen Fällen, wenn eine Region durch eine schwerwiegenden Notfall verloren geht, kann Microsoft ein regionales Failover initiieren. In diesem Fall ist keine weitere Aktion erforderlich. Bis zum Abschluss des von Microsoft verwalteten Failovers haben Sie keinen Schreibzugriff auf Ihr Speicherkonto. Ihre Anwendungen können Lesevorgänge aus der sekundären Region ausführen, wenn Ihr Speicherkonto für RA-GRS oder RA-GZRS konfiguriert ist.

Weitere Informationen