您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

规划将 IaaS 资源从经典部署模型迁移到 Azure 资源管理器Planning for migration of IaaS resources from classic to Azure Resource Manager

尽管 Azure 资源管理器提供了许多精彩功能,但请务必计划迁移,以确保一切顺利进行。While Azure Resource Manager offers many amazing features, it is critical to plan out your migration journey to make sure things go smoothly. 花时间进行规划可确保执行迁移活动时不会遇到问题。Spending time on planning will ensure that you do not encounter issues while executing migration activities.

备注

以下指导的主要参与者为 Azure 客户顾问团队,以及与客户合作迁移大型环境的云解决方案架构师。The following guidance was heavily contributed to by the Azure Customer Advisory team and Cloud Solution architects working with customers on migrating large environments. 此文档将随着出现新的成功模式而持续更新,因此,请不时地回来查看,了解是否有新的推荐内容。As such this document will continue to get updated as new patterns of success emerge, so check back from time to time to see if there are any new recommendations.

迁移之旅包括四个常规阶段:There are four general phases of the migration journey:

迁移阶段

计划Plan

技术注意事项和权衡Technical considerations and tradeoffs

根据技术要求大小、地理区域和操作方案,可能需要考虑:Depending on your technical requirements size, geographies and operational practices, you might want to consider:

  1. 为什么组织需要 Azure 资源管理器?Why is Azure Resource Manager desired for your organization? 迁移的业务原因有哪些?What are the business reasons for a migration?
  2. Azure 资源管理器的技术原因有哪些?What are the technical reasons for Azure Resource Manager? 想要利用其他哪些 Azure 服务(如果有)?What (if any) additional Azure services would you like to leverage?
  3. 迁移包括哪些应用程序(或虚拟机集)?Which application (or sets of virtual machines) is included in the migration?
  4. 迁移 API 支持哪些方案?Which scenarios are supported with the migration API? 请参阅不支持的功能和配置Review the unsupported features and configurations.
  5. 运营团队目前是否支持经典部署模型和 Azure 资源管理器中的应用程序/VM?Will your operational teams now support applications/VMs in both Classic and Azure Resource Manager?
  6. Azure 资源管理器如何更改 VM 部署、管理、监视和报告过程(如果有)?How (if at all) does Azure Resource Manager change your VM deployment, management, monitoring, and reporting processes? 部署脚本是否需要更新?Do your deployment scripts need to be updated?
  7. 用于提醒利益干系人(最终用户、应用程序所有者和基础结构所有者)的通信计划有哪些?What is the communications plan to alert stakeholders (end users, application owners, and infrastructure owners)?
  8. 根据环境的复杂性,是否应有维护时段,其间应用程序对最终用户和应用程序所有者不可用?Depending on the complexity of the environment, should there be a maintenance period where the application is unavailable to end users and to application owners? 如果需要,持续时间有多长?If so, for how long?
  9. 用于确保利益干系人知识渊博且熟悉 Azure 资源管理器的培训计划是什么?What is the training plan to ensure stakeholders are knowledgeable and proficient in Azure Resource Manager?
  10. 用于迁移的项目管理计划是什么?What is the program management or project management plan for the migration?
  11. Azure 资源管理器迁移时间线和其他相关技术路线图有哪些?What are the timelines for the Azure Resource Manager migration and other related technology road maps? 它们是否保持最佳的协调?Are they optimally aligned?

成功模式Patterns of success

成功迁移的客户制定了详细计划,在此期间讨论、记录并控制了上述问题。Successful customers have detailed plans where the preceding questions are discussed, documented and governed. 确保与发起人和利益干系人就迁移计划进行广泛交流。Ensure the migration plans are broadly communicated to sponsors and stakeholders. 使用迁移选项的知识武装自身,强烈建议浏览下面的迁移文档集。Equip yourself with knowledge about your migration options; reading through this migration document set below is highly recommended.

需避免的错误Pitfalls to avoid

  • 未能规划。Failure to plan. 该迁移的技术步骤证实是非常有效的,且结果是可预测的。The technology steps of this migration are proven and the outcome is predictable.
  • 平台支持的迁移 API 将适用于所有方案的假设。Assumption that the platform supported migration API will account for all scenarios. 请参阅不受支持的功能和配置,了解支持的方案有哪些。Read the unsupported features and configurations to understand what scenarios are supported.
  • 未针对最终用户规划可能的应用程序故障。Not planning potential application outage for end users. 计划足够的缓冲区来充分警告最终用户可能不可用的应用程序时间。Plan enough buffer to adequately warn end users of potentially unavailable application time.

实验室测试Lab Test

复移制环境并执行测试迁Replicate your environment and do a test migration

备注

使用社区贡献的、Microsoft 支持部门尚不正式支持的工具按原样复制现有环境。Exact replication of your existing environment is executed by using a community-contributed tool which is not officially supported by Microsoft Support. 因此,它是可选步骤,但它是无需接触生产环境即可找到问题的最佳办法。Therefore, it is an optional step but it is the best way to find out issues without touching your production environments. 如果不能使用社区提供的工具,请阅读下面的验证/准备/中止试运行建议。If using a community-contributed tool is not an option, then read about the Validate/Prepare/Abort Dry Run recommendation below.

针对确切方案(计算、网络和存储)执行实验室测试是确保顺利迁移的最佳办法。Conducting a lab test of your exact scenario (compute, networking, and storage) is the best way to ensure a smooth migration. 这有助于确保:This will help ensure:

  • 待测试的是完全独立的实验室或现有的非生产环境。A wholly separate lab or an existing non-production environment to test. 建议使用可反复迁移和破坏性修改的完全独立的实验室。We recommend a wholly separate lab that can be migrated repeatedly and can be destructively modified. 下面列出了用于收集/水化实际订阅的元数据的脚本。Scripts to collect/hydrate metadata from the real subscriptions are listed below.
  • 在单独的订阅中创建实验室是个好办法。It's a good idea to create the lab in a separate subscription. 原因是实验室将被反复拆毁,单独拥有独立订阅可降低意外删除某实际内容的可能性。The reason is that the lab will be torn down repeatedly, and having a separate, isolated subscription will reduce the chance that something real will get accidentally deleted.

    可以使用 AsmMetadataParser 工具实现此操作。This can be accomplished by using the AsmMetadataParser tool. 在此处了解有关该工具的详细信息Read more about this tool here

成功模式Patterns of success

下面是在许多大型迁移中发现的问题。The following were issues discovered in many of the larger migrations. 这个列表并不详尽,有关详细信息,请参阅不支持的功能和配置This is not an exhaustive list and you should refer to the unsupported features and configurations for more detail. 不一定会遇到这些技术问题,但如果遇到,在尝试迁移前先解决这些问题可确保体验更流畅。You may or may not encounter these technical issues but if you do solving these before attempting migration will ensure a smoother experience.

  • 执行验证/准备/中止试运行 - 这可能是确保经典部署模型成功迁移到 Azure 资源管理器部署模型最重要的步骤。Do a Validate/Prepare/Abort Dry Run - This is perhaps the most important step to ensure Classic to Azure Resource Manager migration success. 迁移 API 包括三个主要步骤:验证、准备和提交。The migration API has three main steps: Validate, Prepare and Commit. 验证将读取经典环境的状态并返回所有问题的结果。Validate will read the state of your classic environment and return a result of all issues. 但是,由于某些问题可能存在于 Azure 资源管理器堆栈中,因此验证并不会捕获所有内容。However, because some issues might exist in the Azure Resource Manager stack, Validate will not catch everything. 作为迁移过程下一步的“准备”有助于公开这些问题。The next step in migration process, Prepare will help expose those issues. “准备”会将元数据从经典部署模型移动到 Azure 资源管理器部署模型,但不会提交移动,且不会删除或更改经典部署模型端的任何内容。Prepare will move the metadata from Classic to Azure Resource Manager, but will not commit the move, and will not remove or change anything on the Classic side. 试运行涉及准备迁移,并中止(而不是提交)迁移准备。The dry run involves preparing the migration, then aborting (not committing) the migration prepare. 验证/准备/中止试运行的目标是查看 Azure 资源管理器堆栈中的所有元数据,对其进行检查(以编程方式或在门户中),并验证所有内容是否正确迁移以及解决技术问题。The goal of validate/prepare/abort dry run is to see all of the metadata in the Azure Resource Manager stack, examine it (programmatically or in Portal), and verify that everything migrates correctly, and work through technical issues. 它还可让你对迁移持续时间有一些认识,以便可以相应地规划停机时间。It will also give you a sense of migration duration so you can plan for downtime accordingly. 验证/准备/中止操作不会导致任何用户停机时间:因此,它对应用程序使用不具有破坏性。A validate/prepare/abort does not cause any user downtime; therefore, it is non-disruptive to application usage.

    • 以下各项需要在试运行前解决,但如果错过了,试运行测试也会安全刷新这些准备步骤。The items below will need to be solved before the dry run, but a dry run test will also safely flush out these preparation steps if they are missed. 企业迁移期间,我们发现试运行是确保迁移准备就绪的安全且重要的方法。During enterprise migration, we've found the dry run to be a safe and invaluable way to ensure migration readiness.
    • 准备运行期间,将对整个虚拟网络锁定控制平面(Azure 管理操作),因此在验证/准备/中止期间无法对 VM 元数据进行任何更改。When prepare is running, the control plane (Azure management operations) will be locked for the whole virtual network, so no changes can be made to VM metadata during validate/prepare/abort. 但在其他方面,所有应用程序功能(RD、VM 使用等)均不受影响。But otherwise any application function (RD, VM usage, etc.) will be unaffected. VM 用户不知道正在执行的是试运行。Users of the VMs will not know that the dry run is being executed.
  • Express Route 线路和 VPNExpress Route Circuits and VPN. 当前含授权链接的快速路由网关不能在不停机的情况下集成。Currently Express Route Gateways with authorization links cannot be migrated without downtime. 有关解决方法,请参阅将 ExpressRoute 线路和关联的虚拟网络从经典部署模型迁移到 Resource Manager 部署模型For the workaround, see Migrate ExpressRoute circuits and associated virtual networks from the classic to the Resource Manager deployment model.

  • VM 扩展 - 虚拟机扩展可能是迁移正在运行的 VM 的最大障碍之一。VM Extensions - Virtual Machine extensions are potentially one of the biggest roadblocks to migrating running VMs. VM 扩展修正可能需要 1-2 天,因此请相应进行规划。Remediation of VM Extensions could take upwards of 1-2 days, so plan accordingly. 一个有效的 Azure 代理是报告正在运行的 VM 的 VM 扩展状态所需的。A working Azure agent is needed to report back VM Extension status of running VMs. 如果正在运行的 VM 返回的状态为不佳,这会暂停迁移。If the status comes back as bad for a running VM, this will halt migration. 代理本身无需处于正常运行状态即可启用迁移,但如果 VM 上存在扩展,则同时需要正常运行的代理和出站 Internet 连接(含 DNS)才能使迁移继续。The agent itself does not need to be in working order to enable migration, but if extensions exist on the VM, then both a working agent AND outbound internet connectivity (with DNS) will be needed for migration to move forward.

    • 如果在迁移期间与 DNS 服务器的连接断开,那么在准备迁移之前,需要先从每个 VM 中删除所有 VM 扩展(BGInfo 版本 1.* 除外),随后再在 Azure 资源管理器迁移后将这些扩展重新添加回 VM。If connectivity to a DNS server is lost during migration, all VM Extensions except BGInfo version 1.* need to first be removed from every VM before migration prepare, and subsequently re-added back to the VM after Azure Resource Manager migration. 这仅适用于正在运行的 VM。This is only for VMs that are running. 如果已停止解除分配 VM,则无需删除 VM 扩展。If the VMs are stopped deallocated, VM Extensions do not need to be removed.

    备注

    Azure 诊断和安全中心监视等诸多扩展都会在迁移后重新安装,因此删除它们并不是问题。Many extensions like Azure diagnostics and security center monitoring will reinstall themselves after migration, so removing them is not a problem.

    • 此外,确保网络安全组不限制出站 Internet 访问权限。In addition, make sure Network Security Groups are not restricting outbound internet access. 这可能针对某些网络安全组配置。This can happen with some Network Security Groups configurations. 若要使 VM 扩展迁移到 Azure 资源管理器,出站 Internet 访问权限(和 DNS)是必需的。Outbound internet access (and DNS) is needed for VM Extensions to be migrated to Azure Resource Manager.
    • BGInfo 扩展有两个版本,分别称为“版本 1”和“版本 2”。Two versions of the BGInfo extension exist and are called versions 1 and 2.

      • 如果 VM 使用的是 BGInfo 版本 1 扩展,可以按原样保留此扩展。If the VM is using the BGInfo version 1 extension, you can leave this extension as is. 迁移 API 会跳过此扩展。The migration API skips this extension. 迁移后,可以添加此 BGInfo 扩展。The BGInfo extension can be added after migration.
      • 如果 VM 使用的是基于 JSON 的 BGInfo 版本 2 扩展,表明 VM 是使用 Azure 门户创建而成。If the VM is using the JSON-based BGInfo version 2 extension, the VM was created using the Azure portal. 迁移 API 会在迁移到 Azure 资源管理器期间添加此扩展,前提是代理可以正常运行且拥有出站 Internet 访问权限(和 DNS)。The migration API includes this extension in the migration to Azure Resource Manager, provided the agent is working and has outbound internet access (and DNS).
    • 补救选项 1Remediation Option 1. 如果你知道 VM 不会有出站 Internet 访问权限、正常运行的 DNS 服务和 VM 上正常运行的 Azure 代理,则在准备前在迁移期间卸载所有 VM 扩展,并在迁移后重新安装这些 VM 扩展。If you know your VMs will not have outbound internet access, a working DNS service, and working Azure agents on the VMs, then uninstall all VM extensions as part of the migration before Prepare, then reinstall the VM Extensions after migration.

    • 补救选项 2Remediation Option 2. 如果 VM 扩展是个大障碍,另一个方法是在迁移前关闭/解除分配所有 VM。If VM extensions are too big of a hurdle, another option is to shutdown/deallocate all VMs before migration. 迁移已解除分配的 VM,并在 Azure 资源管理器端重新启动它们。Migrate the deallocated VMs, then restart them on the Azure Resource Manager side. 这样做的好处是可迁移 VM 扩展。The benefit here is that VM extensions will migrate. 缺点是将丢失所有面向公众的虚拟 IP(这可能是非初学者),并且 VM 明显会关闭,从而对正常运行的应用程序产生大得多的影响。The downside is that all public facing Virtual IPs will be lost (this may be a non-starter), and obviously the VMs will shut down causing a much greater impact on working applications.

      备注

      如果针对要迁移的正在运行的 VM 配置 Azure 安全中心策略,则在删除扩展前需要停止安全策略,否则会在删除扩展后自动重新安装安全监视扩展。If an Azure Security Center policy is configured against the running VMs being migrated, the security policy needs to be stopped before removing extensions, otherwise the security monitoring extension will be reinstalled automatically on the VM after removing it.

  • 可用性集 - 对于要迁移到 Azure 资源管理器的虚拟网络 (vNet),经典部署(即云服务)包含的 VM 必须全部位于同一个可用性集中,或者 VM 均不得位于任何可用性集中。Availability Sets - For a virtual network (vNet) to be migrated to Azure Resource Manager, the Classic deployment (i.e. cloud service) contained VMs must all be in one availability set, or the VMs must all not be in any availability set. 云服务中具有多个可用性集与 Azure 资源管理器不兼容,并且迁移将暂停。Having more than one availability set in the cloud service is not compatible with Azure Resource Manager and will halt migration. 此外,不能出现一些 VM 位于可用性集,而一些 VM 不位于可用性集的情况。Additionally, there cannot be some VMs in an availability set, and some VMs not in an availability set. 若要解决此问题,需要修正或重新配置云服务。To resolve this, you will need to remediate or reshuffle your cloud service. 请相应地进行规划,因为这可能很耗时。Plan accordingly as this might be time consuming.

  • Web/辅助角色部署 - 包含 Web 和辅助角色的云服务无法迁移到 Azure 资源管理器。Web/Worker Role Deployments - Cloud Services containing web and worker roles cannot migrate to Azure Resource Manager. 必须先从虚拟网络中删除 Web/辅助角色,才能开始迁移。The web/worker roles must first be removed from the virtual network before migration can start. 典型的解决方案只是将 Web/辅助角色实例移到单独的经典虚拟网络中,该网络也链接到了 ExpressRoute 回路,或者将代码迁移到较新的 PaaS 应用服务(此讨论已超出本文范围)中。A typical solution is to just move web/worker role instances to a separate Classic virtual network that is also linked to an ExpressRoute circuit, or to migrate the code to newer PaaS App Services (this discussion is beyond the scope of this document). 在前一个重新部署用例中,创建了新的经典虚拟网络,将该 Web/辅助角色移动/重新部署到该新虚拟网络,然后从正在删除的虚拟网络中删除这些部署。In the former redeploy case, create a new Classic virtual network, move/redeploy the web/worker roles to that new virtual network, then delete the deployments from the virtual network being moved. 无需更改代码。No code changes required. 新的虚拟网络对等互连功能可以用来使包含 Web/辅助角色的经典虚拟网络和同一 Azure 区域中的其他虚拟网络(如正在迁移的虚拟网络)通力合作(虚拟网络迁移完成后,对等虚拟网络无法迁移),从而提供没有性能损失和延迟/带宽损失的相同功能。The new Virtual Network Peering capability can be used to peer together the classic virtual network containing the web/worker roles and other virtual networks in the same Azure region such as the virtual network being migrated (after virtual network migration is completed as peered virtual networks cannot be migrated), hence providing the same capabilities with no performance loss and no latency/bandwidth penalties. 鉴于增加了虚拟网络对等互连,现可轻易缓解 Web/辅助角色部署,且不会阻止到 Azure 资源管理器的迁移。Given the addition of Virtual Network Peering, web/worker role deployments can now easily be mitigated and not block the migration to Azure Resource Manager.

  • Azure 资源管理器配额 - 对于经典部署模型和 Azure 资源管理器部署模型,Azure 区域都有单独的配额/限制。Azure Resource Manager Quotas - Azure regions have separate quotas/limits for both Classic and Azure Resource Manager. 即使在不使用新硬件的迁移方案中 (我们正在将现有的 VM 从经典部署模型切换到 Azure 资源管理器部署模型),Azure 资源管理器配额仍需处于容量充足的位置,才能开始迁移。Even though in a migration scenario new hardware isn't being consumed (we're swapping existing VMs from Classic to Azure Resource Manager), Azure Resource Manager quotas still need to be in place with enough capacity before migration can start. 下面列出了我们已知的导致问题的主要限制。Listed below are the major limits we've seen cause problems. 开具配额支持票证来提高限制。Open a quota support ticket to raise the limits.

    备注

    需要在与要迁移的当前环境相同的区域中提高这些限制。These limits need to be raised in the same region as your current environment to be migrated.

    • 网络接口Network Interfaces
    • 负载均衡器Load Balancers
    • 公共 IPPublic IPs
    • 静态公共 IPStatic Public IPs
    • 核心数Cores
    • 网络安全组Network Security Groups
    • 路由表Route Tables

      可通过最新版 Azure PowerShell 使用以下命令查看当前的 Azure 资源管理器配额。You can check your current Azure Resource Manager quotas using the following commands with the latest version of Azure PowerShell.

      计算(核心数、可用性集数)Compute (Cores, Availability Sets)

      Get-AzureRmVMUsage -Location <azure-region>
      

      网络 (虚拟网络、静态公共 IP、公共 IP、网络安全组、网络接口、负载均衡器和路由表)Network (Virtual Networks, Static Public IPs, Public IPs, Network Security Groups, Network Interfaces, Load Balancers, Route Tables)

      Get-AzureRmUsage /subscriptions/<subscription-id>/providers/Microsoft.Network/locations/<azure-region> -ApiVersion 2016-03-30 | Format-Table
      

      存储 (存储帐户)Storage (Storage Account)

      Get-AzureRmStorageUsage
      
  • Azure 资源管理器 API 限制 - 如果有足够大的环境(如Azure Resource Manager API throttling limits - If you have a large enough environment (eg. 在 VNET 中有 > 400 VM),则可能达到 Azure 资源管理器中的写入的默认 API 限制(当前为 1200 writes/hour)。> 400 VMs in a VNET), you might hit the default API throttling limits for writes (currently 1200 writes/hour) in Azure Resource Manager. 开始迁移前,应开具支持票证为订阅提高此限制。Before starting migration, you should raise a support ticket to increase this limit for your subscription.

  • 预配超时 VM 状态 - 如果任何虚拟机具有状态 provisioning timed out,则需要在迁移前解决此问题。Provisioning Timed Out VM Status - If any VM has the status of provisioning timed out, this needs to be resolved pre-migration. 执行此操作的唯一方法是通过取消预配/重新预配 VM(删除、保留磁盘并重新创建 VM)来使用停机时间。The only way to do this is with downtime by deprovisioning/reprovisioning the VM (delete it, keep the disk, and recreate the VM).

  • RoleStateUnknown VM 状态 - 如果迁移因 role state unknown 错误消息暂停,请使用门户检查 VM 并确保其正常运行。RoleStateUnknown VM Status - If migration halts due to a role state unknown error message, inspect the VM using the portal and ensure it is running. 此错误通常数分钟后会自行消失(无需修正),通常属于虚拟机 startstoprestart 操作期间看到的过渡类型。This error will typically go away on its own (no remediation required) after a few minutes and is often a transient type often seen during a Virtual Machine start, stop, restart operations. 建议做法: 数分钟后尝试再次迁移。Recommended practice: re-try migration again after a few minutes.

  • Fabric 群集不存在 - 在某些情况下,由于各种原因,某些 VM 无法迁移。Fabric Cluster does not exist - In some cases, certain VMs cannot be migrated for various odd reasons. 已知情况之一是当 VM 创建于最近(过去一周左右),且碰巧获得尚未为 Azure 资源管理器工作负荷配备的 Azure 群集。One of these known cases is if the VM was recently created (within the last week or so) and happened to land an Azure cluster that is not yet equipped for Azure Resource Manager workloads. 将收到一条错误消息,指出无法迁移 fabric cluster does not exist 和 VM。You will get an error that says fabric cluster does not exist and the VM cannot be migrated. 等待数天通常可解决此特殊问题,因为群集会很快启用 Azure 资源管理器。Waiting a couple of days will usually resolve this particular problem as the cluster will soon get Azure Resource Manager enabled. 但是,一个直接的解决方法是对 VM 执行 stop-deallocate,继续迁移,并在迁移后在 Azure 资源管理器中开始 VM 备份。However, one immediate workaround is to stop-deallocate the VM, then continue forward with migration, and start the VM back up in Azure Resource Manager after migrating.

需避免的错误Pitfalls to avoid

  • 不要走捷径和省略验证/准备/中止试运行迁移。Do not take shortcuts and omit the validate/prepare/abort dry run migrations.
  • 即使不是全部,至少大多数潜在问题都会在验证/准备/中止期间浮现。Most, if not all, of your potential issues will surface during the validate/prepare/abort steps.

迁移Migration

技术注意事项和权衡Technical considerations and tradeoffs

现已准备就绪,因为环境的已知问题已得到解决。Now you are ready because you have worked through the known issues with your environment.

对于实际迁移,可能需要考虑:For the real migrations, you might want to consider:

  1. 使用递增的优先级规划和安排虚拟网络(迁移的最小单位)。Plan and schedule the virtual network (smallest unit of migration) with increasing priority. 首先处理简单的虚拟网络,然后循序渐进到更复杂的虚拟网络。Do the simple virtual networks first, and progress with the more complicated virtual networks.
  2. 大多数客户都有非生产环境和生产环境。Most customers will have non-production and production environments. 最后安排生产。Schedule production last.
  3. (可选) 安排具有足够缓冲区的维护停机时间,以防出现意外。(OPTIONAL) Schedule a maintenance downtime with plenty of buffer in case unexpected issues arise.
  4. 出现问题时,与支持团队沟通并保持一致。Communicate with and align with your support teams in case issues arise.

成功模式Patterns of success

实际迁移前,应考虑和缓解“实验室测试”部分中的技术指南。The technical guidance from the Lab Test section should be considered and mitigated prior to a real migration. 通过充分测试,实际上迁移不属于事件。With adequate testing, the migration is actually a non-event. 对于生产环境,具有其他支持,如受信任的 Microsoft 合作伙伴或 Microsoft 高级服务等会很有帮助。For production environments, it might be helpful to have additional support, such as a trusted Microsoft partner or Microsoft Premier services.

需避免的错误Pitfalls to avoid

未完全测试可能导致迁移出现问题和延迟。Not fully testing may cause issues and delay in the migration.

迁移之外Beyond Migration

技术注意事项和权衡Technical considerations and tradeoffs

既然采用了 Azure 资源管理器,便可以最大程度地发挥平台优势。Now that you are in Azure Resource Manager, maximize the platform. 请参阅 Azure 资源管理器概述,了解其他好处。Read the overview of Azure Resource Manager to find out about additional benefits.

注意事项:Things to consider:

  • 将迁移与其他活动绑定。Bundling the migration with other activities. 大多数客户倾向于应用程序维护时段。Most customers opt for an application maintenance window. 如果是这样,可能需要利用该停机时间启用加密和迁移到托管磁盘等其他 Azure 资源管理器功能。If so, you might want to use this downtime to enable other Azure Resource Manager capabilities like encryption and migration to Managed Disks.
  • 再次浏览 Azure 资源管理器的技术和业务原因;启用仅在应用于环境的 Azure 资源管理器上适用的其他服务。Revisit the technical and business reasons for Azure Resource Manager; enable the additional services available only on Azure Resource Manager that apply to your environment.
  • 使用 PaaS 服务实现环境现代化。Modernize your environment with PaaS services.

成功模式Patterns of success

对现在想要在 Azure 资源管理器中启用哪些服务具有目的性。Be purposeful on what services you now want to enable in Azure Resource Manager. 许多客户找到以下关于其 Azure 环境令人关注的事实:Many customers find the below compelling for their Azure environments:

需避免的错误Pitfalls to avoid

请记住为何要开始这次从经典部署模型到 Azure 资源管理器部署模型的迁移之旅。Remember why you started this Classic to Azure Resource Manager migration journey. 最初的业务原因有哪些?What were the original business reasons? 是否实现了这些业务原因?Did you achieve the business reason?

后续步骤Next steps