从ASM迁移到ARM：平台支持的迁移服务

Posted 2020-08-21

Azure上的ARM模式为用户带来更好的管理，更多新的特性，更好的体验，因此目前正在使用经典模式（ASM）的用户，在了解和使用了ARM之后，也在考虑如何将原来基于ASM模式的虚拟机，存储，网络等IAAS服务转向ARM模式，本文就来介绍一下相关的工具和服务。

目前从ASM迁移到ARM，主要有以下一些工具和服务可以使用：

1.平台内置的迁移服务：这个服务是内置的，只需要你注册Resource Provider就可以使用。

主要的优点：

• 虚拟机无宕机时间

• 有官方支持；

主要缺点

• 迁移粒度只能通过vnet或者云服务来迁移,无法根据客户定制的方式,比如项目进行迁移

• 虚拟机和存储，网络要分开迁移，比较繁琐

• 不支持跨地区，跨订阅的迁移

   

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

 

官网地址：https://github.com/fullscale180/asm2arm

主要优点：

• 自动生成ARM模板和Powershell脚本

• 灵活组合，支持网络，NSG等

主要缺点：

• 无法支持多个虚拟机迁移

• 时间较长

• 有宕机时间（脚本不会帮你关机）

• 无官方支持

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

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

主要优点：

• 可以在不同的订阅之间迁移

• 客户自由选择需要迁移的资源

• 自动化迁移存储的工具

• 允许不同地区之间迁移

主要缺点：

• 有宕机时间

• 无官方支持

可以看到，每一种迁移方式都各有优缺点，大家可以根据自己的需求选择合适的方式进行迁移；本系列会主要介绍Azure平台原生支持的迁移服务以及MigAZ工具，对于基于Powershell的ASMtoARM工具，大家感兴趣可以自己研究一下。

平台内置的迁移服务

平台内置的迁移服务，依赖于ClassicInfrastructureMigrate这个resource provider，目前在中国已经上线了，可以开始使用了。

对于生产环境的迁移，一定要非常谨慎，做好规划和评估，然后再开始迁移。微软的ASM到ARM的迁移，有一些基本的方法论，大家可以做个参考，保证你的迁移过程平滑而顺利：

• 评估 – 评估虚拟机所在虚拟网络是否满足迁移要求

• 开始 – 虚拟网络已经准备好的情况，可以开始准备迁移

• 验证 – 检查和验证所迁移的资源是否正常

• 提交 – 提交迁移请求，正式迁移

用户的环境相对而言会比较多样而复杂，比如在vnet里的虚拟机，不在vnet里的虚拟机，带有gateway的虚拟机等等，我们先来看一下如何迁移最为常见的在虚拟网络中的所有虚拟机。

迁移虚拟网络中的虚拟机到ARM

1.首先我们准备一个测试的环境，一个Linux虚拟机，在一个vnet里面，它的存储账号是demovmstorage：

2.打开Powershell，登陆到你的资源管理器账号：

Login-AzureRmAccount -EnvironmentName AzureChinaCloud

3.登陆完成后，首先你要注册ClassicInfrastructureMigrate，否则后续的迁移无法使用：

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

检查当前ClassicInfrastructureMigrate的注册状态，如果你看到状态变成了Registered，才可以进行后续的操作。

Get-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

4.使用ASM登陆到当前的Azure账号：

Add-AzureAccount -Environment AzureChinaCloud

选择你的源订阅：

Select-AzureSubscription -SubscriptionId YOURSUBID

5.在迁移之前，你需要检查一下你的资源管理器配额，确保你有足够的资源进行迁移，如果不够的话，需要打21v 400电话扩展你的配额

Get-AzureRmVMUsage -Location "China East"

6.定义一下你要迁移的虚拟机的虚拟网络，并验证一下迁移该虚拟网络是否有任何问题：

$vnetName = "myVnet"

Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName

如果你看到如下的输出，那么就证明你的迁移验证是成功的：

 

7.根据我们多阶段验证的操作，你首先需要准备这个操作，然后才能提交这个操作，首先准备这个操作：

Move-AzureVirtualNetwork -Prepare -VirtualNetworkName $vnetName

8.然后正式提交这个操作，操作成功后，到经典管理的界面，检查当前虚拟机，看到已经不见了，这是因为经典的portal只能管理经典模式的虚拟机：

Move-AzureVirtualNetwork -Commit -VirtualNetworkName $vnetName

可以看到，在经典模式的管理界面中，虚拟网络和虚拟机都已经看不到了，但是存储账号还在，这就意味着虚拟机和网络已经被迁移到ARM模式，但是存储并没有没迁移：

9.登录到新的portal，在资源组页面，你可以看到系统已经自动创建了两个资源组，以原来虚拟机名称和虚拟网络，后面加上migrated而成，如果你希望所有的资源在一个资源组中，你可以手工选择移动将一个资源组中的所有资源移动到另外一个中：

10. 从上述描述可以看到，存储实际上目前还是保留在经典模式，我们需要单独迁移，同样的步骤，我们可以定义存储，准备迁移，提交迁移：

$storageAccountName = "demovmstorage"

 

Move-AzureStorageAccount -Prepare -StorageAccountName $storageAccountName

 

Move-AzureStorageAccount -Validate -StorageAccountName $storageAccountName

 

Move-AzureStorageAccount -Commit -StorageAccountName $storageAccountName

 

11.上述迁移成功后，打开新的portal界面，检查当前新的资源组resource group，可以看到和之前一样的规则，产生了一个新的资源组demovmstorage-Migrated，如果你希望他们放在一个资源组，也可以进行移动：

从本文可以看到，使用平台原生的迁移服务，可以方便的迁移IAAS资源（虚拟机，网络，存储）：

• 迁移过程中系统无中断

• 系统自动创建资源组，切分别为虚拟网络，虚拟机和存储单独创建

• 可以通过虚拟网络迁移所有在该网络中的虚拟机

• 存储需要单独迁移

• 如果需要，需要手工把多个迁移的资源组合并为一个

但并不是所有的IAAS特性和配置都支持，有些配置和特性目前在平台支持的迁移服务中还不支持，比如：

• 虚拟机的自定义镜像

• 启用了启动诊断的高级存储虚拟机

• 虚拟网络的端点访问控制

• 虚拟网关，Traffic manager的配置文件

更多的迁移支持范围可以参考：https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-migration-classic-resource-manager