Migration zu App Service-Umgebung v3 mithilfe des Features für die parallele Migration

Hinweis

Das in diesem Artikel beschriebene Migrationsfeature wird für die automatisierte parallele Migration (anderes Subnetz) von App Service-Umgebung v2 zu App Service-Umgebung v3 verwendet. Wenn Sie keine 30-tägige Karenzzeit angefordert haben, finden Sie in der Übersicht über die Karenzzeit weitere Informationen. Fordern Sie dann eine Karenzzeit an, indem Sie im Azure-Portal das Blatt „Migration“ für jede Ihrer App Service-Umgebungen besuchen.

Wenn Sie nach Informationen zur Funktion für die direkte Migration suchen, lesen Sie Migrieren zu App Service-Umgebung v3 mithilfe der Direktmigrationsfunktion. Wenn Sie nach Informationen zu Optionen für die manuelle Migration suchen, lesen Sie Optionen für die manuelle Migration. Hilfe bei der Entscheidung, welche Migrationsoption für Sie geeignet ist, finden Sie unter Entscheidungsstruktur für den Migrationspfad. Weitere Informationen zu Version 3 der App Service-Umgebung finden Sie unter Übersicht über App Service-Umgebung v3.

Die parallele Migration ist im Vergleich zur direkten Migration mit zusätzlichen Herausforderungen verbunden. Für Kund*innen, die zwischen den beiden Optionen entscheiden müssen, empfiehlt sich die direkte Migration, da sie weniger Schritte umfasst und weniger komplex ist. Wenn Sie sich für die Verwendung der parallelen Migration entscheiden, überprüfen Sie den Abschnitt Häufige Problemquellen bei der Migration mithilfe der parallelen Migration, um häufige Fallstricke zu vermeiden.

App Service kann die Migration Ihrer App Service-Umgebung v1 und v2 zu einer App Service-Umgebung v3 automatisieren. Es gibt verschiedene Migrationsoptionen. Sehen Sie sich die Entscheidungsstruktur für den Migrationspfad an, um zu entscheiden, welche Option für Ihren Anwendungsfall die beste ist. Die App Service-Umgebung v3 bietet Vorteile und Featureunterschiede gegenüber früheren Versionen. Informieren Sie sich vor der Migration über die unterstützten Features der App Service-Umgebung v3, um das Risiko eines unerwarteten Anwendungsproblems zu verringern.

Das Feature für die parallele Migration automatisiert die Migration zu App Service-Umgebung v3. Das Feature für die parallele Migration erstellt eine neue App Service-Umgebung v3 mit allen Ihren Apps in einem anderen Subnetz. Ihre vorhandene App Service-Umgebung wird erst gelöscht, wenn Sie den Löschvorgang am Ende des Migrationsprozesses initiieren. Diese Migrationsoption eignet sich am besten für Kunden, die ohne Downtime zu App Service-Umgebung v3 migrieren möchten und die Verwendung eines anderen Subnetzes für ihre neue Umgebung unterstützen können. Wenn Sie dasselbe Subnetz verwenden müssen und etwa eine Stunde Anwendungsdowntime unterstützen können, lesen Sie den Artikel zur Funktion für die direkte Migration. Optionen für die manuelle Migration, die Ihnen die Migration im eigenen Tempo ermöglichen, finden Sie unter Optionen für die manuelle Migration.

Wichtig

Wenn Sie nicht alle in diesem Lernprogramm beschriebenen Schritte ausführen, treten Ausfallzeiten auf. Wenn Sie z. B. nicht alle abhängigen Ressourcen mit den neuen IP-Adressen aktualisieren oder den Zugriff auf Ihr neues/von Ihrem neuen Subnetz nicht zulassen, z. B. im Fall für den benutzerdefinierten Schlüsseltresor für Domänensuffix, treten Ausfallzeiten auf, bis dies behoben ist.

Es wird empfohlen, dieses Feature zuerst für Entwicklungsumgebungen zu verwenden, bevor Sie Produktionsumgebungen migrieren, um den Prozess zu testen und sicherzustellen, dass keine unerwarteten Probleme auftreten. Senden Sie uns Feedback zu diesem Artikel oder dem Feature über die Schaltflächen am unteren Rand der Seite.

Unterstützte Szenarios

Derzeit unterstützt das Feature für die parallele Migration in folgenden Regionen keine Migrationen zur App Service-Umgebung v3:

Azure – Öffentlich

• VAE, Mitte

Azure Government

• US DoD, Mitte
• US DoD, Osten
• US Gov Arizona
• US Gov Texas
• US Government, Virginia

Microsoft Azure von 21Vianet

• China, Osten 2
• China, Norden 2

Die folgenden App Service-Umgebungskonfigurationen können mithilfe des Features für die parallele Migration migriert werden. In der Tabelle wird die Konfiguration von App Service-Umgebung v3 aufgeführt, wenn Sie das Feature für die parallele Migration basierend auf Ihrer vorhandenen App Service-Umgebung verwenden.

Konfiguration	v3-Konfiguration der App Service-Umgebung
Interner Load Balancer der App Service-Umgebung v2	ILB-App Service-Umgebung v3
Externe (ELB/Internet mit öffentlicher IP-Adresse) App Service-Umgebung v2	ELB-App Service-Umgebung v3
App Service-Umgebung v2 mit ILB und benutzerdefiniertem Domänensuffix	ILB-App Service-Umgebung v3 mit benutzerdefiniertem Domänensuffix

App Service-Umgebung v3 kann zonenredundant bereitgestellt werden. Zonenredundanz kann aktiviert werden, sofern sich Ihre App Service-Umgebung v3 in einer Region befindet, die Zonenredundanz unterstützt.

Wenn Sie möchten, dass Ihre neue App Service-Umgebung v3 ein benutzerdefiniertes Domänensuffix verwendet und Sie derzeit kein benutzerdefiniertes Domänensuffix verwenden, kann dieses jederzeit konfiguriert werden, nachdem die Migration abgeschlossen wurde. Weitere Informationen finden Sie unter Konfigurieren eines benutzerdefinierten Domänensuffixes für die App Service-Umgebung. Wenn Ihre vorhandene Umgebung über ein benutzerdefiniertes Domänensuffix verfügt und Sie es nicht mehr verwenden möchten, müssen Sie für die Migration ein benutzerdefiniertes Domänensuffix konfigurieren. Sie können das benutzerdefinierte Domänensuffix nach Abschluss der Migration entfernen.

Einschränkungen des Features für die parallele Migration

Bei der Verwendung des Features für die parallele Migration gelten die folgenden Einschränkungen:

• Ihre neue App Service-Umgebung v3 befindet sich in einem anderen Subnetz, aber im selben virtuellen Netzwerk wie Ihre vorhandene Umgebung.
• Sie können die Region, in der sich Ihre App Service-Umgebung befindet, nicht ändern.
• Eine ELB-App Service-Umgebung kann nicht zu einer ILB-App Service-Umgebung v3 migriert werden und umgekehrt.
• Wenn Ihre vorhandene App Service-Umgebung ein benutzerdefiniertes Domänensuffix verwendet, müssen Sie während des Migrationsprozesses das benutzerdefinierte Domänensuffix für Ihre App Service-Umgebung v3 konfigurieren.
  • Wenn Sie kein benutzerdefiniertes Domänensuffix mehr verwenden möchten, können Sie es entfernen, nachdem die Migration abgeschlossen wurde.
• Das Feature für die parallele Migration ist nur über die CLI oder über die REST-API verfügbar. Das Feature ist im Azure-Portal nicht verfügbar.

Die Version 3 der App Service-Umgebung unterstützt folgende Features nicht, die Sie möglicherweise in Ihrer aktuellen App Service-Umgebung v2 verwenden:

• Konfigurieren einer IP-basierten TLS/SSL-Bindung mit Ihren Apps
• In Version 3 der App Service-Umgebung wird nicht auf Azure DNS zurückgegriffen, wenn Ihre konfigurierten benutzerdefinierten DNS-Server im virtuellen Netzwerk einen bestimmten Namen nicht auflösen können. Sollte dieses Verhalten benötigt werden, stellen Sie sicher, dass Sie über eine Weiterleitung an ein öffentliches DNS verfügen, oder schließen Sie Azure DNS in die Liste der benutzerdefinierten DNS-Server ein.

Die folgenden Szenarien werden vom Feature für die parallele Migration nicht unterstützt. Falls Ihre App Service-Umgebung in eine dieser Kategorien fällt, lesen Sie die Informationen zu den manuellen Migrationsoptionen.

• App Service-Umgebung v1
  • Sie können die Version Ihrer App Service-Umgebung finden, indem Sie im Azure-Portal zu Ihrer App Service-Umgebung navigieren und auf der linken Seite unter EinstellungenKonfiguration auswählen. Sie können auch den Azure-Ressourcen-Explorer verwenden und den Wert der kind-Eigenschaft für Ihre App Service-Umgebung überprüfen.
  • Wenn Sie über App Service-Umgebung v1 verfügen, können Sie die Migration mithilfe der Direktmigrationsfunktion oder einer der Optionen für die manuelle Migration durchführen.
• ELB-App Service-Umgebung v2 mit IP-SSL-Adressen
• An eine Zone geheftete App Service-Umgebung v2
• App Service-Umgebung mit einem Namen, der die Zeichenbeschränkungen nicht erfüllt. Der gesamte Name, einschließlich des Domänensuffixes, darf maximal 64 Zeichen lang sein. Beispiel: my-ase-name.appserviceenvironment.net für ILB und my-ase-name.p.azurewebsites.net für ELB darf maximal 64 Zeichen lang sein. Wenn die Zeichenbeschränkung nicht erfüllt ist, müssen Sie manuell migrieren. Folgende Zeichenbeschränkungen gelten speziell für den Namen der App Service-Umgebung:
  • Zeichenbeschränkung für Namen von ILB-App Service-Umgebungen: 36 Zeichen
  • Zeichenbeschränkung für Namen von ELB-App Service-Umgebungen: 42 Zeichen

Die App Service-Plattform überprüft Ihre App Service-Umgebung, um die Unterstützung für die parallele Migration zu bestätigen. Wenn Ihr Szenario nicht alle Validierungsprüfungen besteht, können Sie zu diesem Zeitpunkt keine Migration mithilfe des Features für die parallele Migration durchführen. Wenn Sich Ihre Umgebung in einem fehlerhaften oder angehaltenen Zustand befindet, können Sie erst migrieren, wenn Sie die erforderlichen Updates durchführen.

Hinweis

Die App Service-Umgebung v3 unterstützt IP-SSL nicht. Wenn Sie IP-SSL verwenden, müssen Sie alle IP-SSL-Bindungen entfernen, bevor Sie zu App Service-Umgebung v3 migrieren. Das Migrationsfeature wird Ihre Umgebung unterstützen, sobald alle IP-SSL-Bindungen entfernt wurden.

Problembehandlung

Wenn Ihre App Service-Umgebung die Validierungsprüfungen nicht besteht oder Sie versuchen, einen Migrationsschritt in der falschen Reihenfolge auszuführen, wird eine der folgenden Fehlermeldungen angezeigt:

Fehlermeldung	BESCHREIBUNG	Empfehlung
Das Migrieren kann nur in einer ASE im ARM-VNet aufgerufen werden und diese ASE befindet sich im klassischen VNet.	App Service-Umgebungen in klassischen virtuellen Netzwerken können nicht mithilfe des Features für die parallele Migration migriert werden.	Migrieren Sie mithilfe einer der manuellen Migrationsoptionen.
Die ASEv3-Migration ist noch nicht bereit.	Die zugrunde liegende Infrastruktur ist nicht bereit, die App Service-Umgebung v3 zu unterstützen.	Migrieren Sie mithilfe einer der manuellen Migrationsoptionen, wenn Sie sofort migrieren möchten. Warten Sie andernfalls, bis das Feature für die parallele Migration in Ihrer Region verfügbar ist.
Die Zonenredundanz für diese App Service-Umgebung kann nicht aktiviert werden.	Die Region, in der sich die App Service-Umgebung befindet, unterstützt keine Zonenredundanz.	Wenn Sie Zonenredundanz aktivieren müssen, verwenden Sie eine der Optionen für die manuelle Migration, um zu einer Region zu migrieren, die Zonenredundanz unterstützt.
Die Migration kann derzeit nicht für diese ASE mit benutzerdefiniertem DNS-Suffix aufgerufen werden.	Die Migration des benutzerdefinierten Domänensuffixes ist blockiert.	Öffnen Sie einen Supportfall, um mit dem Support zusammenzuarbeiten, um Ihr Problem zu beheben.
Die Migration der zonenredundanten ASE kann zurzeit nicht aufgerufen werden.	Die Migration der zonenredundanten App Service-Umgebung ist blockiert.	Öffnen Sie einen Supportfall, um mit dem Support zusammenzuarbeiten, um Ihr Problem zu beheben.
Die Migration kann nicht für eine zonengebundene ASEv2 aufgerufen werden.	Eine App Service-Umgebung v2, die in einer Zone angeheftet ist, kann zu diesem Zeitpunkt nicht mit dem Feature für die parallele Migration migriert werden.	Migrieren Sie mithilfe einer der manuellen Migrationsoptionen, wenn Sie sofort migrieren möchten.
Derzeit wird ein Vorgang zum Rückgängigmachen der Migration ausgeführt. Versuchen Sie es später noch einmal.	Ein vorheriger Migrationsversuch wird rückgängig gemacht.	Warten Sie, bis der Vorgang abgeschlossen ist, bevor Sie erneut versuchen, die Migration zu starten.
„Properties.VirtualNetwork.Id“ muss die Subnetzressourcen-ID enthalten.	Der Fehler wird angezeigt, wenn Sie versuchen, eine die Migration auszuführen, ohne ein neues Subnetz für Ihre App Service-Umgebung v3 bereitzustellen.	Befolgen Sie unbedingt die Anleitung, und führen Sie den Schritt aus, um das Subnetz zu ermitteln, das Sie für Ihre App Service-Umgebung v3 verwenden werden.
Es ist nicht möglich, von der aktuellen Phase <previous phase> der Migration ohne Downtime zu <requested phase> zu wechseln.	Dieser Fehler wird angezeigt, wenn Sie versuchen, einen Migrationsschritt in der falschen Reihenfolge auszuführen.	Führen Sie die Migrationsschritte unbedingt in der angegebenen Reihenfolge aus.
Fehler beim Starten des Zurücksetzungsvorgangs für die ASE im Hybridzustand. Versuchen Sie es später noch einmal.	Dieser Fehler wird angezeigt, wenn Sie versuchen, die Migration zurückzusetzen, aber Probleme auftreten. Dieser Fehler wirkt sich weder auf Ihre alte noch Ihre neue Umgebung aus.	Öffnen Sie einen Supportfall, um mit dem Support zusammenzuarbeiten, um Ihr Problem zu beheben.
Diese ASE kann nicht ohne Downtime migriert werden.	Dieser Fehler tritt auf, wenn Sie versuchen, das Feature für die parallele Migration in einer App Service-Umgebung v1 zu verwenden.	Das Feature für die parallele Migration unterstützt die App Service-Umgebung v1 nicht. Migrieren Sie mithilfe der Direktmigrationsfunktion oder einer der Optionen für die manuelle Migration.
Die Migration ist für dieses Abonnement nicht verfügbar.	Für die Migration dieser App Service-Umgebung müssen Sie den Support in Anspruch nehmen.	Öffnen Sie einen Supportfall, um mit dem Support zusammenzuarbeiten, um Ihr Problem zu beheben.
Die zonenredundante Migration kann nicht aufgerufen werden, da die während der Migrationsvorbereitung erstellten IP-Adressen nicht zonenredundant sind.	Dieser Fehler wird angezeigt, wenn Sie versuchen, eine zonenredundante Migration durchzuführen, wobei jedoch während der IP-Generierung die generierten IPs als zonenredundant erstellt wurden. Die Plattform versucht, alle IPs zonenredundant zu machen, um die Back-End-Resilienz sicherzustellen.	Öffnen Sie einen Supportfall, um Support zu erhalten, wenn Sie Zonenredundanz aktivieren müssen. Die Techniker setzen die Migration zurück und ermöglichen so einen neuen Versuch, die IPs zu erstellen. Andernfalls können Sie die Migration durchführen, ohne Zonenredundanz zu aktivieren.
Die Migration kann nicht aufgerufen werden, wenn IP-SSL für eine der Websites aktiviert ist.	App Service-Umgebungen, die über Websites mit aktiviertem IP-SSL verfügen, können nicht mit dem Feature für die parallele Migration migriert werden.	Entfernen Sie IP-SSL aus allen Ihren Apps in der App Service-Umgebung, um das Migrationsfeature zu aktivieren.
Die Migration im selben Subnetz ist nicht möglich.	Der Fehler wird angezeigt, wenn Sie dasselbe Subnetz, in dem sich Ihre aktuelle Umgebung befindet, für App Service-Umgebung v3 angeben.	Sie müssen ein anderes Subnetz für Ihre App Service-Umgebung v3 angeben. Wenn Sie dasselbe Subnetz verwenden müssen, migrieren Sie mithilfe der Funktion für die direkte Migration.
Das Abonnement weist zu viele App Service-Umgebungen auf. Entfernen Sie einige davon, bevor Sie versuchen, weitere zu erstellen.	Das Kontingent für Ihr Abonnement der App Service-Umgebung wurde erfüllt.	Entfernen Sie nicht benötigte Umgebungen, oder kontaktieren Sie den Support, um Ihre Optionen zu prüfen.
Die Migration kann in dieser ASE erst aufgerufen werden, wenn das aktive Upgrade abgeschlossen ist.	App Service Umgebungen können während Plattformupgrades nicht migriert werden. Sie können Ihre Upgradeeinstellungen im Azure-Portal festlegen. Upgrades dauern je nach Größe (Anzahl von Instanzen/Kernen) der App-Dienstumgebung 8-12 Stunden oder länger.	Warten Sie, bis das Upgrade abgeschlossen ist, und migrieren Sie dann.
In der App Service-Umgebung wird ein Verwaltungsvorgang ausgeführt.	Ihre App Service-Umgebung wird einem Verwaltungsvorgang unterzogen. Diese Vorgänge können Aktivitäten wie Bereitstellungen oder Upgrades umfassen. Die Migration wird blockiert, bis diese Vorgänge abgeschlossen wurden.	Sobald diese Vorgänge abgeschlossen wurden, können Sie die Migration ausführen.
Ihr InteralLoadBalancingMode wird derzeit nicht unterstützt.	App Service-Umgebungen, bei denen InternalLoadBalancingMode auf bestimmte Werte festgelegt ist, können derzeit nicht mit der Migrationsfunktion migriert werden. Der interne Lastenausgleichsmodus (InternalLoadBalancingMode) muss vom Microsoft-Team manuell geändert werden.	Öffnen Sie einen Supportfall, um mit dem Support zusammenzuarbeiten, um Ihr Problem zu beheben. Fordern Sie eine Aktualisierung des internen Lastenausgleichsmodus (InternalLoadBalancingMode) an.
Die vollständige Migration kann nicht aufgerufen werden, bevor IP-Adressen generiert wurden.	Dieser Fehler tritt auf, wenn Sie versuchen zu migrieren, bevor Sie die Schritte vor der Migration abgeschlossen haben.	Stellen Sie sicher, dass Sie alle Schritte vor der Migration ausführen, bevor Sie versuchen, zu migrieren. Weitere Informationen finden Sie in der schrittweisen Anleitung zum Migrieren.
Die vollständige Migration kann nicht auf Ase mit eingestelltem benutzerdefinierten DNS-Suffix aufgerufen werden, ohne dass eine benutzerdefinierte DNS-Suffix-Konfiguration für AseV3 konfiguriert wurde.	Ihre vorhandene App Service-Umgebung verwendet ein benutzerdefiniertes Domänensuffix. Sie müssen während des Migrationsprozesses ein benutzerdefiniertes Domänensuffix für Ihre App Service-Umgebung v3 konfigurieren.	Konfigurieren eines benutzerdefinierten Domänensuffixes Wenn Sie kein benutzerdefiniertes Domänensuffix mehr verwenden möchten, können Sie es entfernen, nachdem die Migration abgeschlossen wurde.

Übersicht über den Migrationsprozess mithilfe des Features für die parallele Migration

Die parallele Migration besteht aus einer Reihe von Schritten, die der Reihe nach befolgt werden müssen. Für eine Teilmenge der Schritte werden wichtige Informationen gegeben. Es ist wichtig zu verstehen, was während dieser Schritte geschieht und wie sie Ihre Umgebung und Ihre Apps beeinflussen. Nachdem Sie die folgenden Informationen gelesen haben und bereit sind, zu migrieren, befolgen Sie die Schritt-für-Schritt-Anleitung.

Überprüfen, ob die Migration mithilfe des Parallelmigrationsfeatures für Ihre App Service-Umgebung unterstützt wird

Die Plattform überprüft, ob Ihre App Service-Umgebung mithilfe des Features für die parallele Migration migriert werden kann. Wenn die App Service-Umgebung nicht alle Validierungsprüfungen besteht, können Sie zu diesem Zeitpunkt keine Migration mithilfe der Parallelmigrationsfunktion durchführen. Ausführliche Informationen zu den möglichen Ursachen eines Überprüfungsfehlers finden Sie im Abschnitt Problembehandlung. Wenn Sich Ihre Umgebung in einem fehlerhaften oder angehaltenen Zustand befindet, können Sie erst migrieren, wenn Sie die erforderlichen Updates durchführen. Wenn Sie nicht mithilfe des Features für die parallelen Migration migrieren können, sehen Sie sich die Optionen für die manuelle Migration an.

Bei der Validierung wird zudem überprüft, ob Ihre App Service-Umgebung den für die Migration erforderlichen Mindestbuild nutzt. Dieser Build ist möglicherweise neuer als der Standardbuild, der mit dem Routineplattformupgrade/Wartungszyklus bereitgestellt wird. Der Mindestbuild wird regelmäßig aktualisiert, um sicherzustellen, dass die neuesten Fehlerbehebungen und Verbesserungen verfügbar sind. Wenn die App Service-Umgebung nicht den Mindestbuild verwendet, müssen Sie das Upgrade selbst starten. Dieses Upgrade ist ein Standardprozess, bei dem Ihre App Service-Umgebung nicht beeinträchtigt wird. Sie können Ihre App-Service-Umgebung jedoch während des Upgrades nicht skalieren oder Änderungen daran vornehmen. Sie können erst migrieren, wenn das Upgrade abgeschlossen ist. Upgrades können je nach Größe Ihrer Umgebung 8 bis 12 Stunden oder länger dauern. Wenn Sie ein bestimmtes Zeitfenster für die Migration planen, sollten Sie die Validierungsprüfung 24 bis 48 Stunden vor der geplanten Migrationszeit ausführen, um sicherzustellen, dass Sie bei Bedarf Zeit für ein Upgrade haben.

Auswählen und Vorbereiten des Subnetzes für Ihre neue App Service-Umgebung v3

Die Plattform erstellt Ihre neue App Service-Umgebung v3 in einem anderen Subnetz als Ihre vorhandene App Service-Umgebung. Sie müssen ein Subnetz auswählen, das die folgenden Anforderungen erfüllt:

• Das Subnetz muss sich im selben virtuellen Netzwerk und daher in derselben Region wie Ihre vorhandene App Service-Umgebung befinden.
  • Wenn Ihr virtuelles Netzwerk kein verfügbares Subnetz enthält, müssen Sie eins erstellen. Möglicherweise müssen Sie den Adressraum Ihres virtuellen Netzwerks erhöhen, um ein neues Subnetz zu erstellen. Weitere Informationen finden Sie unter Erstellen eines virtuellen Netzwerks.
• Das Subnetz muss in beide Richtungen mit dem Subnetz kommunizieren können, in dem sich Ihre vorhandene App Service-Umgebung befindet. Stellen Sie sicher, dass keine Netzwerksicherheitsgruppen oder andere Netzwerkkonfigurationen vorhanden sind, die die Kommunikation zwischen den Subnetzen verhindern würden.
• Das Subnetz muss über eine einzelne Delegierung von Microsoft.Web/hostingEnvironments verfügen.
• Das Subnetz muss über genügend verfügbare IP-Adressen verfügen, um Ihre neue App Service-Umgebung v3 zu unterstützen. Die Anzahl der erforderlichen IP-Adressen hängt von der Anzahl der Instanzen ab, die Sie für Ihre neue App Service-Umgebung v3 verwenden möchten. Weitere Informationen finden Sie unter Netzwerkfunktionalität in der App Service-Umgebung v3.
• Auf das Subnetz dürfen keine Sperren angewendet sein. Wenn Sperren vorhanden sind, müssen sie vor der Migration entfernt werden. Die Sperren können nach Abschluss der Migration bei Bedarf erneut hinzugefügt werden. Weitere Informationen zu Sperren und zur Vererbung von Sperren finden Sie unter Sperren von Ressourcen zum Schutz Ihrer Infrastruktur.
• Es darf keine Azure-Richtlinien geben, die die Migration oder zugehörige Aktionen blockieren. Wenn Sie Richtlinien haben, welche die Erstellung von App Service-Umgebungen oder die Änderung von Subnetzen blockiert, müssen diese vor der Migration entfernt werden. Die Richtlinien können bei Bedarf nach Abschluss der Migration wieder hinzugefügt werden. Weitere Informationen zu Azure Policy finden Sie unter Azure Policy im Überblick.

Generieren von ausgehenden IP-Adressen für Ihre neue App Service-Umgebung v3

Die Plattform erstellt die die neuen ausgehenden IP-Adressen. Während diese IP-Adressen erstellt werden, wird die Aktivität mit Ihrer vorhandenen App Service-Umgebung nicht unterbrochen. Sie können jedoch nicht skalieren oder Änderungen an Ihrer vorhandenen Umgebung vornehmen. Für diesen Prozess werden etwa 15 Minuten benötigt.

Nach Abschluss des Vorgangs werden die neuen ausgehenden IP-Adressen erstellt, die Ihre zukünftige App Service-Umgebung v3 verwendet. Diese neuen IP-Adressen haben keine Auswirkungen auf Ihre vorhandene Umgebung.

Sie erhalten die neue eingehende IP-Adresse, sobald die Migration abgeschlossen ist, aber bevor Sie die DNS-Änderung vornehmen, um den Kundendatenverkehr an Ihre neue App Service-Umgebung v3 umzuleiten. Sie erhalten die eingehende IP-Adresse nicht an dieser Stelle, da es Abhängigkeiten bei den Ressourcen in der App Service-Umgebung v3 gibt, die während des Migrationsschritts erstellt werden. Sie haben die Möglichkeit, alle Ressourcen zu aktualisieren, die von der neuen eingehenden IP-Adresse abhängig sind, bevor Sie den Datenverkehr an Ihre neue App Service-Umgebung v3 umleiten.

Aktualisieren abhängiger Ressourcen mit neuen ausgehenden IP-Adressen

Die neuen ausgehenden IPs werden erstellt und Ihnen mitgeteilt, bevor Sie mit der tatsächlichen Migration beginnen. Sie verfügen über die neuen, standardmäßigen, zum Internet ausgehenden öffentlichen IP-Adressen. Damit können Sie externe Firewalls, DNS-Routing, Netzwerksicherheitsgruppen und alle anderen Ressourcen, die diese IP-Adressen verwenden, vor dem Abschließen der Migration anpassen. Es liegt in Ihrer Verantwortung, sämtliche Ressourcen zu aktualisieren, die von der Änderung der IP-Adresse im Zusammenhang mit der neuen App Service-Umgebung v3 betroffen sind. Fahren Sie erst mit dem nächsten Schritt fort, wenn Sie alle erforderlichen Änderungen vorgenommen haben. Während und nach der Migration tritt möglicherweise Downtime auf, wenn Sie Abhängigkeiten bei den ausgehenden IP-Adressen haben und nicht alle erforderlichen Updates vornehmen können. Dies liegt daran, dass die zugrunde liegende Computeumgebung nach Beginn der Migration die neue App Service-Umgebung v3 im neuen Subnetz ist, auch wenn der Datenverkehr weiterhin an die Front-Ends Ihrer App Service-Umgebung v2 geleitet wird.

Dieser Schritt ist auch ein guter Zeitpunkt, um die Abhängigkeitsänderungen ein- und ausgehender Netzwerk zu überprüfen, wenn Sie zur App Service-Umgebung v3 wechseln, einschließlich der Portänderung für den Azure Load Balancer-Integritätstest, der jetzt Port 80 verwendet.

Delegieren des Subnetzes Ihrer App Service-Umgebung

Die App Service-Umgebung v3 erfordert ein beinhaltendes Subnetz mit einer einzelnen Delegierung von Microsoft.Web/hostingEnvironments. Die Migration kann nicht erfolgreich abgeschlossen werden, wenn das Subnetz der App Service-Umgebung nicht delegiert ist oder an eine andere Ressource delegiert ist. Stellen Sie sicher, dass das Subnetz, das Sie für Ihre neue App Service-Umgebung v3 auswählen, über eine einzelne Delegierung von Microsoft.Web/hostingEnvironments verfügt.

Überprüfen von Änderungen an der Instanzgröße

Ihre App Service-Pläne werden im Rahmen der Migration mit der entsprechenden SKU „V2 Isoliert“ erstellt. Pläne vom Typ „I2“ entsprechen beispielsweise „I2v2“. Ihre Apps sind nach der Migration möglicherweise überdimensioniert, da die Dienstebene „V2 Isoliert“ mehr Arbeitsspeicher und CPU pro entsprechender Instanzgröße bietet. Nach Abschluss der Migration haben Sie die Möglichkeit, Ihre Umgebung bedarfsgerecht zu skalieren. Weitere Informationen finden Sie in den SKU-Details.

Sicherstellen, dass keine Sperren für Ihre Ressourcen vorhanden sind

Sperren für virtuelle Netzwerke blockieren Plattformvorgänge während der Migration. Wenn für Ihr virtuelles Netzwerk Sperren vorhanden sind, müssen Sie sie vor der Migration entfernen. Die Sperren können nach Abschluss der Migration bei Bedarf erneut hinzugefügt werden. Sperren können in drei verschiedenen Bereichen vorhanden sein: Abonnement, Ressourcengruppe und Ressource. Wenn Sie eine Sperre in einem übergeordneten Bereich anwenden, erben alle Ressourcen in diesem Bereich die entsprechende Sperre. Wenn Sperren im Abonnement, der Ressourcengruppe oder im Ressourcengruppenbereich vorliegen, müssen diese vor der Migration entfernt werden. Weitere Informationen zu Sperren und zur Vererbung von Sperren finden Sie unter Sperren von Ressourcen zum Schutz Ihrer Infrastruktur.

Stellen Sie sicher, dass die Migration nicht durch Azure-Richtlinien blockiert wird.

Azure Policy kann verwendet werden, um die Erstellung und Änderung von Ressourcen für bestimmte Prinzipale zu verweigern. Wenn Sie eine Richtlinie haben, welche die Erstellung von App Service-Umgebungen oder die Änderung von Subnetzen blockiert, müssen Sie diese vor der Migration entfernen. Die Richtlinie kann bei Bedarf nach Abschluss der Migration wieder hinzugefügt werden. Weitere Informationen zu Azure Policy finden Sie unter Azure Policy im Überblick.

Hinzufügen eines benutzerdefinierten Domänensuffixes (optional)

Wenn Ihre vorhandene App Service-Umgebung ein benutzerdefiniertes Domänensuffix verwendet, müssen Sie ein benutzerdefiniertes Domänensuffix für Ihre neue App Service-Umgebung v3 konfigurieren. Ein benutzerdefiniertes Domänensuffix in App Service-Umgebung v3 wird anders implementiert als in App Service-Umgebung v2. Sie müssen den benutzerdefinierten Domänennamen, die verwaltete Identität und das Zertifikat angeben. Diese müssen in Azure Key Vault gespeichert werden. Weitere Informationen zum benutzerdefinierten Domänensuffix der App Service-Umgebung v3 (einschließlich Anforderungen, schrittweisen Anleitungen und bewährten Methoden) finden Sie unter Konfigurieren eines benutzerdefinierten Domänensuffix für die App Service-Umgebung. Wenn Ihre App Service-Umgebung v2 ein benutzerdefiniertes Domänensuffix verwendet, müssen Sie ein benutzerdefiniertes Domänensuffix für Ihre neue Umgebung konfigurieren, auch wenn Sie sie nicht länger verwenden wollen. Nachdem die Migration abgeschlossen wurde, können Sie die benutzerdefinierte Domänensuffixkonfiguration bei Bedarf entfernen.

Wenn Ihre Migration ein benutzerdefiniertes Domänensuffix für die App Service-Umgebung v3 enthält, wird die benutzerdefinierte Domäne nicht im Abschnitt Grundlagen der Übersichtsseite des Portals angezeigt, da sie sich auf die App Service-Umgebung v1/v2 bezieht. Navigieren Sie stattdessen für die App Service-Umgebung v3 zur Seite Benutzerdefiniertes Domänensuffix, auf der Sie bestätigen können, dass Ihr benutzerdefiniertes Domänensuffix richtig konfiguriert ist. Wenn Sie in der App Service-Umgebung v2 ein benutzerdefiniertes Domänensuffix verwenden, enthält der Standardhostname auch Ihr benutzerdefiniertes Domänensuffix und wird im Format APP-NAME.internal.contoso.com angegeben. In der App Service-Umgebung v3 verwendet der Standardhostname immer das Standarddomänensuffix und wird im Format APP-NAME.ASE-NAME.appserviceenvironment.net angegeben. Dieser Unterschied ist darauf zurückzuführen, dass die App Service-Umgebung v3 das Standarddomänensuffix beibehält, wenn Sie ein benutzerdefiniertes Domänensuffix hinzufügen. Bei der App Service-Umgebung v2 gibt es nur ein einzelnes Domänensuffix.

Migrieren zur App Service-Umgebung v3

Nach Abschluss der oben aufgeführten Schritte sollten Sie die Migration so bald wie möglich fortsetzen.

Während der Migration kommt es zu keiner Anwendungsdowntime. Allerdings können Sie wie im Schritt zur Generierung von IP-Adressen Ihre vorhandene App Service-Umgebung nicht skalieren oder ändern und während dieses Prozesses keine Apps darin bereitstellen.

Wichtig

Da die Skalierung während der Migration blockiert wird, sollten Sie Ihre Umgebung auf die gewünschte Größe skalieren, bevor Sie die Migration starten. Wenn die automatische Skalierung aktiviert ist und wenn vor dem Start der Migration ein Skalierungsereignis auftritt, müssen Sie warten, bis das Skalierungsereignis abgeschlossen ist, bevor Sie die Migration starten. Sie müssen die automatische Skalierung deaktivieren, bevor Sie die Migration starten, um dieses Problem zu vermeiden. Wenn Sie Ihre Umgebung nach der Migration skalieren müssen, können Sie dies nach Abschluss der Migration tun.

In diesem Schritt entscheiden Sie außerdem, ob Sie Zonenredundanz für die neue App Service-Umgebung v3 aktivieren möchten. Zonenredundanz kann aktiviert werden, sofern sich Ihre App Service-Umgebung v3 in einer Region befindet, die Zonenredundanz unterstützt.

Die parallele Migration erfordert ein Dienstfenster von drei bis sechs Stunden für Migrationen von App Service-Umgebung v2 zu v3. Während der Migration werden Skalierungs- und Umgebungskonfigurationen blockiert, und die folgenden Ereignisse treten auf:

• Die neue App Service-Umgebung v3 wird im ausgewählten Subnetz erstellt.
• Ihre neuen App Service-Pläne werden in der neuen App Service-Umgebung v3 mit der entsprechenden Dienstebene „V2 Isoliert“ erstellt.
• Ihre Apps werden in der neuen App Service-Umgebung v3 erstellt.
• Die zugrunde liegenden Compute/Worker für Ihre Apps werden in die neue App Service-Umgebung v3 verschoben. Dies bedeutet, dass Ihre Apps jetzt in Ihrer App Service-Umgebung v3 ausgeführt werden. Die Front-Ends Ihrer App Service-Umgebung v2 Ends werden jedoch standardmäßig weiterhin ausgeführt und dienen dem Datenverkehr. Ihre alte eingehende IP-Adresse wird weiterhin verwendet, aber es werden Ihre neuen ausgehenden IPs verwendet. Darüber hinaus werden die Front-Ends Ihrer neuen App Service-Umgebung v3 erstellt und für den Datenverkehr bereitgemacht.
  • Für ILB-App Service-Umgebung werden Ihre App Service-Umgebung v3-Front-Ends erst verwendet, wenn Sie Ihre privaten DNS-Zonen mit der neuen eingehenden IP-Adresse aktualisieren.
  • Bei ELB-App Service-Umgebungen wird Datenverkehr beim Migrationsprozess erst dann zu den Front-Ends der App Service-Umgebung v3 umgeleitet, wenn Sie den letzten Schritt der Migration abgeschlossen haben.

Nach Abschluss dieses Schritts wird der Anwendungsdatenverkehr weiterhin an die Front-Ends Ihrer alten App Service-Umgebung v2 und die eingehende IP-Adresse gesendet, die ihnen zugewiesen wurde. Tatsächlich werden Ihre Apps jedoch auf Workern in Ihrer neuen App Service-Umgebung v3 ausgeführt.

Hinweis

Aufgrund eines bekannten Fehlers können Webaufträge während des Hybridbereitstellungsschritts möglicherweise nicht gestartet werden. Wenn Sie Webaufträge verwenden, kann dieser Fehler zu App-Problemen/Ausfallzeiten führen. Öffnen Sie einen Supportfall, wenn Sie Fragen oder Bedenken zu diesem Problem haben.

Abrufen der eingehenden IP-Adresse für Ihre neue App Service-Umgebung v3 und Aktualisieren abhängiger Ressourcen

Die neue eingehende IP-Adresse wird angegeben, damit Sie neue Endpunkte mit Diensten wie Traffic Manager oder Azure Front Door einrichten und Ihre privaten DNS-Zonen aktualisieren können. Fahren Sie mit dem nächsten Schritt erst fort, wenn Sie diese Änderungen vorgenommen haben. Es kommt zu Downtime, wenn Sie abhängige Ressourcen nicht mit der neuen eingehenden IP-Adresse aktualisieren. Es liegt in Ihrer Verantwortung, sämtliche Ressourcen zu aktualisieren, die von der Änderung der IP-Adresse im Zusammenhang mit der neuen App Service-Umgebung v3 betroffen sind. Fahren Sie erst mit dem nächsten Schritt fort, wenn Sie alle erforderlichen Änderungen vorgenommen haben.

Umleiten des Kundendatenverkehrs, Validieren Ihrer App Service-Umgebung v3 und Abschließen der Migration

Der letzte Schritt besteht darin, den Datenverkehr zu den Front-Ends Ihrer neuen App Service-Umgebung v3 umzuleiten und die Migration abzuschließen. Bevor Sie diesen Schritt ausführen, sollten Sie Ihre neue App Service-Umgebung v3 überprüfen und alle erforderlichen Tests durchführen, um zu überprüfen, ob sie wie beabsichtigt funktioniert. Standardmäßig wird der Datenverkehr an das Front-End Ihrer App Service-Umgebung v2 weitergeleitet. Wenn Sie eine ILB-App Service-Umgebung v3 verwenden, können Sie Ihre App Service-Umgebung v3-Front-Ends testen, indem Sie Ihre private DNS-Zone mit der neuen eingehenden IP-Adresse aktualisieren. Wenn Sie eine ELB-App Service-Umgebung v3 verwenden, hängt der Testvorgang von Ihrer spezifischen Netzwerkkonfiguration ab. Eine einfache Methode zum Testen von ELB-Umgebungen besteht darin, die Datei „hosts“ so zu aktualisieren, dass die IP-Adresse für eingehenden Datenverkehr Ihrer neuen App Service-Umgebung v3 verwendet wird. Wenn Sie Ihren einzelnen Apps benutzerdefinierte Domänen zugewiesen haben, können Sie alternativ deren DNS so aktualisieren, dass es auf die neue IP-Adresse für eingehenden Datenverkehr verweist. Wenn Sie diese Änderung testen, können Sie Ihre App Service-Umgebung v3 vollständig überprüfen, bevor Sie den letzten Schritt der Migration initiieren, in der Ihre alte App Service-Umgebung gelöscht wird.

Sobald Sie bereit sind, Datenverkehr umzuleiten, können Sie den letzten Schritt der Migration abschließen. In diesem Schritt werden interne/Plattform-DNS-Einträge aktualisiert, um auf die IP-Adresse des Lastenausgleichs Ihrer neuen App Service-Umgebung v3 und auf die Front-Ends zu verweisen, die im Rahmen der Migration erstellt wurden. Änderungen sind innerhalb weniger Minuten wirksam. Es liegt in Ihrer Verantwortung, Ihre DNS-Einträge so zu aktualisieren, dass sie auf die neue eingehende IP-Adresse verweisen. Wenn Probleme oder Anwendungsdowntime auftreten, überprüfen Sie Ihre Cache- und TTL-Einstellungen. In diesem Schritt wird darüber hinaus Ihre alte App Service-Umgebung heruntergefahren und gelöscht. Ihre neue App Service-Umgebung v3 ist jetzt Ihre Produktionsumgebung.

Wichtig

Die Plattform garantiert eine Migration ohne Downtime. Ihre DNS-Einstellungen können jedoch während des DNS-Änderungsschritts zu Downtime führen. Dies kann auf Probleme im Zusammenhang mit TTL- und Cacheeinstellungen zurückzuführen sein, da der Datenverkehr nach der DNS-Änderung möglicherweise immer noch an Ihre alte App Service-Umgebung weitergeleitet wird. Überprüfen Sie Ihre DNS-Einstellungen, und stellen Sie sicher, dass Sie über eine niedrige TTL verfügen und dass Ihr DNS-Anbieter schnelle Weitergabe unterstützt. Wenn Sie einen hohen TTL-Wert haben, kann es während des DNS-Änderungsschritts zu Downtime kommen.

Hinweis

Es ist wichtig, diesen Schritt so schnell wie möglich abzuschließen. Wenn sich Ihre App Service-Umgebung im Hybridzustand befindet, kann sie keine Plattformupgrades und Sicherheitspatches empfangen, sodass sie anfälliger für Instabilität und Sicherheitsbedrohungen ist.

Sie haben 14 Tage Zeit, um diesen Schritt abzuschließen. Nach 14 Tagen schließt die Plattform die Migration automatisch ab und löscht Ihre alte Umgebung. Wenn Sie mehr Zeit benötigen, können Sie einen Supportfall öffnen, um Ihre Optionen zu besprechen.

Wenn Sie Probleme mit Ihrer neuen App Service-Umgebung v3 feststellen, führen Sie den Befehl zum Umleiten des Kundendatenverkehrs nicht aus. Mit diesem Befehl wird auch das Löschen Ihrer App Service-Umgebung v2 initiiert. Wenn Sie ein Problem finden, wenden Sie sich an den Support.

Verwenden der Funktion der Parallelmigration

Voraussetzungen

Stellen Sie sicher, dass Sie wissen, wie sich die Migration zur App Service-Umgebung v3 auf Ihre Anwendungen auswirkt. Sehen Sie sich den gesamten Migrationsprozess an, um den zeitlichen Ablauf des Prozesses zu verstehen und zu ermitteln, wann und wo Aktionen Ihrerseits erforderlich sind. Schauen Sie sich auch die FAQs an, die Ihnen einige Ihrer Fragen beantworten können.

Vergewissern Sie sich, dass keine Sperren für Ihr virtuelles Netzwerk, Ihre Ressourcengruppe, Ihre Ressource oder Ihr Abonnement vorhanden sind. Sperren blockieren Plattformvorgänge während der Migration.

Stellen Sie sicher, dass keine Azure-Richtlinien vorhanden sind, die Aktionen blockieren, die für die Migration erforderlich sind, einschließlich Subnetzänderungen und Azure App Service-Ressourcenerstellungen. Richtlinien, die Ressourcenänderungen und Erstellungen blockieren, können dazu führen, dass die Migration hängen bleibt oder fehlschlägt.

Da sich App Service-Umgebung v3 in einem anderen Subnetz in Ihrem virtuellen Netzwerk befindet, müssen Sie sicherstellen, dass Sie über ein verfügbares Subnetz in Ihrem virtuellen Netzwerk verfügen, das die Subnetzanforderungen für App Service-Umgebung v3 erfüllt. Das von Ihnen ausgewählte Subnetz muss zudem mit dem Subnetz kommunizieren können, in dem sich Ihre vorhandene App Service-Umgebung befindet. Stellen Sie sicher, dass die Kommunikation zwischen den beiden Subnetzen nicht blockiert wird. Wenn Sie kein verfügbares Subnetz haben, müssen Sie vor der Migration ein Subnetz erstellen. Wenn Sie ein neues Subnetz erstellen, müssen Sie möglicherweise den Adressraum des virtuellen Netzwerks erhöhen. Weitere Informationen finden Sie unter Erstellen eines virtuellen Netzwerks und des Subnetzes.

Da die Skalierung während der Migration blockiert wird, sollten Sie Ihre Umgebung auf die gewünschte Größe skalieren, bevor Sie die Migration starten. Wenn Sie Ihre Umgebung nach der Migration skalieren müssen, können Sie dies nach Abschluss der Migration tun. Wenn die automatische Skalierung aktiviert ist und wenn vor dem Start der Migration ein Skalierungsereignis auftritt, wird die Migration blockiert, bis das Skalierungsereignis abgeschlossen ist. Sie müssen die automatische Skalierung deaktivieren, bevor Sie die Migration starten, um dieses Problem zu vermeiden.

Führen Sie die hier beschriebenen Schritte der Reihe nach aus, da Sie Azure-REST-API-Aufrufe ausführen. Es wird empfohlen, diese API-Aufrufe mithilfe der Azure CLI auszuführen. Informationen zu anderen Methoden finden Sie in der Azure-REST-API-Referenz.

Für dieses Handbuch können Sie die Azure CLI installieren oder Azure Cloud Shell verwenden, und verwenden Sie eine Bash-Shell.

Hinweis

Es wird empfohlen, dass Sie eine Bash-Shell verwenden, um die in diesem Handbuch angegebenen Befehle auszuführen. Die Befehle sind möglicherweise nicht mit PowerShell-Konventionen und Escapezeichen kompatibel.

Wichtig

Während der Migration zeigt das Azure-Portal möglicherweise falsche Informationen zu Ihrer App Service-Umgebung und Ihren Apps an. Wechseln Sie nicht zur Migrationserfahrung im Azure-Portal, da das Feature für die parallele Migration dort nicht verfügbar ist. Wir empfehlen Ihnen, Azure CLI zu verwenden, um den Status Ihrer Migration zu überprüfen. Wenn Sie Fragen zum Status Ihrer Migration oder Ihrer Apps haben, wenden Sie sich an den Support.

1. Auswählen des Subnetzes für Ihre neue App Service-Umgebung v3

Wählen Sie ein Subnetz in Ihrer App Service-Umgebung v3 aus, das die Subnetzanforderungen für App Service-Umgebung v3 erfüllt. Notieren Sie sich den Namen des ausgewählten Subnetzes. Dieses Subnetz muss sich von dem Subnetz unterscheiden, in dem sich die vorhandene App Service-Umgebung befindet.

2. Abrufen der ID für Ihre App Service-Umgebung

Führen Sie die folgenden Befehle aus, um die ID für Ihre App Service-Umgebung abzurufen und als Umgebungsvariable zu speichern. Ersetzen Sie die Platzhalter für den Namen und Ressourcengruppen durch Ihre Werte für die App Service-Umgebung, die Sie migrieren möchten. ASE_RG und VNET_RG sind identisch, wenn sich Ihr virtuelles Netzwerk und die App Service-Umgebung in derselben Ressourcengruppe befinden.

ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)

3. Überprüfen, ob die Migration unterstützt wird

Mit dem folgenden Befehl wird überprüft, ob die Migration Ihrer App Service-Umgebung unterstützt wird. Mit diesem Befehl wird auch überprüft, ob Ihre App Service-Umgebung die für die Migration unterstützte Buildversion verwendet. Wenn die App Service-Umgebung nicht die unterstützte Buildversion verwendet, müssen Sie das Upgrade selbst starten. Weitere Informationen zum Upgrade vor der Migration finden Sie unter Überprüfen, ob die Migration mithilfe des Features für die parallele Migration für Ihre App Service-Umgebung unterstützt wird.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"

Wenn keine Fehler auftreten, wird Ihre Migration unterstützt, und Sie können mit dem nächsten Schritt fortfahren.

Wenn Sie ein Upgrade starten müssen, um Ihre App Service-Umgebung auf die unterstützte Buildversion zu aktualisieren, die je nach Größe Ihrer Umgebung 8-12 Stunden oder länger dauern kann, führen Sie den folgenden Befehl aus. Führen Sie diesen Befehl nur aus, wenn beim Überprüfungsschritt ein Fehler auftritt und Sie angewiesen werden, die App Service-Umgebung zu aktualisieren.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"

4. Generieren von ausgehenden IP-Adressen für Ihre neue App Service-Umgebung v3

Führen Sie den folgenden Befehl aus, um neue ausgehende IP-Adressen zu erstellen. Dieser Schritt dauert ungefähr 15 Minuten. Nehmen Sie während dieser Zeit keine Skalierung und keine Änderungen an Ihrer vorhandenen App Service-Umgebung vor.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01"

Führen Sie den folgenden Befehl aus, um den Status dieses Schritts zu überprüfen:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.status

Während der Schritt ausgeführt wird, sehen Sie den Status Migrating. Wenn der Status Ready angezeigt wird, führen Sie den folgenden Befehl aus, um Ihre neuen ausgehenden IP-Adressen anzuzeigen. Werden die neuen IP-Adressen nicht sofort angezeigt, warten Sie einige Minuten, und versuchen Sie es noch einmal.

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses

5. Aktualisieren abhängiger Ressourcen mit neuen ausgehenden IP-Adressen

Aktualisieren Sie unter Verwendung der neuen ausgehenden IP-Adressen alle Ihrer Ressourcen oder Netzwerkkomponenten, um sicherzustellen, dass Ihre neue Umgebung nach Beginn der Migration wie vorgesehen funktioniert. Es liegt in Ihrer Verantwortung, alle notwendigen Aktualisierungen vorzunehmen. Die neuen ausgehenden IPs werden verwendet, sobald die App Service-Umgebung v3 während des Migrationsschritts erstellt wurde. Wenn Sie beispielsweise über ein benutzerdefiniertes Domänensuffix und einen Azure Key Vault verfügen und Zugriffsbeschränkungen mit einer Firewall verwalten, müssen Sie die Firewall von Azure Key Vault aktualisieren, um entweder nur die neuen ausgehenden IPs oder das gesamte neue Subnetz zuzulassen.

6. Delegieren des Subnetzes Ihrer App Service-Umgebung

Die App Service-Umgebung v3 setzt voraus, dass das Subnetz, in dem sie sich befindet, über eine einzelne Delegierung von Microsoft.Web/hostingEnvironments verfügt. In früheren Versionen war diese Delegierung nicht erforderlich. Sie müssen bestätigen, dass Ihr Subnetz ordnungsgemäß delegiert ist, und die Delegierung (bei Bedarf) vor der Migration aktualisieren. Sie können die Delegierung entweder durch Ausführen des folgenden Befehls oder durch Navigieren zum Subnetz im Azure-Portal aktualisieren.

az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments

7. Bestätigen, dass keine Sperren für das virtuelle Netzwerk vorhanden sind

Sperren für virtuelle Netzwerke blockieren Plattformvorgänge während der Migration. Wenn für Ihr virtuelles Netzwerk Sperren vorhanden sind, müssen Sie sie vor der Migration entfernen. Bei Bedarf können Sie die Sperren nach Abschluss der Migration wieder hinzufügen.

Verwenden Sie den folgenden Befehl, um zu überprüfen, ob für Ihr virtuelles Netzwerk Sperren vorhanden sind:

az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

Löschen Sie alle vorhandenen Sperren mit dem folgenden Befehl:

az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

Informationen zu verwandten Befehlen, mit denen Sie überprüfen können, ob für Ihr Abonnement oder Ihre Ressourcengruppe Sperren vorhanden sind, finden Sie in der Azure CLI-Referenz zu Sperren.

8. Vorbereiten Ihrer Konfigurationen

Wenn Ihre vorhandene App Service-Umgebung ein benutzerdefiniertes Domänensuffix verwendet, müssen Sie dieses während des Migrationsprozesses für Ihre neue App Service-Umgebung v3-Ressource konfigurieren. Die Migration schlägt fehl, wenn Sie kein benutzerdefiniertes Domänensuffix konfigurieren, derzeit jedoch eines verwenden. Weitere Informationen zu benutzerdefinierten Domänensuffixen der App Service-Umgebung v3 (einschließlich Anforderungen, schrittweisen Anleitungen und bewährten Methoden) finden Sie unter Benutzerdefiniertes Domänensuffix für App Service-Umgebungen.

Hinweis

Wenn Sie ein benutzerdefiniertes Domänensuffix konfigurieren, stellen Sie beim Hinzufügen der Netzwerkberechtigungen für Ihren Azure-Schlüsseltresor sicher, dass Ihr Schlüsseltresor den Zugriff über das neue Subnetz Ihrer App Service-Umgebung v3 zulässt. Wenn Sie über einen privaten Endpunkt auf Ihren Schlüsseltresor zugreifen, stellen Sie sicher, dass Sie den privaten Zugriff ordnungsgemäß mit dem neuen Subnetz konfiguriert haben. Wenn Sie diesen Zugriff vor der Migration nicht ordnungsgemäß festlegen können, treten Ausfallzeiten auf.

Sie können Ihre neue App Service-Umgebung v3-Zone redundant machen, wenn sich Ihre vorhandene Umgebung in einer Region befindet, die Zonenredundanz unterstützt. Die Zonenredundanz kann durch Festlegen der Eigenschaft zoneRedundant auf true konfiguriert werden. Zonenredundanz ist eine optionale Konfiguration. Diese Konfiguration kann nur während der Erstellung Ihrer neuen App Service-Umgebung v3 festgelegt werden und kann zu einem späteren Zeitpunkt nicht mehr entfernt werden.

Um diese Konfigurationen festzulegen, einschließlich der Identifizierung des zuvor ausgewählten Subnetzes, erstellen Sie eine Datei namens parameters.json mit den folgenden Details basierend auf Ihrem Szenario. Achten Sie darauf, das neue Subnetz zu verwenden, das Sie für die neue App Service-Umgebung v3 ausgewählt haben. Schließen Sie die Eigenschaften für ein benutzerdefiniertes Domänensuffix nicht ein, wenn dieses Feature nicht für Ihre Migration relevant ist. Achten Sie auf den Wert der zoneRedundant-Eigenschaft, und legen Sie sie entsprechend Ihrer Resilienzanforderung fest.

Wenn Sie ohne benutzerdefiniertes Domänensuffix migrieren, verwenden Sie den folgenden Code:

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>"
    }
}

Wenn Sie eine benutzerseitig zugewiesene verwaltete Identität für die Konfiguration des benutzerdefinierten Domänensuffixes nutzen, verwenden Sie den folgenden Code:

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
        }
    }
}

Wenn Sie eine systemseitig zugewiesene verwaltete Identität für die Konfiguration des benutzerdefinierten Domänensuffixes nutzen, verwenden Sie den folgenden Code:

{
    "properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "SystemAssigned"
        }
    }
}

9. Migrieren zu App Service-Umgebung v3 und Überprüfen des Status

Nachdem Sie alle vorherigen Schritte durchgeführt haben, können Sie mit der Migration beginnen. Vergewissern Sie sich, dass Sie die Auswirkungen der Migration.

Dieser Schritt dauert drei bis sechs Stunden. Während dieser Zeit gibt es keine Anwendungsausfallzeiten, wenn Sie die vorherigen Schritte befolgt haben. Skalierung, Bereitstellungen und Änderungen Ihrer vorhandenen App Service-Umgebung werden während dieses Schritts blockiert.

Hinweis

Aufgrund eines bekannten Fehlers können Webaufträge während des Hybridbereitstellungsschritts möglicherweise nicht gestartet werden. Wenn Sie Webaufträge verwenden, kann dieser Fehler zu App-Problemen/Ausfallzeiten führen. Öffnen Sie einen Supportfall, wenn Sie Fragen oder Bedenken zu diesem Problem haben.

Führen Sie den folgenden Befehl aus, um die Migration zu starten:

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json

Führen Sie den folgenden Befehl aus, um den Status der Migration zu überprüfen:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

Wenn der Status MigrationPendingDnsChange angezeigt wird, ist die Migration abgeschlossen, und Sie verfügen über eine App Service-Umgebung v3-Ressource. Ihre Apps werden jetzt in Ihrer neuen Umgebung und in Ihrer alten Umgebung ausgeführt.

Führen Sie den folgenden Befehl aus, um die Details Ihrer neuen Umgebung abzurufen:

az appservice ase show --name $ASE_NAME --resource-group $ASE_RG

Wichtig

Während der Migration sowie während des Schritts MigrationPendingDnsChange zeigt das Azure-Portal falsche Informationen zu Ihrer App Service-Umgebung und Ihren Apps an. Verwenden Sie die Azure CLI, um den Status Ihrer Migration zu überprüfen. Wenn Sie Fragen zum Status Ihrer Migration oder Ihrer Apps haben, wenden Sie sich an den Support.

Hinweis

Wenn Ihre Migration ein benutzerdefiniertes Domänensuffix enthält, wird die Konfiguration des benutzerdefinierten Domänensuffixes möglicherweise nach Abschluss der Migration aufgrund eines bekannten Fehlers als beeinträchtigt angezeigt. Ihre App Service-Umgebung sollte weiterhin wie erwartet funktionieren. Der beeinträchtigte Zustand sollte sich nach sechs bis acht Stunden ändern. Wenn die Konfiguration nach acht Stunden weiterhin beeinträchtigt ist oder Ihr benutzerdefiniertes Domänensuffix nicht funktioniert, wenden Sie sich an den Support.

10. Abrufen der eingehenden IP-Adressen für Ihre neue App Service-Umgebung v3 und Aktualisieren abhängiger Ressourcen

Sie verfügen in dieser Phase im Migrationsprozess über zwei Gruppen von Front-Ends der App Service-Umgebung, und beide Gruppen sind in der Lage, den Anwendungsdatenverkehr zu verarbeiten. Ihr DNS wird nicht geändert. Der Datenverkehr wird daher standardmäßig an die Front-Ends der alten App Service-Umgebung gesendet. Sie müssen alle abhängigen Ressourcen so aktualisieren, dass sie die neue eingehende IP-Adresse für Ihre neue App Service-Umgebung v3 verwenden. Bei internen App Service-Umgebungen (ILB) müssen Sie die privaten DNS-Zonen so aktualisieren, dass sie auf die neue eingehende IP-Adresse verweisen.

Sie können die neue eingehende IP-Adresse für Ihre neue App Service-Umgebung v3 mithilfe des folgenden Befehls abrufen, der dem Lastenausgleichstyp Ihrer App Service-Umgebung entspricht. Es liegt in Ihrer Verantwortung, alle notwendigen Aktualisierungen vorzunehmen.

Für ILB App Service-Umgebungen rufen Sie die private eingehende IP-Adresse mit dem folgenden Befehl ab:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses

Für ELB App Service-Umgebungen rufen Sie die öffentliche eingehende IP-Adresse mit dem folgenden Befehl ab:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses

Wichtig

Wenn Ihre Migration ein benutzerdefiniertes Domänensuffix enthält, unterscheidet sich das Verhalten des Standardhostnamens für App Service--Umgebung v3 von dem für App Service-Umgebung v2. In der App Service-Umgebung v3 verwendet der Standardhostname immer das Standarddomänensuffix und wird im Format APP-NAME.ASE-NAME.appserviceenvironment.net angegeben. Überprüfen Sie alle abhängigen Ressourcen, z. B. die App Gateway-Instanz, die die Hostnamen Ihrer Apps verwenden, und stellen Sie sicher, dass sie an dieses Verhalten angepasst werden. Weitere Informationen zu Featureunterschieden bei App Service-Umgebungen der verschiedenen Versionen finden Sie unter Versionsvergleich von App Service-Umgebungen.

11. Umleiten des Kundendatenverkehrs, Überprüfen von App Service-Umgebung v3 und Abschließen der Migration

In diesem Schritt können Sie Ihre neue App Service-Umgebung v3 testen und überprüfen.

Wichtig

Sie haben 14 Tage Zeit, um diesen Schritt abzuschließen. Nach 14 Tagen schließt die Plattform die Migration automatisch ab und löscht Ihre alte Umgebung. Wenn Sie mehr Zeit benötigen, können Sie einen Supportfall öffnen, um Ihre Optionen zu besprechen.

Nachdem Sie sich vergewissert haben, dass Ihre Apps erwartungsgemäß funktionieren, können Sie die Migration abschließen, indem Sie den folgenden Befehl ausführen. Mit diesem Befehl wird außerdem Ihre alte Umgebung gelöscht.

Wenn Sie Probleme feststellen oder sich an diesem Punkt entscheiden, dass Sie die Migration nicht mehr fortsetzen möchten, wenden Sie sich an den Support, um Ihre Optionen zu besprechen. Führen Sie den DNS-Änderungsbefehl nicht aus, da dieser Befehl die Migration abschließt.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"

Führen Sie den folgenden Befehl aus, um den Status dieses Schritts zu überprüfen:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

Während dieses Schritts erhalten Sie den Status CompletingMigration. Wenn Sie den Status MigrationCompletederhalten, ist der Schritt der Datenverkehrsumleitung fertig und die Migration abgeschlossen.

Häufige Ursachen von Problemen bei der Migration mithilfe des Parallelmigrationsfeatures

Im Folgenden finden Sie Beispiele für häufige Ursachen von Problemen, die Kunden beim Migrieren mithilfe des Parallelmigrationsfeatures feststellen. Sie sollten diese Bereiche überprüfen, um sicherzustellen, dass während oder nach dem Migrationsprozess keine Ausfallzeiten oder Dienstausfälle auftreten.

• Azure Key Vault sollte Datenverkehr von den neuen ausgehenden IPs/Subnetz zulassen.
• Die beiden Subnetze sollten in beide Richtungen miteinander kommunizieren können. Kunden lassen in der Regel Datenverkehr vom alten zum neuen Subnetz zu, vergessen jedoch, Datenverkehr vom neuen zum alten Subnetz zuzulassen.
• Das App-Gateway sollte mit den neuen IP-Adressen aktualisiert werden.
• DNS-Einträge sollten mit den neuen IP-Adressen aktualisiert werden.
• Wenn Sie hartcodierte IP-Adressen in Ihren Anwendungen haben, müssen Sie sie mit den neuen IP-Adressen aktualisieren.
• Routentabellen sollten mit allen neuen Routen aktualisiert werden.

Preiskalkulation

Es entstehen keine Kosten für die Migration Ihrer App Service-Umgebung. Ihnen wird jedoch sowohl App Service-Umgebung v2 als auch die neue App Service-Umgebung v3 in Rechnung gestellt, sobald Sie den Migrationsprozess starten. Die alte App Service-Umgebung v2 wird nicht mehr in Rechnung gestellt, wenn Sie den letzten Migrationsschritt abschließen, in dem die alte Umgebung gelöscht wird. Sie sollten die Überprüfung so schnell wie möglich abschließen, um zu verhindern, dass zu hohe Gebühren anfallen. Weitere Informationen zu den Preisen für die App Service-Umgebung v3 finden Sie in den Preisdetails.

Wenn Sie von früheren Versionen zu App Service-Umgebung v3 migrieren, sollten Sie Szenarien in Betracht ziehen, die ihre monatlichen Kosten möglicherweise reduzieren können. Berücksichtigen Sie Reservierungen und Sparpläne, um Ihre Kosten weiter zu senken. Informationen zu Kosteneinsparungsmöglichkeiten finden Sie unter Kosteneinsparungsmöglichkeiten nach dem Upgrade auf App Service-Umgebung v3.

Hinweis

Aufgrund der Unterschiede zwischen den Tarifen „App Service (isoliert)“ und „V2 Isoliert“ sind Ihre Apps nach der Migration möglicherweise überdimensioniert, da der Tarif „V2 Isoliert“ mehr Arbeitsspeicher und CPU pro entsprechender Instanzgröße bietet. Nach Abschluss der Migration haben Sie die Möglichkeit, Ihre Umgebung bedarfsgerecht zu skalieren. Weitere Informationen finden Sie in den SKU-Details.

Ihre App Service-Pläne herunterskalieren

Die App Service Plan-SKUs, die für App Service-Umgebung v3 verfügbar sind, werden auf der Ebene „Isoliert v2 (Iv2)“ ausgeführt. Die Anzahl der Kerne und die RAM-Menge werden im Vergleich zur Ebene „Isoliert“ effektiv pro entsprechender Ebene verdoppelt. Bei der Migration werden Ihre App Service-Pläne in die entsprechende Ebene konvertiert. Beispielsweise werden Ihre I2-Instanzen in I2v2 konvertiert. Während I2 über zwei Kerne und 7 GB RAM verfügt, verfügt I2v2 über vier Kerne und 16 GB RAM. Wenn Sie erwarten, dass Ihre Kapazitätsanforderungen unverändert bleiben, wurden Sie überdimensioniert und zahlen für Compute- und Arbeitsspeicher, den Sie nicht verwenden. In diesem Szenario können Sie Ihre I2v2-Instanz auf I1v2 herunterskalieren und verfügen am Ende über eine ähnliche Anzahl von Kernen und Arbeitsspeicher wie zuvor.

Häufig gestellte Fragen

• Was, wenn die Migration meiner App Service-Umgebung derzeit nicht unterstützt wird?
  Sie können die Migration mithilfe des Features für die parallele Migration zu diesem Zeitpunkt nicht ausführen. Wenn Sie über eine nicht unterstützte Umgebung verfügen und sofort migrieren möchten, finden Sie weitere Informationen unter den manuellen Migrationsoptionen.
• Wie wähle ich aus, welche Migrationsoption die richtige für mich ist?
  Sehen Sie sich die Entscheidungsstruktur für den Migrationspfad an, um zu entscheiden, welche Option für Ihren Anwendungsfall die beste ist.
• Woher weiß ich, ob ich das Feature für die parallele Migration verwenden sollte?
  Die Feature für die parallele Migration eignet sich am besten für Kunden, die zu App Service-Umgebung v3 migrieren möchten, aber keine Anwendungsdowntime erlauben dürfen. Da ein neues Subnetz für Ihre neue Umgebung verwendet wird, müssen einige Netzwerkaspekte beachtet werden, einschließlich neuer IP-Adressen. Wenn Sie Downtime unterstützen können, sehen Sie sich die Direktmigrationsfunktion, die nur minimale Konfigurationsänderungen beinhaltet, oder die Optionen zur manuellen Migration an. Die Direktmigrationsfunktion erstellt Ihre App Service-Umgebung v3 im selben Subnetz wie Ihre vorhandene Umgebung und verwendet dieselbe Netzwerkinfrastruktur.
• Kommt es während der Migration zu Ausfallzeiten?
  Die Plattform garantiert, dass während des parallelen Migrationsprozesses keine Downtime auftritt. Ihre DNS-Einstellungen können jedoch während des DNS-Änderungsschritts zu Downtime führen. Dies kann auf Probleme im Zusammenhang mit TTL- und Cacheeinstellungen zurückzuführen sein, da der Datenverkehr nach der DNS-Änderung möglicherweise immer noch an Ihre alte App Service-Umgebung weitergeleitet wird. Überprüfen Sie Ihre DNS-Einstellungen, und stellen Sie sicher, dass Sie über eine niedrige TTL verfügen und dass Ihr DNS-Anbieter schnelle Weitergabe unterstützt.
• Muss ich nach der Migration etwas tun, damit meine Apps in der neuen App Service-Umgebung ausgeführt werden?
  Nein, alle Apps, die in der alten Umgebung ausgeführt wurden, werden automatisch zur neuen Umgebung migriert und wie zuvor ausgeführt. Es ist keine Benutzereingabe erforderlich.
• Was passiert, wenn meine App Service-Umgebung ein benutzerdefiniertes Domänensuffix hat?
  Das Feature für die parallele Migration unterstützt dieses Migrationsszenario.
• Was passiert, wenn meine App Service-Umgebung an eine Zone angeheftet ist?
  Das Feature für die parallele Migration unterstützt dieses Migrationsszenario derzeit nicht. Wenn Sie über eine zonengebundene App Service-Umgebung verfügen und sofort migrieren möchten, finden Sie weitere Informationen unter Optionen für die manuelle Migration.
• Was geschieht, wenn mein App Service-Umgebung über IP-SSL-Adressen verfügt?
  IP-SSL wird in der App Service-Umgebung v3 nicht unterstützt. Sie müssen alle IP-SSL-Bindungen entfernen, bevor Sie die Migration mithilfe des Migrationsfeatures oder einer der manuellen Optionen durchführen. Wenn Sie beabsichtigen, das Feature für die parallele Migration zu nutzen, haben Sie, sobald Sie alle IP-SSL-Bindungen entfernt haben, die Validierungsprüfung bestanden und können mit der automatischen Migration fortfahren.
• Welche Eigenschaften meiner App Service-Umgebung werden sich ändern?
  Sie befinden sich auf App Service-Umgebung v3. Informieren Sie sich daher über die Features und Featureunterschiede im Vergleich zu früheren Versionen. Sowohl die eingehenden als auch die ausgehenden IP-Adressen ändern sich bei Verwendung des Features für die parallele Migration. Beachten Sie, dass es für ELB-App Service-Umgebungen zuvor nur eine IP-Adresse für eingehende und ausgehende Verbindungen gab. Für die App Service-Umgebung v3 gibt es separate Adressen. Weitere Informationen finden Sie unter Netzwerkfunktionalität in der App Service-Umgebung v3. Einen vollständigen Vergleich der App Service-Umgebungsversionen finden Sie unter Vergleich der App Service-Umgebungsversionen.
• Was geschieht, wenn die Migration fehlschlägt oder während der Migration ein unerwartetes Problem auftritt?
  Wenn es zu einem unerwarteten Problem kommt, stehen Supportteams bereit. Es wird empfohlen, Entwicklungsumgebungen zu migrieren, bevor Sie Produktionsumgebungen nutzen, um den Migrationsprozess kennenzulernen und zu sehen, wie er sich auf Ihre Workloads auswirkt.
• Was geschieht mit meiner alten App Service-Umgebung?
  Wenn Sie eine App Service-Umgebung mithilfe des Features für die parallele Migration migrieren möchten, wird Ihre alte Umgebung bis zum letzten Schritt im Migrationsprozess verwendet. Nachdem Sie den letzten Schritt abgeschlossen haben, werden die alte Umgebung und alle darin gehosteten Apps heruntergefahren und gelöscht. Auf Ihre alte Umgebung kann nicht mehr zugegriffen werden. Eine Wiederherstellung der alten Umgebung an diesem Punkt ist nicht möglich.
• Was geschieht mit meinen Ressourcen der App Service-Umgebung v1/v2 nach dem 31. August 2024?
  Wenn Sie nach dem 31. August 2024 nicht zu App Service-Umgebung v3 migriert haben, sind Ihre App Service-Umgebungen v1/v2 und die darin bereitgestellten Apps nicht mehr verfügbar. App Service-Umgebung v1/v2 wird auf App Service-Skalierungseinheiten gehostet, die in einer Cloud Services (klassisch)-Architektur ausgeführt werden, die am 31. August 2024 eingestellt wird. Aus diesem Grund ist App Service-Umgebung v1/v2 nach diesem Datum nicht mehr verfügbar. Migrieren Sie zu App Service-Umgebung v3, um die Funktionsfähigkeit Ihrer Apps zu gewährleisten, oder speichern bzw. sichern Sie alle Ressourcen oder Daten, die Sie erhalten müssen.

Nächste Schritte

Netzwerkfunktionalität in der App Service-Umgebung v3

Verwenden der App Service-Umgebung v3

Benutzerdefiniertes Domänensuffix