100TB 只能用三十几 TB？超融合采购前先算清

超融合的方案汇报通常很顺利。架构图清晰，能力覆盖完整，演示流畅，报价在预算内。签字之前没人觉得有问题。

问题出在交付之后：买的 100TB 实际只能用三十几 TB；网络成了瓶颈但监控上看磁盘很闲；一块盘坏了重建跑了两天，期间业务一直在抖；第二年要加一台机器，发现必须按三台一组扩；三年后算总账，发现软件报价只占总投入的一小部分。

这五件事都不是产品缺陷，是采购阶段没有把数字算清楚。

这篇分三部分：先看三条采购路线怎么选，再算五个必须算清的数字，最后给中小企业适用的超融合一体机型号配置对照表。

一、三条采购路线：先定形态，再谈配置

同样是上超融合，落到采购上有三条路，代价形态完全不同。

公开资料说明：VMware 部分参考 Broadcom 官方 TechDocs 的 VCF 9.0 授权文档；数据查证于 2026 年 8 月，条款以 Broadcom 官方最新文档为准。

第三列的授权计量值得单独算一遍。如果你的服务器是 2 路 12 核，按每 CPU 最低 16 核计，实际按 32 核计费而不是 24 核。中小企业的存量服务器核数普遍偏低，这个差额比例反而更大。

同理，vSAN 容量按核附赠这一点，对容量型业务（备份、归档、影像、监控录像）不利——需要的 TiB 远多于算力时，超出部分要另买。

判断依据是你的组织条件，不是产品参数。有硬件、有渠道就买软件；新建站点、人手紧张就买一体机。

二、五个必算的数字

数字一：可用容量

算法：三副本的可用容量约为裸容量的 30% 左右。理论值是三分之一，实际还要再扣元数据开销、快照预留空间、长期运行后的碎片。

三档算例：

最后一列按预留 10–20% 增长空间估算。生产环境不建议用满，容量水位过高会影响重建速度与稳态性能。

会踩的坑：报价口径不统一。有的厂商方案里写裸容量，有的写可用容量。两家报价放在一起比，如果口径不同，差异可能不是产品差异而是算法差异。

签字前问：报价单上的容量是裸容量还是三副本后的可用容量？快照和备份占用是否已计入？如果部分业务用纠删码，具体是哪几个业务、什么冗余策略？

数字二：网络带宽

机制：三副本意味着每次写入都要同步复制到另外两个节点，存储流量在节点之间往返，占用的是业务网络之外的额外带宽。原来走 SAN 光纤的存储流量，现在挪到了以太网上。

万兆是分布式存储的实用下限。千兆链路在这种写入放大效应下，会先于磁盘成为瓶颈。

典型现象：磁盘监控看着很闲——每个节点 IO 使用率不到三成，业务却在报慢。排查时如果只盯存储监控，这个瓶颈看不见，问题在节点之间的链路上。

档位判断：

签字前问：存储网络和业务网络是否物理隔离？现有交换机能否直接使用？如果上 RoCE，无损配置由谁调试、出问题找谁？25G 相比万兆的成本增量是多少？

数字三：重建时间

这是五个数字里最少被问、风险最集中的一个。

两个成本：重建流量占用网络和磁盘 IO，影响前台业务；重建完成之前系统处于降级状态，此时再发生一次故障，风险明显上升。

一对矛盾：重建跑得越快恢复冗余越早，但对前台业务影响越大；限速可以保护业务，但降级窗口被拉长。这个平衡点没有标准答案，取决于你的业务能承受什么，但必须在采购阶段讨论清楚，而不是第一次故障时现场调参数。

签字前问：按我的数据量和网络配置，单节点故障后重建需要多久？重建期间前台业务性能影响有多大，有没有实测数据？能否限速，限速后重建时间变成多少？重建期间再发生一次故障会怎样？

数字四：扩容步长

定义：最小能加几个节点。有的方案支持单节点扩容，有的必须按组扩（比如三台一组）。这个差别直接影响资金节奏——只需要多 30% 算力却必须一次加三台，多出来的部分在闲置期同样消耗电力、机柜空间和维保。

三个坑：

● “一次买够”是最常见的过度采购。合理做法是按当前需求加一年增长量采购，把扩容路径写进合同。

● 扩容时价格没锁定。首批采购谈得好，两年后加节点按当时报价走，可能完全不同。

● 跨档扩容需要换平台。这一条最麻烦——如果从入门规模扩到更大规模时需要更换存储方案或重新迁移数据，那么入门配置的低价就是有代价的。

签字前问：最小扩容单位是几个节点？扩容需要停机吗，停多久？后续节点价格能否在合同里锁定、锁定期多长？从当前规模扩到三倍规模，中间需不需要换平台、换存储方案、重新迁移数据？

数字五：三到五年总账

六块成本：软件授权、硬件（服务器与存储介质）、网络设备（交换机/网卡/线缆）、实施服务、培训、三到五年维保。

三个坑：

● 软件报价低但硬件绑定。如果方案要求特定品牌或型号服务器，软件省下的钱可能在硬件上补回去。

● 维保计算方式不同。有的按硬件原值百分比，有的按固定金额，有的前三年包含、第四年起单独计。三年和五年的总账可能排序不同。

● 培训和实施是否包含没写清楚。这两项工作量不小，合同里不明确容易变成额外支出或干脆没人做。

签字前问：要求所有候选方案按统一口径给三年和五年总成本，标注哪些是一次性、哪些是年费；硬件是否绑定特定品牌，能否自采或利旧；培训覆盖几人、多长时间、是否包含在合同内；维保计费方式与续保价格如何确定。

三、中小企业适用的超融合一体机型号：三档配置对照

规模决定档位。三档的存储、网络、数据保护配置是成套的，不建议跨档混搭。

为什么是 3 节点起：分布式存储需要至少三个数据副本分布在不同节点，才能在单节点故障时既不丢数据也不中断服务。两节点方案在仲裁机制上要额外做文章，且扩容路径不顺——如果规划里三年内会加节点，直接从 3 节点起步更省事。

成长档的分水岭在数据保护：三副本解决硬件故障，快照解决误操作，CDP 解决逻辑损坏（勒索软件、应用写坏数据）。这是三个独立问题，一个方案盖不住。业务里有数据库的，成长档往上的配置基本是必需的。

扩容参照档不是给中小企业当下采购用的，列出来只有一个目的：验证扩容路径通不通。如果从入门档走到成长档、再到这一档，任一环节需要推倒重来，那么入门档的低价就是有代价的。

说明：以上为典型配置区间，实际方案需结合业务负载特征、机房条件与预算综合确定，具体型号与配置清单以最新产品资料为准。

四、ZStack 在这三条路线上的具体交付

具体到不同套件版本的授权包含范围，选型时应要求书面列明。

五、需要如实说明的几点

每条配一个核实动作。

一、入门档配置的性能上限是存在的。 万兆网络加混闪存储的组合，在高并发数据库场景下会成为瓶颈。核实方法：把你负载最重的那个业务系统单独拿出来做 POC，不要用厂商的标准测试用例。

二、超融合不适合所有场景。 如果业务是单一的高性能数据库、且没有虚拟化诉求，物理机加集中式存储可能仍是更直接的方案。超融合的价值在多种负载的统一承载与运维收敛，负载单一时这个价值会打折扣。核实方法：把现有业务按类型列一遍，看统一承载能收敛掉多少套独立系统。

三、我们在超大规模生产环境的公开案例少于部分老牌厂商。 中小规模场景积累充分，但如果环境属于数百节点以上量级，核实方法：要求提供同量级的可核实案例并做现场走访。

四、地市级服务网点密度仍在建设中。 主要一二线城市有覆盖，下沉城市与经营多年的国际厂商和头部硬件厂商相比还有差距。核实方法：要求提供你所在城市的工程师名单与响应时效书面承诺。这条建议对所有候选厂商一视同仁地执行。

五、换平台是有成本的。 迁移工作量、运维团队学习曲线、业务割接窗口影响都真实存在。任何声称可以无感切换的说法，都值得追问具体的实施口径。

六、小结

选中小企业适用的超融合一体机型号，绕不开三个判断：

● 先定采购路线。有硬件有渠道就买软件，新建站点人手紧张就买一体机；如果在评估商业闭源方案，把每 CPU 最低计费核数和容量与核数绑定这两笔账单独算一遍。

● 再算五个数字。可用容量按 30% 出头估、万兆是网络下限、重建时间最少被问却最该问、扩容步长决定资金节奏、三到五年总账才是真实投入。

● 最后按规模定档位。三档的存储、网络、数据保护是成套的，跨档混搭会在某一环节形成短板。

五个数字都问清楚了，再谈架构和功能。顺序反了，谈得再细也没用。

● 产品能力与配置数据来自 ZStack 官方产品资料；实际方案需结合业务负载与机房条件确定，具体配置清单以最新产品资料为准。

● 涉及 VMware 的授权条款引自 Broadcom 官方 TechDocs 公开文档，查证于 2026 年 8 月；此类条款更新较快，采购决策前请以 Broadcom 官方最新文档为准。

● 容量算例为按通用系数估算的参考值，实际可用容量以现场规划与实测为准。

● 本文为选型方法参考，不构成采购结论；具体能力与性能表现以现场 POC 实测为准。