Zuverlässigkeit in Azure Functions

Azure Functions ist ein ereignisgesteuerter Computedienst, der kleine Codeblöcke ausführt, oder functions ohne explizite Bereitstellung oder Verwaltung der Infrastruktur. Funktionen können auf Ereignisse wie HTTP-Anforderungen, Zeitgeber, Warteschlangennachrichten und Änderungen in anderen Azure-Diensten reagieren. Diese Fähigkeit macht Funktionen gut geeignet für die Datenverarbeitung, Systemintegration und Hintergrundaufgaben.

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 Funktionen für verschiedene potenzielle Ausfälle und Probleme wie vorübergehende Fehler, Verfügbarkeitszonenfehler und regionsweite Fehler ausfallsicher werden. Außerdem werden wichtige Informationen zum Servicelevelvertrag "Functions Service Level Agreement (SLA)" hervorgehoben.

Bereitstellungsempfehlungen für die Produktion

Das Azure Well-Architected Framework bietet Empfehlungen für Zuverlässigkeit, Sicherheit, Kosten, Vorgänge und Leistung. Informationen dazu, wie sich diese Bereiche gegenseitig beeinflussen und zu einer zuverlässigen Funktionslösung beitragen, finden Sie unter Architektur bewährte Methoden für Funktionen.

Übersicht über die Zuverlässigkeitsarchitektur

Wenn Sie Funktionen bereitstellen, ist es wichtig, sich mit den folgenden Konzepten vertraut zu machen:

  • Hostingpläne: Pläne stellen die Hostingumgebung für Ihre Funktions-Apps dar. Der Plan bestimmt die verfügbaren Computeressourcen, das Preismodell und das Skalierungsverhalten.

  • Speicherkonten: Wenn Sie eine Funktions-App erstellen, müssen Sie ein Hostspeicherkonto angeben. Das Speicherkonto verwaltet Aspekte der internen Vorgänge der Funktions-App, einschließlich Funktionscodespeicherung, Protokollierung und Parallelitätsverwaltung (z. B. Blob-Leases für bestimmte Triggertypen).

    Sie können auch ein Speicherkonto für die Bereitstellung verwenden. Dieses Speicherkonto ist möglicherweise identisch mit Ihrem Hostspeicherkonto oder einem anderen Speicherkonto.

    Von Bedeutung

    Speicherkonten sind ein wichtiger Bestandteil ihrer Funktionssicherheitsarchitektur. Konfigurieren Sie sie so, dass sie die Resilienzanforderungen Ihrer Funktions-App erfüllen.

  • Trigger und Bindungen: Trigger und Bindungen ermöglichen es Ihrer Funktion, auf Ereignisse zu reagieren, Daten von anderen Diensten zu empfangen und Daten in andere Dienste zu schreiben.

  • Dauerhafte Funktionen: Dauerhafte Funktionen sind ein Feature von Funktionen. Es stellt zustandsbehaftete Funktionen wie langlaufende Orchestrierungen und zustandsbehaftete Entitäten bereit.

    Wenn Sie dauerhafte Funktionen verwenden, konfigurieren Sie einen Speicheranbieter , der den Zustand speichert. Bewerten Sie die Zuverlässigkeitsmerkmale des von Ihnen ausgewählten Zustandsspeichers, und konfigurieren Sie ihn, um Ihre Resilienzanforderungen zu erfüllen.

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 zur Behandlung vorübergehender Fehler.

Beachten Sie die folgenden Empfehlungen für die Behandlung vorübergehender Fehler in Ihren Funktions-Apps:

  • Trigger und Bindungen: Die Functions-Plattform enthält integrierte vorübergehende Fehlerbehandlung für Trigger und Bindungen. Wenn ein vorübergehender Fehler auftritt, während ein unterstützter Trigger ausgelöst wird oder eine unterstützte Bindung Daten liest oder schreibt, kann die Plattform den Vorgang automatisch wiederholen. Dieses integrierte Wiederholungsverhalten stellt sicher, dass temporäre Verbindungsprobleme oder Dienstunterbrechungen die Ausführung Ihrer Funktion nicht verhindern. Weitere Informationen finden Sie unter "Fehlerbehandlung von Funktionen" und "Wiederholungen".

    Dieser Schutz deckt nur vorübergehende Fehler ab. Die Plattform wiederholt keine dauerhaften Fehler, z. B. eine falsch konfigurierte Verbindungszeichenfolge oder eine gelöschte Ressource.

    Die Plattform behandelt dauerhafte Fehler und wiederholte vorübergehende Fehler als Fehler. Konfigurieren Sie die Protokollierung, um Informationen zu Funktionsausführungsfehlern zu erfassen. Weitere Informationen finden Sie unter Konfigurieren der Überwachung für Funktionen.

  • Ihr Funktionscode: Im Funktionscode sind Sie für die Behandlung vorübergehender Fehler verantwortlich, wenn Ihre Funktion externe Dienste aufruft. Implementieren Sie Wiederholungslogik, Timeouts und Schaltkreistrennmuster entsprechend für externe Dienstaufrufe, die in Ihrem Funktionscode ausgeführt werden. Entwerfen Sie Ihre Funktionen so, dass sie möglichst idempotent sind, sodass Wiederholungen keine doppelten Nebenwirkungen erzeugen.

  • Kunden: Clientanwendungen, die synchron eine Verbindung mit Funktionen herstellen, z. B. über eine HTTP-Verbindung, sollten für vorübergehende Fehler widerstandsfähig sein.

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.

Verbrauchspläne unterstützen keine Verfügbarkeitszonen. Wenn Zonenredundanz eine Anforderung für Ihre Workload ist, sollten Sie stattdessen die Pläne Flex Consumption, Premium oder Dedicated (Azure App Service) verwenden.

Flex-Verbrauchspläne unterstützen zonenredundante Bereitstellungen.

Premium-Pläne unterstützen zonenredundante Bereitstellungen.

Wenn Zonenredundanz aktiviert ist, verteilt die Plattform Ihre Planinstanzen automatisch über alle Verfügbarkeitszonen in der ausgewählten Region. Wenn eine Verfügbarkeitszone in der Region ein Problem hat, werden Ihre Funktionen weiterhin mithilfe von Instanzen in fehlerfreien Zonen ausgeführt.

Sie müssen den zonenredundanten Speicher (ZRS) für das Hostspeicherkonto aktivieren, wodurch sichergestellt wird, dass er auch widerstandsfähig für Zonenausfälle ist.

Diagramm, das einen plan mit zonenredundanten Funktionen zeigt, der drei Instanzen umfasst, die sich über drei Zonen und ein ZRS-Konto erstrecken.

Der Dedizierte Plan (App Service) unterstützt zonenredundante Bereitstellungen. Wenn Zonenredundanz aktiviert ist, verteilt die Plattform Ihre Instanzen automatisch über alle Verfügbarkeitszonen in der ausgewählten Region. Sie konfigurieren Zonenredundanz für den Plan. Weitere Informationen dazu, wie Azure App Service Zonenredundanz behandelt, finden Sie unter Reliability in App Service.

Ihr Plan ist nicht zonen- oder regional , wenn Sie keine Zonenredundanz aktivieren. Die Plattform kann Planinstanzen in einer beliebigen Verfügbarkeitszone in der Region oder in derselben Verfügbarkeitszone platzieren. Planinstanzen sind nicht widerstandsfähig gegen Ausfälle von Verfügbarkeitszonen. Ihr Plan kann während eines Ausfalls in irgendeiner Zone der Region Ausfallzeiten haben.

Anforderungen

  • Regionsunterstützung: Sie können zonenredundante Flex-Verbrauchspläne in einer bestimmten Gruppe von Regionen bereitstellen. Sie können die aktuelle Liste der unterstützten Regionen mithilfe der Azure CLI abrufen. Weitere Informationen finden Sie unter Anzeigen von Regionen, die Verfügbarkeitszonen unterstützen.

  • Regionsunterstützung: Sie können zonenredundante Premium-Pläne in den folgenden Regionen bereitstellen.

    Amerika Europa Naher Osten Afrika Asien-Pazifik
    Brasilien Süd Frankreich, Mitte Israel Central Südafrika Nord Australia East
    Canada Central Deutschland West Central Qatar Central Zentralindien
    Central US Italy North Vereinigte Arabische Emirate, Norden China, Norden 3
    East US Nordeuropa Ostasien
    Ost-USA 2 Norway East Japan, Osten
    Süd-Mittel-USA Schweden, Mitte Südostasien
    Westliches USA 2 Switzerland North
    Westliches USA 3 UK South
    West Europe

  • Operating systems: Die Plattform unterstützt die Bereitstellung zonenredundanter Windows und Linux-Pläne.

  • Mindestanzahl der Instanzen: Zonenredundanz für Premium-Pläne erfordert mindestens zwei immer einsatzbereite Instanzen.

  • Hostspeicherkonto: Sie müssen das Standardmäßige Hostspeicherkonto Ihrer Funktions-App für die Verwendung von ZRS konfigurieren. Wenn Sie ein Hostspeicherkonto verwenden, das nicht für ZRS konfiguriert ist, verhält sich Ihre App möglicherweise unerwartet während eines Zonenausfalls.
  • Bereitstellungscontainerspeicherkonto: Wenn Sie ein separates Speicherkonto für den Bereitstellungscontainer der App verwenden, aktualisieren Sie es auch so, dass es zonenredundant ist.

Überlegungen

Nichtruntime-Verhalten: Zonenredundanz garantiert nur eine fortgesetzte Betriebszeit für bereitgestellte Anwendungen. Ein Ausfall der Verfügbarkeitszone kann sich auf Aspekte von Funktionen auswirken, obwohl die Anwendung weiterhin Datenverkehr bedient. Zu diesen Verhaltensweisen gehören planskalierung, Anwendungserstellung, Anwendungskonfiguration und Anwendungsveröffentlichung.

Instanzverteilung über Zonen hinweg

Wenn Sie Flex-Verbrauchsplan-Apps als zonenredundant konfigurieren, verteilt die Plattform Automatisch Planinstanzen über mehrere Zonen in der ausgewählten Region mit unterschiedlichen Regeln für immer einsatzbereite und on-demand-Instanzen:

  • Immer einsatzbereite Instanzen werden mithilfe der Roundrobinverteilung über mindestens zwei Zonen verteilt.

    Um die Zonenresilienz sicherzustellen, verwaltet die Plattform automatisch mindestens zwei stets einsatzbereite Instanzen für jede per-Funktion-Skalierungsfunktion oder Gruppe, unabhängig von der stets einsatzbereiten Konfiguration für die App. Instanzen, die von der Plattform erstellt werden, werden plattformverwaltet, als immer einsatzbereite Instanzen in Rechnung gestellt und ändern nicht die immer einsatzbereiten Konfigurationseinstellungen.

  • On-Demand-Instanzen ergeben sich aus Ereignisquellvolumes, da die App über die Anzahl der immer einsatzbereiten Instanzen hinaus skaliert wird. On-Demand-Instanzen werden über Verfügbarkeitszonen hinweg auf Best-Effort-Basis verteilt. Die Plattform priorisiert eine schnellere Erweiterung statt einer gleichmäßigen Verteilung über die Zonen hinweg. Die Plattform versucht, die Verteilung im Laufe der Zeit auszugleichen.

Wenn Sie Elastic Premium-Funktions-App-Pläne als zonenredundant konfigurieren, verteilt die Plattform automatisch Planinstanzen über mehrere Zonen in der ausgewählten Region. Die Instanzenverteilung folgt diesen Regeln, auch wenn die App skaliert und verkleinert wird:

  • Die Mindestanzahl der Funktions-App-Instanzen ist zwei.

  • Wenn Sie eine Kapazität angeben, die größer als die Anzahl der Zonen ist, werden Instanzen gleichmäßig verteilt, wenn die Kapazität ein Vielfaches der Anzahl von Zonen ist.

  • Bei einem Kapazitätswert, der größer ist als das Produkt aus der Anzahl der Zonen und der Anzahl der Instanzen, werden zusätzliche Instanzen über die verbleibenden Zonen verteilt.

Wenn Funktionen Instanzen einem zonenredundanten Premium-Plan zuordnen, verwendet sie das Best-Effort-Zonen-Balancing, das die zugrunde liegenden Azure Virtual Machine Scale Sets bereitstellen. Azure betrachtet einen Premium-Plan als ausgeglichen, wenn jede Zone dieselbe Anzahl von virtuellen Computern (VMs) wie die anderen Zonen im Plan hat, plus oder minus einer VM.

Cost

Es entstehen keine zusätzlichen Kosten, wenn Sie Zonenredundanz aktivieren. Die Preise für einen zonenredundanten Plan sind identisch mit einem Einzelzonenplan. Das Aktivieren von Zonenredundanz wirkt sich jedoch auf die Mindestanzahl von Instanzen in Ihrem Plan aus.

Wenn Sie Verfügbarkeitszonen in einer App mit einer immer einsatzbereiten 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.

Wenn Sie Verfügbarkeitszonen für einen Plan aktivieren, der weniger als zwei Instanzen aufweist, erzwingt die Plattform eine Mindestinstanzanzahl von zwei für diesen Plan, und Sie werden für beide Instanzen in Rechnung gestellt.

Vollständige Preisdetails finden Sie unter Funktionen-Preise.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

  • Erstellen Sie einen neuen plan für zonenredundante Funktionen. Sie können Zonenredundanz aktivieren, wenn Sie einen neuen Plan erstellen. Weitere Informationen finden Sie unter Erstellen einer zonenredundanten Funktions-App.

  • Aktivieren Sie Zonenredundanz für einen vorhandenen Plan. Sie können Verfügbarkeitszonen für vorhandene Elastic Premium-Pläne aktivieren oder deaktivieren. Elastic Premium-Pläne weisen ein spezifisches Kapazitätsverhalten auf, das sich von dedizierten Plänen (App Service) unterscheidet und zusätzliche Konfigurationsschritte erfordert. Ausführliche Schritte finden Sie unter Aktivieren der Zonenredundanz für einen vorhandenen Plan.

  • Erstellen Sie einen neuen plan für zonenredundante Funktionen. Sie können Zonenredundanz aktivieren, wenn Sie einen neuen Plan erstellen. Weitere Informationen finden Sie unter Erstellen einer zonenredundanten Funktions-App.

  • Aktivieren Sie Zonenredundanz für einen vorhandenen Plan. Bei Premium-Plänen können Sie Zonenredundanz nur während der Planerstellung aktivieren. Sie können keinen vorhandenen Premium-Plan in einen zonenredundanten Plan umwandeln. Migrieren Sie Stattdessen Ihre App, indem Sie eine parallele Bereitstellung in einer neuen Premium-Plan-App erstellen. Weitere Informationen finden Sie unter Aktivieren der Zonenredundanz für einen vorhandenen Plan.

Kapazitätsplanung und -verwaltung

Zonenredundante Funktions-Apps werden auch dann weiterhin ausgeführt, wenn Zonen in der Region einen Ausfall erleben.

Während eines Zonenausfalls erkennt Funktionen verlorene Instanzen und versucht automatisch, Ersatzinstanzen in den fehlerfreien Zonen zu suchen oder zu erstellen. Die Plattform führt diesen Prozess auf Best-Effort-Basis aus und garantiert keinen Erfolg. Wenn Ihre Workload eine bestimmte Anzahl von Instanzen erfordert, um die erwartete Serviceebene beizubehalten, sollten Sie die Anzahl der stets bereiten Instanzen überdimensionieren. Die Überteilung ermöglicht es der Lösung, Kapazitätsverluste zu tolerieren und ohne verringerte Leistung weiter zu funktionieren. Weitere Informationen finden Sie unter Kapazität durch Überprovisionierung verwalten.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein Plan redundant ist, das Hostspeicherkonto ZRS verwendet und alle Verfügbarkeitszonen betriebsbereit sind.

  • Zonenübergreifender Vorgang: Wenn Sie Zonenredundanz für Funktionen konfigurieren, werden Anforderungen automatisch auf die Instanzen in jeder Verfügbarkeitszone verteilt. Eine Anforderung könnte an jede Instanz in einer beliebigen Verfügbarkeitszone gerichtet werden.

  • Zonenübergreifende Datenreplikation: Funktionen sind ein zustandsloser Computedienst, daher gibt es keine Daten, die zwischen Zonen repliziert werden sollen. Die Plattform repliziert die Konfiguration automatisch über Zonen hinweg.

    Wenn Ihr Hostspeicherkonto ZRS verwendet, repliziert Azure Storage seine Daten synchron in mehreren Verfügbarkeitszonen.

    Überprüfen Sie bei dauerhaften Funktionen Ihren Speicheranbieter, um zu erfahren, wie sie Daten über Zonen hinweg repliziert.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten sollten, wenn ein Plan zonenredundant ist, das Hostspeicherkonto ZRS verwendet und ein Ausfall in der Verfügbarkeitszone auftritt.

  • Erkennung und Reaktion: Die Funktionenplattform ist dafür verantwortlich, einen Fehler in einer Verfügbarkeitszone zu erkennen. Sie müssen kein Zonenfailover initiieren.
  • Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone deaktiviert ist. Sie können jedoch Azure Resource Health verwenden, um den Status einer einzelnen Ressource zu überwachen, und Sie können Resource Health Alerts einrichten, um Sie über Probleme zu informieren. Sie können auch 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 Anforderungen: Wenn eine Verfügbarkeitszone nicht verfügbar ist, werden laufende Anforderungen, die eine Verbindung mit einer Instanz in der fehlerhaften Verfügbarkeitszone herstellen, beendet und müssen erneut versucht werden. Stellen Sie sicher, dass Ihre Anwendungen vorbereitet sind, indem Sie die Richtlinien für die vorübergehende Fehlerbehandlung ausführen.

  • Erwarteter Datenverlust: Es wird nicht erwartet, dass Zonenfehler Datenverlust verursachen, da Funktionen ein zustandsloser Dienst ist.

    Wenn Ihr Hostspeicherkonto ZRS verwendet, stellt Storage sicher, dass kein Datenverlust durch einen Zonenfehler auftritt.

    Überprüfen Sie bei dauerhaften Funktionen Ihren Speicheranbieter, um zu erfahren, ob Datenverlust während eines Zonenfehlers möglich ist.

  • Erwartete Ausfallzeiten: Während Zonenausfällen kann es zu kurzen Unterbrechungen bei den Verbindungen kommen, die in der Regel einige Sekunden dauern, während der Datenverkehr umverteilt wird. Stellen Sie sicher, dass Ihre Anwendungen vorbereitet sind, indem Sie die Richtlinien für die vorübergehende Fehlerbehandlung ausführen.

  • Datenverkehrsumleitung: Funktionen erkennen die verlorenen Instanzen aus dieser Zone und versuchen, neue Ersatzinstanzen zu finden. Nachdem Funktionen Ersetzungen gefunden haben, verteilt sie den Datenverkehr nach Bedarf über die neuen Instanzen.

    Von Bedeutung

    Azure garantiert nicht, dass Anforderungen nach mehr Instanzen in einem Szenario mit Zonenausfall erfolgreich sind. Die Plattform versucht, verlorene Instanzen nach Möglichkeit abzugleichen. Wenn Sie während eines Ausfalls der Verfügbarkeitszone eine garantierte Kapazität benötigen, erstellen und konfigurieren Sie Ihre Pläne, um Zonenverluste zu berücksichtigen, indem Sie die Kapazität überprovisionieren.

  • Nichtruntime-Verhalten: Anwendungen in einem zonenredundanten Funktions-App-Plan werden weiterhin ausgeführt und stellen den Datenverkehr auch dann zur Verfügung, wenn eine Verfügbarkeitszone einen Ausfall erlebt. Während eines Ausfalls einer Verfügbarkeitszone können jedoch nicht-laufzeitabhängige Verhaltensweisen beeinträchtigt werden. Zu diesen Verhaltensweisen gehören Funktions-App-Skalierung, Anwendungserstellung, Anwendungskonfiguration und Anwendungsveröffentlichung.

Zonenwiederherstellung

Wenn die Verfügbarkeitszone wiederhergestellt wird, stellt Functions die Instanzen in der Verfügbarkeitszone automatisch wieder her, entfernt temporäre Instanzen, die in den anderen Verfügbarkeitszonen erstellt wurden, und leitet den Datenverkehr zwischen Ihren Instanzen wie gewohnt um.

Test auf Zonenfehler

Die Funktionsplattform verwaltet Traffic-Routing, Failover und Zonenwiederherstellung für zonenredundante Ressourcen. Sie brauchen nichts zu initiieren. Azure dieses Feature vollständig verwaltet, sodass Sie keine Fehlerprozesse der Verfügbarkeitszone überprüfen müssen.

Widerstandsfähigkeit bei regionalen Ausfällen

Funktionen ist ein Einzelregionendienst. Wenn die Region nicht verfügbar ist, ist ihre Functions-Ressource ebenfalls nicht verfügbar.

Benutzerdefinierte Lösungen mit mehreren Regionen für Resilienz

Um Unterbrechungen ihres Diensts während regionsweiter Ausfälle zu vermeiden, können Sie die gleichen Funktionen redundant für Funktionen von Apps in mehreren Regionen bereitstellen.

Sie sind dafür verantwortlich:

  • Bereitstellen von Funktions-Apps in mehreren Regionen.

  • Verkehrssteuerung zwischen den Regionen verwalten.

  • Implementieren von Failovermechanismen.

  • Sicherstellen der Datenkonsistenz in allen Regionen (falls zutreffend).

  • Überwachen und Verwalten von regionsübergreifenden Bereitstellungen.

Wenn Sie denselben Funktionscode in mehreren Regionen ausführen, berücksichtigen Sie die active-active und active-passive Muster. In den folgenden Abschnitten werden diese Muster vorgestellt, aber keine detaillierten Anleitungen oder Konfigurationsschritte bereitgestellt.

Aktiv-aktiv-Muster für HTTP-Triggerfunktionen

In einem Aktiv-Aktiv-Muster werden Funktionen in beiden Regionen aktiv ausgeführt und verarbeiten Ereignisse entweder auf doppelte Weise oder im Wechsel. Verwenden Sie ein Aktiv-Aktiv-Muster in Kombination mit Azure Front Door für Ihre kritischen HTTP-ausgelösten Funktionen, die HTTP-Anfragen zwischen Funktionen weiterleiten und im Round-Robin-Verfahren verteilen können, die in mehreren Regionen ausgeführt werden. Azure Front Door kann auch regelmäßig die Integrität jedes Endpunkts überprüfen. Wenn eine Funktion in einer Region nicht mehr auf Gesundheitsprüfungen reagiert, entfernt Azure Front Door sie aus dem Verteilungsprozess und leitet nur den Datenverkehr an die verbleibenden gesunden Funktionen weiter.

Diagramm, das ein Beispiel für eine Aktiv-Aktiv-Architektur zeigt. Azure Front Door routet zwischen Funktionen-Apps in verschiedenen Regionen, die jeweils über eine eigene Datenbank verfügen.

Aktiv-passives Muster für Nicht-HTTP-Triggerfunktionen

Verwenden Sie für ereignisgesteuerte, nicht HTTP ausgelöste Funktionen (z. B. Azure Service Bus und Azure Event Hubs Trigger) ein aktiv-passives Muster. In einem aktiv-passiven Muster werden Funktionsinstanzen in der Region ausgeführt, die Ereignisse empfängt, während die Instanzen im sekundären Bereich im Leerlauf bleiben. Dieses Muster stellt sicher, dass nur eine Funktion jede Nachricht verarbeitet, wodurch die Datenkonsistenz gewährleistet wird. Es bietet auch eine Möglichkeit, während einer Katastrophe, wie z. B. einem Regionalausfall, in die sekundäre Region umzuschalten.

Erwägen Sie das Failover von Funktions-Apps zusammen mit dem Failoververhalten anderer Dienste, die Sie verwenden, z. B.:

Betrachten Sie eine Beispieltopologie, die einen Event Hubs-Trigger verwendet, in der Ihr Event Hubs-Namespace für die Geo-Notfallwiederherstellung konfiguriert ist. In diesem Fall erfordert das aktiv-passive Muster die folgenden Komponenten:

  • Event Hubs-Namespaces, die sowohl in einer primären als auch in einer sekundären Region bereitgestellt werden.

  • Geo-Notfallwiederherstellung aktiviert, um die primären und sekundären Ereignishubs zu koppeln. Mit dieser Konfiguration wird auch ein Alias erstellt, den Sie verwenden können, um eine Verbindung mit dem Event Hubs-Namespace herzustellen und den Alias von der primären zur sekundären zu wechseln, ohne die Verbindungsinformationen zu ändern.

  • Funktions-Apps, die sowohl für die primäre als auch für die sekundäre Region bereitgestellt werden. Die App im sekundären Bereich bleibt im Leerlauf, da sie keine Nachrichten empfängt.

  • Die Trigger jeder Funktions-App verwenden die direct (nonalias) Verbindungszeichenfolge für den jeweiligen Event Hubs-Namespace.

  • Herausgeber im Event Hubs-Namespace veröffentlichen über die Alias-Verbindungszeichenfolge.

Diagramm, das ein Beispiel für eine aktiv-passive Architektur zeigt. Die Geo-Notfallwiederherstellung von Event Hubs umfasst mehrere Regionen und separate Funktions-Apps und Datenbanken in jeder Region.

Vor dem Failover leiten Herausgeber, die Ereignisse an den freigegebenen Alias senden, Datenverkehr an den primären Event Hub weiter. Die primäre Funktions-App lauscht ausschließlich auf den primären Ereignishub. Die sekundäre Funktions-App bleibt passiv und im Leerlauf.

Beim Starten des Failovers werden Herausgeber, die Ereignisse an den freigegebenen Alias senden, an den sekundären Event Hub weitergeleitet. Die sekundäre Funktions-App wird aktiv und wird automatisch ausgelöst. Der Event Hub kann den gesamten Failoverprozess steuern, und jede Funktions-App wird nur ausgeführt, wenn der entsprechende Event Hub aktiv ist.

Dauerhafte Funktionen

Informationen zur Notfallwiederherstellung mit mehreren Regionen für Durable Functions finden Sie unter Disaster Recovery und Geoverteilung in Azure Durable Functions.

Resilienz gegenüber Wartungsarbeiten an Diensten

Funktionen ausführen regelmäßige Dienstupgrades und andere Wartungsaufgaben.

  • Vorübergehende Fehlerresilienz: Während der Dienstwartung können die Instanzen, die Ihre Funktions-App ausführen, neu starten oder vorübergehende Unterbrechungen erleben. Stellen Sie sicher, dass Clientanwendungen, die mit Ihrer Funktions-App interagieren, widerstandsfähig gegen vorübergehende Fehler sind.
  • Zonenredundanz aktivieren: Wenn Sie Zonenredundanz für Ihren Plan aktivieren, verbessern Sie auch die Resilienz während Plattformupdates. Wenn Sie mehrere Instanzen in Ihrem Plan bereitstellen und Zonenredundanz für Ihren Plan aktivieren, wird eine zusätzliche Resilienzebene hinzugefügt, wenn eine Instanz oder eine Zone während eines Upgrades fehlerhaft wird.

  • Zusätzliche temporäre Instanzen: Um ihre erwartete Kapazität während eines Upgrades aufrechtzuerhalten, fügt die Plattform während des Upgradevorgangs automatisch zusätzliche Instanzen des Plans hinzu.

  • Zonenredundanz aktivieren: Wenn Sie Zonenredundanz für Ihren Plan aktivieren, verbessern Sie auch die Resilienz während Plattformupdates. Aktualisierungsdomänen bestehen aus Sammlungen von virtuellen Computern, die während eines Updates offline gehen und sie den Verfügbarkeitszonen zugeordnet sind. Wenn Sie mehrere Instanzen in Ihrem Plan bereitstellen und Zonenredundanz für Ihren Plan aktivieren, wird eine zusätzliche Resilienzebene hinzugefügt, wenn eine Instanz oder eine Zone während eines Upgrades fehlerhaft wird.

  • App-Dienstumgebung: Wenn Sie Ihre Funktions-App in einer App-Dienstumgebung hosten, können Sie den Upgradezyklus anpassen. Wenn Sie die Auswirkungen von Upgrades auf Ihre Workload überprüfen müssen, aktivieren Sie manuelle Upgrades. Verwenden Sie diesen Ansatz, um eine Nichtproduktionsinstanz zu überprüfen und zu testen, bevor Sie die Upgrades auf Ihre Produktionsinstanz anwenden.

    Weitere Informationen zu Wartungseinstellungen finden Sie unter Upgradeeinstellungen für die geplante Wartung der App-Dienstumgebung.

Resilienz gegenüber Anwendungsbereitstellungen

Anwendungsbereitstellungen führen das Risiko von Problemen in einer Produktionsumgebung ein. Seien Sie darauf vorbereitet, ein Update zurückzusetzen, wenn es Probleme verursacht. Steuern Sie, wie Updates bereitgestellt werden, um Unterbrechungen von Anwendungsneustarts zu reduzieren.

Flex-Verbrauchspläne unterstützen Strategien für Websiteupdates, die mehrere Möglichkeiten zum Bereitstellen Ihrer App-Updates bieten. Zu diesen Strategien gehören rollierende Updates für Bereitstellungen ohne Ausfallzeiten.

Bereitstellungsplätze für Funktionen ermöglichen Bereitstellungen ohne Ausfallzeiten Ihrer Funktions-Apps. Verwenden Sie Bereitstellungsplätze, um die Auswirkungen von Bereitstellungen und Konfigurationsänderungen für Ihre Benutzer zu minimieren. Durch die Verwendung von Bereitstellungsplätzen wird auch die Wahrscheinlichkeit reduziert, dass Ihre Anwendung neu gestartet wird. Anwendungsneustarts verursachen vorübergehende Fehler.

Service-Level-Vereinbarung

Der Service level agreement (SLA) für Azure-Dienste beschreibt die erwartete Verfügbarkeit jedes Diensts und die Bedingungen, die Ihre Lösung erfüllen muss, um diese Verfügbarkeitserwartungen zu erreichen. Weitere Informationen finden Sie unter Dienstleistungsvereinbarungen für Onlinedienste.

Funktionen bieten unterschiedliche Verfügbarkeits-SLAs für den Verbrauchsplan und für andere Plantypen.

Verwandte Inhalte

  • Last updated on