Freigeben über

Notfallwiederherstellung und Failover für Azure Files

  • Artikel

Microsoft möcht sicherstellen, dass Azure-Dienste immer verfügbar sind. Es kann jedoch zu ungeplanten Dienstausfällen kommen, und Sie sollten über einen Notfallwiederherstellungsplan (Disaster Recovery, DR) für den Umgang mit einem regionalen Dienstausfall verfügen. Ein wichtiger Teil eines Notfallwiederherstellungsplans ist die Vorbereitung auf den Ausfall des sekundären Endpunkts, falls der primäre Endpunkt nicht mehr verfügbar ist. In diesem Artikel werden die Konzepte und Prozesse beschrieben, die mit der Notfallwiederherstellung und dem Failover von Speicherkonten verbunden sind.

Wichtig

Azure-Dateisynchronisierung unterstützt nur das Failover des Speicherkontos, wenn der Speichersynchronisierungsdienst ebenfalls fehlgeschlagen ist. Der Grund dafür ist, dass Azure-Dateisynchronisierung das Speicherkonto und den Speichersynchronisierungsdienst in derselben Azure-Region benötigt. Wenn nur das Speicherkonto fehlgeschlagen ist, schlagen die Synchronisierungs- und Cloudebenenvorgänge fehl, bis der Speichersynchronisierungsdienst in der sekundären Region ausgeführt wird. Wenn Sie ein Failover eines Speicherkontos mit Azure-Dateifreigaben, die als Cloudendpunkte in Azure File Sync verwendet werden, ausführen möchten, finden Sie unter bewährte Methoden für die Notfallwiederherstellung von Azure-Dateisynchronisierung und Serverwiederherstellung für Azure-Dateisynchronisierung weitere Informationen.

Kundenseitig verwaltetes geplantes Failover (Preview)

Das kundenseitig verwaltete geplante Failover kann auch in mehreren Szenarien verwendet werden, einschließlich geplanter Notfallwiederherstellungstests, eines proaktiven Ansatzes für umfangreiche Notfälle oder zum Wiederherstellen von nicht speicherbezogenen Ausfallen.

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.

Wenn Sie die Vorschauversion aktivieren möchten, informieren Sie sich unter Einrichten von Previewfunktionen im Azure-Abonnement, und geben Sie AllowSoftFailover als Name des Features an. Der Anbietername für diese Previewfunktion ist Microsoft.Storage.

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.

Kosten und Metriken für die Notfallwiederherstellung

Um eine effektive Notfallstrategie zu definieren, muss eine Organisation Folgendes verstehen:

  • Wie viel Datenverlust sich die Organisation bei einem Ausfall leisten kann (Recovery Point Objective, RPO)
  • Wie schnell Geschäftsfunktionen und -daten wiederhergestellt werden müssen (Recovery Time Objective, RTO)

Die Kosten für die Notfallwiederherstellung steigen in der Regel, wenn RPO/RTO niedrig oder null ist. Unternehmen, die nach einem Notfall in wenigen Sekunden betriebsbereit sein müssen und keinen Datenverlust in Kauf nehmen können, zahlen mehr für die Notfallwiederherstellung, während die Kosten für Organisationen mit höheren RPO/RTO-Werten geringer sind. Azure bietet Lösungen, die verschiedene RPO- und RTO-Anforderungen erfüllen.

Auswählen der richtigen Redundanzoption

Azure Files umfasst verschiedene Redundanzoptionen, um Ihre Daten vor geplanten und ungeplanten Ereignissen zu schützen, die von vorübergehenden Hardwarefehlern, Netzwerk- und Stromausfällen bis hin zu Naturkatastrophen reichen können. Alle Azure-Dateifreigaben können lokal redundanten (LRS) oder zonenredundanten Speicher (ZRS) verwenden. Weitere Informationen finden Sie unter Azure Files-Redundanz.

Azure Files unterstützt ein Kontofailover für Standardspeicherkonten, die mit georedundanten Speicher (GRS) und geozonenredundanten Speicher (GZRS) zum Schutz vor regionalen Ausfällen konfiguriert sind. Mit Kontofailover können Sie den Failoverprozess für Ihr Speicherkonto einleiten, wenn der primäre Endpunkt nicht mehr verfügbar ist. Bei einem Failover wird der sekundäre Endpunkt so aktualisiert, dass er zum primären Endpunkt für das Speicherkonto wird. Nach Abschluss des Failovers können Clients in den neuen primären Endpunkt schreiben.

GRS und GZRS bergen trotzdem das Risiko eines Datenverlusts, da Daten asynchron in die sekundäre Region kopiert werden. Dies bedeutet, dass es zu einer Verzögerung kommt, bevor ein Schreibvorgang in der primären Region in die sekundäre Region kopiert wird. Bei einem Ausfall gehen Schreibvorgänge auf den primären Endpunkt, die noch nicht auf den sekundären Endpunkt kopiert wurden, verloren. Ein Ausfall, der die primäre Region betrifft, kann daher zu Datenverlust führen, wenn die primäre Region nicht wiederhergestellt werden kann. Das Intervall zwischen den letzten Schreibvorgängen in der primären Region und dem letzten Schreibvorgang in der sekundären Region wird als RPO (Recovery Point Objective) bezeichnet. Azure Files weist normalerweise einen RPO-Wert von 15 Minuten oder weniger auf, aber es gibt derzeit keine SLA zur Dauer der Replikation in die sekundäre Region.

Wichtig

GRS/GZRS werden für Azure-Premium-Dateifreigaben nicht unterstützt. Sie können jedoch eine Synchronisierung zwischen zwei Azure-Dateifreigaben ausführen, um geografische Redundanz zu erzielen.

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:

Außerdem wird empfohlen, Ihre Anwendung so zu gestalten, dass die Möglichkeit von Ausfällen bei Schreibvorgängen berücksichtigt wird. Ihre Anwendung sollte Schreibfehler so erkennen, dass Sie auf die Möglichkeit eines Ausfalls in der primären Region aufmerksam gemacht werden.

Als bewährte Methode sollten Sie Ihre Anwendung so entwerfen, dass Sie anhand der Eigenschaft „Letzte 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.

Nachverfolgen von Ausfällen

Sie können das Azure Service Health-Dashboard abonnieren, um die Integrität und den Status von Azure Files und anderen Azure-Diensten zu verfolgen.

Verstehen des Kontofailoverprozesses

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

Weitere Informationen zum Initiieren eines Failovers finden Sie unter Initiieren eines Kontofailovers.

Funktionsweise eines Kontofailovers

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

Diagramm: Clients schreiben Daten in das Speicherkonto in der primären Region.

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

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

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

Diagramm: Der Kunde initiiert das Kontofailover zum sekundären Endpunkt.

Der Schreibzugriff für georedundante Konten wird wiederhergestellt, sobald der DNS-Eintrag aktualisiert wurde und Anforderungen an den neuen primären Endpunkt geleitet werden. Bestehende Speicherdienstendpunkte bleiben nach dem Failover unverändert. Dateihandles und -leases werden beim Failover nicht beibehalten. Clients müssen daher die Bereitstellung der Dateifreigaben aufheben und Dateifreigaben erneut bereitstellen.

Wichtig

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

Beachten Sie, dass die Konvertierung eines lokal redundanten Speicherkontos zur Nutzung von Georedundanz sowohl mit Kosten als auch Zeit verbunden ist. Weitere Informationen finden Sie unter Die Zeit und Kosten eines Failovers.

Vorhersehen von Datenverlust

Achtung

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

Da Daten asynchron aus der primären Region in die sekundäre Region geschrieben werden, wurden die letzten Schreibvorgänge möglicherweise noch nicht in die sekundäre Region kopiert, wenn die primäre Region ausfällt.

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

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

Überprüfen der Eigenschaft für die letzte Synchronisierung

Die Eigenschaft Letzte Synchronisierung (Last Sync Time, LST) gibt an, wann die Daten aus der primären Region garantiert in die sekundäre Region geschrieben wurden. Alle Daten, die vor der letzte Synchronisierung geschrieben wurden, sind in der sekundären Region verfügbar, während Daten, die nach der letzten Synchronisierung geschrieben wurden, möglicherweise nicht in die sekundären Region geschrieben wurden und verloren gegangen sind. Verwenden Sie diese Eigenschaft bei einem Ausfall, um die Höhe des Datenverlustes abzuschätzen, der durch die Einleitung eines Kontofailovers entstehen kann.

Um sicherzustellen, dass Dateifreigaben bei einem Failover einen konsistenten Zustand aufweisen, wird alle 15 Minuten eine Momentaufnahme des Systems in der primären Region erstellt und in die sekundäre Region repliziert. Wenn ein Failover auf die sekundäre Region erfolgt, basiert der Freigabestatus auf der aktuellsten Momentaufnahme des Systems in der sekundären Region. Wenn in der primären Region ein Fehler auftritt, befindet sich die sekundäre Region wahrscheinlich hinter der primären Region, da sämtliche Schreibvorgänge im primären Replikat noch nicht in die sekundäre Region repliziert wurden. Aufgrund von geografisch bedingten Verzögerungen oder anderen Problemen kann die aktuellste Momentaufnahme des Systems in der sekundären Region älter als 15 Minuten sein.

Alle Schreibvorgänge, die vor der LST in die primäre Region geschrieben wurden, wurden erfolgreich in die sekundäre Region repliziert, sodass sie für das Lesen aus der sekundären Region zur Verfügung stehen. Alle Schreibvorgänge, die nach der letzten Synchronisationszeit in die primäre Region geschrieben wurden, können ggf. in die sekundäre Region repliziert worden sein (oder auch nicht), sodass sie möglicherweise nicht für Lesevorgänge zur Verfügung stehen.

Sie können den Wert der Eigenschaft Letzte Synchronisationszeit mit Azure PowerShell, der Azure CLI oder der Clientbibliotheken abfragen. Die Eigenschaft Last Sync Time ist ein GMT-Datums-/Uhrzeitwert. Weitere Informationen finden Sie unter Überprüfen der Eigenschaft „Letzte Synchronisierung“ für ein Speicherkonto.

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

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

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

Um einen größeren Datenverlust zu vermeiden, überprüfen Sie vorher den Wert der Eigenschaft Letzte Synchronisierung. Vergleichen Sie die letzte Synchronisierung mit dem Zeitpunkt, an dem die Daten in die neue primäre Region geschrieben wurden, um den erwarteten Datenverlust zu bewerten.

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

Initiieren eines Kontofailovers

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

Von Microsoft verwaltetes Failover

Wenn eine Region in extremen Fällen durch eine schwerwiegenden Notfall verloren geht, kann Microsoft ein regionales Failover initiieren. In diesem Fall ist keine weitere Aktion erforderlich. Bis zum Abschluss des von Microsoft verwalteten Failovers haben Sie keinen Schreibzugriff auf Ihr Speicherkonto.

Siehe auch