Zuverlässigkeit in Azure Speichervorgänge

Azure Storage Actions ist eine vollständig verwaltete Plattform, die Datenverwaltungsaufgaben für Azure Blob Storage und Azure Data Lake Storage automatisiert. Sie planen Speicheraufgaben so, dass sie für Ihre Speicherkonten ausgeführt werden. Sie können Aufgaben konfigurieren, um Blobs zu löschen, BLOB-Tags festzulegen und Zugriffsstufen basierend auf dem Alter Ihrer Daten zu ändern.

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 Storage Aktionen für vorübergehende Fehler, Konfigurationsprobleme, Verfügbarkeitszonenfehler, regionsweite Fehler und Dienstwartung widerstandsfähig machen. Darüber hinaus werden Sicherungs- und Wiederherstellungsoptionen sowie wichtige Informationen zum Azure Storage Actions-Service-Level-Agreement (SLA) beschrieben.

Important

Wenn Sie die Zuverlässigkeit von Azure Storage Aktionen berücksichtigen, berücksichtigen Sie jedes Speicherkonto, das über eine Speicheraufgabenzuweisung verfügt. Microsoft verwaltet die Verfügbarkeit des Storage Actions-Diensts. Sie sind für die Auswahl von Redundanzkonfigurationen für Speicherkonten verantwortlich, die den Zuverlässigkeitsanforderungen Ihrer Workload entsprechen. Ein Speicherkontoausfall kann die Ausführung zugewiesener Speicheraufgaben verhindern, auch wenn die Storage Actions-Steuerungsebene weiterhin verfügbar ist. Informationen zu den Zuverlässigkeitsmerkmalen von Redundanzkonfigurationen von Speicherkonten finden Sie unter Zuverlässigkeit in Azure Blob Storage.

Empfehlungen für die Produktionsimplementierung für Zuverlässigkeit

Für Produktionsarbeitslasten empfehlen wir Folgendes:

  • Konfigurieren Sie jedes Zielspeicherkonto mit der Redundanzoption, die Ihre Zuverlässigkeitsanforderungen erfüllt. Verwenden Sie für die meisten Produktionsworkloads mindestens einen zonenredundanten Speicher (ZRS). Wenn Sie Resilienz für einen regionsweiten Ausfall benötigen und sich Ihr Speicherkonto in einer gekoppelten Region befindet, verwenden Sie den geozonenredundanten Speicher (GZRS). Die Ausführung der Speicheraufgabe erbt die Zuverlässigkeitsmerkmale des Zielspeicherkontos.

  • Aktivieren Sie blob soft delete, bevor Sie Speicheraufgaben zum Löschen von Blobs verwenden. Aktivieren Sie vorläufiges Löschen für Blobs für jedes Zielspeicherkonto, damit Sie Blobs, die durch eine Speicheraufgabe unbeabsichtigt gelöscht wurden, während der Aufbewahrungsdauer wiederherstellen können.

  • Vermeiden Sie Überschneidungen zwischen Speicheraufgaben und anderen Richtlinien für die Lebenszyklusverwaltung. Konfigurieren Sie eine Speicheraufgabe und eine andere Richtlinie für die Lebenszyklusverwaltung nicht so, dass sie widersprüchliche Vorgänge für dieselben Blobs ausführen. Ein Löschvorgang für Speicheraufgaben kann z. B. fehlschlagen, wenn eine Blob Storage Lifecycle-Verwaltungsrichtlinie versucht, dasselbe Blob zu löschen.

  • Überprüfen Sie ihre Konfiguration für Speicheraktionen, bevor Sie sie anwenden. Verwenden Sie eine Bedingungsvorschau für eine fokussierte Überprüfung, während Sie Aufgabenbedingungen verfassen, und verwenden Sie eine Simulierte Ausführung , um die vollständige Zuweisung zu überprüfen, bevor Sie sie zum Ausführen von Vorgängen aktivieren.

Übersicht über die Zuverlässigkeitsarchitektur

In diesem Abschnitt werden einige der wichtigen Aspekte der Funktionsweise des Diensts beschrieben, die aus Zuverlässigkeitsperspektive am relevantesten sind. Im Abschnitt wird die logische Architektur vorgestellt, die einige der Ressourcen und Features enthält, die Sie bereitstellen und verwenden. Außerdem wird die physische Architektur erläutert, die Details zur Funktionsweise des Diensts unter den Deckeln bereitstellt.

Logische Architektur

Wenn Sie Azure Storage Actions verwenden, erstellen Sie eine oder mehrere Ressourcen vom Typ Speicheraufgabe. Jede Speicheraufgabe enthält Bedingungen zur Auswahl von Objekten sowie Vorgänge, die für übereinstimmende Objekte ausgeführt werden sollen. Um eine Speicheraufgabe für ein Speicherkonto auszuführen, erstellen Sie eine Speicheraufgabenzuweisung. Die Zuordnung wird als Teil der Speicherkontoressource gespeichert und identifiziert die Objekte, die als Ziel dienen sollen, wann und wie oft der Vorgang ausgeführt wird und wo Ausführungsberichte gespeichert werden. Wenn eine Aufgabenausführung den Completed Status erreicht, schreibt der Dienst einen Ausführungsbericht an den in der Zuordnung angegebenen Speicherort.

Sie sind dafür verantwortlich, jede Zuordnung zu konfigurieren und der verwalteten Identität der Speicheraufgabe eine entsprechende Azure Rolle zuzuweisen.

Physische Architektur

Azure Storage Actions weisen zwei Ebenen auf, die für die Zuverlässigkeit relevant sind:

  • Steuerebene: Anfragen fließen über Azure Resource Manager an den Ressourcenanbieter Azure Storage Actions, der Verwaltungsvorgänge und asynchrone Bereitstellungsworkflows für Speicheraufgaben und Zuordnungen verarbeitet.

  • Datenebene: Enthält den Scheduler, Worker, die Speicheraufgabenbedingungen auswerten und die konfigurierten Vorgänge für Zielspeicherkonten ausführen, sowie Berichtskomponenten. Diese Komponenten laufen auf der Azure-Storage-Infrastruktur.

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.

Vorübergehende Fehler können Azure Storage Actions auf zwei Hauptarten beeinträchtigen:

  • Verwaltungsvorgänge: Wenn Sie die Verwaltung von Speicheraktionen automatisieren, z. B. das Bereitstellen oder Ändern von Speicheraufgaben, sind Sie für die Behandlung vorübergehender Fehler in Ihrer Automatisierung verantwortlich. Verwenden Sie begrenzte Wiederholungsversuche mit einer angemessenen Verzögerung zwischen den Versuchen.

  • Aufgabenausführung: Wenn ein Zielspeicherkonto Vorgänge drosselt, reduziert Azure Storage Actions die Anforderungsrate und wiederholt den Vorgang nach einer Verzögerung. Solange die Zuweisung weiterhin Fortschritte erzielt, wiederholt Storage Actions die Versuche über die gesamte Laufzeit des Workflows hinweg. Wenn die Zuweisung vier Stunden lang beim Auflisten oder Verarbeiten von Blobs keine Fortschritte macht, beendet Storage Actions die Ausführung, sodass eine andere Zuweisung ausgeführt werden kann.

Azure Storage Actions verarbeitet für jedes Zielspeicherkonto jeweils nur eine Zuweisung gleichzeitig. Der Dienst reguliert die Aufgabenausführung selbstständig, sodass Anwendungsworkloads im Zielspeicherkonto Vorrang haben. Die Ausführungsskala hängt von der im Konto verfügbaren Transaktionskapazität ab. Wenn weniger Transaktionskapazität verfügbar ist, kann eine Aufgabenausführung möglicherweise gedrosselt werden und länger dauern, um abgeschlossen zu werden. Weitere Informationen finden Sie unter Skalierung in Abhängigkeit von der für das Speicherkonto verfügbaren Transaktionskapazität.

Nicht alle Aufgabenausführungsfehler sind vorübergehend. Eine Aufgabe kann z. B. fehlschlagen, da ihre verwaltete Identität nicht über die erforderlichen Berechtigungen verfügt, die Anzahl der Anforderungen einen Skalierungsgrenzwert überschreitet oder das Zielspeicherkonto den Netzwerkzugriff blockiert. Sie sind für die Überwachung von Aufgabenstatus, Metriken und Dashboards sowie für die Behebung dieser Fehler verantwortlich. Ein Ausführungsbericht wird nur für einen Durchlauf erstellt, der den Status Completed erreicht. Fehlgeschlagene und übersprungene Ausführungen erzeugen keinen Ausführungsbericht. Vergleichen Sie die tatsächlichen Ausführungszeiten mit dem Zeitplan der Zuweisung, um Durchläufe zu ermitteln, die nicht stattgefunden haben. Informationen zum Identifizieren und Beheben von Aufgabenfehlern finden Sie unter "Problembehandlung bei Speicheraufgaben".

Resilienz bei Konfigurationsproblemen

Bedingungen für Speicheraufgaben bestimmen, auf welche Objekte eine Aufgabe angewendet wird, und eine falsche Bedingung oder ein fehlerhafter Vorgang kann sich auf unbeabsichtigte Objekte auswirken. Microsoft führt jede Zuweisung entsprechend ihrer Konfiguration aus. Sie sind dafür verantwortlich, die Zuweisung zu überprüfen, bevor Sie zulassen, dass sie Daten ändert, insbesondere wenn sie destruktive oder nicht umkehrbare Vorgänge umfasst.

Verwenden Sie die folgenden Überprüfungsmethoden:

  • Bedingungsvorschau: Während Sie Aufgabenbedingungen verfassen, verwenden Sie das Vorschaufeature im Azure-Portal oder die REST-API für Vorschauaktionen, um ein Beispiel von bis zu 5.000 Blobs auszuwerten. Eine Vorschau gibt sofortige Ergebnisse zurück und generiert keinen Ausführungsbericht.

  • Simulierte Ausführung: Bevor Sie die Zuweisung zum Ausführen von Vorgängen aktivieren, erstellen Sie einen Mock-Run für die endgültige Überprüfung. Bei einer Pseudoausführung werden alle Blobs im Zuordnungsbereich ausgewertet, ohne die konfigurierten Vorgänge auszuführen. Sie wird asynchron wie eine normale Zuweisung ausgeführt und erzeugt einen CSV-Ausführungsbericht. Überprüfen Sie den Bericht, um zu überprüfen, welche Blobs den Bedingungen entsprechen und welche Vorgänge die Aufgabe ausführen würde.

Die Überprüfung verringert zwar das Risiko unbeabsichtigter Vorgänge, ersetzt jedoch nicht den Schutz von Daten. Bevor Sie Speicheraufgaben zum Löschen von Blobs verwenden, aktivieren Sie vorläufiges Löschen für Blobs für jedes Zielspeicherkonto. Durch das vorläufige Löschen können Sie gelöschte Blobs während der konfigurierten Aufbewahrungsdauer wiederherstellen.

Überprüfen Sie Speicheraufgabenzuweisungen zusammen mit anderen Datenverwaltungsrichtlinien, die auf dieselben Blobs angewendet werden. Konfigurieren Sie keine sich überschneidenden Aufgaben oder Richtlinien, die widersprüchliche Vorgänge ausführen. Ein Löschvorgang für Speicheraufgaben kann z. B. fehlschlagen, wenn eine Blob Storage Lifecycle-Verwaltungsrichtlinie versucht, dasselbe Blob zu löschen.

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.

Die Steuerungsebene von Azure Storage Actions ist zonenredundant. Microsoft verwaltet die Verteilung automatisch über mehrere Verfügbarkeitszonen hinweg, und Sie wählen die Zonen nicht aus. Während eines Ausfalls der Verfügbarkeitszone können Sie Speicheraufgaben und Zuordnungen weiterhin verwalten.

Die Resilienz der Aufgabenausführung hängt von der Redundanzkonfiguration jedes Zielspeicherkontos ab, da die Aufgaben mit den Daten in diesen Konten arbeiten. Wenn die Ausführung der Aufgabe während eines Zonenfehlers fortgesetzt werden muss, konfigurieren Sie jedes Zielkonto mit einer zonenredundanten Speicheroption (ZRS, GZRS oder RA-GZRS).

Das folgende Beispiel zeigt die Storage Actions-Steuerungsebene und eine Aufgabe, die auf ein zonenredundantes Konto in einer Drei-Zonen-Region ausgerichtet ist. Sowohl die Steuerebene als auch das Zielkonto können weiterhin funktionieren, wenn eine Zone nicht verfügbar ist:

Diagramm, das die Speicheraktionen-Steuerungsebene und ein ZRS-Zielspeicherkonto zeigt, das drei Verfügbarkeitszonen umfasst.

Im Gegensatz dazu ist ein LRS-Zielkonto nicht zonenredundant. Im folgenden Beispiel erstreckt sich die Steuerebene über alle drei Zonen, und das Zielkonto wird in der Verfügbarkeitszone 1 angezeigt, um ein Konto zu veranschaulichen, das keine Zonen umfasst. Wenn die Zone, in der das Zielkonto gehostet wird, ausfällt, bleibt die Steuerungsebene zwar verfügbar, die Aufgabe kann jedoch erst wieder für das Zielkonto ausgeführt werden, wenn das Konto wiederhergestellt ist:

Diagramm, das die Steuerungsebene für Speicheraktionen zeigt, die sich über drei Verfügbarkeitszonen erstreckt, sowie ein LRS-Zielkonto, das in Zone 1 angezeigt wird.

Requirements

  • Regionsunterstützung: Wenn Sie eine Speicheraufgabenzuweisung konfigurieren, muss sich die Speicheraufgabe und das Zielspeicherkonto in derselben Region befinden. Wählen Sie einen Bereich aus, der Azure Storage Actions sowie Verfügbarkeitszonen unterstützt, um die Aufgabenausführung ausfallsicher zu machen.

  • Konfiguration des Speicherkontos: Konfigurieren Sie jedes Zielkonto mit einer zonenredundanten Speicheroption. Lokal redundanter Speicher (LRS), georedundanter Speicher (GRS) und georedundanter Speicher mit Lesezugriff (RA-GRS) bieten keine Zonenredundanz in der primären Region.

Considerations

Die Zonenredundanz der Steuerungsebene macht die Aufgabenausführung nicht zonenresilient, wenn ein Zielspeicherkonto nicht verfügbar ist. Bewerten Sie die Redundanzkonfiguration jedes Zielkontos separat.

Cost

Die Zonenredundanz für die Steuerungsebene von Storage Actions erfolgt automatisch, und für die Aktivierung fallen keine zusätzlichen Storage Actions-Gebühren an. Standardnutzungsgebühren für Aufgabenausführungen, gezielte Objekte und aufgerufene Vorgänge gelten weiterhin. Weitere Informationen finden Sie unter Azure Storage Actions-Preise.

Die Redundanzoption, die Sie für jedes Zielspeicherkonto auswählen, wirkt sich auf Ihre Azure Storage Gebühren aus. Weitere Informationen finden Sie unter Blob Storage-Preise.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

Zonenredundanz ist für die Storage Actions-Steuerungsebene automatisch. Sie konfigurieren zonenredundanz nicht separat für Speicheraufgaben oder Zuordnungen.

Um die Ausführung von Aufgaben gegen Ausfälle von Verfügbarkeitszonen ausfallsicher zu machen, wählen Sie beim Erstellen jedes Zielspeicherkontos eine zonenredundante Speicheroption aus oder ändern Sie die Redundanzkonfiguration eines vorhandenen Kontos.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Sie erwarten können, wenn die Kontrollebene von Storage Actions verfügbar ist, Zielspeicherkonten eine zonenredundante Speicheroption verwenden und alle Verfügbarkeitszonen betriebsbereit sind.

  • Zonenübergreifender Betrieb: Microsoft verteilt die Infrastruktur der Storage Actions-Steuerungsebene über Verfügbarkeitszonen hinweg. Aufgabendurchläufe werden für jedes Zielspeicherkonto ausgeführt, und Azure Storage verteilt Anforderungen transparent über die Infrastruktur, in der das Konto gehostet wird.

  • Zonenübergreifende Datenreplikation: Storage Actions speichert oder repliziert die von Aufgaben verarbeiteten Blobdaten nicht.

    Azure Storage repliziert synchron Daten in Konten, die eine zonenredundante Speicheroption über Verfügbarkeitszonen in der primären Region verwenden. Azure Storage schließt einen Schreibvorgang erst dann ab, wenn die Daten über die vom Konto verwendeten Zonen repliziert wurden.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, womit Sie rechnen können, wenn die Storage Actions-Kontrollebene verfügbar ist, Zielspeicherkonten eine zonenredundante Speicheroption verwenden und es in einer Verfügbarkeitszone einen Ausfall gibt.

  • Erkennung und Reaktion: Microsoft erkennt und reagiert auf Fehler, die sich auf die Steuerungsebene von Storage Actions auswirken.

    Bei Zielkonten, die eine zonenredundante Speicheroption verwenden, leitet Azure Storage Aufgabenausführungs- und Speichervorgänge automatisch an fehlerfreie Zonen weiter. Sie müssen kein Failover initiieren.

  • Notification: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone abfällt. Sie können jedoch Azure Service Health verwenden, um den Gesamtstatus des Diensts zu verstehen, einschließlich aller Zonenfehler, und Sie können Service Health Alerts einrichten, um Sie über Probleme zu informieren.

  • Aktive Anfragen: Speicheraufgaben, die auf verfügbare zonenredundante Konten abzielen, machen weiterhin Fortschritte. Aufgaben, die auf ein nicht verfügbares Konto abzielen, können fehlschlagen.

    Ausstehende einmalige Zuweisungen werden möglicherweise noch verarbeitet. Bei Ausführungen, die unterbrochen oder fehlgeschlagen wurden, müssen Sie diese möglicherweise manuell neu planen, je nachdem, wo die Verarbeitung beendet wurde.

  • Erwarteter Datenverlust: Storage Actions speichern keine separate Kopie Ihrer BLOB-Daten. Die Erwartungen an Datenverlust hängen von der Redundanzkonfiguration jedes Zielkontos ab. Wenn ein Konto eine zonenredundante Speicheroption verwendet, repliziert Azure Storage seine Daten synchron über Verfügbarkeitszonen in der primären Region hinweg, sodass bei einem Zonenausfall kein Datenverlust für erfolgreich abgeschlossene Schreibvorgänge zu erwarten ist.

  • Erwartete Ausfallzeit: Die Storage Actions-Steuerungsebene bleibt während eines Zonenfehlers verfügbar.

    Die Ausführung der Aufgabe wird fortgesetzt, solange auf das Zielspeicherkonto zugegriffen werden kann. Wenn das Konto nicht mehr verfügbar ist, wie etwa ein LRS-Speicherkonto in einer betroffenen Zone, schlagen betroffene Durchläufe möglicherweise fehl.

  • Umverteilung: Microsoft verwaltet die Reaktion und Umverteilung der Steuerungsebene von Storage Actions.

    Azure Storage leitet Vorgänge automatisch für Konten weiter, die eine zonenredundante Speicheroption verwenden, an fehlerfreie Zonen. Es ist keine Kundenaktion erforderlich.

Zonenwiederherstellung

Wenn die ausgefallene Zone wiederhergestellt wird, stellt Microsoft die normale Control-Plane-Verteilung wieder her. Azure Storage stellt den normalen Vorgang für zonenredundante Konten wieder her. Geplante Aufgabenzuweisungen werden gemäß ihren Zeitplänen fortgesetzt.

Wiederkehrende Zuweisungen werden gemäß ihren konfigurierten Zeitplänen wieder aufgenommen. Ausstehende einmalige Zuweisungen werden möglicherweise noch verarbeitet. Überprüfen Sie den Status der vom Ausfall betroffenen Durchläufe. Je nachdem, wo die Verarbeitung beendet wurde, müssen Sie möglicherweise unterbrochene oder fehlgeschlagene Ausführungen neu planen.

Test auf Zonenfehler

Microsoft verwaltet Zonenverteilung, Failover und Wiederherstellung für die Storage Actions-Steuerungsebene und für zonenredundante Speicherkonten. Sie müssen keine Plattformzonenfehler testen. Testen Sie Ihre Betrieblichen Verfahren, indem Sie überprüfen, ob Sie fehlgeschlagene Aufgabenvorgänge identifizieren und sie sicher erneut ausführen können.

Widerstandsfähigkeit bei regionalen Ausfällen

Die Ausfallsicherheit der Ausführung von Speicheraufgaben während eines regionsweiten Ausfalls hängt von der Redundanzkonfiguration jedes Zielspeicherkontos ab. Wenn ein Zielkonto eine georedundante Speicheroption verwendet (GRS, GZRS, RA-GRS und RA-GZRS), kann das Speicherkonto ein Failover in die gekoppelte Region durchführen, und zukünftige Ausführungen der Speicheraufgabe können in der neuen primären Region fortgesetzt werden.

Georedundante Zielspeicherkonten

Bei einem georedundanten Speicherkonto ist die Region, die derzeit Schreibvorgänge akzeptiert, die primäre Region. Azure Storage repliziert Daten asynchron in die gekoppelte Region des Kontos, die die sekundäre Region ist.

Speicheraufgaben werden für das Konto in der primären Region ausgeführt. Nach dem Failover des Kontos wird die vorherige sekundäre Region zur neuen primären Region, und zukünftige Ausführungen von Speicheraufgaben werden dort automatisch ausgeführt. Für Azure Storage Actions ist keine separate Failoveraktion erforderlich.

Requirements

Cost

Georedundante Speicherkonfigurationen verursachen Gebühren für Replikation und Speicher in der sekundären Region. Weitere Informationen finden Sie unter Blob Storage-Preise.

Konfigurieren der Multiregion-Unterstützung

Wählen Sie beim Erstellen des Zielspeicherkontos eine georedundante Speicheroption aus, oder ändern Sie die Redundanzkonfiguration eines vorhandenen Kontos.

Wenn Sie eine Speicheraufgabenzuweisung erstellen, während das Zielkonto eine nicht-georedundante Option verwendet und das Konto später in GRS, GZRS, RA-GRS oder RA-GZRS konvertiert wird, aktualisieren Sie die Zuordnung, bevor Sie das Failover eines vom Kunden verwalteten Kontos initiieren. Sie können jede Zuweisungseigenschaft ändern. Das Update bewirkt, dass die Steuerungsebene von Storage Actions die neue georedundante Konfiguration des Kontos erkennt.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten können, wenn ein Zielspeicherkonto eine georedundante Speicheroption verwendet und sowohl die primären als auch die sekundären Regionen betriebsbereit sind.

  • Standortübergreifender Betrieb: Während des normalen Vorgangs befinden sich die Speicheraufgabendefinition, die Zuordnung und das Zielspeicherkonto in der primären Region. Die sekundäre Region verarbeitet keine Speicheraufgabenvorgänge.

  • Regionsübergreifende Datenreplikation: Azure Storage Actions repliziert die von Aufgaben verarbeiteten Blobdaten nicht eigenständig.

    Azure Storage repliziert asynchron Daten aus der primären Region in die sekundäre Region. Da die Replikation asynchron ist, sind die letzten Änderungen in der sekundären Region möglicherweise noch nicht vorhanden.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, womit zu rechnen ist, wenn die primäre Region eines Zielspeicherkontos, das eine georedundante Speicheroption verwendet, nicht verfügbar ist.

  • Erkennung und Reaktion: Speicherkontofailover kann vom Kunden verwaltet oder Microsoft verwaltet werden. Microsoft verwaltetes Failover ist für außergewöhnliche Umstände reserviert und kann nur nach einem erweiterten Ausfall auftreten. Verlassen Sie sich daher nicht auf das Failover für Ihren Notfallwiederherstellungsplan. Befolgen Sie die Blob Storage Failoveranleitung, um zu entscheiden, ob und wann ein vom Kunden verwaltetes Failover initiiert werden soll.

    Für Azure Storage Actions ist keine separate Failoveraktion erforderlich. Wenn Sie die Zuordnung jedoch erstellt haben, während das Zielkonto LRS verwendet und das Konto später in GRS oder GZRS konvertiert wurde, aktualisieren Sie die Zuweisung, bevor Sie das Failover des vom Kunden verwalteten Kontos initiieren. Weitere Informationen finden Sie unter Konfigurieren der Multiregion-Unterstützung.

  • Notification: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Sie können jedoch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich aller Regionsfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

  • Aktive Anforderungen: Während eines Speicherkontofailovers sind die primären und sekundären Speicherkontoendpunkte vorübergehend nicht verfügbar. Laufende Ausführungen von Speicheraufgaben können fehlschlagen. Überprüfen Sie nach dem Failover den Status der betroffenen Aufgabenausführungen, und führen Sie fehlerhafte oder unvollständige Vorgänge nach Bedarf erneut aus.

    Wenn bei einer wiederkehrenden Zuweisung die vorherige Iteration beim Planen der nächsten Iteration noch in Bearbeitung ist, überspringt Storage Actions die neue Iteration. Die nächste Iteration wird nach Abschluss der vorherigen Iteration an der festgelegten Auslösezeit ausgeführt.

  • Erwarteter Datenverlust: Azure Storage Actions verwaltet keine separate Kopie Ihrer Blobdaten.

    Während eines ungeplanten Failovers können aktuelle Änderungen verloren gehen, wenn sie nicht in die sekundäre Region repliziert wurden. Eine Aufgabe, die fehlschlägt, während sie ausgeführt wird, kann auch Vorgänge nur für einige ihrer Zielobjekte abgeschlossen haben. Überprüfen Sie nach dem Failover den Status betroffener Aufgabenausführungen und führen Sie fehlerhafte oder unvollständige Vorgänge nach Bedarf erneut aus. Ausführliche Informationen zu Speicherkontowiederherstellungspunkten und Datenverlust finden Sie unter Erwarteter Datenverlust während des Ausfalls einer Blob Storage-Region.

  • Erwartete Ausfallzeiten: Vor dem Failover können Speicheraufgaben keinen Fortschritt vornehmen, während das Zielspeicherkonto nicht verfügbar ist.

    Während des Failovers bleiben die Endpunkte des Speicherkontos nicht verfügbar, sodass die Ausführungen der Aufgabe keinen Fortschritt erzielen können und fehlschlagen können.

    Nach Abschluss des Failovers verarbeiten die Datenebenenkomponenten von Storage Actions in der neuen primären Region des Speicherkontos zukünftige Durchläufe von Aufgabenzuweisungen. Die Speicheraufgabenressource verbleibt in ihrer ursprünglichen Region, sodass die Berichterstellung für die Aufgabendefinition weiterhin beeinträchtigt sein kann, solange diese Region nicht verfügbar ist. Die Berichterstellung für andere Abschnitte der Ressource funktioniert weiterhin.

    Die Gesamtunterbrechung umfasst die Zeit zum Erkennen des Ausfalls, zur Entscheidung, ob ein Failover initiiert werden soll, und zum Abschließen des Speicherkonto-Failovers.

    Wenn kein Failover auftritt, bleibt die Aufgabenausführung bis zur Wiederherstellung der ursprünglichen primären Region nicht verfügbar.

    Verwaltungsvorgänge bleiben während eines Regionsfehlers verfügbar.

  • Umverteilung: Azure Storage aktualisiert die Speicherkontoendpunkte, sobald das Failover abgeschlossen ist. Zukünftige Durchläufe von Aufgabenzuweisungen werden automatisch für das Konto in der neuen primären Region ausgeführt. Sie müssen die Speicheraufgabe oder die Zuweisung nicht neu konfigurieren.

Regionswiederherstellung

Der Failbackprozess hängt vom Failovertyp des Speicherkontos ab. Befolgen Sie die Anleitung zur Wiederherstellung der Blob Storage-Region, um ein Failback für das Zielspeicherkonto durchzuführen. Azure Storage Actions erfordert keine zusätzliche Konfiguration nach einem Speicherkonto-Failback.

Test auf Regionsfehler

Um Ihren Wiederherstellungsvorgang ohne den Datenverlust zu testen, der einem ungeplanten Failover zugeordnet ist, erstellen Sie repräsentative Speicheraufgabenzuweisungen für ein Nichtproduktionsspeicherkonto, das eine georedundante Speicheroption verwendet, und initiieren Sie dann ein vom Kunden verwaltetes geplantes Failover. Überprüfen Sie alle laufenden Durchläufe, und stellen Sie sicher, dass ein zukünftiger geplanter Durchlauf für das Konto in der neuen primären Region ausgeführt wird. Anleitungen für Failovertests finden Sie unter Testen von Regionsfehlern in Azure Blob Storage.

Benutzerdefinierte Multiregion-Lösungen für Resilienz

Integrierte Failoverunterstützung für Azure Storage Aktionen ist nur verfügbar, wenn sich das Zielspeicherkonto in einer gekoppelten Region befindet und eine georedundante Speicheroption verwendet.

Wenn Ihre Multiregion-Speicherlösung unabhängige Speicherkonten in jeder Region anstelle des Speicherkontofailovers verwendet, können Sie eine Speicheraufgabe in derselben Region wie jedes Zielkonto bereitstellen und eine Zuweisung für jedes Konto erstellen. Sie sind dafür verantwortlich, Daten zwischen den Konten zu replizieren, Aufgabendefinitionen und Zuweisungen zu synchronisieren und zu steuern, welche Zuweisungen während des normalen Betriebs und Failovers ausgeführt werden. Stellen Sie sicher, dass Zuweisungen in verschiedenen Regionen keine widersprüchlichen Vorgänge für replizierte Daten ausführen.

Sichern und Wiederherstellen

Um die Konfiguration Ihrer Azure Storage Actions nach dem versehentlichen Löschen wiederherzustellen, definieren Sie Ihre Speicheraufgaben und Zuweisungen als Infrastruktur als Code (IaC), und speichern Sie die Definitionen in der Quellcodeverwaltung. Berücksichtigen Sie dabei Aufgabenbedingungen und -vorgänge, Zeitpläne, Bereiche der Zielspeicherkonten, Einstellungen für Berichtscontainer, verwaltete Identitäten sowie erforderliche Rollenzuweisungen. Sie können eine Speicheraufgabe mithilfe von Bicep bereitstellen und Speicheraufgabenzuweisungen in Bicep definieren.

Speicheraufgaben und Zuweisungen bestehen aus Konfigurationsdaten und enthalten nicht die Kundendaten, die von den Aufgaben verarbeitet werden. Verwenden Sie den zuvor beschriebenen IaC-Ansatz, um diese Konfiguration wiederherzustellen. Sie sind dafür verantwortlich, die Daten in Ihren Zielspeicherkonten separat zu schützen und wiederherzustellen. Informationen zu den Optionen für den Schutz von Daten in Azure Storage finden Sie unter Übersicht über den Schutz von Daten.

Testen Sie Das Wiederherstellungsverfahren in einer Nichtproduktionsumgebung. Bevor Sie neu erstellte Zuweisungen aktivieren, verwenden Sie bedingungsvorschauen und simulierte Ausführungen, um zu überprüfen, ob die Aufgabe die beabsichtigten Blobs anspricht. Weitere Informationen finden Sie unter Bewährte Methoden für die Verwendung von Speicheraufgaben.

Resilienz gegenüber Wartungsarbeiten an Diensten

Microsoft wendet regelmäßig Dienstupdates an und führt andere Wartungen durch. Die Azure Plattform übernimmt diese Aktivitäten automatisch, um sicherzustellen, dass die Wartung nahtlos und transparent für Sie ist. Bei Wartungsereignissen wird keine Ausfallzeit erwartet, es sei denn, Sie wurden über die geplante Wartung in Azure Service Health informiert.

Service-Level-Vereinbarung

Azure Storage Actions bietet kein Verfügbarkeits-SLA an.

Verwandte Inhalte

  • Zuletzt aktualisiert um