向Azure迁移之Hyper-V篇
第二章 Hyper-V向Azure迁移
上一章,我主要讲解了如何通过无代理服务器从Vmware迁移到Azure。这一章我详细讲解一下如何从Hyper-V向Azure迁移。因为通过Azure Migrate迁移,上面一章已经讲解的很清楚了,大部分内容都是通用的。所以这一次,我选择使用Site Recovery功能来进行迁移。本次迁移的HyperV服务器的部分,和利用Azure Migrate迁移是通用的,主要区别是在Azure部分的操作,大家正好可以进行比较。
首先是进入Recovery Service保管库,创建自己的Vault
这里,选择自己的订阅,资源组,设置保管库的名字,比如这里我用iteablue-migrate,最后选择区域
下一步,确定创建的设置内容,这里注意一下,默认是利用GRS冗余,至于什么是GRS,可以参考挨踢茶馆的AZ-103视频教程,学习一下具体内容。
确认之后,就可以开始部署了,Azure会显示部署的具体过程。
部署完成以后,可以进入创建好的保管库查看
这里,我们选择Site Recovery
然后选择右边的:准备基础结构,下面要配置保护目标的具体内容,这里选择本地,要复制到Azure,需要迁移,然后系统会推荐利用Azure Migrate来进行迁移,我们这里选择坚持用Site Recovery。
然后选择虚化类型,选择HyperV,由于我没有使用SCVMM,所以这里选择否,如果大家在生产环境中有用SCVMM,则选择是
下面要选择部署规划,这里提供了一个工具,叫Deployment Planner来对你的虚拟环境进行评估。如果你需要对大型环境进行迁移的话,建议下载下来,安装到虚拟环境的某一台管理服务器来进行评估,具体内容由于篇幅的原因就不多叙述。我这里选择我将稍后进行。
下一步,由于我们的HyperV环境还没有和Azure通讯,所以这选择添加HyperV站点,并填入站点名称
创建好站点以后,需要添加Hyper-V服务器
我们需要在Hyper-V服务器下载步骤3里面的安装程序和步骤4里面的密钥,我在这里演示一下Win2019服务器作为HyperV服务器的情况,如果大家用的是Hyper-V Server话,因为是全CLI界面,会麻烦很多,由于篇幅有限,我在这里不做过多叙述,有兴趣的朋友可以关注我以后专门的Hyper-V server迁移的文章。
以管理员身份运行步骤3下载的应用程序,这里我们可以根据实际情况来确定是否需要检查更新,一般来说最好是安装一下,这里测试用,就不安装了。
选择安装的位置,然后点击安装
安装好以后,点击注册
这里需要选取刚才步骤4下载好的密钥文件,然后系统会自动识别出订阅,保管库和hyperV站点名称,点击下一步
这里选择不使用代理,如果你的生产环境有代理,则需要配置代理信息
然后系统会自动和Azure联系并注册
注册好以后,我们在hyperV这一端的工作就告一段落,回到Azure Portal这里来,重新开始一下刚才的步骤1-3,可以看到这里已经识别出了添加好的Hyper-V服务器
下一步,选择订阅,部署模型(缺省是资源管理器,也不需要管其他的,新的服务都是基于资源管理器的,不理解的同学可以看一下茶馆的Az-103的视频教程),选择自己存放复制磁盘的存储账户,最后选择一个虚拟网络。
最后一步,创建和关联复制的策略,迁移其实是先复制,再利用复制好的备份磁盘和Azure的计算能力来创建一个虚拟机
创建好复制策略以后,就点击关联,系统会自动完成剩下的工作。
等看到这个界面以后,我们的基础结构的准备所需要的配置就完成了。
完成以后,我们回到Site Recovery界面,选择步骤1: 复制应用程序
第一步和刚才类似,照搬设置就行
第二步,设置目标,里面选择好订阅,资源组,部署模型,存储账户,虚拟网络和子网信息
第三步,选择需要复制的虚拟机,我们在hyperV平台刚好有4个虚拟机,这里直接全部选取。
下一步,配置虚拟机的类型和磁盘
最后,选择合适的复制策略,这是我们刚才创建好并关联的,如果你有多个复制策略,要选择适合的,至于什么是复制策略,请参考茶馆的AZ-103视频教程。
这里步骤1就全部完成了,我们可以看到通知里面显示正在启动保护
点击一个进去以后查看,具体信息如下
如果我们回到保管库,选择复制的项,则可以看到所有虚拟机的复制情况,现在是正在启用,过一会就开始了复制,并且有同步的百分比提供参考,请注意,这里会根据网络的速度和硬盘的大小来决定同步的时间,机器越多,硬盘越大,则复制的时间越长,这里的百分比就和windows提供的copy预估时间一样,非常不准确~~~
我们也可以点击单个虚拟机进去查看同步状态。在这里,我们可以看到底下有一个基础结构视图,这是Azure migrate所没有的。这个视图直观的告诉大家,Hyper-V和Azure的同步是通过Site Recovery来管理磁盘复制,这其实是一个HA高可用性的体现,Hyper-V环境可以作为Azure的DR灾难恢复的一个端点。
复制好以后的状态描述让人真的很无语,就不能找个中国人翻译么。。。
我们点击centos进去看一下,上面3个选项都已经可以使用了,类似于Azure migrate里面的测试,只是因为是Hyper-V,所以可以像我上面提到的那样,用来做故障转移。
这里我测试一下故障转移,点击进去看到可以选择恢复点和一个虚拟网络,请注意,这里的虚拟网络最好是和生产网络不同的网络,仅供测试使用。
确定以后,我们可以看到状态变成了:正在启动测试故障切换
点击状态进去查看,原来也是启动一个测试虚拟机
我们到虚拟机项目下查看,一个测试虚拟机已经创建好了
测试完以后,我们可以回到刚才的界面,选择清理测试故障转移,千万别自己手贱删除测试虚拟机,有的时候会导致这里卡住。
同样的,要给一个理由,我就直接跳过了。不过,生产环境中最好给一个理由,方便回溯。
确认无误以后,我们就可以选择故障转移了。类似于Azure Migrate,这里也建议关闭虚拟机以获得所有数据,我这里测试用就不在乎了。生产环节中请根据实际情况来决定,最好能选择在非工作时间关闭虚拟机,然后执行故障转移,不然一定会或多或少丢失一些数据。
启动故障转移以后,状态变了,下面的基础结构视图也变了,因为执行了故障转移,这就不再是Hyper-V和Azure的复制了,Azure已经不再是一个灾难备份,而是完全在Azure这边创建新的虚拟机了。
我们可以去虚拟机选项查看,可以看到一个完整的VM已经创建好了。
复制的项中的提示也变了
点击centos进去查看,状态已经变成了:故障转移已完成。
一般来说,如果你想继续保持Hyper-V和Azure的互相灾备的状态的话,可以就这样结束了,因为即便故障转移以后,Azure端的虚拟机和Hyper-V端的虚拟机还会继续相互复制。如果你不想再用Hyper-V端的虚拟机的话,可以在菜单里选择:完成迁移
完成迁移的意思是,Azure端的虚拟机将完全独立出来,不再和Hyper-V端有复制行为,是一个完全独立的个体了。这适合只保留Azure端,并且需要淘汰Hyper-V服务器的情况。
选择完成迁移以后,我们可以看到,Azure在两个位置上都禁止了复制,停止了两个虚拟机的所有联系。
我们在复制的项中也看不到完成迁移的Centos虚拟机了,它彻彻底底的变成了Azure虚拟机。
这样,整个迁移的过程就彻底完成了。其他的服务器都可以按照这个方式实现从Hyper-V迁移到Azure。这里我插一句,如果是用Site Recovery迁移Vmware虚拟机的话,基础结构视图会有所不同,也无法实现HA和DR等高级功能,这里大家要注意一下。毕竟Azure虚拟的本质就是基于Hyper-V,所以对Hyper-V有天然的亲和力。
总之,在迁移的过程中,如果发生问题,可以查看通知,里面会给出详细的解释并提供解决参考方案。解决以后,重试复制就可以了。本教程里面涉及到的各种概念,如果不熟悉的话,请参考挨踢茶馆的AZ-103培训课程,里面有详细的解析,并且全程实操,非常适合大家学习和查漏补缺。
第二章的内容就到这里,下一章,我将讲解从本地物理机复制到Azure,还有从AWS虚拟机复制到Azure的骚操作~~~~(点击查看向Azure迁移之本地物理机和AWS)
Tag:Azure
1个评论
赞一个