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