Ceph 是一个开源的、统一的软件定义分布式存储系统,起源于美国加州大学圣克鲁兹分校的博士研究,2006 年以开源项目形式发布。它把对象存储、块存储和文件系统三种接口集成在同一个集群中,底层依托无中心节点的 RADOS 对象存储与 CRUSH 数据放置算法,可运行在通用硬件上并随节点增加而扩展,现已成为 OpenStack、Kubernetes 等平台常见的存储后端。
定义
Ceph 是一个开源的、统一的软件定义分布式存储系统,设计目标是为现代数据中心提供高性能、高可靠性和高可扩展性的存储服务[1]。它在同一套集群中同时提供对象存储、块存储和文件系统三类服务接口,使用者不必为不同存储类型分别部署独立的系统[2]。
Ceph 的所有存储能力都由底层的 RADOS 提供,RADOS 是一个可靠、自动、分布式的对象存储层[3]。在其之上,RADOS 网关提供兼容 Amazon S3 等接口的对象存储,块设备(RBD)提供块级存储,Ceph 文件系统(CephFS)则提供符合 POSIX 语义的文件服务[4]。
原理
Ceph 集群由多类守护进程组成。监视器(ceph-mon)保存集群状态映射表的主副本并分发给客户端,通常需要部署多个以避免单点故障;对象存储设备(ceph-osd)负责数据的存储、复制、纠删码、恢复与再均衡;管理器(ceph-mgr)收集运行时指标并提供监控接口;元数据服务器(ceph-mds)只在提供文件服务时使用,负责管理文件元数据[3]。
数据以对象形式存放在逻辑上的存储池中,存储池再被切分为放置组(Placement Group,PG)。客户端先对对象标识做哈希并对放置组数量取模,得到对象所属的放置组编号,再由 CRUSH 算法计算出承载该放置组的一组 OSD[5]。可以用下式表示这一映射关系:$pgid = hash(oid) \bmod num\_pg$,随后 $osds = CRUSH(pgid)$[6]。
CRUSH 全称是可控副本分布算法,它用集群的物理位置信息进行计算,支持多副本和纠删码两种冗余方式,并能通过故障域划分让副本分布在不同机架或机房[6]。由于客户端和 OSD 都能自行计算数据位置,集群不需要中央查表节点,避免了集中式节点带来的瓶颈[3]。
flowchart LR
C[客户端] -->|cluster map| M[监视器 ceph-mon]
C -->|object id 哈希| PG[放置组 PG]
PG -->|CRUSH| O1[OSD 1]
PG -->|CRUSH| O2[OSD 2]
PG -->|CRUSH| O3[OSD 3]
O1 -.心跳.-> M
O2 -.心跳.-> M
O3 -.心跳.-> M
发展历程
Ceph 源于 2004 年 Sage Weil 在加州大学圣克鲁兹分校存储系统研究中心开展的博士研究课题,该研究由劳伦斯利弗莫尔、桑迪亚和洛斯阿拉莫斯国家实验室资助,目标是构建 PB 级规模的存储系统[7][8]。2006 年,介绍 Ceph 的论文在 OSDI 会议发表,CRUSH 数据放置算法的论文则在 SC 会议发表,代码以 LGPL 协议公开[7]。2007 年 Weil 完成博士论文,项目继续在 DreamHost 推进[7]。
2010 年,Ceph 客户端代码被合并进 Linux 内核 2.6.34,此后 Linux 可以原生挂载 Ceph 文件系统[7][9]。2012 年,Weil 与团队创立 Inktank 公司提供商业支持,同年 Argonaut 成为第一个长期稳定版本[7]。2014 年 Red Hat 收购 Inktank,同年恰逢 Ceph 首行代码写下十周年[7][8]。
2018 年,Ceph 基金会在柏林 Ceph Day 上成立,成为 Linux 基金会下的定向基金,创始成员机构共 31 家[7]。在版本演进上,Ceph 早期的后端引擎为 FileStore,到 Luminous(v12)版本引入 BlueStore,提升了性能与效率。Ceph 基金会章程与技术章程随后确立,技术决策权保留在社区,基金会侧重资金、推广与生态建设[7]。
应用
Ceph 的典型用途是作为私有云的底层存储。它支持超融合与分离式两种部署形态,可用作虚拟机云盘和系统镜像的后端,也被用于大数据分析、富媒体以及替代公有云存储的场景[8]。由于接口统一,它适合承载云平台、OpenStack、Kubernetes 以及基于容器的微服务负载。
在实际部署层面,Ceph 被用于学术与科研机构、电信运营商和云服务商。欧洲核子研究中心(CERN)曾以 Ceph 构建 PB 级块存储服务,为 AFS、NFS 服务器以及规模较大的 OpenStack 集群提供后端存储[10]。对象存储方面,Ceph 的网关服务可与网盘类应用对接[9]。
局限
Ceph 的部署与运维门槛较高。有资料指出,生产环境中的默认参数很少针对混合负载做过优化,对集群进行大版本升级需要在大量节点上严格操作,使用者往往需要投入专职的存储工程人员[11]。集群日志复杂度高,定位异常需要专门经验,有运维团队反映往往更依赖对外部硬件与资源的外部监控来判断问题[12]。
自愈与再均衡过程会占用集群内部带宽和磁盘 I/O,如果不加限流,业务应用可能出现明显的延迟上升[11]。集群接近容量上限时,写操作会被整体拒绝,而删除数据本身也需要写权限,使扩容前的清理变得棘手[11]。有实践材料建议规划容量时让日常使用率保持在 70% 以下,为恢复和再均衡留出余量。
CRUSH 算法本身也存在不足。有研究指出,选择 OSD 时可能出现权重失衡,增删 OSD 会带来额外数据迁移,完全依赖哈希随机性还可能导致各 OSD 容量使用率不均衡,实际环境中出现过超过 40% 的差异,因此 Ceph 从 Luminous 版本起提供了 upmap 机制用于手动指定放置组分布。此外,Ceph 的架构最初面向机械硬盘时代设计,对延迟敏感的高性能块存储负载存在额外网络跳数与协议转换开销[13]。有运维总结还提到,加入或移除节点可能引发大量数据迁移,建议起步时至少准备 5 个节点以减小迁移比例[14]。
参见
参考资料
- Discover [引用日期2026-10-14]
- Welcome to Ceph [引用日期2026-10-14]
- The Ceph Storage Cluster [引用日期2026-10-14]
- 案例研究：CEPH 檔案系統 [引用日期2026-10-14]
- Dynamic Cluster Management [引用日期2026-10-14]
- ceph工作原理和安装 [引用日期2026-10-14]
- History [引用日期2026-10-14]
- 带你读《存储漫谈Ceph原理与实践》第一章分布式存储概述1.3Ceph 的发展历程 [引用日期2026-10-14]
- Ceph分布式存储实战 1.1 Ceph概述 [引用日期2026-10-14]
- Building an organic block storage service at CERN with Ceph [引用日期2026-10-14]
- Ceph Storage Comparison: Performance, Scale & Efficiency [引用日期2026-10-14]
- Les malheurs de Cephie [引用日期2026-10-14]
- Ceph Storage for Block Workloads: Performance & Alternatives [引用日期2026-10-14]
- Why Ceph? [引用日期2026-10-14]