一、整体方案
1.1 背景
随着银行国产化替代趋势的显著增强，为响应我行中心当前及未来对VMware资源迁移的迫切需求，亟需一套全面且成熟的技术解决方案。该方案需深入考量计算、存储、网络及安全资源等多个维度，确保在不影响业务连续性的前提下，对现有VMware虚拟化环境进行高效、有序的转换，并最大限度地降低迁移过程中的潜在风险。1.2 迁移工具需求
在如上介绍的大背景下，针对VMware的迁移替代，选择一种合适的迁移工具就是重中之重了。不妨先绘制一个理想迁移工具的蓝图。- 首先，它需要具备一定的业务保护措施，能够实现在新环境做完基础验证后再进行切换，并且可支持回退；
- 可批量迁移，支持较高并发，保障在有限的割接时间内完成一个网段、一个网络域或者一个业务系统的迁移任务；
可兼容其他厂商，目的端不做绑定。
二、云厂商迁移工具调研
2.1 迁移工具概况
先对迁移方式做一个大致总结，按照功能可以大致分为：l2l（离线镜像转换）、V2V（迁移虚拟机到虚拟化平台）、P2V（迁移物理服务器到虚拟化平台）。尽管离线镜像转换的方式在技术上可以自行实施，但存在业务停机时间长，手工操作较多的问题。所以在此处不多做探讨，只分析在线迁移工具。了解了市面上的主流云厂商的在线迁移工具，认为大致可以分为两种思路，一种是在OS层面通过扇区复制、分区快照等手段实现数据迁移，即：有代理迁移；另一种是在底层存储/虚拟化层通过块设备快照等方式实现块级别的数据迁移，即：无代理迁移。可以说，其本质的区别就在于实现需求所利用的技术层级不同。毕竟要想通过底层（存储/虚拟化层）去解决，得先拿到源端底层的权限和接口支持，对其兼容适配的程度也会直接影响到迁移的成功率。而有代理迁移在OS层面解决，避开了底层的复杂性和兼容性问题，提供了更好的适配性，但可能在性能方面相对有所降低。2.2 调研思路
调研一个迁移工具的核心是要了解它针对数据迁移的实现，大致也可以分为两个阶段，首先是全（存）量数据复制，即确保在迁移开始的这一特定时刻，源端的数据能够完整无误地复制到目标端；随后是增量数据同步，即处理在此时间点之后产生的所有新增数据，确保数据的完整性和实时性。在真实场景中，迁移工具的设计会更为精细。例如，在全量迁移过程中产生的增量数据，与迁移开始后新产生的增量数据可能需要进行区分处理。同样，在割接前的增量数据同步与割接时的增量数据同步机制也可能有所不同。无需太过关注此处，基本的实现思路是一样的，只不过在迁移的业务逻辑上实现的更精细些。迁移工具的外围些配置类似驱动注入、配置网络、分区格式化、grub引导等都是在虚拟化层和OS层的通用配置，基本都是将离线镜像转换中同样存在的手工操作以自动化、图形化的方式在页面上实现，各工具大同小异，至于其所带来的稳定性、适配性、用户体验等还需在实际使用中仔细感受，此处不多赘述。下面也将围绕数据迁移的实现上对有代理和无代理这两种方式展开说明。2.3 有代理迁移
下面的介绍主要参考了某主流云厂商迁移工具的实现思路。针对Windows的迁移，在存（全）量数据复制层面，其主要依靠bitmap来识别有效扇区，复制已使用扇区到目的端；在增量数据同步上，主要依据变化扇区追踪表来读取分区快照数据（卷影副本）进行数据复制。可以参考如下示意图。
针对Linux的迁移，有文件级和块级别两种方式，块级迁移在存（全）量数据复制层面，是使用dd命令进行全盘数据读取，根据源端磁盘已分配的大小计算需要传输的块数，从而拷贝磁盘中标记为已使用的扇区；增量数据同步通过拷贝磁盘中有变化的扇区到目的端实现。Linux文件级迁移在存（全）量数据复制层面，依靠依靠源端 tar工具配合脚本进行全量复制；增量数据同步则是依靠源端rsync工具。可以参考如下示意图。
同时初步了解了多家云厂商的迁移工具，大体上的迁移机制是相似的，但具体的底层实现细节仍需进一步深入探索。有代理的迁移方式优势在于迁移场景广泛，v2v、p2v，并且可以支持公有云迁移到私有云，不受源端平台限制。2.4 无代理迁移
无代理迁移的实现大多是利用两次块设备快照进行数据比对，同步增量数据。无代理相较于有代理，毕竟是从更底层去解决需求，其优势在于性能好，效率高。但对于源端来说，各厂商的快照机制等不一致，这种方式对源端也就会有一定的局限性，比如源端是自己家的产品或者VMware。
2.5 云厂商迁移工具总结
在OS层实现的有代理的迁移方式，主要借鉴的是不同OS下所使用的数据恢复、数据同步等技术手段，将其应用到迁移工具中。又可以分成块级和文件级，块级的优势在于速度相对较快、分区结构与源端保持一致；文件级的优势在于支持分区大小调整、可按目录排除不需要迁移的文件、只迁移有效数据。而底层存储/虚拟化层的无代理迁移方式，主要就是利用存储或者虚拟化提供的磁盘快照功能，通过全量加增量的方式高效实现数据迁移。回顾需求，在产品自身健壮性、稳定性、性能满足要求的同时，还需要用户侧容易上手、开箱即用，再有就是开源开放，能兼容其他厂商的产品。根据现有的调研情况来看，厂商的迁移工具都会借助快照等技术实现一定的业务保护措施，并且均可在确认业务无问题后正式切换。但根据对主流云厂商迁移工具的调研结果来看，目标端都是对自家产品做了限定。VMware等迁移到自家虚拟化平台上都可以适配，但如果迁移到其他厂商的虚拟化平台上是无法支持的。所以导致了不同的目的虚拟化平台所要适配的迁移工具也不一样。伴随云厂商迁移工具的调研，特别是关于文件级别的迁移思路打开了视野，如果迁移的目标端能够灵活支持主流信创Linux操作系统，而非必须与迁移前的操作系统保持一致，这将极大满足迁移业务需求，提升迁移的灵活性和效率。下面将进一步展开对OS厂商迁移方案的调研。
三、OS厂商迁移方案调研
3.1 原机迁移
可以支持对原主机CentOS/RHEL系统直接替换到OS厂商符合信创的操作系统，且无需重新部署业务应用。其原机迁移评估报告还可以展示基本信息、包变更列表、包差异列表、接口兼容性、应用软件兼容性、第三方驱动兼容性和系统环境信息。3.2 扩容迁移
可以支持在新建主机资源并部署他们符合信创的操作系统的场景下，对原业务应用部署到新建系统的迁移评估分析。扩容迁移支持对应用软件或系统配置进行从CentOS向新系统迁移的迁移评估，具备对待迁移软件包进行文件扫描、依赖识别，接口差异、操作建议等功能，具备从用户环境收集配置信息并评估的功能。可见，在一步改造到信创操作系统的需求上，OS厂商的迁移方案比云厂商文件级别的迁移方式更能满足需求。但据调研情况来看，现此方案案例较少，直接应用在现网生产环境风险较大。先将其作为技术储备，待后期深度测试后进行评估。
四、工具及路线选择
4.1 迁移工具的场景匹配
- 源端：VMware+RedHat，目的端：信创虚拟化+信创OS
- 源端：VMware+RedHat，目的端：信创虚拟化+RedHat
源端：VMware+RedHat，目的端：信创虚拟化+信创OS，主要针对OS能更换为信创的情况。可以实现在底层硬件资源、虚拟化及OS一同完成信创改造，在基础设施层一步到位。针对该种场景可以在主流OS厂商迁移方案成熟后可以考虑。源端：VMware+RedHat，目的端：信创虚拟化+RedHat，主要针对OS暂不支持信创的情况。伴随资源层面Intel+VMware传统架构的后期投入减少，而业务改造暂时无法支持信创，还需使用RedHat的场景下，可能会需要先迁移到另一个KVM虚拟化平台。针对该种场景，根据目的虚拟化平台，使用该厂商迁移工具，迁移工具兼容性上达到最优解。其余类似Windows改造为Linux、Windows虚拟机直接改造为容器、Linux虚拟机改造为容器等变革，均属业务改造。此类需求需虚拟机平台相关能力支持较少。在此处不多做赘述。4.2 资源替换路线
整体迁移方案的设计应充分考量传统架构与云架构之间的核心差异，并精心规划资源替换路径，以确保迁移过程顺畅且业务系统能够顺利完成信创改造。迁移过程中，不仅涉及虚拟机，还包括防火墙、负载均衡、WAF、交换机等网络及安全资源的整合。可以概括为4种主要技术路线：1、首先是延续使用传统架构，将VMware的虚拟机迁移到国产虚拟化平台上。虽然虚拟化平台本身不提供全面的网络、存储和安全功能，但可以配合相应的硬件设备，如防火墙、负载均衡等，进行整体替换为信创产品。这种方案的优势在于部署简单、基础设施复用率高，短期成本效益显著。且与替代前架构完全一致，各管理员都更容易上手。然而，其劣势在于对存储、网络的适配需求还需进一步测试，且不同厂商间的兼容性可能存在差别，出现问题时需针对各厂商产品联查。2、另一种是采用云架构，将VMware虚拟机迁移到云平台上。以VPC来划分网络域、以云内vFW/网络ACL来代替硬件防火墙设备、以SLB来代替硬件负载均衡设备、以vWAF来代替WAF设备等以云服务的方式代替传统硬件设备。云架构的优势在于提供丰富的开箱即用服务，包括SDN、SDS等基础设施能力，以及中间件、数据库、容器、大数据等扩展能力，以提供更全面的运维能力，更多样的运营模式。且一般情况下网络、计算、存储等能力都由一家提供，兼容性方面会更好，出现问题时协调更简单，但同样，也更容易被一家厂商所绑定。此外，云架构的建设成本较高，且需要工程师具备相应的技术栈。3、当然，在这两种架构之间还可以选择超融合架构。超融合架构对比信创虚拟化传统架构的优势在于将计算能力、存储和网络等基础设施层能力高度集成，使得在小规模场景下可以以最低的成本让用户实现云化体验，建设成本和管理成本相对云架构都要低廉。但同时，对比IaaS云平台的云管功能可能稍显不足，对比信创虚拟化方案在存储等基础架构选择的灵活性也可能稍逊一筹。此外，随着规模的不断扩大，计算不足扩计算、存储不足扩存储的需求愈发强烈，存算分离架构的灵活性也愈发彰显，超融合一体机的方案就不太适配了。4、长远来看，如果能一步到位直接迁移到云原生平台是再好不过了。尽管这一过程复杂度较高，需要对各个应用及其服务分析依赖关系并拆分，选择软件替代路线，进而完成容器化改造和持久化数据迁移，但这将带来根本性的变革。无论是平替虚拟化、超融合还是IaaS云平台，它们还只是在Hypervisor层面进行替换，而迁移到以容器为核心的云原生平台是真正意义上的部署方式革新。在选择迁移路线时，需综合考虑现网环境需求、资源投入现状、资源类型的增长预期、预期投入以及工程师技术栈等现实因素。没有绝对的优劣之分，只有最适合自身情况的方案。因此，在决策过程中应充分评估各种因素，在确保迁移过程顺利、业务系统稳定运行的同时，平衡成本效益，才能达到期望的产出。
五、结语
迁移是一个系统工程，熟悉工具原理、理解其设计思想的同时，要注重整体迁移方案的设计，在保证业务连续性的同时尽可能提升迁移效率。迁移工具本质上只是解决了计算（换了计算平台）和存储（卷或者文件的数据同步到新平台）的问题，将工具揉入到整体迁移方案，与现网环境以及届时的迁移场景相匹配是日后重点。无论选择何种技术路径和迁移工具，预配置、割接与业务迁移工作的协同配合都至关重要，要求在资源、流程和工具三方面同时发力。预配置主要指的是云内或者云外的网络资源预配置，需要在业务割接前完成，以此来减轻割接当天压力。在迁移完成的关键时刻，业务停机同步最终增量数据的同时，需同步进行网络资源的割接，确保迁移后业务资源服务能力的顺利暴露。此外，有两个关键的细节需要引起重视。首先，对于如Oracle、WAS等数据库、中间件、应用及业务系统的迁移，必须制定详尽的备份、重启恢复及验证方案。这些方案不仅要确保系统服务的开机自启功能正常，还需在迁移完成后迅速完成业务恢复和业务验证工作，以确保业务的连续性和稳定性。其次，在迁移开始前，尽量确保虚拟机磁盘及分区关系的准确性。这两方面的忽视可能导致仅重启（即使不迁移）会发生的问题对迁移工作造成困扰。下方流程图基于我们本次对迁移工具调研及之前迁移经验进行详细整理，比较实用参考。希望可以可为大家在学习和生产环境实践中提供参考。
（点击图片可放大）
欢迎点击文末阅读原文到社区阅读和讨论交流，发表您的看法觉得本文有用，请转发或点击在看，让更多同行看到
