Teilen über

Zuverlässigkeit in Azure Functions

In diesem Artikel wird die Zuverlässigkeitsunterstützung in Azure Functions beschrieben, wobei sowohl regionsinterne Resilienz mittels Verfügbarkeitszonen als auch regionsübergreifende Wiederherstellung und Geschäftskontinuität behandelt werden. Eine ausführlichere Übersicht über die Zuverlässigkeitsprinzipien in Azure finden Sie unter Azure-Zuverlässigkeit.

Die Verfügbarkeitszonenunterstützung für Azure Functions hängt von Ihrem Hostingplan für Funktionen ab:

Hostingplan Unterstützungsstufe Weitere Informationen...
Flex-Verbrauchstarif Vorschau Wählen Sie "Flex-Verbrauch" oben in diesem Artikel aus.
Elastic Premium-Plan Allgemein verfügbar Wählen Sie oben in diesem Artikel "Premium" aus.
Dedizierter (App Service-) Plan Allgemein verfügbar Siehe Zuverlässigkeit in Azure App Service.
Verbrauchstarif n/a Wird vom Verbrauchsplan nicht unterstützt.

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb jeder Azure-Region. Wenn eine Zone ausfällt, kann für die Dienste ein Failover zu einer der verbleibenden Zonen erfolgen.

Azure Functions unterstützt eine zonenredundante Bereitstellung.

Unterstützung von Verfügbarkeitszonen

Wichtig

Die Unterstützung für Verfügbarkeitszonen beim Hosten Ihrer App in einem Flex-Verbrauchsplan befindet sich derzeit in der Vorschauphase.

Wenn Sie Flex-Verbrauchsplan-Apps als zonenredundant konfigurieren, verteilt die Plattform automatisch Instanzen Ihrer Funktions-App über die Zonen in der ausgewählten Region mit unterschiedlichen Regeln für immer einsatzbereite und on-Demand-Instanzen.

Wenn Zonenredundanz in einem Flex-Verbrauchsplan aktiviert ist, wird die Instanzenverteilung innerhalb der folgenden Regeln bestimmt:

  • Immer einsatzbereite Instanzen werden in einer Roundrobin-Art über mindestens zwei Zonen verteilt.
  • Bedarfsgesteuerte Instanzen, die infolge von Ereignisquellvolumes erstellt werden, wenn die App über jederzeit verfügbare Instanzen hinaus skaliert wird, werden nach dem Prinzip der bestmöglichen Leistung über Verfügbarkeitszonen verteilt. Dies bedeutet, dass für On-Demand-Instanzen eine schnellere Skalierung gegenüber der gleichmäßigen Verteilung über Verfügbarkeitszonen bevorzugt wird. Die Plattform versucht, die Verteilung im Laufe der Zeit gleichmäßig zu verteilen.
  • Um die Zonenresilienz mit Verfügbarkeitszonen sicherzustellen, verwaltet die Plattform automatisch mindestens zwei immer einsatzbereite Instanzen für jede Skalierungsfunktion oder Gruppe, unabhängig von der immer einsatzbereiten Konfiguration für die App. Alle Instanzen, die von der Plattform erstellt werden, werden plattformverwaltet, als immer einsatzbereite Instanzen in Rechnung gestellt und ändern nicht die immer einsatzbereiten Konfigurationseinstellungen.

Wenn Sie Elastic Premium-Funktions-App-Pläne als zonenredundant konfigurieren, verteilt die Plattform automatisch die Funktions-App-Instanzen über die Zonen in der ausgewählten Region.

Die Verteilung der Instanzen bei einer zonenredundanten Bereitstellung wird innerhalb der folgenden Regeln festgelegt, auch wenn die App auf-und abskaliert:

  • Die Mindestanzahl der Funktions-App-Instanzen ist zwei.
  • Wenn Sie eine Kapazität angeben, die größer als die Anzahl der Zonen ist, werden die Instanzen nur gleichmäßig verteilt, wenn die Kapazität ein Vielfaches der Anzahl von Zonen ist.
  • Bei einem Kapazitätswert, der mehr als die Anzahl der Zonen * Anzahl der Instanzen ist, werden zusätzliche Instanzen über die verbleibenden Zonen verteilt.

Wichtig

Azure Functions kann auf der Azure App Service-Plattform ausgeführt werden. In der App Service-Plattform werden Pläne, die Premium-Funktions-Apps hosten, als Elastic Premium-Pläne bezeichnet, mit SKU-Namen wie EP1. Wenn Sie Ihre Funktions-App auf einem Premium-Plan ausführen möchten, stellen Sie sicher, dass Sie einen Plan mit einem SKU-Namen erstellen, der mit E, wie z. B. EP1 beginnt. SKU-Namen des App Service-Plans, die mit P( P1V2 Premium V2 Small Plan) beginnen, sind dedizierte Hostingpläne. Da sie "Dedicated" und nicht "Elastic Premium" sind, werden Pläne mit SKU-Namen, die mit P beginnen, nicht dynamisch skaliert und können Ihre Kosten erhöhen.

Regionale Verfügbarkeit

Derzeit unterstützen nicht alle Regionen Zonenredundanz für Flex-Verbrauchspläne. Sie können die Azure CLI verwenden, um die Regionen anzuzeigen, die sie unterstützen:

  1. Wenn Sie dies noch nicht getan haben, installieren Sie Azure, und melden Sie sich mit der Azure CLI bei Azure an:

    az login

    Der az login Befehl meldet Sie bei Ihrem Azure-Konto an.

  2. Verwenden Sie diesen az functionapp list-flexconsumption-locations Befehl mit der --zone-redundant=true Option, eine Liste der Regionen zurückzugeben, die derzeit zonenredundante Flex-Verbrauchspläne unterstützen:

    az functionapp list-flexconsumption-locations --zone-redundant=true --query "sort_by(@, &name)[].{Region:name}" -o table

Wenn Sie im Azure-Portal eine Flex-Verbrauch-App erstellen, wird der Bereich Zone redundancy auf der Seite Grundlagen aktiviert, wenn Ihre ausgewählte Region ihn unterstützt.

Zonenredundante Premium-Pläne sind in diesen Regionen verfügbar:

Amerika Europa Naher Osten Afrika Asien-Pazifik
Brasilien, Süden Frankreich, Mitte Israel, Mitte Südafrika, Norden Australien, Osten
Kanada, Mitte Deutschland, Westen-Mitte Katar, Mitte Indien, Mitte
USA, Mitte Italien, Norden UAE, Norden China, Norden 3
Ost-USA Nordeuropa Asien, Osten
USA (Ost) 2 Norwegen, Osten Japan, Osten
USA Süd Mitte Schweden, Mitte Asien, Südosten
USA, Westen 2 Schweiz, Norden
USA, Westen 3 UK, Süden
Europa, Westen

Voraussetzungen

Die Unterstützung von Verfügbarkeitszonen ist eine Eigenschaft des Flex-Nutzungsplans. Hier sind die aktuellen Überlegungen zur Verwendung von Verfügbarkeitszonen:

Unterstützung für Verfügbarkeitszonen ist eine Eigenschaft des Premium-Plans. Hier sind aktuelle Überlegungen für Verfügbarkeitszonen:

  • Sie können Verfügbarkeitszonen nur im Plan aktivieren, wenn Sie Ihre App erstellen. Sie können einen vorhandenen Premium-Plan nicht so konvertieren, dass Verfügbarkeitszonen verwendet werden.
  • Sie müssen ein zonenredundantes Speicherkonto (ZRS) für das Standardmäßige Hostspeicherkonto Ihrer Funktions-App verwenden. Wenn Sie einen anderen Speicherkontotyp verwenden, verhält sich Ihre App möglicherweise unerwartet während eines Zonalausfalls.
  • Es werden sowohl Windows als auch Linux unterstützt.
  • Funktions-Apps, die in einem Premium-Plan gehostet werden, müssen mindestens zwei immer einsatzbereite Instanzen aufweisen.
  • Die Plattform erzwingt diese Mindestanzahl hinter den Kulissen, wenn Sie eine Instanzanzahl weniger als zwei angeben.
  • Wenn Sie keinen Premium-Plan bzw. keine Skalierungseinheit verwenden, die Verfügbarkeitszonen unterstützt, sich in einer nicht unterstützten Region befinden oder unsicher sind, lesen Sie den Migrationsleitfaden.

Preise

Dem Aktivieren von Verfügbarkeitszonen ist kein separater Zähler zugeordnet. Die Preise für Instanzen, die für eine zonenredundante App vom Typ „Flex-Verbrauch“ verwendet werden, sind identisch mit denen für eine App vom Typ „Flex-Verbrauch“ mit einer einzelnen Zone. Weitere Informationen finden Sie unter Abrechnung.

Wenn Sie Verfügbarkeitszonen in einer App mit immer einsatzbereiter Instanzkonfiguration von weniger als zwei Instanzen für jede Skalierungsfunktion oder Gruppe aktivieren, erstellt die Plattform automatisch zwei Instanzen des always-ready-Typs für jede Skalierungsfunktion oder Gruppe pro Funktion. Diese neuen Instanzen werden auch als immer einsatzbereite Instanzen in Rechnung gestellt.

Mit dem Aktivieren von Verfügbarkeitszonen sind keine zusätzlichen Kosten verbunden. Die Preise für einen zonenredundanten Premium App Service-Plan sind identisch mit einem einzelnen Zonen Premium-Plan. Für jeden App Service-Plan, den Sie verwenden, werden die Gebühren auf Grundlage der ausgewählten SKU, der von Ihnen angegebenen Kapazität und aller Instanzen berechnet, auf die Sie basierend auf Ihren Kriterien für die Autoskalierung skalieren. Wenn Sie Verfügbarkeitszonen für einen Plan mit weniger als zwei Instanzen aktivieren, erzwingt die Plattform eine Mindestinstanzanzahl von zwei für diesen App Service-Plan, und Sie werden für beide Instanzen in Rechnung gestellt.

Erstellen Sie eine Funktions-App in einem zonenredundanten Plan

Es gibt derzeit mehrere Möglichkeiten zum Bereitstellen einer zonenredundanten Flex-Verbrauch-App.

  1. Navigieren Sie im Azure-Portal zur Seite Funktions-App erstellen. Weitere Informationen zum Erstellen einer Funktions-App im Portal finden Sie unter Erstellen einer Funktions-App.

  2. Wählen Sie Flex-Verbrauch und dann die Auswahl-Schaltfläche aus.

  3. Geben Sie auf der Seite "Funktions-App erstellen" (Flex-Verbrauch) auf der Registerkarte " Grundlagen " die Einstellungen für Ihre Funktions-App ein. Achten Sie besonders auf die Einstellungen in der folgenden Tabelle (auch im nachstehenden Screenshot hervorgehoben), für die spezifische Anforderungen in Bezug auf die Zonenredundanz gelten.

    Einstellung Vorgeschlagener Wert Hinweise für Zonenredundanz
    Region Ihre bevorzugte unterstützte Region Die Region, in der Ihr Flex-Verbrauchsplan erstellt wird. Sie müssen eine Region auswählen, die Verfügbarkeitszonen unterstützt. Siehe die Liste der regionalen Verfügbarkeit.
    Zonenredundanz Aktiviert Diese Einstellung gibt an, ob Ihre App zonenredundant ist. Sie können nur auswählen Enabled , wenn Sie einen Bereich ausgewählt haben, der Zonenredundanz unterstützt.

    Screenshot der Registerkarte

  4. Geben Sie auf der Registerkarte Speicher die Einstellungen für Ihr Funktions-App-Speicherkonto ein. Achten Sie besonders auf die Einstellung in der folgenden Tabelle, für die spezifische Anforderungen in Bezug auf die Zonenredundanz gelten.

    Einstellung Vorgeschlagener Wert Hinweise für Zonenredundanz
    Speicherkonto Zonenredundantes Speicherkonto Wie im Abschnitt Voraussetzungen beschrieben, wird dringend die Verwendung eines zonenredundanten Speicherkontos für Ihre zonenredundante Funktions-App empfohlen.

  5. Gehen Sie im übrigen Prozess zur Erstellung Ihrer Funktions-App wie gewohnt vor. Im übrigen Erstellungsprozess gibt es keine Einstellungen, die sich auf die Zonenredundanz auswirken.

Nachdem der zonenredundante Plan erstellt und bereitgestellt wurde, ist die Funktions-App vom Typ „Flex-Verbrauch“, die in Ihrem neuen Plan gehostet wird, zonenredundant.

Aktualisieren eines Flex-Verbrauchsplans, um zonenredundant zu sein

Das Ändern der Zonenredundanz Ihrer App erfordert einen Neustart, was zu Ausfallzeiten in Ihrer App führt.

Bevor Sie Ihren Flex-Verbrauchsplan so aktualisieren, dass er zonenredundant ist, sollten Sie das Standardmäßige Hostspeicherkonto so aktualisieren, dass es auch zonenredundant ist. Wenn Sie ein separates Speicherkonto für den Bereitstellungscontainer der App verwenden, sollten Sie es auch so aktualisieren, dass es zonenredundant ist.

Führen Sie die folgenden Schritte aus, um Ihre Speicherkonten für die Änderung vorzubereiten:

  1. Überprüfen Sie Überlegungen zur Speicherung.
  2. Erstellen oder bestimmten Sie ein zonenredundantes Speicherkonto als Standardhostspeicherkonto für die App.
  3. Aktualisieren Sie die speicherbezogenen Anwendungseinstellungen der App, wie zum Beispiel AzureWebJobsStorage, um auf das zonenredundante Speicherkonto zu verweisen. Siehe "Arbeiten mit Anwendungseinstellungen".
  4. Aktualisieren Sie das Bereitstellungsspeicherkonto für die App, das identisch oder anders sein kann als das Speicherkonto, das der App zugeordnet ist. Siehe Konfigurieren von Bereitstellungseinstellungen.

Nachdem die von Ihrer App verwendeten Speicherkonten aktualisiert wurden, können Sie den Flex Consumption-Plan so aktualisieren, dass er zonenredundant ist, indem Sie Bicep- oder ARM-Vorlagen verwenden. Das Azure-Portal unterstützt derzeit keine Zonenredundanzupdates für den Plan.

Wird derzeit nicht unterstützt.

Derzeit gibt es zwei Möglichkeiten, einen zonenredundanten Premium-Plan und eine zonenredundante Funktions-App bereitzustellen. Sie können das Azure-Portal oder eine ARM-Vorlage verwenden.

  1. Navigieren Sie im Azure-Portal zur Seite Funktions-App erstellen. Weitere Informationen zum Erstellen einer Funktions-App im Portal finden Sie unter Erstellen einer Funktions-App.

  2. Wählen Sie Functions Premium und dann die Schaltfläche Auswählen aus.

  3. Geben Sie auf der Seite Funktions-App erstellen (Functions Premium) auf der Registerkarte Grundlagen die Einstellungen für Ihre Funktions-App ein. Achten Sie besonders auf die Einstellungen in der folgenden Tabelle (auch im nachstehenden Screenshot hervorgehoben), für die spezifische Anforderungen in Bezug auf die Zonenredundanz gelten.

    Einstellung Vorgeschlagener Wert Hinweise für Zonenredundanz
    Region Ihre bevorzugte unterstützte Region Die Region, in der Ihr Elastic Premium-Plan erstellt wird. Sie müssen eine Region auswählen, die Verfügbarkeitszonen unterstützt. Siehe die Liste der regionalen Verfügbarkeit.
    Pricing Plan Einer der Pläne vom Typ „Elastisch Premium“. Weitere Informationen finden Sie unter Verfügbare Instanz-SKUs. In diesem Artikel erfahren Sie, wie Sie eine zonenredundante App in einem Premium-Plan erstellen. Zonenredundanz ist derzeit nicht in Verbrauchsplänen verfügbar. Informationen zur Zonenredundanz für App Service-Pläne finden Sie unter Zuverlässigkeit in Azure App Service.
    Zonenredundanz Aktiviert Diese Einstellung gibt an, ob Ihre App zonenredundant ist. Sie können Enabled nur auswählen, wenn Sie eine Region ausgewählt haben, die Zonenredundanz unterstützt, wie zuvor beschrieben.

    Screenshot: Registerkarte „Grundlagen“ auf der Seite zum Erstellen einer Funktions-App

  4. Geben Sie auf der Registerkarte Speicher die Einstellungen für Ihr Funktions-App-Speicherkonto ein. Achten Sie besonders auf die Einstellung in der folgenden Tabelle, für die spezifische Anforderungen in Bezug auf die Zonenredundanz gelten.

    Einstellung Vorgeschlagener Wert Hinweise für Zonenredundanz
    Speicherkonto Zonenredundantes Speicherkonto Wie im Abschnitt Voraussetzungen beschrieben, wird dringend die Verwendung eines zonenredundanten Speicherkontos für Ihre zonenredundante Funktions-App empfohlen.

  5. Gehen Sie im übrigen Prozess zur Erstellung Ihrer Funktions-App wie gewohnt vor. Im übrigen Erstellungsprozess gibt es keine Einstellungen, die sich auf die Zonenredundanz auswirken.

Nachdem der zonenredundante Plan erstellt und bereitgestellt wurde, ist jede Funktions-App, die in Ihrem neuen Plan gehostet wird, zonenredundant.

Migration der Verfügbarkeitszone

Sie können derzeit die Verfügbarkeitszone-Unterstützung eines Elastic Premium-Plans für eine vorhandene Funktions-App nicht ändern. Informationen zum Migrieren des öffentlichen Multitenant Premium-Plans von der Nichtverfügbarkeitszone zur Unterstützung der Verfügbarkeitszone finden Sie unter Migrieren des App-Diensts zur Unterstützung der Verfügbarkeitszone.

Zonenausfall

Alle verfügbaren Funktions-App-Instanzen von zonenredundanten Flex-Verbrauchsplan-Apps sind aktiviert und verarbeiten Ereignisse. Apps im Plan „Flex-Verbrauch“ funktionieren weiter, selbst wenn für andere Zonen in derselben Region ein Ausfall auftritt. Es ist allerdings möglich, dass nicht laufzeitbedingte Verhaltensweisen aufgrund eines Ausfalls in anderen Verfügbarkeitszonen beeinträchtigt sind. Standardfunktions-App-Verhalten, die sich auf die Verfügbarkeit auswirken können, umfassen:

  • Skalierung
  • App-Erstellung
  • Konfigurationsänderungen
  • Bereitstellungen

Zonenredundanz für Premium-Pläne stellt nur eine kontinuierliche Uptime für bereitgestellte Anwendungen sicher, die gerade ausgeführt werden.

Wenn eine Zone abläuft, erkennt Functions verlorene Instanzen und versucht automatisch, ersatzinstanzen nach Bedarf in den verfügbaren Zonen zu suchen oder zu erstellen. Während des zonalen Ausfalls versucht die Plattform, das Gleichgewicht auf den verbleibenden verfügbaren Zonen wiederherzustellen.

Alle verfügbaren Funktions-App-Instanzen zonenredundanter Funktions-Apps sind aktiviert und verarbeiten Ereignisse. Wenn eine Zone ausfällt, erkennt Functions die verlorenen Instanzen und versucht bei Bedarf automatisch, neue Ersatzinstanzen zu finden. Das Verhalten der elastischen Skalierung gilt weiterhin. In einem Szenario mit einer ausgefallenen Zone gibt es keine Garantie dafür, dass Anforderungen zusätzlicher Instanzen erfolgreich sein werden, da das Auffüllen verlorener Instanzen nach dem Prinzip der bestmöglichen Leistung erfolgt. Anwendungen, die in einem Premium-Plan mit aktivierter Verfügbarkeitszone bereitgestellt werden, werden auch dann weiter ausgeführt, wenn andere Zonen in derselben Region ausfallen. Es ist jedoch möglich, dass nicht laufzeitbezogene Verhaltensweisen dennoch von einem Ausfall in anderen Verfügbarkeitszonen betroffen sein können. Diese betroffenen Verhaltensweisen können Folgendes umfassen: Skalierung von Premium-Plänen, Anwendungserstellung, Anwendungskonfiguration und Anwendungsveröffentlichung. Zonenredundanz für Premium-Pläne stellt nur eine kontinuierliche Uptime für bereitgestellte Anwendungen sicher.

Wenn Functions einem zonenredundanten Premium-Plan Instanzen zuordnet, wird ein „Best Effort“-Zonenausgleich verwendet, der von den zugrunde liegenden Azure-VM-Skalierungsgruppen angeboten wird. Ein Premium-Plan wird als ausgeglichen betrachtet, wenn jede Zone entweder die gleiche Anzahl virtueller Computer in allen anderen Zonen aufweist, die vom Premium-Plan verwendet werden, plus-oder minus ein virtueller Computer.

Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität

Notfallwiederherstellung (DR) bezieht sich auf Methoden, die Organisationen zum Wiederherstellen von Ereignissen mit hohem Einfluss verwenden, z. B. Naturkatastrophen oder fehlerhafte Bereitstellungen, die zu Ausfallzeiten und Datenverlusten führen. Unabhängig von der Ursache ist das beste Mittel gegen einen Notfall ein gut definierter und getesteter Notfallwiederherstellungsplan und ein Anwendungsdesign, das die Notfallwiederherstellung aktiv unterstützt. Bevor Sie mit der Erstellung Ihres Notfallwiederherstellungsplans beginnen, finden Sie Unter "Empfehlungen für das Entwerfen einer Notfallwiederherstellungsstrategie".

Für DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In diesem Modell stellt Microsoft sicher, dass die Basisinfrastruktur und Plattformdienste verfügbar sind. Viele Azure-Dienste replizieren jedoch nicht automatisch Daten oder greifen von einer fehlgeschlagenen Region zurück, um sie in eine andere aktivierte Region zu replizieren. Für diese Dienste sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die im Rahmen von Azure-PaaS-Angeboten (Plattform-as-a-Service) ausgeführt werden, bieten Features und Anleitungen zur Unterstützung der Notfallwiederherstellung. Sie können dienstspezifische Features verwenden, um die schnelle Wiederherstellung zu unterstützen, um Ihren DR-Plan zu entwickeln.

In diesem Abschnitt werden einige der Strategien erläutert, mit denen Sie eine Funktions-App bereitstellen können, um die Notfallwiederherstellung zu ermöglichen.

Informationen zur Notfallwiederherstellung für Durable Functions finden Sie unter Notfallwiederherstellung und geografische Verteilung in Azure Durable Functions.

Notfallwiederherstellung in mehreren Regionen

Da keine integrierte Redundanz verfügbar ist, werden Funktionen in einer Funktions-App in einer bestimmten Azure-Region ausgeführt. Um Ausführungsverluste bei Ausfällen zu vermeiden, können Sie dieselben Funktionen redundant einsetzen, um Anwendungen in mehreren Regionen zu betreiben. Weitere Informationen über Bereitstellungen in mehreren Regionen finden Sie in der Anleitung Hochverfügbare Webanwendung für mehrere Regionen.

Wenn Sie denselben Funktionscode in mehreren Regionen ausführen, gibt es zwei Muster zu beachten: Aktiv-aktiv und Aktiv-passiv.

Aktiv-aktiv-Muster für HTTP-Triggerfunktionen

Mit einem Aktiv-aktiv-Muster werden Funktionen in beiden Regionen aktiv ausgeführt und verarbeiten Ereignisse, entweder in doppelter Weise oder wechselweise. Sie sollten ein Aktiv-Aktiv-Muster in Kombination mit Azure Front Door für Ihre kritischen, von HTTP ausgelösten Funktionen verwenden, das HTTP-Anfragen zwischen Funktionen, die in mehreren Regionen ausgeführt werden, weiterleiten und Round-Robin-Vorgänge für sie ausführen kann. Front Door kann außerdem die Integrität der einzelnen Endpunkte regelmäßig überprüfen. Wenn eine Funktion in einer Region nicht mehr auf Integritätsprüfungen reagiert, nimmt Azure Front Door sie aus der Rotation und leitet den Datenverkehr nur an die verbleibenden gesunden Funktionen weiter.

Architektur für Azure Front Door und Funktionen

Ein Beispiel finden Sie im Beispiel zum Implementieren des Geode-Musters durch Bereitstellen der API für Geoden in verteilten Azure-Regionen.For an example, see the sample on how to implement the geode pattern by deploying the API to geodes in distributed Azure regions..

Aktiv-passiv-Redundanz für Nicht-HTTPS-Triggerfunktionen

Es wird empfohlen, dass Sie das Aktiv-passiv-Muster für Ihre ereignisgesteuerten, nicht über HTTP ausgelösten Funktionen verwenden, z. B. über Service Bus und Event Hubs ausgelöste Funktionen.

Verwenden Sie ein Aktiv-passiv-Muster, um Redundanz für Nicht-HTTP-Triggerfunktionen zu erstellen. Mit einem Aktiv-passiv-Muster werden Funktionen aktiv in der Region ausgeführt, die Ereignisse empfängt, während die gleichen Funktionen in einer zweiten Region inaktiv bleiben. Das Aktiv-passiv-Muster bietet eine Möglichkeit, dass nur eine einzige Funktion jede Nachricht verarbeitet, und stellt gleichzeitig einen Mechanismus zur Verfügung, um im Notfall ein Failover in der sekundären Region durchzuführen. Funktions-Apps arbeiten mit dem Failover-Verhalten der Partnerdienste, wie Azure Service Bus Geo-Recovery und Azure Event Hubs Geo-Recovery.

Betrachten Sie eine Beispieltopologie mit einem Azure Event Hubs-Auslöser. In diesem Fall erfordert das Aktiv-Passiv-Muster die Einbeziehung der folgenden Komponenten:

  • Azure Event Hubs ist für eine primäre und eine sekundäre Region bereitgestellt.
  • Georedundante Notfallwiederherstellung ist aktiviert, um den primären und sekundären Event Hub zu koppeln. Dadurch wird auch ein Alias erstellt, mit dem Sie eine Verbindung zu Event-Hubs herstellen und von einem primären zu einem sekundären Hub wechseln können, ohne die Verbindungsdaten zu ändern.
  • Funktions-Apps werden sowohl in der primären als auch in der sekundären (Failover-)Region eingesetzt, wobei die App in der sekundären Region im Wesentlichen inaktiv ist, da keine Nachrichten dorthin gesendet werden.
  • Die Funktions-App wird für die direkte (Nicht-Alias-)Verbindungszeichenfolge für ihren jeweiligen Event Hub ausgelöst.
  • Verleger für den Event Hub sollten ihre Veröffentlichungen über die Aliasverbindungszeichenfolge ausführen.

Beispielarchitektur für aktiv/passiv

Vor dem Failover leiten Verleger, die an den gemeinsamen Alias senden, zum primären Event Hub weiter. Die primäre Funktions-App lauscht exklusiv auf den primären Event Hub. Die sekundäre Funktions-App ist passiv und befindet sich im Leerlauf. Sobald der Failover eingeleitet wird, werden Verleger, die an den gemeinsamen Alias senden, an den sekundären Event Hub weitergeleitet. Die sekundäre Funktions-App wird nun aktiv und löst automatisch aus. Ein effektives Failover zu einer sekundären Region kann vollständig vom Event Hub gesteuert werden, wobei die Funktionen nur aktiv werden, wenn der jeweilige Event Hub aktiv ist.

Lesen Sie mehr über Informationen und Überlegungen zum Failover mit Service Bus und Event Hubs.

Aktiv-Aktiv-Muster für Nicht-HTTPS-Triggerfunktionen

Sie werden zwar ermutigt, das aktiv-passive Muster für Nicht-HTTPS-Triggerfunktionen zu verwenden, aber Sie können weiterhin aktive Bereitstellungen für nicht-HTTP-ausgelöste Funktionen erstellen. Bevor Sie dieses Muster implementieren, müssen Sie überlegen, wie die beiden aktiven Regionen miteinander interagieren oder koordinieren.

Erwägen Sie beispielsweise die Bereitstellung des gleichen Service Bus-Funktionscodes in zwei Regionen, aber das Auslösen in derselben Service Bus-Warteschlange. In diesem Fall fungieren beide Funktionen als konkurrierende Consumer beim Entfernen aus der einzelnen Warteschlange. Obwohl jede Nachricht nur von einer der beiden App-Instanzen verarbeitet werden kann, bedeutet dies auch, dass es immer noch einen einzigen Fehlerpunkt gibt, bei dem es sich um die einzelne ServiceBus-Instanz handelt.

Sie können stattdessen zwei Servicebuswarteschlangen mit einer in einer primären Region, einer in einer sekundären Region, bereitstellen. In diesem Fall könnten Sie zwei Funktions-Apps haben, die jeweils auf die in ihrer Region aktive Servicebus-Warteschlange verweisen. Die Herausforderung bei dieser Topologie besteht darin, wie die Nachrichten der Warteschlange zwischen den beiden Regionen verteilt werden. Häufig bedeutet dies, dass jeder Herausgeber versucht, eine Nachricht in beiden Regionen zu veröffentlichen, und jede Nachricht von beiden aktiven Funktions-App verarbeitet wird. Dadurch entsteht zwar das gewünschte Aktiv/Aktiv-Muster, aber es ergeben sich auch andere Herausforderungen in Bezug auf die Duplizierung von Rechenleistung und die Frage, wann und wie Daten konsolidiert werden.

Nächste Schritte