Azure Storage: Planen der Notfallwiederherstellung und Durchführen eines Failovers

  • Artikel

Microsoft möcht sicherstellen, dass Azure-Dienste immer verfügbar sind. Es kann jedoch zu ungeplanten Dienstausfällen kommen. Zu den wichtigsten Komponenten eines guten Plans für die Notfallwiederherstellung gehören Strategien für:

In diesem Artikel geht es um das Failover für global redundante Speicherkonten (GRS, GZRS und RA-GZRS) und darum, wie Sie Ihre Anwendungen so gestalten, dass sie bei einem Ausfall und einem anschließenden Failover hochverfügbar bleiben.

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 von dem Grad der Ausfallsicherheit ab, den Sie für Ihre Anwendungen benötigen.

Mit lokal redundantem Speicher (LRS) werden drei Kopien Ihres Speicherkontos automatisch innerhalb eines einzelnen Rechenzentrums gespeichert und repliziert. Bei zonenredundantem Speicher (ZRS) wird in jeder der drei separaten Verfügbarkeitszonen innerhalb derselben Region eine Kopie gespeichert und repliziert. Weitere Informationen zu Verfügbarkeitszonen finden Sie unter Azure-Verfügbarkeitszonen.

Die Wiederherstellung einer einzelnen Kopie eines Speicherkontos erfolgt bei LRS und ZRS automatisch.

Global redundanter Speicher und Failover

Bei global redundantem Speicher (GRS, GZRS und RA-GZRS) kopiert Azure Ihre Daten asynchron in eine zweite geografische Region, die sich mindestens einige hundert Kilometer entfernt befindet. So können Sie Ihre Daten wiederherstellen, wenn es in der primären Region zu einem Ausfall kommt. Ein Feature, das den global redundanten Speicher vom lokal redundanten (LRS) und dem zonenredundanten Speicher (ZRS) unterscheidet, ist die Fähigkeit, bei einem Ausfall der primären Region ein Failover auf die sekundäre Region durchzuführen. Bei einem Failover werden die DNS-Einträge für die Dienstendpunkte Ihres Speicherkontos so aktualisiert, dass die Endpunkte für die sekundäre Region zu den neuen primären Endpunkten für Ihr Speicherkonto werden. Sobald das Failover abgeschlossen ist, können die Clients damit beginnen, Schreibvorgänge auf den neuen primären Endpunkten durchzuführen.

RA-GRS- und RA-GZRS-Redundanzkonfigurationen bieten georedundanten Speicher mit dem zusätzlichen Vorteil eines Lesezugriffs für den sekundären Endpunkt, falls es in der primären Region zu einem Ausfall kommt. Wenn der primäre Endpunkt ausfällt, können Anwendungen, die für den Lesezugriff auf die sekundäre Region konfiguriert und auf Hochverfügbarkeit ausgelegt sind, weiterhin Lesevorgänge auf dem sekundären Endpunkt ausführen. Microsoft empfiehlt RA-GZRS, um maximale Verfügbarkeit und Dauerhaftigkeit für Ihre Speicherkonten zu gewährleisten.

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

Planen eines Speicherkontofailovers

Azure Storage-Konten unterstützen zwei Arten von Failover:

1Das von Microsoft verwaltete Failover kann nicht für einzelne Speicherkonten, Abonnements oder Mandanten eingeleitet werden. Weitere Details finden Sie unter Von Microsoft verwaltetes Failover.
2 Ihr Plan zur Notfallwiederherstellung sollte auf einem kundenseitig verwalteten Failover beruhen. Verlassen Sie sich nicht auf das von Microsoft verwaltete Failover, da dieses nur in Extremsituationen zum Einsatz kommt.

Für jede Art von Failover gibt es bestimmte Anwendungsfälle, entsprechende Erwartungen in Bezug auf Datenverlust sowie Unterstützung für Konten mit einem aktivierten hierarchischen Namespace (Azure Data Lake Storage Gen2). Diese Tabelle fasst diese Aspekte der einzelnen Failovertypen zusammen:

Typ Failoverbereich Anwendungsfälle Erwarteter Datenverlust HNS unterstützt
Vom Kunden verwaltet Speicherkonto Die Speicherdienstendpunkte für die primäre Region sind ausgefallen, aber die sekundäre Region ist verfügbar.

Sie haben eine Azure-Empfehlung erhalten, in der Microsoft Ihnen rät, einen Failovervorgang für Speicherkonten durchzuführen, die möglicherweise von einem Ausfall betroffen sind.		 Ja Ja (in der Vorschau)
von Microsoft verwaltet Gesamte Region oder Skalierungseinheit Die primäre Region ist aufgrund eines schwerwiegenden Notfalls ausgefallen, aber die sekundäre Region ist verfügbar. Ja Ja

Kundenverwaltetes Failover

Wenn die Datenendpunkte für die Speicherdienste in Ihrem Speicherkonto in der primären Region nicht mehr verfügbar sind, können Sie auf die sekundäre Region ausweichen. Nach Abschluss des Failovers wird die sekundäre Region zur neuen primären Region und die Benutzer*innen können auf die Daten in der neuen primären Region zugreifen.

Damit Sie die Auswirkungen eines kundenseitig verwalteten Kontofailovers auf Ihre Benutzer*innen und Anwendungen in vollem Umfang nachvollziehen können, müssen Sie wissen, was bei jedem Schritt des Failover- und Failbackprozesses passiert. Einzelheiten darüber, wie der Prozess funktioniert, finden Sie unter Funktionsweise eines kundenseitig verwalteten Speicherkontofailovers.

Von Microsoft verwaltetes Failover

In Extremsituationen, in denen die ursprüngliche primäre Region aufgrund eines schwerwiegenden Notfalls als nicht innerhalb eines angemessenen Zeitraums wiederherstellbar erachtet wird, kann Microsoft ein regionales Failover einleiten. 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.

Wichtig

Ihr Plan zur Notfallwiederherstellung sollte auf einem kundenseitig verwalteten Failover beruhen. Verlassen Sie sich nicht auf das von Microsoft verwaltete Failover, da dieses nur in Extremsituationen zum Einsatz kommt. Ein von Microsoft verwaltetes Failover wird für eine gesamte physische Einheit eingeleitet, z. B. für eine Region, ein Rechenzentrum oder eine Skalierungseinheit. Es kann nicht für einzelne Speicherkonten, Abonnements oder Mandanten initiiert werden. Informationen über die Möglichkeit zum selektiven Failover einzelner Speicherkonten finden Sie unter Kundenseitig verwaltetes Kontofailover.

Antizipieren von Datenverlust und -inkonsistenzen

Achtung

Ein Speicherkontofailover ist in der Regel mit einem gewissen Datenverlust und möglicherweise mit Datei- und Dateninkonsistenzen verbunden. In Ihrem Plan zur Notfallwiederherstellung sollten Sie unbedingt die möglichen Auswirkungen eines Failovers auf Ihre Daten berücksichtigen, bevor Sie ein Failover einleiten.

Da Daten asynchron von der primären Region in die sekundäre Region geschrieben werden, kommt es immer zu einer Verzögerung, bevor ein in der primären Region durchgeführter Schreibvorgang 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.

Bei einem Failover gehen alle Daten in der primären Region verloren, weil die sekundäre Region zur neuen primären Region wird. Alle bereits in die sekundäre Region kopierten Daten werden beibehalten, wenn das Failover durchgeführt wird. Allerdings gehen alle Daten, die in die primäre Region geschrieben und nicht zusätzlich in die sekundäre Region kopiert wurden, dauerhaft verloren.

Die neue primäre Region ist nach dem Failover als lokal redundant (LRS) konfiguriert.

Es kann außerdem zu Datei- oder Dateninkonsistenzen kommen, wenn für Ihre Speicherkonten mindestens eine der folgenden Optionen aktiviert ist:

Letzte Synchronisierungszeit

Die Eigenschaft Letzte Synchronisierung gibt an, wann die Daten aus der primären Region garantiert in die sekundäre Region geschrieben wurden. Für Konten mit einem hierarchischen Namespace gilt dieselbe Eigenschaft Letzte Synchronisierungszeit auch für die Metadaten, die vom hierarchischen Namespace verwaltet werden, einschließlich ACLs. Alle Daten und Metadaten, die vor der letzte Synchronisierungszeit geschrieben wurden, sind in der sekundären Region verfügbar, während Daten und Metadaten, die nach der letzten Synchronisierungszeit geschrieben wurden, möglicherweise nicht in die sekundären Region geschrieben wurden und verloren gehen können. Verwenden Sie diese Eigenschaft, um bei einem Ausfall den Umfang des Datenverlusts abzuschätzen, der durch das Einleiten eines Kontofailovers entstehen könnte.

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 den Zeitpunkt 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 Synchronisierungszeit finden Sie unter Überprüfen der Eigenschaft „Letzte Synchronisierung“ für ein Speicherkonto.

Dateikonsistenz für Azure Data Lake Storage Gen2

Die Replikation für Speicherkonten mit aktiviertem hierarchischen Namespace (Azure Data Lake Storage Gen2) erfolgt auf Dateiebene. Dies bedeutet, dass bei einem Ausfall in der primären Region möglicherweise nur einige der Dateien in einem Container oder Verzeichnis erfolgreich in die sekundäre Region repliziert wurden. Die Konsistenz für alle Dateien in einem Container oder Verzeichnis nach einem Failover des Speicherkontos ist nicht garantiert.

Änderungsfeed- und Blobdateninkonsistenzen

Ein Speicherkontofailover georedundanter Speicherkonten mit aktiviertem Änderungsfeed kann zu Inkonsistenzen zwischen den Änderungsfeedprotokollen und den Blobdaten und/oder Metadaten führen. Solche Inkonsistenzen können sich aus der asynchronen Art der Aktualisierungen der Änderungsprotokolle und der Replikation von Blobdaten aus der primären in die sekundäre Region ergeben. Inkonsistenzen sind nur dann nicht zu erwarten, wenn alle aktuellen Protokolleinträge erfolgreich in die Protokolldateien geschrieben und sämtliche Speicherdaten erfolgreich von der primären in die sekundäre Region repliziert wurden.

Informationen darüber, wie der Änderungsfeed funktioniert, finden Sie unter Funktionsweise des Änderungsfeeds.

Beachten Sie, dass für andere Speicherkontofeatures die Aktivierung des Änderungsfeeds erforderlich ist, z. B. für die operative Sicherung von Azure Blob Storage, die Objektreplikation und die Zeitpunktwiederherstellung für Blockblobs.

Inkonsistenzen bei Zeitpunktwiederherstellungen

Das vom Kunden verwaltete Failover wird für Speicherkonten im Standardtarif vom Typ „Universell v2“, die Blockblobs enthalten, unterstützt. Wenn Sie jedoch ein vom Kunden verwaltetes Failover für ein Speicherkonto durchführen, wird der frühestmögliche Wiederherstellungspunkt für das Konto zurückgesetzt. Daten für die Zeitpunktwiederherstellung für Blockblobs sind nur bis zur Failoverabschlusszeit konsistent. Daher können Sie Blockblobs nur zu einem Zeitpunkt wiederherstellen, der nicht vor dem Abschluss des Failovers liegt. Sie können die Failoverabschlusszeit auf der Registerkarte „Redundanz“ Ihres Speicherkontos im Azure-Portal überprüfen.

Angenommen, Sie haben den Aufbewahrungszeitraum auf 30 Tage festgelegt. Wenn seit dem Failover mehr als 30 Tage vergangen sind, können Sie innerhalb dieser 30 Tage einen beliebigen Punkt wiederherstellen. Wenn seit dem Failover jedoch weniger als 30 Tage vergangen sind, können Sie – unabhängig vom Aufbewahrungszeitraum – nicht auf einen Punkt vor dem Failover wiederherstellen. Liegen beispielsweise seit dem Failover 10 Tage zurück, dann liegt der frühestmögliche Wiederherstellungspunkt 10 Tage in der Vergangenheit und nicht 30 Tage in der Vergangenheit.

Zeit und Kosten für ein Failover

Die nach dem Einleiten für ein Failover benötigte Zeit kann variieren, in der Regel dauert ein Failover jedoch weniger als eine Stunde.

Bei einem kundenseitig verwalteten Failover ist im Anschluss an ein Failover (und Failback) keine Georedundanz mehr gegeben. Ihr Speicherkonto wird bei einem Failover automatisch in lokal redundanten Speicher (LRS) in der neuen primären Region umgewandelt, und das Speicherkonto in der ursprünglichen primären Region wird gelöscht.

Sie können für das Konto erneut georedundanten Speicher (GRS) oder georedundanten Speicher mit Lesezugriff (RA-GRS) aktivieren. Beachten Sie jedoch, dass die Umwandlung von LRS zu GRS oder RA-GRS zusätzliche Kosten verursacht. Die Kosten ergeben sich aus den Gebühren für ausgehenden Netzwerkdatenverkehr zum erneuten Replizieren der Daten in die neue sekundäre Region. Außerdem müssen alle archivierten Blobs auf einer Onlineebene reaktiviert werden, bevor das Konto für Georedundanz konfiguriert werden kann. Auch hierfür fallen Kosten an. Weitere Informationen zu Preisen finden Sie hier:

Nachdem Sie wieder GRS für Ihr Speicherkonto aktiviert haben, beginnt Microsoft, die Daten in Ihrem Konto in die neue sekundäre Region zu replizieren. Die Replikationszeit hängt von vielen Faktoren ab, z. B.:

  • Anzahl und Größe der im Speicherkonto gespeicherten Objekte. Die Replikation vieler kleiner Objekte kann länger dauern als die Replikation weniger und größerer Objekte.
  • Verfügbare Ressourcen für die Hintergrundreplikation, z. B. CPU, Arbeitsspeicher, Datenträger und WAN-Kapazität. Livedatenverkehr hat Vorrang vor der Georeplikation.
  • Wenn Ihr Speicherkonto Blobs enthält, die Anzahl von Momentaufnahmen pro Blob.
  • Wenn Ihr Speicherkonto Tabellen enthält, die Strategie zur Datenpartitionierung. Der Replikationsprozess kann nicht über die Anzahl der verwendeten Partitionsschlüssel hinaus skaliert werden.

Unterstützte Speicherkontotypen

Alle georedundanten Angebote unterstützen ein von Microsoft verwaltetes Failover. Darüber hinaus unterstützen einige Kontotypen ein kundenseitig verwaltetes Kontofailover, wie in der folgenden Tabelle dargestellt:

Typ des Failovers GRS/RA-GRS GZRS/RA-GZRS
Kundenverwaltetes Failover Universell V2-Konten
Universell V1-Konten
Legacy-Blob Storage-Konten		 Allgemeines Konto vom Typ „General Purpose v2“
Von Microsoft verwaltetes Failover Alle Kontotypen Allgemeines Konto vom Typ „General Purpose v2“

Klassische Speicherkonten

Wichtig

Das Failover eines kundenseitig verwalteten Kontos wird nur für Speicherkonten unterstützt, die mithilfe des ARM-Bereitstellungsmodells (Azure Resource Manager) bereitgestellt werden. Das ASM-Bereitstellungsmodell (Azure Service Manager), auch bekannt als klassisches Modell, wird nicht unterstützt. Damit klassische Speicherkonten für das kundenseitig verwaltete Kontofailover in Frage kommen, müssen sie zunächst zum ARM-Modell migriert werden. Für das Upgrade muss der Zugriff auf Ihr Speicherkonto möglich sein, deshalb darf sich die primäre Region derzeit nicht in einem fehlerhaften Zustand befinden.

Bei einem Notfall, der sich auf die primäre Region auswirkt, verwaltet Microsoft das Failover für klassische Speicherkonten. Weitere Informationen finden Sie unter Microsoft-verwaltetes Failover.

Azure Data Lake Storage Gen2

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.

Nicht unterstützte Features und Dienste

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

  • Azure File Sync unterstützt vom Kunden initiiertes Speicherkontofailover nicht. Für Speicherkonten mit Azure-Dateifreigaben, die als Cloudendpunkte bei 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. Weitere Informationen finden Sie unter Bewährte Methoden für die Notfallwiederherstellung mit Azure Dateisynchronisierung.
  • Für ein Speicherkonto mit Premium-Blockblobs kann kein Failover durchgeführt werden. Speicherkonten, die Premium-Blockblobs unterstützen, unterstützen derzeit keine Georedundanz.
  • Ein vom Kunden verwaltetes Failover wird weder für das Quell- noch für das Zielkonto in einer Objektreplikationsrichtlinie unterstützt.
  • Um ein Failover für ein Konto mit aktiviertem SSH File Transfer Protocol (SFTP) durchzuführen, müssen Sie zuerst SFTP für das Konto deaktivieren. Wenn Sie SFTP nach Abschluss des Failovers fortsetzen möchten, aktivieren Sie es einfach erneut.
  • Network File System 3.0 (NFSv3) wird für ein Failover von Speicherkonten nicht unterstützt. Sie können kein für globale Redundanz konfiguriertes Speicherkonto erstellen, wenn NFSv3 aktiviert ist.

Ein Failover dient nicht der Kontomigration

Ein Speicherkontofailover sollte nicht Teil Ihrer Strategie zur Datenmigration sein. Ein Failover ist eine vorübergehende Lösung bei einem Dienstausfall. Informationen zur Migration Ihrer Speicherkonten finden Sie unter Übersicht über die Azure Storage-Migration.

Speicherkonten mit archivierten Blobs

Speicherkonten mit archivierten Blobs unterstützen ein Kontofailover. Nach Abschluss eines kundenseitig verwalteten Failovers 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

Virtuelle Azure-Computer (VMs) werden im Rahmen eines Kontofailovers nicht verschoben. 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, die spezifischen Hinweise zur Hochverfügbarkeit und Notfallwiederherstellung für VMs in Azure zu befolgen.

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

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 Durchführung des Failovers nicht vollständig mit den VHD-Dateien aktualisiert wurde, funktioniert die VM in der neuen primären Region möglicherweise nicht ordnungsgemäß.
  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.

Kopieren von Daten als Alternative zum Failover

Wenn Ihr Speicherkonto für einen Lesezugriff auf die sekundäre Region 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 durchführen möchten, können Sie mithilfe von Tools wie AzCopy oder Azure PowerShell Daten aus Ihrem Speicherkonto in der sekundären Region in ein anderes Speicherkonto in einer nicht betroffenen Region kopieren. Sie können Ihre Anwendungen dann auf dieses Speicherkonto verweisen, sowohl für die Lese- als auch für die Schreibverfügbarkeit.

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 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 außerdem die Verwendung von Azure Site Recovery, 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. Wenn GRS nicht verfügbar ist und Sie Georedundanz erzielen möchten, verwenden Sie AzCopy oder Azure PowerShell, 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.

Siehe auch