Hochverfügbare Unternehmensbereitstellung über eine App Service-Umgebung

Verfügbarkeitszonen sind physisch getrennte Sammlungen von Rechenzentren in einer bestimmten Region. Durch die zonenübergreifende Bereitstellung von Ressourcen wird sichergestellt, dass sich Ausfälle, die auf eine Zone beschränkt sind, nicht auf die Verfügbarkeit Ihrer Anwendungen auswirken. Diese Architektur zeigt, wie Sie die Resilienz einer Bereitstellung von App Service-Umgebung verbessern können, indem Sie diese in einer zonenredundanten Architektur bereitstellen. Diese Zonen hängen nicht mit der Nähe zusammen. Sie können verschiedenen physischen Standorten für verschiedene Abonnements zugeordnet sein. Die Architektur geht von einer Bereitstellung mit einem einzelnen Abonnement aus.

Wenn Sie App Service-Umgebung zonenredundant konfigurieren, stellt die Plattform die Instanzen des Azure App Service-Plans automatisch in drei Zonen in der ausgewählten Region bereit. Daher beträgt die Mindestanzahl der Instanzen des App Service-Plans immer drei.

Azure-Dienste, die Verfügbarkeitszonen unterstützen, können zonal, zonenredundant oder beides sein. Zonale Dienste können in einer bestimmte Zone bereitgestellt werden. Zonenredundante Dienste können automatisch zonenübergreifend bereitgestellt werden. Detaillierte Anleitungen und Empfehlungen finden Sie unter Unterstützung von Verfügbarkeitszonen. Die vorherige Version von App Service-Umgebung (v2) hat nur zonale Bereitstellungen unterstützt, aber die aktuelle Version (v3) unterstützt zonenredundante Bereitstellungen.

Eine Referenzimplementierung dieser Architektur ist auf GitHub verfügbar.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Die Ressourcen in den Subnetzen von App Service-Umgebung in dieser Referenzimplementierung sind identisch mit denen in der Standardbereitstellungsarchitektur von App Service-Umgebung. Diese Referenzimplementierung verwendet die zonenredundanten Funktionalitäten von App Service-Umgebung v3 und Azure Cache for Redis, um eine höhere Verfügbarkeit bereitzustellen. Beachten Sie, dass diese Referenzarchitektur auf eine einzelne Region beschränkt ist.

Workflow

Dieser Abschnitt beschreibt die Art der Verfügbarkeit für in dieser Architektur verwendete Dienste:

• App Service-Umgebung v3 kann für Zonenredundanz konfiguriert werden. Sie können Zonenredundanz nur während der Erstellung von App Service-Umgebung und nur in Regionen konfigurieren, die alle Abhängigkeiten von App Service-Umgebung v3 unterstützen. Jeder App Service-Plan in einer zonenredundanten App Service-Umgebung muss mindestens drei Instanzen aufweisen, damit sie in drei Zonen bereitgestellt werden können. Die Mindestgebühr gilt für neun Instanzen. Weitere Informationen hierzu finden Sie in diesem Preisleitfaden. Detaillierte Anleitungen und Empfehlungen finden Sie unter Unterstützung von App Service-Umgebung für Verfügbarkeitszonen.

• Azure Virtual Network umfasst alle Verfügbarkeitszonen, die sich in einer einzelnen Region befinden. Die Subnetze im virtuellen Netzwerk sind auch über Verfügbarkeitszonen hinweg verfügbar. Weitere Informationen finden Sie in den Netzwerkanforderungen für App Service-Umgebung.

• Application Gateway v2 ist zonenredundant. Es deckt ebenso wie das virtuelle Netzwerk mehrere Verfügbarkeitszonen pro Region ab. Daher ist ein einzelnes Anwendungsgateway für ein hochverfügbares System ausreichend, wie in dieser Referenzarchitektur gezeigt. Die Referenzarchitektur verwendet die WAF-SKU von Application Gateway, die basierend auf einer Implementierung des Core Rule Set (CRS) des Open Web Application Security Project (OWASP) einen erhöhten Schutz vor gängigen Bedrohungen und Sicherheitsrisiken bietet. Weitere Informationen finden Sie unter Skalierung von Application Gateway v2 und WAF v2.

• In Azure Firewall ist die Unterstützung für Hochverfügbarkeit bereits integriert. Sie kann ohne zusätzliche Konfiguration mehrere Zonen umfassen.

  Bei Bedarf können Sie auch eine bestimmte Verfügbarkeitszone konfigurieren, wenn Sie die Firewall bereitstellen. Weitere Informationen finden Sie unter Azure Firewall und Verfügbarkeitszonen. (Diese Konfiguration wird in der Referenzarchitektur nicht verwendet.)

• Microsoft Entra ID ist ein hochverfügbarer, hochredundanter globaler Dienst, der mehrere Verfügbarkeitszonen und Regionen umfasst. Weitere Informationen finden Sie unter Erweiterte Verfügbarkeit von Microsoft Entra.

• GitHub Actions bietet Funktionalitäten für Continuous Integration und Continuous Deployment (CI/CD) für diese Architektur. Da sich App Service-Umgebung im virtuellen Netzwerk befindet, wird eine VM als Jumpbox im virtuellen Netzwerk verwendet, um Apps in den App Service-Plänen bereitzustellen. Die Aktion erstellt die Apps außerhalb des virtuellen Netzwerks. Erwägen Sie für verbesserte Sicherheit und nahtlose RDP/SSH-Konnektivität die Verwendung von Azure Bastion für die Jumpbox.

• Azure Cache for Redis ist ein zonenredundanter Dienst. Ein zonenredundanter Cache wird auf VMs ausgeführt, die über mehrere Verfügbarkeitszonen hinweg bereitgestellt sind. Dieser Dienst bietet höhere Resilienz und Verfügbarkeit.

Überlegungen

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Verfügbarkeit

App Service-Umgebung

Sie können App Service-Umgebung über Verfügbarkeitszonen hinweg bereitstellen, um Resilienz und Zuverlässigkeit für Ihre unternehmenskritischen Workloads zu gewährleisten. Diese Konfiguration ist auch als Zonenredundanz bekannt.

Wenn Sie die Zonenredundanz implementieren, verteilt die Plattform die Instanzen des App Service-Plans automatisch auf drei Zonen in der ausgewählten Region. Daher beträgt die Mindestanzahl der Instanzen des App Service-Plans immer 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 bereitgestellt. Andernfalls werden alle verbleibenden Instanzen der verbleibenden Zone hinzugefügt oder in den verbleibenden zwei Zonen bereitgestellt.

• Sie konfigurieren Verfügbarkeitszonen, wenn Sie Ihre App Service-Umgebung erstellen.
• Alle App Service-Pläne, die in dieser App Service-Umgebung erstellt werden, erfordern mindestens drei Instanzen. Sie werden automatisch zonenredundant sein.
• Sie können Verfügbarkeitszonen nur angeben, wenn Sie eine neue App Service-Umgebung erstellen. Sie können eine bereits vorhandene App Service-Umgebung nicht für die Verwendung von Verfügbarkeitszonen konvertieren.
• Verfügbarkeitszonen werden nur in einer Teilmenge der Regionen unterstützt.

Weitere Informationen finden Sie unter Migrieren der App Service-Umgebung zu Verfügbarkeitszonenunterstützung.

Resilienz

Die Anwendungen, die in App Service-Umgebung ausgeführt werden, bilden den Back-End-Pool für Application Gateway. Wenn eine Anforderung an die Anwendung aus dem öffentlichen Internet erfolgt, leitet das Gateway die Anforderung an die Anwendung weiter, die in App Service-Umgebung ausgeführt wird. Diese Referenzarchitektur implementiert Integritätsprüfungen im Haupt-Web-Front-End votingApp. Dieser Integritätstest überprüft, ob die Web-API und der Redis-Cache fehlerfrei sind. Sie können den Code, der diesen Test implementiert, in Startup.cs sehen:

            var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionStrings:VotingDataAPIBaseUri"))
            {
                Path = "/health"
            };

            services.AddHealthChecks()
                .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
                .AddRedis(Configuration.GetValue<string>("ConnectionStrings:RedisConnectionString"));

Der folgende Code zeigt, wie das Skript commands_ha.azcli die Back-End-Pools und den Integritätstest für das Anwendungsgateway konfiguriert:

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "certificate": {
      "data": "${CERT_DATA_1}",
      "password": "${PFX_PASSWORD}"
    },
    "probePath": "/health"
  }
]

Wenn eine der Komponenten (das Web-Front-End, die API oder der Cache) den Integritätstest nicht besteht, leitet Application Gateway die Anforderung an die andere Anwendung im Back-End-Pool weiter. Diese Konfiguration stellt sicher, dass die Anforderung immer an die Anwendung in einem vollständig verfügbaren Subnetz für App Service-Umgebung geroutet wird.

Der Integritätstest ist auch in der Standardreferenzimplementierung enthalten. Dort gibt das Gateway einfach einen Fehler zurück, wenn der Integritätstest fehlschlägt. Die hochverfügbare Implementierung verbessert jedoch die Resilienz der Anwendung sowie die Qualität der Benutzererfahrung.

Kostenoptimierung

Bei der Kostenoptimierung geht es darum, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Die Kostenüberlegungen für die Hochverfügbarkeitsarchitektur sind ähnlich wie bei der Standardbereitstellung.

Folgende Unterschiede können sich auf die Kosten auswirken:

• Ihnen werden mindestens neun App Service-Planinstanzen in einer zonenredundanten App Service-Umgebung in Rechnung gestellt. Weitere Informationen finden Sie unter App Service-Umgebung v3 – Preise.
• Azure Cache for Redis ist auch ein zonenredundanter Dienst. Ein zonenredundanter Cache wird auf VMs ausgeführt, die über mehrere Verfügbarkeitszonen hinweg bereitgestellt sind, um eine höhere Resilienz und Verfügbarkeit zu bieten.

Der Kompromiss für ein hochverfügbares, resilientes und hochsicheres System sind höhere Kosten. Verwenden Sie den Preisrechner, um Ihre Anforderungen in Bezug auf die Preise zu bewerten.

Überlegungen zur Bereitstellung

Diese Referenzimplementierung verwendet dieselbe CI/CD-Pipeline auf Produktionsebene wie die Standardbereitstellung, mit nur einer Jumpbox-VM. Sie können sich jedoch dafür entscheiden, eine Jumpbox für jede der drei Zonen zu verwenden. Diese Architektur verwendet nur eine Jumpbox, da sich die Jumpbox nicht auf die Verfügbarkeit der App auswirkt. Die Jumpbox wird nur für die Bereitstellung und das Testen verwendet.

Bereitstellen dieses Szenarios

Informationen zum Bereitstellen der Referenzimplementierung für diese Architektur finden Sie in der GitHub-Infodatei. Verwenden Sie das Skript für die Hochverfügbarkeitsbereitstellung.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Deep Bhattacharya | Cloud Solution Architect
• Suhas Rao | Cloud Solution Architect

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Sie können diese Architektur anpassen, indem Sie Ihre Anwendungen horizontal skalieren, innerhalb derselben Region oder über mehrere Regionen hinweg, basierend auf der erwarteten Spitzenlastkapazität. Das Replizieren Ihrer Anwendungen in mehreren Regionen kann dazu beitragen, die Risiken weitreichenderer geografischer Rechenzentrumsausfälle zu mindern, wie sie beispielsweise von Erdbeben oder anderen Naturkatastrophen verursacht werden. Weitere Informationen zur horizontalen Skalierung finden Sie unter Geografisch verteilte Skalierung mit App Service-Umgebungen. Bei einer globalen und hochverfügbaren Routinglösung sollten Sie die Verwendung von Azure Front Door in Betracht ziehen.