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

超融合（Hyper-Converged Infrastructure，HCI）要解决的问题，是把传统数据中心里分属三套设备的能力——计算、存储、网络——装进同一批 x86 服务器节点，用软件把这些节点组织成一台"横向扩展的分布式主机"。它背后最基础的事实是：每个节点的本地盘不再是"这台服务器附带的空间"，而是被聚合成一个跨节点的分布式存储池；同一份数据通过多副本或纠删码分散保存在不同节点上，任何一个节点宕机，数据都能从其余副本读出；虚拟机的计算运行在某个节点的 CPU 与内存上，虚拟网络决定流量在节点之间如何转发。理解了这三条机制，后面关于可靠性、扩容、运维的绝大多数结论都能直接推出来，而不是靠背产品特性。

"把计算和存储融到一台机器里，简化运维"——第一次听超融合的介绍，最打动人的通常是这句话。这句话本身没错，但它描述的其实是采购形态的变化，不是收益。真正需要判断的是：这个变化在什么场景下是赚的，在什么场景下是把风险藏起来了。这篇文章按"合并的是哪一层 → 分布式存储如何保证可靠 → 为什么扩容必须同步加节点 → 怎么部署、验证与排障 → 什么时候不该用它"的因果链展开。

#一、合并的到底是哪一层：底层事实与采购形态的错位

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

要读懂这张表，得先分清两个不同层面的"合并"。

第一层合并是数据路径的合并。传统架构里，虚拟机（VM）读写数据要穿过完整的"服务器 → HBA/网卡 → FC/iSCSI 存储网络 → 存储控制器 → 盘柜"路径；超融合里，这条路径被压缩成"虚拟机 → 节点本地盘/对端节点的网络"，存储逻辑以软件形式跑在每个节点上。这是延迟改善的来源，也是"为什么不需要专用存储网络"的原因。

第二层合并是生命周期与采购的合并。传统架构里，服务器、存储阵列、存储交换机是三套生命周期：各自升级、各自扩容、各自维护。超融合把它们绑成一套——同一个节点同时承担计算与存储，扩容的最小单位从"一个盘柜/一对控制器"变成"一整台节点"。这带来运维上的简化，也带来成本曲线上的台阶，第三节专门展开。

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

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

#二、原理层：同一批 x86 节点如何同时完成计算、存储、网络三类虚拟化

超融合不是"换个机箱装三样东西"，而是把三类虚拟化软件装进同一批节点，让它们共享同一批硬件资源。理解它，需要分别看这三类虚拟化各自靠什么机制工作，再看它们如何互相影响。

#计算虚拟化：把"一台 x86"变成"N 个逻辑主机"

计算虚拟化的底层事实是：现代 CPU 的虚拟化扩展（Intel VT-x / AMD-V）允许虚拟机里的指令直接跑在物理 CPU 上，而不是被软件逐条翻译模拟。Hypervisor（虚拟机监视器）负责两件事：一是调度——决定哪个 vCPU 在哪个物理核上运行、运行多久；二是隔离——通过内存二级地址转换（Intel EPT / AMD NPT）让每个虚拟机看到独立的、受控的物理内存映射，一个虚拟机无法读写另一个虚拟机的内存。

由此可以推出超融合的第一组行为特征：

• 计算资源天然是"节点内分配"的。一台物理节点能跑几十台虚拟机，数量只受节点的 CPU 核数、内存容量和 IO 能力约束。当你给集群加一台节点，等于让"可调度 CPU/内存总量"上升一个台阶。
• 内存超分配是一种设计选择。虚拟化平台通常允许"承诺给虚拟机的内存总和"超过物理内存总量，靠的是虚拟机的实际占用通常低于承诺值。超融合里这很常见，但它直接连着故障行为：如果一台节点故障，剩下节点的物理内存必须能容纳故障节点上所有虚拟机（连同它们的真实内存占用），否则 HA 迁移根本落不了地——落在"物理内存不够"上的迁移，会一直失败重试，等价于把故障窗口无限拉长。
• 热迁移必须走节点间网络。虚拟机从节点 A 迁到节点 B 的机制是：先把内存页迭代拷贝到目标节点，最后一轮短暂停机把剩余改动同步过去，再切换执行。这个过程产生的流量全部是东西向的。这就是为什么后面那张网络表里，"迁移"和"重建"被归到同一类流量上——它们共享同一张网络和同一种带宽预算。

#分布式存储：数据如何切分、寻址、保持一致与重建

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

切分与寻址。 数据被切成固定大小的对象/块（典型如 4MB 量级的粒度），每个对象通过一致性哈希类算法（如 Ceph 的 CRUSH）确定它应该落在哪些节点的哪些盘上。寻址不需要查一个集中的"文件在哪"的表格，而是把对象 ID 代入哈希函数直接算出位置——这一条是后面"控制平面故障时数据仍可用"的机制基础：读写的目标位置是算出来的，不是问出来的。

副本与纠删码。 写一份数据时，集群按策略写多个拷贝到不同节点：

• 三副本：同一份数据写三份到三个不同节点，任何一台节点故障，剩余两份仍完整。
• 纠删码（Erasure Coding，EC）：把一份数据切成 k 份数据块 + m 份校验块（记作 k+m），分散到 k+m 个节点；任意丢失 m 块，都能用剩余块把数据算回来。例如 4+2 配置下，空间利用率约 2/3（四份数据只额外配两份校验），比三副本的 1/3 显著省空间；代价是读写要承担编解码的计算开销，重建时每恢复一块丢失的数据要读出 k 块来重算，网络放大效应比副本更明显。

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

• 副本数与可用容量是倒数关系（三副本 → 可用容量约为裸容量的 1/3，还要留出重建余量）。"三次方关系"是口语化的强调：副本数从 2 到 3，可用容量就除以 3；换纠删码策略，容量账要按 k/(k+m) 重新算。
• 重建是网络密集型的。重建一份 1TB 的数据，瓶颈通常不是盘的写入速度，而是节点间带宽——数据要从存活节点通过网络发到新目标节点。
• 重建期间冗余度下降。三副本退化成两副本的那几个小时，是集群最脆弱的窗口。

写路径的一致性。 多副本写入时，分布式存储通常采用"达到法定多数（quorum）即返回成功"的模型：三副本写两份成功即可确认，这样即使有节点暂时失联，读写仍能继续。这个模型的直接后果是：你必须把"允许同时坏几台"当成容量之外的另一个预算来管理——三副本意味着"最多同时坏 1 台，且不建议长时间维持"，这对应第六节的表格。

为什么三节点是最常见的起步规模。 多数选举机制可以推出一个很具体的结论：quorum 需要"超过一半"的节点在线才能选出主、才能做写入确认。三节点集群坏 1 台还剩 2/3，多数仍在，可以继续工作；两节点集群坏 1 台只剩 1/2，不再有严格多数，退化为只读或不可写。所以"三节点起步"不是商务惯例，是分布式共识在最小故障容错下的必然选择。这也顺便解释了为什么"再小也要三台":两台机器加一块共享盘，本质上还是传统双控那套，不是超融合的分布式语义。

故障域与反亲和：副本放在哪里，比放几份更重要。 副本必须落在"不会同时故障"的实体上，这个实体叫故障域（failure domain）：最小是节点，往上是机架、机房。如果集群不做故障域感知（常见说法是没配反亲和规则），调度器可能把两个副本放在同一台物理机上——这台机器一坏，两个副本一起没，三副本实际退化成两副本甚至一副本。这是"副本数"表格里"三副本 + 反亲和性 = 1 台且必须跨故障域"一行的机制解释。

控制平面与数据平面：故障时的可用性边界。 理解超融合故障行为，最关键的分界是控制面与数据面的分离：

• 数据平面：虚拟机与存储之间的实际 IO 路径。对象的位置由哈希直接算出，IO 直接打到目标节点，不经过任何单一管理入口。
• 控制平面：集群管理、配置下发、卷创建/删除、重建调度、虚拟机迁移、扩缩容等"改变系统状态"的操作。它通常由集群中的一组高可用管理服务承担，管理自身的元数据也带副本，靠多数选举选主。

由此推出控制平面故障时的可用性边界：

• 已建立的 IO（数据面）通常不受影响：正在跑的虚拟机继续读写，因为读写不需要每次去问管理服务"数据在哪"。
• 依赖控制面的操作不可用：新建卷、创建/迁移虚拟机、扩容、故障后的重建调度会暂停，直到控制面恢复。
• 控制面恢复后数据仍一致：控制面管理的是"状态变更"，数据本身有冗余；只要多数管理节点还在，集群会选出新主并继续。

需要说明的是，这是分布式系统控制面/数据面分离的通用机制推导；具体产品在多大程度上让"控制面不可用"与"数据面可用"解耦，实现细节以官方文档和实际故障演练为准。这也是为什么可靠的落地实践都要求：把"管理节点/控制面挂掉一台"纳入故障演练清单，而不是只在虚拟机上做高可用测试——后者验证的是应用层的 HA，前者验证的是整个集群还能不能自我管理。

#网络虚拟化：东西向与南北向流量如何共处

虚拟网络要解决的底层问题，是让"虚拟机之间"和"虚拟机对外"的流量在物理网卡上正确转发与隔离。超融合里至少有两类流量在节点间流动：

• 南北向流量：虚拟机对外提供服务（业务网）。
• 东西向流量：分布式存储的副本写入、故障重建、虚拟机热迁移——这些全是节点之间的横向流量。

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

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

#三、从机制推导：为什么扩容必须计算与存储同步加节点

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

这个形状不是商务策略，而是前面两条机制的必然推论：分布式存储的容量分布在所有节点的本地盘上，计算能力也分布在同一批节点的 CPU/内存上，而"一台节点"是两者的最小共同单位。存储池要增加容量，唯一的办法是把新节点（以及它身上的盘）纳入池；计算池要增加算力，唯一的办法也是加新节点。两者共享同一个载体，所以任何一侧的扩容都必然带上另一侧——这就是"计算与存储必须同步加节点"的根本原因：物理上它们无法分开买，架构上它们共享生命周期。

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

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

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

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

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

顺便说一个容易踩的点：不同厂商对"异构节点能不能混进同一集群"的宽容度差别很大。混节点之前务必确认官方支持列表，而不是"技术上能起来"——技术上能起来的东西，出问题时往往是"不在支持范围"。支持列表通常约束的是：CPU 型号与代际、内存类型、盘型和容量区间、网卡与固件版本。混入不在列表的组合，短期看不出问题，长期在重建、热迁移、升级这些"需要整集群协同"的场景里暴露。

#四、操作层：架构组件、部署形态、扩展与运维路径

下面的内容以 H3C UIS 这类商用超融合产品为对象。本文写的是架构与流程层面的通用路径，具体界面入口、命令与参数每个版本都在变，落到操作时以你手上的版本手册为准——故意不写与版本绑定的点，正因为"抄一遍很快就会过期，而且误导性比帮助大"。

#架构组件：一个集群里有哪几类角色

从一个节点的视角看，超融合节点上同时运行着四类组件：

• 管理平面：集群的管理服务（部分产品称为"管理节点/控制节点"），负责配置下发、虚拟机全生命周期管理、存储卷管理、监控告警、升级与扩缩容。它自身由多数选举保证可用性，管理数据也带冗余。
• 计算平面：Hypervisor 与虚拟机调度，把 vCPU/内存分配给虚拟机，执行热迁移、HA 等动作。
• 存储平面：分布式存储服务。它认领本节点的本地盘，把盘加入存储池，对外提供块设备（卷），执行副本/纠删码的写入、读取与重建。
• 网络平面：分布式虚拟交换机与网络策略。它把虚拟机的虚拟网卡连到业务网/存储网，并实现租户隔离、限速等。

部署时最常见的形态是三节点起步：三台同构 x86 服务器，每台都装齐上述四类组件，管理角色在节点间形成高可用；之后通过加节点线性扩展。为什么要三台而不是两台，第二节已经从多数选举推过了：两节点在单节点故障后失去严格多数，不满足分布式共识的容错前提。

#部署形态与前置规划

一台新的 UIS 节点需要满足的基本前置条件（以官方兼容性列表为准）：CPU 支持硬件虚拟化扩展（Intel VT-x / AMD-V）并已在 BIOS 开启；内存容量按虚拟化密度规划，并且要额外考虑"单节点故障后邻居节点能否吞下它的内存"；本地盘至少区分系统盘与数据盘，数据盘容量决定该节点为存储池贡献多少裸容量；网卡按第二节的三网规划分配（业务网、存储/迁移网、管理网），东西向网建议万兆起步——这条建议的根据就是"重建速度的天花板是节点间带宽"。

存储池规划里最容易算错的是容量预算。以"裸容量 36TB、三副本"为例：

裸容量:              36 TB
三副本名义可用:      36 ÷ 3 = 12 TB
留出重建余量(约 20%): 12 × 0.8 ≈ 9.6 TB（建议按此值做容量水位告警）

重建余量的含义：当集群退化到两副本时，剩余可用空间要能让数据重建出第三份副本；如果容量已经打满，重建会因为"没有地方放新副本"而停滞，集群长时间停留在最脆弱的两副本状态。容量水位告警线因此要按"三副本 + 重建余量后"的可用来设，而不是按裸容量。

#扩展路径：加一个节点的标准流程

把"扩容"落到操作上，通用路径是：

1. 硬件与网络就绪：新节点安装与集群同版本或兼容版本的节点镜像，接入业务网、存储网、管理网。
2. 加入集群：在管理平台执行"添加节点"，新节点的计算资源与本地盘被纳管。
3. 数据再平衡：存储池按数据分布算法把部分数据迁移到新节点，使容量与负载趋于均匀。这一过程会占用东西向带宽，等价于一次主动发起的重建，要避开业务高峰，并留出重建余量。
4. 验证：确认新节点状态健康、容量生效、再平衡完成（验证方法见第五节）。
5. 投入使用：从管理平台把虚拟机迁移/分布到新节点，或让调度器自然利用新增资源。

注意第 3 步在运维上的含义：加节点本身就是一次"可控的重建"，它和节点故障后的重建共享同一张网络、同一种带宽预算。习惯上"扩容窗口内不看再平衡进度"的做法，会把一次安全操作变成风险事件——再平衡没跑完就接着做下一次变更，等于在脆弱窗口里又开了一个窗口。

#运维路径：维护前确认三件事

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

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

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

#五、验证层：怎么确认我做对了

超融合的验证分四个层面：集群健康、数据冗余、重建收敛、扩容生效。以下判定标准与产品无关，可以套用到任何同类平台；凡涉及具体视图/命令的，以版本手册为准。

1. 集群健康：状态全绿不是"看起来正常"。 进入管理平台的集群健康视图，逐项核对：所有节点在线、所有数据盘状态正常、存储池健康、无告警弹出。健康视图里任何"降级（degraded）""重建中（rebuilding）""离线"状态都要先处理，而不是忽略。一个常见误区是只看节点在线率——节点在线但某块盘故障，容量与冗余已经受损，健康视图会标红。

2. 数据冗余：副本/纠删片是否都在预期位置。 查看存储对象的副本分布，确认三副本落在三个不同节点（而不是因为没配反亲和而挤在一起）；若是纠删码，确认 k+m 分片分布在 k+m 个不同节点。这一步对应的是"允许同时坏几台"的预算是否真的成立。

3. 重建收敛：上一次重建是否已经结束。 在故障或扩容后，观察重建任务进度直到归零。判定标准是：重建任务列表为空、存储池不再处于降级状态、每个对象的副本数都回到满配。在重建完成前，不要再开第二次变更——这是第四节那条 bash 注释背后的可验证含义。

4. 扩容生效：容量、性能与再平衡。 添加节点后确认：存储池总容量按预期增加（新节点裸容量 × 可用比例）；数据再平衡任务开始并最终完成；新节点上的虚拟机可正常创建/迁移。值得做一次双侧重验：从"虚拟机内看到新卷并完成读写"（业务侧）和"存储池容量视图"（平台侧）各确认一次，防止只在管理界面看到数字。

5. 网络验证：东西向带宽是否成为恢复速度的天花板。 在测试窗口内模拟一次节点故障（若有测试集群），记录重建速率；与东西向网络带宽对比，判断瓶颈在网络还是在盘。如果重建速率远低于盘的写入能力，先查网络：端口协商速率、交换机拥塞、是否有其他流量占用了存储网。判定的根本经验是一条瓶颈公式：重建速度 = min(源端读带宽, 网络带宽, 目标端写带宽)，三者里最小的一项就是你能观察到的速度，也是你优化时的第一优先级。

下面是一段示意性的健康检查输出（字段以实际平台为准），用来展示"该看什么"：

Cluster: uis-cluster-01            Status: HEALTHY
Nodes:   3/3 online                2 nodes degraded: none
Storage: pool health=OK            1 pool, 36 TB raw, 12 TB usable (3-replica)
Rebuild: no active jobs            last rebuild: completed 2025-12-05 21:14
Data:    0 objects degraded        0 objects misplaced

把"看到 HEALTHY"当作通过标准是危险的；上面这几行的判定顺序是：先看有没有 degraded 对象和重建任务，再看容量是否在预算内，最后才看总状态。任何一行非健康，都意味着"允许同时坏几台"的预算已被部分消耗。

#六、边界与坑：常见失败模式、排查与什么时候不该用

#可用性是一个减法问题

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

日常维护（换盘、升级固件、扩容节点）时，"先关一台"这个动作必须和这个表格对齐——第四节已经把"维护前确认三件事"制度化，这里再强调一次：表格里的"允许 1 台离线"不是让你把机器关一整天的许可，它默认的前提是重建在几小时内收敛、且期间不再发生第二次故障。

#常见失败模式与排查

失败模式 1：重建期间的二次故障。 三副本退化成一副本时，再坏一台，那部分数据即不可读。为什么？因为剩余节点可能不包含所有对象的第三份数据。排查思路：任何时候先问"当前冗余度是多少"——如果集群正处在重建中，任何非紧急操作都应推迟。这也解释了为什么"上一次重建是否结束"是维护前必查项。

失败模式 2：网络按常态规划，故障当天成为天花板。 东西向带宽按稳态负载设计，遇到重建就拥塞，恢复时间被拉长到小时级甚至天级。排查思路：重建慢时先看存储网端口利用率与丢包，而不是先怀疑盘。修正办法是回看第二节的设计要点：按"最坏情况下同时重建几条流"来规划存储网。

失败模式 3：混节点踩出支持边界。 异构型号、不同代 CPU、容量悬殊的盘混进一个集群，"技术上能起来"，但重建、调度、热迁移在一段时期后可能触发不支持的行为。排查思路：加节点前查官方支持列表；已经混入且不在支持范围的，规划替换窗口，不要等到故障时才发现。

失败模式 4：多个"各自安全"的变更叠加。 上午换盘、下午升级固件、晚上跑备份，单看每一步都安全，叠加起来可能连续触发两次重建，越过"允许同时动几台"的预算。这是用变更日历可以完全避免的失败模式，属于流程问题，不是技术问题。

失败模式 5：把高可用当成备份。 超融合的高可用不等于备份——副本防的是硬件故障，防不了误删和勒索。这是另一篇的内容，但在这里必须划清边界：副本是"冗余"，备份是"可回退快照"；前者不防逻辑错误，后者才防。

失败模式 6：性能场景错配。 需要亚毫秒稳定延迟的数据库核心库、或者需要极致顺序带宽的场景，专门的块存储/全闪阵列仍有结构性优势——不是超融合不行，而是"分布式 + 通用网络 + 本地盘"的架构在极端性能下有它的上限。排查思路：先量化延迟/带宽的 SLO 是什么，再决定架构，而不是先买设备再找用途。

#什么时候不该上超融合

超融合是很好的形态，但它不是"更先进的架构"：

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

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

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

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

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

#七、收尾：把"单点"换成一段时间

最后补上这篇没有覆盖、但你应该知道的边界，避免误读：

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

一句话收束：超融合把"单点"从一个部件换成了一段时间。买它之前先把这段时间量出来，比看任何一张架构图都有用。量出来的方法就在前面：第三节的网络预算、第五节的重建收敛判定、第六节那张"允许同时离线几台"的表格。如果还想再进一步，就在测试集群里做一次故障演练，把"坏一台之后多久回到三副本"这个数字实测出来——拿到这个数字，再决定这个架构值不值得，就比听任何推销都踏实。