Ceph 存储运维完全指南 / 01 - Ceph 架构与概述
01 - Ceph 架构与概述
1.1 Ceph 简介
Ceph 是由 Sage Weil 在博士论文中提出的开源分布式存储系统,遵循 CRUSH(Controlled Replication Under Scalable Hashing) 算法,实现了无中心节点的去中心化数据分布。Ceph 由 Red Hat 主导开发,是 OpenStack、Kubernetes 等云平台的首选后端存储。
核心特性
| 特性 |
说明 |
| 统一存储 |
同时支持块存储(RBD)、文件存储(CephFS)、对象存储(RGW) |
| 无单点故障 |
所有组件均可水平扩展,无中心瓶颈 |
| 自我修复 |
自动检测故障并重新平衡数据 |
| 线性扩展 |
可从 TB 扩展到 EB 级别 |
| CRUSH 算法 |
无需查表,通过计算确定数据位置 |
| 开源免费 |
LGPL 协议,社区活跃 |
版本演进
| 版本代号 |
版本号 |
发布时间 |
关键特性 |
| Luminous |
12.2.x |
2017 |
BlueStore 稳定、管理器(MGR) |
| Nautilus |
14.2.x |
2019 |
仪表盘改进、异步恢复 |
| Octopus |
15.2.x |
2020 |
自动伸缩 PG、改进 scrub |
| Pacific |
16.2.x |
2021 |
CephFS 多活 MDS、RGW 新特性 |
| Quincy |
17.2.x |
2022 |
改进的 cephadm、更好的性能 |
| Reef |
18.2.x |
2023 |
改进的 EC、更好的 NVMe 支持 |
| Squid |
19.2.x |
2024 |
CephFS 多文件系统、改进的安全 |
1.2 Ceph 统一存储架构
Ceph 的核心设计哲学是统一存储(Unified Storage),即通过一个集群同时提供三种存储接口:
┌──────────────────────────────────────┐
│ Ceph 集群 │
│ │
┌────────────┐ │ ┌────────┐ ┌────────┐ ┌────────┐ │
│ RBD 块存储 │──│─→│ OSD │ │ OSD │ │ OSD │ │
│ (QEMU/K8s) │ │ │ Node 1 │ │ Node 2 │ │ Node 3 │ │
└────────────┘ │ └────────┘ └────────┘ └────────┘ │
│ ↑ ↑ ↑ │
┌────────────┐ │ ┌──────────────────────────────────┐ │
│ CephFS 文件 │──│─→│ RADOS (可靠自主分布式对象存储) │ │
│ 存储 │ │ └──────────────────────────────────┘ │
└────────────┘ │ ↑ │
│ ┌──────────────────────────────────┐ │
┌────────────┐ │ │ MON (监控) + MGR (管理器) │ │
│ RGW 对象 │──│─→└──────────────────────────────────┘ │
│ 存储(S3) │ │ │
└────────────┘ └──────────────────────────────────────┘
三种存储接口对比
| 存储类型 |
接口 |
协议 |
典型场景 |
性能特点 |
| 块存储 (RBD) |
块设备 |
iSCSI / KRBD / QEMU |
虚拟机磁盘、数据库 |
低延迟、高 IOPS |
| 文件存储 (CephFS) |
POSIX 文件系统 |
FUSE / 内核 |
共享目录、日志存储 |
元数据性能关键 |
| 对象存储 (RGW) |
RESTful API |
S3 / Swift |
图片、视频、备份 |
高吞吐、大文件优化 |
1.3 CRUSH 算法原理
CRUSH 是 Ceph 的灵魂,它是一种伪随机数据分布算法,通过计算而非查表来确定数据存放位置。
传统哈希 vs CRUSH
传统方式: Client → 查元数据表 → 确定位置 → 访问数据
(元数据服务器是瓶颈和单点故障)
CRUSH: Client → CRUSH(placement_info) → 计算位置 → 直接访问数据
(无中心节点,所有客户端独立计算出相同结果)
CRUSH 核心概念
| 概念 |
说明 |
示例 |
| CRUSH Map |
集群的拓扑描述 |
包含所有设备和规则 |
| Bucket(桶) |
容器层级 |
root → datacenter → room → rack → host |
| 故障域(Failure Domain) |
数据隔离的层级 |
host、rack、row、room |
| CRUSH Rule |
数据放置规则 |
副本数、故障域约束 |
| Placement Group (PG) |
数据映射的逻辑单元 |
每个池有若干 PG |
数据映射流程
File → Object → (pool_id, object_id) → CRUSH(pgid) → [OSD1, OSD2, OSD3]
↑ ↑ ↑
文件拆分为对象 通过哈希确定 PG CRUSH 计算 OSD 列表
# 查看 CRUSH Map
ceph osd getcrushmap -o /tmp/crushmap.bin
crushtool -d /tmp/crushmap.bin -o /tmp/crushmap.txt
cat /tmp/crushmap.txt
1.4 Ceph 集群核心组件
| 组件 |
全称 |
数量建议 |
职责 |
| MON |
Monitor |
3 或 5(奇数) |
维护集群状态映射(cluster map) |
| OSD |
Object Storage Daemon |
每块盘一个 |
存储数据、处理复制、恢复、再平衡 |
| MGR |
Manager |
2(Active/Standby) |
提供监控接口、运行管理模块 |
| MDS |
Metadata Server |
2+ (CephFS 用) |
管理 CephFS 元数据 |
| RGW |
RADOS Gateway |
2+ |
提供 S3/Swift 对象存储接口 |
组件交互流程
1. Client 向 MON 获取最新 Cluster Map
2. Client 根据 CRUSH 算法计算数据位置
3. Client 直接与目标 OSD 通信读写数据
4. Primary OSD 负责复制到 Secondary OSDs
5. OSD 定期向 MON 汇报状态
6. MGR 收集指标供监控使用
1.5 适用场景与不适用场景
✅ 适用场景
| 场景 |
说明 |
使用接口 |
| 云平台后端存储 |
OpenStack / Proxmox 虚拟机磁盘 |
RBD |
| Kubernetes 持久化存储 |
PVC 动态供给 |
RBD / CephFS |
| 对象存储 |
图片/视频/备份/大数据 |
RGW (S3) |
| 共享文件系统 |
多节点共享读写 |
CephFS |
| 大数据分析 |
HDFS 替代方案 |
CephFS / RADOS |
| 邮件/数据库存储 |
需要块设备的场景 |
RBD |
❌ 不适用场景
| 场景 |
原因 |
替代方案 |
| 超低延迟(<1ms) |
网络和复制开销 |
本地 NVMe / Redis |
| 小文件海量存储 |
元数据开销大 |
SeaweedFS / MinIO |
| 3 节点以下集群 |
可靠性不足 |
单机存储 / 云盘 |
| 简单文件共享 |
部署和运维复杂度高 |
NFS / SMB |
| 实时流处理 |
延迟不可预测 |
本地 SSD + 应用层优化 |
1.6 Ceph vs MinIO 对比分析
| 对比维度 |
Ceph |
MinIO |
| 存储类型 |
统一存储(块+文件+对象) |
纯对象存储 |
| 架构 |
分布式、去中心化 |
分布式、去中心化 |
| 协议 |
S3/Swift/块/文件 |
S3 兼容 |
| 最小节点 |
3 节点(推荐) |
4 节点(纠删码模式) |
| 数据保护 |
副本 / 纠删码 |
纠删码(Reed-Solomon) |
| 元数据 |
RADOS 内部管理 |
目录结构 |
| 小文件性能 |
一般 |
较好 |
| 大文件性能 |
优秀 |
优秀 |
| 运维复杂度 |
高 |
低 |
| 学习曲线 |
陡峭 |
平缓 |
| 社区/生态 |
极其成熟(2004 年起) |
较新(2016 年起) |
| 适用规模 |
PB~EB 级 |
TB~PB 级 |
| 企业支持 |
Red Hat、SUSE |
MinIO Inc. |
| 许可证 |
LGPL |
AGPL v3 |
选型建议
需要块存储/文件存储? ──是──→ Ceph
│
否
↓
只需对象存储?
│
├─ 规模 > 1PB 且有运维团队 → Ceph RGW
│
└─ 规模 < 1PB 且追求简单 → MinIO
1.7 业务场景示例
场景一:OpenStack 云平台
┌─────────────────────────────────┐
│ OpenStack │
│ Nova ←→ Cinder ←→ Ceph RBD │
│ Glance ←→ Ceph RBD │
│ Swift ←→ Ceph RGW │
└─────────────────────────────────┘
场景二:Kubernetes 持久化存储
# StorageClass 示例
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ceph-rbd
provisioner: rbd.csi.ceph.com
parameters:
clusterID: <cluster-id>
pool: kubernetes
imageFormat: "2"
imageFeatures: layering
reclaimPolicy: Delete
allowVolumeExpansion: true
场景三:视频监控存储
摄像头 → NVR → Ceph RGW (S3 API) → 生命周期管理自动降级/删除
↓
30天后转低频存储
90天后自动删除
1.8 快速验证环境
# 使用 cephadm 快速创建测试集群(单节点)
sudo cephadm bootstrap --mon-ip 192.168.1.10
# 检查集群状态
sudo ceph -s
# 预期输出
# cluster:
# id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
# health: HEALTH_OK
#
# services:
# mon: 1 daemons, quorum node1
# mgr: node1.xxxx(active)
#
# data:
# pools: 1 pools, 1 pgs
# objects: 0 objects, 0 B
# usage: 0 B used, 0 B / 0 B avail
# pgs: 1 active+clean
扩展阅读
- Ceph 官方文档
- CRUSH 论文原文
- Ceph Architecture Deep Dive
- Red Hat Ceph Storage Guide
- 《Ceph 分布式存储实战》— 李志云 等著
下一章:02 - 安装与部署 — 学习使用 cephadm、手动部署、ROOK 等多种方式安装 Ceph 集群。