在一个云迁移项目中，用户希望将系统盘存储于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资源池的数据盘等。这种方式将耗时的数据同步仍然在同步阶段完成，避免了在割接阶段对项目进度的影响。
方案三：直接修改卷类型
这种方式直接将目前用于数据同步的SATA卷通过底层同步至SAS资源池，而在cinder中不改变原有的卷id。这种方式对整个迁移流程影响最小，但是可能对源端已经同步的数据造成影响，所以需要非常慎重的进行前期测试。
实施过程
最终，经过云平台和HyperMotion团队的共同讨论及联合测试，最终确定采用方案三作为首选方案，而方案二则作为备选方案。
1、筛选需要切换类型的卷
首先，需要区分所有需要转换资源池的数据盘，这些信息直接可以从HyperMotion现有的资源池中获取。同时，获取这些卷所对应的云存储网关。为了数据完整性，在切换过程中，先暂停源端数据同步并关闭存储网关所在的虚拟机并进行卸载操作。
2、修改卷类型
OpenStack Cinder中提供了一个retype命令，用于修改卷类型，底层会调用存储底层命令实现卷之间的拷贝，例如：在Ceph中就是直接调用RBD相关命令完成复制工作。
但是在修改之前有两个前提条件：
- 操作的对象卷不能为挂载状态，所以在上述步骤中，我们需要将卷先进行卸载
- 操作的对象卷不能有依赖的快照资源，由于之前已经将所有的业务系统在云平台进行了演练，导致底层存在依赖链，必须要断链后才能删除快照，这里使用了rbd flatten命令进行解链操作
rbd --pool {pool-name} flatten --image {image-name} rbd flatten {pool-name}/{image-name}
完成以上配置后，通过脚本批量的对卷类型进行修改，修改后，卷的ID信息仍然保持不变。
3、重新挂载验证
将修改后的卷，按照之前的归属关系，重新挂载回云存储网关，重新开机。此时由于卷类型已经改变，需要在HyperMotion中修改卷类型，以保证下次接口调用的正确性。完成后，继续进行增量同步，一切恢复正常。通过迁移演练功能，在云平台进行割接前构建仿真环境，经验证数据完整，且能够继续增量，业务系统运行正常，验证方案成功。
总结与产品需求思考
由于HyperMotion在同步数据时，云存储网关可以实现多对一的能力，所以在实际处理过程中相对比较集中，不容易出现错误。通过构建“仿真”环境，在完成相关更换卷类型后，从业务层面进行验证，保证数据完整性和安全性。
目前HyperMotion已经在前期规划阶段提供了功能，支持将系统盘和数据盘分别同步到不同的资源池内，这样就避免了在后期切换资源池的情况发生。目前在同步阶段切换卷类型的需求还不普遍，但是基于HyperMotion与云平台的API深度对接的方式，可以在后期直接利用retype接口自动化完成相关的切换动作。
