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, 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.
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:
- 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
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:
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:
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:
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 Wichtige Auswirkungen eines Kontofailoovers.
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.