Freigeben über

Zuverlässigkeit in Azure Files

In diesem Artikel wird die Zuverlässigkeitsunterstützung in Azure Files beschrieben. Azure Files bietet vollständig verwaltete Dateifreigaben in der Cloud, auf die über branchenübliche Protokolle für Server Message Block (SMB) und Network File System (NFS) zugegriffen werden kann.

Wenn Sie Azure verwenden, ist Zuverlässigkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.

In diesem Artikel wird beschrieben, wie Sie Azure Files für eine Vielzahl potenzieller Ausfälle und Probleme widerstandsfähig machen, einschließlich vorübergehender Fehler, Ausfall der Verfügbarkeitszone und Regionsausfälle. Außerdem wird beschrieben, wie Sie Sicherungen verwenden können, um sich von anderen Arten von Problemen zu erholen, und es werden einige wichtige Informationen zur Service-Level-Vereinbarung (SLA) von Azure Files hervorgehoben.

Hinweis

Azure Files ist Teil der Azure Storage-Plattform. Einige der Funktionen von Azure Files sind in vielen Azure Storage-Diensten üblich. In diesem Artikel verwenden wir Azure Storage, um diese allgemeinen Funktionen zu erläutern.

Bereitstellungsempfehlungen für die Produktion

Informationen zum Bereitstellen von Azure Files zur Unterstützung der Zuverlässigkeitsanforderungen Ihrer Lösung und wie sich die Zuverlässigkeit auf andere Aspekte Ihrer Architektur auswirkt, finden Sie unter Architektur bewährte Methoden für Azure Files im Azure Well-Architected Framework.

Übersicht über die Zuverlässigkeitsarchitektur

Lokal redundanter Speicher (LRS) repliziert die Daten in Ihren Speicherkonten in eine oder mehrere Azure-Verfügbarkeitszonen, die sich in der primären Region Ihrer Wahl befinden. Obwohl es keine Option gibt, Ihre bevorzugte Verfügbarkeitszone auszuwählen, kann Azure LRS-Konten über Zonen hinweg verschieben oder erweitern, um den Lastenausgleich zu verbessern. Es gibt keine Garantie dafür, dass Ihre Daten über Zonen verteilt werden. Weitere Informationen zu Verfügbarkeitszonen finden Sie unter Was sind Verfügbarkeitszonen?.

Diagramm, das zeigt, wie Daten mithilfe von LRS in Verfügbarkeitszonen repliziert werden.

Zonenredundanter Speicher (ZRS), georedundanter Speicher (GRS) und geozonenredundanter Speicher (GZRS) bieten zusätzlichen Schutz. In diesem Artikel werden diese Optionen ausführlich beschrieben.

Azure Files ist in zwei Medienebenen verfügbar:

  • Die Premium-Stufe verwendet Solid-State-Laufwerke (SSD) für hohe Leistung. Diese Stufe wird für Workloads empfohlen, die eine niedrige Latenz erfordern.

  • Die Standardebene unterstützt Festplattenlaufwerke (HDD). HDD-Dateifreigaben stellen eine kostengünstige Speicheroption für universelle Dateifreigaben bereit.

Weitere Informationen finden Sie unter Plan to deploy Azure Files – Storage tiers.

Azure Files realisiert Redundanz auf Speicher-Kontoebene, wobei Dateifreigaben diese Redundanzkonfiguration automatisch übernehmen. Der Dienst unterstützt mehrere Redundanzmodelle, die sich bei ihrem Datenschutzansatz unterscheiden.

Resilienz für vorübergehende Fehler

Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können, in der Regel durch Wiederholen betroffener Anforderungen.

Alle in der Cloud gehosteten Anwendungen sollten die Anleitung zur vorübergehenden Fehlerbehandlung von Azure befolgen, wenn sie mit cloudgehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zum Umgang mit vorübergehenden Fehlern.

Um vorübergehende Fehler effektiv zu verwalten, wenn Sie Azure Files verwenden, konfigurieren Sie geeignete Timeoutwerte für Ihre Dateivorgänge basierend auf dateigrößen- und Netzwerkbedingungen. Größere Dateien erfordern längere Timeouts, während kleinere Vorgänge kürzere Werte verwenden können, um Fehler schnell zu erkennen.

Um sicherzustellen, dass nur sichere Verbindungen mit Ihrer NFS-Freigabe hergestellt werden, empfehlen wir, einen privaten Endpunkt für Ihr Speicherkonto zu konfigurieren. Ein privater Endpunkt verwendet Azure Private Link, um Ihrem Speicherkonto eine statische IP-Adresse aus dem privaten Adressraum Ihres virtuellen Netzwerks zuzuweisen. Ein privater Endpunkt trägt dazu bei, Verbindungsunterbrechungen von änderungen an dynamischen IP-Adressen zu verhindern. Weitere Informationen zur Sicherheit Ihrer NFS-Freigaben finden Sie unter NFS-Dateifreigaben – Sicherheit und Netzwerk.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb einer Azure-Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.

Azure Files bietet stabile Verfügbarkeitszonenunterstützung über ZRS-Konfigurationen, die Ihre Daten automatisch über mehrere Verfügbarkeitszonen innerhalb einer Region verteilen. Im Gegensatz zu LRS garantiert ZRS, dass Azure Ihre Dateidaten synchron über mehrere Verfügbarkeitszonen repliziert. ZRS stellt sicher, dass Ihre Daten auch dann zugänglich bleiben, wenn eine Zone einen Ausfall erlebt.

Diagramm, das zeigt, wie Daten in der primären Region mit zonenredundanten Speicher (ZRS) repliziert werden.

Anforderungen

ZRS wird unterstützt in:

Kosten

Wenn Sie den zonenredundanten Speicher (ZRS) aktivieren, werden Sie aufgrund des zusätzlichen Replikations- und Speicheraufwands mit einer anderen Rate als lokal beim redundantem Speicher (LRS) belastet.

Ausführliche Preisinformationen finden Sie unter Azure Files-Preise.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

  • Erstellen Sie eine Dateifreigabe mit Zonenredundanz. Informationen zum Erstellen einer neuen Dateifreigabe mit ZRS finden Sie unter Erstellen einer Azure-Dateifreigabe , und wählen Sie ZRS oder GZRS als Redundanzoption während der Kontoerstellung aus.

  • Ändern Sie den Replikationstyp. Informationen zum Konvertieren eines vorhandenen Speicherkontos in ZRS und Informationen zu Migrationsoptionen und Anforderungen finden Sie unter Ändern der Redundanzkonfiguration für Azure Files.

  • Zonenredundanz deaktivieren. Konvertieren Sie ZRS-Konten zurück in eine nichtzonale Konfiguration, z. B. LRS, durch denselben Redundanzkonfigurationsänderungsprozess.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein Dateispeicherkonto für Zonenredundanz konfiguriert ist und alle Verfügbarkeitszonen betriebsbereit sind.

  • Datenverkehrsrouting zwischen Zonen: Azure Storage mit zonenredundanten Speicher (ZRS) verteilt Anforderungen automatisch über Speichercluster in mehreren Verfügbarkeitszonen. Die Datenverkehrsverteilung ist für Anwendungen transparent und erfordert keine clientseitige Konfiguration.

  • Datenreplikation zwischen Zonen: Alle Schreibvorgänge im ZRS werden synchron in allen Verfügbarkeitszonen innerhalb der Region repliziert. Wenn Sie Daten hochladen oder ändern, wird der Vorgang erst als abgeschlossen betrachtet, wenn die Daten in allen Verfügbarkeitszonen erfolgreich repliziert wurden. Diese synchrone Replikation stellt eine starke Konsistenz und keinen Datenverlust bei Zonenfehlern sicher.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein Dateispeicherkonto für Zonenredundanz konfiguriert ist und es einen Ausfall der Verfügbarkeitszone gibt.

  • Erkennung und Reaktion: Microsoft erkennt Zonenfehler automatisch und initiiert Wiederherstellungsprozesse. Für Konten mit zonenredundantem Speicher (ZRS) ist keine Kundenaktion erforderlich.

    Wenn eine Zone nicht mehr verfügbar ist, nimmt Azure Netzwerkupdates vor, wie z. B. die DNS-Neuzuordnung (Domain Name System).

  • Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone deaktiviert ist. Sie können jedoch Azure Resource Health verwenden, um den Status einer einzelnen Ressource zu überwachen, und Sie können Ressourcenintegritätswarnungen einrichten, um Sie über Probleme zu informieren. Sie können auch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich jeglicher Zonenfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

  • Aktive Anforderungen: In-Flight-Anforderungen werden möglicherweise während des Wiederherstellungsvorgangs verworfen und sollten erneut überprüft werden. Anwendungen sollten Wiederholungslogik implementieren , um diese temporären Unterbrechungen zu behandeln.

  • Erwarteter Datenverlust: Während Zonenfehlern tritt kein Datenverlust auf, da Daten synchron über mehrere Zonen repliziert werden, bevor Schreibvorgänge abgeschlossen sind.

  • Erwartete Downtime: Ein wenig Downtime, in der Regel einige Sekunden, kann während der automatischen Wiederherstellung auftreten, da der Datenverkehr zu fehlerfreien Zonen umgeleitet wird. Halten Sie beim Entwerfen von Anwendungen für ZRS die Vorgehensweisen für vorübergehende Fehler ein. Dazu gehört u. a. die Implementierung von Wiederholungsrichtlinien mit exponentiellem Backoff.

  • Datenverkehrsumleitung: Azure leitet den Datenverkehr automatisch an die verbleibenden fehlerfreien Verfügbarkeitszonen um. Der Dienst verwaltet die volle Funktionalität mithilfe der überlebenden Zonen, ohne dass ein Kundeneingriff erforderlich ist. Es ist keine Neueinbindung von Azure-Dateifreigaben auf den verbundenen Clients erforderlich.

Zonenwiederherstellung

Wenn die fehlgeschlagene Verfügbarkeitszone wiederhergestellt wird, stellt Azure Storage automatisch normale Vorgänge in allen Verfügbarkeitszonen wieder her. Der Dienst stellt automatisch die Datenkonsistenz sicher, indem alle Vorgänge synchronisiert werden, die während des Ausfallzeitraums aufgetreten sind.

Test auf Zonenfehler

Wenn Sie zonenredundanten Speicher (ZRS) verwenden, verwaltet Azure Storage automatisch Replikations-, Datenverkehrsrouting- und Zonendownantworten. Da dieses Feature vollständig verwaltet ist, müssen Sie die Ausfallprozesse für Verfügbarkeitszonen weder einleiten noch überprüfen.

Widerstandsfähigkeit bei regionalen Ausfällen

Azure Storage, einschließlich Azure Blob Storage, Azure Files, Azure Table Storage und Azure Queue Storage, bietet eine Reihe von Georedundanz- und Failoverfunktionen für unterschiedliche Anforderungen.

Von Bedeutung

Georedundanter Speicher (GRS) funktioniert nur innerhalb von Azure-gekoppelten Regionen. Wenn die Region Ihres Speicherkontos nicht gekoppelt ist, sollten Sie die benutzerdefinierten Multi-Region-Lösungen zur Resilienz verwenden.

Georedundanter Speicher für gekoppelte Regionen

Azure Storage bietet mehrere Arten von GRS in gekoppelten Regionen. Unabhängig davon, welche Art von GRS Sie verwenden, werden Daten in der sekundären Region immer mithilfe von lokal redundantem Speicher (LRS) repliziert. Dieser Ansatz bietet Schutz vor Hardwarefehlern innerhalb der sekundären Region.

Von Bedeutung

Azure Files unterstützt nur Georedundanz (GRS oder GZRS) für Standard (HDD)-Dateifreigaben.

Azure Files unterstützt nicht georedundanten Speicher mit Lesezugriff (RA-GRS) oder geozonenredundanten Speicher mit Lesezugriff (RA-GZRS). Wenn ein Speicherkonto für die Verwendung von RA-GRS oder RA-GZRS konfiguriert ist, werden die Standarddateifreigaben (HDD) als GRS oder GZRS konfiguriert und in Rechnung gestellt.

Failovertypen

Azure Storage unterstützt drei Arten von Failover für verschiedene Szenarien.

  • Kundenseitig verwaltetes nicht geplantes Failover: Sie sind für das Initiieren der Wiederherstellung verantwortlich, wenn in Ihrer primären Region ein regionsweiter Speicherfehler auftritt.

  • Vom Kunden verwaltetes geplantes Failover: Sie sind für das Initiieren der Wiederherstellung verantwortlich, wenn ein anderer Teil Ihrer Lösung einen Fehler in Ihrer primären Region aufweist und Sie die gesamte Lösung in eine sekundäre Region umstellen müssen. Verwenden Sie ein geplantes Failover, wenn der Speicher in der primären Region betriebsbereit bleibt, aber Sie die gesamte Lösung in eine sekundäre Region verschieben müssen, zum Beispiel bei Notfallwiederherstellungs-Übungen, die darauf abzielen, Compliance- und Audit-Anforderungen zu erfüllen.

  • Von Microsoft verwaltetes Failover: Unter außergewöhnlichen Umständen kann Microsoft ein Failover für alle georedundanten Speicherkonten (GRS) in einer Region initiieren. Das von Microsoft verwaltete Failover ist jedoch ein letztes Mittel und wird erwartet, dass es nur nach einem längeren Zeitraum des Ausfalls ausgeführt wird. Sie sollten sich nicht auf das von Microsoft verwaltete Failover verlassen.

GRS-Konten können jeden dieser Failovertypen verwenden. Sie müssen kein Speicherkonto vorkonfigurieren, um einen der Failovertypen vorab zu verwenden.

Anforderungen

  • Nur Standarddateifreigaben: Azure Files unterstützt nur Georedundanz (GRS oder GZRS) für Standardmäßige (HDD)-Dateifreigaben. SSD-Dateifreigaben müssen LRS oder ZRS verwenden. Wenn Sie über Premium-Dateifreigaben verfügen und die Daten über Regionen hinweg replizieren möchten, um eine höhere Resilienz zu erhalten, lesen Sie benutzerdefinierte Lösungen mit mehreren Regionen zur Resilienz.

  • Nur GRS und GZRS: Azure Files unterstützt keinen georedundanten Lesezugriffsspeicher (RA-GRS) oder Lesezugriff auf geozonenredundanten Speicher (RA-GZRS). Wenn ein Speicherkonto für die Verwendung von RA-GRS oder RA-GZRS konfiguriert ist, werden die Standarddateifreigaben (HDD) als GRS oder GZRS konfiguriert und in Rechnung gestellt.

Überlegungen

Berücksichtigen Sie beim Implementieren von Azure Files mit mehreren Regionen die folgenden wichtigen Faktoren:

  • Asynchrone Replikationswartezeit: Die Datenreplikation in die sekundäre Region ist asynchron. Dies bedeutet, dass zwischen dem Schreiben von Daten in die primäre Region und deren Verfügbarkeit in der sekundären Region ein Verzögerung besteht. Diese Verzögerung kann zu einem potenziellen Datenverlust führen, wenn ein Primärregionsfehler auftritt, bevor die letzten Daten repliziert werden. Der Datenverlust wird durch Recovery Point Objective (RPO) gemessen. Sie können davon ausgehen, dass die Replikationsverzögerung weniger als 15 Minuten beträgt, aber diese Zeit ist eine Schätzung und nicht garantiert.

    Sie können die Eigenschaft Letzte Synchronisierungszeit überprüfen, um zu verstehen, wie viele Daten verloren gehen können, wenn bei Ihrem Speicherkonto ein ungeplantes Failover auftritt.

  • Zeitpunkt der letzten Synchronisierung: Bei Azure Files basiert die letzte Synchronisierungszeit auf der neuesten Systemmomentaufnahme in der sekundären Region.

    Die Berechnung der letzten Synchronisierungszeit kann eine Zeitüberschreitung verursachen, wenn mehr als 100 Dateifreigaben in einem Speicherkonto vorhanden sind. Es wird empfohlen, 100 oder weniger Dateifreigaben für jedes Speicherkonto bereitzustellen, um Timeouts zu vermeiden.

  • Zugriff auf sekundäre Regionen: Auf die sekundäre Region kann erst zugegriffen werden, wenn ein Failover auftritt.

  • Featurebeschränkungen: Einige Azure Files-Features werden nicht unterstützt oder haben Einschränkungen, wenn Sie GRS oder vom Kunden verwaltetes Failover verwenden. Diese Einschränkungen umfassen bestimmte Dateifreigabetypen, Zugriffsebenen und Verwaltungstools und -vorgänge. Überprüfen Sie die Featurekompatibilitätsdokumentation , bevor Sie Georedundanz implementieren.

Kosten

Konfigurationen für Azure Storage-Konten mit mehreren Regionen verursachen zusätzliche Kosten für die regionsübergreifende Replikation und den Speicher in der sekundären Region. Die Datenübertragung zwischen Azure-Regionen wird basierend auf standardmäßigen Bandbreitenraten zwischen Regionen berechnet.

Ausführliche Preisinformationen finden Sie unter Azure Files-Preise.

Konfigurieren der Unterstützung für mehrere Regionen

  • Erstellen Sie ein neues Konto mit georedundantem Speicher (GRS). Informationen zum Erstellen eines GRS-Kontos finden Sie unter Erstellen eines Speicherkontos. Wählen Sie GRS, georedundanter Speicher mit Lesezugriff (RA-GRS), geozonenredundanter Speicher (GZRS) oder geozonenredundanter Speicher mit Lesezugriff (RA-GZRS) während der Kontoerstellung aus.

  • Aktivieren Sie Georedundanz für ein vorhandenes Dateispeicherkonto. Informationen zum Konvertieren eines vorhandenen Dateispeicherkontos in GRS finden Sie unter Ändern der Redundanzkonfiguration für Azure Files.

    Warnung

    Nachdem Ihr Konto für Georedundanz neu konfiguriert wurde, kann es eine erhebliche Zeit dauern, bis vorhandene Daten in der neuen primären Region vollständig in die neue sekundäre Region kopiert werden.

    Um einen großen Datenverlust zu vermeiden, überprüfen Sie den Wert der Eigenschaft Letzte Synchronisierungszeit, bevor Sie ein ungeplantes Failover initiieren. Um potenzielle Datenverluste auszuwerten, vergleichen Sie die letzte Synchronisierungszeit mit dem zeitpunkt, zu dem Daten in den neuen primären Bereich geschrieben wurden.

  • Georedundanz deaktivieren. Setzen Sie GRS-Konten durch denselben Prozess der Änderung der Redundanzkonfiguration auf einzelregionale Konfigurationen (LRS oder ZRS) zurück.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein Speicherkonto für Georedundanz konfiguriert ist und alle Regionen betriebsbereit sind.

  • Datenverkehrsrouting zwischen Regionen: Azure Files verwendet einen aktiv-passiven Ansatz, bei dem alle Lese- und Schreibvorgänge an die primäre Region geleitet werden.

  • Datenreplikation zwischen Regionen: Schreibvorgänge werden zunächst mithilfe des konfigurierten Redundanztyps (LRS für GRS oder ZRS für GZRS) an die primäre Region gebunden. Nach erfolgreichem Abschluss im primären Bereich werden Die Daten asynchron in den sekundären Bereich repliziert, in dem sie mithilfe von LRS gespeichert werden.

    Die asynchrone Art der regionsübergreifenden Replikation bedeutet, dass es in der Regel einen Zeitabstand zwischen dem Schreiben von Daten in die primäre Region und der Verfügbarkeit in der sekundären Region gibt. Sie können die Replikationszeit mithilfe der Eigenschaft Letzte Synchronisierungszeit überwachen.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein Speicherkonto für Georedundanz konfiguriert ist und ein Ausfall in der primären Region vorhanden ist.

  • Kundenseitig verwaltetes Failover (ungeplant): Verwenden Sie ein ungeplantes Failover, wenn der Speicher in der primären Region nicht verfügbar ist.

    • Erkennung und Reaktion: Im unwahrscheinlichen Fall, dass Ihr Speicherkonto in Ihrer primären Region nicht verfügbar ist, können Sie erwägen, ein vom Kunden verwaltetes nicht geplantes Failover zu initiieren. Berücksichtigen Sie die folgenden Faktoren, um diese Entscheidung zu treffen:

      • Gibt an, ob Azure Resource Health Probleme beim Zugriff auf das Speicherkonto in Ihrer primären Region anzeigt.

      • Gibt an, ob Microsoft Ihnen empfiehlt, ein Failover in eine andere Region durchzuführen.

      Warnung

      Ein ungeplantes Failover kann zu Datenverlust führen. Bevor Sie ein kundenseitig verwaltetes Failover initiieren, entscheiden Sie, ob die Wiederherstellung des Diensts das Risiko eines Datenverlusts rechtfertigt.

    • Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Aber:

    • Aktive Anforderungen: Während des Failoverprozesses werden sowohl die Endpunkte des primären als auch des sekundären Speicherkontos für Lese- und Schreibvorgänge vorübergehend nicht verfügbar. Möglicherweise werden alle aktiven Anforderungen gelöscht, und Clientanwendungen müssen nach Abschluss des Failovers erneut versuchen.

    • Erwarteter Datenverlust: Datenverlust tritt bei einem ungeplanten Failover aufgrund der asynchronen Replikationsverzögerung häufig auf. Dies bedeutet, dass zuletzt verwendete Schreibvorgänge möglicherweise nicht repliziert werden. Sie können die Eigenschaft Letzte Synchronisierungszeit überprüfen, um zu verstehen, wie viele Daten während eines ungeplanten Failovers verloren gehen könnten. Erwarteter Datenverlust wird häufig als Ziel des Wiederherstellungspunkts (Recovery Point Objective, RPO) bezeichnet. Sie können in der Regel davon ausgehen, dass das RPO weniger als 15 Minuten beträgt, aber diese Zeit ist nicht garantiert.

    • Erwartete Ausfallzeiten: Die Menge der erwarteten Ausfallzeiten wird häufig als Wiederherstellungszeitziel (RTO) bezeichnet. Das vom Kunden verwaltete Failover wird in der Regel innerhalb von 60 Minuten abgeschlossen, je nach Kontogröße und Komplexität.

    • Datenverkehrsumleitung: Nach Abschluss des Failovers aktualisiert Azure automatisch die Endpunkte des Speicherkontos, sodass Anwendungen nicht neu konfiguriert werden müssen. Wenn Ihre Anwendung DNS-Einträge (Domain Name System) zwischengespeichert hat, muss der Cache möglicherweise gelöscht werden, um sicherzustellen, dass die Anwendung Datenverkehr an die neue primäre Region sendet.

    • Konfiguration nach dem Failover: Nach Abschluss eines ungeplanten Failovers verwendet Ihr Speicherkonto in der Zielregion die lokal redundante Speicherebene (LRS). Wenn Sie es erneut replizieren müssen, müssen Sie den georedundanten Speicher (GRS) erneut aktivieren und warten, bis die Daten in die neue sekundäre Region repliziert werden.

    Weitere Informationen zum Initiieren eines kundenseitig verwalteten Failovers finden Sie unter Funktionsweise eines kundenseitig verwalteten (ungeplanten) Failovers und Initiieren eines Speicherkontofailovers.

  • Kundenseitig verwaltetes Failover (geplant): Verwenden Sie ein geplantes Failover, wenn der Speicher in der primären Region betriebsbereit bleibt, aber Sie aus einem anderen Grund ein Failover für die gesamte Lösung in eine sekundäre Region durchführen müssen. Beispielsweise kann ein anderer Azure-Dienst ein Problem haben, und Sie müssen zur Verwendung einer sekundären Region für Ihre gesamte Lösung wechseln. Oder Sie können ein geplantes Failover verwenden, um einen Notfallwiederherstellungs-Test für Compliance- und Prüfzwecke durchzuführen.

    • Erkennung und Reaktion: Sie sind für die Ausführung eines Failovers verantwortlich. Diese Entscheidung treffen Sie normalerweise, wenn Sie zwischen Regionen ein Failover durchführen müssen, selbst wenn Ihr Speicherkonto in Ordnung ist. Sie können z. B. ein Failover auslösen, wenn es zu einem großen Ausfall eines anderen Anwendungskomponents kommt, von dem Sie sich in der primären Region nicht erholen können.

      • Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Aber:

    • Aktive Anforderungen: Während des Failoverprozesses werden sowohl die Endpunkte des primären als auch des sekundären Speicherkontos für Lese- und Schreibvorgänge vorübergehend nicht verfügbar. Möglicherweise werden alle aktiven Anforderungen gelöscht, und Clientanwendungen müssen nach Abschluss des Failovers erneut versuchen.

    • Erwarteter Datenverlust: Es wird kein Datenverlust erwartet, da der Failovervorgang erst abgeschlossen wird, nachdem alle Daten synchronisiert wurden, was zu einem RPO von Null führt.

    • Erwartete Ausfallzeiten: Failover wird in der Regel innerhalb von 60 Minuten abgeschlossen, was bedeutet, dass die erwartete RTO je nach Kontogröße und Komplexität 60 Minuten beträgt. Während des Failoverprozesses werden sowohl die Endpunkte des primären als auch des sekundären Speicherkontos für Lese- und Schreibvorgänge vorübergehend nicht verfügbar.

    • Datenverkehrsumleitung: Nach Abschluss des Failovers aktualisiert Azure automatisch die Endpunkte des Speicherkontos, sodass Anwendungen nicht neu konfiguriert werden müssen. Wenn Ihre Anwendung DNS-Einträge zwischengespeichert hat, muss der Cache möglicherweise gelöscht werden, um sicherzustellen, dass die Anwendung Datenverkehr an die neue primäre Region sendet.

    • Konfiguration nach dem Failover: Nach Abschluss eines geplanten Failovers wird Ihr Speicherkonto in der Zielregion weiterhin georeplikatiert und verbleibt auf der GRS-Ebene.

    Weitere Informationen zum Initiieren eines kundenseitig verwalteten Failovers finden Sie unter Funktionsweise des vom Kunden verwalteten (geplanten) Failovers und Initiieren eines Speicherkontofailovers.

  • Von Microsoft verwaltetes Failover: Im seltenen Fall einer großen Katastrophe, bei der Microsoft feststellt, dass die primäre Region dauerhaft nicht wiederhergestellt werden kann, kann ein automatisches Failover in die sekundäre Region initiiert werden. Microsoft verarbeitet den gesamten Prozess, und es ist keine Kundenaktion erforderlich. Die Zeitspanne, die vor dem Failover verstrichen ist, hängt vom Schweregrad der Katastrophe und der Zeit ab, die zum Bewerten der Situation erforderlich ist.

    • Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Aber:

    Von Bedeutung

    Verwenden Sie vom Kunden verwaltete Failoveroptionen, um Ihre DR-Pläne zu entwickeln, zu testen und zu implementieren. Verlassen Sie sich nicht auf ein von Microsoft verwaltetes Failover, das nur unter extremen Umständen verwendet werden kann. Ein von Microsoft verwaltetes Failover wird wahrscheinlich für eine gesamte Region initiiert. Sie kann nicht für einzelne Speicherkonten, Abonnements oder Kunden initiiert werden. Failover kann zu unterschiedlichen Zeiten für verschiedene Azure-Dienste auftreten. Es wird empfohlen, das kundenseitig verwaltete Failover zu verwenden.

Regionswiederherstellung

Der Failbackprozess unterscheidet sich erheblich zwischen vom Microsoft verwalteten und kundenseitig verwalteten Failoverszenarien.

  • Kundenseitig verwaltetes Failover (ungeplant): Nach einem ungeplanten Failover wird das Speicherkonto mit lokal redundanten Speicher (LRS) konfiguriert. Für ein Failback, müssen Sie die georedundante Speicherbeziehung (GRS) neu einrichten und warten, bis die Daten repliziert werden.

  • Kundenseitig verwaltetes Failover (geplant): Nach einem geplanten Failover bleibt das Speicherkonto georepliziert. Sie können ein weiteres kundenseitig verwaltetes Failover initiieren, um zu der ursprünglichen primären Region zurückzukehren. Es gelten dieselben Failoverüberlegungen.

  • Von Microsoft verwaltetes Failover: Wenn Microsoft ein Failover initiiert, ist es wahrscheinlich, dass in der primären Region ein erheblicher Notfall aufgetreten ist und die primäre Region möglicherweise nicht wiederhergestellt werden kann. Alle Zeitpläne oder Wiederherstellungspläne hängen vom Umfang der regionalen Notfall- und Wiederherstellungsbemühungen ab. Sie sollten die Azure Service Health-Kommunikation auf Details überwachen.

Test auf Regionsfehler

Bei GRS-Konten können Sie geplante Failovervorgänge während der Wartungsfenster ausführen, um den vollständigen Failover- und Failbackprozess zu testen. Geplantes Failover erfordert keinen Datenverlust, erfordert aber ausfallzeiten sowohl während des Failovers als auch des Failbacks.

Benutzerdefinierte Lösungen mit mehreren Regionen für Resilienz

Die regionsübergreifenden Failoverfunktionen von Azure Storage sind aus den folgenden Gründen möglicherweise nicht geeignet:

  • Ihr Speicherkonto befindet sich in einer nicht gepaarten Region.

  • Ihre Geschäftsbetriebsziele sind nicht mit der Wiederherstellungszeit oder dem Datenverlust zufrieden, die die integrierten Failoveroptionen bereitstellen.

  • Sie müssen ein Failover zu einer Region ausführen, die nicht das Paar Ihrer primären Region ist.

  • Sie benötigen eine Aktiv-Aktiv-Konfiguration in allen Regionen.

  • Sie verwenden Dateifreigabetypen, die keine Georedundanz unterstützen.

Dieser Abschnitt enthält eine allgemeine Übersicht über einige zu berücksichtigende Ansätze. Eine umfassende Übersicht über Bereitstellungstopologien mit mehreren Regionen für Azure Storage liegt außerhalb des Umfangs dieses Artikels.

Berücksichtigen Sie die folgenden hochrangigen Ansätze:

  • Mehrere Speicherkonten: Azure Files kann über mehrere Regionen hinweg bereitgestellt werden, indem separate Speicherkonten in jeder Region verwendet werden. Dieser Ansatz bietet Flexibilität bei der Regionsauswahl, der Möglichkeit, nicht gekoppelte Regionen zu verwenden und eine genauere Kontrolle über den Replikationszeitpunkt und die Datenkonsistenz zu erreichen. Wenn Sie mehrere Speicherkonten regionsübergreifend implementieren, müssen Sie die regionsübergreifende Datenreplikation konfigurieren, Lastenausgleichs- und Failoverrichtlinien implementieren und die Datenkonsistenz in allen Regionen sicherstellen.

  • Replikation auf Anwendungsebene: Implementieren Sie benutzerdefinierte Replikationslogik mithilfe von Azure Data Factory oder AzCopy , um Daten zwischen Dateifreigaben in verschiedenen Regionen zu synchronisieren. Für diesen Ansatz sind benutzerdefinierte Entwicklungs- und Konfliktlösungsmechanismen erforderlich.

  • Verwenden Sie Azure File Sync, um Dateien in eine Dateifreigabe in einer anderen Azure-Region zu replizieren. Sie können Azure File Sync verwenden, um zwischen einer SMB Azure-Dateifreigabe (Cloudendpunkt), einem lokalen Windows-Dateiserver und einer bereitgestellten Dateifreigabe zu synchronisieren, die auf einem virtuellen Computer (VM) in einer anderen Azure-Region (einem DR-Serverendpunkt) ausgeführt wird.

    Bei diesem Ansatz müssen Sie mehrere Dateifreigaben und einen virtuellen Computer bereitstellen, um den Synchronisierungsprozess zu koordinieren.

    Wenn Sie diesen Ansatz für die Replikation von Dateien in mehreren Regionen verwenden:

    • Deaktivieren Sie das Cloud-Tiering, um sicherzustellen, dass alle Daten lokal auf dem Dateiserver vorhanden sind.

    • Stellen Sie genügend Speicherplatz auf dem virtuellen Azure-Computer bereit, um das gesamte Dataset zu speichern.

    • Greifen Sie auf Dateien auf dem Serverendpunkt und nicht in Azure zu, um sicherzustellen, dass Änderungen schnell in die sekundäre Region repliziert werden.

Sichern und Wiederherstellen

Die Sicherung von Azure Files ist eine systemeigene Integration zwischen Azure Files und Azure Backup, die darauf ausgelegt ist, Daten vor versehentlichen Löschungen, Beschädigungen und Ransomware-Angriffen zu schützen.

Die Azure Files-Backup erstellt Snapshots auf Freigabeebene, die im selben Speicherkonto gespeichert werden. Diese Funktion ermöglicht die schnelle Wiederherstellung einzelner Dateien und vollständiger Dateifreigaben. Sie können auch Sicherungsrichtlinien verwenden, um lange Aufbewahrungszeiträume mit anpassbarer Sicherungshäufigkeit bereitzustellen.

Sie können Ihre Momentaufnahmen erstellen und auf zwei verschiedene Arten speichern:

  • Speicher auf Freigabeebene: Für betriebs- und kurzfristige Wiederherstellungsszenarien können Sie Schnappschüsse auf Freigabeebene erstellen und diese innerhalb desselben Speicherkontos speichern. Momentaufnahmen auf Freigabeebene ermöglichen eine schnelle Wiederherstellung einzelner Dateien oder vollständiger Dateifreigaben auf den ursprünglichen oder einen alternativen Speicherort.

  • Gesicherter Backup-Speicher: Mithilfe des gesicherten Backups können Sie Ihre täglichen Momentaufnahmen in einem Azure Recovery Services-Vault kopieren. Um die Sicherheit zu verbessern, ist dieser Tresor isoliert und luftgespalten vom primären Speicherkonto.

    Wenn Sie eine gekoppelte Azure-Region verwenden und den Tresor für die Verwendung von GRS konfigurieren, repliziert der Tresor Daten in die gekoppelte Region. Diese Replikation unterstützt regionsübergreifende Wiederherstellungs- und DR-Workflows.

Service-Level-Vereinbarung

Der Servicelevelvertrag (SLA) für Azure Storage beschreibt die erwartete Verfügbarkeit des Diensts und die Bedingungen, die erfüllt werden müssen, um diese Verfügbarkeitserwartungen zu erreichen. Die Verfügbarkeits-SLA, für die Sie berechtigt sind, hängt von der Speicherebene und vom verwendeten Replikationstyp ab. Weitere Informationen finden Sie unter SLAs für Onlinedienste.

Verwandte Inhalte

  • Last updated on