使用就地迁移功能迁移到应用服务环境 v3

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

就地迁移功能通过在同一子网中升级现有应用服务环境，自动迁移到应用服务环境 v3。 如果客户想要迁移到应用服务环境 v3，并且只想对网络配置进行最小更改，那么此迁移选项最适合他们。 还必须能够支持大约 1 小时的应用程序停机时间。 如果不支持停机，请参阅手动迁移选项。

支持的方案

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

由世纪互联运营的 Azure

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

可以使用就地迁移功能迁移以下应用服务环境配置。 该表提供了在使用基于现有应用服务环境的就地迁移功能时的应用服务环境 v3 配置。 只要环境位于支持区域冗余的区域，所有支持的应用服务环境都可以使用就地迁移功能迁移到区域冗余应用服务环境 v3。 可以在迁移过程中配置区域冗余。

如果你希望新的应用服务环境 v3 使用自定义域后缀，而当前没有使用，可以在迁移完成后随时配置自定义域后缀。 有关详细信息，请参阅为应用服务环境配置自定义域后缀。

可以通过导航到 Azure 门户中的应用服务环境，然后在左侧的“设置”下选择“配置”来找到应用服务环境的版本。

就地迁移功能限制

下面是使用就地迁移功能时的限制：

• 新应用服务环境 v3 在用于旧环境的现有子网中。
• 无法更改应用服务环境所在的区域。
• ELB 应用服务环境无法迁移到 ILB 应用服务环境 v3，反之亦然。
• 如果现有的应用服务环境使用自定义域后缀，则必须在迁移过程中为应用服务环境 v3 配置自定义域后缀。
  • 如果你不再想使用自定义域后缀，可以在迁移完成后将其删除。

应用服务环境 v3 不支持你的当前应用服务环境 v1 或 v2 可能使用的以下功能。

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

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

• 经典虚拟网络中的应用服务环境 v1
• 使用 IP SSL 地址的 ELB 应用服务环境 v2
• 使用 IP SSL 地址的 ELB 应用服务环境 v1
• 名称不符合字符限制的应用服务环境。 整个名称（包括域后缀）不得超过 64 个字符。 例如：ILB 的 my-ase-name.appserviceenvironment.cn 和 ELB 的 my-ase-name.p.chinacloudsites.cn 必须不超过 64 个字符。 如果不满足字符限制，则必须手动迁移。 专门针对应用服务环境名称的字符限制如下：
  • ILB 应用服务环境名称字符限制：36 个字符
  • ELB 应用服务环境名称字符限制：42 个字符

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

疑难解答

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

使用就地迁移功能的迁移过程概述

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

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

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

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

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

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

完成后，会向你提供你的未来应用服务环境 v3 使用的新 IP。 这些新 IP 对现有环境没有任何影响。 现有环境使用的 IP 会继续被使用，直到在迁移步骤中关闭现有环境。

使用新 IP 更新依赖资源

创建新的 IP 后，你将拥有新的默认出站到 Internet 公共地址。 在准备迁移时，可以调整任何外部防火墙、DNS 路由、网络安全组以及依赖于这些 IP 的任何其他资源。 对于 ELB 应用服务环境，还可以使用新的入站 IP 地址，通过流量管理器之类的服务设置新的终结点。 你负责更新将受与新应用服务环境 v3 关联的 IP 地址更改影响的所有资源。 在完成所有必要的更新之前，请不要继续执行下一步。 此步骤也提供了一个很好的机会来查看在迁移到应用服务环境 v3 时入站和出站网络依赖项的变化，包括 Azure 负载均衡器运行状况探测的端口变化，它现在使用端口 80。

委托应用服务环境子网

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

确认实例大小更改

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

确保资源中没有锁

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

确保没有阻止迁移的 Azure Policy

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

选择应用服务环境 v3 配置

可以在支持应用服务环境 v3 的 Azure 区域中跨可用性区域部署该服务。 此体系结构称为区域冗余。 只能在创建应用服务环境期间配置区域冗余。 如果你希望新的应用服务环境 v3 是区域冗余的，请在迁移过程中启用该配置。 只要使用的 Azure 区域支持应用服务环境 v3 的区域冗余，就可以将任何使用就地迁移功能进行迁移的应用服务环境配置为区域冗余。 如果你的现有环境正在使用不支持区域冗余的区域，则会禁用该配置选项，且你无法进行配置。 就地迁移功能不支持更改区域。 如果你想要使用不同的区域，请使用手动迁移选项之一。

如果你的现有应用服务环境使用自定义域后缀，系统会提示你为新的应用服务环境 v3 配置自定义域后缀。 需要提供自定义域名、托管标识和证书。 有关应用服务环境 v3 自定义域后缀的详细信息，包括要求、分步说明和最佳做法，请参阅为应用服务环境配置自定义域后缀。 必须为新的环境配置自定义域后缀，即使你不再想使用自定义域后缀。 迁移完成后，可根据需要删除自定义域后缀配置。

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

迁移到应用服务环境 v3

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

应用服务环境 v2 到 v3 的迁移需要三到六小时的服务时段。 根据 v1 到 v3 迁移的环境大小，最多需要 6 小时的服务时段。 在需要服务团队手动干预的极少数情况下，可能会扩展服务窗口。 在迁移期间，缩放和环境配置被阻止，并发生以下事件：

• 现有应用服务环境关闭并被替换为新的应用服务环境 v3。
• 应用服务环境中的所有应用服务计划都从隔离转换为隔离 v2 层。
• 应用服务环境中的所有应用都暂时关闭。 在此期间，预计大约有一小时的停机时间。
  • 如果无法支持停机时间，请参阅迁移备选方案。
• 应用服务环境使用的公共地址会更改为在 IP 生成步骤期间生成的 IP。

迁移过程中可使用以下状态：

与 IP 生成步骤一样，在此过程中，你无法缩放或修改应用服务环境或向其部署应用。 迁移完成后，旧应用服务环境中的应用会在新的应用服务环境 v3 上运行。

使用就地迁移功能

先决条件

请确保了解迁移到应用服务环境 v3 对应用程序的影响。 查看迁移过程，了解流程时间线以及需要参与的时间和位置。 另请查看常见问题解答，其中可以回答一些问题。

请确保虚拟网络、资源组、资源或订阅中没有锁定。 在迁移期间，锁会阻止平台操作。

请确保没有 Azure 策略会阻止迁移所需的操作，包括子网修改和 Azure 应用服务资源创建。 阻止资源修改和创建的策略可能会导致迁移停滞或失败。

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

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": "westchinanorth2",
    "properties": {
        "zoneRedundant": true
    }
}

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westchinanorth2",
    "properties": {
        "zoneRedundant": true,
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.cn/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": "westchinanorth2",
    "properties": {
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.cn/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

定价

迁移应用服务环境无需任何费用。 使用就地迁移功能时，当你之前的应用服务环境在迁移过程中关闭时，会立即停止对它的收费。 一旦部署新的应用服务环境 v3，就会开始向你收取费用。 有关应用服务环境 v3 定价的详细信息，请参阅定价详细信息。

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

纵向缩减应用服务计划

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

常见问题解答

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

后续步骤