Zuverlässigkeit in Azure App Service
In diesem Artikel wird die Zuverlässigkeitsunterstützung in Azure App Service beschrieben, wobei sowohl regionsinterne Resilienz mittels Verfügbarkeitszonen als auch regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität behandelt werden. Eine ausführlichere Übersicht über die Zuverlässigkeitsprinzipien in Azure finden Sie unter Azure-Zuverlässigkeit.
Azure App Service ist ein HTTP-basierter Dienst zum Hosten von Webanwendungen, REST-APIs und mobilen Back-Ends und fügt Ihrer Anwendung die Leistungsfähigkeit von Microsoft Azure hinzu, z. B.:
- Sicherheit
- Lastenausgleich
- Automatische Skalierung
- Automatisierte Verwaltung
Wie Azure App Service die Zuverlässigkeit und Resilienz Ihrer Anwendungsworkload verbessern kann, erfahren Sie unter Gründe für die Verwendung von App Service.
Zuverlässigkeitsempfehlungen
Dieser Abschnitt enthält Empfehlungen für das Erreichen von Resilienz und Verfügbarkeit. Jede Empfehlung fällt in eine von zwei Kategorien:
Integritätselemente umfassen Bereiche wie Konfigurationselemente und die ordnungsgemäße Funktion der Hauptkomponenten, aus denen Ihr Azure-Workload besteht, wie z. B. Konfigurationseinstellungen der Azure-Ressourcen oder Abhängigkeiten von anderen Diensten.
Risikoelemente umfassen Bereiche wie Verfügbarkeits- und Wiederherstellungsanforderungen, Tests, Überwachung, Bereitstellung und andere Elemente, die die Wahrscheinlichkeit von Problemen in der Umgebung erhöhen, wenn sie nicht gelöst werden.
Prioritätsmatrix der Zuverlässigkeitsempfehlungen
Jede Empfehlung wird gemäß der folgenden Prioritätsmatrix gekennzeichnet:
| Image | Priority | BESCHREIBUNG |
|---|---|---|
|
High | Sofortige Korrektur erforderlich. |
|
Mittel | Korrektur innerhalb von 3-6 Monaten. |
|
Niedrig | Muss überprüft werden. |
Zusammenfassung der Zuverlässigkeitsempfehlungen
Hochverfügbarkeit
ASP-1: Bereitstellen zonenredundanter App Service-Pläne
Um die Resilienz und Zuverlässigkeit Ihrer unternehmenskritischen Workloads zu verbessern, wird empfohlen, Dass Sie Ihre neuen App Service Plans mit Zonenredundanz bereitstellen. Befolgen Sie die Schritte, um die Unterstützung für Verfügbarkeitszonen erneut bereitzustellen, konfigurieren Sie Ihre Pipelines so, dass Ihre Web-App im neuen App Service-Plan erneut bereitgestellt wird, und verwenden Sie dann einen Blau-Grün-Bereitstellungsansatz für das Failover auf den neuen Standort.
Indem Sie Ihre Anwendungen auf mehrere Verfügbarkeitszonen verteilen, können Sie die Fortführung des Betriebs auch im Falle eines Ausfalls auf Rechenzentrumsebene sicherstellen. Weitere Informationen zur Unterstützung von Verfügbarkeitszonen in Azure App Service finden Sie unter Unterstützung von Verfügbarkeitszonen.
// Azure Resource Graph Query
// The query filters the qualified App Service Plans that do not have Zone Redundancy enabled.
// Its important to check regions that support availability zones for Azure App Services running on multi-tenant and App Service Environments https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service?tabs=graph%2Ccli#:~:text=The%20following%20regions%20support%20Azure%20App%20Services%20running%20on%20multi%2Dtenant%20environments%3A
resources
| where type =~ 'microsoft.web/serverfarms'
| extend zoneRedundant = tobool(properties.zoneRedundant)
| extend sku_tier = tostring(sku.tier)
| where (tolower(sku_tier) contains "isolated" or tolower(sku_tier) contains "premium") and zoneRedundant == false
| project recommendationid="asp-1", name, id, tags, param1=sku_tier, param2="Not Zone Redundant"
Resilienz
ASP-2: Verwenden eines App Service-Plans, der Verfügbarkeitszonen unterstützt
Verfügbarkeitszonen werden nur in bestimmten App Service Plänen unterstützt. Informationen dazu, welchen Plan Sie für die Verwendung von Verfügbarkeitszonen benötigen, finden Sie unter Voraussetzungen für Verfügbarkeitszonen.
// Azure Resource Graph Query
// Provides a list of Azure App Service Plans that are not in the "Standard", "Premium", or "IsolatedV2" SKU tiers.
resources
| where type =~ 'microsoft.web/serverfarms'
| extend sku_tier = tostring(sku.tier)
| where tolower(sku_tier) !contains "standard" and
tolower(sku_tier) !contains "premium" and
tolower(sku_tier) !contains "isolatedv2"
| project recommendationid="asp-2", name, id, tags, param1= strcat("SKU=",sku_tier)
ASP-4: Erstellen von separaten App Service-Plänen für Produktion und Tests
Um die Resilienz und Zuverlässigkeit Ihrer unternehmenskritischen Workloads zu verbessern, sollten Sie Ihre vorhandenen App Service-Pläne und -Umgebungen migrieren, damit Verfügbarkeitszonen unterstützt werden. Indem Sie Ihre Anwendungen auf mehrere Verfügbarkeitszonen verteilen, können Sie die Fortführung des Betriebs auch im Falle eines Ausfalls auf Rechenzentrumsebene sicherstellen. Weitere Informationen zur Unterstützung von Verfügbarkeitszonen in Azure App Service finden Sie unter Unterstützung von Verfügbarkeitszonen.
Skalierbarkeit
ASP-3: Vermeiden von häufigem Hoch- oder Herunterskalieren
Sie sollten ein häufiges Hoch- oder Herunterskalieren Ihrer Azure App Service-Instanzen vermeiden. Wählen Sie stattdessen einen geeigneten Tarif und eine geeignete Instanzgröße für Ihre typische Workload aus, und skalieren Sie die Instanzen auf, um diese an Änderungen im Datenverkehrsvolumen anzupassen. Das Hoch- oder Herunterskalieren kann möglicherweise einen Anwendungsneustart auslösen, was zu Dienstunterbrechungen führen kann.
ASP-5: Aktivieren der automatischen Skalierung, damit ausreichende Ressourcen für Dienstanforderungen verfügbar sind
Es wird empfohlen, die automatische Skalierung für Ihre Azure App Service-Instanz zu aktivieren, um sicherzustellen, dass genügend Ressourcen für die Verarbeitung eingehender Anforderungen verfügbar sind. Bei der automatischen Skalierung handelt es sich um regelbasierte Skalierung, während die Autoskalierung basierend auf dem HTTP-Datenverkehr eine automatische Ab- und Aufskalierung durchführt. Weitere Informationen finden Sie unter Automatische Skalierung in Azure App Service oder Erste Schritte mit der Autoskalierung in Azure.
// under-development
Unterstützung für Verfügbarkeitszonen
Azure-Verfügbarkeitszonen sind mindestens drei physisch getrennte Gruppen von Rechenzentren innerhalb jeder Azure-Region. Die Rechenzentren innerhalb jeder Zone sind mit unabhängiger Stromversorgung, Kühlung und Netzwerkinfrastruktur ausgestattet. Bei einem Fehler in der lokalen Zone sind Verfügbarkeitszonen so konzipiert, dass regionale Dienste, Kapazität und Hochverfügbarkeit von den verbleibenden beiden Zonen unterstützt werden, wenn eine Zone betroffen ist.
Ausfälle können von Software- und Hardwareausfällen bis hin zu Ereignissen wie Erdbeben, Überflutungen und Bränden reichen. Fehlertoleranz wird durch Redundanz und logische Isolierung von Azure-Diensten erreicht. Ausführlichere Informationen zu Verfügbarkeitszonen in Azure finden Sie unter Regionen und Verfügbarkeitszonen.
Azure-Dienste mit Unterstützung von Verfügbarkeitszonen bieten das richtige Maß an Zuverlässigkeit und Flexibilität. Für die Konfiguration gibt es zwei Möglichkeiten. Sie können entweder zonenredundant mit automatischer zonenübergreifender Replikation oder zonenbasiert mit Instanzen sein, die an eine bestimmte Zone angeheftet werden. Sie können diese Ansätze auch kombinieren. Weitere Informationen zur zonalen im Vergleich zur zonenredundanten Architektur finden Sie unter Empfehlungen für die Verwendung von Verfügbarkeitszonen und Regionen.
Azure App Service kann über Verfügbarkeitszonen hinweg bereitgestellt werden, um Resilienz und Zuverlässigkeit für Ihre unternehmenskritischen Workloads zu erzielen. Diese Architektur wird auch als „Zonenredundanz“ bezeichnet.
Wenn Sie App Service zonenredundant konfigurieren, verteilt die Plattform die Instanzen des Azure App Service-Plans 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 App Service Plan-Instanzen ist drei.
- Wenn Sie eine Kapazität größer als drei angeben und die Anzahl der Instanzen durch drei teilbar ist, werden die Instanzen gleichmäßig verteilt.
- Andere Anzahlen von Instanzen über 3*N hinaus werden auf die verbleibenden ein oder zwei Zonen verteilt.
Unterstützung für Verfügbarkeitszonen ist eine Eigenschaft des App Service-Plans. App Service-Pläne können in einer verwalteten mehrinstanzenfähigen Umgebung oder einer dedizierten Umgebung mithilfe einer App Service-Umgebung der Version 3 erstellt werden. Weitere Informationen zu Version 3 der App Service-Umgebung finden Sie unter Übersicht über die App Service-Umgebung (Version 3).
Für App Services, die nicht zonenredundant konfiguriert sind, sind VM-Instanzen nicht zonenresilient und können während eines Ausfalls in jeder Zone in dieser Region Ausfallzeiten erleiden.
Informationen zur Architektur für Unternehmensbereitstellungen finden Sie unter Hochverfügbare Unternehmensbereitstellung mit der App Service-Umgebung.
Voraussetzungen
Aktuelle Voraussetzungen und Einschränkungen für die Aktivierung von Verfügbarkeitszonen:
Es werden sowohl Windows als auch Linux unterstützt.
Verfügbarkeitszonen werden nur im neueren Teil von App Service unterstützt. Selbst wenn Sie eine der unterstützten Regionen verwenden, erhalten Sie eine Fehlermeldung, wenn Verfügbarkeitszonen für Ihre Ressourcengruppe nicht unterstützt werden. Um sicherzustellen, dass Ihre Workloads bei einem Stempel eingehen, der Verfügbarkeitszonen unterstützt, müssen Sie möglicherweise eine neue Ressourcengruppe, einen App Service-Plan und eine App Service-Instanz erstellen.
Ihr App Services-Plan muss einer der folgenden Pläne sein, die Verfügbarkeitszonen unterstützen:
- In einer mehrinstanzenfähigen Umgebung mit App Service Premium v2- oder Premium v3-Plänen.
- In einer dedizierten Umgebung mit einer App Service-Umgebung v3, die mit isolierten v2-App Service-Plänen verwendet wird.
Für dedizierte Umgebungen muss die App Service-Umgebung der Version 3 verwendet werden.
Wichtig
Die App Service-Umgebung v2 und v1 werden am 31. August 2024 eingestellt. Die App Service-Umgebung v3 ist benutzerfreundlicher und basiert auf einer leistungsfähigeren Infrastruktur. Weitere Informationen zur App Service-Umgebung v3 finden Sie unter Übersicht über die App Service-Umgebung. Wenn Sie derzeit die App Service-Umgebung v2 oder v1 verwenden und Sie ein Upgrade auf v3 durchführen möchten, führen Sie die Schritte in diesem Artikel aus, um zur neuen Version zu migrieren.
Die Mindestanzahl der Instanzen von drei Zonen wird erzwungen. Die Plattform erzwingt diese Mindestanzahl im Hintergrund, wenn Sie eine niedrigere Anzahl der Instanzen als drei angeben.
Verfügbarkeitszonen können nur beim Erstellen eines neuen App Service-Plans angegeben werden. Ein bereits vorhandener App Service-Plan kann nicht so konvertiert werden, dass er Verfügbarkeitszonen verwendet.
Die folgenden Regionen unterstützen Azure App Services, die in mehrinstanzenfähigen Umgebungen ausgeführt werden:
- Australien (Osten)
- Brasilien Süd
- Kanada, Mitte
- Indien, Mitte
- USA (Mitte)
- Asien, Osten
- East US
- USA (Ost) 2
- Frankreich, Mitte
- Deutschland, Westen-Mitte
- Japan, Osten
- Korea, Mitte
- Nordeuropa
- Norwegen, Osten
- Polen, Mitte
- Katar, Mitte
- Südafrika, Norden
- USA Süd Mitte
- Asien, Südosten
- Schweden, Mitte
- Schweiz, Norden
- Vereinigte Arabische Emirate, Norden
- UK, Süden
- Europa, Westen
- USA, Westen 2
- USA, Westen 3
- Microsoft Azure operated by 21Vianet – China, Norden 3
- Azure Government – US Gov Virginia
Informationen dazu, welche Regionen Verfügbarkeitszonen für App Service-Umgebung v3 unterstützen, finden Sie unter Regionen.
Erstellen einer Ressource mit aktivierter Verfügbarkeitszone
Bereitstellen eines zonenredundanten mehrinstanzenfähigen App Service
Um Verfügbarkeitszonen mithilfe der Azure CLI zu aktivieren, schließen Sie den Parameter --zone-redundant ein, wenn Sie Ihren App Service-Plan erstellen. Sie können auch den Parameter --number-of-workers einschließen, um die Kapazität anzugeben. Wenn Sie keine Kapazität angeben, verwendet die Plattform standardmäßig drei. Die Kapazität sollte auf Grundlage der Workloadanforderung festgelegt werden, aber nicht weniger als drei betragen. Eine gute Faustregel für die Auswahl der Kapazität (capacity) ist es, genügend Instanzen für die Anwendung sicherzustellen, sodass beim Verlust einer Zone von Instanzen genügend Kapazität übrig bleibt, um die erwartete Last zu bewältigen.
az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6
Tipp
Um die Instanzkapazität zu bestimmen, können Sie die folgende Berechnung verwenden:
Da die Plattform VMs auf drei Zonen verteilt und Sie mindestens den Ausfall einer Zone abfangen können müssen, multiplizieren Sie die Instanzenanzahl des Spitzenworkloads mit dem Faktor „Zonen/(Zonen-1)“ oder „3/2“. Wenn Ihre typische Spitzenworkload beispielsweise vier Instanzen erfordert, sollten Sie sechs Instanzen bereitstellen: (2/3 * 6 Instanzen) = 4 Instanzen.
Bereitstellen einer zonenredundanten App Service-Instanz mithilfe einer dedizierten Umgebung
Informationen zum Erstellen einer App Service-Umgebung v3 für den isolierten v2-Plan finden Sie unter Erstellen einer App Service-Umgebung.
Problembehandlung
| Fehlermeldung | BESCHREIBUNG | Empfehlung |
|---|---|---|
| Zonenredundanz ist für die Ressourcengruppe „RG-NAME“ nicht verfügbar. Stellen Sie den App Service-Plan „ASP-NAME“ in einer neuen Ressourcengruppe bereit. | Verfügbarkeitszonen werden nur im neueren Teil von App Service unterstützt. Selbst wenn Sie eine der unterstützten Regionen verwenden, erhalten Sie eine Fehlermeldung, wenn Verfügbarkeitszonen für Ihre Ressourcengruppe nicht unterstützt werden. | Um sicherzustellen, dass Ihre Workloads bei einem Stempel eingehen, der Verfügbarkeitszonen unterstützt, erstellen Sie eine neue Ressourcengruppe, einen App Service-Plan und eine App Service-Instanz. |
Fehlertoleranz
Um sich auf ausfallende Verfügbarkeitszonen vorzubereiten, sollten Sie die Kapazität des Diensts überdimensionieren, um sicherzustellen, dass die Lösung einen 1/3-Kapazitätsverlust tolerieren kann und weiterhin ohne Leistungseinbußen bei zonenweiten Ausfällen funktioniert. Da die Plattform VMs auf drei Zonen verteilt und Sie mindestens den Ausfall einer Zone abfangen können müssen, multiplizieren Sie die Instanzenanzahl des Spitzenworkloads mit dem Faktor „Zonen/(Zonen-1)“ oder „3/2“. Wenn Ihre typische Spitzenworkload beispielsweise vier Instanzen erfordert, sollten Sie sechs Instanzen bereitstellen: (2/3 * 6 Instanzen) = 4 Instanzen.
Zonenausfall
Der Datenverkehr wird an alle Ihre verfügbaren App Service-Instanzen geroutet. Wenn eine Zone ausfällt, erkennt die App Service-Plattform verlorene Instanzen und versucht automatisch, neue Ersatzinstanzen zu finden und den Datenverkehr nach Bedarf zu verteilen. Wenn Sie Autoskalierung konfiguriert haben und diese feststellt, dass weitere Instanzen benötigt werden, gibt die Autoskalierung auch eine Anforderung an App Service aus, um weitere Instanzen hinzuzufügen. Beachten Sie, dass das Verhalten der Autoskalierung vom Verhalten der App Service-Plattform unabhängig ist und dass ihre Spezifikation für die Anzahl der Autoskalierungsinstanzen kein Vielfaches von drei sein muss.
Hinweis
Es gibt keine Garantie dafür, dass Anforderungen nach zusätzlichen Instanzen in einem Szenario mit Zonenausfall erfolgreich sind. Die Wiederbesetzung verlorener Instanzen erfolgt nach bestem Bemühen. Die empfohlene Lösung besteht in der Erstellung und Konfiguration Ihrer App Service-Pläne, um den Verlust einer Zone abzufangen, wie im nächsten Abschnitt beschrieben.
Anwendungen, die in einem für Verfügbarkeitszonen aktivierten App Service-Plan bereitgestellt werden, werden weiterhin ausgeführt und bedienen Datenverkehr, auch wenn andere Zonen in derselben Region ausfallen. Es ist jedoch möglich, dass Verhalten außerhalb der Laufzeit, einschließlich Skalieren von App Service-Plänen, Anwendungserstellung, -konfiguration und -veröffentlichung, weiterhin von einem Ausfall in anderen Verfügbarkeitszonen betroffen sind. Zonenredundanz für App Service-Pläne stellt nur eine kontinuierliche Uptime für bereitgestellte Anwendungen sicher.
Wenn die App Service-Plattform einem zonenredundanten App Service-Plan Instanzen zuordnet, verwendet sie einen „Best Effort“-Zonenausgleich, der von den zugrunde liegenden Azure-VM-Skalierungsgruppen angeboten wird. Ein App Service-Plan ist „ausgeglichen“, wenn jede Zone entweder über dieselbe Anzahl von VMs oder +/-1 VM in allen anderen Zonen verfügt, die vom App Service-Plan verwendet werden.
Migration der Verfügbarkeitszone
Sie können vorhandene App Service-Instanzen oder Umgebungsressourcen nicht von fehlender Unterstützung von Verfügbarkeitszonen zur Unterstützung von Verfügbarkeitszonen migrieren. Um Unterstützung für Verfügbarkeitszonen zu erhalten, müssen Sie Ihre Ressourcen mit aktivierten Verfügbarkeitszonen erstellen.
Preise
Mit dem Aktivieren von Verfügbarkeitszonen sind keine zusätzlichen Kosten verbunden. Die Preise für einen zonenredundanten App Service sind identisch mit den Preisen für einen App Service mit einer einzelnen Zone. Die Gebühren werden auf Grundlage Ihrer App Service-Plan-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 angeben, erzwingt die Plattform eine Mindestanzahl von drei Instanzen und berechnet Ihnen diese drei Instanzen. Preisinformationen für App Service-Umgebung v3 finden Sie unter Preise.
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 gängige Strategien für Web-Apps behandelt, die in App Service bereitgestellt werden.
Wenn Sie eine Web-App in App Service erstellen und während der Ressourcenerstellung eine Azure-Region auswählen, handelt es sich um eine App mit einer einzelnen Region. Wenn die Region während eines Notfalls nicht mehr verfügbar ist, ist auch Ihre Anwendung nicht mehr verfügbar. Wenn Sie mithilfe einer Architektur für mehrere geografische Regionen eine identische Bereitstellung in einer sekundären Azure-Region erstellen, ist Ihre Anwendung weniger anfällig bei einem Notfall in einer einzelnen Region. Dadurch wird Geschäftskontinuität gewährleistet. Durch eine Datenreplikation zwischen den Regionen können Sie Ihren letzten Anwendungsstatus wiederherstellen.
In der IT werden Geschäftskontinuitätspläne größtenteils durch RTO (Recovery Time Objective) und RPO (Recovery Point Objective) gesteuert. Weitere Informationen zu RTO und RPO finden Sie unter Wiederherstellungsziele.
Normalerweise ist die Verwaltung einer SLA für RTO für regionale Notfälle unpraktisch, und Sie würden Ihre Notfallwiederherstellungsstrategie in der Regel nur auf RPO festlegen (d. h. konzentrieren Sie sich auf die Wiederherstellung von Daten und nicht auf die Minimierung von Unterbrechungen). Mit Azure ist es jedoch nicht nur praktisch, sondern sogar unkompliziert, App Service für automatische Geofailover bereitzustellen. So können Sie Ihre Anwendungen im Notfall noch besser absichern, indem Sie sowohl für RTO als auch für RPO sorgen.
Je nach Ihren gewünschten RTO- und RPO-Metriken werden sowohl in der mehrinstanzenfähigen Version von App Service als auch in App Service-Umgebungen häufig drei Architekturen für die Notfallwiederherstellung verwendet. Jede dieser Architekturen wird in der folgenden Tabelle beschrieben:
| Metrik | Aktiv/Aktiv | Aktiv-Passiv | Passiv-Kalt |
|---|---|---|---|
| RTO | Echtzeit oder Sekunden | Minuten | Stunden |
| RPO | Echtzeit oder Sekunden | Minuten | Stunden |
| Kosten | $$$ | $$ | $ |
| Szenarien | Unternehmenskritische Apps | Apps mit hoher Priorität | Apps mit niedriger Priorität |
| Möglichkeit zur Bereitstellung von Benutzerdatenverkehr in mehreren Regionen | Ja | Ja/vielleicht | Nein |
| Codebereitstellung | CI/CD-Pipelines bevorzugt | CI/CD-Pipelines bevorzugt | Sichern und Wiederherstellen |
| Erstellen neuer App Service-Ressourcen während einer Ausfallzeit | Nicht erforderlich | Nicht erforderlich | Erforderlich |
Hinweis
Ihre Anwendung hängt wahrscheinlich von anderen Datendiensten in Azure ab, z. B. Azure SQL-Datenbank- und Azure Storage-Konten. Sie sollten auch Strategien für die Notfallwiederherstellung für jeden dieser abhängigen Azure-Dienste entwickeln. Informationen für SQL-Datenbank finden Sie unter Aktive Georeplikation für Azure SQL-Datenbank. Informationen für Azure Storage finden Sie unter Azure Storage-Redundanz.
Notfallwiederherstellung für mehrere Regionen
Es gibt mehrere Möglichkeiten, Inhalte und Konfigurationen Ihrer Web-Apps in Azure-Regionen in einer Aktiv-Aktiv- oder Aktiv-Passiv-Architektur zu replizieren, z. B. die Verwendung von App Service-Sicherung und -Wiederherstellung. Durch Sicherung und Wiederherstellung werden jedoch Zeitpunktmomentaufnahmen erstellt, die schließlich zu Herausforderungen bei der Web-App-Versionsverwaltung in verschiedenen Regionen führen. In der folgenden Tabelle finden Sie einen Vergleich zwischen einem Leitfaden zur Sicherung/Wiederherstellung und einem Leitfaden zur Notfallwiederherstellung:
Sichern und Wiederherstellen im Vergleich zur Notfallwiederherstellung
| Plattform | Leitfaden zum Sichern und Wiederherstellen | Leitfäden zur Notfallwiederherstellung |
|---|---|---|
| App Service-Web-Apps (Tarif „Free“ und „Shared“) |
Wenn Sie Webanwendungen im Tarif „Free“ oder „Shared“ bereitgestellt haben und für diese Web-Apps Zugriff auf die Funktionen zum Sichern und Wiederherstellen benötigen, können Sie auf den Tarif „Basic“ oder höher hochskalieren. | Verschieben von App Service-Apps in eine andere Region Ab dem 31. März 2025 werden App Service-Anwendungen während eines Notfalls in einer Azure-Region nicht in den Notfallwiederherstellungsmodus versetzt, wie im Artikel Verschieben von App Service-Apps in eine andere Region erläutert. Es wird empfohlen, häufig verwendete Methoden zur Notfallwiederherstellung zu implementieren, um Downtime und Datenverluste während eines regionalen Notfalls zu verhindern. |
| App Service-Web-Apps (Tarif „Basic“/„Standard“/„Premium“) |
In Azure App Service können Sie bedarfsgesteuerte benutzerdefinierte Sicherungen erstellen oder automatische Sicherungen verwenden. Sie können eine Sicherung wiederherstellen, indem Sie eine vorhandene App überschreiben und in einer neuen App oder einem neuen Slot wiederherstellen. Weitere Informationen finden Sie unter Sichern und Wiederherstellen Ihrer App in Azure App Service. |
Aktuelle Anleitungen dazu, wie Sie App Service-Ressourcen während eines regionalen Notfalls in einer anderen Azure-Region wieder online schalten, finden Sie unter Verschieben von App Service-Apps in eine andere Region. Ab dem 31. März 2025 werden Azure App Service-Webanwendungen während eines Notfalls in einer Azure-Region nicht mehr in den Notfallwiederherstellungsmodus versetzt, wie im Artikel Verschieben von App Service-Apps in eine andere Region erläutert. Wir empfehlen Ihnen, häufig verwendete Methoden zur Notfallwiederherstellung zu implementieren, um den Verlust von Funktionen oder Daten für Ihre Web-Apps zu verhindern, wenn es zu einem regionalen Notfall kommt. |
| App Service Environment (V2 und V3) | In einer Azure App Service-Umgebung können Sie bedarfsgesteuerte benutzerdefinierte Sicherungen erstellen oder automatische Sicherungen verwenden. Automatische Sicherungen können in einer Ziel-App innerhalb derselben ASE, aber nicht in einer anderen ASE wiederhergestellt werden. Benutzerdefinierte Sicherungen können in einer Ziel-App in einer anderen ASE wiederhergestellt werden (z. B. von einer V2-ASE in einer V3-ASE). Sicherungen können in der Ziel-App derselben Betriebssystemplattform wie der der Quell-App wiederhergestellt werden. Ausführlichere Informationen finden Sie unter Sichern und Wiederherstellen Ihrer App in Azure App Service. |
Wir empfehlen Ihnen, mithilfe von häufig verwendeten Methoden zur Notfallwiederherstellung Richtlinien zur Notfallwiederherstellung für Web-Apps zu implementieren, die in einer App Service-Umgebung bereitgestellt werden. |
| Azure Functions (Dedicated) | In Azure Functions können Sie bedarfsgesteuerte benutzerdefinierte Sicherungen erstellen oder automatische Sicherungen verwenden. Sie können eine Sicherung wiederherstellen, indem Sie eine vorhandene App überschreiben und in einer neuen App oder einem neuen Slot wiederherstellen. Weitere Informationen finden Sie unter Sichern und Wiederherstellen Ihrer App in Azure App Service. |
Aktuelle Anleitungen dazu, wie Sie Azure Functions-Apps (Dedicated) während eines regionalen Notfalls in einer anderen Azure-Region wieder online schalten, finden Sie unter Verschieben von App Service-Apps in eine andere Region. Ab dem 31. März 2025 werden App Service-Anwendungen während eines Notfalls in einer Azure-Region nicht in den Notfallwiederherstellungsmodus versetzt, wie im Artikel Verschieben von App Service-Apps in eine andere Region erläutert. Implementieren Sie stattdessen georedundante Notfallwiederherstellung in Azure Functions. Darüber hinaus finden Sie Informationen im Zusammenhang mit Azure Functions (Dedicated) auch unter Strategien für Geschäftskontinuität und Notfallwiederherstellung in Azure App Service. |
| Azure Functions („Verbrauch“ und „Premium“) | Mit einem Plan vom Typ „Verbrauch“ oder „Premium“ bereitgestellte Azure-Funktionen bieten keinen Zugriff auf benutzerdefinierte und automatische Sicherungen. Der Inhalt der Funktions-App befindet sich in einem Azure-Speicherkonto. Verwenden Sie Optionen für Azure Storage-Redundanz, um sicherzustellen, dass Ihr Speicherkonto während eines Ausfalls die Verfügbarkeits- und Dauerhaftigkeitsziele erfüllt. Wenn Sie Ihre Funktionen mithilfe des Editors im Azure-Portal erstellt haben, können Sie auch Ihr vorhandenes Funktions-App-Projekt als ZIP-Datei herunterladen. |
Wir empfehlen Ihnen dringend, georedundante Notfallwiederherstellung und Zuverlässigkeit in Azure Functions zu implementieren. |
Um die Einschränkungen der Sicherungs- und Wiederherstellungsmethoden zu vermeiden, konfigurieren Sie Ihre CI/CD-Pipelines, um Code in beiden Azure-Regionen bereitzustellen. Erwägen Sie die Verwendung von Azure Pipelines oder GitHub Actions. Weitere Informationen finden Sie unter Continuous Deployment in Azure App Service.
Erkennung, Benachrichtigung und Verwaltung von Ausfällen
Es wird empfohlen, Überwachung und Warnungen für Ihre Web-Apps einzurichten, um während eines Notfalls zeitnahe Benachrichtigungen zu erhalten. Weitere Informationen finden Sie unter Application Insights-Verfügbarkeitstests.
Verwenden Sie einen IaC-Mechanismus (Infrastructure-as-Code), um Ihre Anwendungsressourcen in Azure zu verwalten. In einer komplexen Bereitstellung über mehrere Regionen hinweg ist ein vorhersagbarer, testbarer und wiederholbarer Prozess erforderlich, um die Regionen unabhängig zu verwalten und die Konfiguration regionsübergreifend zuverlässig zu synchronisieren. Ziehen Sie ein IaC-Tool wie Azure Resource Manager-Vorlagen oder Terraform in Betracht.
Einrichten der Notfallwiederherstellung und Ausfallerkennung
Um die Notfallwiederherstellung in einer Geografie mit mehreren Regionen vorzubereiten, können Sie entweder eine Aktiv-Aktiv- oder eine Aktiv-Passiv-Architektur verwenden.
Aktiv/Aktiv-Architektur
Bei einer Aktiv-Aktiv-Architektur für die Notfallwiederherstellung werden identische Web-Apps in zwei separaten Regionen bereitgestellt, und Datenverkehr wird mit Azure Front Door an beide aktiven Regionen weitergeleitet.
Mit dieser Beispielarchitektur:
- Identische App Service-Apps werden in zwei separaten Regionen bereitgestellt, einschließlich Tarif und Anzahl der Instanzen.
- Öffentlicher Datenverkehr direkt an die App Service-Apps wird blockiert.
- Datenverkehr wird mit Azure Front Door an beide aktive Regionen weitergeleitet.
- Während eines Notfalls geht eine der Regionen offline, und Azure Front Door leitet den Datenverkehr ausschließlich an die Region weiter, die online bleibt. Die RTO während eines solchen Geofailovers ist nahezu null.
- Anwendungsdateien sollten in beiden Web-Apps mit einer CI/CD-Lösung bereitgestellt werden. Dadurch wird sichergestellt, dass die RPO praktisch null ist.
- Wenn Ihre Anwendung das Dateisystem aktiv ändert, besteht die beste Möglichkeit zum Minimieren von RPO darin, nur in eine eingebundene Azure Storage-Freigabe zu schreiben, anstatt direkt in die /home-Inhaltsfreigabe der Web-App zu schreiben. Verwenden Sie dann die Redundanzfeatures von Azure Storage (GZRS oder GRS) für Ihre bereitgestellte Freigabe, die über eine RPO von etwa 15 Minuten verfügt.
Die Schritte zum Erstellen einer Aktiv/Aktiv-Architektur für Ihre Web-App in App Service werden wie folgt zusammengefasst:
Erstellen Sie zwei App Service-Pläne in zwei verschiedenen Azure-Regionen. Konfigurieren Sie die beiden App Service-Pläne identisch.
Erstellen Sie zwei Instanzen Ihrer Web-App, wobei eine in jedem App Service-Plan enthalten ist.
Erstellen Sie ein Azure Front Door-Profil mit:
- Ein Endpunkt.
- Zwei Ursprungsgruppen mit jeweils einer Priorität von 1. Die gleiche Priorität weist Azure Front Door an, Datenverkehr gleichmäßig an beide Regionen weiterzuleiten (also aktiv/aktiv).
- Einer Route.
Beschränken Sie den Netzwerkdatenverkehr aus der Azure Front Door-Instanz nur auf die Web-Apps.
Richten Sie alle anderen Azure-Back-End-Dienste ein, z. B. Datenbanken, Speicherkonten und Authentifizierungsanbieter.
Stellen Sie Code für beide Web-Apps mit Continuous Deployment bereit.
In Tutorial: Erstellen einer hochverfügbaren App mit mehreren Regionen in Azure App Service wird das Einrichten einer Aktiv/Passiv-Architektur gezeigt. Mit den gleichen Schritten mit minimalen Änderungen (Festlegen der Priorität auf „1“ für beide Ursprünge in den Ursprungsgruppen in Azure Front Door) erhalten Sie eine Aktiv/Aktiv-Architektur.
Aktiv/Passiv-Architektur
Bei diesem Ansatz für die Notfallwiederherstellung werden identische Web-Apps in zwei separaten Regionen bereitgestellt, und Datenverkehr wird mit Azure Front Door an nru eine Region (die aktive Region) weitergeleitet.
Mit dieser Beispielarchitektur:
Identische App Service-Apps werden in zwei separaten Regionen bereitgestellt.
Öffentlicher Datenverkehr direkt an die App Service-Apps wird blockiert.
Azure Front Door wird verwendet, um Datenverkehr an die primäre Region weiterzuleiten.
Um Kosten zu sparen, ist der sekundäre App Service-Plan so konfiguriert, dass er weniger Instanzen enthält und/oder einen niedrigeren Tarif aufweist. Es gibt drei mögliche Ansätze:
Bevorzugt: Der sekundäre App Service-Plan hat den gleichen Tarif wie der primäre Tarif mit der gleichen Anzahl von Instanzen oder weniger. Dieser Ansatz gewährleistet die Parität bei der Feature- und VM-Größenanpassung für die beiden App Service-Pläne. Die RTO während eines Geofailovers hängt nur von der Zeit ab, in der die Instanzen aufskaliert werden.
Weniger bevorzugt: Der sekundäre App Service-Plan hat den gleichen Tariftyp (z. B. PremiumV3), aber eine kleinere VM-Größe mit weniger Instanzen. Beispielsweise kann sich die primäre Region im P3V3-Tarif befinden, während sich die sekundäre Region im P1V3-Tarif befindet. Dieser Ansatz gewährleistet weiterhin die Featureparität für die beiden App Service-Pläne, aber die fehlende Größenparität erfordert möglicherweise ein manuelles Hochskalieren, wenn die sekundäre Region zur aktiven Region wird. Die RTO während eines Geofailovers hängt von der Zeit ab, in der die Instanzen hoch- und aufskaliert werden.
Am wenigsten bevorzugt: Der sekundäre App Service-Plan hat einen anderen Tarif als der primärer und weniger Instanzen. Beispielsweise kann sich die primäre Region im P3V3-Tarif befinden, während sich die sekundäre Region im S1-Tarif befindet. Stellen Sie sicher, dass der sekundäre App Service-Plan alle Features enthält, die Ihre Anwendung für die Ausführung benötigt. Unterschiede in der Verfügbarkeit von Features zwischen den beiden Plänen können zu Verzögerungen bei der Wiederherstellung Ihrer Web-App führen. Die RTO während eines Geofailovers hängt von der Zeit ab, in der die Instanzen hoch- und aufskaliert werden.
Die Autoskalierung wird für die sekundäre Region konfiguriert, wenn die aktive Region inaktiv wird. Es ist ratsam, ähnliche Regeln für die Autoskalierung sowohl in aktiven als auch in passiven Regionen zu verwenden.
Während eines Notfalls wird die primäre Region inaktiv, und die sekundäre Region empfängt Datenverkehr und wird zur aktiven Region.
Sobald die sekundäre Region aktiv wird, löst die Netzwerkauslastung vorkonfigurierte Regeln für die automatische Skalierung aus, um die sekundäre Web-App aufskalieren zu können.
Möglicherweise müssen Sie den Tarif für die sekundäre Region manuell hochskalieren, wenn diese noch nicht über die erforderlichen Features verfügt, um als aktive Region ausgeführt zu werden. Für die automatische Skalierung ist beispielsweise die Standardebene oder höher erforderlich.
Wenn die primäre Region wieder aktiv ist, leitet Azure Front Door den Datenverkehr automatisch zurück, und die Architektur ist wie zuvor wieder aktiv/passiv.
Anwendungsdateien sollten in beiden Web-Apps mit einer CI/CD-Lösung bereitgestellt werden. Dadurch wird sichergestellt, dass die RPO praktisch null ist.
Wenn Ihre Anwendung das Dateisystem aktiv ändert, besteht die beste Möglichkeit zum Minimieren von RPO darin, nur in eine eingebundene Azure Storage-Freigabe zu schreiben, anstatt direkt in die /home-Inhaltsfreigabe der Web-App zu schreiben. Verwenden Sie dann die Redundanzfeatures von Azure Storage (GZRS oder GRS) für Ihre bereitgestellte Freigabe, die über eine RPO von etwa 15 Minuten verfügt.
Die Schritte zum Erstellen einer Aktiv/Passiv-Architektur für Ihre Web-App in App Service werden wie folgt zusammengefasst:
- Erstellen Sie zwei App Service-Pläne in zwei verschiedenen Azure-Regionen. Der sekundäre App Service-Plan kann mithilfe eines der zuvor genannten Ansätze bereitgestellt werden.
- Konfigurieren Sie Regeln für die automatische Skalierung für den sekundären App Service-Plan, damit er auf die gleiche Instanzanzahl wie der primäre Plan skaliert wird, wenn die primäre Region inaktiv wird.
- Erstellen Sie zwei Instanzen Ihrer Web-App, wobei eine in jedem App Service-Plan enthalten ist.
- Erstellen Sie ein Azure Front Door-Profil mit:
- Ein Endpunkt.
- Einer Ursprungsgruppe mit der Priorität 1 für die primäre Region.
- Einer zweiten Ursprungsgruppe mit einer Priorität von 2 für die sekundäre Region. Der Unterschied in der Priorität weist Azure Front Door an, die primäre Region zu bevorzugen, wenn sie online ist (also aktiv-passiv).
- Einer Route.
- Beschränken Sie den Netzwerkdatenverkehr aus der Azure Front Door-Instanz nur auf die Web-Apps.
- Richten Sie alle anderen Azure-Back-End-Dienste ein, z. B. Datenbanken, Speicherkonten und Authentifizierungsanbieter.
- Stellen Sie Code für beide Web-Apps mit Continuous Deployment bereit.
In Tutorial: Erstellen einer hochverfügbaren App mit mehreren Regionen in Azure App Service wird das Einrichten einer Aktiv/Passiv-Architektur gezeigt.
Passiv-Kalt-Architektur
Verwenden Sie eine Passiv-Kalt-Architektur, um regelmäßige Sicherungen Ihrer Web-Apps in einem Azure Storage-Konto zu erstellen und zu verwalten, das sich in einer anderen Region befindet.
Mit dieser Beispielarchitektur:
Eine einzelne Web-App wird in einer einzelnen Region bereitgestellt.
Die Web-App wird regelmäßig in einem Azure Storage-Konto in derselben Region gesichert.
Die regionsübergreifende Replikation Ihrer Sicherungen hängt von der Konfiguration der Datenredundanz im Azure-Speicherkonto ab. Sie sollten Ihr Azure Storage-Konto nach Möglichkeit auf GZRS festlegen. GZRS bietet sowohl synchrone Zonenredundanz innerhalb einer Region als auch asynchrone Zonenredundanz in einer sekundären Region. Wenn GZRS nicht verfügbar ist, konfigurieren Sie das Konto als GRS. Sowohl GZRS als auch GRS haben eine RPO von etwa 15 Minuten.
Um sicherzustellen, dass Sie Sicherungen abrufen können, wenn die primäre Region des Speicherkontos nicht mehr verfügbar ist, aktivieren Sie den schreibgeschützten Zugriff auf die sekundäre Region (sodass das Speicherkonto RA-GZRS bzw. RA-GRS ist). Weitere Informationen zum Entwerfen Ihrer Anwendungen für die Nutzung von Georedundanz finden Sie unter Verwenden von Georedundanz zum Entwerfen von hoch verfügbaren Anwendungen.
Während eines Notfalls in der Region der Web-App müssen Sie alle erforderlichen, von App Service abhängigen Ressourcen manuell bereitstellen, indem Sie die Sicherungen aus dem Azure Storage-Konto verwenden, höchstwahrscheinlich aus der sekundären Region mit Lesezugriff. Die RTO kann Stunden oder Tage betragen.
Um RTO zu minimieren, wird dringend empfohlen, über ein umfassendes Playbook zu verfügen, in dem alle Schritte beschrieben werden, die zum Wiederherstellen der Sicherung Ihrer Web-App in einer anderen Azure-Region erforderlich sind.
Die Schritte zum Erstellen einer Passiv/Kalt-Region für Ihre Web-App in App Service werden wie folgt zusammengefasst:
Erstellen Sie ein Azure-Speicherkonto in derselben Region wie Ihre Web-App. Wählen Sie die Leistungsstufe „Standard“, und wählen Sie als Redundanz „Geo-Redundanter Speicher (GRS)“ oder „Geozonenredundanter Speicher (GZRS)“ aus.
Aktivieren Sie RA-GRS oder RA-GZRS (Lesezugriff für die sekundäre Region).
Konfigurieren Sie die benutzerdefinierte Sicherung für Ihre Web-App. Sie können einen Zeitplan für Ihre Web-App-Sicherungen festlegen, z. B. stündlich.
Stellen Sie sicher, dass die Web-App-Sicherungsdateien in der sekundären Region Ihres Speicherkontos abgerufen werden können.
Tipp
Neben Azure Front Door bietet Azure weitere Optionen für den Lastenausgleich, z. B. Azure Traffic Manager. Einen Vergleich der verschiedenen Optionen finden Sie unter Optionen für den Lastenausgleich – Azure Architecture Center.
Notfallwiederherstellung für eine Region
Wenn die Region Ihrer Web-App keinen GZRS- oder GRS-Speicher aufweist oder wenn Sie sich in einer Azure-Region befinden, die nicht zu einem Regionenpaar gehört, müssen Sie zonenredundanten Speicher (ZRS) oder lokal redundanten Speicher (LRS) verwenden, um eine ähnliche Architektur zu erstellen. Beispielsweise können Sie eine sekundäre Region für das Speicherkonto wie folgt manuell erstellen:
Die Schritte zum Erstellen einer Passiv/Kalt-Region ohne GRS und GZRS werden wie folgt zusammengefasst:
Erstellen Sie ein Azure-Speicherkonto in derselben Region wie Ihre Web-App. Wählen Sie die Leistungsstufe „Standard“, und wählen Sie als Redundanz „Zonenredundanter Speicher (ZRS)“ aus.
Konfigurieren Sie die benutzerdefinierte Sicherung für Ihre Web-App. Sie können einen Zeitplan für Ihre Web-App-Sicherungen festlegen, z. B. stündlich.
Stellen Sie sicher, dass die Web-App-Sicherungsdateien in der sekundären Region Ihres Speicherkontos abgerufen werden können.
Erstellen Sie ein zweites Azure-Speicherkonto in einer anderen Region. Wählen Sie die Leistungsstufe „Standard“, und wählen Sie als Redundanz „Lokal redundanter Speicher (LRS)“ aus.
Replizieren Sie mithilfe eines Tools wie AzCopy Ihre benutzerdefinierte Sicherung (ZIP-, XML- und Protokolldateien) aus der primären Region in den sekundären Speicher. Zum Beispiel:
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'Sie können Azure Automation mit einem PowerShell-Workflow-Runbook verwenden, um Ihr Replikationsskript nach einem Zeitplan auszuführen. Stellen Sie sicher, dass der Replikationszeitplan einem ähnlichen Zeitplan folgt wie die Web-App-Sicherungen.