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