Notfallwiederherstellung und Failover für Azure Files

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

Failover für die Azure-Dateisynchronisierung

Wenn Sie Azure-Dateisynchronisierung verwenden, lesen Sie zuerst diesen Abschnitt. Wenn Sie Azure-Dateisynchronisierung nicht verwenden, gilt dieser Abschnitt nicht.

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 beim Speicherkonto ein Failover stattgefunden hat, treten bei den Synchronisierungs- und Cloudebenenvorgängen Fehler auf, 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-Dateisynchronisierung 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.

Nach Abschluss eines Speicherkontofailovers (z. B. von Kanada Central nach Kanada East) erkennt Azure-Dateisynchronisierung den neuen Speicherort des Speicherkontos nicht automatisch. Die Steuerebene bleibt in der ursprünglichen ARM-Region registriert, während nur die Datenebene zur neuen Region migriert wird.

Führen Sie die folgenden Schritte aus, um ein Failover für Azure-Dateisynchronisierung auszuführen:

1. Wenden Sie sich an Microsoft-Support, um anzufordern, dass Azure-Dateisynchronisierung den neuen Speicherort des Speicherkontos berücksichtigen.
2. Nachdem Azure-Dateisynchronisierung aktualisiert wurde, leitet es Serververkehr (Data Plane) in die neue Region um. Die Steuerungsebene des Speichersynchronisierungsdiensts spiegelt möglicherweise weiterhin die ursprüngliche Region im Azure-Portal wider.

Das Azure-Portal zeigt nur den Steuerebenenstandort für die Speichersynchronisierung an. Der Endpunkt der Datenebene wird nicht verfügbar gemacht. Sie können überprüfen, ob Server auf die richtige Region verweisen, indem Sie mit Microsoft-Support arbeiten.

Kundenseitig verwaltetes geplantes Failover

Sie können kundengesteuertes geplantes Failover in mehreren Szenarien verwenden, einschließlich geplanter Disaster Recovery-Tests, einem proaktiven Ansatz bei groß angelegten Katastrophen oder zur Wiederherstellung von nicht speicherbedingten Ausfällen.

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.

Kosten und Metriken für die Notfallwiederherstellung

Um eine effektive Disaster-Recovery-Strategie zu formulieren, 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 HDD-Dateifreigaben, die mit georedundantem Speicher (GRS) und geozonenredundantem 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 beginnen, zum neuen primären Endpunkt zu 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.

Entwurf für Hochverfügbarkeit

Konzipieren Sie Ihre Anwendung von Anfang an auf hohe Verfügbarkeit. Sehen Sie sich diese Azure-Ressourcen für Hinweise zur Gestaltung Ihrer Anwendung und zur Planung der Katastrophenwiederherstellung an:

• 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.
• Verwendung von Georedundanz zum Entwerfen hochverfügbarer Anwendungen: Entwurfsleitfaden für das Erstellen von Anwendungen, um georedundanten Speicher für SMB-Dateifreigaben zu nutzen

Gestalte deine Anwendung außerdem so, dass sie auf mögliche Schreibfehler vorbereitet ist. 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.

Ausfälle verfolgen

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

Wenn Sie den Failover eines kundenverwalteten Kontos verwenden, können Sie Ihr gesamtes Speicherkonto auf die sekundäre Region übertragen, falls 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. Setzen Sie Ihre Arbeitslast so weit wie möglich aus, bevor Sie ein Konto-Failover starten.

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

Funktionsweise eines Kontofailovers

Unter normalen Umständen schreibt ein Client Daten auf ein Speicherkonto in der primären Region, und das System kopiert diese Daten asynchron in die sekundäre Region.

Wenn der primäre Endpunkt aus irgendeinem Grund nicht verfügbar ist, kann der Client nicht auf das Speicherkonto schreiben. Du kannst dann ein Konto-Failover einleiten. Diese Aktion aktualisiert den von Azure Storage bereitgestellten DNS-Eintrag, sodass der sekundäre Endpunkt zum neuen primären Endpunkt für Ihr Speicherkonto wird.

Der Schreibzugriff wird für georedundante Konten wiederhergestellt, nachdem der DNS-Eintrag aktualisiert wurde und Anfragen an den neuen primären Endpunkt weitergeleitet werden. Bestehende Speicherdienst-Endpunkte bleiben nach dem Failover gleich. Dateihandles und -leases werden beim Failover nicht beibehalten. Clients müssen daher die Bereitstellung der Dateifreigaben aufheben und Dateifreigaben erneut bereitstellen.

Datenverlust während des Failovers voraussehen

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.

Der Failover-Prozess verwaltet alle bereits auf die Sekundärstufe kopierten Daten. Allerdings gehen alle Daten, die auf den primären Knoten geschrieben und nicht auch auf den sekundären Knoten repliziert werden, dauerhaft verloren.

Überprüfen Sie die Eigenschaft „Letzte Synchronisierungszeit“

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 im Falle eines Failovers in einem konsistenten Zustand sind, erstellt die primäre Region alle 15 Minuten einen Systemsnapshot und repliziert ihn in die sekundäre Region. Wenn ein Failover in die sekundäre Region erfolgt, basiert der Freigabestatus auf der neuesten Systemmomentaufnahme in der sekundären Region. Wenn ein Fehler in der primären Region auftritt, liegt die sekundäre Region wahrscheinlich hinter der primären, da alle Schreibvorgänge in die primäre Region noch nicht in die sekundäre Region repliziert werden. Aufgrund von Geo-Lag (Replikationsverzögerung zwischen Regionen) oder anderen Problemen kann der neueste Systemsnapshot 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 unter Eigenschaft „Letzte Synchronisierungszeit“ für ein Speicherkonto überprüfen.

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 den Wert der Eigenschaft Letzte Synchronisierungszeit, bevor Sie zurückkehren. Vergleichen Sie die Zeit der letzten Synchronisierung mit dem Zeitpunkt, an dem die Daten in das neue primäre System geschrieben wurden, um den zu erwartenden Datenverlust zu bewerten.

Nach einem Failbackvorgang können Sie die neue primäre Region erneut als georedundant konfigurieren. Wenn das ursprüngliche primäre System für LRS konfiguriert war, können Sie es für GRS konfigurieren. Wenn das ursprüngliche Primary für ZRS konfiguriert wurde, können Sie es auf 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.

Bewährte Methoden für geplantes Geo-Failover

Stellen Sie vor dem Initiieren eines geplanten Failovers sicher, dass alle Anwendungs- und Clientaktivitäten für Azure-Dateifreigaben vollständig beendet werden. Aktive Lese- oder Schreibvorgänge während des Failovers können dazu führen, dass Dateifreigaben nach Abschluss des Failovers einen inkonsistenten Zustand erreichen.

Vor dem Starten des Failovers:

• Beenden Sie alle Anwendungen und Clients, die auf Azure-Dateifreigaben zugreifen.
• Stellen Sie sicher, dass keine aktive Ein-/Ausgabe (Schreib- oder Lesevorgang) in einer Dateifreigabe des Speicherkontos vorhanden ist.
• Stellen Sie sicher, dass in den Dateifreigaben keine geöffneten Dateihandler vorhanden sind.
• Verwenden Sie das Azure PowerShell-Cmdlet "Get-AzStorageFileHandle ", um aktive Dateihandles und verbundene Client-IP-Adressen aufzulisten.
• Beenden Sie alle Client-IP-Adressen, die in den Ergebnissen angezeigt werden, bevor Sie den Failovervorgang für das Speicherkonto starten.

Fahren Sie mit dem geplanten Failover nur fort, wenn alle Dateifreigaben inaktiv sind und keine aktiven Clientverbindungen vorhanden sind.

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

• Azure Files-Redundanz
• Übersicht über den Schutz von Daten in Azure Files
• Initiieren eines Speicherkontofailovers