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.

Hintergrund

In dauerhaften Funktionen wird der gesamte Zustand standardmäßig in Azure Storage beibehalten. Ein task hub ist ein logischer Container für Azure Storage Ressourcen, die für orchestrations und entities verwendet werden. Orchestrator-, Aktivitäts- und Entitätsfunktionen können nur miteinander interagieren, wenn sie zum gleichen Aufgabenhub gehören. Dieser Artikel bezieht sich auf Aufgabenhubs, wenn Szenarien beschrieben werden, in denen diese Azure Storage Ressourcen hoch verfügbar bleiben.

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.

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 zuerst startende App ruft eine Bloblease auf Anwendungsebene ab, die verhindert, dass andere Apps Nachrichten aus den Aufgabenhub-Warteschlangen „stehlen“. 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 oder einem regionalen dauerhaften Aufgabenplaner

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 dauerhafte Vorgangsplaner fehlschlägt.

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

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

• Isolation des regionalen Zustands: Jede Funktions-App ist mit einem eigenen regionalen Speicherkonto oder einem dauerhaften Aufgabenplaner 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 Aufgabenplaner) verortet, sodass keine zusätzliche Latenz in der Failoverregion vorhanden ist.
• Resilienz gegen Status-Backing-Fehlschläge: Wenn das Speicherkonto oder der langlebige Aufgabenplaner in einer Region fehlschlägt, schlägt Durable Functions in dieser Region fehl. 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.

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.

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.

Nächster Schritt