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

9AMC

　　使用过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的配置文件，具体的迁移支持范围