4-16 简单的虚拟化基础设施 · 波仔的云计算课

📄 一句话概括

超融合（HCI）做的事是把三层摊平成一层：传统数据中心是【服务器 + 存储阵列 + 存储网络】三套东西，超融合把它们合到同一批节点里——每台节点既算又存；代价是计算和存储被绑在一起扩展，所以它适合中小规模与分支机构，不适合【计算和存储要各自独立扩】的大场景。

📝 本节和前面几节的关系

前两节讲存储（4-14、4-15）。这一节是把前面讲过的计算、网络、存储三条线合起来看——超融合就是一个【把三者装进同一个盒子】的形态。

它的技术基础正好是前几节：本地盘聚成池（4-15 的分布式存储思路）+ 虚拟化（4-3）+ 扁平网络（4-13）。所以它不是新技术，而是把这些技术组合成一种【更简单的交付形态】。

一、它合并了什么

先看传统三层结构和超融合的对比：

层次	传统三层	超融合
计算	服务器	每个节点自己算
存储	独立存储阵列	每个节点的本地盘，由软件聚成池
存储网络	专用网络（光纤通道或存储网）	复用普通以太网
扩展方式	算和存各自买、各自加	加一个节点，同时加算和存

关键的改变是【存储不再是独立设备】。传统架构里，服务器要访问数据必须经过一套专门的存储网络连到阵列；超融合里，每个节点用自己的本地盘，通过软件在节点之间同步数据——读数据很多时候就在本机，不需要走网络。

这件事带来两个直接收益：

少了一套专用网络和一台专用设备——采购、维护、故障点都少了一批
读取路径变短——因为数据可能就在本机，延迟更低

二、代价：绑定

超融合最需要想清楚的一点是【绑定】：

绑定的东西	意味着什么
计算与存储绑在一起扩	存储不够时，也得连带买一批 CPU 和内存
反过来也一样	计算不够时，也会连带多出一批盘
软件与硬件通常配套	换品牌等于整套换

什么场景下这个绑定不痛？

负载比较均衡的中小规模（50~500 台虚拟机）——算和存大致同比例增长，一起加正好
分支机构、边缘站点——要的就是【一台设备搞定，别派人去维护】
新建的绿地环境——没有已存在的存储阵列要复用

什么场景下痛？

有专门的高性能数据库——这类负载需要专用阵列的特定能力（缓存、多路径、特定协议）
已经有成熟存储团队和存量阵列——把那套东西扔掉重来，账很难算平
计算和存储的增长曲线明显不同——比如存储一年涨 50%、计算只涨 10%

三、动手 Demo：五年总账怎么算

看到什么算成功：

==================================================================================================
【Demo 16】超融合架构：把三层摊平成一层
==================================================================================================
  传统数据中心是三层：服务器 + 存储阵列 + 存储网络。
  超融合（HCI）把它们合并到同一批节点里：每台节点既算又存。

  以 200 台虚拟机的规模，五年总成本对比（把三层的 5 年 TCO 记作 100）：

  项目                      三层架构          超融合
  --------------------------------------------------------------------------------------------
  硬件与软件首年投入        100               82~88
  第 2~5 年每年支出         10~12             7~8
  五年合计                  140~148           110~120
  运维人力                  2.5 人            1.0~1.5 人
  采购与集成周期            8~12 周           2~4 周
  扩容方式                  计算与存储分开加  加节点，一次加两样
  --------------------------------------------------------------------------------------------
  省下来的钱里，硬件只占小头，人力才是大头——三项能力一次到位：
    一套管理界面（不用再学存储阵列那一套）
    一个支持电话（不用在两家厂商之间互相推）
    一次扩容（不用先算存储够不够、再算服务器够不够）

  它不适合谁？
    · 已经有成熟存储团队与存量阵列，且还要用两年以上的大企业
    · 计算与存储需要各自独立扩展的场景（超融合会把两者绑在一起）
    · 需要 FC、大型机接入等专用存储特性的场景

读结果：

看【五年合计】那两行：140~148 对 110~120，差约 20%。这个差距不大，所以单看硬件成本，超融合并不是压倒性的——这提醒我们别被【省 20%】这种数字带着走。
真正的差别在下面两行：运维人力从 2.5 人减到 1.0~1.5 人；采购集成从 8~12 周缩到 2~4 周。按一个人年成本算，人力省下的钱往往超过硬件省下的——这和 3-12 那节课【最大一块是人力】的结论完全一致。

30 秒实验

在任意一家云服务商的控制台文档里搜【本地盘】或【裸金属 + 本地存储】，做一件事：

看它有没有提供【本地盘的实例类型】，以及这类实例的价格与【云盘实例】的价格差多少。

做完这个你会看到一个事实：本地盘的单 TB 价格明显更低——因为它不需要走网络、不需要额外的冗余硬件。这正是超融合的经济性来源：把存储就近放在计算节点上。而云上的本地盘实例通常也标注了【数据不持久，重启或迁移会丢】——那是它把省下的钱对应的风险，清楚地写在了产品说明里。

常见误区

错误：超融合只是一种【更小的传统架构】。——纠正：它们的分层逻辑完全不同。传统三层是按功能分层（算、存、网各自独立设备），超融合是按节点分（一台节点里什么都有）。这决定了扩展方式、故障模型、运维方式全都不一样——不是大小之分，是结构之分。把它理解成【小号的传统架构】，就会用错场合。
错误：超融合一定比三层便宜。——纠正：要看规模和负载形状。它的经济性来自【省掉专用设备与专用网络 + 运维人力摊薄】，而这些收益需要一定规模才显现。而且如果算和存的增长不同步，被绑着一起买的那部分会变成浪费。所以正确的做法是按自己未来五年的算力与容量增长曲线去算，而不是拿厂商宣传的【省 X%】当结论。
错误：既然节点里都有本地盘，那就不需要备份了。——纠正：超融合的冗余是【集群内】的，逃不出集群。它通常在每个节点之间保存若干个副本——这套机制能扛单节点故障，但扛不住整个集群的问题（机房事故、误删、勒索软件、软件升级出错）。所以备份仍然必须有一份离开这个集群（异地、另一套系统、或公有云）。这和 4-14 里【快照不是备份】是同一个道理，只是换了个层级。
错误：超融合只能跑虚拟机，不适合容器这类新负载。——纠正：现在两类都能跑，而且同时跑是常态。主流平台都支持在有状态容器上挂持久化存储，让容器和虚拟机用同一套存储。所以超融合的定位正在从【虚拟化平台】变成【统一的基础设施层】——这也符合把它理解为【一种交付形态】而不是【一种虚拟化技术】。

自测三问（点开对答案）

1. 为什么超融合的账里，人力比硬件更值得看？ —— 因为**硬件成本差 20%，人力成本可以差一倍**。2.5 人减到 1.0~1.5 人，按每人每年几十万算，**一年就能省出好几台服务器的钱，五年下来超过硬件差价**。而且【少一个人】的收益不止在工资上：**交接成本、培训成本、排班压力**全都跟着下降。**这也是 3-12 那节课的核心结论：云和传统架构的成本差别，最大一块从来不在硬件上。** 2. 【计算与存储绑在一起扩展】在什么情况下会变成真问题？ —— **当两者的增长曲线明显不同的时候**。举个具体情形：如果业务主要是【数据不断堆积】（比如日志、影像、备份），那**存储一年涨一半、计算几乎不涨**——这时超融合意味着每次加存储都得连带买一批用不上的 CPU。**所以选型前必须问一句：未来五年，我的算力和容量大概各涨多少？** 同比例增长就适合超融合，差得远就要慎重。 3. 为什么超融合仍然需要独立的备份？ —— 因为**它的冗余范围是【集群内】**。副本机制防的是【节点坏】，**而集群本身的问题它防不了**：机房的电力或网络故障、一次错误的批量删除、软件升级引入的缺陷、被加密——**这些都会同时影响所有副本**，因为它们在同一个集群、同一个信任边界里。所以备份的定义仍然是那一句：**要有一份能扛住【整套系统全没了】的副本。**

⚠️ 2026 现状：超融合的今天

它已经从【新架构】变成了【中端市场的主流选择】。近十年来，超融合在中小规模（几十到几百台虚拟机）的虚拟化场景里逐步取代了传统三层架构，这一节教材的判断被验证了。
一个明显的新变化是【AI 负载】的加入。GPU 密集型工作负载正在成为超融合的新需求来源，厂商也在往【算力 + 存储 + AI 平台】一体化的方向做。这意味着超融合的定位继续在往上走：从【跑虚拟机的盒子】变成【装一整套基础设施的盒子】。
另一件值得留意的事是：虚拟化软件的许可模式变化，正在推动一轮平台迁移（商用虚拟化的订阅制与按核计费让不少用户重新算账），超融合因为把软件与硬件绑得比较紧，在这轮迁移里既是受益方也是需要重新评估的一方。所以现在选超融合，要额外问一句：如果我的虚拟化层要换，这套硬件还能用吗？

☐ 下一节（4-17 构建 IaaS 的基础软件：OpenStack）