1、迁移需求分析
Hyper-V虚拟化是微软旗下的开发的虚拟化技术,现有市场下还是有不少在使用微软大家族的产品,但是对于国内来说虽然桌面产品还没办法完全取代微软,可是在服务侧还是有望将运行生产环境转移到开源的KVM虚拟化架构运行,自主可控,符合国家要求。现在好多云底层都是使用的KVM作为云平台虚拟化技术底座,OpenStack也是全面应用了KVM虚拟化技术,所以我们看如何可以将Hyper-V虚拟化平台运行的虚拟机平滑迁移至OpenStack平台运行。
最直接的方式就是把Hyper-V运行的虚拟机vhd格式磁盘导出直接通过OpenStack导入镜像的方式迁移到OpenStack,不过这种方式一种冷迁移方式,而且还涉及到了跨虚拟化架构,中间还需要人工做复杂的驱动转换,时间没保障不说,源端虚拟机还得一直停机。个人觉得如果你是小企业,对业务上云的SLA没有要求,我觉得以人工操作慢慢迁移上云倒是没太大问题,但是对于一个有几十台、上百台的Hyper-V虚拟机,并且对业务停机时间有很严苛的要求的企业,导入镜像方式来满足迁移需求,其实并不是一种企业将Hyper-V虚拟机迁移上云的最好选择。
考虑到国内市场云平台众多,迁移需求发生频次高,如果你是一家做云服务的公司,那么掌握一个成熟的商业迁移工具是非常有必要的,工具的效率和兼容性很关键。这里我们排除传统的迁移服务公司,市场上不少宣传提供云迁移服务的公司还停留在使用大量的人力和工具做系统重新部署等工作的阶段。
2、技术选型:成熟的云迁移工具应具备什么能力?
那对于Hyper-V虚拟化上跑了大批量的虚拟机的企业应该如何选型一个合适的技术方案,而且应该具备那些能力?首先技术实现上应该具体以下几点:
- 在线迁移能力
所谓在线迁移能力,可以在数据全量、增量传输过程中,源端业务可以在线提供服务,不停服。最起码不能冷迁移吧,让源端业务停个一两天,SLA怎么保证?这个是云迁移技术选型必不可少的能力。
- 支持增量数据的传输
具备源端全量数据传输云上后,后续还可以继续增量数据的传输,来保证业务的可持续运行。
- 支持整机迁移
整体迁移也是AWS在定义迁移服务里面,所提到的Rehost迁移模式,也是6R模式里面最简单的一种迁移上云的方式,整机迁移可以保证你原有主机业务的形态,迁移上云后无需重新部署,直接启动后就可以使用,也是客户在初次上云中最常见、最简单的、风险最低的一种方式。
- 支持批量迁移
对于Hyper-V虚拟化运行了大批量的业务虚拟机,可以支持大批量并行迁移的能力,减少技术人员的人力投入,可以快速低成本的完成迁移