7 台老旧物理机整合到 3 节点 ESXi 集群
一家东莞的五金制造企业，把分散在车间与办公楼的 7 台旧服务器收敛成 3 节点虚拟化集群，机房从 2 个减到 1 个
内容说明：为避免泄露客户信息，本案例未标注企业名称、联系人与合同金额。行业、规模、配置与效果数据来自我方交付记录，用于说明选型思路，不构成对具体项目的效果承诺。
项目背景
接到需求时，客户的原话是「服务器太老了，想换新的」。但直接 1:1 换 7 台新机器，既浪费预算，也没有解决真正的问题：7 台设备分在车间配电房和办公楼两处，车间那边粉尘大、夏天温度高、没人巡检，硬盘和电源故障过好几次，每次都要停一条产线的报工。
我们先做了一轮资源盘点，把 7 台机器近 30 天的 CPU、内存、磁盘 IO 峰值拉出来。结论很直接：7 台机器的 CPU 平均利用率都在 8% 以下，内存峰值最紧张的一台用到 62%，磁盘 IO 只有数据库那台有明显压力。也就是说，7 台机器的算力总量绰绰有余，缺的是冗余和集中管理。
虚拟化的价值在这里不是「新技术」，而是把 7 份硬件冗余合并成 3 份节点冗余：任何一台节点故障，虚拟机自动在其他节点重启，不再有「一台机器坏了、一个业务停一天」的情况。同时把车间机房撤掉，减少一个无人值守的故障点。
约束条件
选型不是「挑最好的」，而是在这些约束下找可行解：
- ERP 数据库是 SQL Server，对内存和磁盘 IO 敏感，迁移窗口只能放在周末
- 车间配电房夏季实测温度超过 38℃，不适合继续放服务器，必须迁出
- 客户 IT 只有 1 个人兼管，方案必须能被他独立维护，不能引入复杂运维栈
- 预算按 3 年折旧核算，要求在 3 年内不因容量不足再次采购
- 必须支持后续原地扩容，不接受「换整机才能升级」的方案
最终配置
下表为实际交付的配置与对应的选型理由，可对照自己的场景看哪些项需要调整。
| 部件 | 选型 | 选型理由 |
|---|---|---|
| 节点数量 | 3 台 2U 双路机架式服务器 | 3 节点可承受 1 台故障仍保留全部虚拟机运行（N+1），2 节点无冗余，4 节点超出需求 |
| 处理器 | 单节点双路 16 核 32 线程 | 按 14 台虚拟机的 vCPU 总量 44 核规划，单节点 32 线程折算后余量约 2.2 倍 |
| 内存 | 单节点 256GB ECC，集群共 768GB | 虚拟化最稀缺的资源是内存。当前虚拟机内存分配合计 320GB，余量支持后续增加到 20+ 台虚拟机 |
| 系统盘 | 单节点 2 × 480GB 企业级 SSD，RAID 1 | ESXi 系统盘独立，避免与数据盘争 IO，且可整盘替换 |
| 数据盘 | 单节点 4 × 1.92TB 企业级 SSD，RAID 10 | ERP 数据库的 IOPS 需求靠 SSD 满足，RAID 10 兼顾写性能与冗余 |
| 阵列卡 | 硬件 RAID 卡，带 2GB 缓存与掉电保护 | 写缓存对数据库事务延迟影响明显，掉电保护避免异常断电丢数据 |
| 网络 | 单节点 4 口千兆 + 2 口万兆，万兆用于存储与 vMotion | vMotion 迁移一台 64GB 内存的虚拟机，千兆约需 12 分钟，万兆约 1.5 分钟 |
| 电源 | 800W 冗余电源（1+1） | 单节点功耗实测约 380W，冗余电源应对单路故障 |
| 管理 | 独立 IPMI 口 + vCenter 单点管理 | 带外管理可远程装机、看硬件日志，IT 一人可维护 |
被放弃的方案
比「选了什么」更有参考价值的是「为什么没选别的」。以下方案都曾进入备选：
原样 1:1 更换 7 台物理机
预算接近虚拟化方案的两倍，机房仍是 2 个，无人值守的故障点没消除
2 节点集群 + 共享存储
2 节点无法承受单点故障后继续运行全部业务；独立共享存储又增加一个高成本单点
超融合一体机
软件授权与硬件绑定，3 节点起步价明显高于通用服务器 + 免费/已有授权的方案，对 14 台虚拟机的规模属于过度设计
交付效果
| 指标 | 改造前 | 交付后 |
|---|---|---|
| 机房数量 | 2 个（车间配电房 + 办公楼） | 1 个（办公楼机房），车间机房撤除 |
| 单点故障影响 | 任一物理机故障即有一个业务中断，恢复以天计 | 任一节点故障，虚拟机自动重启，中断以分钟计 |
| 运维方式 | 7 台分别登录，无统一监控 | 1 个 vCenter 控制台，资源与告警集中查看 |
| 资源利用率 | 7 台平均 CPU 利用率 8%，大量闲置 | 集群 CPU 平均利用率约 26%，内存约 42%，仍有余量 |
| 机房环境 | 车间夏季 38℃+，粉尘，无巡检 | 办公楼机房恒温 24℃，有温湿度告警 |
交付过程
-
D+0
现场盘点 7 台物理机的型号、年限、业务归属与资源占用
-
D+3
导出近 30 天性能数据，给出集群规模测算与两套方案对比
-
D+5
确认 3 节点方案，核对办公楼机房供电、承重与网络
-
D+9
集群到货上架，配置 vSphere 集群、HA 与 vMotion，做节点故障演练
-
D+12
第一个周末迁移非核心业务（文件共享、监控回放、OA）
-
D+15
第二个周末迁移 ERP 数据库与域控，旧机保留 7 天可回退
-
D+16
确认业务正常，旧机下架，车间机房设备清运
复盘：三条可复用的判断
- 「服务器太老了想换新」通常不是采购问题，是架构问题。先盘资源，再谈买几台。
- 虚拟化的瓶颈永远是内存，不是 CPU。按 vCPU 数买机器，最后一定会内存不足。
- 迁移窗口要按业务重要性排序，核心数据库单独一个周末，不要一次性全切。
同类项目的常见问题
关键看资源规划是否基于实测数据。这个案例里 14 台虚拟机的内存分配合计 320GB，集群 768GB，余量超过一倍；CPU 按 32 线程折算后余量约 2.2 倍。真正的风险不是总量不够，而是某台虚拟机被分配了过多资源导致争抢，所以规划时要设上限而不是无限分配。
主要是网卡、阵列卡和硬盘背板。VMware 有官方兼容性列表，不在列表内的网卡可能认不到或驱动不稳定，阵列卡可能无法被识别。选型时必须逐项核对，尤其是客户自采配件的情况。这个案例的三节点用的都是列表内的部件。
常用两种：一是虚拟机级快照与备份软件，按虚拟机整体备份，恢复快；二是在虚拟机内装传统备份代理，灵活性高但恢复慢。中小企业建议虚拟机级备份为主，至少保留 7 天，并每季度做一次恢复演练——只备份不演练，等于没有备份。