Freigeben über

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

  • Artikel

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

In diesem Artikel werden die verfügbaren Optionen für georedundante Speicherkonten beschrieben und Empfehlungen für die Entwicklung hochverfügbarer Anwendungen und das Testen Ihres Notfallwiederherstellungsplans gegeben.

Auswählen der richtigen Redundanzoption

Azure Storage verwaltet mehrere Kopien Ihres Speicherkontos, um sicherzustellen, dass die Verfügbarkeits- und Dauerhaftigkeitsziele erfüllt werden, selbst bei Ausfällen. Die unterschiedlichen Arten der Datenreplikation bieten unterschiedliche Schutzniveaus. Jede Option hat ihre eigenen Vorteile. Für welche Option Sie sich entscheiden, hängt also vom Grad der Resilienz ab, den Ihre Anwendungen benötigen.

Bei lokal redundantem Speicher (LRS), der kostengünstigsten Redundanzoption, werden automatisch drei Kopien Ihres Speicherkontos in einem einzigen Rechenzentrum gespeichert und repliziert. Obwohl LRS Ihre Daten vor Serverschrank- und Laufwerksausfällen schützt, ist es nicht auf Katastrophen wie Feuer oder Überschwemmungen in einem Rechenzentrum ausgerichtet. Bei solchen Katastrophen können alle Replikate eines Speicherkontos, das für die Verwendung von LRS konfiguriert ist, verloren gehen oder nicht wiederherstellbar sein.

Im Vergleich dazu behält der zonenredundante Speicher (ZRS) eine Kopie eines Speicherkontos und repliziert sie in jeder der drei separaten Verfügbarkeitszonen innerhalb derselben Region. Weitere Informationen zu Verfügbarkeitszonen finden Sie unter Azure-Verfügbarkeitszonen.

Georedundanter Speicher und Failover

Georedundanter Speicher (GRS), geozonenredundanter Speicher (GZRS) und geozonenredundanter Speicher mit Lesezugriff (RA-GZRS) sind Beispiele für geografisch redundante Speicheroptionen. Wenn Sie Azure für die Verwendung von georedundantem Speicher (GRS, GZRS und RA-GZRS) konfigurieren, kopiert Azure Ihre Daten asynchron in eine sekundäre geografische Region. Diese Regionen befinden sich hunderte oder sogar Tausende von Meilen entfernt. Dank dieser umfassenden Redundanz können Sie Ihre Daten wiederherstellen, wenn es in der gesamten primären Region zu einem Ausfall kommt.

Im Gegensatz zu LRS und ZRS bietet der georedundante Speicher auch Unterstützung für ein nicht geplantes Failover zu einer sekundären Region, wenn ein Ausfall in der primären Region vorhanden ist. Während des Failover-Prozesses werden die DNS-Einträge (Domain Name System) für die Dienstendpunkte Ihres Speicherkontos automatisch so aktualisiert, dass die Endpunkte der sekundären Region zu den neuen primären Endpunkten werden. Sobald das ungeplante Failover abgeschlossen ist, können die Clients damit beginnen, Schreibvorgänge auf den neuen primären Endpunkten durchzuführen.

Georedundanter Speicher mit Lesezugriff (RA-GRS) und geozonenredundanter Speicher mit Lesezugriff (RA-GZRS) bieten ebenfalls Georedundanz, bieten aber den zusätzlichen Vorteil des Lesezugriffs auf den sekundären Endpunkt. Diese Optionen sind ideal für Anwendungen, die für hochverfügbare, geschäftskritische Anwendungen konzipiert sind. Wenn der primäre Endpunkt ausfällt, können Anwendungen, die für den Lesezugriff auf die sekundäre Region konfiguriert sind, weiterhin ausgeführt werden. Microsoft empfiehlt RA-GZRS, um maximale Verfügbarkeit und Dauerhaftigkeit für Ihre Speicherkonten zu gewährleisten.

Weitere Informationen zur Redundanz für Azure Storage finden Sie unter Azure Storage-Redundanz.

Planen des Failovers

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

1 Ein von Microsoft verwaltetes Failover kann nicht für einzelne Speicherkonten, Abonnements oder Mandanten initiiert werden. Weitere Informationen finden Sie unter Microsoft-verwaltetes Failover.
2 Verwenden Sie vom Kunden verwaltete Failoveroptionen, um Ihre Notfallwiederherstellungspläne zu entwickeln, zu testen und zu implementieren. 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). Diese Tabelle fasst diese Aspekte der einzelnen Failovertypen zusammen:

Typ Failoverbereich Anwendungsfälle Erwarteter Datenverlust Hierarchischer Namespace (HNS) wird unterstützt
Kundenseitig verwaltetes geplantes Failover (Preview) Speicherkonto Die Dienstendpunkte für die primären und sekundären Regionen sind verfügbar, und Sie möchten Notfallwiederherstellungstests durchführen.

Die Speicherdienstendpunkte für die primäre Region sind verfügbar, aber ein anderer Dienst verhindert, dass Ihre Workloads ordnungsgemäß funktionieren.

Um sich proaktiv für große Katastrophen wie einen Hurrikan zu wappnen, der sich auf eine Region auswirken könnte.		 Nein Ja
(In der Preview)
Kundenseitig verwaltetes (ungeplantes) Failover 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 Preview)
von Microsoft verwaltet Gesamte Region Die primäre Region ist aufgrund einer Katastrophe ausgefallen, aber die sekundäre Region ist verfügbar. Ja Ja

In der folgenden Tabelle wird der Redundanzstatus eines Speicherkontos nach jedem Failovertyp verglichen:

Ergebnis eines Failovers für … Kundenseitig verwaltetes geplantes Failover (Preview) Kundenseitig verwaltetes (ungeplantes) Failover
… die sekundäre Region Die sekundäre Region wird zur neuen primären Region Die sekundäre Region wird zur neuen primären Region
… die ursprüngliche primäre Region Die ursprüngliche primäre Region wird zur neuen sekundären Region Die Kopie der Daten im ursprünglichen primären Bereich wird gelöscht
… die Kontoredundanzkonfiguration Das Speicherkonto wird in GRS konvertiert Das Speicherkonto wird in LRS konvertiert
… die Georedundanzkonfiguration Die Georedundanz bleibt erhalten Georedundanz geht verloren

Die folgende Tabelle fasst die resultierende Redundanzkonfiguration in jeder Phase des Failover- und Failback-Prozesses für jeden Failovertyp zusammen:

Original
Konfiguration		 Nach
failover		 Nach der erneuten Aktivierung
Georedundanz		 Nach
Failback		 Nach der erneuten Aktivierung
Georedundanz
Kundenseitig verwaltetes geplantes Failover
GRS GRS Nicht verfügbar 1 GRS Nicht verfügbar 1
GZRS GRS Nicht verfügbar 1 GZRS Nicht verfügbar 1
Kundenseitig verwaltetes geplantes Failover
GRS LRS GRS LRS GRS
GZRS LRS GRS ZRS GZRS

1 Die Georedundanz wird während eines geplanten Failovers beibehalten und muss nicht manuell neu konfiguriert werden.

Kundenseitig verwaltetes geplantes Failover (Preview)

Das geplante Failover kann in zahlreichen Szenarien verwendet werden, beispielsweise für das Testen der geplanten Notfallwiederherstellung (ein proaktiver Ansatz für große Ausfälle) oder um eine Wiederherstellung nach Ausfällen durchzuführen, die nicht auf den Speicher zurückzuführen sind.

Während des geplanten Failoverprozesses werden die primären und sekundären Regionen ausgetauscht. Die ursprüngliche primäre Region wird herabgestuft und wird zur neuen sekundären Region. Gleichzeitig wird die ursprüngliche sekundäre Region höhergestuft und zur neuen Primären. Nach Abschluss des Failovers können Benutzer auf die Daten in der neuen primären Region zugreifen, und Administratoren können ihren Notfallwiederherstellungsplan überprüfen. Das Speicherkonto muss sowohl in den primären als auch in sekundären Regionen verfügbar sein, bevor ein geplantes Failover initiiert werden kann.

Datenverlust wird während des geplanten Failover- und Failbackprozesses nicht erwartet, solange die primären und sekundären Regionen während des gesamten Prozesses verfügbar sind. Weitere Details finden Sie im Abschnitt Antizipieren von Datenverlust und Inkonsistenzen.

Um die Auswirkungen dieses Failovertypen auf Ihre Benutzer und Anwendungen zu verstehen, ist es hilfreich zu wissen, was bei jedem Schritt der geplanten Failover- und Failback-Prozesse passiert. Ausführliche Informationen zur Funktionsweise dieses Prozesses finden Sie unter Funktionsweise des vom Kunden verwalteten (geplanten) Failovers.

Wichtig

Das kundenseitig verwaltete geplante Failover befindet sich derzeit in der VORSCHAU und ist auf die folgenden Regionen beschränkt:

  • Frankreich, Mitte
  • Frankreich, Süden
  • Indien, Mitte
  • Indien, Westen
  • Asien, Osten
  • Asien, Südosten

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

Nach einem geplanten Failover kann der Wert für den letzten Synchronisierungszeitpunkt (Last Sync Time, LST) eines Speicherkontos veraltet erscheinen oder als NULL gemeldet werden, wenn Azure Files-Daten vorhanden sind.

Systemmomentaufnahmen werden in regelmäßigen Abständen in der sekundären Region eines Speicherkontos erstellt, um konsistente Wiederherstellungspunkte erhalten, die während des Failovers und Failbacks verwendet werden. Das Initiieren eines kundenseitig verwalteten geplanten Failovers bewirkt, dass die ursprüngliche primäre Region zur neuen sekundären Region wird. In einigen Fällen sind nach Abschluss des geplanten Failovers keine Systemmomentaufnahmen in der neuen sekundären Region verfügbar, sodass der LST-Gesamtwert des Kontos veraltet scheint oder als Null angezeigt wird.

Da Benutzeraktivitäten wie das Erstellen, Ändern oder Löschen von Objekten die Erstellung von Momentaufnahmen auslösen können, erfordern Konten, bei denen diese Aktivitäten nach dem geplanten Failover stattfinden, keine zusätzliche Aufmerksamkeit. Konten ohne Momentaufnahmen oder Benutzeraktivitäten können jedoch weiterhin den LST-Wert Null anzeigen, bis die Erstellung von Systemmomentaufnahmen ausgelöst wird.

Führen Sie bei Bedarf eine der folgenden Aktivitäten für jede Freigabe innerhalb eines Speicherkontos aus, um die Erstellung von Momentaufnahmen auszulösen. Nach Abschluss sollte Ihr Konto innerhalb von 30 Minuten einen gültigen LST-Wert anzeigen.

  • Binden Sie die Freigabe ein, und öffnen Sie dann eine beliebige Datei zum Lesen.
  • Laden Sie eine Test- oder Beispieldatei in die Freigabe hoch.

Kundenseitig verwaltetes (ungeplantes) Failover

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

Um die Auswirkungen dieses Failovertypen auf Ihre Benutzer und Anwendungen zu verstehen, ist es hilfreich zu wissen, was bei jedem Schritt des ungeplanten Failover- und Failback-Prozesses passiert. Ausführliche Informationen zur Funktionsweise dieses Prozesses finden Sie unter Funktionsweise des vom Kunden verwalteten (ungeplanten) Failovers.

Von Microsoft verwaltetes Failover

Microsoft könnte ein regionales Failover unter extremen Umständen initiieren, z. B. eine katastrophale Katastrophe, die sich auf eine gesamte Georegion auswirkt. Während dieser Ereignisse ist keine Aktion Ihrerseits erforderlich. Wenn Ihr Speicherkonto für RA-GRS oder RA-GZRS konfiguriert ist, können Ihre Anwendungen während eines von Microsoft verwalteten Failover von der sekundären Region lesen. Sie haben jedoch keinen Schreibzugriff auf Ihr Speicherkonto, bis der Failover-Prozess abgeschlossen ist.

Wichtig

Verwenden Sie vom Kunden verwaltete Failoveroptionen, um Ihre Notfallwiederherstellungspläne zu entwickeln, zu testen und zu implementieren. Verlassen Sie sich nicht auf das von Microsoft verwaltete Failover, da dieses nur in Extremsituationen zum Einsatz kommt. Ein von Microsoft verwaltetes Failover würde für eine gesamte physische Einheit eingeleitet, z. B. für eine Region oder ein Rechenzentrum. 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 geplantes Failover.

Antizipieren von Datenverlust und -inkonsistenzen

Achtung

Bei einem kundenseitig verwalteten (ungeplanten) Failover tritt in der Regel ein gewisser Datenverlust auf. Außerdem können dabei Datei- und Dateninkonsistenzen verursacht werden. 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 mehr verfügbar ist, ist es möglich, dass die letzten Schreibvorgänge noch nicht in die sekundäre Region kopiert wurden.

Bei einem ungeplanten Failover gehen alle Daten in der primären Region verloren, weil die sekundäre Region zur neuen primären Region wird. Alle Daten, die bereits in die sekundäre Region kopiert wurden, bleiben erhalten, wenn das Failover durchgeführt wird. Allerdings gehen alle Daten, die auf den primären Speicher geschrieben wurden und noch nicht in der sekundären Region vorhanden sind, 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 Last Sync Time gibt den letzten Zeitpunkt an, zu dem Daten aus der primären Region auch 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 (Access Control-Listen). Alle Daten und Metadaten, die vor dem letzten Synchronisierungszeitpunkt geschrieben wurden, sind in der sekundären Region verfügbar. Im Gegensatz dazu sind Daten und Metadaten, die nach der letzten Synchronisierung geschrieben wurden, möglicherweise noch nicht in die sekundäre Region kopiert worden und könnten daher verloren gehen. Verwenden Sie diese Eigenschaft, um bei einem Ausfall abzuschätzen, wie hoch der Datenverlust sein könnte, wenn Sie ein Kontofailover initiieren.

Als bewährte Methode sollten Sie Ihre Anwendung so gestalten, dass Sie Last Sync Time verwenden können, um den zu erwartenden Datenverlust zu bewerten. Wenn Sie beispielsweise alle Schreibvorgänge protokollieren, können Sie die Zeiten Ihres letzten Schreibvorgangs mit der letzten Synchronisierungszeit vergleichen. Mit dieser Methode können Sie feststellen, welche Schreibvorgänge noch nicht mit dem sekundären System synchronisiert sind und verloren zu gehen drohen.

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

Die Replikation für Speicherkonten mit aktiviertem hierarchischen Namespace (Azure Data Lake Storage) erfolgt auf Dateiebene. Da die Replikation auf dieser Ebene stattfindet, kann ein Ausfall in der primären Region dazu führen, dass einige der Dateien in einem Container oder Verzeichnis nicht erfolgreich in die sekundäre Region repliziert werden können. Die Konsistenz aller Dateien innerhalb eines Containers oder Verzeichnisses nach einem Failover des Speicherkontos ist nicht garantiert.

Änderungsfeed- und Blobdateninkonsistenzen

Kundenseitig verwaltetes (ungeplantes) Failover von Speicherkonten, auf denen Änderungsfeed aktiviert ist, könnte zu Inkonsistenzen zwischen den Änderungsfeed-Protokollen und den Blobdaten und/oder Metadaten führen. Solche Inkonsistenzen können durch die asynchrone Natur der Aktualisierung des Änderungsprotokolls und der Datenreplikation zwischen der primären und sekundären Region entstehen. Sie können Inkonsistenzen vermeiden, indem Sie die folgenden Vorsichtsmaßnahmen treffen:

  • Stellen Sie sicher, dass alle Protokolldatensätze in die Protokolldateien geleert werden.
  • Stellen Sie sicher, dass alle Speicherdaten von der primären in die sekundäre Region repliziert werden.

Weitere Informationen zum Änderungsfeed finden Sie unter Funktionsweise des Änderungsfeeds.

Beachten Sie, dass auch für andere Funktionen des Speicherkontos der Änderungsfeed aktiviert sein muss. Dazu gehören: betriebsbereite Sicherung von Azure Blob Storage, Objektreplikation und Zeitpunktwiederherstellung für Block-Blobs.

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 Failover-Abschlusszeit auf der Registerkarte „Redundanz“ Ihres Speicherkontos im Azure-Portal überprüfen.

Zeit und Kosten für ein Failover

Es kann unterschiedlich lange dauern, bis ein kundenseitig verwaltes Failover abgeschlossen ist, in der Regel dauert es jedoch weniger als eine Stunde.

Ein geplantes kundenseitig verwaltetes Failover verliert seine Georedundanz nach einem Failover und nachfolgendem Failback nicht, aber ein ungeplantes kundenseitig verwaltetes Failover schon.

Durch das Initiieren eines vom Kunden verwalteten nicht geplanten Failovers wird Ihr Speicherkonto automatisch in einen lokal redundanten Speicher (LRS) innerhalb einer neuen primären Region konvertiert und das Speicherkonto in der ursprünglichen primären Region gelöscht.

Sie können georedundanten Speicher (GRS) oder georedundanten Speicher mit Lesezugriff (RA-GRS) für das Konto wieder aktivieren, aber die erneute Replikation von Daten in die neue sekundäre Region ist kostenpflichtig. Außerdem müssen alle archivierten Blobs auf eine Online-Ebene reaktiviert werden, bevor das Konto für Georedundanz rekonfiguriert werden kann. Auch für diese Reaktivierung fallen zusätzliche 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 Dauer des Replikationsvorgangs hängt von mehreren Faktoren ab. Hierzu gehören u. a.:

  • 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.
  • Die Anzahl der Momentaufnahmen pro Blob, falls vorhanden.
  • Die Strategie zur Datenpartitionierung, wenn Ihr Speicherkonto Tabellen enthält. 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
Kundenseitig verwaltetes geplantes Failover (Preview) Universell V2-Konten
Universell V1-Konten
Legacy-Blob Storage-Konten		 Allgemeines Konto vom Typ „General Purpose v2“
Kundenseitig verwaltetes geplantes 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 kundenseitig verwaltete Failover wird nur für Speicherkonten unterstützt, die mithilfe des ARM-Bereitstellungsmodells (Azure Resource Manager) bereitgestellt werden. Das Azure Service Manager (ASM)-Bereitstellungsmodell, auch bekannt als das klassische 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 einer Katastrophe, die die primäre Region betrifft, verwaltet Microsoft das Failover für klassische Speicherkonten. Weitere Informationen finden Sie unter Microsoft-verwaltetes Failover.

Hierarchischer Namespace (HNS)

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 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.

Nicht unterstützte Features und Dienste

Die folgenden Features und Dienste werden für das kundenseitig verwaltete Failover nicht unterstützt:

  • Azure File Sync unterstützt kein kundenseitig verwaltetes Kontofailover. Auf Speicherkonten, die als Cloudendpunkte für die Azure-Dateisynchronisierung verwendet werden, sollte das Failover nicht angewendet werden. Das Failover stört die Dateisynchronisierung und kann zu einem unerwarteten Datenverlust von neu eingestuften Dateien 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.
  • Network File System 3.0 (NFSv3) wird für ein Failover von Speicherkonten nicht unterstützt. Sie können kein für Georedundanz konfiguriertes Speicherkonto erstellen, wenn NFSv3 aktiviert ist.

Die folgende Tabelle kann verwendet werden, um auf die Featureunterstützung zu verweisen.

Geplantes Failover Ungeplantes Failover
Azure Data Lake-Speicher Unterstützt (Vorschau) Unterstützt (Vorschau)
Änderungsfeed Nicht unterstützt Unterstützt
Objektreplikation Nicht unterstützt Nicht unterstützt
SFTP Unterstützt (Vorschau) Unterstützt (Vorschau)
NFSv3 GRS wird nicht unterstützt GRS wird nicht unterstützt
Speichervorgänge Unterstützt1 Unterstützt1
Zeitpunktwiederherstellung (PITR) Nicht unterstützt Unterstützt

1 Wenn Sie ein vom Kunden verwaltetes geplantes oder ungeplantes Failover initiieren, können Speicheraufgaben nicht auf dem Konto ausgeführt werden, bis es in die ursprüngliche primäre Region zurückgesetzt wurde. Weitere Informationen

Failover sind nicht für die Kontomigration gedacht

Speicherkontofailover sind eine temporäre Lösung, die zum Entwickeln und Testen Ihrer Notfallwiederherstellungspläne (DR) oder zum Wiederherstellen bei einem Ausfall verwendet wird. Ein Failover sollte nicht Teil Ihrer Strategie zur Datenmigration sein. 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 Failover müssen jedoch alle archivierten Blobs auf eine Online-Ebene 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 einmal 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

Azure-VMs werden im Rahmen eines Failover von Speicherkonten nicht ausgelagert. Alle VMs, die als Reaktion auf einen Ausfall auf eine sekundäre Region übertragen wurden, müssen nach Abschluss des Failover-Vorgangs neu erstellt werden. Das Kontofailover kann zum Verlust von Daten führen, die auf einem temporären Datenträger gespeichert sind, wenn der virtuelle Computer (VM) heruntergefahren wird. Microsoft empfiehlt, die spezifischen Hinweise zur Hochverfügbarkeit und Notfallwiederherstellung für VMs in Azure zu befolgen.

Nicht verwaltete Azure-Datenträger

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. Bevor ein Failover für ein Konto initiiert werden kann, das nicht verwaltete Datenträger enthält, die an Azure-VMs angeschlossen sind, müssen die Datenträger heruntergefahren werden. Zu den von Microsoft empfohlenen bewährten Methoden gehört daher die Konvertierung aller nicht verwalteten Datenträger in verwaltete Datenträger.

Um ein Failover für ein Konto mit nicht verwalteten Datenträgern durchzuführen, gehen Sie wie folgt vor:

  1. Bevor Sie beginnen, notieren Sie sich die Namen aller nicht verwalteten Datenträger, ihre logische Gerätenummer (LUN) und die VM, an die sie angefügt 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 den virtuellen Computer, behalten Sie jedoch die VHD-Dateien (Virtual Hard Disk) für die nicht verwalteten Datenträger bei. Notieren Sie die Zeit, zu der Sie die VM gelöscht haben.
  4. Warten Sie, bis Last Sync Time aktualisiert wird, und vergewissern Sie sich, dass dieser Zeitpunkt nach dem Zeitpunkt liegt, an dem Sie die VM gelöscht haben. Dieser Schritt stellt sicher, dass der sekundäre Endpunkt mit den VHD-Dateien vollständig aktualisiert wird, wenn das Failover stattfindet, und dass die VM in der neuen primären Region ordnungsgemäß funktioniert.
  5. Initiieren Sie das Kontofailover.
  6. Warten Sie, bis das Kontofailover abgeschlossen und die sekundäre Region die neue primäre Region 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 Failoveralternative

Wie bereits erläutert, können Sie eine hohe Verfügbarkeit aufrechterhalten, indem Sie Anwendungen so konfigurieren, dass sie ein Speicherkonto verwenden, das für den Lesezugriff auf eine sekundäre Region konfiguriert ist. Wenn Sie es jedoch vorziehen, während eines Ausfalls in der primären Region kein Failover durchzuführen, können Sie Ihre Daten alternativ auch manuell kopieren. Mit Tools wie AzCopy und Azure PowerShell können Sie Daten von Ihrem Speicherkonto in der betroffenen Region auf ein anderes Speicherkonto in einer nicht betroffenen Region kopieren. Nach Abschluss des Kopiervorgangs können Sie Ihre Anwendungen so rekonfigurieren, dass sie das Speicherkonto in der nicht betroffenen Region sowohl für die Lese- als auch für die Schreibverfügbarkeit verwenden.

Entwurf für Hochverfügbarkeit

Es ist wichtig, Ihre Anwendung von Anfang an auf Hochverfügbarkeit auszurichten. In diesen Azure-Ressourcen finden Sie Anleitungen für die Entwicklung Ihrer Anwendung und die Planung der Notfallwiederherstellung:

Beachten Sie diese bewährten Methoden, um eine hohe Verfügbarkeit Ihrer Azure Storage-Daten zu gewährleisten:

  • Datenträger: Verwenden Sie den Azure Backup, um die von Ihrem virtuellen Computer verwendeten VM-Datenträger zu sichern. Ziehen Sie auch den Einsatz von Azure Site Recovery in Betracht, um Ihre VMs vor einer regionalen Katastrophe 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 Status von Azure Storage und 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