Freigeben über


Unterstützung für Verfügbarkeitszonen in App Service-Umgebung v2

Wichtig

In diesem Artikel wird die App Service-Umgebung v2 beschrieben, die mit Plänen vom Typ „App Service (isoliert)“ verwendet wird. App Service-Umgebung v1 und v2 wurden am 31. August 2024 eingestellt. Für die App Service-Umgebung steht eine neue Version zur Verfügung. Diese ist benutzerfreundlicher und basiert auf einer leistungsfähigeren Infrastruktur. Weitere Informationen zu dieser neuen Version finden Sie unter Einführung in die App Service-Umgebung. Wenn Sie derzeit App Service-Umgebung v1 verwenden, führen Sie die Schritte in diesem Artikel aus, um zur neuen Version zu migrieren.

Die Vereinbarung zum Servicelevel (Service Level Agreement, SLA) und Dienstguthaben gelten seit dem 31. August 2024 nicht mehr für Workloads der App Service-Umgebung v1 und v2, da es sich um eingestellte Produkte handelt. Die Außerbetriebnahme der Hardware für die App Service-Umgebung v1 und v2 hat begonnen. Dies kann sich auf die Verfügbarkeit und Leistung Ihrer Apps und Daten auswirken.

Sie müssen die Migration zur App Service-Umgebung v3 sofort abschließen, sonst werden Ihre Apps und Ressourcen möglicherweise gelöscht. Es wird versucht, alle verbleibenden App Service-Umgebungen v1 und v2 bestmöglich mithilfe des Features für die direkte Migration automatisch zu migrieren, doch Microsoft garantiert die Anwendungsverfügbarkeit nach der automatischen Migration nicht. Möglicherweise müssen Sie eine manuelle Konfiguration durchführen, um die Migration abzuschließen und Ihre SKU-Auswahl für den App Service-Plan auf Basis Ihrer Anforderungen zu optimieren. Wenn die automatische Migration nicht möglich ist, werden Ihre Ressourcen und zugehörigen App-Daten gelöscht. Sie sollten schnell handeln, um diese Szenarien zu vermeiden.

Wenn Sie mehr Zeit benötigen, können wir Ihnen eine einmalige Karenzzeit von 30 Tagen anbieten, damit Sie Ihre Migration abschließen können. Weitere Informationen auch zum Anfordern dieser Karenzzeit finden Sie in der Übersicht über die Karenzzeit. Navigieren Sie anschließend im Azure-Portal zum Blatt „Migration“ für jede Ihrer App Service-Umgebungen.

Die aktuellsten Informationen zur Einstellung der App Service Environment v1/v2 finden Sie im Update zur Einstellung der App Service Environment v1 und v2.

App Service-Umgebung v2 kann in Verfügbarkeitszonen (VZ) bereitgestellt werden. Kunden können eine ILB-ASE (Internal Load Balancer, interner Lastenausgleich) für eine bestimmte VZ in einer Azure-Region bereitstellen. Wenn Sie Ihre ILB-ASE an eine bestimmte VZ anheften, werden die von der ILB-ASE verwendeten Ressourcen entweder an die angegebene VZ angeheftet oder zonenredundant bereitgestellt.

Eine ILB-ASE, die explizit in einer VZ bereitgestellt wird, wird als zonale Ressource betrachtet, da die ILB-ASE an eine bestimmte Zone angeheftet ist. Die folgenden ILB-ASE-Abhängigkeiten werden an die angegebene Zone angeheftet:

  • Die IP-Adresse des internen Lastenausgleichs der ASE
  • Computeressourcen, die von der ASE zum Verwalten und Ausführen von Webanwendungen genutzt werden

Der Remotedateispeicher für Webanwendungen, die in einer zonalen ILB-ASE bereitgestellt werden, verwendet zonenredundanten Speicher (ZRS).

Wenn Sie die in diesem Artikel beschriebenen Schritte nicht befolgen, werden ILB-ASEs nicht automatisch zonal bereitgestellt. Eine externe ASE mit einer öffentlichen IP-Adresse kann nicht an eine bestimmte Verfügbarkeitszone angeheftet werden.

Zonale ILB-ASEs können in den folgenden Regionen erstellt werden:

  • Australien (Osten)
  • Kanada, Mitte
  • USA (Mitte)
  • East US
  • USA (Ost) 2
  • USA, Osten 2 (EUAP)
  • Frankreich, Mitte
  • Japan, Osten
  • Nordeuropa
  • Europa, Westen
  • Asien, Südosten
  • UK, Süden
  • USA, Westen 2

In einer zonalen ILB-ASE bereitgestellte Anwendungen werden weiterhin in dieser ASE ausgeführt und verarbeiten Datenverkehr in ihr, selbst wenn andere Zonen in derselben Region ausfallen. Möglicherweise sind Vorgänge außerhalb der Laufzeit wie das Skalieren von App Service-Plänen oder das Erstellen, Konfigurieren und Veröffentlichen von Anwendungen weiterhin von einem Ausfall in anderen Verfügbarkeitszonen betroffen. Die Bereitstellung einer zonalen ILB-ASE mit Anheften an eine Zone gewährleistet nur eine fortlaufende Betriebszeit für bereits bereitgestellte Anwendungen.

Bereitstellen einer App Service-Umgebung in einer Verfügbarkeitszone

Zonale ILB-ASEs müssen mithilfe von ARM-Vorlagen erstellt werden. Sobald eine zonale ILB-ASE über eine ARM-Vorlage erstellt wurde, kann sie über das Azure-Portal und die Befehlszeilenschnittstelle angezeigt werden und ist für Interaktionen verfügbar. Eine ARM-Vorlage wird nur für die anfängliche Erstellung einer zonalen ILB-ASE benötigt.

Die einzige erforderliche Änderung an einer ARM-Vorlage zum Angeben einer zonalen ILB-ASE ist die neue zones-Eigenschaft. Die zones-Eigenschaft sollte abhängig von der logischen Verfügbarkeitszone, an die die ILB-ASE angeheftet werden soll, auf einen der Werte „1“, „2“ oder „3“ festgelegt werden.

Der nachstehende Beispielcodeausschnitt für die ARM-Vorlage zeigt die neue zones-Eigenschaft, die angibt, dass die ILB-ASE an Zone 2 angeheftet werden soll.

"resources": [
    {
        "type": "Microsoft.Web/hostingEnvironments",
        "kind": "ASEV2",
        "name": "yourASENameHere",
        "apiVersion": "2015-08-01",
        "location": "your location here",
        "zones": [
            "2"
        ],
        "properties": {
            "name": "yourASENameHere",
            "location": "your location here",
            "ipSslAddressCount": 0,
            "internalLoadBalancingMode": "3",
            "dnsSuffix": "contoso-internal.com",
            "virtualNetwork": {
                "Id": "/subscriptions/your-subscription-id-here/resourceGroups/your-resource-group-here/providers/Microsoft.Network/virtualNetworks/your-vnet-name-here",
                "Subnet": "yourSubnetNameHere"
            }
        }
    }
]

Damit Ihre Apps zonenredundant sind, müssen Sie zwei zonale ILB-ASEs bereitstellen. Die beiden zonalen ILB-ASEs müssen sich in getrennten Verfügbarkeitszonen befinden. Anschließend müssen Sie Ihre Apps in beiden ILB-ASEs bereitstellen. Nach dem Erstellen Ihrer Apps müssen Sie eine Lösung für den Lastenausgleich konfigurieren. Die empfohlene Lösung ist das Bereitstellen einer zonenredundanten Application Gateway-Instanz hinter den zonalen ILB-ASEs.

Data Residency in der Region

In einer Verfügbarkeitszone bereitgestellte ILB-ASEs speichern nur Kundendaten in der Region, in der die zonale ILB-ASE bereitgestellt wurde. Sowohl der Inhalt von Websitedateien als auch die kundenseitig bereitgestellten Einstellungen und Geheimnisse, die in App Service gespeichert sind, verbleiben innerhalb der Region, in der die zonale ILB-ASE bereitgestellt wurde.

Kunden können für Data Residency in einer einzelnen Region sorgen, indem sie die weiter oben im Abschnitt „Bereitstellen einer App Service-Umgebung in einer Verfügbarkeitszone“ beschriebenen Schritte befolgen. Durch Konfigurieren anhand dieser Schritte erfüllt eine in einer Verfügbarkeitszone bereitgestellte App Service-Umgebung die Anforderungen an die Region für Data Residency – auch die in Azure Trust Center angegebenen.

Kunden können sich mit den folgenden Schritten vergewissern, dass eine App Service-Umgebung ordnungsgemäß zum Speichern von Daten in einer einzelnen Region konfiguriert ist:

  1. Navigieren Sie mit dem Ressourcen-Explorer zur Azure Resource Manager-Ressource für die App Service-Umgebung. ASEs werden unter providers/Microsoft.Web/hostingEnvironments aufgelistet.
  2. Wenn eine zones-Eigenschaft in der Ansicht der ARM-JSON-Syntax (Azure Resource Manager) enthalten ist und ein JSON-Array mit einem einzelnen Wert „1“, „2“ oder „3“ enthält, wird die ASE zonal bereitgestellt, und die Kundendaten verbleiben in derselben Region.
  3. Wenn keine zones-Eigenschaft vorhanden ist oder die Eigenschaft keinen der zuvor angegebenen gültigen Zonenwerte aufweist, wird die ASE nicht zonal bereitgestellt, und die Kundendaten werden nicht exklusiv in derselben Region gespeichert.