你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
使用并排迁移功能将应用服务环境 v2 迁移到应用服务环境 v3
注意
本文中所述的迁移功能用于并排（在不同子网中）将应用服务环境 v2 自动迁移到应用服务环境 v3。
如果要查找有关就地迁移功能的信息，请参阅使用就地迁移功能迁移到应用服务环境 v3。 如果要查找有关手动迁移选项的信息，请参阅手动迁移选项。 如果在确定适合你的迁移选项时需要帮助，请参阅迁移路径决策树。 若要详细了解应用服务环境 v3，请参阅应用服务环境 v3 概述。
你可以使用并排迁移功能自动将应用服务环境 v2 迁移到应用服务环境 v3。 若要详细了解迁移过程，以及你的应用服务环境目前是否支持迁移，请参阅并排迁移功能概述。
重要
建议在迁移任何生产环境之前先将此功能用于开发环境，以避免意外问题。 请使用页面底部的按钮提供与本文或所介绍功能相关的任何反馈。
先决条件
请确保了解迁移到应用服务环境 v3 对应用程序的影响。 查看迁移过程，了解流程时间线以及需要参与的时间和位置。 另请查看常见问题解答，其中可以回答一些问题。
请确保虚拟网络、资源组、资源或订阅中没有锁。 在迁移期间，锁会阻止平台操作。
请确保没有 Azure 策略会阻止迁移所需的操作，包括子网修改和 Azure 应用服务资源创建。 阻止资源修改和创建的策略可能会导致迁移停滞或失败。
由于你的应用服务环境 v3 位于虚拟网络中的一个不同子网中，因此你需要确保虚拟网络中有一个可用子网满足应用服务环境 v3 的子网要求。 你选择的子网还必须能够与你的现有应用服务环境所在的子网进行通信。 请确保两个子网之间的通信没有被阻止。 如果你没有可用的子网，则需要在迁移前创建一个。 创建新子网可能涉及增大虚拟网络地址空间。 有关详细信息，请参阅创建虚拟网络和子网。
由于迁移期间阻止了缩放，因此在开始迁移之前，你应将环境缩放为所需的大小。 如果需要在迁移后缩放环境，可以在迁移完成后执行此操作。
请按照本文中的顺序和所写内容执行所述步骤，因为要进行 Azure REST API 调用。 建议使用 Azure CLI 进行这些 API 调用。 有关其他方法的信息，请参阅 Azure REST API 参考。
对于本指南，请安装 Azure CLI，或使用 Azure Cloud Shell 并使用 Bash shell。
注意
我们建议使用 Bash shell 运行本指南中给出的命令。 这些命令可能与 PowerShell 约定和转义字符不兼容。
重要
在迁移期间，Azure 门户可能会显示有关应用服务环境和应用的错误信息。 请勿转到 Azure 门户中的迁移体验，因为并行迁移功能不可用。 建议使用 Azure CLI 检查迁移的状态。 如果对迁移或应用的状态有任何疑问，请联系支持人员。
1.为你的新应用服务环境 v3 选择子网
在应用服务环境 v3 中选择一个满足应用服务环境 v3 的子网要求的子网。 记下你选择的子网的名称。 此子网必须不同于你现有的应用服务环境所在的子网。
2.获取应用服务环境 ID
请运行以下命令，以获取应用服务环境 ID，并将其存储为环境变量。 将名称和资源组的占位符替换为要迁移的应用服务环境的值。 如果虚拟网络和应用服务环境位于同一资源组中，则 ASE_RG 和 VNET_RG 相同。
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. 验证迁移是否受支持
以下命令会检查应用服务环境是否支持迁移。 如果收到错误，或者应用服务环境处于不正常或挂起状态，则此时无法迁移。 有关可能会收到的潜在错误消息的说明，请参阅故障排除部分。 如果你的环境不支持使用并排迁移功能进行迁移，或者你希望在不使用并排迁移功能的情况下迁移到应用服务环境 v3，请参阅手动迁移选项。 此命令还会验证应用服务环境是否在受支持的生成版本中进行迁移。 如果你的应用服务环境没有使用受支持的生成版本，你需要自行启动升级。 有关迁移前升级的详细信息，请参阅验证是否支持使用并排迁移功能对应用服务环境进行迁移。
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"
如果没有错误，则表示支持迁移，可以继续执行下一步。
如果需要开始升级来将应用服务环境升级到受支持的生成版本，请运行以下命令。 仅当验证步骤失败，并且系统要求你升级应用服务环境时，才运行此命令。
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"
4.为新的应用服务环境 v3 生成出站 IP 地址
创建一个名为 zoneredundancy.json 的文件，在其中包含有关你的区域和区域冗余选择的以下详细信息。
{
"location":"<region>",
"Properties": {
"zoneRedundant": "<true/false>"
}
}
如果现有环境位于支持区域冗余的区域，可以将新的应用服务环境 v3 区域设置为冗余。 可以通过将 zoneRedundant 属性设置为 true 来配置区域冗余。 区域冗余是可选的配置。 只能在新建应用服务环境 v3 期间设置此配置，且后续无法删除。
运行以下命令来创建新的出站 IP 地址。 完成此步骤大约需要 15 分钟。 在此期间，请不要缩放或更改现有应用服务环境。
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01" --body @zoneredundancy.json
请运行以下命令，以检查此步骤的状态：
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.status
如果该步骤正在进行，则会获得 Migrating 状态。 获得 Ready 状态后，运行以下命令来查看新的出站 IP。 如果未立即看到新 IP，请等待几分钟，然后重试。
az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses
5.使用新的出站 IP 更新依赖资源
通过使用新的出站 IP，更新所有资源或网络组件，确保迁移完成后新环境按预期运行。 你应负责进行所有必要更新。
6.委托应用服务环境子网
应用服务环境 v3 要求其所在子网具有 Microsoft.Web/hostingEnvironments 的单一委托。 以前的版本不需要此委托。 在迁移之前，需要确认子网已正确委派并更新委派（如有必要）。 你可以通过运行以下命令或在 Azure 门户中导航到该子网来更新委托。
az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments
7.确认虚拟网络中没有锁
在迁移期间，虚拟网络锁会阻止平台操作。 如果虚拟网络具有锁，则需要在迁移之前将其删除。 如有必要，可以在迁移完成后添加回锁定。
锁定可以存在于三个范围：订阅、资源组和资源。 在父范围应用锁时，该范围内所有资源都会继承相同的锁。 如果在订阅、资源组或资源范围内应用了锁定，则需要在迁移之前将其移除。 有关锁和锁继承的详细信息，请参阅锁定资源以保护基础结构。
请使用以下命令检查虚拟网络是否具有任何锁定：
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
有关用于检查订阅或资源组是否具有锁定的相关命令，请参阅 Azure CLI 锁定参考。
8.准备你的配置
如果现有的应用服务环境使用自定义域后缀，需要在迁移过程中为新的应用服务环境 v3 资源配置一个自定义域后缀。 如果未配置但当前要使用自定义域后缀，迁移会失败。 有关应用服务环境 v3 自定义域后缀的详细信息（包括要求、分步说明和最佳做法），请参阅应用服务环境的自定义域后缀。
注意
如果要配置自定义域后缀，在向 Azure 密钥保管库添加网络权限时，请确保密钥保管库允许从应用服务环境 v3 的新子网进行访问。
若要设置这些配置（包括标识你前面选择的子网），请创建名为 parameters.json 的另一个文件，并根据你的方案在其中包含以下详细信息。 请确保使用你为新的应用服务环境 v3 选择的新子网。 如果自定义域后缀不适用于你的迁移，请不要包含自定义域后缀的属性。 请注意 zoneRedundant 属性的值，并将其设置为你在出站 IP 生成步骤中使用的同一值。 必须为区域冗余使用你在出站 IP 生成步骤中使用的同一值。
如果是在没有自定义域后缀的情况下进行迁移，请使用以下代码：
{
"Properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>"
}
}
如果你为自定义域后缀配置使用用户分配的托管标识，请使用以下代码：
{
"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/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
}
}
}
如果你为自定义域后缀配置使用系统分配的托管标识，请使用以下代码：
{
"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.迁移到应用服务环境 v3 并检查状态
完成上述所有步骤后，即可开始迁移。 请确保了解迁移的影响。
此步骤需要三到六个小时才能完成。 在此期间，应用程序不会停机。 在此步骤中，会阻止对现有应用服务环境进行缩放、部署和修改。
运行以下命令来启动迁移：
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json
运行以下命令来检查迁移状态：
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
获得 MigrationPendingDnsChange 状态后，迁移就完成了，你就有了一个应用程序服务环境 v3 资源。 你的应用现在同时在新环境中和旧环境中运行。
运行以下命令获取新环境的详细信息：
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
重要
在迁移期间以及在执行 MigrationPendingDnsChange 步骤期间，Azure 门户会显示有关应用服务环境和应用的错误信息。 使用 Azure CLI 检查迁移的状态。 如果对迁移或应用的状态有任何疑问，请联系支持人员。
注意
如果迁移包含自定义域后缀，则迁移完成后，自定义域后缀配置可能会因已知 bug 显示为已降级。 应用服务环境仍应按预期工作。 已降级状态应在 6-8 小时内自行解决。 如果配置在 8 小时后降级，或者自定义域后缀不起作用，请联系支持人员。
10.获取新的应用服务环境 v3 的入站 IP 地址并更新依赖资源
在迁移过程的此阶段，你有两个应用服务环境。 你的应用同时在这两个环境中运行。 需要将任何依赖资源更新为使用新的应用服务环境 v3 的新 IP 入站地址。 对于面向内部 (ILB) 的应用服务环境，你需要将你的专用 DNS 区域更新为指向新的入站 IP 地址。
可以通过运行对应于应用服务环境负载均衡器类型的以下命令来获取新应用服务环境 v3 的新入站 IP 地址。 你应负责进行所有必要更新。
对于 ILB 应用服务环境，请运行以下命令获取专用入站 IP 地址：
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses
对于 ELB 应用服务环境，请运行以下命令获取公共入站 IP 地址：
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses
11.重定向客户流量、验证应用服务环境 v3 并完成迁移
此步骤提供了测试和验证新应用服务环境 v3 的机会。 默认情况下，流量会发送到应用服务环境 v2 前端。 如果你使用的是 ILB 应用服务环境 v3，则可以通过使用新的入站 IP 地址更新专用 DNS 区域来测试应用服务环境 v3 前端。 如果使用的是 ELB 应用服务环境 v3，则测试过程取决于特定的网络配置。 测试 ELB 环境的一种简单方法是更新主机文件，以使用新的应用服务环境 v3 入站 IP 地址。 如果已将自定义域分配给单个应用，则可以改为更新其 DNS 以指向新的入站 IP。 通过测试此项更改，可以在启动最后一个迁移步骤（此步骤会删除旧的应用服务环境）之前全面验证应用服务环境 v3。 如果能够在不出现问题的情况下访问应用，这意味着你已准备好完成迁移。
确认你的应用按预期工作后，可运行以下命令来将客户流量重定向到新应用服务环境 v3。 此命令还会删除旧环境。 你有 14 天时间来完成此步骤。 如果未在 14 天内完成此步骤，则迁移会自动还原到应用服务环境 v2。 如果需要超过 14 天才能完成此步骤，请联系支持人员。
如果发现任何问题或此时决定不想再继续迁移，请联系支持人员来还原迁移。 如果你需要还原迁移，请不要运行 DNS 更改命令。 有关详细信息，请参阅还原迁移。
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"
请运行以下命令，以检查此步骤的状态：
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
在此步骤中，你获得状态“CompletingMigration”。 获得“MigrationCompleted”状态时，流量重定向步骤已完成，迁移已完成。