首页 > 代码库 > 从ASM迁移到ARM（1）：平台支持的迁移服务
从ASM迁移到ARM（1）：平台支持的迁移服务
Azure上的ARM模式为用户带来更好的管理，更多新的特性，更好的体验，因此目前正在使用经典模式（ASM）的用户，在了解和使用了ARM之后，也在考虑如何将原来基于ASM模式的虚拟机，存储，网络等IAAS服务转向ARM模式，本文就来介绍一下相关的工具和服务。
目前从ASM迁移到ARM，主要有以下一些工具和服务可以使用：
- 平台内置的迁移服务：这个服务是内置的，只需要你注册Resource Provider就可以使用。
主要的优点：
- 虚拟机无宕机时间
- 有官方支持；
主要缺点
- 迁移粒度只能通过vnet或者云服务来迁移,无法根据客户定制的方式,比如项目进行迁移
- 虚拟机和存储，网络要分开迁移，比较繁琐
- 不支持跨地区，跨订阅的迁移
- 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
- 首先我们准备一个测试的环境，一个Linux虚拟机，在一个vnet里面，它的存储账号是demovmstorage：
- 打开Powershell，登陆到你的资源管理器账号：
Login-AzureRmAccount -EnvironmentName AzureChinaCloud
- 登陆完成后，首先你要注册ClassicInfrastructureMigrate，否则后续的迁移无法使用：
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate
检查当前ClassicInfrastructureMigrate的注册状态，如果你看到状态变成了Registered，才可以进行后续的操作。
Get-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate
- 使用ASM登陆到当前的Azure账号：
Add-AzureAccount -Environment AzureChinaCloud
选择你的源订阅：
Select-AzureSubscription -SubscriptionId YOURSUBID
- 在迁移之前，你需要检查一下你的资源管理器配额，确保你有足够的资源进行迁移，如果不够的话，需要打21v 400电话扩展你的配额
Get-AzureRmVMUsage -Location "China East"
- 定义一下你要迁移的虚拟机的虚拟网络，并验证一下迁移该虚拟网络是否有任何问题：
$vnetName = "myVnet"
Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName
如果你看到如下的输出，那么就证明你的迁移验证是成功的：
- 根据我们多阶段验证的操作，你首先需要准备这个操作，然后才能提交这个操作，首先准备这个操作：
Move-AzureVirtualNetwork -Prepare -VirtualNetworkName $vnetName
- 然后正式提交这个操作，操作成功后，到经典管理的界面，检查当前虚拟机，看到已经不见了，这是因为经典的portal只能管理经典模式的虚拟机：
Move-AzureVirtualNetwork -Commit -VirtualNetworkName $vnetName
可以看到，在经典模式的管理界面中，虚拟网络和虚拟机都已经看不到了，但是存储账号还在，这就意味着虚拟机和网络已经被迁移到ARM模式，但是存储并没有没迁移：
- 登录到新的portal，在资源组页面，你可以看到系统已经自动创建了两个资源组，以原来虚拟机名称和虚拟网络，后面加上migrated而成，如果你希望所有的资源在一个资源组中，你可以手工选择移动将一个资源组中的所有资源移动到另外一个中：
- 从上述描述可以看到，存储实际上目前还是保留在经典模式，我们需要单独迁移，同样的步骤，我们可以定义存储，准备迁移，提交迁移：
$storageAccountName = "demovmstorage"
Move-AzureStorageAccount -Prepare -StorageAccountName $storageAccountName
Move-AzureStorageAccount -Validate -StorageAccountName $storageAccountName
Move-AzureStorageAccount -Commit -StorageAccountName $storageAccountName
- 上述迁移成功后，打开新的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
从ASM迁移到ARM（1）：平台支持的迁移服务