Hochverfügbare Unternehmensbereitstellung über eine App Service-Umgebung

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb einer bestimmten Region. Die Replikation Ihrer Bereitstellungen in mehreren Zonen stellt sicher, dass die Verfügbarkeit Ihrer Anwendung durch lokale, auf eine Zone beschränkte Ausfälle nicht beeinträchtigt wird. Diese Architektur zeigt, wie Sie die Resilienz einer ASE-Bereitstellung durch Bereitstellen in mehreren Verfügbarkeitszonen verbessern. Diese Zonen hängen nicht mit der Nähe zusammen. Sie können verschiedenen physischen Standorten für verschiedene Abonnements zugeordnet sein. In dieser Architektur wird von einer einzelnen Abonnementbereitstellung ausgegangen.

Eine Referenzimplementierung dieser Architektur ist auf GitHub verfügbar.

Aufbau

Der Inhalt der ASE-Subnetze in dieser Referenzimplementierung ist identisch mit dem Inhalt der hier beschriebenen Architektur für die ASE-Standardbereitstellung. Bei dieser Referenzimplementierung wird die Bereitstellung in zwei ASE-Subnetzen repliziert. Jedes Subnetz verfügt über eine eigene Web-App, eine eigene API und eigene Funktionsinstanzen, die jeweils in ihren individuellen App Service-Plänen ausgeführt werden. Die für die Anwendungen erforderliche Redis Cache-Instanz wird ebenfalls repliziert, um die Leistung zu verbessern. Beachten Sie, dass diese Referenzarchitektur auf eine einzelne Region beschränkt ist.

Workflow

Der folgende Abschnitt enthält Informationen zur Art der Verfügbarkeit für in dieser Architektur verwendete Dienste:

App Service-Umgebungen können in mehreren Verfügbarkeitszonen bereitgestellt werden (nur im internen Modus oder im ILB-Modus). Bei dieser Referenzimplementierung werden zwei ASE-Subnetze in jeweils einer anderen Verfügbarkeitszone bereitgestellt. Es werden mindestens zwei Verfügbarkeitszonen empfohlen, um eine End-to-End-Resilienz Ihrer Anwendung zu erreichen. Alle ILB-ASE-Laufzeitressourcen befinden sich in der angegebenen Zone: die IP-Adresse des internen Lastenausgleichs der ASE sowie die Computeressourcen und der zugrunde liegende Dateispeicher, der von der ASE zum Ausführen aller in dieser ASE bereitgestellten Apps benötigt wird. Ausführliche Informationen und Empfehlungen finden Sie unter Unterstützung der App Service-Umgebung für Verfügbarkeitszonen.

Azure Virtual Network (oder VNET) deckt alle Verfügbarkeitszonen innerhalb einer einzelnen Region ab. Die Subnetze innerhalb des VNET sind ebenfalls verfügbarkeitszonenübergreifend. Bei dieser Referenzarchitektur wird ein Subnetz für jede ASE-Bereitstellung erstellt, die für eine Verfügbarkeitszone erstellt wurde. Weitere Informationen finden Sie in den Netzwerkanforderungen für App Service-Umgebungen.

Application Gatewayv2 ist zonenredundant. Es deckt ebenso wie das virtuelle Netzwerk mehrere Verfügbarkeitszonen pro Region ab. Dies bedeutet wiederum, dass ein einzelnes Anwendungsgateway für ein hochverfügbares System ausreicht, wie in dieser Referenzarchitektur gezeigt. Von der v1-SKU wird dies nicht unterstützt. Ausführlichere Informationen finden Sie unter Automatische Skalierung und zonenredundantes Application Gateway v2.

In Azure Firewall ist die Unterstützung für Hochverfügbarkeit bereits integriert. Der Dienst kann ohne zusätzliche Konfiguration mehrere Zonen abdecken. Dies ermöglicht wie in dieser Referenzarchitektur die Verwendung einer einzelnen Firewall für in mehreren Zonen bereitgestellte Anwendungen. Bei Bedarf kann beim Bereitstellen der Firewall auch eine spezifische Verfügbarkeitszone konfiguriert werden. Diese Möglichkeit wird in der vorliegenden Architektur jedoch nicht genutzt. Weitere Informationen finden Sie im Artikel zu Azure Firewall und Verfügbarkeitszonen.

Azure Active Directory ist ein hochverfügbarer, hochredundanter globaler Dienst, der mehrere Verfügbarkeitszonen und Regionen abdeckt. Weitere Informationen finden Sie unter Erweitern der Verfügbarkeit von Azure Active Directory.

Azure Pipelines unterstützt die parallele Verarbeitung von CI/CD-Aktivitäten. Nutzen Sie dies in der Bereitstellungsphase, um die erstellten Anwendungen über mehrere virtuelle Jumpbox-Computer oder Bastion-Subnetze gleichzeitig in mehreren ASE-Subnetzen bereitzustellen. Bei dieser Architektur werden zwei virtuelle Jumpbox-Computer verwendet, um die gleichzeitige Bereitstellung zu unterstützen. Beachten Sie, dass die Anzahl paralleler Aufträge vom Tarif abhängt. Im kostenlosen Basistarif einer von Microsoft gehosteten CI/CD-Instanz können bis zu zehn Aufgaben parallelisiert und jeweils bis zu sechs Stunden lang ausgeführt werden.

Azure Cache for Redis ist kein zonenfähiger Dienst. Bei dieser Architektur werden zwei Subnetze für Redis Cache erstellt und jeweils an die Verfügbarkeitszone eines ASE-Subnetzes gebunden. Diese Vorgehensweise wird empfohlen, da sich die App-Leistung verbessert, wenn der Cache weniger weit von der Anwendung entfernt ist. Beachten Sie, dass es sich hierbei um eine Previewfunktion handelt, die nur im Premium-Tarif zur Verfügung steht.

Überlegungen

Diese Überlegungen setzen die Säulen des Azure Well-Architected Framework um, das eine Reihe von Leitprinzipien enthält, die zur Verbesserung der Qualität eines Workloads verwendet werden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Verfügbarkeit

App Service-Umgebungen

App Service-Umgebungen mit ILB können in einer bestimmten Verfügbarkeitszone bereitgestellt werden. Verfügbarkeitszonen sind geografisch getrennte, eigenständige Rechenzentren innerhalb der gleichen Region. Wenn ein Rechenzentrum ausfällt, kann die Verfügbarkeit durch in anderen Rechenzentren bereitgestellte Anwendungen gewährleistet werden, sofern dies von Ihrer Architektur unterstützt wird.

Nutzen Sie dieses Feature wie folgt:

• Stellen Sie mindestens zwei solche Umgebungen in zwei unterschiedlichen Zonen bereit, und duplizieren Sie dabei die Anwendungen in den einzelnen ASEs. Und:
• Verwenden Sie einen Lastenausgleich für den an die ASEs übermittelten Datenverkehr unter Verwendung einer zonenredundanten Application Gateway-Instanz, wie in dieser Referenzarchitektur gezeigt.

Beachten Sie außerdem folgende Punkte:

• Durch eine in einer Zone bereitgestellte ILB-ASE wird die Uptime bereits bereitgestellter Apps und der von ihnen verwendeten Ressourcen sichergestellt. Die Skalierung von App Service-Plänen sowie App-Erstellung und App-Bereitstellung können jedoch trotzdem durch Ausfälle in anderen Zonen beeinträchtigt werden.
• Für die Erstbereitstellung der ILB-ASE in einer Verfügbarkeitszone muss eine ARM-Vorlage verwendet werden. Danach kann über das Portal oder über die Befehlszeile darauf zugegriffen werden. Die Eigenschaft zones muss zur Angabe der logischen Zonen auf „1“, „2“ oder „3“ festgelegt werden.
• Das virtuelle Netzwerk ist standardmäßig zonenredundant. Daher können sich alle zonal bereitgestellten ASE-Subnetze im gleichen virtuellen Netzwerk befinden.
• Von außen zugängliche ASEs können nicht an eine Verfügbarkeitszone gebunden werden.

Ausführlichere Informationen finden Sie unter Unterstützung der App Service-Umgebung für Verfügbarkeitszonen.

Resilienz

Die Anwendungen in beiden ASE-Subnetzen bilden den Back-End-Pool für die Application Gateway-Instanz. Wenn aus dem öffentlichen Internet eine Anforderung an die Anwendung übermittelt wird, kann das Gateway eine der beiden Anwendungsinstanzen auswählen. Application Gateway überwacht standardmäßig die Integrität der Back-End-Poolressourcen, wie unter Systemüberwachung des Application Gateways – Übersicht beschrieben. In der Referenzeinrichtung kann von einem Standardintegritätstest nur das Web-Front-End überwacht werden. Da von diesem Web-Front-End wiederum andere Komponenten verwendet werden, wird es unter Umständen als fehlerfrei betrachtet, fällt aber trotzdem aus, wenn es aufgrund eines Teilausfalls des Rechenzentrums in dieser Zone zu einem Fehler bei den Abhängigkeiten kommt. Verwenden Sie zur Vermeidung derartiger Fehler einen benutzerdefinierten Test, um zu steuern, was „fehlerfrei“ für die Anwendung wirklich bedeutet. Bei dieser Referenzarchitektur werden Integritätsprüfungen im Haupt-Web-Front-End (votingApp) implementiert. Dieser Integritätstest überprüft, ob die Web-API und Redis Cache fehlerfrei sind. Der folgende Codeausschnitt zeigt die Implementierung dieses Tests in Startup.cs:

            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 Codeausschnitt zeigt, wie die Back-End-Pools und der Integritätstest für die App Gateway-Instanz mithilfe des Skripts deploy_ha.sh konfiguriert werden:

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

Sollte bei diesem Integritätstest ein Fehler für eine der Komponenten (Web-Front-End, API oder Cache) auftreten, wird die Anforderung von der Application Gateway-Instanz an die andere Anwendung aus dem Back-End-Pool weitergeleitet. Dadurch wird sichergestellt, dass die Anforderung immer an die Anwendung in einem vollständig verfügbaren ASE-Subnetz weitergeleitet wird.

Der Integritätstest ist auch in der Standardreferenzimplementierung enthalten. Dort gibt das Gateway einfach einen Fehler zurück, wenn der Integritätstest nicht erfolgreich ist. In der hochverfügbaren Implementierung verbessert er jedoch die Resilienz der Anwendung sowie die Qualität der Benutzererfahrung.

Kostenoptimierung

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

Die Kostenbetrachtung für die Hochverfügbarkeitsarchitektur ähnelt größtenteils der Kostenbetrachtung für die Standardbereitstellung.

Folgende Unterschiede können sich auf die Kosten auswirken:

• Mehrere Bereitstellungen von App Service-Umgebungen
• Mehrere Bereitstellungen von Azure Cache for Redis-Instanzen im Premium-Tarif. In dieser Referenzarchitektur wird aus folgenden Gründen der Premium-Tarif verwendet:
  • Innerhalb des virtuellen Netzwerks kann nur Redis Cache im Premium-Tarif verwendet werden. Und:
  • Die zonale Bindung von Redis Cache (Public Preview-Feature) steht nur im Premium-Tarif zur Verfügung.

Für ein hochverfügbares, robustes und sicheres System müssen höhere Kosten in Kauf genommen werden. Verwenden Sie den Preisrechner, um die Unternehmensanforderungen im Hinblick auf die Preise zu bewerten.

Überlegungen zur Bereitstellung

Diese Referenzimplementierung erweitert die CI/CD-Pipeline auf der Produktionsebene, die in der Standardbereitstellung verwendet wird, mit jeweils einem virtuellen Jumpbox-Computer pro Verfügbarkeitszone. Dies erfüllt zweierlei Zwecke:

• Die virtuellen Computer werden an die gleichen Verfügbarkeitszonen gebunden, die auch von den ASE-Ressourcen verwendet werden, um die Uptime in der Bereitstellung bei einem Ausfall zu gewährleisten, der auf ein bis zwei Zonen beschränkt ist.
• Diese Vorgehensweise trägt außerdem zur Parallelisierung der Bereitstellung bei, indem die virtuellen Computer als Pool von Azure Pipelines-Agents verwendet werden.

In der Datei azure-pipelines.yml der Referenzimplementierung wird diese parallele Bereitstellung durch die Erstellung separater Bereitstellungsphasen (deploy) für die einzelnen zonalen ASEs veranschaulicht.

Bereitstellen dieses Szenarios

Lesen Sie zum Bereitstellen der Referenzimplementierung für diese Architektur die Informationen auf GitHub, und verwenden Sie das Skript für die Hochverfügbarkeitsbereitstellung.

Nächste Schritte

Sie können auf den in dieser Referenzarchitektur vermittelten Erkenntnissen aufbauen und Ihre Anwendungen basierend auf der erwarteten Spitzenlastkapazität horizontal innerhalb der gleichen Region oder über verschiedene Regionen hinweg skalieren. Das Replizieren Ihrer Anwendungen in mehreren Regionen kann dazu beitragen, die Risiken weitreichenderer geografischer Rechenzentrumsausfälle zu mindern, wie sie beispielsweise im Falle von Erdbeben oder anderen Naturkatastrophen auftreten können. Weitere Informationen zur horizontalen Skalierung finden Sie unter Geografisch verteilte Skalierung mit App Service-Umgebungen. Bei einer globalen und hochverfügbaren Routinglösung empfiehlt sich ggf. die Verwendung von Azure Front Door.