目录

如何在迁移过程中更换存储资源池

在一个云迁移项目中,用户希望将系统盘存储于SATA资源池,而将数据盘全部存储于SAS资源池内,由于最初没有合理的就存储资源池类型进行规划,而割接的时间点又迫在眉睫,重新同步数据不现实。最终,通过云平台侧和HyperMotion迁移工具团队的共同努力,找到了最佳方案,满足了客户需求,也为相关需求提供了最佳实践。

项目现状与需求

在某政务云项目中,HyperMotion需要将用户原有运行在物理机、Xen、VMware、KVM上的多种操作系统迁移至目标云平台中。用户多套业务系统分布在89台主机中,总磁盘数量178块,分配数据量为58TB,实际使用量为23TB。目标云平台基于OpenStack技术构建,底层存储使用Ceph,分为SATA和SAS两个不同性能的存储池。由于在前期同步时,全部的资源都同步到了SATA池中。

通过HyperMotion云端仿真环境构建能力,用户在验证业务系统过程中,发现运行在SATA资源池内的主机运行过慢,所以希望将数据盘移动至SAS资源池。但是由于原有割接计划的安排,重新同步数据显然是不可能的,所以希望在正式割接完成前,对资源池进行切换。

解决方案

经过初步讨论,大概确定了三种不同的解决方案:

方案一:启动后变更磁盘类型

这种方式是在系统启动后,将数据盘从底层由SATA资源池复制到SAS资源池,从而实现项目需求。但是这种方式有一个明显的硬伤,就是会对割接时间(RTO)造成较大的影响,跨资源池的拷贝速度无疑会耗占很长的时间,虽然这种方式是最稳妥的,但是不符合项目进度的要求。

方案二:增量同步至SAS资源池

这种方式较为复杂,整体的时序图如下图所示。核心思路是将现有正在用于同步的SATA盘,使用Ceph层面的增量方式复制到SAS资源池。在最终启动过程中,直接使用SAS资源池的完成启动。这种方式是对数据流影响最小,但是需要进行一些针对性的定制开发,例如:需要实现Ceph层面的增量同步、以及在启动过程中,让HyperMotion使用SAS资源池的数据盘等。这种方式将耗时的数据同步仍然在同步阶段完成,避免了在割接阶段对项目进度的影响。

/images/2021-12-03-11-50-08.png

方案三:直接修改卷类型

这种方式直接将目前用于数据同步的SATA卷通过底层同步至SAS资源池,而在cinder中不改变原有的卷id。这种方式对整个迁移流程影响最小,但是可能对源端已经同步的数据造成影响,所以需要非常慎重的进行前期测试。

实施过程

最终,经过云平台和HyperMotion团队的共同讨论及联合测试,最终确定采用方案三作为首选方案,而方案二则作为备选方案。

1、筛选需要切换类型的卷

首先,需要区分所有需要转换资源池的数据盘,这些信息直接可以从HyperMotion现有的资源池中获取。同时,获取这些卷所对应的云存储网关。为了数据完整性,在切换过程中,先暂停源端数据同步并关闭存储网关所在的虚拟机并进行卸载操作。

2、修改卷类型

OpenStack Cinder中提供了一个retype命令,用于修改卷类型,底层会调用存储底层命令实现卷之间的拷贝,例如:在Ceph中就是直接调用RBD相关命令完成复制工作。

/images/2021-12-03-14-53-10.png

但是在修改之前有两个前提条件:

  • 操作的对象卷不能为挂载状态,所以在上述步骤中,我们需要将卷先进行卸载
  • 操作的对象卷不能有依赖的快照资源,由于之前已经将所有的业务系统在云平台进行了演练,导致底层存在依赖链,必须要断链后才能删除快照,这里使用了rbd flatten命令进行解链操作
1
2
rbd --pool {pool-name} flatten --image {image-name}
rbd flatten {pool-name}/{image-name}

完成以上配置后,通过脚本批量的对卷类型进行修改,修改后,卷的ID信息仍然保持不变。

3、重新挂载验证

将修改后的卷,按照之前的归属关系,重新挂载回云存储网关,重新开机。此时由于卷类型已经改变,需要在HyperMotion中修改卷类型,以保证下次接口调用的正确性。完成后,继续进行增量同步,一切恢复正常。通过迁移演练功能,在云平台进行割接前构建仿真环境,经验证数据完整,且能够继续增量,业务系统运行正常,验证方案成功。

总结与产品需求思考

由于HyperMotion在同步数据时,云存储网关可以实现多对一的能力,所以在实际处理过程中相对比较集中,不容易出现错误。通过构建“仿真”环境,在完成相关更换卷类型后,从业务层面进行验证,保证数据完整性和安全性。

目前HyperMotion已经在前期规划阶段提供了功能,支持将系统盘和数据盘分别同步到不同的资源池内,这样就避免了在后期切换资源池的情况发生。目前在同步阶段切换卷类型的需求还不普遍,但是基于HyperMotion与云平台的API深度对接的方式,可以在后期直接利用retype接口自动化完成相关的切换动作。