如何将已部署在ASM的资源迁移到ARM中

使用过Azure的读者都知道，Azure向客户提供了两个管理portal，一个是ASM，一个是ARM，虽然Azure官方没有宣布说淘汰ASM，两个portal可能会在很长的一段时间共存，但是考虑到ARM提供了更多的功能，只有很少部分工作才会用到powershell完成，所以笔者建议以后大家尽量使用ARM，但是对于哪些已经使用ASM作为生产环境的用户想迁移到ARM中，应该怎么办，今天笔者就像大家介绍一下如何将云资源从ASM迁移到ARM中！！！

首先介绍一下现在迁移可以使用的一些服务与工具

1.平台内置的迁移服务，只需要你注册resource provider就可以使用

特点:虚拟机迁移过程中不会宕机

有官方提供支持与保证

迁移颗粒度不能定制化，不能选择某个应用，系统，或者项目来迁移，只能以云服务或者虚拟网络为单位来迁移

迁移过程中，VM和Vnet以及存储账号只能逐个迁移，而不整体迁移

迁移不能跨数据中心，同时只能在同一个订阅下迁移

2.ASMtoARM项目：支持单个虚拟机移植的powershell脚本，可以在官网地址下载

特点：可以自动生成powershell脚本与ARM模板

可以灵活的*组合，支持网络，NSG等

不能一次迁移多个虚拟机迁移

迁移过程较长

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

无官方支持与保证

3.MigAZ,该迁移工具由微软的服务部门开发，官网下载地址

特点：可以在不同的订阅之间迁移

客户可以*选择需要迁移的资源

自动化迁移存储的工具

允许不同地区之间的迁移

有宕机时间

无官方支持与保证

从以上的的比较可以看出，每种迁移方式的特点是不一样的，读者可以根据自身的需要来进行选择，本次博文中笔者重点介绍方法一，后续会介绍方法三

在这里，笔者觉得有必要提醒大家一句，在这里笔者只是在迁移简单的测试环境，笔者只是展示方法论，对于正式的生产环境，大家在迁移的时候一定要非常慎重，最好先做好如下的准备工作

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

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

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

提交——提交迁移请求，正式迁移

第一步，在ASM中建立虚拟机，存储账号，虚拟网络，云服务，过程省略，结果如下

云服务

存储账号

虚拟网络

虚拟机

第二步，使用powershell，登陆到ARM账号

PS C:\Users\羊羊> Login-AzureRmAccount -EnvironmentName AzureChinaCloud

输入账号密码，完成登陆

注册ClassicInfrastructureMigrate，否则后续的迁移无法使用

PS C:\Users\羊羊> Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

注册时间会有一分钟左右，注册完成以后输入如下命令观察注册结果

PS C:\Users\羊羊> Get-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

使用ASM登陆到当前账号

PS C:\Users\羊羊> Add-AzureAccount -Environment AzureChinaCloud

输入账号与密码，完成登陆

选择你的源订阅

PS C:\Users\羊羊> Select-AzureSubscription -SubscriptionId xxxxxxxx

迁移之前，检查你的资源管理器配额，需要确保你有足够的资源可以迁移

PS C:\Users\羊羊> Get-AzureRmVMUsage -Location "China East"

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

PS C:\Users\羊羊> $vnetName = "asmvnet"

PS C:\Users\羊羊> Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName

看到如下结果表示成功

根据我们多阶段验证的操作，也就是说每一个操作必须先验证，再进行操作

PS C:\Users\羊羊> Move-AzureVirtualNetwork -Prepare -VirtualNetworkName $vnetName

看到如下结果表示成功

接下来可以提交正式操作了

PS C:\Users\羊羊> Move-AzureVirtualNetwork -Commit -VirtualNetworkName $vnetName

看到如下结果表示成功

现在我们回到ASM portal中观察结果，大家会发现一个奇怪的事情，就是虚拟网络没有了，但是存储账号还在

可以看到一开始创建的ASMVM已经没有了

一开始创建的asmvnet也没有了

其实云服务也没有了

这是因为虚拟机与虚拟网络已经被迁移到ARM里面了，所以在ASM中就看不到了，但是存储还在

接下来，我们登陆到ARM portal里面，发现多了两个资源组，并且以原来的虚拟机名称与虚拟网络名称后面加上migrated而成，如果你希望所有的资源在一个资源组，你可以手动选择移动将一个资源组中的资源移到另一个资源组中

我们发现原本在ASM中的资源都被迁移到ARM中了

对于存储，我们需要单独迁移，步骤都一样，定义存储，准备迁移，提交迁移

PS C:\Users\羊羊> $storageAccountName = "asmstorage"
PS C:\Users\羊羊> Move-AzureStorageAccount -Prepare -StorageAccountName $storageAccountName
PS C:\Users\羊羊> Move-AzureStorageAccount -Validate -StorageAccountName $storageAccountName
PS C:\Users\羊羊> Move-AzureStorageAccount -Commit -StorageAccountName $storageAccountName

结果如下

回到ASM portal中观察结果，会发现一开始建立的asmstorage存储也看不到了

回到ARM portal里观察结果，发现多了一个资源组，同样你也可以将其手动移动到刚刚的那个资源组里面。

最终结果如下

根据此次poc的过程，我们可以看出，使用平台内置的迁移服务，有如下几个特点

可以便捷地迁移IaaS资源

迁移过程系统是不会被中断

可以通过迁移虚拟网络从而迁移该虚拟网络中的虚拟机

存储需要单独迁移

如有需要，可以把多个资源组合并为一个

但是在这里笔者想提醒大家一句，并非所有的IaaS资源都可以迁移，有些配置和特性暂时还不能支持，比如虚拟机的自定义镜像，启用了启动诊断的高级存储虚拟机，虚拟网络的端点访问控制，虚拟网关，Traffic Manager的配置文件，具体的迁移支持范围