#信服智创#【项目案例】某会计行业VMware替换实战:双路径迁移模型下的70+虚拟机平滑迁移与架构收敛
  

小懒 1101人觉得有帮助

{{ttag.title}}
本帖最后由 小懒 于 2026-3-27 16:39 编辑

目录:
一、项目背景        
   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、一个比较深的体会
这次项目回头看,关键并不在“完成迁移”。
真正起作用的是三点:
  • 把复杂过程拆开
  • 每一步都能验证
  • 出现问题可以回退

在不确定因素较多的环境里,这种方式更容易落地,也更容易控制风险。


打赏鼓励作者,期待更多好文!

打赏
1人已打赏

陈璨 发表于 2026-3-30 16:32
  
继续排查vmtools安装日志,发现报错:
Error: copy file success but the file is not the same! Please retry.
Install Update module failed!

请问这个vmtools安装日志的排查过程,是参考的哪篇文档呢?还请不吝赐教
发表新帖
热门标签
全部标签>
有一说一
GIF动图学习
新版本体验
每日一问
纪元平台
信服课堂视频
功能体验
安装部署配置
高手请过招
【 社区to talk】
安全效果
每周精选
2025年技术争霸赛
解决方案
标准化排查
社区新周刊
问题分析处理
产品连连看
畅聊IT
答题自测
专家问答
技术笔记
技术圆桌
在线直播
MVP
网络基础知识
升级
安全攻防
上网策略
测试报告
日志审计
流量管理
每日一记
运维工具
用户认证
原创分享
sangfor周刊
VPN 对接
项目案例
SANGFOR资讯
专家分享
技术顾问
信服故事
SDP百科
功能咨询
终端接入
授权
设备维护
资源访问
地址转换
虚拟机
存储
迁移
排障笔记本
产品预警公告
玩转零信任
S豆商城资讯
技术争霸赛
「智能机器人」
追光者计划
2023技术争霸赛专题
卧龙计划
华北区拉练
天逸直播
以战代练
秒懂零信任
技术晨报
平台使用
技术盲盒
山东区技术晨报
文档捉虫
齐鲁TV
华北区交付直播
2024年技术争霸赛
北京区每日一练
场景专题
故障笔记
排障那些事
西北区每日一问
升级&主动服务
高频问题集锦
POC测试案例
全能先锋系列
云化安全能力
专家说
热门活动
产品动态
行业实践
产品解析
关键解决方案
声音值千金
工具体验官
产品知识周周练
产品体验官

本版版主

207
402
1043

发帖

粉丝

关注

8
18
28

发帖

粉丝

关注

12
11
1

发帖

粉丝

关注

本版达人

皮皮虾·真

本周建议达人

郑州网络

本周分享达人

二进制网络

本周提问达人