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

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:

• Datenschutz
• Sichern und Wiederherstellen
• Datenredundanz
• Failover
• Entwerfen von Anwendungen für Hochverfügbarkeit

In diesem Artikel werden die verfügbaren Optionen für global redundante 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 global redundante Speicheroptionen. Wenn Sie Azure für die Verwendung von global redundantem 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 global redundante 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:

• Kundenseitig verwaltetes geplantes Failover – Kunden können das Failover des Speicherkontos verwalten, um ihren Notfallwiederherstellungsplan zu testen.
• Kundenseitig verwaltetes (ungeplantes) Failover: Kunden können bei einem unerwarteten Dienstausfall das Failover der Speicherkonten verwalten.
• Von Microsoft verwaltetes Failover – Wird möglicherweise von Microsoft aufgrund einer schweren Katastrophe in der primären Region initiiert. ^1,2

¹ Ein von Microsoft verwaltetes Failover kann nicht für einzelne Speicherkonten, Abonnements oder Mandanten initiiert werden. Weitere Informationen finden Sie unter Microsoft-verwaltetes Failover.
² 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 Gen2). Diese Tabelle fasst diese Aspekte der einzelnen Failovertypen zusammen:

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

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

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

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

Antizipieren von Datenverlust und -inkonsistenzen

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:

• Hierarchischer Namespace (Azure Data Lake Storage Gen2)
• Änderungsfeed
• Point-in-Time-Wiederherstellung für Blockblobs

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 Gen2

Die Replikation für Speicherkonten mit aktiviertem hierarchischen Namespace (Azure Data Lake Storage Gen2) 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:

• Preisübersicht Bandbreite
• Preise für Azure Storage

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:

Klassische Speicherkonten

Hierarchischer Namespace (HNS)

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 globale Redundanz konfiguriertes Speicherkonto erstellen, wenn NFSv3 aktiviert ist.

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

Failover sind nicht für die Kontomigration gedacht

Speicherkontofailover sind eine temporäre Lösung, die entweder zum Planen und Testen Ihrer DR-Pläne oder zum Wiederherstellen eines Dienstausfalls verwendet werden kann. 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 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:

• Entwerfen resilienter Anwendungen für Azure: Ein Überblick über die wichtigsten Konzepte für die Architektur hochverfügbarer Anwendungen in Azure.
• Checkliste für Resilienz: Eine Checkliste zur Überprüfung, ob Ihre Anwendung die Best Practices für den Entwurf für Hochverfügbarkeit implementiert.
• Verwenden von Georedundanz zum Entwerfen von hochverfügbaren Anwendungen: Entwurfsleitfaden zum Erstellen von Anwendungen zur Nutzung der Vorteile von georedundantem Speicher.
• Tutorial: Erstellen einer hochverfügbaren Anwendung mit Blob Storage: Ein Tutorial, das zeigt, wie Sie eine hochverfügbare Anwendung erstellen, die automatisch zwischen Endpunkten wechselt, wenn Ausfälle und Wiederherstellungen simuliert werden.

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

• Verwenden von Georedundanz zum Entwerfen von hochverfügbaren Anwendungen
• Tutorial: Erstellen einer hochverfügbaren Anwendung mit Blob Storage
• Azure-Speicherredundanz
• Funktionsweise kundenseitig verwalteter geplanter Failover (Preview)
• Funktionsweise kundenseitig verwalteter geplanter Failover