你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用并排迁移功能迁移到应用服务环境 v3

注意

本文中所述的迁移功能用于并排（在不同子网中）将应用服务环境 v2 自动迁移到应用服务环境 v3。 如果尚未申请 30 天的宽限期，请查看宽限期概述，然后通过转到 Azure 门户并访问每个应用服务环境的“迁移”边栏选项卡来申请宽限期。

如果要查找有关就地迁移功能的信息，请参阅使用就地迁移功能迁移到应用服务环境 v3。 如果要查找有关手动迁移选项的信息，请参阅手动迁移选项。 如果在确定适合你的迁移选项时需要帮助，请参阅迁移路径决策树。 若要详细了解应用服务环境 v3，请参阅应用服务环境 v3 概述。

与就地迁移相比，并行迁移面临额外的挑战。 对于需要在两个选项之间做出选择的客户，建议使用就地迁移，因为步骤更少且复杂性更低。 如果决定使用并行迁移，请查看使用并行迁移功能进行迁移时的常见问题来源部分，以避免常见错误。

应用服务可以将应用服务环境 v1 和 v2 自动迁移到应用服务环境 v3。 有不同的迁移选项。 查看迁移路径决策树，确定哪种选项最适合你的用例。 与早期版本相比，应用服务环境 v3 具有一些优点和功能差异。 请确保在迁移之前查看应用服务环境 v3 支持的功能，以降低出现意外应用程序问题的风险。

并排迁移功能可自动帮你迁移到应用服务环境 v3。 并排迁移功能会创建一个新的应用服务环境 v3，将你的所有应用置于不同的子网中。 在你于迁移过程结束时发起删除之前，不会删除现有的应用服务环境。 此迁移选项最适合想要在零停机的情况下迁移到应用服务环境 v3，并且可支持为新环境使用不同子网的客户。 如果你需要使用相同的子网，并且可以支持大约一个小时的应用程序停机，请参阅就地迁移功能。 如需让你以自己的节奏迁移的手动迁移选项，请参阅手动迁移选项。

重要

如果未完成本教程中所述的所有步骤，可能需要停机。 例如，如果不使用新的 IP 地址更新所有依赖资源，或不允许访问新子网/从新子网访问，例如自定义域后缀密钥保管库的情况，则在满足所需条件之前需要停机。

建议先在开发环境中使用此功能，然后再迁移生产环境，以演练该过程和确保不出现意外问题。 请使用页面底部的按钮提供与本文或所介绍功能相关的任何反馈。

支持的方案

目前，并排迁移功能不支持迁移到以下区域的应用服务环境 v3：

Azure Public

• 阿联酋中部

Azure 政府

• US DoD 中部
• US DoD 东部
• US Gov 亚利桑那州
• US Gov 德克萨斯州
• US Gov 弗吉尼亚州

由世纪互联运营的 Microsoft Azure

• 中国东部 2
• 中国北部 2

可以使用并排迁移功能迁移以下应用服务环境配置。 该表提供了在使用基于现有应用服务环境的并排迁移功能时的应用服务环境 v3 配置。

配置	应用服务环境 v3 配置
内部负载均衡器 (ILB) 应用服务环境 v2	ILB 应用服务环境 v3
外部（ELB/面向 Internet，使用公共 IP）应用服务环境 v2	ELB 应用服务环境 v3
具有自定义域后缀的 ILB 应用服务环境 v2	具有自定义域后缀的 ILB 应用服务环境 v3

应用服务环境 v3 可以部署为区域冗余。 只要你的应用服务环境 v3 位于支持区域冗余的 Azure 区域，就可以启用区域冗余。

如果你希望新的应用服务环境 v3 使用自定义域后缀，而当前没有使用，可以在迁移完成后随时配置自定义域后缀。 有关详细信息，请参阅为应用服务环境配置自定义域后缀。 如果你的现有环境具有自定义域后缀，并且你不再想要使用它，则必须为迁移配置自定义域后缀。 迁移完成后，可以删除自定义域后缀。

并排迁移功能限制

下面是使用并排迁移功能时的限制：

• 你的新应用服务环境 v3 位于不同的子网中，但与你现有的环境位于同一虚拟网络中。
• 无法更改应用服务环境所在的区域。
• ELB 应用服务环境无法迁移到 ILB 应用服务环境 v3，反之亦然。
• 如果现有的应用服务环境使用自定义域后缀，则必须在迁移过程中为应用服务环境 v3 配置自定义域后缀。
  • 如果你不再想使用自定义域后缀，可以在迁移完成后将其删除。
• 目前只能通过 CLI 或 REST API 来使用并排迁移功能。 此功能在 Azure 门户中不可用。

应用服务环境 v3 不支持以下你可能正在用于你的当前应用服务环境 v2 的功能。

• 为应用配置基于 IP 的 TLS/SSL 绑定。
• 如果虚拟网络中配置的自定义 DNS 服务器无法解析给定的名称，则应用服务环境 v3 不会回退到 Azure DNS。 如果需要此行为，请确保提供一个指向公共 DNS 的转发器，或者将 Azure DNS 包含在自定义 DNS 服务器的列表中。

并排迁移功能不支持以下方案。 如果你的应用服务环境属于这些类别之一，请参阅手动迁移选项。

• 应用服务环境 v1
  • 可以通过导航到 Azure 门户中的应用服务环境，然后在左侧的“设置”下选择“配置”来找到应用服务环境的版本。 还可使用 Azure 资源浏览器，并查看应用服务环境的 kind 属性的值。
  • 如果你有应用服务环境 v1，则可以使用就地迁移功能或某个手动迁移选项进行迁移。
• 使用 IP SSL 地址的 ELB 应用服务环境 v2
• 区域固定的应用服务环境 v2
• 名称不符合字符限制的应用服务环境。 整个名称（包括域后缀）不得超过 64 个字符。 例如：ILB 的 my-ase-name.appserviceenvironment.net 和 ELB 的 my-ase-name.p.azurewebsites.net 不得超过 64 个字符。 如果不满足字符限制，则必须手动迁移。 专门针对应用服务环境名称的字符限制如下：
  • ILB 应用服务环境名称字符限制：36 个字符
  • ELB 应用服务环境名称字符限制：42 个字符

应用服务平台会查看你的应用服务环境以确认并排迁移支持。 如果你的方案没有通过所有验证检查，则此时你无法使用并排迁移功能进行迁移。 如果环境处于不正常或挂起状态，在你进行所需的更新之前无法迁移。

注意

应用服务环境 v3 不支持 IP SSL。 如果使用 IP SSL，则必须在迁移到应用服务环境 v3 之前删除所有 IP SSL 绑定。 删除所有 IP SSL 绑定后，迁移功能将支持你的环境。

疑难解答

如果应用服务环境未通过验证检查，或者你尝试按不正确的顺序执行迁移步骤，则会看到以下错误消息之一：

错误消息	说明	建议
只能对 ARM VNET 中的 ASE 调用迁移，此 ASE 位于经典 VNET 中。	经典虚拟网络中的应用服务环境不能使用并排迁移功能进行迁移。	使用手动迁移选项之一进行迁移。
ASEv3 迁移尚未准备就绪。	底层基础结构未准备好支持应用服务环境 v3。	如果要立即迁移，请使用手动迁移选项之一进行迁移。 否则，请等待并排迁移功能在你的区域推出。
无法为此 ASE 启用区域冗余。	应用服务环境所在的 Azure 区域不支持区域冗余。	如果需要启用区域冗余，请使用某个手动迁移选项迁移到支持区域冗余的 Azure 区域。
目前无法在此自定义 DNS 后缀 ASE 上调用迁移。	自定义域后缀迁移被阻止。	创建支持案例，以联系支持人员来解决问题。
目前无法调用区域冗余 ASE 迁移。	区域冗余应用服务环境迁移被阻止。	创建支持案例，以联系支持人员来解决问题。
无法在区域固定的 ASEv2 上调用迁移。	目前无法使用并排迁移功能迁移区域固定的应用服务环境 v2。	如果要立即迁移，请使用手动迁移选项之一进行迁移。
正在进行现有的还原迁移操作，请稍后重试。	正在还原之前的迁移尝试。	请等待正在进行的还原完成，然后再尝试重新开始迁移。
Properties.VirtualNetwork.Id 应包含子网资源 ID。	如果你尝试迁移而不提供新子网来放置你的应用服务环境 v3，则会出现此错误。	确保遵循指南并完成相关步骤，以确定你将用于应用服务环境 v3 的子网。
无法从“无停机迁移”的当前阶段 <previous phase> 转到 <requested phase>。	如果你尝试按不正确的顺序执行迁移步骤，则会出现此错误。	请确保按顺序执行迁移步骤。
无法对混合状态下的 ASE 启动还原操作，请稍后重试。	如果你尝试还原迁移，但出现了问题，则会出现此错误。 此错误不会影响你的旧环境或新环境。	创建支持案例，以联系支持人员来解决问题。
此 ASE 无法在不停机的情况下迁移。	如果在应用服务环境 v1 上尝试使用并排迁移功能，则会出现此错误。	并排迁移功能不支持应用服务环境 v1。 使用就地迁移功能或某个手动迁移选项进行迁移。
迁移不适用于此订阅。	需要接洽支持人员以迁移此应用服务环境。	创建支持案例，以联系支持人员来解决问题。
无法调用区域冗余迁移，因为预迁移期间创建的 IP 地址不是区域冗余的。	如果尝试进行区域冗余迁移，但未将 IP 生成步骤期间生成的 IP 创建为区域冗余，则会出现此错误。 平台会尝试使所有 IP 都变为区域冗余，以确保后端复原能力。	如果需要启用区域冗余，请提出支持案例以获取支持。 工程师将还原迁移，并允许再次尝试创建 IP。 否则，可以在不启用区域冗余的情况下进行迁移。
如果在任何站点上启用了 IP SSL，则无法调用迁移。	无法使用并排迁移功能迁移具有启用了 IP SSL 的站点的应用服务环境。	从应用服务环境的所有应用中删除 IP SSL，以启用迁移功能。
不能在同一子网中迁移。	如果指定你的当前环境所在的子网用来放置你的应用服务环境 v3，则会出现此错误。	必须为应用服务环境 v3 指定不同的子网。 如果需要使用相同的子网，请使用就地迁移功能进行迁移。
订阅的应用服务环境过多。 请在尝试创建更多环境之前移除一些。	已达到订阅的应用服务环境配额。	请移除不需要的环境，或联系支持人员来查看你的选项。
在活动升级完成之前，无法对此 ASE 调用迁移。	在平台升级期间，应用服务环境无法迁移。 可以从 Azure 门户设置升级首选项。 升级需要 8-12 小时或更长时间，具体取决于应用服务环境的大小（实例/核心数）。	等待升级完成，然后迁移。
正在执行应用服务环境管理操作。	应用服务环境正在进行管理操作。 这些操作包括部署或升级等活动。 在这些操作完成之前，迁移将被阻止。	完成这些操作后，可以迁移。
目前不支持 InteralLoadBalancingMode。	对于已将 InternalLoadBalancingMode 设置为特定值的应用服务环境，目前无法使用迁移功能进行迁移。 InternalLoadBalancingMode 必须由 Microsoft 团队手动更改。	创建支持案例，以联系支持人员来解决问题。 请求更新 InternalLoadBalancingMode。
生成 IP 地址之前无法调用完整迁移。	如果在完成迁移前步骤之前尝试迁移，会出现此错误。	在尝试迁移之前，请确保完成所有预迁移步骤。 请参阅迁移分步指南。
无法在设置了自定义 DNS 后缀但未配置 AseV3 自定义 DNS 后缀配置的 Ase 上调用完整迁移。	现有应用服务环境将使用自定义域后缀。 必须在迁移过程中为应用服务环境 v3 配置自定义域后缀。	配置自定义域后缀。 如果你不再想使用自定义域后缀，可以在迁移完成后将其删除。

使用并排迁移功能的迁移过程概述

并排迁移包括一系列必须按顺序执行的步骤。 下面介绍了一些步骤的要点。 重要的是要了解在这些步骤中会发生的情况以及你的环境和应用会受到怎样的影响。 查看以下信息并准备好进行迁移后，请按照分步指南操作。

验证是否支持使用并行迁移功能对应用服务环境进行迁移

该平台验证是否可使用并行迁移功能迁移应用服务环境。 如果你的应用服务环境没有通过所有验证检查，则此时你无法使用并行迁移功能进行迁移。 若要详细了解验证失败的可能原因，请参阅故障排除部分。 如果环境处于不正常或挂起状态，在你进行所需的更新之前无法迁移。 如果无法使用并行迁移功能进行迁移，请参阅手动迁移选项。

此验证还会检查你的应用服务环境是否在使用迁移所需的最低版本。 此版本可能比通过常规平台升级/维护周期部署的标准版本更新。 最低版本会定期更新，以确保有最新的 bug 修复和改进可用。 如果你的应用服务环境没有使用最低版本，你需要自行启动升级。 此升级是一个标准过程，其中你的应用服务环境不会受到影响，但你在升级过程中无法缩放或更改应用服务环境。 在升级完成之前，将无法迁移。 升级可能需要 8-12 小时或更长时间才能完成，具体取决于环境的大小。 如果计划迁移的特定时间范围，则应在计划迁移时间前 24-48 小时运行验证检查，以确保有时间进行升级（如果需要）。

为新的应用服务环境 v3 选择并准备子网

该平台会在与你现有的应用服务环境不同的子网中创建新的应用服务环境 v3。 你需要选择一个满足以下要求的子网：

• 该子网必须位于与你现有的应用服务环境相同的虚拟网络中，因此也位于同一 Azure 区域中。
  • 如果你的虚拟网络没有可用的子网，则需要创建一个。 你可能需要增加虚拟网络的地址空间才能创建新子网。 有关详细信息，请参阅创建虚拟网络。
• 该子网必须能够与现有应用服务环境所在的子网进行双向通信。 确保没有网络安全组或其他网络配置会阻止子网之间的通信。
• 该子网必须具有 Microsoft.Web/hostingEnvironments 的单个委派。
• 该子网必须有足够的可用 IP 地址来支持新的应用服务环境 v3。 所需的 IP 地址数取决于要用于新应用服务环境 v3 的实例数。 有关详细信息，请参阅应用服务环境 v3 网络。
• 该子网不得应用任何锁。 如果存在锁，则必须在迁移之前将其移除。 迁移完成后，可以根据需要读取锁。 有关锁和锁继承的详细信息，请参阅锁定资源以保护基础结构。
• 不得有任何 Azure 策略阻止迁移或相关操作。 如果存在阻止创建应用服务环境或修改子网的策略，则必须在迁移之前移除它们。 迁移完成后，可以根据需要读取策略。 有关 Azure Policy 的详细信息，请参阅 Azure Policy 概述。

为新的应用服务环境 v3 生成出站 IP 地址

平台会创建新的出站 IP 地址。 创建这些 IP 时，现有应用服务环境的活动不会中断，但是，你将无法扩展或更改现有环境。 此过程需要大约 15 分钟才能完成。

完成后，将会创建将来应用服务环境 v3 使用的新出站 IP。 这些新 IP 对现有环境没有任何影响。

迁移完成后，进行 DNS 更改以将客户流量重定向到新的应用服务环境 v3 之前，你会收到新的入站 IP 地址。 此时无法获取入站 IP，因为存在对迁移步骤期间创建的应用服务环境 v3 资源的依赖项。 在将流量重定向到新的应用服务环境 v3 之前，你有机会更新依赖于新的入站 IP 的任何资源。

使用新的出站 IP 更新依赖资源

在开始实际的迁移之前，新的出站 IP 会被创建并给予你。 新的到 Internet 公共地址的默认出站会被提供，以便你可以在完成迁移之前调整任何外部防火墙、DNS 路由、网络安全组和依赖于这些 IP 的任何其他资源。 你负责更新将受与新应用服务环境 v3 关联的 IP 地址更改影响的所有资源。 在完成所有必要的更新之前，请不要继续执行下一步。 如果对出站 IP 具有依赖项，并且无法进行所有必要的更新，则迁移步骤期间和完成后可能会遇到停机。 这是因为迁移开始后，即使流量仍转到应用服务环境 v2 前端，但基础计算是新子网中的新应用服务环境 v3。

此步骤也提供了一个很好的机会来查看在迁移到应用服务环境 v3 时入站和出站网络依赖项的变化，包括 Azure 负载均衡器运行状况探测的端口变化，它现在使用端口 80。

委托应用服务环境子网

应用服务环境 v3 要求其中的子网具有 Microsoft.Web/hostingEnvironments 的单一委托。 如果没有委托应用服务环境的子网，或将其委托给其他资源，则迁移无法成功。 确保你为新的应用服务环境 v3 选择的子网具有 Microsoft.Web/hostingEnvironments 的单个委派。

确认实例大小更改

你的应用服务计划是在迁移过程中使用相应的独立 v2 SKU 创建的。 例如，I2 计划对应于 I2v2。 你的应用可能会在迁移后过度预配，因为独立 v2 层在每个相应实例大小上具有更多内存和 CPU。 迁移完成后，可以根据需要缩放环境。 有关详细信息，请查看 SKU 详细信息。

确保资源中没有锁

在迁移期间，虚拟网络锁会阻止平台操作。 如果虚拟网络具有锁，则需要在迁移之前将其删除。 迁移完成后，可以根据需要读取锁。 锁可以存在于三个不同的范围：订阅、资源组和资源。 在父范围应用锁时，该范围内所有资源都会继承相同的锁。 如果在订阅、资源组或资源范围内应用了锁，则需要在迁移前将其删除。 有关锁和锁继承的详细信息，请参阅锁定资源以保护基础结构。

确保没有阻止迁移的 Azure Policy

Azure Policy 可用于拒绝对某些主体创建和修改资源。 如果有策略阻止创建应用服务环境或修改子网，则需要在迁移之前将其删除。 迁移完成后，可以根据需要读取策略。 有关 Azure Policy 的详细信息，请参阅 Azure Policy 概述。

添加自定义域后缀（可选）

如果你的现有应用服务环境使用自定义域后缀，则必须为新的应用服务环境 v3 配置自定义域后缀。 应用服务环境 v3 上的自定义域后缀与应用服务环境 v2 上的实现方式不同。 你需要提供自定义域名、托管标识和证书，它们必须存储在 Azure Key Vault 中。 有关应用服务环境 v3 自定义域后缀（包括要求、分步说明和最佳做法）的详细信息，请参阅为应用服务环境配置自定义域后缀。 如果应用服务环境 v2 具有自定义域后缀，则必须为新环境配置自定义域后缀，即使你不再想要使用它。 迁移完成后，可根据需要删除自定义域后缀配置。

如果迁移包含自定义域后缀，则对于应用服务环境 v3，自定义域不会显示在门户“概述”页面的“基本信息”部分中，因为它适用于应用服务环境 v1/v2。 对于应用服务环境 v3，请转到“自定义域后缀”页面，可在其中确认自定义域后缀配置是否正确。 此外，在应用服务环境 v2 上，如果有自定义域后缀，则默认主机名包括自定义域后缀，并且格式为 APP-NAME.internal.contoso.com。 在应用服务环境 v3 上，默认主机名始终使用默认域后缀，格式为 APP-NAME.ASE-NAME.appserviceenvironment.net。 区别在于，添加自定义域后缀时，应用服务环境 v3 保留默认域后缀。 使用应用服务环境 v2 时，只有一个域后缀。

迁移到应用服务环境 v3

完成上述步骤后，应尽快继续迁移。

迁移期间不会出现应用程序停机时间，但与 IP 生成步骤一样，你无法在此过程期间缩放、修改现有应用服务环境或将应用部署到它。

重要

由于迁移期间阻止了缩放，因此在开始迁移之前，你应将环境缩放为所需的大小。 如果启用了自动缩放，并且在迁移开始之前发生了缩放事件，则你必须等待缩放事件完成，然后才能开始迁移。 应在开始迁移之前禁用自动缩放，以避免此问题。 如果需要在迁移后缩放环境，可以在迁移完成后执行此操作。

你还需在此步骤中决定是否要为新的应用服务环境 v3 启用区域冗余。 只要你的应用服务环境 v3 位于支持区域冗余的 Azure 区域，就可以启用区域冗余。

应用服务环境 v2 到 v3 的并排迁移需要三到六小时的服务时段。 在迁移期间，缩放和环境配置被阻止，并发生以下事件：

• 你选择的子网中会创建新的应用服务环境 v3。
• 新的应用服务计划是在具有相应独立 v2 层的新应用服务环境 v3 中创建的。
• 你的应用是在新的应用服务环境 v3 中创建的。
• 应用的基础计算/辅助角色已移动到新的应用服务环境 v3，这意味着应用现在在应用服务环境 v3 上运行。 但是，应用服务环境 v2 前端默认仍在运行并提供流量服务。 旧的入站 IP 地址仍在使用中，但新的出站 IP 正在使用中。 此外，新的应用服务环境 v3 前端已创建并准备好提供流量服务。
  • 对于 ILB 应用服务环境，在使用新的入站 IP 地址更新专用 DNS 区域之前，不会使用应用服务环境 v3 前端。
  • 对于 ELB 应用服务环境，在完成迁移的最后一步之前，迁移过程不会将流量重定向到应用服务环境 v3 前端。

此步骤完成后，你的应用程序流量仍会转到旧的应用服务环境 v2 前端和分配给它的入站 IP。 但是，应用实际上在新的应用服务环境 v3 中的辅助角色上运行。

注意

由于一个已知 bug，在混合部署步骤中可能无法启动网络作业。 如果使用 Web 作业，则此 bug 可能会导致应用问题/停机。 如果对此问题有任何疑问或担忧，请提交支持案例。

获取新的应用服务环境 v3 的入站 IP 地址并更新依赖资源

提供了新的入站 IP 地址，以便你可以使用流量管理器或 Azure Front Door 等服务设置新终结点，并更新任何专用 DNS 区域。 在做出这些更改之前，请不要继续执行下一步。 如果不使用新的入站 IP 更新依赖资源，则会出现停机。 你负责更新受与新应用服务环境 v3 关联的 IP 地址更改影响的所有资源。 在完成所有必要的更新之前，请不要继续执行下一步。

重定向客户流量、验证应用服务环境 v3 并完成迁移

最后一步是将流量重定向到新的应用服务环境 v3 前端并完成迁移。 在执行此步骤之前，你应检查新的应用服务环境 v3 并执行任何所需的测试，以验证它是否按预期运行。 默认情况下，流量会转到你的应用服务环境 v2 前端。 如果你使用的是 ILB 应用服务环境 v3，则可以通过使用新的入站 IP 地址更新专用 DNS 区域来测试应用服务环境 v3 前端。 如果使用的是 ELB 应用服务环境 v3，则测试过程取决于特定的网络配置。 测试 ELB 环境的一种简单方法是更新主机文件，以使用新的应用服务环境 v3 入站 IP 地址。 如果已将自定义域分配给单个应用，则可以改为更新其 DNS 以指向新的入站 IP。 通过测试此项更改，可以在启动最后一个迁移步骤（此步骤会删除旧的应用服务环境）之前全面验证应用服务环境 v3。

准备好重定向流量后，即可完成迁移的最后一步。 此步骤会更新内部/平台 DNS 记录，以指向新的应用服务环境 v3 的负载均衡器 IP 地址和在迁移期间创建的前端。 更改将在几分钟内生效。 你负责将 DNS 记录更新为指向新的入站 IP 地址。 如果遇到问题或应用程序停机，请检查缓存和 TTL 设置。 此步骤还会关闭旧的应用服务环境并删除它。 新的应用服务环境 v3 现在是你的生产环境。

重要

该平台保证零停机时间迁移体验。 但是，DNS 设置可能会导致 DNS 更改步骤期间停机。 这可能是由于与 TTL 和缓存设置相关的问题，因为在 DNS 更改后，流量可能仍会被定向到旧的应用服务环境。 应查看 DNS 设置，并确保具有较低的 TTL，并且 DNS 提供程序支持快速传播。 如果 TTL 较高，则 DNS 更改步骤期间可能会遇到停机。

注意

请务必尽快完成此步骤。 当应用服务环境处于混合状态时，它无法接收平台升级和安全修补程序，这使得它更容易受到不稳定和安全威胁的影响。

你有 14 天时间来完成此步骤。 14 天后，平台会自动完成迁移并删除旧环境。 如果需要更多时间，可以开启支持案例来讨论你的选项。

如果你发现新的应用服务环境 v3 存在任何问题，请不要运行该命令来重定向客户流量。 此命令还会启动应用服务环境 v2 的删除。 如果发现问题，请联系支持人员。

使用并行迁移功能

先决条件

请确保了解迁移到应用服务环境 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. 验证迁移是否受支持

以下命令会检查应用服务环境是否支持迁移。 此命令还会验证应用服务环境是否在受支持的生成版本中进行迁移。 如果你的应用服务环境没有使用受支持的生成版本，你需要自行启动升级。 有关迁移前升级的详细信息，请参阅验证是否支持使用并排迁移功能对应用服务环境进行迁移。

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

如果没有错误，则表示支持迁移，可以继续执行下一步。

如果需要开始升级，将应用服务环境升级到受支持的生成版本（可能需要 8-12 小时或更长时间，具体取决于环境的大小），请运行以下命令。 仅当验证步骤失败，并且系统要求你升级应用服务环境时，才运行此命令。

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

4.为新的应用服务环境 v3 生成出站 IP 地址

运行以下命令来创建新的出站 IP 地址。 完成此步骤大约需要 15 分钟。 在此期间，请不要缩放或更改现有应用服务环境。

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

请运行以下命令，以检查此步骤的状态：

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，更新所有资源或网络组件，确保迁移启动后新环境按预期运行。 你应负责进行所有必要更新。 在迁移步骤期间创建应用服务环境 v3 后，将使用新的出站 IP。 例如，如果你有一个自定义域后缀和一个 Azure 密钥保管库，并且正在使用防火墙管理访问限制，那么你需要更新 Azure 密钥保管库的防火墙，使其允许新的出站 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 的新子网进行访问。 如果使用专用终结点访问密钥保管库，请确保已使用新子网正确配置了专用访问。 如果在迁移之前未正确设置此访问权限，则需要停机。

如果现有环境位于支持区域冗余的区域，可以将新的应用服务环境 v3 区域设置为冗余。 可以通过将 zoneRedundant 属性设置为 true 来配置区域冗余。 区域冗余是可选的配置。 只能在新建应用服务环境 v3 期间设置此配置，且后续无法删除。

若要设置这些配置（包括标识你前面选择的子网），请创建名为 parameters.json 的一个文件，并根据你的方案在其中包含以下详细信息。 请确保使用你为新的应用服务环境 v3 选择的新子网。 如果自定义域后缀不适用于你的迁移，请不要包含自定义域后缀的属性。 请注意 zoneRedundant 属性的值，并根据复原能力要求对其进行设置。

如果是在没有自定义域后缀的情况下进行迁移，请使用以下代码：

{
    "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 并检查状态

完成上述所有步骤后，即可开始迁移。 请确保了解迁移的影响。

此步骤需要三到六个小时才能完成。 在此期间，如果已执行上述步骤，则不会造成应用程序停机。 在此步骤中，会阻止对现有应用服务环境进行缩放、部署和修改。

注意

由于一个已知 bug，在混合部署步骤中可能无法启动网络作业。 如果使用 Web 作业，则此 bug 可能会导致应用问题/停机。 如果对此问题有任何疑问或担忧，请提交支持案例。

运行以下命令来启动迁移：

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 地址并更新依赖资源

在迁移过程的此阶段，有两组应用服务环境前端，并且两组前端都能够为应用程序流量提供服务。 DNS 不会更改，因此默认情况下，流量将发送到旧的应用服务环境前端。 需要将任何依赖资源更新为使用新的应用服务环境 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

重要

如果迁移包含自定义域后缀，则应用服务环境 v3 的默认主机名行为与应用服务环境 v2 不同。 对于应用服务环境 v3，默认主机名始终使用默认域后缀，格式为 APP-NAME.ASE-NAME.appserviceenvironment.net。 检查使用应用主机名的所有依赖资源（例如应用网关），确保它们已根据此行为进行了更新。 有关不同版本的应用服务环境功能差异的详细信息，请参阅应用服务环境版本比较。

11.重定向客户流量、验证应用服务环境 v3 并完成迁移

此步骤提供了测试和验证新应用服务环境 v3 的机会。

重要

你有 14 天时间来完成此步骤。 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”状态时，流量重定向步骤已完成，迁移已完成。

使用并行迁移功能进行迁移时的常见问题来源

下面是客户在使用并行迁移功能进行迁移时遇到的常见问题来源的示例。 应查看这些区域，以确保在迁移过程期间或之后不会发生停机或服务中断。

• Azure Key Vault 应允许来自新出站 IP/子网的流量。
• 这两个子网应该能够双向相互通信。 客户通常允许从旧子网到新子网的流量，但忘记允许从新子网到旧子网的流量。
• 应用网关应使用新的 IP 地址进行更新。
• DNS 记录应使用新的 IP 地址进行更新。
• 如果应用程序中已硬编码 IP 地址，则需要使用新的 IP 地址更新这些地址。
• 应使用任何新路由更新路由表。

定价

迁移应用服务环境无需任何费用。 但是，启动迁移过程后，你需要同时为应用服务环境 v2 和新的应用服务环境 v3 付费。 完成删除旧环境的最后一个迁移步骤后，你将停止为旧的应用服务环境 v2 付费。 应尽快完成验证，以防止累计额外费用。 有关应用服务环境 v3 定价的详细信息，请参阅定价详细信息。

从早期版本迁移到应用服务环境 v3 时，应考虑某些可能会降低每月成本的方案。 考虑预留和节省计划以进一步降低成本。 有关节省成本的机会的信息，请参阅升级到应用服务环境 v3 后的成本节省机会。

注意

由于隔离与隔离 v2 定价层之间的差异，你的应用可能会在迁移后过度预配，因为隔离 v2 层对每个相应的实例大小具有更多内存和 CPU。 迁移完成后，可以根据需要缩放环境。 有关详细信息，请查看 SKU 详细信息。

纵向缩减应用服务计划

可用于应用服务环境 v3 的应用服务计划 SKU 在独立 v2 (Iv2) 层上运行。 与独立层相比，每个相应层的核心数和 RAM 量实际上翻了一番。 迁移时，应用服务计划会转换为相应的层。 例如，I2 实例将转换为 I2v2。 虽然 I2 有两个核心和 7 GB RAM，但 I2v2 有四个核心和 16 GB RAM。 如果你预计容量要求保持不变，则会过度预配，并支付未使用的计算和内存费用。 对于此方案，可以将 I2v2 实例缩减到 I1v2，最终得到与之前类似的核心数和 RAM。

常见问题解答

• 如果当前不支持迁移我的应用服务环境怎么办？
  你目前无法使用并排迁移功能进行迁移。 如果你的环境不受支持，并且想要立即迁移，请参阅手动迁移选项。
• 如何选择适合我的迁移选项？
  查看迁移路径决策树，确定哪种选项最适合你的用例。
• 如何知道我是否应该使用并排迁移功能？
  并排迁移功能最适合想要迁移到应用服务环境 v3 但不支持应用程序停机的客户。 由于新的子网用于你的新环境，因此需要考虑网络注意事项，包括新的 IP。 如果你可以支持停机，请查看就地迁移功能，它会带来最少的配置更改，或查看手动迁移选项。 就地迁移功能会在你现有环境所在的子网中创建应用服务环境 v3，并使用相同的网络基础结构。
• 迁移期间是否会出现停机？
  平台保证在并排迁移过程中不会停机。 但是，DNS 设置可能会导致 DNS 更改步骤期间停机。 这可能是由于与 TTL 和缓存设置相关的问题，因为在 DNS 更改后，流量可能仍会被定向到旧的应用服务环境。 应查看 DNS 设置，并确保具有较低的 TTL，并且 DNS 提供程序支持快速传播。
• 迁移后，我是否需要对应用执行任何操作，使其在新应用服务环境上运行？
  不需要，在旧环境上运行的所有应用都会自动迁移到新环境，并像以前一样运行。 无需用户输入。
• 如果我的应用服务环境具有自定义域后缀，应该怎么办？
  并排迁移功能支持此迁移方案。
• 如果我的应用服务环境是区域固定的，应该怎么办？
  并排迁移功能目前不支持此迁移方案。 如果你有一个区域固定的应用服务环境并想要立即迁移，请参阅手动迁移选项。
• 如果我的应用服务环境具有 IP SSL 地址，该怎么办？
  应用服务环境 v3 不支持 IP SSL。 在使用迁移功能或手动选项之一进行迁移之前，必须删除所有 IP SSL 绑定。 如果打算使用并排迁移功能，在移除所有 IP SSL 绑定后，需通过验证检查，然后可以继续进行自动迁移。
• 我的应用服务环境的哪些属性会更改？
  你在使用应用服务环境 v3，因此请务必查看与以前版本相比的特性和功能差异。 使用并排迁移功能时，入站和出站 IP 都会发生更改。 请注意，对于 ELB 应用服务环境，以前入站和出站使用同一个 IP。 对于应用服务环境 v3，它们是独立的。 有关详细信息，请参阅应用服务环境 v3 网络。 有关应用服务环境版本的完整比较，请参阅应用服务环境版本比较。
• 如果迁移失败或迁移期间出现意外问题，该怎么办？
  如果出现意外问题，支持团队随时待命。 建议在接触任何生产环境之前，应先迁移开发环境，了解迁移过程，并了解它会如何影响工作负载。
• 我的旧应用服务环境会怎样？
  如果你决定使用并排迁移功能迁移应用服务环境，则旧环境将一直用到迁移过程的最后一步。 完成最后一步后，旧环境及其承载的所有应用都会关闭并删除。 你的旧环境不再可访问。 此时无法还原到旧环境。
• 2024 年 8 月 31 日之后，应用服务环境 v1/v2 资源会怎样？
  2024 年 8 月 31 日之后，如果不迁移到应用服务环境 v3，则应用服务环境 v1/v2 以及其中部署的应用将不再可用。 应用服务环境 v1/v2 托管在应用服务缩放单元上，缩放单元在云服务（经典）体系结构上运行，该体系结构将于 2024 年 8 月 31 日停用。 因此，应用服务环境 v1/v2 在该日期之后将不再可用。 迁移到应用服务环境 v3，使应用保持运行，或者保存或备份需要维护的任何资源或数据。

后续步骤

应用服务环境 V3 网络

使用应用服务环境 v3

自定义域后缀