4-15 存储技术② 分布式存储软件 Ceph

📄 一句话概括

Ceph 是分布式存储的开源代表：不靠专用存储阵列，把普通服务器的本地盘聚成一个池，同一套集群同时提供三种接口（块、对象、文件）；而它最需要算清的一笔账是冗余方式——三副本简单可靠但要占三倍空间，纠删码省一半空间但写入慢、重建贵，所以实用做法是热数据用三副本、冷数据用纠删码。

📝 本节和前面几节的关系

上一节（4-14）讲的是传统做法：一台存储阵列，里面配 RAID，外面接多路径。这一节讲另一种做法：把很多台普通服务器拼起来，用软件实现可靠性——不需要专门的存储阵列。

这两条路线的差别，其实就是里 DAS/SAN/NAS 那一节的延续：传统路线是【买一套专门的硬件】，分布式路线是【用普通硬件 + 软件来实现】。后者正是【软件定义】这个大趋势在存储上的体现——和 4-12 讲的 SDN 是同一个思路（把能力从专用硬件里搬到软件里）。

一、思路的转变：从【买一台好设备】到【用很多台普通设备】

对比一下两条路线：

	传统存储阵列	分布式存储
靠什么保证可靠	阵列内部做冗余（RAID、双控制器）	跨节点做冗余（副本、纠删码）
扩容方式	换更大的阵列，或加扩展柜	加普通服务器节点
单价	高（专用硬件）	低（通用硬件）
被谁锁定	该品牌	不锁定（软件开源、硬件随便选）
运维复杂度	相对低（有厂商支持）	相对高（要自己会搭会调）

分布式存储的关键突破在【不锁定】：因为软件是开源的、硬件是通用的，你可以随时换服务器品牌，也不用担心换不了阵列。这和 2-12 讲的【开源真正解决的是不被锁死】是同一件事。

代价也清楚：它把可靠性从【硬件的责任】变成了【软件 + 运维的责任】。阵列坏了你打电话给厂商；分布式存储的某个节点坏了，是你自己在这个周末把它换掉、然后盯着数据重新均衡完。

二、Ceph 的三个接口与两种冗余

一套 Ceph 集群同时提供三种存储接口：

接口	全称	用来做什么	对应云上什么
块	RBD	给虚拟机当磁盘用	云盘
对象	RGW（兼容 S3）	存图片、备份、日志	对象存储
文件	CephFS	当共享目录挂载	文件存储

为什么要三种都提供：因为真实系统里这三种需求同时存在——虚拟机要块、备份要对象、共享目录要文件。如果只提供一种，就得再引入一套系统，多一套就多一份运维。这正是它叫【统一存储】的意思。

绕开集中元数据的做法：传统存储有一个【记录每块数据在哪】的中心表，规模大了这张表就是瓶颈。Ceph 用的算法是由数据本身算出它该放在哪儿——不需要查表，所以它可以从三台节点扩到上千台。这也是它能【自成规模】的原因。

三、动手 Demo：三副本与纠删码，差多少空间

看到什么算成功：

==================================================================================================
【Demo 15】分布式存储 Ceph：三副本还是纠删码
==================================================================================================
  分布式存储的做法是：不靠专用阵列，把普通服务器的本地盘聚成一个池。
  Ceph 是最常见的开源实现，一套集群同时提供三种接口：
    块（RBD）＝给虚拟机当磁盘用
    对象（RGW，兼容 S3）＝存图片、备份、日志
    文件（CephFS）＝当共享目录挂载

  同样 100 TB 的原始盘，两种冗余方式的可用容量差很多：

  方式                副本份数      可用容量      容量开销
  --------------------------------------------------------------------------------------------
  三副本              3 份          33.3 TB       200%（每 1 TB 数据占 3 TB）
  纠删码 4+2          2 份校验      66.7 TB       50%（每 1 TB 数据占 1.5 TB）
  --------------------------------------------------------------------------------------------
  算式：
    三副本：100 × 1/3 = 33.3 TB；开销 = 3/1 − 1 = 200%
    纠删码：100 × 4/6 = 66.7 TB；开销 = 6/4 − 1 = 50%

  纠删码省一半以上空间，那为什么不全用？

  对比项              三副本                    纠删码 4+2
  --------------------------------------------------------------------------------------------
  写入延迟            低（写三份）              高（要算校验再分散写）
  重建一块盘的数据量  复制 1 份                 读 4 份算 1 份（网络压力大）
  适合                热数据、数据库盘          冷数据、备份、归档
  容错                任意坏 2 份               任意坏 2 份
  --------------------------------------------------------------------------------------------
  所以实用做法是分池：热数据用三副本，冷数据用纠删码。

读结果：

看两个算式：三副本要 3 倍的盘才存 1 倍的数据；纠删码 4+2 只要 1.5 倍。如果 100 TB 全部用三副本，你实际只有 33.3 TB 可用——这就是为什么【分布式存储不一定便宜】：省了硬件的单价，但可能要买更多的盘。
看最后那张对比表的第一行：纠删码的代价在写入上——每次写都要算校验并分散写到多个节点，延迟明显更高。所以它不适合数据库盘、不适合日志这类【必须立刻落盘】的场景，而适合备份、归档这类【写进去之后很久不读】的数据。这就是分池的由来。

30 秒实验

在能上网的机器上看一眼你常用的网盘或对象存储的容量报价页，做两件事：

找有没有【冗余类型】或【存储级别】这类选项（比如【标准】／【低频】／【归档】）。
看它们的单价差多少倍。

做完这个你会看到一件事：同一家厂商的存储，不同级别的单价可以差好几倍——而差价的主要来源，正是本节讲的冗余方式与介质（热数据用快速冗余的三副本或镜像，冷数据用便宜的纠删码或更低速的介质）。这是一个放之四海皆准的结构：把用得少的东西存得更省。

常见误区

错误：分布式存储比传统阵列便宜，因为用的是普通硬盘。——纠正：要看总账，而不是看单价。三个因素会把省下的钱吃掉：① 冗余开销（三副本要买 3 倍的盘）；② 必须配高速网络（数据要在节点之间搬，网络成了瓶颈）；③ 人力（自己搭、自己调、自己处理故障，这部分不便宜）。所以在小规模场景下，分布式存储常常比买一套阵列更贵——它的优势在【大到一定程度之后】，扩展成本和锁定风险才开始显示出来。
错误：三副本能扛住任意两台机器同时挂掉，所以特别安全。——纠正：要看这三份放在哪儿。如果三份副本被放在同一个机架里，那这个机架断电时三份一起没——冗余只有在【分散在不同的故障域】时才有意义。所以真实部署要求做机架感知（同一个数据的副本跨机架分布）。判断冗余是否有效，看的不是【几份】，而是【这几份最坏情况下会不会一起出问题】。
错误：纠删码是【更省空间的三副本】，纯升级。——纠正：它是另一笔交易。省的是空间，付出的是写入性能和重建成本（重建时要读多个分片算回来，网络压力大得多）。所以它和 RAID 5/6 是同一类东西——用计算和性能换容量效率。没有免费的空间。
错误：既然一套 Ceph 能提供三种接口，那所有存储都放进同一套集群最省事。——纠正：会出问题的是【性能隔离】。块存储（虚拟机的盘）对延迟敏感，对象存储（备份）对吞吐敏感——放在同一个池里，备份任务一跑起来，虚拟机的磁盘响应就抖了（这在 4-3 里叫【吵闹的邻居】）。所以规范做法是按用途分池、分别配硬件和参数，而不是一个大池装所有东西。

自测三问（点开对答案）

1. 为什么分布式存储能把可靠性从【硬件】转移到【软件】？ —— 因为**它把冗余做在了【节点之间】，而不是【设备内部】**。传统阵列靠的是内部的双控制器、RAID 卡、冗余电源——**这些都在一个机箱里，所以机箱整体出问题时就都靠不住**；分布式存储靠的是【同一份数据在多个节点上有副本】，**任何一个节点整个坏掉都不影响**。而且这些节点是通用服务器，**坏了一台换一台，不需要原厂**。转移的代价是：**判断哪台坏了、数据有没有恢复完、要不要加盘——这些都要你自己管。** 2. 【三份副本放在同一个机架里】这个问题，为什么值得单独讲？ —— 因为**它是【看起来做了冗余，实际上没有】的典型**。冗余设计的核心概念是【故障域】：**同一个故障能同时影响到的范围**。同一个机架共享电源、共享交换机、共享空调——**一次断电或一次交换机故障就会同时命中**。所以【副本数 = 3】这个数字本身没有意义，**必须有【副本分布在不同故障域】这个前提**。**这条原则适用于任何冗余设计**：备份要异地、控制器要跨机房、电源要双路——都是同一个道理。 3. 做存储选型时，为什么不能只算【每 TB 单价】？ —— 因为**每 TB 单价只反映了硬件成本的一小块**。完整的账至少要包括：① **冗余开销**（可用容量 = 原始容量 ÷ 冗余倍数）；② **网络成本**（分布式存储要靠网络搬数据，网络规格直接决定体验）；③ **人力成本**（自建要自己运维，买商用有厂商支持）；④ **扩展性成本**（扩的时候是不是必须【一次加好几个节点】）。**把四项加起来的五年总账，才是能比较的数字**——这也正是 4-16 讲超融合时用的同一种算法。

⚠️ 2026 现状：Ceph 与存储的今天

Ceph 仍是这个领域的开源主力，版本节奏稳定、社区活跃。近几年的迭代重点从【能跑】转向性能与云原生：块存储增加了高速网络（NVMe over Fabrics）的支持，纠删码的小块读写性能有了明显改善（这是过去它最大的短板），同时在 Kubernetes 上的部署（Rook）也成了主流方式之一。
一个值得注意的变化是【同时提供三种接口】这件事被验证得更彻底了：现在很多私有云、虚拟化平台、Kubernetes 集群的底层存储都是同一套 Ceph，不再为块和对象分别买两套系统——教材这一节的判断在十年后被证明是对的。
但要留意另一面：存储领域也出现过【开源项目转为商业许可】的情况（知名的对象存储项目就发生过），所以选开源存储时要把它背后的治理与许可放在评估项里，而不是只看功能表——这是 2-12 那节课留下的教训。