#信服智创# 【项目案例】某会计行业VMware替换实战:双路径迁移模型下的70+虚拟机平滑迁移与架构收敛
目录:一、项目背景 1、部署情况如下 2、两套存储体系 3、业务规模二、现网问题分析 1、稳定性开始出现波动 2、资源已经逼近上限 3、架构复杂度逐渐失控 4、生命周期风险进入临界区三、方案设计 1、整体思路 2、方案取舍过程 3、资源与容量设计 4、业务承载策略 5、存储架构选择 6、双路径迁移模型设计 7、迁移策略设计 四、简要实施过程 1、迁移前准备 2、环境准备 3、迁移工具验证 4、分批迁移策略 5、业务割接与回退 五、关键问题与处理 问题一:vmtools 安装失败导致虚机网络异常 问题二:文件服务器访问延迟波动 六、效果验证 1、稳定性 2、资源使用情况 3、架构变化 4、运维侧变化 七、项目价值总结 1、架构层面 2、稳定性 3、成本与资源策略 4、迁移模型价值八、项目复盘 1、双路径迁移更适合复杂环境 2、分批迁移是风险控制核心 3、文件服务器比想象中更“敏感” 4、一个比较深的体会 一、项目背景 某客户为会计服务机构,核心业务覆盖财务开票、企业代账、资料归档等场景,系统本身不算复杂,但有一个特点:不能中断、不能出错。一旦异常,影响的是客户报税和开票,业务容错空间比较小。 现网环境搭建时间较早,整体已经运行了接近 7 年。1、部署情况如下 服务器:5台 Dell R740 单节点内存:256GB 虚拟化平台:VMware + vSAN 2、两套存储体系 vSAN存储:每节点2×960GB SSD(缓存)+ 14×1.2TB HDD(容量),集群vSAN原始容量约74TB,实际可用容量约37TB(2副本策略) 外置HP存储(iSCSI方式接入),约7TB 3、业务规模业务在不断增长,目前虚拟机数量在70台以上。 其中几类业务比较关键: AD域控(所有认证依赖) 财务开票系统(核心生产) 文件服务器 Web服务及合作方系统 实际存储占用约54TB,折算有效数据约27TB(考虑副本开销后)。 从资源规模看,这套环境并不算小,但也没有大到必须做复杂架构。问题的关键不在“规模”,而在运行时间 + 架构叠加。 二、现网问题分析 这次改造并不是因为某一次重大故障触发的,而是系统在长期运行过程中逐渐“变得不太对劲”。有些问题单独看都还能接受,但叠加在一起,就开始影响决策。 1、稳定性开始出现波动 历史上出现过两次ESXi紫屏(PSOD),当时恢复过程比较顺利,没有造成长时间中断,但这个问题一直没有彻底定位清楚。这个问题虽未引发长时间业务中断,但已经具备明显的不确定性风险。 2、资源逼近平台上限 集群总内存约1.25TB,但使用情况比较紧张: 日常运行:80%左右 高峰期:存在明显资源争抢 最直接的影响是: 新业务上线需要反复评估资源 部分业务性能波动 一开始考虑过扩容,但很快遇到现实问题: 老型号内存采购周期长 成本明显偏高 投入之后仍然是老架构 扩容变成了一件“投入大、收益不确定”的事情。 3、架构复杂度逐渐失控 存储侧是两套体系同时存在: vSAN(本地) iSCSI外置存储 这在早期是为了扩展容量,但随着时间推移,带来了几个明显问题: 存储路径变复杂(本地 + 网络存储并存) 故障排查需要跨多层(虚拟化 / 存储 / 网络) 一些问题很难第一时间判断归属 实际运维中,经常会遇到这种情况: 一开始怀疑是网络 → 排查后没问题 → 再看存储 → 最后才定位到具体组件 排查路径被拉长,风险也随之增加。 4、生命周期风险进入临界区 7年这个时间点,本身就比较敏感。现场能明显感觉到变化: 磁盘故障更换频率增加(尤其是HDD) 硬件状态不再稳定 厂商支持逐步减少 继续在原平台上叠加投入,风险很难评估。 三、方案设计 这次设计并没有一开始就确定“必须上深信服HCI”。现场其实讨论过一段时间,核心问题是:是继续补这套老系统,还是换一套更简单的架构。 1、总体设计策略最终确定的方向是: 新建一套深信服HCI承载核心业务 原VMware保留,作为过渡与回退环境 采用分阶段迁移,避免一次性割接 这不是“推倒重来”,而是一个相对稳的过渡方案。 2、方案取舍过程方案一:继续扩容VMware优点很直接: 不需要迁移 风险可控 但问题也很明确: 原有架构复杂度不会下降 历史问题(PSOD、存储结构)仍然存在 后续还要继续投入 这条路更像是在“延长使用寿命”。 方案二:新建HCI(最终选择)优势在于: 架构收敛(计算 + 存储一体) 运维路径更短 后续扩展更简单 更关键的一点是:可以把复杂度“清掉一部分”,而不是继续叠加。 最终选择新建 HCI,再通过迁移完成过渡。 3、资源与容量设计 新平台采用: 深信服 aServer-X5-2105 × 2 台 资源配置: 单节点内存:512GB 集群总内存:1TB 存储:6×3.84TB SSD / 节点(全闪) 集群原始容量约44TB(双副本后可用约22TB) 4、业务承载策略 一开始并没有打算“全量迁移”。现网有效数据约27TB,如果全部迁入: 容量压力较大 成本不合理 最终做了拆分: 核心业务(约7TB)迁入HCI 非核心业务继续留在原平台 这样处理之后,新平台负载控制在约30%~50%,同时预留了扩展空间。 5、存储模型选择 在方案设计阶段,对两种路径进行评估: 方案 优点 缺点 混合架构(SSD+HDD) 容量大 随机IO性能不稳定 全闪SSD架构 高性能成本较高、容量受限 结合实际业务: 文件服务器:大量小文件随机读写 财务系统:数据库事务型IO 在经验判断中,混合架构有一个明显问题:一旦缓存命中下降,HDD会成为瓶颈,尤其是在并发访问时,延迟会放大。 最终还是选择了全闪架构,核心考虑不是“性能极致”,而是:让性能更稳定、可预期。 6、双路径迁移模型设计 在多业务迁移场景中,如果只依赖一种迁移方式,一旦失败,会影响整体节奏。因为不确定性主要来自: 虚拟机驱动差异 存储结构差异 操作系统兼容性 于是补了一条“兜底路径”,形成双路径模型: 主路径:纳管迁移 无需Agent 支持在线迁移 适用于标准虚机批量迁移 兜底路径:SCMT迁移 支持Agent 支持全量 + 增量同步 切换窗口可控 主要用于: 驱动兼容问题 纳管迁移失败场景 7、迁移执行策略 所有虚拟机统一采用三阶段迁移: 全量同步 多轮增量同步 最终切换 在实际执行中,大多数业务中断可以控制在: 3~10分钟(特殊情况例外) 四、简要实施过程整个实施周期控制在两周左右,没有做“大批量一次性迁移”,而是拆开执行。1、迁移前准备 主要做了几件事: 梳理70+虚机清单 标记业务依赖关系(重点关注AD、财务系统) 整理VLAN、IP规划 统计迁移数据量(约7TB核心数据) 在梳理依赖关系时,有一个比较直观的感受:AD一旦出问题,所有系统都会受影响 所以后面迁移顺序是围绕这个来设计的。 2、HCI、SCMT环境准备 完成集群初始化 计算、网络、存储配置与调优 部署SCMT虚拟机 这里有个关注点: VMware、HCI网络打通(确保迁移链路稳定) 3、迁移工具验证 在正式迁移前,单独对SCMT做了一轮验证。当时的目标很简单:不追求快,只确认“能不能用”。 测试结果: Windows / Linux都能正常迁移 启动成功率100% 单台切换时间约5分钟 做到这一步,其实心里就比较有底了。 4、分批迁移策略 迁移顺序不是按“重要程度”,而是按“影响范围 + 可控性”来排的: Web、打印服务 → 先做验证 文件服务器 → 中间阶段(重点观察) AD、财务系统 → 最后迁移 这里有一个取舍:文件服务器虽然不是最核心,但用户感知最明显,所以放在中间阶段处理。 5、业务割接与回退设计 割接统一在夜间窗口执行。流程相对固定: 完成最终增量同步 停止源端虚机 启动 HCI 侧虚机 回退策略做得比较保守: 源虚机不关机 仅断开网络 出现问题可以快速恢复 整个迁移过程中,这套回退机制没有真正用上,但在现场非常关键——有回退,执行起来心里更稳。 五、关键问题与处理这次迁移整体过程是可控的,但并不是完全“顺滑”。 真正有价值的,反而是中间遇到的这些问题。 问题一:vmtools 安装失败导致虚拟机网络异常现象 个别虚拟机迁移完成后,系统可以正常启动,但网络始终不通。 现场第一反应是比较常见的方向: 虚拟网卡类型是否兼容 但检查下来,配置本身没有明显问题。 排查过程 一开始的判断其实有点“惯性思维”——优先怀疑驱动兼容。 尝试过: 更换虚拟网卡类型 问题依然存在。这时候才把关注点从“虚拟化层”往系统内部转。 继续排查vmtools安装日志,发现报错:Error: copy file success but the file is not the same! Please retry.Install Update module failed!这个报错本身不算典型,很容易被当成偶发错误忽略。 根因定位继续往系统层看,发现一个细节: /boot分区使用率已经接近满 进一步分析后确认:vmtools安装过程中需要写入引导相关文件/boot空间不足时: 文件写入不完整 校验失败 安装流程中断 最终导致:驱动未正确加载 → 网络异常 处理方式处理过程反而比较简单: 清理 /boot 分区无用文件 释放空间 重新安装vmtools 处理后: 驱动正常加载 网络恢复 经验总结:这个问题本身不复杂,但有两个点比较典型: 迁移问题不一定出在“迁移工具”或“虚拟化层” 系统内部环境(尤其是分区空间)很容易被忽略 在后续迁移中,针对 Linux 虚机,额外增加了一步检查: 提前确认/boot、/、/var等关键分区空间 避免同类问题重复出现。 问题二:文件服务器访问延迟现象文件服务器迁移完成后,用户反馈: 日常访问基本正常 但在高并发访问时,偶尔会出现短时间卡顿 这个问题的特点是: 不稳定、不可复现、但用户有感知 排查过程现场第一判断是典型三板斧: 看存储IO 看网络 看资源使用 结果比较“反直觉”: IO没有明显打满 网络无丢包 CPU /内存也正常 一度怀疑是应用层问题,但对比迁移前情况,又基本可以排除。 定位过程后来把关注点放在一个细节上: 存储策略和原环境是否一致 发现: 初始配置使用的是通用策略 没有针对文件服务器做单独优化 虽然资源没有打满,但在并发场景下: 缓存命中率波动 IO调度不稳定 就会放大延迟感知。 处理方式针对文件服务器做了两点调整: 切换为高性能存储策略 优化磁盘分配方式 调整后: 延迟波动明显收敛 用户侧基本无感 经验总结这个问题有一个比较典型的误区:“监控看不出问题 ≠ 用户体验没问题” 尤其是文件服务这类场景: 对延迟敏感 对稳定性要求高 在迁移后,建议优先做一轮: “用户体验验证”,而不仅仅是资源指标验证 六、效果验证迁移完成后,没有立即做结论,而是观察了一段时间运行情况,再做对比。1、平台稳定性迁移前: 存在磁盘老化问题 HDD更换频率增加 出现过PSOD 迁移后: 集群运行稳定,无异常告警 全闪架构下,未再出现磁盘相关问题 未出现主机级异常 现场最直观的反馈是:运维侧“心理压力明显降低” 2、资源使用情况迁移前: 内存长期维持在 80%+ 高峰期存在资源争抢 迁移后: 内存使用率约40%~60% 资源冗余空间明显提升 这带来的变化不是“更快”,而是: 更稳、更有余量 3、平台架构变化 迁移前: vSAN + iSCSI双存储体系 存储路径分散 网络链路复杂 迁移后: 单一HCI架构 无外置存储依赖 存储与计算统一管理 变化的核心不是“减少设备”,而是:故障路径被明显缩短 4、运维侧变化 迁移前: 存储问题需要分别排查vSAN与iSCSI 网络与存储链路需逐层确认 磁盘更换操作频繁 迁移后: 存储统一在HCI平面处理 故障定位路径更直接 外置链路消失 整体变化可以总结为: 从“经验驱动运维” → “结构驱动运维” 七、项目价值总结 1、架构层面 完成从“多套系统叠加”到“单一平台”的收敛。减少了: 多存储体系并存 多路径依赖 系统结构变得更简单,也更可控。 2、稳定性 这次改造没有追求极限性能,而是优先解决不确定性: 老旧硬件风险被消除 磁盘频繁更换问题不再出现 历史隐患(PSOD)不再影响当前环境 3、成本与资源 本次没有做“全量替换”,而是只迁移核心业务(约7TB)这样做的实际效果是: 避免一次性资源投入过高 原平台压力得到缓解 新平台资源使用更集中 资源使用变得更“有针对性”,而不是平均分配。 4、迁移模型价值双路径迁移模型在这次项目中起到了实际作用: 纳管迁移 → 提升整体效率 SCMT → 处理异常情况 相比单一方案: 容错空间更大 迁移节奏更可控 这个模型在多业务环境中是可复用的。 八、项目复盘 1、双路径迁移模型更适用于复杂环境 在虚机数量多、系统类型复杂的场景中: 不确定性来自多个维度(驱动、系统、存储) 单一迁移方式很难覆盖所有情况 双路径设计的价值在于: 出现问题时,不需要“卡住”,可以直接切换路径继续推进 2、分批迁移是风险控制核心 这次没有追求效率,而是优先控制风险: 每一批迁移都单独验证 每一步都可回退 这样做的结果是: 没有出现集中性问题 节奏始终可控 3、文件服务器比想象中更“敏感” 在这个项目中,一个比较深的体会是:文件服务器往往比数据库更容易引发用户反馈问题。原因在于: 用户直接感知 操作频繁 对延迟敏感 迁移这类业务时: 需要更关注“体验”,而不是只看监控 4、一个比较深的体会这次项目回头看,关键并不在“完成迁移”。真正起作用的是三点: 把复杂过程拆开 每一步都能验证 出现问题可以回退 在不确定因素较多的环境里,这种方式更容易落地,也更容易控制风险。