Ceph系列第一期：Ceph分布式存储核心概念与架构初识

本期目标

理解Ceph是什么、技术优势与典型使用场景
掌握Ceph的核心组件（RADOS、OSD、MON、MGR、MDS）
了解Ceph中的用户角色与职责划分
理解Ceph的数据寻址机制（CRUSH算法）以及读写流程
为后续的部署和管理打下理论基础

1. Ceph简介

Ceph是一款开源的、分布式、软件定义存储（SDS）系统。它具备极高的可用性 、扩展性 和易用性，旨在存储海量数据。

可部署在通用服务器上（支持x86和ARM架构）
支持在同一集群内混合使用不同架构的主机
核心设计理念：去中心化，客户端可直接计算出数据存储位置

软件定义存储（SDS）：将存储硬件资源抽象化，通过软件实现存储服务的自动化管理和扩展。

2. Ceph的技术优势

特点	说明
RADOS核心	将所有数据作为对象，存储在存储池中
去中心化	客户端基于CRUSH算法自行计算对象位置，避免中心节点瓶颈
自我管理	集群自动进行扩展、数据再平衡、故障恢复

3. Ceph的发展历史

2003-2007：加州大学圣克鲁兹分校Sage Weil博士项目，Ceph文件系统原型（约4万行C++代码）
2006：遵循LGPL协议开源
2012：成立Inktank公司，提供Ceph专业服务
2014：Red Hat收购Inktank，Ceph成为红帽存储产品核心
目前已与Linux内核、OpenStack、Kubernetes等深度集成

上游版本命名规则（自Infernalis起）

版本格式：x.y.z
- x：发布周期（例如16代表Pacific）
- y：类型（0=开发版，1=候选版，2=稳定版）
- z：修订号
从Nautilus（14.2.0）开始，每年3月1日发布一个稳定版本，生命周期约2年

LTS版本与红帽RHCS产品生命周期保持一致。

4. Ceph架构总览

Ceph采用模块化分布式架构 ，核心是RADOS（可靠自主分布式对象存储）。

text

复制代码

┌─────────────────────────────────────────────────────────┐
│                    接入层（多种访问方式）                   │
├──────────────┬───────────────┬──────────────┬───────────┤
│   RBD块设备   │   RGW对象网关  │   CephFS文件系统 │  librados │
│  (librbd)    │  (libradosgw) │  (libcephfs)  │  原生API   │
└──────┬───────┴───────┬───────┴───────┬───────┴─────┬─────┘
       │               │               │             │
       └───────────────┴───────────────┴─────────────┘
                       │
               ┌───────▼───────┐
               │    RADOS      │ （对象存储核心）
               └───────┬───────┘
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
      MON            MGR            OSD
   (监视器)        (管理器)      (对象存储设备)
        │              │              │
        └──────────────┴──────────────┘
                    │
              ┌─────▼─────┐
              │   MDS    │ （仅CephFS需要）
              └──────────┘

4.1 核心组件说明

组件	全称	功能描述
RADOS	Reliable Autonomic Distributed Object Store	可靠自主分布式对象存储，Ceph的基石，负责对象的存储、复制、恢复、再平衡
OSD	Object Storage Device	负责存储数据，处理数据复制、恢复和再平衡。每个磁盘通常对应一个OSD守护进程
MON	Monitor	维护集群状态映射（包括MON映射、OSD映射、PG映射等），通过Paxos算法保证一致性
MGR	Manager	跟踪运行时指标，提供Dashboard和REST API，辅助集群管理
MDS	Metadata Server	仅用于CephFS，管理文件元数据（目录层次、权限、时间戳等）

4.2 Ceph的三种访问方式

访问方式	接口	典型使用场景
RBD (块设备)	`librbd`	虚拟机磁盘、云平台（OpenStack Cinder）
RGW (对象存储)	`libradosgw` (S3/Swift兼容)	图片、视频、备份归档、大数据
CephFS (文件系统)	`libcephfs` (POSIX兼容)	共享文件存储、HPC场景
librados	原生C/C++/Python/Java等	追求极致性能的应用直接访问RADOS

性能排序：librados > RBD/RGW/CephFS（后者是封装层）

5. Ceph中的用户角色（理解分工）

在生产环境中，通常存在多种存储相关角色。理解这些角色有助于定位管理边界。

角色	主要职责
存储管理员	安装、配置、维护集群；培训架构师；提供灾备方案；自动化集成
存储操作员	日常监控（Dashboard）、更换故障设备、响应告警
云操作员	管理OpenStack/OpenShift等云基础设施，与存储管理员协作
应用架构师	将Ceph布局与应用的资源需求、扩展性和延迟关联
基础架构架构师	设计集群的物理布局（机架、主机、设备）和CRUSH规则
数据中心操作员	负责底层数据中心的供电、网络、物理设备

在小规模组织中，一个人可能承担多个角色（例如既是存储管理员又是架构师）。

6. Ceph数据寻址机制（CRUSH算法）

6.1 为什么需要CRUSH？

传统存储依赖中心查找表（如元数据服务器）定位数据，存在单点瓶颈。
Ceph客户端通过CRUSH算法直接计算出对象所在OSD，无需中心查询。

6.2 关键概念

对象（Object）：Ceph存储的最小单元，包含ID、二进制数据、元数据。
存储池（Pool）：对象的逻辑容器，可设置副本数或纠删码策略。
归置组（Placement Group, PG）：对象的集合，是Pool和OSD之间的中间层。一个PG会映射到一组OSD（acting set）。
CRUSH Map：描述集群的物理拓扑（如host, rack, row, room）和故障域，以及数据分布规则。

6.3 对象 → OSD 的映射流程

text

复制代码

对象ID + 池名称
      │
      ▼
 PG_ID = hash(对象ID) % PG总数   （在指定池内）
      │
      ▼
 CRUSH(PG_ID) → 一组OSD（acting set）
      │
      ▼
 客户端直接与主OSD通信

6.4 为什么PG重要？

PG数量过少：单个PG数据量过大，数据迁移时占用大量带宽。
PG数量过多：集群维护大量PG元数据，消耗CPU和内存。

历史经验公式（仅供参考）：

集群PG总数 = (OSD数 × 100) / 最大副本数
单池PG数 = 集群PG总数 / 池数量
结果取2的N次幂

现代Ceph支持pg_autoscaler模块自动调整PG数量，无需手工精确计算。

7. 客户端读写流程

7.1 读流程

text

复制代码

1. 客户端向MON获取最新集群映射（Cluster Map）
2. 根据Pool + 对象ID计算PG，再通过CRUSH找到主OSD
3. 客户端直接向主OSD发送读请求
4. 主OSD返回数据

7.2 写流程（强一致性）

text

复制代码

1. 客户端获取集群映射，计算主OSD位置
2. 客户端向主OSD发送写请求
3. 主OSD同时向所有副本OSD写入数据
4. 所有副本OSD确认写入后，主OSD向客户端返回确认

性能优化点 ：Ceph采用两次确认机制

第一次：数据写入所有OSD的缓存后，立即向客户端确认（快速响应）
第二次：数据从缓存落盘后，再次确认（可选，用于客户端确认持久化）

8. 数据保护类型

类型	原理	存储效率	CPU开销	适用场景
副本池	每个对象保存N个完整副本	较低（N倍空间）	低	频繁访问、需要低延迟
纠删码池	分成k个数据块 + m个编码块	较高（(k+m)/k倍）	高	冷数据、归档、不频繁访问

池类型一旦创建不可更改。

9. 关键概念速查表（第一期汇总）

术语	解释
RADOS	Ceph的核心分布式对象存储系统
OSD	存储数据的守护进程，每个磁盘对应一个
MON	维护集群映射，实现仲裁
MGR	提供监控和管理接口
MDS	CephFS的元数据服务
PG	归置组，对象的集合，用于分布到OSD
CRUSH	伪随机算法，计算PG到OSD的映射
Pool	存储池，PG的逻辑容器
librados	Ceph原生API，最高性能接口

10. 本期小结

Ceph是一个统一存储系统，同时提供块、文件、对象三种接口。
其核心是RADOS 和CRUSH算法，实现了去中心化的数据分布。
核心组件包括MON、MGR、OSD（必需）和MDS（仅CephFS需要）。
客户端自行计算对象位置，直接与主OSD通信，避免了中心节点瓶颈。
副本池与纠删码池分别适用于热数据和冷数据场景。

下一期预告 ：我们将进入实战环节，使用cephadm工具部署一个完整的Ceph集群，并完成节点添加、OSD部署和Dashboard访问。