《VMware迁移实践指南》让医疗行业告别“不敢动、不会动、怕出事”

来源：HIT专家网 供稿：深信服

随着医疗行业信创升级建设改造的速度加快，以及VMware技术与成本的不确定性，越来越多的医院开始启动VMware迁移工作。但由于医疗业务系统复杂、连续性要求极高，许多医院在实践中普遍存在“不敢动、不会动、怕出事”的顾虑。

深信服深耕医疗行业多年，为超过2500家医疗机构提供迁移咨询服务与落地实践经验，助力超700家三甲医院将核心业务系统平滑迁移至超融合、私有云及托管云平台，包括华中科技大学同济医学院附属同济医院、青岛大学附属医院、广西医科大学第一附属医院、浙江省中医院等大型三甲医院。在大规模迁移实践沉淀中，深信服总结出了一套可落地、可复制、风险可控的VMware迁移方法论，希望为广泛的医院提供实操指南，助力医院核心业务系统迁移更稳定、更高效、更安全。

一、迁移前的调研评估

1.环境信息全面盘点
医院应对现有VMware环境进行全面盘点，覆盖服务器、操作系统、虚拟化平台、网络、存储等，形成统一台账，为后续评估与迁移提供数据基础。

2.以业务为核心的深度分析
由医院信息中心牵头，联合业务系统负责人逐一确认（图1内容）。

3.虚拟机与硬件兼容性评估

需确认操作系统、虚拟机配置是否满足目标平台兼容要求。建议使用自动化工具从vCenter批量采集虚拟机信息，提前识别快照、RDM、独立磁盘、SR-IOV等高风险配置，避免人工遗漏。
最终形成《医院VMware环境调研报告》，明确可迁移对象、风险点及应对策略。

【实践经验分享】

某市级三甲医院在VMware迁移初期，因对HIS、EMR等核心业务间依赖关系梳理不足，导致迁移后部分业务无法启动，虽依靠回退机制降低了影响，但影响了用户对核心业务迁移的信心。此后，深信服承接迁移任务，通过“自研工具批量采集+业务方专项确认”的方式，按业务系统整体关系进行了重新梳理（比如HIS系统和Oracle数据库的连接地址、端口；EMR和打印系统的交互关系，跨系统调用的优先级；Windows是不是动态磁盘、有没有AD集群域控、软件授权是不是依赖UUID或MAC地址；Linux集群、Nginx服务有没有未写入网卡配置文件的虚IP以及虚IP的绑定方式和切换逻辑），对具有依赖关系的业务实行统一批次迁移，确保业务连续性。最终，在一周内顺利将百余台核心虚拟机迁移至超融合平台，且每次迁移后均能快速恢复业务。

二、迁移方案设计：分级、分批、可回退

1.虚拟机迁移工具策略

针对虚拟机迁移，基于业务连续性要求与系统复杂度，目前主要采用有代理迁移与无代理迁移两种方式。

2.数据库迁移策略

（1）单机版数据库：采用虚拟机整机迁移方式实施，确保数据库运行环境与配置的一致性。

（2）数据库集群：采用专用的数据迁移工具（如DTS）进行迁移，避免整机迁移时影响数据库数据的一致性。

3.迁移批次规划：基于依赖关系与中断窗口

迁移批次规划遵循“以业务为中心、小步快跑、逐批验证”的原则，综合考虑图2中各项因素。

4.迁移应急回退机制

系统迁移属于高风险变更操作，即使在充分测试和严格管控的前提下，仍存在小概率迁移失败或异常的可能性。因此，在迁移方案设计阶段即需同步规划应急回退机制，以确保业务连续性和数据安全。

【实践经验分享】

某大型三甲医院在虚拟机迁移时，为追求效率与稳定，选择了有代理的迁移方式。但深信服团队敏锐发现医院HIS、LIS、EMR等核心业务系统已使用超过十年，大部分核心业务系统运行的是CentOS 7（3.10 内核）、SUSE 12 SP5（4.12 内核）、Ubuntu 24.04等老旧或特殊版本的操作系统。如果直接迁移很可能出现驱动不兼容、启动失败的问题。因此，深信服采用有代理和无代理相结合的解决方案，以覆盖不同类型的虚拟机迁移需求：

针对老旧或特殊版本操作系统的解决方案：（1）信息采集：通过MigrateInsight工具筛选出不兼容的虚拟机，针对性用uname -a、cat /etc/*-release命令批量收集内核版本、文件系统类型，无需逐台采集。（2）验证部署：先在隔离测试环境验证适配效果，确认无误后，通过深信服自研SCMT平台，导入适配包，实现全量兼容。（3）风险兜底：针对RDM（裸设备映射）磁盘虚拟机，先将RDM磁盘转换为虚拟磁盘，再进行迁移，避免直接迁移导致兼容性问题。

除此之外，深信服还按医院业务中断容忍度、重要程度，对业务进行分类分级：

（1）“零容忍”业务（68台虚拟机，含HIS、LIS、EMR、PACS、集成平台等核心业务）：用SCMT热备迁移，实时同步数据，切换时间控制在5分钟内，确保零中断。

（2）“短窗口”业务（75台虚拟机，含医疗科研大数据/临床AI、云体检等）：部分无特殊配置的虚拟机用VMware纳管迁移（无需代理），其余用SCMT有代理点对点迁移，先预同步数据，再短时间停机切换。

（3）“可宽限”业务（50台虚拟机，含门户网站、互联网医院、微信公众号等）：优先用VMware纳管迁移即可，节省工具资源。

（4）在迁移工具部署上，部署了3台32核64G规格的SCMT迁移平台，支持40并发迁移、18并发切换，就算是大规模迁移，效率也能跟上。

采用有代理和无代理相结合的解决方案，既保障了迁移速度，又保障了虚拟机迁移的稳定性，帮助用户在一周内完成接近200个核心业务的虚拟机迁移工作。

三、迁移实施：稳妥推进，确保业务连续与风险可控

1.迁移测试：在正式迁移前完成全流程验证

如图3所示，在正式迁移之前，建议开展完整的迁移测试，用于验证迁移方案在真实环境下的可行性。

2.提前备份：为迁移提供兜底保障

备份的目的并非替代迁移回退机制，而是在极端情况下为业务恢复提供最后一道保障，确保迁移过程中的异常不会导致不可逆的数据风险。

3.正式迁移实施：在线迁移与增量同步并行

正式迁移阶段，虚拟机采用SCMT/SCP在线迁移+增量同步的方式实施。在白天业务运行期间可以执行热迁移，待数据迁移基本完成后，选择夜间执行切换，标准切换流程如图4所示。

通过该方式，可将业务中断时间控制在1–5分钟内，满足医院核心业务对连续性的要求。

4.分批迁移节奏：小步快跑，持续验证

（1）首批迁移，进行低风险验证：首批选取1-2个非核心业务系统迁移，验证迁移方案及平台运行稳定性；迁移完成后，设置1个完整工作日的观察期，核查业务稳定性、性能及可用性。

（2）扩展迁移，稳定节奏推进：每晚/隔日迁移2-4个业务系统，按数据量灵活调整，严控单次迁移数量；当晚完成割接与初验，次日白天由专人保障运行、观察系统状态。

迁移实施阶段是VMware迁移过程中风险最集中、最考验方法论成熟度的环节。在医疗场景下，迁移实施的核心目标并非“迁得快”，而是在可控节奏下完成迁移，确保业务不中断、数据不丢失、问题可回退。因此，迁移实施需严格遵循“先验证、再迁移、持续观察”的原则。

【实践经验分享】

为保障某大型三甲医院50余台多品牌物理主机（含刀片、华为、浪潮等）、超400台VMware虚拟机的整体迁移顺利，深信服组建了“总部专家+区域团队+研发支撑”的三级专属团队，提供体系化支撑：

1.精细化计划：按天拆解，进度透明

深信服制定了一份“按天拆解 + 按小时落地”的迁移计划表，对每天要迁移的虚拟机数量、负责人、业务验证节点都进行了详细计划：

（1）每日迁移清单：明确启动要迁移的虚拟机名称、业务类型、责任和预期时长。

（2）时间窗口划分：将不可中断的业务严格锁定在22:00-06:00的夜间窗口，每台虚拟机的迁移时间精确到小时。

（3）验证节点设定：每迁移10台虚拟机就进行一次“检查”，每日结束后给客户发送《迁移日报》，复盘当日结果。

（4）资源提前：提前锁定SCMT迁移平台的载波数和网络带宽，避免迁移过程中要“抢”资源，影响医院核心业务运行。

2.小范围验证先行：用实际效果说话

先挑选5台有代表性的虚拟机做试点迁移，并且特意选择老旧服务器承载的业务，重点验证兼容性、迁移速度和业务连续性。

3.全流程回退方案：给业务多重保障

针对医院最关心的“迁移失败怎么回退”，深信服设计了三重兜底机制，确保万无一失：

（1）迁移前备份：给所有虚拟机创建快照，针对核心业务如HIS系统的Oracle数据库，还额外做了全量数据备份，并将备份文件存在独立的集中式存储里，实现双重保障。

（2）实时数据同步：核心业务采用SCMT热备模式，迁移过程中实时同步源虚拟机数据，就算出问题，也不会丢数据。

（3）应急回退流程：一旦目标机异常，先关闭目标机网卡，避免和源虚拟机IP、MAC冲突；然后在VMware 控制台启用源虚拟机网卡，配合业务厂家直接登录启动服务，全程不超过5分钟。

四、迁移验证：确保“迁得过去、跑得稳定、用得放心”

1.迁移方验证：从平台与系统层面保障可用性

迁移方验证，重点关注迁移后的虚拟机与基础平台是否满足运行要求，主要从以下几个维度进行：

（1）系统启动验证：避免因迁移后虚拟机无法正常启动，直接导致业务中断。登录虚拟机控制台，确认操作系统可正常进入，且不存在蓝屏、启动失败等异常情况。

（2）网络连通性验证：保障业务访问路径完整，避免因网络异常导致核心服务不可用（图5）。

（3）性能优化工具验证：平台性能优化工具正常运行，才能确保迁移后虚拟机性能达标，避免因工具缺失或异常导致业务运行卡顿（图6）。

（4）配置一致性验证：核对迁移后虚拟机的CPU、内存、磁盘配置是否与源虚拟机保持一致，并且磁盘分区及容量无变化。

2.业务方验证：从业务与合规层面确认“可用即合格”

（1）核心服务启动验证：Oracle数据库、HIS应用服务等，检查服务日志，确认无启动失败或异常报错情况。

（2）核心功能以及业务流程测试：执行查询、插入等典型操作，验证SQL执行结果正确；模拟完整业务流程，验证跨系统调用和交互是否顺畅。

（3）数据库和文件数据一致性验证：对比迁移前后数据库的表数量、行记录数，对核心表进行抽样核对，确保数据一致；对关键业务文件（如影像报告、审计日志等）进行校验，通过MD5等方式确认文件未损坏、未丢失。

【实践经验分享】

迁移验证是VMware迁移过程中成败的关键。在医疗场景下，验证的目标不仅是确认虚拟机成功迁移，更重要的是确保业务系统在新平台上稳定运行、性能达标、数据完整。

针对VMware迁移后的重要验证点以及解决方案包括：

（1）VMware虚拟机迁移前后源机和目标机容易发生变化的参数，如CPU型号、MAC地址、网卡类型、磁盘类型、磁盘驱动、系统UUID等；在迁移前需调研核实业务软件授权是否发生变化，软件是否需要重装（C86和x86版本区别）、是否使用AVX2等指令集、停机时长以及软件厂商提供的支持力度等。

（2）Windows Server 2008系统安装虚拟机vmtools重启后，会出现丢失网关的现象，需要重新配置网关；部分vmtools会出现无法自动注入安装的情况，可以挂载镜像后进入虚拟机手动安装；同时切换到目标主机后，需要重启一遍或者几遍，目的是让虚拟机vmtools配置能及时生效，否则会影响超融合升级等功能。

（3）部分使用docker部署软件的业务，迁移后可能会出现docker网络不通的问题，此时需要软件厂商重新调整docker网络，才能保证业务正常使用。

（4）迁移结束后，部分迁移插件可能未自动卸载，登录服务器手动卸载即可，其中卸载插件不需要重启。

（5）若业务要求必须使用原MAC地址，在迁移任务结束后，可手动重新配置目标机MAC地址为原MAC地址，但是迁移过程中目标机需要使用新的MAC地址作为过渡。

五、经验总结与建议

医院业务信息系统呈现业务系统数量多、类型复杂、业务系统之间依赖关系复杂、停机窗口短等特点，导致VMware迁移过程中存在以下风险点（图7）：

因此，医院VMware迁移不是一次性工程，而是一个需持续推进的过程。通过充分调研、科学规划、分批实施和严格验证，医院可以在保障业务连续性的前提下，平稳完成VMware迁移，为后续信创建设和统一运维奠定基础。

【VMware迁移案例简介（部分）】

1.华中科技大学同济医学院附属同济医院：内网核心业务系统（含HIS、PACS、LIS等业务系统）由VMware迁移至深信服超融合平台双活承载。

2.青岛大学附属医院：超过200个内网核心业务系统（含LIS 、EMR等核心业务系统）由VMware迁移至深信服超融合平台。

3.广西医科大学第一附属医院：超过1500台核心业务虚拟机（承载HIS、EMR、LIS等核心业务系统）部分由VMware迁移至深信服超融合平台，稳定运行超2500天。

4.浙江省中医院：承载HIS等核心业务的超过200台虚拟机由VMware迁移至深信服超融合平台，迁移时间＜1周，迁移峰值速度达500MB/s。（本文由深信服供稿）

【责任编辑：陈曦 版式：明超】