Notfallwiederherstellung und Verteilung über geografische Standorte in Durable Functions

Microsoft ist bestrebt, sicherzustellen, dass Azure Dienste immer verfügbar sind. Ungeplante Dienstausfälle können jedoch auftreten. Wenn Ihre Anwendung Resilienz erfordert, sollten Sie Ihre App für Georedundanz konfigurieren.

Sie sollten auch über einen Notfallwiederherstellungsplan für die Behandlung eines regionalen Dienstausfalls verfügen. Ein wichtiger Teil eines Notfallwiederherstellungsplans besteht darin, vorbereitet zu sein, bei Ausfall der primären Replikate auf die sekundären Replikate Ihrer App und Ihres Speicherkontos umzuschalten.

In diesem Artikel werden Beispielszenarien für die Konfiguration von Notfallwiederherstellung und Geo-Distribution mithilfe der Funktion Durable Functions von Azure Functions beschrieben.

Beschreibung des Szenarios

In diesem Artikel werden drei Konfigurationen für die aktive/passive Notfallwiederherstellung behandelt. Wählen Sie das Szenario aus, das Ihrer Fehlertoleranz und den Kostenanforderungen entspricht:

Scenario Schützt vor Datenverlust beim Failover Regionsübergreifende Latenz Relative Kosten
Szenario 1: Freigegebener Speicher Computerausfall Nichts Ja (Speicher in primärer Region) Niedrig
Szenario 2: Regionaler Speicher Rechner- und Speicher-/Planerausfall In-Flight-Orchestrierungen wurden angehalten, bis die primäre Wiederherstellung ausgeführt wird. Nichts Medium
Szenario 3: Gemeinsam genutzter GRS-Speicher Rechenleistungsausfall und Speicherausfall (mit Replikation) Möglicher Verlust der letzten Transaktionen (asynchrone Replikationsverzögerung) Ja (bis zum Abschluss des DNS-Failovers) Hoch

Note

Wenn Sie den Durable Task Scheduler anstelle des standardanbieters Azure Storage verwenden, ist Szenario 2 der empfohlene Notfallwiederherstellungsansatz.

Hintergrund

In Durable Functions wird der gesamte Zustand in einem Speicher-Back-End beibehalten. Standardmäßig ist dieses Back-End Azure Storage, Sie können aber auch den Durable Task Scheduler oder eine datenbank SQL Server verwenden. Ein Aufgabenhub ist ein logischer Container für die Speicherressourcen, die für Orchestrierungen und Entitäten verwendet werden. Orchestrator-, Aktivitäts- und Entitätsfunktionen können nur miteinander interagieren, wenn sie zum gleichen Aufgabenhub gehören. Bei der Beschreibung von Szenarien, in denen diese Speicherressourcen hochverfügbar bleiben, bezieht sich dieser Artikel auf Aufgabenhubs.

Orchestrierungen und Entitäten können über clientfunktionen ausgelöst werden, die selbst über HTTP oder einen der anderen unterstützten Azure Functions Triggertypen ausgelöst werden. Orchestrierungen und Entitäten können auch über integrierte HTTP-APIs ausgelöst werden. Der Einfachheit halber konzentriert sich dieser Artikel auf Szenarien mit Azure Storage und HTTP-basierten Funktionstriggern sowie Optionen zum Erhöhen der Verfügbarkeit und Minimierung von Ausfallzeiten während der Notfallwiederherstellung. In diesem Artikel werden nicht explizit andere Triggertypen behandelt, z. B. Azure Service Bus oder Azure Cosmos DB Trigger.

Die Szenarien in diesem Artikel basieren auf aktiven/passiven Konfigurationen, die die Verwendung von Azure Storage am besten unterstützen. Dieses Muster besteht darin, eine Sicherungs-Funktionsanwendung (passiv) in einer anderen Region bereitzustellen. Azure Traffic Manager überwacht die primäre (aktive) Function App auf die HTTP-Verfügbarkeit. Wenn die primäre App fehlschlägt, wird auf die Sicherungsfunktions-App umgeschaltet. Weitere Informationen finden Sie unter Prioritätsverkehrsrouting-Methode.

Allgemeine Hinweise

Beachten Sie diese Überlegungen beim Konfigurieren einer aktiven/passiven Failoverkonfiguration für Durable Functions:

  • In diesem Artikel wird davon ausgegangen, dass Sie den Standardanbieter Azure Storage zum Speichern des Durable Functions Laufzeitzustands verwenden. Sie können auch alternative Speicheranbieter konfigurieren, die den Zustand an anderer Stelle speichern, z. B. in einer SQL Server-Datenbank. Alternative Speicheranbieter erfordern möglicherweise unterschiedliche Notfallwiederherstellungsstrategien und Geoverteilungsstrategien. Weitere Informationen finden Sie unter Durable Functions Speicheranbieter.
  • Die vorgeschlagene aktive/passive Konfiguration stellt sicher, dass ein Client immer neue Orchestrierungen über HTTP auslösen kann. Wenn zwei Funktions-Apps jedoch denselben Aufgabenhub im Speicher gemeinsam nutzen, können einige Hintergrundspeichertransaktionen zwischen den Apps verteilt werden. Aufgrund dieser Verteilung kann diese Konfiguration zu zusätzlichen Kosten für ausgehenden Datenverkehr für die sekundäre Funktions-App führen.
  • Das zugrunde liegende Speicherkonto und der Aufgabenhub werden beide in der primären Region erstellt. Die Funktions-Apps teilen dieses Speicherkonto und den Aufgabenhub.
  • Alle Funktions-Apps, die redundant bereitgestellt werden, müssen dieselben Funktionszugriffsschlüssel gemeinsam nutzen, wenn sie über HTTP aktiviert werden. Die Azure Functions Laufzeit macht eine Management-API verfügbar, die Sie zum programmgesteuerten Hinzufügen, Löschen und Aktualisieren von Funktionsschlüsseln verwenden können. Sie können Schlüssel auch mithilfe von Azure Resource Manager-APIs verwalten.

Szenario 1: Lastenausgleichs-Compute mit gemeinsam genutztem Speicher

Um die Möglichkeit von Ausfallzeiten zu verringern, wenn Ihre Funktions-App-Ressourcen nicht verfügbar sind, verwendet dieses Szenario zwei Funktions-Apps, die in verschiedenen Regionen bereitgestellt werden. Wir empfehlen dieses Szenario als Lösung für Failovers.

Der Datenverkehrs-Manager ist so konfiguriert, dass Probleme in der primären Funktions-App erkannt und der Datenverkehr automatisch an die Funktions-App in der sekundären Region umgeleitet wird. Diese Funktions-App verwendet dasselbe Azure Storage Konto und Aufgabenhub. Der Status der Funktions-Apps geht nicht verloren, und die Arbeit kann normal fortgesetzt werden. Nachdem die Integrität in der primären Region wiederhergestellt wurde, startet Azure Traffic Manager das Routing von Anforderungen an diese Funktions-App automatisch.

Diagramm, das Funktionsapps in separaten Regionen mit einem geteilten Azure Storage-Konto zeigt.

Es gibt mehrere Vorteile für die Verwendung dieses Bereitstellungsszenarios:

  • Wenn die Computeinfrastruktur fehlschlägt, kann die Arbeit in der Failoverregion ohne Datenverlust fortgesetzt werden.
  • Der Traffic Manager übernimmt automatisch das Failover zur fehlerfreien Funktions-App.
  • Der Traffic Manager stellt automatisch den Datenverkehr zur Hauptfunktions-App wieder her, nach Beendigung des Ausfalls.

Szenariospezifische Überlegungen

  • Wenn Sie die Funktions-App mit einem dedizierten Azure App Service-Plan bereitstellen, treibt die Replikation der Computeinfrastruktur im Rechenzentrum, für das das Failover durchgeführt wird, die Kosten in die Höhe.

  • Dieses Szenario deckt Ausfälle in der Computeinfrastruktur ab, aber das Speicherkonto ist weiterhin der einzige Fehlerpunkt für die Funktions-App. Wenn ein Azure Storage Ausfall auftritt, leidet die Anwendung an Ausfallzeiten.

  • Wenn die Funktions-App fehlgeschlagen ist, erhöht sich die Latenz, da die App regionenübergreifend auf das Speicherkonto zugreift.

  • Wenn sich die Funktions-App im Failover befindet, greift sie auf den Speicherdienst in der ursprünglichen Region zu. Der Netzwerkausgangsverkehr kann zu höheren Kosten führen.

  • Dieses Szenario ist abhängig vom Traffic Manager. Eine Clientanwendung kann einige Zeit in Anspruch nehmen, bevor sie die Funktions-App-Adresse von Traffic Manager erneut anfordern muss. Weitere Informationen finden Sie unter "Funktionsweise von Traffic Manager".

  • Ab Version 2.3.0 der Durable Functions-Erweiterung können Sie zwei Funktions-Apps gleichzeitig mit demselben Speicherkonto und derselben Task Hub-Konfiguration ausführen. Die erste App, die gestartet wird, erhält eine Blob-Lease auf Anwendungsebene, die verhindert, dass andere Apps Nachrichten aus den Task-Hub-Warteschlangen verarbeiten. Wenn diese erste App nicht mehr ausgeführt wird, läuft der Lease ab. Eine zweite App kann den Lease übernehmen und damit beginnen, Aufgabenhub-Nachrichten zu verarbeiten.

    Bei Erweiterungsversionen vor 2.3.0 verarbeiten Funktions-Apps, die so konfiguriert sind, dass sie dasselbe Speicherkonto nutzen, Nachrichten und aktualisieren Speicherartefakte gleichzeitig. Diese gleichzeitige Aktivität führt zu höheren Gesamtlatenz- und Ausgangskosten. Wenn für die primäre und die Replikat-App ein anderer Code bereitgestellt wird, auch temporär, könnten Orchestrierungen möglicherweise ebenfalls nicht ordnungsgemäß ausgeführt werden, da in beiden Apps Inkonsistenzen der Orchestratorfunktion auftreten.

    Alle Apps, die die Geoverteilung für die Notfallwiederherstellung erfordern, sollten Version 2.3.0 oder höher der Durable Functions-Erweiterung verwenden.

Szenario 2: Lastenausgleichsberechnung mit regionalem Speicher

Im vorherigen Szenario werden nur Fehler behandelt, die auf die Computeinfrastruktur beschränkt sind. Ein Ausfall der Funktions-App kann auch auftreten, wenn entweder der Speicherdienst oder der Durable Task Scheduler fehlschlägt.

Um einen kontinuierlichen Betrieb von Durable Functions sicherzustellen, stellt das zweite Szenario ein dediziertes Speicherkonto oder einen dauerhaften Taskplaner in jeder Region bereit, in der Funktions-Apps gehostet werden. Wir empfehlen derzeit diesen Notfallwiederherstellungsansatz, wenn Sie den Durable Task Scheduler verwenden.

Diagramm, das Function-Apps in separaten Regionen mit separaten Azure-Speicherkonten zeigt.

Mit diesem Ansatz werden dem vorherigen Szenario Verbesserungen hinzugefügt:

  • Regionale Zustandsisolation: Jede Funktions-App ist mit einem eigenen regionalen Speicherkonto oder einem durable Task Scheduler verknüpft. Wenn die Funktions-App fehlschlägt, leitet der Traffic-Manager den Datenverkehr an die sekundäre Region weiter. Da die Funktions-App in jeder Region den lokalen Speicher oder den dauerhaften Aufgabenplaner verwendet, kann Durable Functions die Verarbeitung mithilfe des lokalen Zustands fortsetzen.
  • Keine zusätzliche Latenz beim Failover: Während eines Failovers werden eine Funktions-App und ein Statusanbieter (Speicherkonto oder dauerhafter Taskplaner) verortet, sodass keine zusätzliche Latenz in der Failoverregion vorhanden ist.
  • Resilienz gegenüber Fehlern bei der Systemunterstützung: Wenn das Speicherkonto oder der Durable Task Scheduler in einer Region ausfällt, fällt Durable Functions in dieser Region aus. Der Fehler von Durable Functions löst die Umleitung an den sekundären Bereich aus. Da sowohl der Compute- als auch der App-Zustand pro Region isoliert sind, bleibt Durable Functions in der Failoverregion betriebsbereit.

Szenariospezifische Überlegungen

  • Wenn die Funktions-App mit einem dedizierten App Service-Plan bereitgestellt wird, treibt eine Replikation der Computeinfrastruktur im Rechenzentrum, für das das Failover durchgeführt wird, die Kosten in die Höhe.
  • Für den aktuellen Zustand wird kein Failover durchgeführt. Vorhandene Orchestrierungen und Entitäten werden effektiv unterbrochen und stehen nicht zur Verfügung, bis die primäre Region wiederhergestellt wird. Ob dieser Kompromiss zur Beibehaltung der Latenz und minimierung der Ausgangskosten akzeptabel ist, hängt von den Anforderungen der Anwendung ab.
  • Wenn Sie den Dauerhaften Aufgabenplaner verwenden, sollten Sie private Endpunkte für die Netzwerkisolation zwischen Ihrer Funktions-App und dem regionalen Zeitplan konfigurieren.

Szenario 3: Lastenausgeglichene Rechenleistung mit gemeinsam genutztem geo-redundantem Speicher (GRS)

Dieses Szenario stellt eine Abwandlung des ersten Szenarios dar (Implementierung eines gemeinsam genutzten Speicherkontos). Der Hauptunterschied besteht darin, dass das Speicherkonto mit aktivierter Georeplikation erstellt wird.

Diagramm mit Funktions-Apps in separaten Regionen, die ein Speicherkonto gemeinsam nutzen, mit einem Failover-Prozess zu einem Replikat.

Dieses Szenario bietet dieselben funktionalen Vorteile wie das erste Szenario, ermöglicht aber auch andere Vorteile der Datenwiederherstellung:

  • Georedundanter Speicher (GRS) und Read-Access GRS (RA-GRS) maximieren die Verfügbarkeit Ihres Speicherkontos.
  • Wenn ein regionaler Ausfall des Azure Storage-Diensts vorhanden ist, können Sie manual ein Failover zum sekundären Replikat initiieren. Unter extremen Umständen, in denen eine Region aufgrund einer Katastrophe verloren geht, kann Microsoft ein regionales Failover initiieren. In diesem Fall müssen Sie keine Maßnahmen ergreifen.
  • Wenn ein Failover auftritt, wird der Status der Durable Functions bis zur letzten Replikation des Speicherkontos beibehalten. Die Replikation erfolgt in der Regel alle paar Minuten.

Weitere Informationen finden Sie unter Azure Storage Disaster Recovery Planning and Failover.

Szenariospezifische Überlegungen

  • Ein Failover auf das Replikat kann einige Zeit in Anspruch nehmen. Bis das Failover abgeschlossen ist und Azure Storage DNS-Einträge aktualisiert werden, kann die Funktions-App weiterhin nicht darauf zugreifen.
  • Es gibt höhere Kosten für die Verwendung von georeplizierten Speicherkonten.
  • Die GRS-Replikation kopiert Ihre Daten asynchron. Einige der neuesten Transaktionen können aufgrund der Latenz des Replikationsprozesses verlorengehen.
  • Wie für das erste Szenario beschrieben, empfehlen wir, dass in dieser Strategie bereitgestellte Funktions-Apps Version 2.3.0 oder höher der Durable Functions-Erweiterung verwenden.

Verwandte Inhalte

  • Last updated on