H3C UIS 超融合架构深度剖析：从原理到企业落地实践

第一次听超融合的介绍，最打动人的那句通常是"把计算和存储融到一台机器里，简化运维"。这句话本身没错，但它描述的其实不是收益，是采购形态的变化。

真正需要判断的是：这个变化在什么场景下是赚的，在什么场景下是把风险藏起来了。这篇按这个顺序讲。

#一、合并的到底是哪一层

先把传统三层架构和超融合摆在一起看：

最后一格是整篇的核心。三层架构里，你的风险是"控制器的可靠性"——一个看得见、有冗余、可更换的部件。超融合里，你的风险是"一次故障之后，集群要花多久回到冗余状态"——一个看不见、没有硬件规格、只能靠设计决定的数字。

这就是它最容易被包装的地方：从"消除单点"到"把单点换成一段时间"，是工程实现；而"这段时间可以接受"，是价值选择。前者厂商可以给你保证，后者只能你自己签字。

#二、分布式存储是心脏，也是唯一的软肋

超融合节点的本地盘不再是"服务器附带的空间"，而是被组成了一个分布式存储池。逻辑和 Ceph 那套是同一族：数据切分、多副本（或纠删码）分布到不同节点、故障时自动重建。

于是所有分布式存储的老问题一个不少地跟了过来：

• 副本数与可用容量是三次方关系（三副本 → 可用容量约为裸容量的 1/3，还要留出重建余量）。
• 重建是网络密集型的。重建一份 1TB 的数据，瓶颈通常不是盘的写入速度，而是节点间带宽。
• 重建期间冗余度下降。三副本退化成两副本的那几个小时，是集群最脆弱的窗口。

在超融合里，这几个问题比在专用存储上更难处理，因为重建流量和业务流量跑在同一张网络上。这就是为什么超融合部署几乎都建议把东西向流量单独拉一张网络：

如果只能记一条：东西向网络的容量要按"最坏情况下同时重建几条流"来算，而不是按常态流量。按常态规划的网络，在故障当天会成为恢复速度的实际天花板。

#三、扩容：最小单位决定了你的成本曲线

超融合的成本曲线有一条很具体的形状：它以节点为台阶，而不是以线性的方式增长。

这带来两个必须提前想清的问题：

1. "最小可用集群"和"最小扩容单位"之间往往有空隙。 三节点起步的集群，当你需要 20% 的容量时，可能只能选择加一个节点（>30%）。多出来的部分是沉没成本。
2. 计算和存储被迫同比扩张。 如果瓶颈只在存储（典型的如日志、归档、视频这类），你仍要买来同样比例的 CPU 和内存。反过来，如果瓶颈只在计算，你也顺带买了一堆盘。

所以选型时真正该问的不是"它能不能扩"，而是：

未来 3 年，我的瓶颈会出现在哪一侧？
  两侧大致同步增长（虚拟化整合、通用业务）  → 超融合的曲线是合适的
  只有一侧增长（纯存储型/纯计算型负载）      → 台阶会被浪费，考虑存算分离
  增长不可预测                              → 台阶的代价要靠"弹性"抵回来，评估是否值得

这类判断没有标准答案，但有没有问过，决定了三年后的预算是一次还是两次。

顺便说一个容易踩的点：不同厂商对"异构节点能不能混进同一集群"的宽容度差别很大。混节点之前务必确认官方支持列表，而不是"技术上能起来"——技术上能起来的东西，出问题时往往是"不在支持范围"。

#四、把"能同时坏几台"写成预算

超融合集群的可用性，本质是一个减法问题：给定副本数，你允许自己同时动几台机器。

日常维护（换盘、升级固件、扩容节点）时，"先关一台"这个动作必须和这个表格对齐。运维上更可靠的做法是把它制度化：

# 无论用什么平台，维护前先确认三件事：
# 1) 集群健康状态是否全绿（不是"看起来正常"）
# 2) 上一次重建是否已经结束（不要在上一次没跑完时开第二次）
# 3) 变更窗口内有没有其它计划内变更重叠

第三条经常被忽略：多个"各自安全"的变更叠加起来，可能刚好越过不可用的门槛。 变更日历的价值就在这里，它管的不是单次变更的技术风险，是叠加风险。

#五、什么时候不该上超融合

这部分是这篇最想写清楚的地方。超融合是很好的形态，但它不是"更先进的架构"：

• 单机/小规模场景：三节点起步、最小扩容一个节点的曲线，在小规模下明显偏贵。
• 性能极端分化：需要亚毫秒稳定延迟的数据库核心库、或者需要极致顺序带宽的场景，专门的块存储/全闪阵列仍有结构性优势。
• 已有成熟集中存储且利用率健康：把好用的存储换掉，通常换不来收益，只换来一次迁移风险。
• 合规要求物理隔离环境：分布式存储的"数据在多台机器上"这一事实，有时需要额外解释成本。

反过来说，超融合真正擅长的场景也很清楚：虚拟化整合、分支/边缘、快速增长且瓶颈同步的业务、以及缺少专职存储运维团队的组织。最后一条常被低估——超融合省下的不只是机柜，还有"谁来管存储"这个组织和技能的负担。

#六、落地前值得逐条确认的事

不写检查清单的话，这类文章容易变成观点输出。下面是我认为签合同前该逐条问清、且必须落到纸面的项目：

1. 单节点故障时，剩余节点能否承载业务峰值（不是均值）。这决定了你的 N+1 是真冗余还是纸面冗余。
2. 重建速率：官方数据是多少、在什么条件下达到、你的网络能不能喂饱它。
3. 扩容的粒度与混节点策略：写在支持列表里的，才算数。
4. 故障域配置能力：机架感知、反亲和规则能不能自己配，还是写死。
5. 升级路径：大版本升级是否需要停机、能不能滚动。
6. 退出成本：数据怎么整体迁出、有没有被绑定（这一点几乎没人问，但它决定了三年后的议价能力）。

#七、这篇没写什么

• 没写具体产品的界面与配置步骤。 每个版本都不一样，抄一遍很快就会过期，而且误导性比帮助大。请以你手上的版本手册为准。
• 没写性能对比数字。 这类数字高度依赖盘型、网络、副本策略和负载形态，任何脱离场景的"IOPS 对比"都不值得引用。
• 没给出选型结论。 上面那些问题问完，答案通常是自己浮现的；我替读者下结论只会遮住这个浮现过程。
• 没写备份。 超融合的高可用不等于备份——副本防的是硬件故障，防不了误删和勒索。这是另一篇。

一句话收束：超融合把"单点"从一个部件换成了一段时间。买它之前先把这段时间量出来，比看任何一张架构图都有用。