Verwenden des Features für die parallele Migration zum Migrieren von App Service-Umgebung v2 zu App Service-Umgebung v3
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 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.
Sie können App Service-Umgebung v2 mithilfe des Features für die parallele Migration automatisch zu App Service-Umgebung v3 migrieren. Wenn Sie mehr über den Migrationsprozess erfahren und überprüfen möchten, ob Ihre App Service-Umgebung die Migration zu diesem Zeitpunkt unterstützt, lesen Sie die Informationen in der Übersicht über das Feature für die parallele Migration.
Wichtig
Es wird empfohlen, dieses Feature für Entwicklungsumgebungen vor der Migration von Produktionsumgebungen zu verwenden, um unerwartete Probleme zu vermeiden. Senden Sie uns über die Schaltflächen am unteren Rand der Seite Feedback zu diesem Artikel oder zum Feature.
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 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.
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. Wenn Sie einen Fehler erhalten oder sich Ihre App Service-Umgebung im Zustand „Fehlerhaft“ oder „Angehalten“ befindet, können Sie sie zu diesem Zeitpunkt nicht migrieren. Eine Beschreibung der möglichen Fehlermeldungen finden Sie im Abschnitt zur Problembehandlung. Wenn für Ihre Umgebung die Migration mit dem Feature für die parallele Migration nicht unterstützt wird, oder wenn Sie ohne das Feature für die parallele Migration zu App Service-Umgebung v3 migrieren möchten, sehen Sie sich die Optionen zur manuellen Migration an. 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
Erstellen Sie eine Datei namens zoneredundancy.json mit den folgenden Details für Ihre Region und die Zonenredundanzauswahl.
{
"location":"<region>",
"Properties": {
"zoneRedundant": "<true/false>"
}
}
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.
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" --body @zoneredundancy.json
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 Abschluss der Migration wie vorgesehen funktioniert. Es liegt in Ihrer Verantwortung, alle notwendigen Aktualisierungen vorzunehmen.
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.
Sperren können in drei 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 angewendet sind, müssen Sie diese vor der Migration entfernen. Weitere Informationen zu Sperren und zur Vererbung von Sperren finden Sie unter Sperren von Ressourcen zum Schutz Ihrer Infrastruktur.
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.
Um diese Konfigurationen festzulegen, einschließlich der Identifizierung des zuvor ausgewählten Subnetzes, erstellen Sie eine weitere 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 Eigenschaft zoneRedundant, und legen Sie ihn auf denselben Wert fest, den Sie im Schritt zum Erstellen ausgehender IP-Adressen verwendet haben. Sie müssen den gleichen Wert für Zonenredundanz verwenden, den Sie im Schritt zur Generierung von ausgehenden IP-Adressen verwendet haben.
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 kommt es zu einer Anwendungsdowntime. Skalierung, Bereitstellungen und Änderungen Ihrer vorhandenen App Service-Umgebung werden während dieses Schritts blockiert.
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
In dieser Phase befinden sich zwei App Service-Umgebungen im Migrationsprozess. Ihre Apps werden in beiden Umgebungen ausgeführt. 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
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. Standardmäßig wird Datenverkehr an die Front-Ends von App Service-Umgebung v2 gesendet. Wenn Sie eine ILB-App Service-Umgebung v3 verwenden, können Sie die Front-Ends von App Service-Umgebung v3 testen, indem Sie Ihre private DNS-Zone mit der neuen IP-Adresse für eingehenden Datenverkehr 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. Wenn Sie ohne Probleme auf Ihre Apps zugreifen können, bedeutet dies, dass Sie bereit sind, die Migration abzuschließen.
Nachdem Sie sich vergewissert haben, dass Ihre Apps erwartungsgemäß funktionieren, können Sie Kundendatenverkehr an die neue App Service-Umgebung v3 umleiten, indem Sie den folgenden Befehl ausführen. Mit diesem Befehl wird außerdem Ihre alte Umgebung gelöscht. Sie haben 14 Tage Zeit, um diesen Schritt abzuschließen. Wenn Sie diesen Schritt nicht in 14 Tagen abschließen, wird Ihre Migration automatisch auf eine App Service-Umgebung v2 zurückgesetzt. Wenn Sie mehr als 14 Tage benötigen, um diesen Schritt abzuschließen, wenden Sie sich an den Support.
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 die Migration rückgängig zu machen. Führen Sie den DNS-Änderungsbefehl nicht aus, wenn Sie die Migration rückgängig machen müssen. Weitere Informationen finden Sie unter Rückgängig machen der Migration.
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.