先迁移，再调研——容灾渐进式迁移完美实践

       迁移通常是客户上云之前的最后一道门槛，对于集成商伙伴来说，云已经搭好了，最后上云一步往往难以跨越，这是为什么？

       业务系统分散在不同平台，IT人员缺失，老旧系统无人维护等，碰到这样的甲方客户，集成商往往都很难办，不得不投入大量的现场运维人员做前期调研，甚至请迁移厂商驻场，但这也意味着过程中会消耗大量的人力财力，且周期难以预测。这样巨大的迁移成本，让集成商对于提供云迁移服务望而却步，身边没几个咨询顾问，你都不好意思跟客户打招呼？！

        在对业务关联性没有充分调研的情况下，大干快上的迁上云，系统能不能跑，有什么风险？恐怕没有谁敢打包票。但如何解决迁移调研和验证的效率问题？结合我们的产品特点和多年的迁移实践，大胆的提出一个渐进式迁移的思路：先迁移后验证，只需要明确业务系统组成范围和相关责任人，其他复杂业务问题：包括业务关联性、系统变更等，则后置在迁移验证阶段完成，在仿真环境完成。

       大量的实践案例证明，这种迁移思路行之有效且效率高，为上云最后一公里扫清了障碍，也让集成商自助实现云迁移的门槛更低，这种迁移思路我们称之为容灾渐进式迁移：即充分利用云上虚拟网络隔离的特性，构建近似真实的仿真环境，而不影响正常的业务系统运行。通过构建与真实环境相同的网络地址段（与原有网络隔离，避免造成数据污染），将业务系统按照原有IP地址恢复至该网段内，这样仿真环境就真正的建立好了。业务系统的运维方在仿真环境中进行业务变更验证，并将步骤记录，而业务系统负责人在仿真环境从业务维度进一步验证。这使得我们通过验证过程发现问题完成调研，也让业务方能够安心进行验证后迁移。

       当然并不是所有的迁移工具都可以实现“容灾渐进式迁移”，产品与云的亲和程度决定了一切。万博智云的HyperMotion云迁移工具，通过与云原生接口和资源的深度对接，实现了业务系统在云上高度自动化构建“仿真”环境。

       之所以可以采用这种“容灾渐进式迁移”，也取决于我们的产品设计框架，万博的HyperMotion云迁移工具，是支持多次增量验证的迁移工具，即使迁移验证失败，也不需要全量数据重新迁移，只需要根据验证情况完善系统信息，再选择迁移增量数据即可。

      这里我们演示一下，以HyperMotion实现OpenStack迁移且验证的过程为例：一个OA业务系统，占用1台主机。

1.选择待迁移主机，点击启动主机 

2.系统自动跳出提示框，选择确认无误后点击【确定】

这里演示的是OpenStack平台，除了对接常规的启动主机接口外，我们还深度对接了卷转移（Volume Transfer）接口，这样用户可以使用一个租户进行数据同步，而启动到另外一个租户内。

另外通过对接Cinder Backup接口，实现了Ceph存储的解除链式关系的问题。

在启动主机时，除了常规的规格、网络选项外，还特别针对迁移后不改变IP的问题，增加了指定启动主机IP的功能。

3.系统提示‘开始启动主机’，等待启动主机，系统提示“启动系统完成”。

      完成主机迁移后，即可在目标云平台启动OA系统，验证迁移成功情况，而源端系统仍然可以运行。在业务负责人验证迁移成功情况下，再考虑清理源端主机上的信息。

       除了采用容灾渐进式迁移模式外，为了将迁移前期调研的工作进一步简化，让集成商伙伴更易上手，我们通过大量实践的总结，形成了标准化的技术调研方案，进而将该方案形成研发需求，开发出调研及分析工具。调研工具的原理非常简单，主要分为三个主要功能：

功能一，通过网络扫描所有存活的主机，通过对nmap的封装，能够对用户局域网内存活的所有主机进行针对性扫描，同时扫描出开放的端口等信息。该步骤作为详细采集前的准备数据。

功能二，基于第一步扫描的结果，由用户业务方提供主机和密码等信息，如果是VMWare，则只需要提供vCenter或ESXi的用户名和密码，程序执行后将自动获取必要的主机详细信息，为进一步分析提供依据。

功能三，基于功能二的详细输出，根据迁移工具的特点进行详细分析，最终得出准确的技术调研报告，其中包含迁移方法及预估的数据同步时间。

       通过以上方式，在技术调研部分我们逐步形成了标准化和工具化，而上述调研工具我们也将逐步开源(github.com/hostminer)。关于这个工具，我们下回分解。