一份全面的VMware替换数据迁移指南（非常详细）零基础入门到精通，收藏这一篇就够了

本文链接：https://blog.csdn.net/Python_paipai/article/details/140705504

VMware虚拟化平台的替换变得日益迫切，数据迁移更是整个替换过程中的重中之重。要将现有虚拟环境中的数据、应用和配置，无缝迁移到新的平台，并确保业务的平稳过渡和最小化停机时间，这一过程的成功不仅依赖于先进的技术和周密的计划，还需要对业务流程和数据架构有深刻理解。

本文将深入探讨针对VMware虚拟机数据的在线迁移技术、策略、流程和最佳实践，为用户提供一份全面的数据迁移指南，助力用户顺利完成这一关键任务。

虚拟机迁移技术背景

目前国内主流的虚拟化平台都是基于KVM进行开发的，与VMware ESXi所使用的VMDK不同，KVM采用QCOW2作为虚拟磁盘镜像格式，无法直接读取VMDK来启动虚拟机，所以虚拟机迁移的本质是对VMDK的数据进行处理成为KVM可识别的QCOW2文件。在这个过程中，最重要的是保证数据的完整性，即如何正确地、稳定地、安全地处理虚拟机数据使其在迁移完成后可以正常支撑业务运行，同时在迁移的过程中应尽可能降低对业务运行的影响。

在实际的用户环境中，VMware的虚拟化平台有两种部署方式，一种是vSphere挂载FC或iSCSI存储的分离部署，另一种是vSphere配合vSAN存储的融合部署。这两种部署方式对于虚拟机迁移来说数据路径是相同的，由于新建虚拟化平台无法直接读取VMDK使用，所以需要通过一条迁移网络将vSphere环境上的虚拟机从原来的存储介质移动到新的存储介质进行格式转换。因此在网络上需要为迁移打通一条能够稳定高效传输数据的迁移链路，在存储上需要为迁移目标平台准备相同大小的容量空间。

在迁移方式的选择上，VMware提供了一种支持导入导出的OVA文件，允许用户将虚拟机导出为OVA格式以导入到其他虚拟化平台使用。但这种方式在操作时需要虚拟机全程关机，随着业务连续性要求越来越高，这种导出/导入的方式已逐步被迁移方案所淘汰。

**目前主流的迁移方式是以首次全量+持续增量的传输模式实现虚拟机的在线迁移，**在不影响虚拟机运行状态的情况下，通过多次的数据传输将源端数据迁移至目标端，通过提高传输频率来减少差异数据量，通过停机切换来同步最后的差异数据保证迁移前后的数据一致性。

基于首次全量+持续增量的在线迁移模式存在两种迁移技术，以及四种迁移方案：

基于 VDDK 接口的快照迁移（无代理）

VMware纳管迁移：使用深信服云/虚拟化平台纳管vCenter进行数据迁移
SCMT无代理点对点迁移：使用深信服迁移工具对接vCenter进行数据迁移

基于 OS 文件系统的数据拷贝（有代理）

SCMT有代理点对点迁移：使用迁移工具对接代理插件，基于数据复制进行迁移
SCMT有代理热备迁移：使用迁移工具对接代理插件，基于CDP技术进行迁移

基于 VDDK 接口的快照迁移（无代理）

无代理迁移技术使用虚拟化平台或迁移工具对接 vCenter的VDDK接口，对ESXi下达相应的数据快照和传输指令，全量迁移时通过快照来记录全量数据进行传输，增量迁移时通过快照进行数据对比传输增量数据。

所有的数据在传输到目标端之后，由目标端虚拟化平台进行文件格式转换，将VMDK的数据格式转换为目标端平台可以识别的QCOW2格式，在格式转换的过程中来完成相关的驱动注入、VMtools安装、系统优化配置等工作，这一切完成之后源数据才能正常给虚拟机使用。

无代理迁移技术实现逻辑

优点：无代理迁移技术相对来说操作简单，用户不需要准备复杂的迁移环境，只需要对接标准的接口即可实现迁移。

缺点：此方法通过快照实现，在每次数据传输之前需要对虚拟机进行创建快照以及删除快照的操作，而频繁地对VMDK文件打快照将会大幅降低其读写性能，对于正在运行的业务来说可能会影响正常工作。

无代理迁移技术依赖的VDDK接口由vCenter提供，而非ESXi本身，所以在VMware资源池必须部署 vCenter才能对接完成迁移。而不同版本的vCenter接口表现不同，在进行迁移设计时注意确认vCenter与 ESXi 的版本号。

深信服无代理迁移与VMware版本兼容性

注：8.0版本将在24年下半年支持

深信服无代理纳管迁移

**深信服云/虚拟化平台内置纳管VMware的能力，**支持通过443和902端口纳管vCenter调用VDDK接口的方式将VMware虚拟机迁移到深信服平台上运行，允许在开机状态下进行批量系统迁移，在迁移的最后阶段自动关闭源虚拟机完成迁移。

整体过程采用类似于vMotion的做法，简单高效完成迁移动作。

纳管迁移产品实现界面

无代理纳管迁移的方式与日常的运维管理平台相结合，迁移时不需要部署专用的迁移工具和复杂的网络环境，也不需要安装代理插件，适用于对单机类应用系统的批量迁移需求。

纳管迁移在迁移流程上并未进行复杂的工程化处理，比如在迁移过程中不能对配置进行修改、在数据传输完成后自动进行切换、在切换时自动关闭源端虚拟机，因此其适用于那些不关注迁移过程的应用系统，如需实现迁移配置变更、定时切换、无人值守等能力，请使用SCMT迁移工具进行。

深信服无代理迁移工具

深信服提供信服云迁移工具SCMT来实现基于无代理技术的数据迁移，同纳管迁移的技术类似，由SCMT来对接vCenter的接口来获取资源和下发传输指令。相比于纳管迁移来说，SCMT在迁移流程上功能更为丰富，可以实现迁移配置变更、定时切换、虚拟机验证等功能，让整个迁移工作适用于更多场景。

迁移工具无代理迁移逻辑

SCMT迁移工具支持部署在深信服云/虚拟化平台，无需额外的物理硬件资源即可完成迁移工作。

SCMT在迁移流程上做了相对完善的功能设计，整体迁移过程界面可视，加入了更加全面的迁移风险告警。在新建迁移计划时允许对系统资源、IP/MAC、应用配置进行调优，在迁移变更配置时无需多次重启系统。在迁移切换后无需关闭源端操作系统，让迁移过程更加安全，风险可控；支持手动切换、定时切换、批量切换等能力，更加适用于无人值守和非数据库集群迁移场景。

基于 OS 文件系统的数据拷贝（有代理）

有代理迁移技术在待迁移的操作系统内部安装代理插件Agent来直接读取文件系统的磁盘块进行数据传输，在全量迁移时调用Agent读取全部磁盘块的数据，后续持续监控记录IO和磁盘块数据变化，用于进行增量迁移阶段的数据传输。数据在传输到目标端之后会直接保存为可识别的QCOW2格式，不需要经过磁盘格式转换即可正常开机使用。

有代理迁移技术实现逻辑

**优点：**有代理迁移技术直接读取文件磁盘块进行传输，避免了镜像格式转换的过程，无需经过复杂的驱动兼容性处理，一定程度上降低了迁移失败的风险；插件在传输数据时不依赖快照，也避免了打快照引起的业务系统性能下降问题；而且基于插件可以做到更高频率的数据传输，进一步压缩业务停机切换时间。

缺点：此方法需要在待迁移的操作系统中安装代理插件，在大批量迁移场景需逐台安装，增加运维负担；代理插件在进行数据传输的过程中会占用一部分源操作系统的计算资源，造成额外消耗。

在使用有代理迁移技术时，需明确源端操作系统文件系统的格式，避免代理插件无法识别和读取到文件数据。同时需在源端操作系统中预留出用于支撑代理插件运行的CPU和内存资源，避免在迁移过程中与业务进程资源发生抢占，造成不可控的影响。

深信服有代理迁移文件系统兼容性

深信服有代理点对点迁移

**深信服迁移工具SCMT支持通过代理插件Agent的模式进行文件系统的数据拷贝迁移。**在源端操作系统安装Agent之后与SCMT服务端进行连接，用于接收SCMT界面下发的迁移任务和数据传输指令，同时通过读取操作系统中的磁盘块来实现全量和增量数据的传输。借助Agent插件可以降低对源系统的影响，提高迁移效率。

迁移工具有代理迁移逻辑

迁移工具的代理插件Agent在进行数据传输时对源操作系统的CPU占用小于3%，对内存占用小于260M，性能影响可忽略不计。借助Agent做到分钟级的数据传输可以缩短增量数据的传输时间，也就是缩短停机切换的业务停机时间，实现在5~10 钟内完成系统切换开机运行，适用于对业务连续性要求较高的应用迁移。

而相比于无代理备份来说，有代理的迁移方式避免了对源操作系统打快照产生的性能影响，更加适用于对性能表现敏感的单机数据库系统。同时Agent在文件系统层读取数据也意味着可以对源端系统已识别的裸盘或直通卷数据进行迁移，这也是无代理方式无法实现的。

深信服有代理热备迁移

**深信服迁移工具SCMT提供基于CDP持续数据保护技术的热备迁移，**借助代理插件Agent将全量数据和每秒的数据变化量备份至SCMT的服务端，然后通过热备计划将服务端备份的数据推送到目标端虚拟化平台。

目标端在接收到全量数据之后，便生成全新的业务虚拟机，完成驱动注入和配置修改等动作后，进入半开机运行状态与迁移源端同步每秒的差异数据变化量。在进行业务停机切换时，目标端半开机状态的虚拟机可以快速完成 IP 漂移和业务接管，进一步缩短停机切换的时间。