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 Unterstützung von Verfügbarkeitszonen für Azure Functions ist sowohl in Premium- (Elastic Premium) als auch Dedizierten Plänen (App Service) verfügbar. In diesem Artikel geht es um die Unterstützung der Zonenredundanz für Premium-Pläne. Informationen zur Zonenredundanz für dedizierte Pläne finden Sie unter Migrieren von App Service zur Unterstützung von Verfügbarkeitszonen.
Unterstützung für 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.
Weitere Informationen zu Verfügbarkeitszonen in Azure finden Sie unter Was sind Verfügbarkeitszonen?.
Azure Functions unterstützt eine zonenredundante Bereitstellung.
Wenn Sie Functions zonenredundant konfigurieren, verteilt die Plattform die Instanzen der Funktions-App automatisch auf drei 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 drei.
- Wenn Sie eine Kapazität angeben, die größer als drei ist, werden die Instanzen gleichmäßig verteilt, wenn die Kapazität ein Vielfaches von 3 ist.
- Bei einem Kapazitätswert von mehr als 3*N werden zusätzliche Instanzen über die verbleibenden ein oder zwei Zonen verteilt.
Wichtig
Azure Functions kann auf der Azure App Service-Plattform ausgeführt werden. Auf der App Service-Plattform werden Pläne, die Premium-Pläne für Funktions-Apps hosten, als Elastic Premium-Pläne mit SKU-Namen wie EP1 bezeichnet. Wenn Sie Ihre Funktions-App in einem Premium-Plan ausführen möchten, stellen Sie sicher, dass Sie einen Plan mit einem SKU-Namen erstellen, der mit einem „E“ beginnt, z. B. EP1. SKU-Namen von App Service-Plänen, die mit einem „P“ beginnen, z. B. P1V2 (kleiner Premium V2-Plan), sind tatsächlich Dedizierte Hostingpläne. Da es sich um dedizierte Tarife und nicht um Elastic Premium Tarife handelt, werden Tarife mit SKU-Namen, die mit einem „P“ beginnen, nicht dynamisch skaliert und möglicherweise ihre Kosten erhöhen.
Regionale Verfügbarkeit
Zonenredundante Premium-Pläne sind in den folgenden Regionen verfügbar:
| Amerika | Europa | Naher Osten | Afrika | Asien-Pazifik |
|---|---|---|---|---|
| Brasilien Süd | Frankreich, Mitte | Israel, Mitte | Südafrika, Norden | Australien (Osten) |
| Kanada, Mitte | Deutschland, Westen-Mitte | Katar, Mitte | Indien, Mitte | |
| USA (Mitte) | Italien, Norden | Vereinigte Arabische Emirate, Norden | China, Norden 3 | |
| East US | 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
Unterstützung für Verfügbarkeitszonen ist eine Eigenschaft des Premium-Plans. Im Folgenden finden Sie die aktuellen Anforderungen/Einschränkungen zum Aktivieren von Verfügbarkeitszonen:
- Sie können Verfügbarkeitszonen nur aktivieren, wenn Sie einen Premium-Plan für Ihre Funktions-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 Speicherkonto Ihrer Funktions-App verwenden. Wenn Sie einen anderen Speicherkontotyp verwenden, kann es bei einem Zonenausfall in Functions zu unerwartetem Verhalten kommen.
- Es werden sowohl Windows als auch Linux unterstützt.
- Muss auf einem elastischen Premium- oder dedizierten Hosting-Plan gehostet werden. Informationen zum Verwenden von Zonenredundanz mit einem dedizierten Plan finden Sie unter Migrieren von App Service zu Verfügbarkeitszonenunterstützung.
- Verfügbarkeitszonenunterstützung ist derzeit nicht für Funktions-Apps in Verbrauchsplänen verfügbar.
- In einem Premium-Plan gehostete Funktions-Apps müssen zusätzlich eine Mindestanzahl von drei jederzeit bereiten Instanzen aufweisen.
- Die Plattform erzwingt diese Mindestanzahl im Hintergrund, wenn Sie eine Instanzanzahl von weniger als drei 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.
Preisberechnung
Mit dem Aktivieren von Verfügbarkeitszonen sind keine zusätzlichen Kosten verbunden. Die Preise für einen zonenredundanten Premium App Service-Plan sind dieselben wie für einem Premium-Plan für eine einzelne Zone. 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 aktivieren, aber eine kleinere Kapazität als drei für einen App Service-Plan angeben, erzwingt die Plattform eine Mindestanzahl von drei Instanzen und berechnet Ihnen diese drei Instanzen.
Erstellen eines zonenredundanten Premium-Plans und einer Funktions-App
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.
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.
Wählen Sie Functions Premium und dann die Schaltfläche Auswählen aus. 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.
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, unter der die neue Funktions-App erstellt wird. Sie müssen eine Region auswählen, die Verfügbarkeitszonen unterstützt. Siehe die Liste der regionalen Verfügbarkeit Tarif 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 Enablednur auswählen, wenn Sie eine Region ausgewählt haben, die Zonenredundanz unterstützt, wie zuvor beschrieben.
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. 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
Azure-Funktions-Apps unterstützt derzeit keine direkte Migration vorhandener Funktions-Apps-Instanzen. Informationen zum Migrieren des öffentlichen Premium-Plans für mehrere Mandanten aus der Nichtverfügbarkeitszone zu Verfügbarkeitszonenunterstützung finden Sie unter Migrieren von App Service zu Verfügbarkeitszonenunterstützung.
Zonenausfall
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 auf „Best Effort“-Basis 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 gilt als ausgeglichen, wenn jede Zone die gleiche Anzahl von VMs (± 1 VM) in allen anderen Zonen aufweist, die vom Premium-Plan verwendet werden.
Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität
Bei der Notfallwiederherstellung (DR) geht es um die Wiederherstellung nach Ereignissen mit schwerwiegenden Auswirkungen, z. B. Naturkatastrophen oder fehlerhaften Bereitstellungen, die zu Downtime und Datenverlust führen. Unabhängig von der Ursache ist das beste Mittel gegen einen Notfall ein gut definierter und getesteter Notfallplan und ein Anwendungsdesign, die Notfallwiederherstellung aktiv unterstützt. Bevor Sie mit der Erstellung Ihres Notfallwiederherstellungsplans beginnen, lesen Sie die Empfehlungen zum Entwerfen einer Notfallwiederherstellungsstrategie.
Bei DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In einem Modell der gemeinsamen Verantwortung stellt Microsoft sicher, dass die grundlegenden Infrastruktur- und Plattformdienste verfügbar sind. Gleichzeitig replizieren viele Azure-Dienste nicht automatisch Daten oder greifen automatisch auf eine ausgefallene Region zurück, um eine regionsübergreifende Replikation in eine andere aktivierte Region durchzuführen. Für diese Dienste sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die auf Azure Platform as a Service (PaaS)-Angeboten laufen, bieten Funktionen und Anleitungen zur Unterstützung von Notfallwiederherstellung und Sie können dienstspezifische Funktionen zur Unterstützung einer schnellen Wiederherstellung nutzen, um Ihren Notfallwiederherstellungsplan zu entwickeln.
In diesem Abschnitt werden einige der Strategien erläutert, mit denen Sie Funktionen für die Notfallwiederherstellung bereitstellen können.
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 den Einsatz 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. Es wird empfohlen, ein Aktiv-aktiv-Muster in Kombination mit Azure Front Door für Ihre kritischen, von HTTP ausgelösten Funktionen zu verwenden, das HTTP-Anfragen zwischen Funktionen, die in mehreren Regionen laufen, weiterleiten und umleiten 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.
Ein Beispiel finden Sie im Beispiel, wie Sie das Geode-Muster implementieren, indem Sie die API für Geoden in verteilten Azure-Regionen bereitstellen..
Wichtig
Es wird jedoch dringend empfohlen, das Aktiv-passiv-Muster für Nicht-HTTPS-Triggerfunktionen zu verwenden. Für Funktionen, die nicht über HTTP ausgelöst werden, können Sie Aktiv-aktiv-Bereitstellungen erstellen. Sie müssen jedoch berücksichtigen, wie die beiden aktiven Regionen miteinander interagieren oder koordiniert werden. Wenn Sie dieselbe Funktionsanwendung in zwei Regionen bereitstellen, die jeweils auf dieselbe Service-Bus-Warteschlange zugreifen, würden sie als konkurrierende Verbraucher beim Abbau dieser Warteschlange agieren. Dies bedeutet zwar, dass jede Nachricht nur von einer der beiden Instanzen verarbeitet wird, aber auch, dass es immer noch einen Single Point of Failure in der einzelnen Service Bus-Instanz gibt.
Sie könnten stattdessen zwei Service-Bus-Warteschlangen einrichten, eine in einer primären Region und eine in einer sekundären Region. 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.
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 triggert auf die direkte (Nicht-Alias-)Verbindungszeichenfolge für ihren jeweiligen Event Hub.
- Verleger für den Event Hub sollten ihre Veröffentlichungen über die Aliasverbindungszeichenfolge ausführen.
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.