Migration zu App Service-Umgebung v3 mithilfe der Direktmigrationsfunktion
Hinweis
Die in diesem Artikel beschriebene Migrationsfunktion wird für die automatisierte Migration von App Service-Umgebung v1 und 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 zum Feature für die parallele Migration suchen, lesen Sie Migrieren zu App Service-Umgebung v3 mithilfe des Features für die parallele Migration. 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 die App Service-Umgebung (Version 3).
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.
Die Direktmigrationsfunktion automatisiert Ihre Migration zu App Service-Umgebung v3, indem Sie Ihre vorhandene App Service-Umgebung im selben Subnetz aktualisieren. Diese Migrationsoption eignet sich am besten für Kunden, die mit minimalen Änderungen an ihren Netzwerkkonfigurationen zu App Service-Umgebung v3 migrieren möchten. Sie müssen außerdem etwa eine Stunde Anwendungsdowntime verkraften können. Wenn Sie keine Downtime unterstützen können, sehen Sie sich die Parallelmigrationsfunktion oder die Optionen für die manuelle Migration an.
Wichtig
Es wird empfohlen, dieses Feature zuerst für Entwicklungsumgebungen zu verwenden, bevor Sie Produktionsumgebungen migrieren, um 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
In folgenden Regionen werden von der Direktmigrationsfunktion derzeit keine Migrationen zur Version 3 der App Service-Umgebung unterstützt:
Microsoft Azure von 21Vianet
- China, Osten 2
- China, Norden 2
Die folgenden App Service-Umgebungskonfigurationen können mithilfe der Direktmigrationsfunktion migriert werden. In der Tabelle wird die v3-Konfiguration der App Service-Umgebung aufgeführt, wenn Sie die Direktmigrationsfunktion basierend auf Ihrer vorhandenen App Service-Umgebung verwenden. Alle unterstützten App Service-Umgebungen können mithilfe der Direktmigrationsfunktion zu einer zonenredundanten App Service-Umgebung v3 migriert werden, solange sich die Umgebung in einer Region befindet, die Zonenredundanz unterstützt. Sie können Zonenredundanz während des Migrationsprozesses konfigurieren.
| 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 |
| ILB-App Service-Umgebung v1 | ILB-App Service-Umgebung v3 |
| ELB-App Service-Umgebung v1 | ELB-App Service-Umgebung v3 |
| App Service-Umgebung v1 mit ILB und benutzerdefiniertem Domänensuffix | ILB-App Service-Umgebung v3 mit benutzerdefiniertem Domänensuffix |
| An eine Zone geheftete App Service-Umgebung v2 | App Service-Umgebung v3 mit optionaler Zonenredundanz-Konfiguration |
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.
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.
Einschränkungen der Direktmigrationsfunktion
Bei der Verwendung der Direktmigrationsfunktion gelten die folgenden Einschränkungen:
- Ihre neue App Service-Umgebung v3 befindet sich im vorhandenen Subnetz, das für Ihre alte Umgebung verwendet wurde.
- 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.
Die Version 3 der App Service-Umgebung unterstützt folgende Funktionen nicht, die Sie möglicherweise in Ihrer aktuellen App Service-Umgebung von Version 1 oder 2 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 von der Direktmigrationsfunktion 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 in einem klassischen virtuellen Netzwerk
- ELB-App Service-Umgebung v2 mit IP-SSL-Adressen
- ELB-App Service-Umgebung v1 mit IP-SSL-Adressen
- 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 der Direktmigration zu bestätigen. Wenn Ihr Szenario nicht alle Validierungsprüfungen besteht, können Sie zu diesem Zeitpunkt keine Migration mithilfe der Direktmigrationsfunktion 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 möglicherweise 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 VNets können nicht mithilfe der Direktmigrationsfunktion 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 die Direktmigrationsfunktion in Ihrer Region verfügbar ist. |
| Die Migration kann nicht in dieser ASE aufgerufen werden, wenden Sie sich an den Support, um Hilfe bei der Migration zu erhalten. | Für die Migration dieser App Service-Umgebung müssen Sie den Support in Anspruch nehmen. Dieses Problem ist möglicherweise auf benutzerdefinierte Einstellungen zurückzuführen, die von dieser Umgebung verwendet werden. | Öffnen Sie einen Supportfall, um mit dem Support zusammenzuarbeiten, um Ihr Problem zu beheben. |
| 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 Migrationsfeature migriert werden. | Entfernen Sie IP-SSL aus allen Ihren Apps in der App Service-Umgebung, um das Migrationsfeature zu aktivieren. |
| 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 Migration zu ASEv3 ist für diese ASE unzulässig. | Sie können die Migration mithilfe des Migrationsfeatures nicht ausführen. | Migrieren Sie mithilfe einer der manuellen Migrationsoptionen. |
| 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. |
<ZoneRedundant><DedicatedHosts><ASEv3/ASE> ist an diesem Standort nicht verfügbar. |
Diese Fehlermeldung wird angezeigt, wenn Sie versuchen, eine App Service-Umgebung in einer Region zu migrieren, die eines der von Ihnen angeforderten Features nicht unterstützt. | Migrieren Sie mithilfe einer der manuellen Migrationsoptionen, wenn Sie sofort migrieren möchten. Warten Sie andernfalls, bis das Migrationsfeature diese App Service-Umgebungskonfiguration unterstützt. |
| 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. |
| 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. |
| 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, um die Migration zuzulassen. |
Übersicht zum Migrationsprozess mithilfe der Direktmigrationsfunktion
Die Direktmigration besteht aus einer Reihe von Schritten, die in der Reihenfolge 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 Features für die direkte Migration für Ihre App Service-Umgebung unterstützt wird
Die Plattform überprüft, ob Ihre App Service-Umgebung mithilfe des Features für die direkte Migration migriert werden kann. Wenn die App Service-Umgebung nicht alle Validierungsprüfungen besteht, können Sie zu diesem Zeitpunkt keine Migration mithilfe der Direktmigrationsfunktion 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 direkte 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.
Generieren von IP-Adressen für Ihre neue App Service-Umgebung v3
Die Plattform erstellt die neue eingehende IP-Adresse (wenn Sie eine ELB-App Service-Umgebung migrieren) und 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, erhalten Sie die neuen IP-Adressen, die von Ihrer zukünftigen App Service-Umgebung v3 verwendet werden. Diese neuen IP-Adressen haben keine Auswirkungen auf Ihre vorhandene Umgebung. Die von Ihrer vorhandenen Umgebung verwendeten IPs werden weiterhin verwendet, bis Ihre vorhandene Umgebung während des eigentlichen Migrationsschritts heruntergefahren wird.
Aktualisieren abhängiger Ressourcen mit neuen IP-Adressen
Sobald die neuen IP-Adressen erstellt wurden, verfügen Sie über die neuen zum Internet ausgehenden öffentlichen Standardadressen. Zur Vorbereitung der Migration können Sie alle externen Firewalls, DNS-Routing, Netzwerksicherheitsgruppen und alle anderen Ressourcen anpassen, die auf diesen IP-Adressen basieren. Für ELB-App Service-Umgebungen erhalten Sie auch die neue eingehende IP-Adresse, mit der Sie neue Endpunkte mit Diensten wie Traffic Manager oder Azure Front Door einrichten können. 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. 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 oder an eine andere Ressource delegiert ist.
Überprüfen von Änderungen an der Instanzgröße
Ihre App Service-Pläne werden im Rahmen der Migration von der Isolated-Ebene in die entsprechende Isolated v2-Ebene konvertiert. „I2“ wird beispielsweise in „I2v2“ konvertiert. Ihre Apps sind nach der Migration möglicherweise überdimensioniert, da die Isolated v2-Ebene 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.
Auswählen der v3-Konfigurationen der App Service-Umgebung
Ihre App Service-Umgebung v3 kann in Verfügbarkeitszonen in den Regionen bereitgestellt werden, die dies unterstützen. Diese Architektur wird auch als Zonenredundanz bezeichnet. Zonenredundanz kann nur während der Erstellung der App Service-Umgebung konfiguriert werden. Wenn Ihre neue App Service-Umgebung v3 zonenredundant sein soll, aktivieren Sie die Konfiguration während des Migrationsprozesses. Eine App Service-Umgebung, die die Direktmigrationsfunktion zum Migrieren verwenden, kann als zonenredundant konfiguriert werden, solange Sie eine Region verwenden, die Zonenredundanz für die App Service-Umgebung v3 unterstützt. Wenn Ihre vorhandene Umgebung eine Region verwendet, die keine Zonenredundanz unterstützt, ist die Konfigurationsoption deaktiviert, und Sie können sie nicht konfigurieren. Die Direktmigrationsfunktion unterstützt keine Änderung von Regionen. Wenn Sie eine andere Region verwenden möchten, verwenden Sie eine der manuellen Migrationsoptionen.
Hinweis
Die Aktivierung von Zonenredundanz kann zu zusätzlichen Kosten führen. Weitere Informationen finden Sie im Zonenredundanz-Preismodell.
Wenn Ihre vorhandene App Service-Umgebung ein benutzerdefiniertes Domänensuffix verwendet, werden Sie aufgefordert, ein benutzerdefiniertes Domänensuffix für Ihre neue App Service-Umgebung v3 konfigurieren. Sie müssen den benutzerdefinierten Domänennamen, die verwaltete Identität und das Zertifikat angeben. 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änensuffixes für die App Service-Umgebung. Sie müssen ein benutzerdefiniertes Domänensuffix für Ihre neue Umgebung auch dann konfigurieren, wenn Sie es nicht mehr verwenden möchten. 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.
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.
Die Migration erfordert ein Dienstfenster von drei bis sechs Stunden für Migrationen von App Service-Umgebung v2 zu v3. Je nach Umgebungsgröße für Migrationen von v1 zu v3 ist ein Dienstfenster von bis zu sechs Stunden erforderlich. In seltenen Fällen, in denen ein manuelles Eingreifen des Serviceteams erforderlich ist, kann das Servicefenster erweitert werden. Während der Migration werden Skalierungs- und Umgebungskonfigurationen blockiert, und die folgenden Ereignisse treten auf:
- Die vorhandene App Service-Umgebung wird heruntergefahren und durch die neue App Service-Umgebung v3 ersetzt.
- Alle App Service-Pläne in der App Service-Umgebung werden von der Isolated-Ebene in die Isolated v2-Ebene konvertiert.
- Alle Apps Ihrer App Service-Umgebung werden vorübergehend gestoppt. Während dieses Zeitraums sollten Sie mit einer Ausfallzeit von etwa einer Stunde rechnen.
- Wenn Sie keine Downtime erlauben dürfen, sehen Sie sich das Feature für die parallele Migration oder die Migrationsalternativen an.
- Die öffentlichen Adressen, die von der App Service-Umgebung verwendet werden, ändern sich in die IP-Adressen, die während des Schritts zur IP-Generierung generiert wurden.
Die folgenden Status sind während des Migrationsprozesses verfügbar:
| Status | Beschreibung |
|---|---|
| Validierung und Vorbereitung der Migration. | Die Plattform validiert die Migrationsunterstützung und führt die erforderlichen Prüfungen durch. |
| Bereitstellung der Infrastruktur Version 3 der App Service-Umgebung. | Ihre neue Infrastruktur Version 3 der App Service-Umgebung wird gerade bereitgestellt. |
| Warten auf die Fertigstellung der Infrastruktur. | Die Plattform überprüft Ihre neue Infrastruktur und führt erforderliche Prüfungen durch. |
| Einrichten von Netztechnologie. Der Zeitraum für die Ausfallzeit der Migration wurde gestartet. Auf Anwendungen kann nicht zugegriffen werden. | Die Plattform löscht Ihre alte Infrastruktur und verschiebt alle Ihre Anwendungen in Ihre neue App Service-Umgebung Version 3. Ihre Anwendungen sind ausgefallen und akzeptieren keinen Datenverkehr. |
| Ausführen von Validierungen nach der Migration. | Die Plattform führt erforderliche Überprüfungen durch, um sicherzustellen, dass die Migration erfolgreich war. |
| Abschluss der Migration. | Die Plattform schließt die Migration gerade ab. |
Wie im Schritt zur IP-Generierung können Sie Ihre App Service-Umgebung während dieses Vorgangs weder skalieren noch ändern oder Apps darin bereitstellen. Nach Abschluss der Migration werden die Apps, die sich in der alten App Service-Umgebung befanden, auf der neuen App Service-Umgebung v3 ausgeführt.
Verwenden des vorhandenen Migrationsfeatures
Voraussetzungen
Stellen Sie sicher, dass Sie wissen, wie sich die Migration zur App Service-Umgebung v3 auf Ihre Anwendungen auswirkt. Sehen Sie sich den 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 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.
Es wird empfohlen, das Azure-Portal für die direkte Migration zu verwenden. Wenn Sie die Azure CLI für die Migration verwenden möchten, 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.
1. 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)
2. Überprüfen, ob die Migration unterstützt wird
Mit dem folgenden Befehl wird überprüft, ob eine Migration für Ihre App Service-Umgebung unterstützt wird und ob in Ihrer App Service-Umgebung die für die Migration unterstützte Buildversion verwendet wird.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=validation"
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, 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}/migrate?api-version=2021-02-01&phase=PreMigrationUpgrade"
3. Generieren von IP-Adressen für Ihre neue App Service-Umgebung v3-Ressource
Führen Sie den folgenden Befehl aus, um neue 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}/migrate?api-version=2021-02-01&phase=premigration"
Führen Sie den folgenden Befehl aus, um den Status dieses Schritts zu überprüfen:
az rest --method get --uri "${ASE_ID}?api-version=2021-02-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 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=2021-02-01"
4. Aktualisieren abhängiger Ressourcen mit neuen IP-Adressen
Aktualisieren Sie unter Verwendung der neuen IP-Adressen alle Ihrer Ressourcen oder Netzwerkkomponenten, um sicherzustellen, dass Ihre neue Umgebung nach Abschluss der Migration wie vorgesehen funktioniert. Es liegt in Ihrer Verantwortung, alle notwendigen Aktualisierungen vorzunehmen.
5. 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
6. 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.
7. Vorbereiten Ihrer Konfigurationen
Sie können Ihre neue App Service-Umgebung v3-Ressourcenzone 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.
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. Die Migration schlägt auch fehl, wenn Sie während der Migration versuchen, ein benutzerdefiniertes Domänensuffix zu einer Umgebung hinzuzufügen, für die keines konfiguriert ist. 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 Ihre Azure Key Vault-Instanz sicher, dass Ihr Schlüsseltresor den Zugriff von den neuen ausgehenden IP-Adressen Ihrer App Service-Umgebung zulässt, die in Schritt 3 generiert wurden. Wenn Sie über einen privaten Endpunkt auf Ihren Schlüsseltresor zugreifen, stellen Sie sicher, dass Sie den privaten Zugriff ordnungsgemäß konfiguriert haben.
Wenn Ihre Migration kein benutzerdefiniertes Domänensuffix enthält und Sie die Zonenredundanz nicht aktivieren, können Sie mit der Migration fortfahren.
Um diese Konfigurationen festzulegen, erstellen Sie eine Datei namens parameters.json mit den folgenden Details, entsprechend Ihrem Szenario. 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 Eigenschaft zoneRedundant, da diese Konfiguration nach der Migration nicht mehr geändert werden kann. Legen Sie den Wert der Eigenschaft kind entsprechend der Version Ihrer vorhandenen App Service-Umgebung fest. Gültige Werte für die kind-Eigenschaft sind ASEV1 und ASEV2.
Wenn Sie ohne benutzerdefiniertes Domänensuffix migrieren und Zonenredundanz aktivieren, verwenden Sie diesen Code:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"zoneRedundant": true
}
}
Wenn Sie eine benutzerseitig zugewiesene verwaltete Identität für Ihre Konfiguration des benutzerdefinierten Domänensuffixes verwenden und Zonenredundanz aktivieren, verwenden Sie diesen Code:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"zoneRedundant": true,
"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 Ihre Konfiguration des benutzerdefinierten Domänensuffixes verwenden und Zonenredundanz nicht aktivieren, verwenden Sie diesen Code:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "SystemAssigned"
}
}
}
8. 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 je nach Umgebungsgröße drei bis sechs Stunden für v2-zu-v3-Migrationen und bis zu sechs Stunden für v1-zu-v3-Migrationen. Während dieser Zeit kommt es zu einer Anwendungsdowntime von ca. einer Stunde. Skalierung, Bereitstellungen und Änderungen Ihrer vorhandenen App Service-Umgebung werden während dieses Schritts blockiert.
Schließen Sie den Parameter body im folgenden Befehl ein, wenn Sie Zonenredundanz aktivieren und/oder ein benutzerdefiniertes Domänensuffix konfigurieren. Wenn keine dieser Konfigurationen auf Ihre Migration angewendet wird, können Sie den Parameter aus dem Befehl entfernen.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=fullmigration" --body @parameters.json
Führen Sie die folgenden Befehle aus, um den detaillierten Status Ihrer Migration zu überprüfen. Informationen zu den Status finden Sie in den Beschreibungen des Migrationsstatus.
Der erste Befehl ruft die Vorgangs-ID für die Migration ab. Kopieren Sie den Wert der Eigenschaft ID.
az rest --method get --uri "${ASE_ID}/operations?api-version=2022-03-01"
Ersetzen Sie den Platzhalter für die Vorgangs-ID im folgenden Befehl durch den kopierten Wert. Dieser Befehl gibt den detaillierten Status Ihrer Migration zurück. Sie können diesen Befehl so oft wie nötig ausführen, um den neuesten Status zu erhalten.
az rest --method get --uri "${ASE_ID}/operations/<operation-id>/details/default?api-version=2022-09-01"
Wenn der Status Ready 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 ausgeführt.
Führen Sie den folgenden Befehl aus, oder navigieren Sie zum Azure-Portal, um die Details Ihrer neuen Umgebung abzurufen.
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
1. Überprüfen, ob die Migration unterstützt wird
Navigieren Sie im Azure-Portal zur Seite Migration für die App Service-Umgebung, die Sie migrieren. Zum Aufrufen der Seite Migration können Sie oben auf der Seite Übersicht für Ihre App Service-Umgebung das Banner auswählen oder im linken Menü das Element Migration auswählen.
Wählen Sie die Option „Direkte Migration“ aus, um den direkten Migrationsprozess zu starten. Wenn Sie die Option für parallele Migration auswählen, werden Sie zur Dokumentation für diesen Migrationsprozess weitergeleitet. Wählen Sie die Option für die parallele Migration nicht aus, wenn Sie die Funktion für die direkte Migration verwenden möchten.
Auf der Seite Migration überprüft die Plattform, ob die Migration für Ihre App Service-Umgebung unterstützt wird. Wählen Sie Überprüfen aus, und bestätigen Sie dann, dass Sie mit der Überprüfung fortfahren möchten. Die Überprüfung dauert einige Sekunden.
Wenn Ihre Umgebung für die Migration nicht unterstützt wird, wird oben auf der Seite ein Banner mit einer Fehlermeldung und einem Grund angezeigt. Beschreibungen der Fehlermeldungen, die angezeigt werden können, wenn Sie nicht für die Migration in Frage kommen, finden Sie im Abschnitt Problembehandlung.
Wenn Sie ein Upgrade starten müssen, um Ihre App Service-Umgebung auf die unterstützte Buildversion zu aktualisieren, werden Sie aufgefordert, das Upgrade zu starten, was je nach Größe Ihrer Umgebung 8-12 Stunden oder länger dauern kann. Wählen Sie Upgrade aus, um das Upgrade zu starten. Wenn das Upgrade abgeschlossen ist, wird die Validierung bestanden und Sie können die Migrationsfunktion verwenden, um Ihre Migration zu starten.
Wenn die Migration für Ihre App Service-Umgebung unterstützt wird, fahren Sie mit dem nächsten Schritt im Prozess fort. Die Seite Migration führt Sie durch die Schritte zum Abschließen der Migration.
2. Generieren von IP-Adressen für Ihre neue App Service-Umgebung v3-Ressource
Vergewissern Sie sich unter Abrufen neuer IP-Adressen, dass Sie die Auswirkungen verstehen, und wählen Sie die Schaltfläche Starten aus. Dieser Schritt dauert ungefähr 15 Minuten. Sie können während dieser Zeit keine Skalierung und keine Änderungen an Ihrer vorhandenen App Service-Umgebung vornehmen.
3. Aktualisieren abhängiger Ressourcen mit neuen IP-Adressen
Wenn der vorherige Schritt abgeschlossen ist, werden die IP-Adressen für Ihre neue App Service-Umgebung v3-Ressource angezeigt. Aktualisieren Sie unter Verwendung der neuen IP-Adressen alle Ressourcen und Netzwerkkomponenten, damit Ihre neue Umgebung nach Abschluss der Migration wie vorgesehen funktioniert. Es liegt in Ihrer Verantwortung, alle notwendigen Aktualisierungen vorzunehmen.
4. Delegieren des Subnetzes Ihrer App Service-Umgebung
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. Im Portal wird ein Link zu Ihrem Subnetz angezeigt, damit Sie nach Bedarf bestätigen und aktualisieren können.
5. Überprüfen von Änderungen an der Instanzgröße
Klicken Sie auf Bestätigen, um zu bestätigen, dass Sie zur Kenntnis genommen haben, dass Ihre App Service-Pläne im Rahmen der Migration von der Isolated-Ebene in die entsprechende Isolated v2-Ebene konvertiert werden.
6. Sicherstellen, dass das virtuelle Netzwerk keine Sperren aufweist
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. Ausführliche Informationen zum Überprüfen, ob für Ihr Abonnement oder Ihre Ressourcengruppe Sperren vorhanden sind, finden Sie unter Konfigurieren von Sperren.
7. Auswählen Ihrer Konfigurationen
Sie können Ihre neue App Service-Umgebung v3-Ressourcenzone redundant machen, wenn sich Ihre vorhandene Umgebung in einer Region befindet, die Zonenredundanz unterstützt.
Aktivieren Sie das Kontrollkästchen Aktiviert, wenn Sie Zonenredundanz konfigurieren möchten.
Wenn sich Ihre Umgebung in einer Region befindet, die keine Zonenredundanz unterstützt, ist das Kontrollkästchen nicht verfügbar. Wenn Sie eine zonenredundante App Service-Umgebung v3-Ressource benötigen, verwenden Sie eine der manuellen Migrationsoptionen und erstellen Sie die Ressource in einer Region, die Zonenredundanz unterstützt.
Wenn Ihre vorhandene App Service-Umgebung ein benutzerdefiniertes Domänensuffix verwendet, müssen Sie dieses für Ihre neue App Service-Umgebung v3-Ressource konfigurieren. Die Konfigurationsoptionen für ein benutzerdefiniertes Domänensuffix werden angezeigt, wenn diese Situation auf Sie zutrifft. Sie können die Migration erst durchführen, wenn Sie die erforderlichen Informationen angegeben haben.
Wenn Sie ein benutzerdefiniertes Domänensuffix verwenden möchten, aber derzeit noch keines konfiguriert haben, können Sie eines konfigurieren, nachdem die Migration abgeschlossen ist. 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 Ihre Azure Key Vault-Instanz sicher, dass Ihr Schlüsseltresor den Zugriff von den neuen ausgehenden IP-Adressen Ihrer App Service-Umgebung zulässt, die in Schritt 2 generiert wurden. Wenn Sie über einen privaten Endpunkt auf Ihren Schlüsseltresor zugreifen, stellen Sie sicher, dass Sie den privaten Zugriff ordnungsgemäß konfiguriert haben.
Nachdem Sie die Details zu Ihrem benutzerdefinierten Domänensuffix hinzugefügt haben, ist die Schaltfläche Migrieren verfügbar.
8. Migrieren zur App Service-Umgebung v3
Nachdem Sie alle vorherigen Schritte durchgeführt haben, können Sie mit der Migration beginnen. Stellen Sie sicher, dass Sie die Auswirkungen der Migration verstehen, einschließlich der Vorgänge während dieser Zeit.
Dieser Schritt dauert je nach Umgebungsgröße drei bis sechs Stunden für v2-zu-v3-Migrationen und bis zu sechs Stunden für v1-zu-v3-Migrationen. Skalierung und Änderungen an Ihren vorhandenen App Service-Umgebung werden während dieses Schritts blockiert.
Hinweis
In seltenen Fällen kann es vorkommen, dass Sie nach dem Start der Migration die folgende Meldung im Portal erhalten: „Migration zur App Service-Umgebung v3 fehlgeschlagen“. Es gibt einen bekannten Fehler, der diese Benachrichtigung auch dann auslösen kann, wenn die Migration voranschreitet. Überprüfen Sie das Aktivitätsprotokoll für die App-Service-Umgebung, um festzustellen, ob diese Fehlermeldung zutrifft. In den meisten Fällen löst das Aktualisieren der Seite das Problem, und die Fehlermeldung wird nicht mehr angezeigt. Wenn die Fehlermeldung weiterhin angezeigt wird, wenden Sie sich an den Support, um Hilfe zu erhalten.
Zu diesem Zeitpunkt sind detaillierte Migrationsstatus nur verfügbar, wenn Sie die Azure CLI verwenden. Weitere Informationen finden Sie im Abschnitt „Azure CLI“ für die Migration zu App Service-Umgebung v3. Sie können den Status der Migration mit der CLI überprüfen, auch wenn Sie das Portal für die Migration verwenden.
Wenn die Migration abgeschlossen ist, verfügen Sie über eine App Service-Umgebung v3-Ressource, und alle Ihre Apps werden in Ihrer neuen Umgebung ausgeführt. Sie können die Version der Umgebung bestätigen, indem Sie die Seite Konfiguration für Ihre App Service-Umgebung überprüfen.
Wenn Ihre Migration ein benutzerdefiniertes Domänensuffix enthält, wurde die Domäne im Abschnitt Grundlagen der Übersichtsseite des Portals für die App Service-Umgebung v1/v2 angezeigt, jedoch nicht mehr in der App Service-Umgebung v3. Navigieren Sie für die App Service-Umgebung v3 stattdessen zur Seite Benutzerdefiniertes Domänensuffix, auf der Sie bestätigen können, dass Ihr benutzerdefiniertes Domänensuffix richtig konfiguriert ist. Sie können die Konfiguration auch entfernen, wenn Sie sie nicht mehr benötigen, oder eine Konfiguration erstellen, wenn Sie dies zuvor noch nicht getan haben.
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.
Preiskalkulation
Es entstehen keine Kosten für die Migration Ihrer App Service-Umgebung. Wenn Sie die Direktmigrationsfunktion verwenden, werden Ihnen die Kosten für Ihre bisherige App Service-Umgebung nicht mehr in Rechnung gestellt, sobald diese während des Migrationsprozesses heruntergefahren wird. Die Kosten für Ihre neue App Service-Umgebung v3 werden Ihnen in Rechnung gestellt, sobald sie bereitgestellt ist. 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 Konvertierung von App Service-Plänen von Isoliert zu Isoliert v2 sind die Ressource für Ihre Apps nach der Migration möglicherweise überdimensioniert, da der Isoliert v2-Plan 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 der Direktmigrationsfunktion 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 Direktmigrationsfunktion verwenden sollte?
Die Direktmigrationsfunktion eignet sich am besten für Kunden, die mit minimalen Änderungen an ihren Netzwerkkonfigurationen zu App Service-Umgebung v3 migrieren möchten und etwa eine Stunde Anwendungsdowntime verkraften können. Wenn Sie keine Downtime unterstützen können, sehen Sie sich die Parallelmigrationsfunktion oder die Optionen für die manuelle Migration an. Die Direktmigrationsfunktion erstellt Ihre App Service-Umgebung v3 im selben Subnetz wie Ihre vorhandene Umgebung und verwendet dieselbe Netzwerkinfrastruktur. Möglicherweise müssen Sie die Änderungen der eingehenden und ausgehenden IP-Adressen berücksichtigen, wenn Sie Abhängigkeiten von diesen spezifischen IPs haben. - Kommt es während der Migration zu Ausfallzeiten?
Ja, Sie sollten während des drei- bis sechsstündigen Dienstfensters während des Migrationsschritts mit einer Ausfallzeit von etwa einer Stunde rechnen. Planen Sie daher entsprechend. Wenn Sie über eine andere App Service-Umgebung verfügen, auf die Sie während der Migration mit der Direktmigrationsfunktion verweisen können, können Sie Anwendungsdowntime vermeiden. Wenn Sie nicht über eine andere App Service-Umgebung verfügen und keine Downtime unterstützen können, sehen Sie sich die Parallelmigrationsfunktion oder die Optionen für die manuelle Migration an. - 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?
Die Direktmigrationsfunktion unterstützt dieses Migrationsszenario. - Was passiert, wenn meine App Service-Umgebung an eine Zone angeheftet ist?
Die an Zonen angeheftete App Service-Umgebung v2 ist jetzt ein unterstütztes Szenario für die Migration mit der Migrationsfunktion. Die App Service-Umgebung v3 unterstützt keine Zonenbindung. Bei der Migration zur App Service-Umgebung v3 können Sie die Zonenredundanz konfigurieren oder auch nicht. - 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, die Direktmigrationsfunktion 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. Für App Service-Umgebungen mit ILB behalten Sie die gleiche ILB-IP-Adresse bei. Für App Service-Umgebungen mit Internetzugang ändert sich die öffentliche IP-Adresse und die ausgehende IP-Adresse. 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. Sie sollten Entwicklungsumgebungen 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 sich entscheiden, eine App Service-Umgebung mithilfe der Direktmigrationsfunktion zu migrieren, wird die alte Umgebung heruntergefahren und gelöscht, und alle Ihre Anwendungen werden in eine neue Umgebung migriert. Auf Ihre alte Umgebung kann nicht mehr zugegriffen werden. Ein Rollback auf die alte Umgebung 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.