通过

规划将 IaaS 资源从经典部署模型迁移到 Azure Resource Manager

适用于：✔️ Linux VM ✔️ Windows VM

重要

目前，大约有 90% 的 IaaS VM 在使用 Azure 资源管理器。 自 2020 年 2 月 28 日起，经典 VM 已弃用，并将于 2023 年 9 月 6 日完全停用。 详细了解此弃用以及它对你的影响。

尽管 Azure 资源管理器提供了许多精彩功能，但请务必计划迁移，以确保一切顺利进行。 花时间进行规划可确保执行迁移活动时不会遇到问题。

注释

以下指导的主要参与者为 Azure 客户顾问团队，以及与客户合作迁移大型环境的云解决方案架构师。 此文档随着出现新的成功模式而持续更新，因此，请不时地回来查看，了解是否有新的推荐内容。

迁移之旅包括四个常规阶段：

显示迁移阶段的屏幕截图。

计划

技术考量与权衡

根据技术要求大小、地理区域和操作方案，可能需要考虑：

  1. 为什么组织需要 Azure Resource Manager？ 迁移的业务原因有哪些？
  2. Azure Resource Manager 的技术原因有哪些？ 想要使用其他哪些 Azure 服务（如果有）？
  3. 迁移包括哪些应用程序（或虚拟机集）？
  4. 迁移 API 支持哪些方案？ 请参阅不支持的功能和配置。
  5. 运营团队目前是否支持经典部署模型和 Azure Resource Manager 中的应用程序/VM？
  6. Azure Resource Manager 如何更改 VM 部署、管理、监视和报告过程（如果有）？ 部署脚本是否需要更新？
  7. 用于提醒利益干系人（最终用户、应用程序所有者和基础结构所有者）的通信计划有哪些？
  8. 根据环境的复杂性，是否应有维护时段，其间应用程序对最终用户和应用程序所有者不可用？ 如果是这样，持续时间有多长？
  9. 用于确保利益干系人知识渊博且熟悉 Azure Resource Manager 的培训计划是什么？
  10. 用于迁移的项目管理计划是什么？
  11. Azure Resource Manager 迁移时间线和其他相关技术路线图有哪些？ 它们是否保持最佳的协调？

成功模式

成功的客户制定了详细计划，其中讨论、记录并管理了上述问题。 确保与发起人和利益干系人就迁移计划进行广泛交流。 使用迁移选项的知识武装自身，强烈建议浏览下面的迁移文档集。

需避免的错误

  • 未能规划。 该迁移的技术步骤证实是非常有效的，且结果是可预测的。
  • 平台支持的迁移 API 适用于所有场景的假设。 请参阅不受支持的功能和配置，了解支持的方案有哪些。
  • 未规划可能影响终端用户的应用故障。 计划足够的缓冲时间，以充分警告终端用户关于应用程序可能不可用的时间。

实验室测试

复制您的环境并执行测试迁移

注释

使用社区贡献的工具执行现有环境的确切复制，Azure 支持部门不支持该工具。 因此，这是一个 可选 步骤，但它是在不接触生产环境的情况下找出问题的最佳方式。 如果使用社区参与的工具不是一个选项，请阅读下面的“验证/准备/中止试运行”建议。

针对确切方案（计算、网络和存储）执行实验室测试是确保顺利迁移的最佳办法。 这有助于确保：

  • 完全独立的实验室或要测试的现有非生产环境。 建议使用可反复迁移和破坏性修改的完全独立的实验室。 下面列出了用于收集/水化实际订阅的元数据的脚本。

  • 在单独的订阅中创建实验室是个好办法。 原因是实验室将被反复关闭，单独拥有独立订阅可降低意外删除某实际内容的可能性。

    可以使用 AsmMetadataParser 工具实现此操作。 在此处了解有关该工具的详细信息

成功模式

下面是在许多大型迁移中发现的问题。 这个列表并不详尽，有关详细信息，请参阅不支持的功能和配置。 不一定会遇到这些技术问题，但如果遇到，在尝试迁移前先解决这些问题可确保体验更流畅。

  • 执行验证/准备/中止试运行 - 这可能是确保经典部署模型成功迁移到 Azure 资源管理器部署模型最重要的步骤。 迁移 API 有三个主要步骤：验证、准备和提交。 验证将读取经典环境的状态并返回所有问题的结果。 但是，由于某些问题可能存在于 Azure 资源管理器堆栈中，因此验证并不会捕获所有内容。 作为迁移过程下一步的“准备”有助于公开这些问题。 “准备”会将元数据从经典部署模型移动到 Azure 资源管理器部署模型，但不会提交移动，且不会删除或更改经典部署模型端的任何内容。 试运行涉及准备迁移，并中止（而不是提交）迁移准备。 验证/准备/中止试运行的目标是查看 Azure 资源管理器堆栈中的所有元数据，对其进行检查（以编程方式或在门户中 ），并验证所有内容是否正确迁移以及解决技术问题。 它还可让你对迁移持续时间有一些认识，以便可以相应地规划停机时间。 验证/准备/中止操作不会导致任何用户停机时间：因此，它对应用程序使用不具有破坏性。

    • 以下各项需要在试运行前解决，但如果错过了，试运行测试也会安全刷新这些准备步骤。 企业迁移期间，我们发现试运行是确保迁移准备就绪的安全且重要的方法。
    • 当准备运行时，将锁定整个虚拟网络的控制平面（即 Azure 管理操作），因此在验证、准备或中止期间，无法对虚拟机元数据进行任何更改。 但在其他方面，所有应用程序功能（RD、VM 使用等）均不受影响。 VM 用户不知道正在执行的是试运行。

  • Express Route 线路和 VPN。 当前含授权链接的 Express Route 网关无法在不中断服务的情况下进行迁移。 有关解决方法，请参阅将 ExpressRoute 线路和关联的虚拟网络从经典部署模型迁移到资源管理器部署模型。

  • VM 扩展 - 虚拟机扩展可能是迁移正在运行的 VM 的最大障碍之一。 VM 扩展修正可能需要 1-2 天，因此请相应进行规划。 需要一个正常工作的 Azure 代理来报告运行中 VM 的 VM 扩展状态。 如果正在运行的 VM 的状态返回为不佳，这将停止迁移。 代理本身无需处于正常运行状态即可启用迁移，但如果 VM 上存在扩展，则同时需要正常运行的代理和出站 Internet 连接（含 DNS）才能使迁移继续。

    • 如果在迁移过程中与 DNS 服务器的连接丢失，则除 BGInfo v1.* 之外的所有 VM 扩展都需要先从每个 VM 中删除，然后再准备迁移，然后在 Azure 资源管理器迁移后重新重新添加到 VM。 这仅适用于正在运行的 VM。 如果 VM 被停止并解除分配，则无需删除 VM 扩展。 注意：Azure 诊断和 Defender for Cloud 监视等诸多扩展在迁移后将重新安装，因此删除它们没有问题。

    • 此外，确保网络安全组不限制出站 Internet 访问权限。 这可能发生在某些网络安全组配置中。 若要使 VM 扩展迁移到 Azure Resource Manager，出站 Internet 访问权限（和 DNS）是必需的。

    • BGInfo 扩展有两个版本：v1 和 v2。 如果 VM 是通过使用 Azure 门户或 PowerShell 创建的，则该 VM 上可能具有 v1 扩展。 此扩展无需删除且会被迁移 API 跳过（即不迁移）。 但是，如果经典 VM 是使用新的 Azure 门户创建的，它很可能具有基于 JSON 的 v2 版本的 BGInfo，该版本可迁移到 Azure Resource Manager，只要代理正常运行且具有出站 Internet 访问权限（和 DNS）。

    • 补救选项 1。 如果你知道 VM 不会有出站 Internet 访问权限、正常运行的 DNS 服务和 VM 上正常运行的 Azure 代理，则在准备前在迁移期间卸载所有 VM 扩展，并在迁移后重新安装这些 VM 扩展。

    • 补救选项 2。 如果 VM 扩展成为一个过于重大的障碍，那么另一种选择是在迁移之前关闭/解除分配所有 VM。 迁移已解除分配的 VM，并在 Azure Resource Manager 端重新启动它们。 这里的好处是 VM 扩展可以迁移。 缺点是，所有面向公众的虚拟 IP 都将丢失（这可能是一个无法接受的选项），显然，关闭 VM 会对正在运行的应用程序产生更大的影响。

      注释

      如果针对要迁移的正在运行的 VM 配置 Microsoft Defender for Cloud 策略，则在删除扩展前需要停止安全策略，否则会在删除扩展后自动重新安装安全监视扩展。

  • 可用性集 - 对于要迁移到 Azure Resource Manager 的虚拟网络 (vNet)，经典部署（即云服务）包含的 VM 必须全部位于同一个可用性集中，或者 VM 均不得位于任何可用性集中。 云服务中具有多个可用性集无法兼容 Azure 资源管理器，并且将导致迁移暂停。 此外，不能出现一些 VM 位于可用性集，而一些 VM 不位于可用性集的情况。 若要解决此问题，需要修正或重新配置云服务。 请相应地进行规划，因为这可能很耗时。

  • Web/辅助角色部署 - 包含 Web 和辅助角色的云服务无法迁移到 Azure 资源管理器。 必须先从虚拟网络中删除 Web/辅助角色，才能开始迁移。 典型的解决方案只是将 Web/辅助角色实例移到单独的经典虚拟网络中，该网络也链接到了 ExpressRoute 回路，或者将代码迁移到较新的 PaaS 应用服务（此讨论已超出本文范围）中。 在前一个重新部署用例中，创建新的经典虚拟网络，将该 Web/辅助角色移动/重新部署到该新虚拟网络，并从要删除的虚拟网络中删除这些部署。 无需更改代码。 新的虚拟网络对等互连功能可以用来使包含 Web/辅助角色的经典虚拟网络和同一 Azure 区域中的其他虚拟网络（如正在迁移的虚拟网络）实现对等互联（虚拟网络迁移完成后，对等虚拟网络无法迁移），从而提供没有性能损失和延迟/带宽损失的相同功能。 鉴于增加了虚拟网络对等互连，现可轻松实现 Web/辅助角色部署，且不会阻止到 Azure 资源管理器的迁移。

  • Azure Resource Manager 配额 - 对于经典部署模型和 Azure Resource Manager 部署模型，Azure 区域都有单独的配额/限制。 即使在不使用新硬件的迁移方案中 （我们正在将现有的 VM 从经典部署模型切换到 Azure 资源管理器部署模型） ，Azure 资源管理器配额仍需处于容量充足的位置，然后才能开始迁移。 下面列出了我们已知的导致问题的主要限制。 开具配额支持票证来提高限制。

    注释

    需要在与要迁移的当前环境相同的区域中提高这些限制。

    • 网络接口

    • 负载均衡器

    • 公共 IP

    • 静态公共 IP

    • 核心

    • 网络安全组

    • 路由表

      可以通过最新版 Azure CLI 使用以下命令查看当前的 Azure 资源管理器配额。

      计算（核心数、可用性集数）

      az vm list-usage -l <azure-region> -o jsonc

      网络（虚拟网络、静态公共 IP、公共 IP、网络安全组、网络接口、负载均衡器和路由表）

      az network list-usages -l <azure-region> -o jsonc

      存储（存储帐户）

      az storage account show-usage

  • Azure Resource Manager API 限制 - 如果有足够大的环境（例如，VNET 中的 VM 数 > 400），则可能达到 Azure 资源管理器中的写入的默认 API 限制（当前为 1200 次写入/小时）。 在开始迁移之前，您应提交支持请求，以提高您的订阅限制。

  • 预配超时 VM 状态 - 如果任何 VM 具有状态“预配超时”，则需要在迁移前解决此问题。 执行此操作的唯一方法是通过停机期间取消部署并重新部署虚拟机（删除虚拟机，保留磁盘，然后重新创建虚拟机）。

  • RoleStateUnknown VM 状态 - 如果迁移因“角色状态未知”错误消息暂停，请使用门户检查 VM 并确保其正常运行。 此错误通常数分钟后会自行消失（无需修正），通常属于虚拟机启动、停止、重启操作期间经常看到的过渡类型。 建议的做法： 几分钟后再次重试迁移。

  • Fabric 群集不存在 - 在某些情况下，由于各种原因，某些 VM 无法迁移。 已知情况之一是当 VM 在最近（过去一周左右）创建，且碰巧获得尚未为 Azure 资源管理器工作负载配备的 Azure 群集。 出现错误，指出 结构群集不存在 ，VM 无法迁移。 等待数天通常可解决此特殊问题，因为群集会很快启用 Azure Resource Manager。 但是，一个直接的解决方法是对 VM 执行 stop-deallocate，然后继续迁移，并在迁移后在 Azure 资源管理器中开始 VM 备份。

需避免的错误

  • 不要走捷径和省略验证/准备/中止试运行迁移。
  • 即使不是全部，至少大多数潜在问题都会在验证/准备/中止期间浮现。

迁移

技术考量与权衡

因为已经解决了环境中的已知问题，所以现在你已准备就绪。

对于实际迁移，可能需要考虑：

  1. 使用递增的优先级规划和安排虚拟网络（迁移的最小单位）。 首先处理简单的虚拟网络，并循序渐进到更复杂的虚拟网络。
  2. 大多数客户都有非生产环境和生产环境。 最后安排生产。
  3. （可选） 安排具有足够缓冲区的维护停机时间，以防出现意外。
  4. 出现问题时，与支持团队沟通并保持一致。

成功模式

实际迁移前，应考虑上面“实验室测试”部分中的技术指南，并缓解其中的问题。 通过充分测试，实际上迁移不那么难。 对于生产环境，拥有更多支持（例如受信任的 Azure 合作伙伴或 Azure 顶级服务）可能会有所帮助。

需避免的错误

未完全测试可能导致迁移出现问题和延迟。

迁移之外

技术考量与权衡

既然采用了 Azure Resource Manager，便可以最大程度地发挥平台优势。 请参阅 Azure Resource Manager 概述，了解其他好处。

注意事项：

  • 将迁移与其他活动绑定。 大多数客户选择设置应用程序维护时段。 如果是这样，可能需要利用该停机时间启用加密和迁移到托管磁盘等其他 Azure Resource Manager 功能。
  • 再次浏览 Azure 资源管理器的技术和业务原因；启用仅在应用于环境的 Azure 资源管理器上适用的其他服务。
  • 使用 PaaS 服务实现环境现代化。

成功模式

对现在想要在 Azure Resource Manager 中启用哪些服务具有目的性。 许多客户认为以下几点对于他们的 Azure 环境非常有吸引力：

需避免的错误

请记住为何要开始这次从经典部署模型到 Azure Resource Manager 部署模型的迁移之旅。 最初的业务原因有哪些？ 是否实现了这些业务原因？

后续步骤