Compartir a través de

防止和解决因应用服务环境的自动迁移导致的问题

重要

应用服务环境 v1 和 v2 已停用,不再受支持。 如果有应用服务环境 v1 或 v2,则必须迁移到应用服务环境 v3。 有关详细信息,请参阅升级到应用服务环境 v3

自动迁移是由 Microsoft 发起的迁移。 2024 年 9 月 1 日起,平台将使用就地迁移功能在最大程度上努力尝试自动迁移任何剩余的应用服务环境 v1 和 v2,但 Microsoft 对自动迁移后的应用程序可用性不作任何声明或保证。 你可能需要执行手动配置来完成迁移,并优化应用服务计划 SKU 选项来满足需求。 如果无法进行自动迁移,系统将会删除你的资源和关联的应用数据。 我们强烈建议你立即采取行动,以避免发生这两种极端情况之一。

如果应用服务环境 v1 或 v2 已自动迁移到应用服务环境 v3,则可能会遇到应用或服务问题。 本文提供有关如何解决这些问题的指导。

概述

2024 年 9 月 1 日之后,除非另有说明,否则所有应用服务环境 v1 和 v2 均可随时自动迁移到应用服务环境 v3。 平台发起自动迁移,这对于确保应用服务环境在受支持的平台上运行是必需的。

注意

自动迁移和删除以批处理方式完成。 如果应用服务环境尚未自动迁移,则随时可能会进行自动迁移或删除。 确保应用服务环境不会意外自动迁移或删除的唯一方法是请求 30 天的宽限期。

自动迁移是使用就地迁移功能完成的。 此迁移过程大约需要停机一小时。 在迁移过程中,应用服务环境的入站和出站 IP 地址可能会更改。 如果依赖于这些 IP 地址,停机时间可能更长。 如果使用应用服务环境 v3 中不支持的功能,停机时间也可能更长。

宽限期

如果需要更多时间来完成迁移,我们可以提供 30 天的一次性宽限期。 应用服务环境不会在宽限期内自动迁移或删除。 宽限期结束后,我们将尝试自动迁移应用服务环境。 如果无法进行自动迁移,则资源和关联的应用数据会被删除。

若要获得此宽限期,请转到 Azure 门户并访问应用服务环境的“迁移”页。 如果有多个应用服务环境,则需要确认并获取每个需要更多迁移时间的环境的宽限期。

显示“迁移”页上的按钮的屏幕截图,你可以在其中确认提供的 30 天一次性宽限期。

获得宽限期后,“迁移”页顶部的横幅会显示宽限期结束日期。 可能需要刷新页面才能看到更新后的横幅。 横幅更新日期最多可能需要五分钟。

显示“迁移”页上的横幅的屏幕截图,其中显示了提供的 30 天宽限期的结束日期。

如果需要更多支持或有疑问,请使用 Azure 门户中的“迁移”页上的“创建支持工单”选项联系 Azure 支持。 在创建支持请求之前,请务必确认并获取每个需要更多迁移时间的环境的宽限期。 确认和宽限期可确保在处理支持请求时环境不会自动迁移。

显示“迁移”页上的按钮的屏幕截图,可在其中创建支持工单。

自动迁移限制

自动迁移是使用就地迁移功能完成的。 以下限制适用于自动迁移,类似于就地迁移限制

  • 新应用服务环境 v3 在用于旧环境的现有子网中。
  • 新应用服务环境 v3 与旧环境位于同一区域。
  • 新应用服务环境 v3 与旧环境位于同一资源组。
  • 所有资源都保留相同的名称和资源 ID。
  • 应用服务环境 v3 不支持基于 IP 的 TLS/SSL 绑定。 如果具有基于 IP 的 TLS/SSL 绑定,则必须在迁移完成后将其删除。 在删除绑定之前,应用将无法正常使用。
  • 经典虚拟网络中的应用服务环境 v1 不支持迁移。 如果在经典虚拟网络中有应用服务环境 v1,则必须手动迁移。 如果未请求 30 天宽限期,应用服务环境可随时被删除。
  • 中国东部 2 和中国北部 2 不提供就地迁移功能。 此功能不受支持,因为应用服务环境 v3 在这些区域中不可用。 因此,这些区域中的应用服务环境无法自动迁移。 如果这些区域中有应用服务环境,则必须手动迁移到受支持的区域之一,例如中国东部 3 或中国北部 3。 如果未请求 30 天宽限期,应用服务环境可随时被删除。

有关就地迁移的详细信息,以及查看自动迁移期间遵循的过程,请参阅使用就地迁移功能迁移到应用服务环境 v3

不符合自动迁移条件

有两种情况可能不符合自动迁移条件。 第一种情况是,当前环境位于不支持应用服务环境 v3 的区域。 另一种情况是在经典虚拟网络中有应用服务环境 v1。 如果不符合自动迁移条件,并且永远无法自动迁移,门户将显示一条消息,说明不符合条件的原因。 你必须手动迁移。 如果未请求 30 天宽限期,应用服务环境可随时被删除。

在某些情况下,可能会暂时无法自动迁移,但你可以解决阻塞性问题并启用自动迁移。 例如,如果在应用服务环境中具有资源锁,则可以删除资源锁以启用自动迁移。 资源锁、Azure Policy 或网络配置阻止的自动迁移会自动暂停。 如果需要取消暂停应用服务环境,请创建支持工单。

如果无法自动迁移,则门户中可能显示以下错误:

错误 建议
应用服务环境 v1 位于经典虚拟网络中。 经典虚拟网络不支持应用服务环境 v3。 你必须手动迁移
应用服务环境/虚拟网络/资源组/订阅存在阻止迁移的资源锁。 若要启用自动迁移,请删除资源锁。
有一个 Azure Policy 阻止迁移。 若要启用自动迁移,请删除任何阻止对应用服务环境或环境所在虚拟网络进行资源修改或删除的 Azure Policy。
应用服务环境位于不支持自动迁移的区域。 你必须手动迁移

应用服务环境已暂停时如何操作

如果应用服务环境已暂停,则有两种选项。

取消暂停和自行迁移

如果要自行迁移,请使用“迁移”页中的选项创建支持工单,查看是否可以取消暂停应用服务环境。 我们不能保证可以取消暂停环境

显示“迁移”页上的按钮的屏幕截图,可在其中创建支持工单,查看是否可以取消暂停环境。

作为应用服务环境 v3 恢复/取消暂停

若要加快迁移速度,可以将环境作为应用服务环境 v3 恢复/取消暂停。 若要将应用服务环境作为 v3 恢复,请转到 Azure 门户并访问应用服务环境的“迁移”页。 若要将环境作为应用服务环境 v3 恢复,请选择“立即迁移”按钮。 此按钮启动与自动迁移相同的过程。 限制、停机时间和其他注意事项与自动迁移相同。 如果有多个应用服务环境,则需要恢复每个暂停的环境。

显示“迁移”页上的按钮的屏幕截图,可在其中作为应用服务环境 v3 恢复。

限制自动迁移效果的功能

为了限制自动迁移的影响,我们在自动迁移功能中实现了以下功能。

出站 IP 地址保留

以前,在迁移过程中,应用服务环境的出站 IP 地址总是会更改。 现在,应用服务环境的出站 IP 地址可能会在迁移过程中保留。 应用服务环境 v1/v2 公共 IP 地址可能会保留,并用作应用服务环境 v3 的出站 IP 地址。 我们不能保证可以保留出站 IP 地址。 但是,应用服务环境 v3 有两个出站 IP 地址。 如果有自定义域后缀配置,并且通过公共 Internet 连接到 Azure 密钥保管库,则仍可能需要考虑另一个新的出站 IP 地址。

对于内部负载均衡器 (ILB) 应用服务环境迁移,始终保留入站 IP。 在自动迁移期间,此地址保持不变。

对于外部负载均衡器 (ELB) 应用服务环境迁移,入站 IP 仍会更改。 如果使用 A 记录指向应用服务环境的入站 IP 地址,则此更改可能会有影响。 如果使用 A 记录,则必须在迁移过程完成后更新 A 记录,使其指向新的入站 IP 地址。 如果使用 CNAME 记录,则可能无需进行任何 DNS 更改。 如果具有入站 IP 地址的任何其他依赖项,则必须相应地更新它们。

应用服务环境 v2 自定义域后缀配置兼容性

应用服务环境 v3 上的自定义域后缀与应用服务环境 v2 上的实现方式不同。 在应用服务环境 v2 上,证书将直接上传到应用服务环境。 此外,允许使用非通配符证书。 在应用服务环境 v3 上,证书必须存储在 Azure 密钥保管库中,应用服务环境必须能够访问密钥保管库。 此外,不允许使用非通配符证书。

为了减少自动迁移的影响,我们在应用服务环境 v3 上为应用服务环境 v2 自定义域后缀配置实现了有限的兼容性模式。 如果在应用服务环境 v2 上具有自定义域后缀配置,则配置将迁移到应用服务环境 v3。 证书将上传到应用服务环境 v3,配置将更新为使用上传的证书。 此过程是作为临时措施进行的,仅在当前证书到期之前有效。 在迁移过程完成后且证书到期之前,必须更新配置以使用 Azure 密钥保管库。 如果不更新配置,证书到期后,自定义域后缀将不起作用。 有关详细信息,请参阅应用服务环境 v3 上的自定义域后缀

重要

即使使用自定义域后缀兼容性模式,自定义域后缀配置也可能无法按预期工作。 我们不能保证自定义域后缀在自动迁移后正常工作。 强烈建议在迁移过程完成后尽快更新配置以使用 Azure 密钥保管库。

对具有基于 IP 的 TLS/SSL 绑定的应用的迁移支持

应用服务环境 v3 不支持基于 IP 的 TLS/SSL 绑定。 以前,迁移功能仅允许在删除绑定后进行迁移。 若要启用自动迁移,将进行自动验证,以检查基于 IP 的 TLS/SSL 绑定是否已删除。 如果具有基于 IP 的 TLS/SSL 绑定,则必须在迁移完成后将其删除。 在删除绑定之前,应用将无法正常使用。

解决自动迁移导致的问题

以下是在自动迁移后应用或服务可能会遇到的问题。 如果你的问题未在此处列出,并且需要帮助,请联系 Azure 支持

问题:应用服务环境 v3 使用旧自定义域后缀配置

如果在应用服务环境 v2 上具有自定义域后缀配置,则配置将迁移到应用服务环境 v3。 证书将上传到应用服务环境 v3,配置将更新为使用上传的证书。 此过程是作为临时措施进行的,仅在当前证书到期之前有效。 我们不能保证旧自定义域后缀配置在自动迁移后正常工作。

若要解决此不兼容问题,在迁移过程完成后且证书到期之前,必须更新配置以使用 Azure 密钥保管库。 如果不更新配置,证书到期后,自定义域后缀将不起作用。 若要更新自定义域后缀配置,请按照应用服务环境 v3 上的自定义域后缀中的步骤操作。

问题:应用服务环境 v3 上的应用具有基于 IP 的 TLS/SSL 绑定

应用服务环境 v3 不支持基于 IP 的 TLS/SSL 绑定。 迁移完成后,必须删除绑定。 在删除绑定之前,应用将无法正常使用。

问题:依赖资源未更新为使用新的入站 IP 地址

ILB 应用服务环境迁移会保留入站 IP 地址,因此无需执行任何操作。

ELB 应用服务环境迁移会更改入站 IP 地址。 如果使用 A 记录指向应用服务环境的入站 IP 地址,则必须在迁移过程完成后更新 A 记录以指向新的入站 IP 地址。 如果使用 CNAME 记录,则可能无需进行任何 DNS 更改。 如果具有入站 IP 地址的任何其他依赖项,则必须相应地更新它们。 迁移过程完成后,旧入站 IP 地址不再有效。

问题:依赖资源未更新为使用新的出站 IP 地址

应用服务环境 v3 有两个出站 IP 地址。 迁移过程后,现有的出站 IP 地址可能会被保留,但会创建另一个出站 IP。 如果有自定义域后缀配置,并且通过公共 Internet 连接到 Azure 密钥保管库,则可能需要考虑另一个新的出站 IP 地址。 如果未保留原始出站 IP 地址,则还必须考虑此更改。

问题:功能更改或与应用服务环境 v3 不兼容

通常,应用服务环境 v3 与应用服务环境 v1 和 v2 兼容。 但存在一些差异。 若要查看版本之间的差异,请查参阅应用服务环境版本比较。 如果你使用的功能在应用服务环境 v3 上不受支持或行为不同,则必须相应地更新应用。

以下是应用服务环境 v3 中的重要更改:

  • 不支持基于 IP 的 TLS/SSL 绑定。
  • 自定义域后缀配置不同。
  • 即使有自定义域后缀,也始终保留默认域。
  • 不允许自定义域后缀的非通配符证书。
  • 应用服务环境 v3 有两个出站 IP 地址。
  • 可用的 SKU 具有不同的大小。
  • 定价模型不同。
  • 网络模型不同。
  • FTPS 终结点结构不同。 不支持使用自定义域后缀访问 FTPS 终结点。
  • 如果虚拟网络中配置的自定义 DNS 服务器无法解析给定的名称,则应用服务环境 v3 不会回退到 Azure DNS。 如果需要此行为,请确保提供一个指向公共 DNS 的转发器,或者将 Azure DNS 包含在自定义 DNS 服务器的列表中。

定价

自动迁移应用服务环境无需任何费用。 当你之前的应用服务环境在迁移过程中关闭时,会立即停止对它的收费。 一旦部署新的应用服务环境 v3,就会开始向你收取费用。 有关应用服务环境 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。

应用服务环境 v1 和 v2 停用后的支持策略

以下声明代表自 2024 年 9 月 1 日起的 Azure 应用服务环境 v1 和 v2 支持策略。 不影响在应用服务环境 v3 上运行的工作负载。

此支持策略将在任何延期或宽限期结束时到期,届时你将获得 Microsoft 的书面批准,可以在计划的停用日期之后运行服务。 如果在该日期之前迁移失败,将导致所有剩余的 Azure 应用服务环境 v1 和 v2 停用,其中可能包括但不限于删除应用和数据、自动就地迁移和其他停用过程。

外延支持策略包含以下内容:

  • 自 2024 年 9 月 1 日起,服务级别协议 (SLA) 不再适用于应用服务环境 v1 和 v2。 如果在停用日期之后继续使用该产品,则表示你承认 Azure 不承诺对已停用的环境提供 99.95% 的 SLA。
  • 我们承诺维护平台,并允许你完成迁移。 因此,客户支持服务 (CSS) 和产品组 (PG) 支持渠道将继续以商业合理的方式处理支持案例和关键响应事件 (CRI)。 应用服务环境 v1 和 v2 中不会进行新的安全性和符合性投资。
  • 应用服务将根据此处记录的平台更新流程继续修补操作系统和语言运行时。
  • 应用服务将在推出 Azure 应用服务更新之前继续测试和验证,并将继续遵循平台更新的安全部署过程。
  • 应用服务将继续主动监视 Azure 应用服务环境 v1/v2 的生产占用情况,并将继续以与当前相同的紧迫性响应通过此监视检测到的问题。
  • Microsoft 将继续接受 Azure 应用服务支持案例,并及时推动 Azure 应用服务问题的解决。
  • 应用服务将继续针对可能出现的关键 Azure 应用服务平台 bug 应用补丁和修补程序。
  • 但是,由于所有云服务和 Azure 服务管理 (ASM)/RedDog 前端 (RDFE) 组件的停用,有效缓解由较低级别的 Azure 依赖项产生的问题的能力可能会受到损害。

建议尽快完成到 Azure 应用服务环境 v3 的迁移,以避免服务中断。 我们的团队可协助你完成迁移过程,并回答你可能遇到的任何问题。 有关停用和迁移步骤、可用资源和迁移优势的详细信息,请参阅产品文档

常见问题解答

  • 为什么我的应用服务环境 v1/v2 会出现应用程序暂时中断的情况?
    Azure 平台正在为云服务(经典)的停用做准备,它是应用服务环境 v1 和 v2 运行的基础结构。 在此准备期间,会出现暂时中断和服务中断的情况。 为了尽量减少这些中断的影响,我们建议尽快迁移到应用服务环境 v3。
  • 为什么我的应用服务环境会自动迁移?
    应用服务环境 v1 和 v2 已停用,不再受支持。 应用服务环境 v1 和 v2 的支持基础结构即将停用。 为了确保应用服务环境在受支持的平台上运行,Microsoft 启动向应用服务环境 v3 的自动迁移。
  • 为什么我的应用在自动迁移后无法正常使用?
    自动迁移后,由于功能更新或不兼容,应用或服务可能会遇到问题。 若要解决这些问题,请参阅解决自动迁移导致的问题
  • 什么是自动迁移过程中的停机时间?
    自动迁移过程大约需要停机一小时。 在迁移过程中,应用服务环境的入站和出站 IP 地址可能会更改。 如果依赖于这些 IP 地址,停机时间可能更长。 如果使用应用服务环境 v3 中不支持的功能,停机时间也可能更长。
  • 自动迁移是否需要付费?
    自动迁移应用服务环境无需任何费用。 当你之前的应用服务环境在迁移过程中关闭时,会立即停止对它的收费。 一旦部署新的应用服务环境 v3,就会开始向你收取费用。
  • 为什么我的应用服务环境被删除?
    如果无法进行自动迁移,则资源和关联的应用数据会被删除。 我们强烈建议立即采取行动,以避免这种情况发生。 如果需要更多时间来完成迁移,我们可以提供 30 天的一次性宽限期。 应用服务环境不会在宽限期内删除。 宽限期结束后,我们可能会删除应用服务环境和所有关联的数据。