一文讲清楚Ceph分布式存储

2025-8-25

在云计算、大数据和 AI 时代，“数据存储” 不再是简单的 “存文件”—— 需要支撑 PB 级数据、弹性扩展、高可靠、多场景接入（块 / 对象 / 文件），而Ceph正是为解决这些需求而生的分布式存储系统。它不仅是 OpenStack、Kubernetes 等云原生生态的 “标配存储”，也广泛用于企业级存储、大数据平台等场景。

本文将从 “基础定义” 到 “核心原理”，再到 “实际应用”，层层拆解 Ceph，让你彻底搞懂它的设计逻辑和价值。

一、什么是 Ceph？—— 先明确核心定位

Ceph 是一个开源、统一、分布式的存储系统，核心特点是 “三统一”：统一存储接口（支持块存储、对象存储、文件存储）、统一管理（单集群管理所有存储类型）、统一数据池（底层用同一套存储引擎存储所有数据）。

1. Ceph 的背景

起源：2004 年由加州大学圣克鲁兹分校的 Sage Weil 发起（最初是博士论文项目），2010 年被 Red Hat 收购后加速发展，成为开源存储领域的 “事实标准” 之一。
定位：面向 “大规模存储场景”，从几 TB 的小型集群到 EB 级的超大型集群都能支撑，且性能随节点增加线性扩展。

2. Ceph 的核心目标

解决传统存储的三大痛点：

单点故障：传统存储（如 SAN/NAS）依赖硬件阵列，易出现单点故障；Ceph 全分布式设计，无单点。
扩展受限：传统存储扩容需更换硬件，成本高且不灵活；Ceph 支持 “横向扩容”（新增服务器即可），扩展成本低。
场景割裂：传统存储需分别部署块存储（SAN）、对象存储（如 S3）、文件存储（NAS），管理复杂；Ceph 一套集群搞定三类场景。

二、Ceph 的核心架构 —— 从 “底层引擎” 到 “上层接口”

Ceph 的架构是 “分层设计”，最底层是核心引擎，上层是面向不同场景的接口，再配合监控管理组件，形成完整的存储集群。

1. 架构分层图（核心组件）

┌─────────────────────────────────────────────────┐
│                  客户端层                        │
│  (虚拟机/K8s Pod/应用程序)                       │
├─────────────────────────────────────────────────┤
│                  接口服务层                      │
│  RBD (块存储)  |  RGW (对象存储)  |  CephFS (文件存储) │
├─────────────────────────────────────────────────┤
│                  核心引擎层 (RADOS)              │
│  OSD (存储数据)  |  MON (集群管理)  |  MGR (监控运维)  │
└─────────────────────────────────────────────────┘

每个组件的作用是 “各司其职、协同工作”，下面逐一拆解核心组件：

2. 核心组件详解

（1）底层核心：RADOS（可靠的自治分布式对象存储）

RADOS 是 Ceph 的 “灵魂”，所有数据最终都存储在 RADOS 中，它负责数据的分布式存储、副本管理、故障自愈、一致性保证。RADOS 由两个核心模块组成：

组件	全称	核心作用	关键特点
OSD	Object Storage Daemon（对象存储守护进程）	1. 实际存储数据（以 “对象” 形式）； 2. 负责数据的副本同步、修复； 3. 监控自身和其他 OSD 的健康状态。	每个 OSD 对应一个存储设备（如一块硬盘），是 Ceph 的 “存储单元”。
MON	Monitor（监控节点）	1. 维护集群的 “集群地图”（Cluster Map）—— 记录所有组件的位置、状态； 2. 管理集群配置（如副本数、CRUSH 规则）； 3. 协调集群节点的加入 / 退出，保证集群一致性。	需部署奇数个（如 3、5 个），避免脑裂；是 Ceph 的 “大脑”。

（2）监控运维：MGR（Manager）

Ceph Luminous（12.2.x）版本后新增的组件，负责集群监控和运维管理，弥补 MON 在 “精细化监控” 上的不足：

功能：收集集群 metrics（如 OSD 使用率、IOPS、延迟）、提供 Web UI（Dashboard）、支持第三方监控集成（如 Prometheus）、管理集群配置（如用户权限）。
部署：通常与 MON 同节点部署，支持多副本（主从模式），确保高可用。

（3）上层接口：三大存储服务

RADOS 是 “对象存储引擎”，但用户需要的是 “块 / 文件 / 对象” 接口，因此 Ceph 在 RADOS 之上封装了三大服务：

服务	全称	存储类型	核心用途	典型场景
RBD	RADOS Block Device（RADOS 块设备）	块存储	提供 “块级” 存储（类似硬盘），支持随机读写，可挂载到主机 / 虚拟机。	1. 虚拟机磁盘（如 OpenStack Nova 的根磁盘）； 2. K8s 的 PVC（持久化存储）； 3. 传统应用的块设备需求（如数据库）。
RGW	RADOS Gateway（RADOS 网关）	对象存储	提供兼容 S3/Swift 的 REST API，支持 “对象级” 存储（键值对形式）。	1. 非结构化数据存储（图片、视频、日志）； 2. 备份归档（如虚拟机镜像备份）； 3. 云存储服务（如私有 S3 服务）。
CephFS	Ceph File System（Ceph 文件系统）	文件存储	提供兼容 POSIX 标准的文件系统，支持目录结构和文件权限。	1. 共享存储（如多台服务器共享同一目录）； 2. 大数据任务（如 Hadoop 的 DataNode 存储）； 3. 传统应用的文件访问需求（如 NFS 替代）。

三、Ceph 的核心技术原理 —— 为什么它能 “高可用、高扩展”？

Ceph 的优势（无单点、线性扩展、自愈），本质是由其底层技术支撑的，其中最关键的是CRUSH 算法、PG 机制和自愈能力。

1. 数据分布的 “灵魂”：CRUSH 算法

传统分布式存储用 “哈希 + 一致性哈希” 实现数据分布，但一致性哈希在 “节点数量多、权重不同（如硬盘大小不一）” 时效率低。Ceph 发明了CRUSH 算法（Controlled Replication Under Scalable Hashing，可控的可扩展哈希复制），解决了这一问题。

CRUSH 的核心作用：

给定一个 “数据对象”，CRUSH 能快速计算出它应该存储在哪些 OSD 上（无需查询中心节点，实现 “无中心寻址”），且满足以下需求：

均匀分布：数据均匀分散在所有 OSD，避免 “热点”；
可控副本：按配置的副本数（如 3 副本），将数据存储到不同节点的 OSD（避免单节点故障丢失数据）；
动态适应：集群扩容 / 缩容时，仅需迁移少量数据（减少 IO 压力）。

CRUSH 的计算逻辑（简化版）：

对 “数据对象 ID” 和 “集群地图（包含 OSD 列表、权重、故障域）” 进行哈希计算；
根据预设的 “CRUSH 规则”（如 “副本分布在不同主机 / 机房”），筛选出符合条件的 OSD；
输出 “主 OSD”（Primary OSD）和 “从 OSD”（Replica OSD），数据先写入主 OSD，再同步到从 OSD。

2. 数据管理的 “中间层”：PG 机制

如果直接将 “数据对象” 映射到 OSD，会导致两个问题：

数量爆炸：一个集群可能有数十亿个对象，直接管理每个对象的映射关系，效率极低；
操作频繁：每次对象读写都要触发 CRUSH 计算，性能开销大。

Ceph 引入了PG（Placement Group，归置组），作为 “对象” 和 “OSD” 之间的中间层：

定义：PG 是一组 “数据对象” 的集合，所有对象会先被分配到某个 PG，再由 PG 映射到 OSD（一个 PG 对应多个 OSD，即副本数）；
作用：
1. 减少映射粒度：用 “PG” 代替 “对象” 与 OSD 映射，管理量从 “数十亿对象” 缩减到 “数万 PG”，效率极大提升；
2. 批量管理：数据的副本同步、修复、迁移，都以 PG 为单位进行（而非单个对象），降低操作复杂度；
关键配置：PG 数量需合理设置（通常公式：PG总数 = (OSD数量 × 100) / 副本数），如 100 个 OSD、3 副本，PG 总数约 3333。

3. 数据可靠性的 “保障”：副本与自愈

Ceph 通过 “副本机制” 和 “自愈能力”，确保数据在硬件故障时不丢失、不损坏。

（1）副本机制

核心逻辑：每个 PG 会存储 N 个副本（N 由配置osd_pool_default_size决定，默认 3），且副本分布在 “不同故障域”（如不同主机、不同机柜、不同机房）—— 避免单故障域失效导致数据丢失。
写入流程（以 3 副本为例）：
1. 客户端将数据写入 “主 OSD”；
2. 主 OSD 将数据同步到 “从 OSD1” 和 “从 OSD2”；
3. 从 OSD 写入成功后，向主 OSD 返回确认；
4. 主 OSD 收到所有从 OSD 的确认后，向客户端返回 “写入成功”。

（2）自愈能力

当 OSD 故障（如硬盘损坏）或节点下线时，Ceph 能自动修复数据，无需人工干预：

故障检测：MON 通过 OSD 的 “心跳（Heartbeat）” 检测故障（OSD 每几秒向 MON 和其他 OSD 发送心跳）；
状态更新：MON 标记故障 OSD 为 “down”，并更新 “集群地图”，同步给所有组件；
数据修复：
- 若故障 OSD 是 “主 OSD”：从 OSD 中选举一个新主 OSD，继续提供服务；
- 若副本数不足（如 3 副本变成 2 副本）：新主 OSD 会从现有副本中，在健康的 OSD 上复制新副本，直到恢复到配置的副本数。

四、Ceph 的优势与适用场景

1. 核心优势

优势	具体说明
统一存储	一套集群支持块、对象、文件存储，无需部署多套存储系统，降低管理成本。
高可用	无单点故障（MON/OSD/MGR 均支持多副本），自愈能力确保数据不丢失，可用性达 99.999%。
线性扩展	新增 OSD / 节点即可扩展容量和性能，集群规模可从 TB 级扩展到 EB 级。
高性能	无中心架构（客户端直接与 OSD 交互），支持 SSD/HDD 混合部署，可通过缓存（如 BlueStore）优化 IO。
开源免费	基于 Apache 协议开源，无 license 成本，社区活跃（Red Hat、SUSE 等厂商提供商业支持）。
云原生友好	深度集成 OpenStack、Kubernetes、CloudStack 等云平台，支持动态 provisioning（自动创建存储）。

2. 适用场景

（1）云计算场景

作为 OpenStack 的后端存储：为 Nova（虚拟机）提供 RBD 块存储，为 Glance（镜像）提供 RGW 对象存储；
作为 Kubernetes 的持久化存储：通过 RBD 或 CephFS 提供 PVC，支撑 StatefulSet（如数据库、中间件）的持久化需求。

（2）企业级存储场景

替代传统 SAN/NAS：为企业数据库（MySQL、PostgreSQL）提供块存储，为文件共享提供 CephFS，降低硬件成本。

（3）大数据与 AI 场景

为 Hadoop/Spark 提供存储：用 CephFS 存储大数据任务的输入 / 输出数据，或用 RGW 存储日志、模型文件；
为 AI 训练提供存储：存储大规模训练数据（如图片、视频），支持高并发读写。

（4）备份归档场景

用 RGW 提供 S3 兼容的备份服务，存储虚拟机备份、数据库备份、日志归档等数据（支持生命周期管理，如自动迁移冷数据）。

五、Ceph 的部署与运维 —— 关键要点

1. 部署工具

Ceph 的部署工具经历了多代演进，目前主流工具是：

cephadm：Ceph Octopus（15.2.x）版本后官方推荐，基于 Docker/Podman 容器化部署，支持自动发现、升级、修复，操作简单（适合新手）；
Ansible（ceph-ansible）：基于 Ansible 脚本部署，支持更多自定义配置（适合复杂场景，如混合硬件、多机房）；
ceph-deploy：早期工具，功能简单，已逐渐被 cephadm 替代。

2. 运维核心关注点

PG 管理：PG 数量需在集群初始化时合理设置（过少导致数据分布不均，过多导致管理开销大）；后期调整 PG 需谨慎（会触发数据迁移）。
监控告警：通过 MGR 的 Dashboard 或 Prometheus+Grafana 监控集群状态，重点关注 OSD 使用率（避免超过 85%，否则性能下降）、PG 健康状态（无 down/incomplete PG）、IO 延迟。
扩容缩容：
- 扩容：新增 OSD 节点，cephadm/Ansible 自动将节点加入集群，CRUSH 算法自动分配数据；
- 缩容：需先标记 OSD 为 “out”，等待数据迁移完成后再移除，避免数据丢失。
故障处理：
- OSD 故障：若硬盘可修复，重启 OSD 即可；若硬盘损坏，更换硬盘后重建 OSD，集群自动修复数据；
- MON 故障：若 MON 节点下线，需尽快恢复（或新增 MON 节点），确保 MON 数量为奇数。