标签：设置   ges   项目   请求   sub   完整性   关联   reac   创建虚拟机   

目录

一、前言    2

二、三种迁移方式及优缺点    2

三、迁移准备工作    4

（一）支持的ASM IAAS资源    5

（二）支持的迁移范围    5

（三）不支持的功能和配置    7

四、迁移计划制定    10

五、LAB环境测试    10

六、迁移    11

七、迁移后的完整测试    16

八、附录—常见问题索引    17

一、前言

Azure IAAS在Mooncake正式支持ARM模式已经有一段时间了，ASM模式下大部分功能配置需要通过Powershell来配置资源，而ARM模式下基本都可以通过Portal进行配置，同时还可以通过模板部署复杂的应用程序，使用VM扩展来配置虚拟机以及纳入了访问管理和标记。针对计算、网络和存储单独担供生命周期管理，给广大的IT管理员提供了非常好的用户体验。

当前很多购买Azure的企业仍在使用Azure ASM模式，造成一些管理及操作上的不便。今天我们就来谈谈如何从ASM平滑的甚至是0宕机的迁移至ARM。

二、三种迁移方式及优缺点

目前Azure从ASM迁移至ARM分三种方式：

1. 平台内置的迁移服务：

   这个服务是内置的，只需要你注册Resource Provider就可以使用。

   主要优点：

• 虚拟机无宕机时间
• 有官方支持

主要缺点：

• 迁移粒度只能通过vnet或者云服务来迁移,无法根据客户定制的方式,比如项目进行迁移
• 虚拟机和存储，网络要分开迁移，比较繁琐
• 不支持跨地区，跨订阅的迁移

1. ASMtoARM项目：支持单个虚拟机迁移的Powershell脚本

   官网地址：https://github.com/Azure/classic-iaas-resourcemanager-migration

   主要优点：

• 自动生成ARM模板和Powershell脚本
• 灵活组合，支持网络，NSG等

主要缺点：

• 无法支持多个虚拟机迁移
• 时间较长
• 有宕机时间
• 无官方支持

1. MigAZ，一个微软服务部门开发的迁移工具

   官方网址：https://github.com/Azure/classic-iaas-resourcemanager-migration/tree/master/migaz

   主要优点：

• 可以在不同的订阅之间迁移
• 客户自由选择需要迁移的资源
• 自动化迁移存储的工具
• 允许不同地区之间迁移

主要缺点：

• 有宕机时间
• 无官方支持

ASM模式下删除虚拟机后，使用VHD磁盘在ARM模式下创建虚拟机也是可以的。

对于生产环境的迁移，一定要非常谨慎，做好用户云端生产环境评估，选择一种或几种适合用户场景的解决方案，在本地LAB做完测试后，方可开始在用户的生产环境中迁移。

若用户是同一订阅下的ASM到ARM的迁移，建议大家用第一种方式—Azure平台内置的迁移方式，基本可以做到0宕机，保证你的迁移过程平滑而顺利，今天我们以第一种方式的实践经验给大家抛砖引玉。

三、迁移准备工作

首先，在迁移之前必须让客户了解ASM与ARM的数据平面及管理平面的差异，在迁移之后客户才能了解最新的ARM如何管理，如何根据自己的业务逻辑配置诸如ACL功能。差异主要体现在如下两点：

1. "管理/控制平面"：进入管理/控制平面或 API 来修改资源的调用。 例如，创建 VM、重启 VM 以及将虚拟网络更新成新子网等操作均可管理正在运行的资源。 它们并不直接影响到 VM 的连接。
2. "数据平面"（应用程序）:描述应用程序本身的运行时，并涉及与不通过 Azure API 的实例的交互。 例如，访问网站或从运行中的 SQL Server 实例或 MongoDB 服务器拉取数据属于数据平面或应用程序交互。 其他示例包括：从存储帐户复制 Blob，以及访问公共 IP 地址，以便使用远程桌面协议 (RDP) 或安全外壳 (SSH) 连接到虚拟机。 这些操作可让应用程序继续跨计算、网络和存储运行经典部署模型和资源管理器堆栈之间的数据平面是相同的。 区别在于，在迁移过程中，Microsoft 会将资源的表示方式从经典部署模型转换为资源管理器堆栈中的相应模型。 因此，需在资源管理器堆栈中使用新的工具、API 和 SDK 来管理资源，帮助用户平滑的过渡到ARM模式下的管理。

   其次我们需要确认哪些资源可以迁移，哪些资源不可以迁移(一定要注意)。

   （一）支持的ASM IAAS资源

• 虚拟机
• 可用性集
• 云服务
• 存储帐户
• 虚拟网络
• VPN 网关
• 快速路由网关 （仅限在虚拟网络所在的同一订阅中）
• 网络安全组
• 路由表
• 保留 IP

  （二）支持的迁移范围

• 迁移（不在虚拟网络中的）虚拟机
• 迁移（虚拟网络中的）虚拟机
• 存储帐户迁移
• 未附加的资源（网络安全组、路由表和保留 IP）

1. 迁移（不在虚拟网络中的）虚拟机

   在 Resource Manager 部署模型中，默认情况下会针对应用程序强制实施安全性。 在 Resource Manager 模型中，所有 VM 都必须位于虚拟网络内。 Azure 平台会在迁移过程中重新启动（Stop、Deallocate、Start）VM。 对于虚拟机将迁移到的虚拟网络，有两个选项：

2. 可以请求平台创建新的虚拟网络，并将虚拟机迁移到新的虚拟网络。
3. 可以将虚拟机迁移到 Resource Manager 中的现有虚拟网络。

   备注：在此迁移范围内，迁移期间可能有一段时间不允许进行管理平面操作和数据平面操作。

    

4. 迁移（虚拟网络中的）虚拟机

   对于大多数 VM 配置来说，在经典部署模型和 Resource Manager 部署模型之间迁移的只有元数据。基础 VM 在相同硬件、相同网络上，使用相同的存储来运行。在迁移过程中，可能有一段时间不允许进行管理平面操作。不过，数据平面可继续运行。也就是说，在 VM（经典）之上运行的应用程序不会在迁移期间造成停机。

   目前不支持以下配置，如果在将来添加支持，可能会造成这一配置中的某些 VM 停机（经历停止、解除分配和重新启动 VM 等操作）。

• 在单个云服务中有一个以上的可用性集。
• 在单个云服务中有一个或多个可用性集和不在可用性集中的 VM。

  备注：在此迁移范围内，迁移期间可能有一段时间不允许进行管理平面操作。 上述某些配置会造成数据平面停机。

   

1. 存储帐户迁移

   为了让迁移顺畅进行，可以在经典存储帐户中部署 Resource Manager VM。 通过此功能，就可以并且应该迁移计算和网络资源，而不必受到存储帐户的约束。 迁移虚拟机和虚拟网络后，需要迁移存储帐户才能完成迁移过程。

   备注：

   Resource Manager 部署模型没有经典映像和磁盘的概念。 迁移存储帐户时，经典映像和磁盘不在 Resource Manager 堆栈中可见，但后备 VHD 保留在存储帐户中。

    

2. 未附加的资源（网络安全组、路由表和保留 IP）

   未附加到任何虚拟机和虚拟网络的网络安全组、路由表和保留 IP 可以单独迁移。

    

   （三）不支持的功能和配置

   目前不支持某些功能和配置，下表介绍了我们对这些功能和配置的相关建议。

3. 不支持的功能

   目前不支持以下功能，你可以选择删除这些设置、迁移 VM，然后在 Resource Manager 部署模型中重新启用这些设置。

   资源提供程序	功能	建议
   计算	不关联的虚拟机磁盘。	迁移存储帐户时，将迁移这些磁盘后面的 VHD blob
   计算	虚拟机映像。	迁移存储帐户时，将迁移这些磁盘后面的 VHD blob
   网络	终结点 ACL。	删除终结点 ACL 并重试迁移。
   网络	使用 ExpressRoute 网关和 VPN 网关的虚拟网络	开始迁移之前请删除 VPN 网关，然后在迁移完成后重新创建 VPN 网关。
   网络	应用程序网关	开始迁移之前请删除应用程序网关，然后在迁移完成后重新创建应用程序网关。
   网络	使用 VNet 对等互连的虚拟网络。	将虚拟网络迁移到 Resource Manager，然后对等互连。

    

4. 不支持的配置

   目前不支持以下配置。

   服务	配置	建议
   资源管理器	经典资源的基于角色的访问控制 (RBAC)	由于资源的 URI 在迁移后会进行修改，因此建议用户规划需要在迁移后进行的 RBAC 策略更新。
   计算	与 VM 关联的多个子网	将子网配置更新为只引用子网。
   计算	属于虚拟网络，但未分配显式子网的虚拟机	可以选择性地删除 VM。
   计算	具有警报、自动缩放策略的虚拟机	迁移进行下去时，这些设置会删除。 强烈建议用户在进行迁移之前先评估其环境。 或者，也可以在迁移完成之后重新配置警报设置。
   计算	XML VM 扩展（BGInfo 1.*、Visual Studio 调试器、Web 部署和远程调试）	此操作不受支持。 建议用户在继续迁移之前从虚拟机中删除这些扩展，否则系统会在迁移过程中自动删除它们。
   计算	使用高级存储启动诊断	在继续执行迁移之前，为 VM 禁用启动诊断功能。 在迁移完成之后，可以在 Resource Manager 堆栈中重新启用启动诊断。 此外，应删除正用于屏幕截图和串行日志的 blob，以便不会再为这些 blob 向你收费。
   计算	包含 Web 角色/辅助角色的云服务	目前不支持。
   网络	包含虚拟机和 Web 角色/辅助角色的虚拟网络	目前不支持。
   Azure App Service	包含应用服务环境的虚拟网络	目前不支持。
   Azure HDInsight	包含 HDInsight 服务的虚拟网络	目前不支持。
   Microsoft Dynamics Lifecycle Services	包含由 Dynamics Lifecycle Services 管理的虚拟机的虚拟网络	目前不支持。
   Azure AD 域服务	包含 Azure AD 域服务的虚拟网络	目前不支持。
   Azure RemoteApp	包含 Azure RemoteApp 部署的虚拟网络	目前不支持。
   Azure API 管理	包含 Azure API 管理部署的虚拟网络	目前不支持。 若要迁移 IaaS VNET，请更改 API 管理部署的 VNET（该部署不会造成停机）。
   计算	Azure 安全中心扩展，其中包含的 VNET 在本地 DNS 服务器上设有支持传输连接的 VPN 网关或 ExpressRoute 网关	Azure 安全中心在虚拟机上自动安装扩展，用于监视其安全性并引发警报。 如果在订阅上启用了 Azure 安全中心策略，通常会自动安装这些扩展。

    

   四、迁移计划制定

   根据用户的业务情况制定最佳的迁移计划，包括但不限于如下考虑：

5. 迁移包括哪些应用程序，分门别类用表格记录
6. 评估资源是否可以被迁移，若不可以迁移，是否有相应的解决方案
7. 迁移是否有宕机时间，客户是否可以接受
8. 迁移时间预估并在LAB环境中演练
9. 迁移文档
10. 按照迁移文档正式迁移
11. 迁移后的应用测试列表

     

    五、LAB环境测试

    在LAB环境中尽可能模拟用户的正式生产环境，反复迁移测试。可以使用社区贡献的工具ASMMetadataParser（https://github.com/Azure/classic-iaas-resourcemanager-migration/tree/master/AsmToArmMigrationApiToolset）原样复制用户的ASM生产环境，但是也并不是所有功能都会被复制到测试环境。

    注意：测试环境中也许20-40分钟就可以完成迁移测试，但是这不完全代表客户的真实环境也会在短时间内被迁移，同时也需要考虑迁移后的完整性测试，真实的迁移时间远远大于你在实验室测试的时间。

    六、迁移

    正式迁移按照迁移文档的步骤按部就班，这里我以一个真实的迁移场景为例。

    客户的场景:N台VM，N个Vnet, N个可用性组， 1个ER，每台虚拟机都启用了Azure Backup及ACL控制。

    首先，我们先要移除无法迁移的资源，请参考迁移准备部分。

    在这个场景中我们需要移除Azure backup针对Azure VM的备份，同时记录VM的ACL控制列表，删除ACL控制，方便后续在ARM下启用NSG

    其次复制迁移文档里的Powershell,如下(请使用F8选择相应的命令行运行，这样交互式运行方便查看是否有错误，若有错误可以及时纠正，这可是用户的生产环境，一定要注意)：

    #Powershell订阅登陆

    $subscriptionname="订阅名称"

    Add-AzureAccount -Environment azurechinacloud

    Select-AzureSubscription -SubscriptionName $subscriptionname

    Login-AzureRmAccount -EnvironmentName AzureChinaCloud

    Get-AzureRMSubscription | Sort SubscriptionName | Select SubscriptionName

    Select-AzureRmSubscription -SubscriptionName $subscriptionname

    Select-AzureRmSubscription -SubscriptionName $subscriptionname

     

    

     

    #注册Azure资源

    Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

    Get-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

     

    

     

    执行完这个命令后需要等待3分钟左右，3分钟后再执行查看命令是否显示注册成功，如下图：

    

     

    确认Registrationstate为Registered后就可以进行下一步了。

     

    这一步是迁移用户的ER专线到ARM模式，若下段Powershell执行没有任何问题，一气呵成，ER只会产生一次秒断，对于业务的影响很小。

     

    #ER线路迁移至RM模式同时添加经典门户访问ER的权限

    Import-Module ‘C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1‘

    Import-Module ‘C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\ExpressRoute\ExpressRoute.psd1‘

    Get-AzureDedicatedCircuit

    New-AzureRmResourceGroup -Name "ER资源组" -Location "chinanorth"

    Move-AzureRmExpressRouteCircuit -Name "ER名称" -ResourceGroupName "ER资源组" -Location "chinanorth" -ServiceKey "ER密钥"

    $ckt = Get-AzureRmExpressRouteCircuit -Name "ER名称" -ResourceGroupName "ER资源组"

    $ckt.AllowClassicOperations = $true

    Set-AzureRmExpressRouteCircuit -ExpressRouteCircuit $ckt

    get-azurededicatedcircuit

     

    

     

    

     

    到目前为止ER已经转到ARM模式下了，同时ASM的VM还可以继续正常访问ER线路，不会造成业务的中断。

    迁移生产环境的Vnet时会发生各种各样的问题，这时需要我们耐心去解决。

    #迁移经典门户的Vnet及VM

    $vnetname="虚拟网络名称"

    $err=Move-AzureVirtualNetwork -Validate $vnetname

     

    这个Powershell命令是检查是否可以迁移的，在生产环境中，客户的环境是多种多样的，我们初次运行此命令时，大部分可能是如下失败的状态，意味着必须先解决问题才能继续迁移：

     

    

     

    此时使用$err.validationmessages并导出至txt文件分析错误信息

     

    

     

    打开TXT后会发现一些错误，比如：

     

    

    

     

    等所有的Error都解决后，再重新RUN下此命令，直到出现Validation passed。如何解决对应的问题请参考附录。

     

    正常的状态如下：

    

     

    有些VM有warnings，这个没太大关系，主要是有一些VM扩展无法迁移至ARM模式，在迁移的时候会跳过扩展，比如BGinfo1

    

     

    一切正常后就直接执行Vnet迁移

     

    Move-AzureVirtualNetwork -Prepare $vnetName

    Move-AzureVirtualNetwork -Commit $vnetName

     

    

     

     

    #Move-AzureVirtualNetwork -Abort $vnetName

     

    #迁移存储，为了确保迁移成功，不使用循环，迁移一个存储查看一次状态

    $storageAccountName = "0wp"

    Move-AzureStorageAccount -Validate -StorageAccountName $storageAccountName

    Move-AzureStorageAccount -Prepare -StorageAccountName $storageAccountName

    #Move-AzureStorageAccount -Abort -StorageAccountName $storageAccountName

    Move-AzureStorageAccount -Commit -StorageAccountName $storageAccountName

     

    

     

    存储迁移的时间相对来说会比较长一些，根据存储的存储容量，一般来说大概5分钟左右。

    按照上面迁移vnet,存储的方法迁移其它资源就可以了，直至迁移完所有资源。

     

    七、迁移后的完整测试

    迁移后主要分两部分测试，一部分是Azure的资源测试，比如监控数据，虚拟机服务等是否正常；另一部分是用户的业务应用测试，这部分需要花费比较长的时间协助客户测试，有可能因为NSG的设置导致某些端口未开放等等。

     

    八、附录—常见问题索引

     

    错误字符串	缓解措施
    内部服务器错误	在某些情况下，这是重试时会消失的暂时性错误。 如果该错误仍然存在，请联系 Azure 支持人员，因为它需要调查平台日志。
    注意：支持团队跟踪事件后，请不要尝试任何自我缓解措施，因为这可能会对环境造成意想不到的后果。
    HostedService {hosted-service-name} 中的部署 {deployment-name} 不支持迁移，因为它是 PaaS 部署（Web/辅助角色）。	当部署包含 Web/辅助角色时，会发生这种情况。 由于只有虚拟机才支持迁移，请从部署中删除 Web/辅助角色，并重试迁移。
    模板 {template-name} 部署失败。 CorrelationId={guid}	在迁移服务的后端，我们将使用 Azure Resource Manager 模板在 Azure Resource Manager 堆栈中创建资源。 由于模板是幂等的，通常可以安全地重试迁移操作，以通过此错误。 如果此错误仍然存在，请联系 Azure 支持人员，并向他们提供 CorrelationId。
    注意：支持团队跟踪事件后，请不要尝试任何自我缓解措施，因为这可能会对环境造成意想不到的后果。
    虚拟网络 {virtual-network-name} 不存在。	如果在新的 Azure 门户中创建虚拟网络，则可能会发生这种情况。 实际的虚拟网络名称遵循模式"Group * "
    托管服务 {hosted-service-name} 中的 VM {vm-name} 包含 Azure Resource Manager 不支持的扩展 {extension-name}。 建议从 VM 中卸载该扩展，再继续迁移。	Azure Resource Manager 不支持 XML 扩展，如 BGInfo 1.*。 因此，无法迁移这些扩展。 如果将这些扩展保留安装在虚拟机上，则在完成迁移之前会自动将其卸载。
    HostedService {hosted-service-name} 中的 VM {vm-name} 包含当前不支持进行迁移的扩展 VMSnapshot/VMSnapshotLinux。 请从 VM 中卸载它，在迁移完成后再使用 Azure Resource Manager 重新添加它	这是为 Azure 备份配置虚拟机的方案。 由于这是当前不支持的方案，请按照 https://aka.ms/vmbackupmigration 中的解决方法进行操作
    托管服务 {hosted-service-name} 中的 VM {vm-name} 包含未从 VM 报告其状态的扩展 {extension-name}。 因此，此 VM 无法迁移。 确保从此 VM 报告该扩展状态或者将该扩展从此 VM 中卸载，并重试迁移。 托管服务 {hosted-service-name} 中的 VM {vm-name} 包含报告处理程序状态: {handler-status} 的扩展 {extension-name}。 因此，此 VM 无法迁移。 确保所报告的扩展处理程序状态为 {handler-status} 或将该扩展从 VM 中卸载，并重试迁移。 托管服务 {hosted-service-name} 中 VM {vm-name} 的 VM 代理正在将总体代理状态报告为"未就绪"。 因此，该 VM 无法迁移（如果它有可迁移的扩展）。 请确保 VM 代理将总体代理状态报告为"就绪"。 请参阅 https://aka.ms/classiciaasmigrationfaqs。	Azure 来宾代理和 VM 扩展需要对 VM 存储帐户进行出站 Internet 访问以填充其状态。 状态失败的常见原因包括 ? 阻止出站访问 Internet 的网络安全组 ? 如果 VNET 有本地 DNS 服务器并且 DNS 连接已丢失 如果仍然看到不支持的状态，则可以卸载该扩展以跳过此检查并继续进行迁移。
    托管服务 {hosted-service-name} 中的部署 {deployment-name} 不支持迁移，因为它具有多个可用性集。	目前，只有具有 1 个或更少可用性集的托管服务可以进行迁移。 要解决此问题，请将额外的可用性集及这些可用性集中的虚拟机移到其他托管服务。
    托管服务 {hosted-service-name} 中的部署 {deployment-name} 不支持迁移，因为它的 VM 不属于可用性集，即使托管服务包含一个可用性集。	这种情况的解决方法是将所有虚拟机都移到单个可用性集中，或者从托管服务的可用性集中删除所有虚拟机。
    存储帐户/托管服务/虚拟网络 {virtual-network-name} 正处于迁移过程中，因此不能更改	对资源的"准备"迁移操作已完成并触发了对资源的更改操作时，会发生此错误。 由于在"准备"操作完成后锁定了管理平面，因此将阻止对资源的任何更改。 若要解锁管理平面，可以运行"提交"迁移操作以完成迁移，或者"中止"迁移操作以回退"准备"操作。
    托管服务 {hosted-service-name} 不允许迁移，因为它的 VM {vm-name} 处于状态: RoleStateUnknown。 仅当 VM 处于以下状态之一时允许迁移 -"正在运行"、"已停止"、"已停止解除分配"。	该 VM 可能正在进行状态转换，这通常在对托管服务进行更新操作（例如，重新启动、安装扩展等）期间发生。建议等到对托管服务的更新操作完成后，再尝试迁移。
    HostedService {hosted-service-name} 中的部署 {deployment-name} 包含具有数据磁盘 {data-disk-name} 的 VM {vm-name}，该数据磁盘的物理 Blob 大小 {size-of-the-vhd-blob-backing-the-data-disk} 字节数不匹配 VM 数据磁盘逻辑大小 {size-of-the-data-disk-specified-in-the-vm-api} 字节数。 迁移将继续，而无需指定 Azure Resource Manager VM 的数据磁盘的大小。	如果已调整 VHD Blob 的大小，而没有更新 VM API 模型中的大小，将发生此错误。 详细的缓解措施步骤如下所述。
    在云服务 {云服务名称} 中使用媒体链接 {数据磁盘 URI} 为 VM {VM 名称} 验证数据磁盘 {数据磁盘名称} 时发生存储异常。 请确保该虚拟机可以访问 VHD 媒体链接	如果 VM 的磁盘已被删除或不再可访问，则可能发生此错误。 请确保 VM 磁盘存在。
    HostedService {cloud-service-name} 中的 VM {vm-name} 包含具有 blob 名称为 {vhd-blob-name} 的 MediaLink {vhd-uri} 的磁盘，这在 Azure Resource Manager 中不受支持。	当 Blob 的名称包含"/"（这当前在计算资源提供程序中不支持）时，将出现此错误。
    HostedService {cloud-service-name} 中的部署 {deployment-name} 不允许迁移，因为不在区域范围内。 请参阅 http://aka.ms/regionalscope，了解如何将该部署移至区域范围。	在 2014 年，Azure 宣布：网络资源将从群集级别范围移至区域范围。 请参阅 [http://aka.ms/regionalscope]，了解更多详细信息 (http://aka.ms/regionalscope). 当要迁移的部署尚未进行更新操作（自动将其移至区域范围）时，会发生此错误。 最好的解决办法是向 VM 添加终结点，或者向 VM 添加数据磁盘，并重试迁移。 请参阅如何在 Azure 中的经典 Windows 虚拟机上设置终结点或将数据磁盘附加到使用经典部署模型创建的 Windows 虚拟机

     

     

     

Azure从经典模式迁移至资源管理模式实战经验分享

标签：设置   ges   项目   请求   sub   完整性   关联   reac   创建虚拟机   

原文地址：http://www.cnblogs.com/magictwt/p/7823496.html