Migration zu App Service-Umgebung v3 mithilfe der Direktmigrationsfunktion

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.

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.

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.

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:

Ü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.

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.

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:

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.

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)

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=validation"

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=PreMigrationUpgrade"

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=premigration"

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

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2021-02-01"

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

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

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

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "zoneRedundant": true
    }
}

{
    "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/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
        }
    }
}

{
    "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"
        }
    }
}

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=fullmigration" --body @parameters.json

az rest --method get --uri "${ASE_ID}/operations?api-version=2022-03-01"

az rest --method get --uri "${ASE_ID}/operations/<operation-id>/details/default?api-version=2022-09-01"

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

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.

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.

Nächste Schritte