随着企业引入OpenStack平台以后,从边缘应用需求逐步进入到准核心,甚至是核心业务的需求和趋势,私有云运营团队常常需要面对多样化的虚拟机迁移问题和需求(包括计划内和计划外)。
例如,物理服务器进行计划内的停机维护,或者根据对计算和存储更加细粒度的管理和规划,需要将计算和存储融合部署的架构,拆成分离部署架构,以便于未来业务的扩展。这些都涉及到虚拟机的迁移。
根据迁移操作对业务的影响,虚拟机的迁移一般分为两类:
1、冷迁移(Cold Migration / Non-live Migration)
虚拟机需要先停机,等待与此虚拟机相关的计算和存储等资源迁移完成后,再重新启动。在迁移期间,业务无法访问,只有迁移完成后,业务才能恢复。由于迁移过程中涉及到存储数据的拷贝,如果数据量比较大,会造成停机时间过长且不可控,因此冷迁移仅适用于对系统可用性要求不高的业务。
2、热迁移(Live Migration)
虚拟机在迁移过程中保持运行状态,业务可正常访问,根据虚拟机的存储类型又可分为:基于共享存储的热迁移、块设备的热迁移和基于卷的热迁移等。 由于涉及到计算、网络和存储的一体化热迁移,对底层基础设施的要求较高。
01两种场景下的对比
我们先来对比VMware和OpenStack对虚拟机迁移的支持情况:
从上图可以看出,VMware历经了十多年的商业化发展道路,对虚拟机迁移的支持更为全面,支持计算和存储的热迁移,甚至是跨集群迁移,这通常对于目标规划两地三中心业务高可用的用户来讲非常重要,但这些功能仅限于VMware场景使用,也就意味着在满足业务高可用需求的同时,选择了相对比较单一的私有云模型,给用户在供应商平台选择上带来局限性;
相比之下,OpenStack对虚拟机迁移功能的支持则不够完善,对于存储迁移,由于OpenStack本身开放的架构,需要依赖存储厂商实现存储层的迁移能力。
以Ceph为例,Ceph RBD作为OpenStack主流的存储后端,默认不支持在线热迁移,RBD裸盘只能进行离线迁移,这就意味着如果进行跨集群迁移,虚拟机需要长时间停机,整体迁移进度受制于存储的迁移进度,如果存储容量较大,更会让整个迁移时间不可控。
如今,XSKY SDS逐步被很多用户引入到已有的OpenStack架构中,用于替换该私有云架构中原有的Ceph SDS集群,这些用户包括对于业务连续性要求非常高的省级,甚至是更大规模的金融平台。
为了帮助用户应对棘手的在线热迁移问题,XSKY基于自主研发的纳管卷、在线卷迁移和多集群存储等特性,设计了XMotion纳管热迁移技术,不但支持多家OpenStack厂商,提供面向虚拟机和租户的存储计算一体化迁移方案,更可将整体迁移效率提升10倍以上。
XSKY的纳管迁移方案具有以下优势:
▪ 支持存储在线热迁移,业务无需中断,可在业务正常运行中进行迁移;
▪ 不仅支持存储独立纳管迁移,也支持计算和存储一体化迁移;
▪ 以卷为单位,上层应用无感知,无兼容性问题;
▪ 支持从开源Ceph迁移到XSKY存储集群,也支持从XSKY老集群迁移到新集群;
▪ 支持跨计算和存储集群进行迁移;
▪ 无厂商锁定,支持多家OpenStack厂商;
▪ 强一致的数据完整性保证,不丢增量数据;
▪ 支持迁移QoS,可根据业务需要自定义迁移速率,并可随时撤销迁移任务;
▪ 支持以虚拟机或租户为单位,自动扫描关联的存储,一键迁移;
▪ 结合虚机业务的完善回滚方案,应对海量数据迁移过程中的各种硬件和网络异常情况。
02存储纳管迁移
下面以XSKY存储集群纳管开源Ceph为例,介绍存储纳管迁移的步骤:
1、将计算节点添加到XSKY存储集群;
2、OpenStack Nova/Cinder等服务配置存储多集群,可同时访问开源Ceph集群和XSKY存储集群;
3、在XSKY存储集群创建纳管卷,关联该纳管卷与Ceph集群中的被纳管卷;
4、OpenStack Nova/Cinder等服务配置使用纳管卷;
5、XSKY纳管卷启动在线卷迁移;
6、后台数据在线迁移完成后,XSKY纳管卷会自动合并和清理底层临时数据,完成整个迁移过程。
纳管迁移中的IO访问流程如下图所示:
在迁移过程中,由libvirt发起的虚拟机读操作将由迁移网关从开源Ceph读取,写操作则由迁移网关进行同步双写,同时写入纳管卷与被纳管卷;
迁移完成后,读写操作将都只针对新池进行。纳管迁移网关对上层屏蔽迁移细节,libvirt对整个迁移过程无感知,无需做任何修改。
03存算一体化在线迁移
XMotion除了提供存储纳管迁移以外,也支持多家OpenStack厂商之间的存储和计算一体化迁移方案,以虚拟机为单位,自动化迁移虚拟机及其存储部分。
下面我们以某省级农信社的大规模OpenStack生产集群迁移为案例,介绍XMotion的存储和计算一体化在线迁移方案。
因为历史原因,过去为了规避单一供应商的产品和服务风险,该用户在对外省级联社以及对私内部运营,规划和筹建了两套OpenStack集群,这两套集群各自独立运营,资源以及权限分离管理;
而在过去三年的逐步比较中,发现B集群服务商具有更好的产品稳定性和商业服务能力,所以本次迁移的目标是为了将OpenStack厂商A的老集群迁移到OpenStack厂商B的新集群中,同时将原XSKY存储集群迁移到新版本的两套集群中,做存储灾备,因此涉及到计算和存储两个单元的同时跨集群迁移需求。
OpenStack原集群为计算和存储分离部署架构,其中,计算节点49台(46台为纯计算节点,3台计算与控制节点融合部署),共2886台虚拟机;存储节点107台,采用3副本,裸容量4.38PB,有效容量1.46PB,已使用1PB,共5625个卷。
集群迁移前后的架构如下图所示:
以单个虚拟机为例,XSKY的存算一体化迁移方案步骤如下:
1、初始化
▪ OpenStack厂商创建迁移用的虚拟机,进行网络和计算资源初始化等工作
▪ OpenStack配置多集群
2、XMotion执行存储和计算的自动一体化迁移
▪ 创建纳管卷
▪ 迁移虚拟机
▪ 纳管卷重命名
▪ 启动迁移任务
本次迁移属于计划内升级迁移,因此允许对虚拟机业务停机,迁移耗时不超过3分钟,主要集中于虚拟机跨计算集群的重建和启动阶段,得益于XMotion的纳管热迁移技术,整个迁移过程不受存储容量的限制,新虚拟机启动后挂载纳管卷即可对外提供服务,由XSKY的迁移网关在后台执行数据热迁移,业务在存储迁移过程中不受迁移进度影响,可正常访问。
迁移完成后,在OpenStack控制面板可观察到新虚拟机已正常运行:
而在XSKY存储控制面板则可观察到存储卷为在线迁移状态:
XSKY支持针对在线迁移中的卷执行速率调整和取消迁移任务等操作:
▪ 调整迁移速率,支持高、中、低三档迁移速率,如果担心迁移速率过大影响正常业务,则可将迁移速率调小;
▪ 取消迁移任务,如果迁移导致业务速率降低,则可以取消迁移任务,释放带宽来满足前端业务需求,后续再重新开启迁移任务。
本次迁移实测的不同档次迁移速率如下:
XMotion迁移不仅可以支持跨OpenStack厂商和存储迁移,方便后期业务扩展,而且可以获得新版本XSKY存储集群的所有特性,迁移完成后的虚拟机性能也获得同步提升:
04更多适用场景
除了以上提到的场景外,XMotion纳管热迁移技术还可灵活应用于多种业务场景。
1、迁移开源Ceph或老版本XSKY存储
迁移需求:
▪ 开源Ceph运维难度大, 将开源Ceph迁移到XSKY存储上,获得专业和易用的企业级存储能力;
▪ 部署了新版本XSKY存储集群,希望将老集群迁移到新集群,释放老集群资源。
方案优势:
▪ 保留OpenStack计算集群,迁移底层Ceph或XSKY老集群到XSKY新集群;
▪ 以虚拟机和租户为单位,面向业务迁移;
▪ 在线迁移,业务无感知;
▪ 自动化迁移,运维成本低。
2、跨集群迁移计算和存储集群
迁移需求:
▪ 计算集群升级;
▪ 存算分离;
▪ 跨集群迁移虚拟机;
▪ OpenStack集群跨地域迁移;
▪ 不同OpenStack厂商集群切换;
▪ 要求迁移时间可控,迁移过程业务不中断。
方案优势:
▪ 计算和存储同时迁移;
▪ 支持跨计算集群和跨存储集群迁移;
▪ 迁移时间可控,不受存储容量限制;
▪ 多OpenStack厂商支持;
▪ 自动化迁移,运维成本低。
05小结
OpenStack进入我们的视线已经有很多年了,开源且具有开放性的OpenStack平台对于许多植根互联网基因的企业来说具有强大的吸引力,但由于产品化程度不足,运维和开发投入的人力和资金往往不可忽视。
而最终在很多需要跨集群满足业务连续性的场景,无法攻城略地的原因,则来自于OpenStack场景下,天然短板的热迁移(Live-Migration)能力。XSKY XMotion纳管热迁移技术,让OpenStack也能够支持热迁移,极大提升虚拟机迁移效率。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
