Freigeben über

Einführung in die App Service-Umgebung v2

  • Artikel

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 von App Service-Umgebung v1 und v2, da es sich um eingestellte Produkte handelt. Die Außerbetriebnahme der Hardware für 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. Andernfalls 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 Bereich „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.

Übersicht

Azure App Service-Umgebung v2 ist ein Feature von Azure App Service, das eine vollständig isolierte und dedizierte Umgebung zur sicheren Ausführung von App Service-Apps mit umfangreicher Skalierung bereitstellt. Über diese Funktion können folgende Elemente gehostet werden:

  • Windows-Web-Apps
  • Linux-Web-Apps
  • Docker-Container
  • Functions

Hinweis

Linux-Web-Apps und Docker-Container werden in Azure Government- und Microsoft Azure operated by 21Vianet-Regionen nicht unterstützt.

App Service-Umgebungen (App Service Environments, ASEs) sind ideal geeignet für Anwendungsworkloads mit folgenden Anforderungen:

  • Unterstützung sehr vieler Apps
  • Isolierung und sicherer Netzwerkzugriff
  • Hohe Speicherauslastung

Kunden können mehrere ASEs innerhalb einer einzelnen Azure-Region oder über mehrere Azure-Regionen verteilt einrichten. Durch diese Flexibilität eignen sich ASEs hervorragend für die horizontale Skalierung zustandsloser Anwendungsebenen zur Unterstützung von Workloads mit hohen Anforderungen pro Sekunde (Requests per Second, RPS).

ASEs hosten Anwendungen von nur einem Kunden in einem seiner VNETs. Kunden haben präzise Kontrolle über den eingehenden und ausgehenden Netzwerkdatenverkehr der Anwendung. Anwendungen können schnelle, sichere Verbindungen über VPNs mit lokalen Unternehmensressourcen einrichten.

Dedizierte Umgebung

Eine ASE ist eine dedizierte Umgebung, die ausschließlich zu einem einzelnen Kunden gehört und insgesamt 200 App Service-Planinstanzen hosten kann. Ein einzelner isolierter App Service-Plan einer SKU kann bis zu 100 Instanzen enthalten. Wenn Sie alle Instanzen aus allen App Service-Plänen in dieser ASE addieren, muss die Summe kleiner als oder gleich 200 sein.

Eine ASE besteht aus Front-Ends und Worker. Front-Ends sind für die HTTP/HTTPS-Beendigung und den automatischen Lastenausgleich von App-Anforderungen in einer ASE zuständig. Front-Ends werden automatisch hinzugefügt, wenn die App Service-Pläne in der ASE horizontal hochskaliert werden.

Worker sind Rollen, die Kunden-Apps hosten. Worker sind in drei festen Größen verfügbar:

  • Eine vCPU/3,5 GB RAM
  • Zwei vCPUs/7 GB RAM
  • Vier vCPUs/14 GB RAM

Kunden müssen keine Front-Ends und Worker verwalten. Die gesamte Infrastruktur wird automatisch hinzugefügt, wenn Kunden ihre App Service-Pläne aufskalieren. Wenn App Service-Pläne erstellt oder in einer ASE skaliert werden, wird die erforderliche Infrastruktur nach Bedarf hinzugefügt bzw. entfernt.

Es gibt eine monatliche Pauschalgebühr für eine ASE, mit der die Infrastruktur abgedeckt ist. Dies ändert sich nicht mit der Größe der ASE. Darüber hinaus fallen Kosten pro vCPU-App Service-Plan an. Alle in einer ASE gehosteten Apps befinden sich in der isolierten Preis-SKU. Um Informationen zu den Preisen für eine ASE zu erhalten, lesen Sie die Seite App Service-Preise, und überprüfen Sie die verfügbaren Optionen für ASEs.

Unterstützung für virtuelle Netzwerke

Das ASE-Feature ist eine Bereitstellung von Azure App Service direkt im virtuellen Azure Resource Manager-Netzwerk eines Kunden. Weitere Informationen zu virtuellen Azure-Netzwerken finden Sie unter Virtuelle Azure-Netzwerke – FAQs. Eine ASE befindet sich immer in einem virtuellen Netzwerk, genauer gesagt, in einem Subnetz eines virtuellen Netzwerks. Mithilfe der Sicherheitsfunktionen virtueller Netzwerke können Sie ein- und ausgehende Netzwerkkommunikation für Ihre Apps steuern.

Eine ASE kann entweder für Internetzugriff mit einer öffentlichen IP-Adresse oder für die ausschließliche interne Verwendung mit einer Azure-ILB-Adresse (Internal Load Balancer) eingerichtet werden.

Mithilfe von Netzwerksicherheitsgruppen können Sie die eingehende Netzwerkkommunikation mit dem Subnetz einschränken, das eine ASE enthält. Durch NSGs können Sie Apps hinter Upstreamgeräten und -diensten ausführen, wie WAFs und Netzwerk-SaaS-Anbietern.

Apps müssen häufig auch auf Unternehmensressourcen wie interne Datenbanken und Webdienste zugreifen. Wenn Sie die ASE in einem virtuellen Netzwerk bereitstellen, das über eine VPN-Verbindung mit dem lokalen Netzwerk verfügt, können die Apps in der ASE auf die lokalen Ressourcen zugreifen. Diese Funktion besteht unabhängig davon, ob es sich um ein Site-to-Site-VPN oder ein Azure ExpressRoute-VPN handelt.

Weitere Informationen zur Funktionsweise von ASEs mit virtuellen Netzwerken und lokalen Netzwerken finden Sie unter Überlegungen zu Netzwerken mit einer App Service-Umgebung.

App Service-Umgebung v1

Es gibt drei Versionen der App Service-Umgebung: ASEv1, ASEv2 und ASEv3. Die oben aufgeführten Informationen basieren auf ASEv2. In diesem Abschnitt werden die Unterschiede zwischen ASEv1 und ASEv2 aufgezeigt. Weitere Informationen finden Sie unter Übersicht über die App Service-Umgebung.

In ASEv1 müssen Sie alle Ressourcen manuell verwalten. Dies schließt Front-Ends, Worker und IP-Adressen ein, die für IP-basierte TLS/SSL-Bindungen verwendet werden. Bevor Sie Ihren App Service-Plan aufskalieren können, müssen Sie zunächst den Workerpool aufskalieren, den Sie zum Hosten verwenden möchten.

ASEv1 verwendet ein anderes Preismodell als ASEv2. In ASEv1 bezahlen Sie jede zugewiesene vCPU. Dazu gehören vCPUs für Front-Ends oder Worker, die keine Workloads hosten. In ASEv1 beträgt die maximale Standardskalierungsgröße einer ASE insgesamt 55 Hosts. Dazu gehören Worker und Front-Ends. ASEv1 hat den Vorteil, dass die Bereitstellung in einem klassischen virtuellen Netzwerk sowie in einem virtuellen Resource Manager-Netzwerk möglich ist. Weitere Informationen zu ASEv1 finden Sie unter Einführung in die App Service-Umgebung v1.