Ceph基础与部署

Ceph 是分布式存储系统，可以同时提供块存储、文件存储和对象存储。底层数据不是放在某一台“主存储服务器”上，而是通过 CRUSH 算法分散到多台机器的 OSD 里，再按副本或纠删码策略保证可用性。

Ceph 的学习门槛比 NFS 高很多。它不是“装一个服务端、客户端挂载目录”这种模型，而是一套由 MON、MGR、OSD、Pool、PG、CRUSH、认证和客户端接口组成的集群。运维时最常看的不是某个进程是否启动，而是 ceph -s 里的健康状态、OSD 状态、PG 状态、容量和恢复进度。

一、Ceph 组件

Ceph 基本组件：

组件	作用	运维关注
MON	保存集群拓扑、认证和关键状态	quorum、时钟、网络
MGR	管理模块、Dashboard、指标	prometheus 模块、dashboard
OSD	真正存数据的守护进程，一块盘通常对应一个 OSD	磁盘、延迟、容量、down/out
MDS	CephFS 元数据服务	文件系统目录元数据
RGW	S3/Swift 对象网关	bucket、用户、访问密钥

基本关系：

客户端从 MON 拿集群地图和认证信息，然后直接和 OSD 读写数据。这个点和很多传统存储不同：MON 不是数据转发代理，OSD 才是真正承载 IO 的地方。

二、Pool、PG 和 CRUSH

Pool 可以理解成 Ceph 里的逻辑存储池。RBD 镜像、CephFS 数据、RGW 对象最终都会落到某个 Pool 里。

PG 是 Placement Group，介于 Pool 和 OSD 之间。Ceph 不会直接把每个对象逐个映射到 OSD，而是先把对象映射到 PG，再把 PG 映射到一组 OSD。PG 数量影响数据分布、恢复速度和集群开销。

CRUSH 是 Ceph 的数据放置算法。它根据规则决定数据应该放到哪些 OSD、主机、机架或故障域里。

常见概念：

概念	说明
size	副本数，比如 3 表示三副本
min_size	允许 IO 的最小副本数
pg_num	Pool 的 PG 数量
failure domain	故障域，比如 host、rack、room
CRUSH rule	数据按什么故障域分布

三副本 Pool 不是“一个主两个从”。Ceph 会把每个 PG 放到多个 OSD 上，其中有 primary OSD 负责协调这个 PG 的 IO。OSD 故障后，Ceph 会按 CRUSH 重新恢复副本。

三、部署规划

实验环境至少 3 台节点更接近真实 Ceph：

主机	IP	角色
ceph01	192.168.10.41	MON、MGR、OSD
ceph02	192.168.10.42	MON、MGR、OSD
ceph03	192.168.10.43	MON、MGR、OSD

每台至少准备一块独立数据盘，比如 /dev/sdb。OSD 盘会被 Ceph 接管，原有数据会清空。

基础要求：

项目	说明
时间同步	MON quorum 对时间偏差敏感
主机名解析	节点之间能通过主机名互相访问
网络	存储网络延迟和带宽影响明显
磁盘	OSD 数据盘独立，避免和系统盘混用
容器运行时	cephadm 以容器方式部署 Ceph 守护进程
SSH	cephadm 需要免密管理节点

生产里 Ceph 的磁盘、网络和故障域要提前规划。随便拿几台业务机器拼一个 Ceph，后面容量、恢复和性能都会很难看。

四、版本和安装方式

官方推荐的新集群安装方式是 cephadm。它用容器运行 Ceph 守护进程，并通过 orchestrator 管理 MON、MGR、OSD 等服务。

Ceph 长期笔记里更适合用版本变量。官方文档有 latest 页面，但 latest 更偏当前开发文档；实际部署选择稳定发行版，比如 reef、squid 这类 release 名称，再按对应系统版本配置仓库。

# release 按实际稳定版本选择，比如 reef / squid
CEPH_RELEASE=squid

# RHEL/Rocky/CentOS 要让系统版本和 Ceph 仓库路径匹配
curl --silent --remote-name --location "https://download.ceph.com/rpm-${CEPH_RELEASE}/el9/noarch/cephadm"
chmod +x cephadm
./cephadm add-repo --release "${CEPH_RELEASE}"
./cephadm install

Ubuntu/Debian 类系统也可以用 cephadm 脚本安装，版本和仓库要按发行版对应调整。内网环境一般会提前准备三类东西：

项目	说明
软件仓库	cephadm、ceph-common 等包
容器镜像	MON、MGR、OSD、MDS、RGW 等镜像
registry 配置	cephadm 拉镜像时使用内网仓库

公网能装通不代表生产能装通。生产环境更常见的问题是节点无法出网、镜像仓库证书不被信任、代理配置没有传到 cephadm 管理的容器里。

引导第一个 MON/MGR：

# mon-ip 写第一台节点的管理网 IP，后续节点会加入这个集群
cephadm bootstrap --mon-ip 192.168.10.41

有独立集群网络时，bootstrap 可以把 public network 和 cluster network 写清楚：

# public network 给客户端和 MON 通信，cluster network 给 OSD 复制和恢复流量
cephadm bootstrap \
  --mon-ip 192.168.10.41 \
  --cluster-network 10.10.10.0/24

小集群没有独立存储网络也能跑，但恢复、backfill 和业务 IO 会抢同一张网卡。Ceph 集群规模上来以后，网络规划会直接影响故障恢复时的业务抖动。

bootstrap 完成后会生成：

文件 / 信息	作用
/etc/ceph/ceph.conf	Ceph 客户端配置
/etc/ceph/ceph.client.admin.keyring	admin 认证 key
Dashboard 地址和账号	Web 管理入口
cephadm SSH key	后续管理其他节点

安装命令行工具：

cephadm install ceph-common
ceph -s

ceph -s 是 Ceph 运维最常用入口。状态正常时应该能看到 MON quorum、MGR active、OSD 数量、Pool/PG 状态和容量。

五、加入节点

cephadm 通过 SSH 管理其他节点。先把公钥拷到节点：

# 查看 cephadm 管理用公钥
ceph cephadm get-pub-key

把这段公钥加入 ceph02、ceph03 的 root 用户 authorized_keys，再添加主机：

# _admin 标签表示这个节点会自动下发 ceph.conf 和 admin keyring
ceph orch host add ceph02 192.168.10.42 --labels _admin
ceph orch host add ceph03 192.168.10.43 --labels _admin

ceph orch host ls

查看服务：

ceph orch ps
ceph orch ls

如果主机加入失败，常见原因是 SSH 不通、主机名解析异常、Python/容器运行时缺失、目标节点时间不同步。

MON 数量一般保持奇数，3 个 MON 是常见起点。MON 不是越多越好，数量多了 quorum 通信和故障判断也会更复杂；普通中小集群 3 个 MON 已经能覆盖一台控制节点故障。

六、创建 OSD

查看可用磁盘：

# Available 为 Yes 的设备才能被直接创建 OSD
ceph orch device ls

把所有可用盘加入 OSD：

# 会清空被接管磁盘上的数据，执行前确认设备没有业务数据
ceph orch apply osd --all-available-devices

也可以指定某台主机某块盘：

ceph orch daemon add osd ceph01:/dev/sdb
ceph orch daemon add osd ceph02:/dev/sdb
ceph orch daemon add osd ceph03:/dev/sdb

查看 OSD：

ceph osd tree
ceph osd df
ceph -s

OSD 状态里 up 表示进程在，in 表示参与数据分布。down 是守护进程不可用，out 是 Ceph 不再把数据分配给它。故障处理时要区分这两个状态。

七、OSD 故障和替换

OSD 故障通常先从 ceph -s 或监控里看到：

ceph -s
ceph health detail
ceph osd tree
ceph osd df

定位到节点后看磁盘和守护进程：

# 看 OSD 容器或 systemd 状态
ceph orch ps --daemon_type osd

# 到对应节点看磁盘、内核日志和 SMART
lsblk
dmesg | grep -iE 'error|fail|nvme|sd[a-z]' | tail -50
smartctl -a /dev/sdb

坏盘替换的大致顺序：

# 确认这个 OSD 是否可以安全销毁，避免副本不足时继续操作
ceph osd safe-to-destroy osd.<id>

# 如果已经安全，清理 OSD 守护进程和 CRUSH/认证记录
ceph orch osd rm <id> --replace
ceph orch osd rm status

换盘后重新加入：

# 新盘出现后确认 Available 为 Yes
ceph orch device ls

# 用新盘创建 OSD
ceph orch daemon add osd <host>:/dev/sdb

有些故障是磁盘慢但还没彻底坏，表现为 slow ops、OSD apply/commit latency 高。这个时候只看 up/in 会误判成正常，ceph osd perf 和磁盘延迟更有参考价值。

OSD 被移除或新增后会触发 recovery/backfill。恢复期间业务 IO、OSD 磁盘和集群网络都会变忙：

ceph -s
ceph pg stat
ceph osd perf

需要临时控制恢复强度时，可以调整恢复参数：

# 降低恢复并发，减少对业务 IO 的影响；具体值要按集群规模压测
ceph config set osd osd_max_backfills 1
ceph config set osd osd_recovery_max_active 1

恢复太慢会延长降级时间，恢复太快又可能把业务 IO 打满。这个参数不是“一劳永逸”的固定值，更适合在故障恢复现场结合业务压力临时调整，恢复后再复查。

八、Pool 创建

创建一个三副本 Pool：

# 这里 pg_num 用 32 只是小集群示例，生产要按 OSD 数量和数据规模规划
ceph osd pool create rbd-pool 32
ceph osd pool set rbd-pool size 3
ceph osd pool set rbd-pool min_size 2

启用 RBD 应用类型：

ceph osd pool application enable rbd-pool rbd

查看 Pool：

ceph osd pool ls detail
ceph pg stat

Pool 的副本数直接影响可用容量。三副本大致是 3T 原始容量提供 1T 可用容量，还要预留恢复和水位空间。Ceph 集群长期跑到 85% 以上，恢复、重平衡和写入都会变得紧张。

九、健康状态

ceph -s 常见状态：

状态	含义
HEALTH_OK	当前无健康告警
HEALTH_WARN	有风险或待处理告警
HEALTH_ERR	严重问题，可能影响 IO 或数据冗余

常见告警：

告警	方向
OSD_DOWN	OSD 进程挂了、节点异常、磁盘异常
PG_DEGRADED	副本不足，正在恢复或有 OSD 不可用
PG_STUCK	PG 长时间不活跃或不干净
MON_CLOCK_SKEW	MON 节点时间不同步
NEARFULL / FULL	OSD 或 Pool 容量水位过高
SLOW_OPS	磁盘、网络或 OSD 队列慢

查看详细健康信息：

ceph health detail
ceph -s
ceph osd tree
ceph pg dump_stuck

我个人排 Ceph 故障时习惯从 ceph -s 和 ceph health detail 开始。直接冲到某台机器看日志容易迷路，因为 Ceph 的问题通常是集群状态和单机状态叠在一起。

十、容量和恢复

查看容量：

ceph df
ceph osd df tree

容量里要区分：

项目	说明
RAW STORAGE	原始磁盘容量
POOLS	Pool 逻辑使用量
%RAW USED	原始容量使用比例
MAX AVAIL	按当前 CRUSH 和副本策略估算的可用容量

OSD 故障后，Ceph 会恢复副本。恢复会消耗磁盘和网络资源：

ceph -s
ceph pg stat
ceph osd perf

恢复期间业务 IO 可能变慢。生产集群要在业务高峰、恢复速度和数据冗余之间取舍，恢复太慢风险时间长，恢复太快可能把业务 IO 打满。

十一、Dashboard 和监控

cephadm bootstrap 默认会启用 Dashboard。查看服务：

ceph mgr services

Prometheus 模块：

# mgr prometheus 模块会暴露 Ceph 指标，通常给 Prometheus 抓取
ceph mgr module enable prometheus
ceph mgr services

日常监控重点：

指标	说明
OSD up/in	OSD 是否在线并参与数据分布
PG active+clean	PG 是否健康
容量水位	OSD、Pool、集群整体使用率
延迟	OSD apply/commit latency
recovery/backfill	是否在恢复或重平衡
slow ops	慢操作数量和持续时间

Ceph 监控里容量告警要留足提前量。等到 FULL 才处理，写入会被阻塞，扩容和数据迁移也更被动。

十二、常见排查入口

集群状态：

ceph -s
ceph health detail
ceph orch ps

OSD：

ceph osd tree
ceph osd df
ceph osd perf

PG：

ceph pg stat
ceph pg dump_stuck

日志：

# cephadm 部署的守护进程跑在容器里，日志可以通过 cephadm 或 journalctl 看
cephadm logs --name osd.<id>
journalctl -u ceph-*.service -n 200 --no-pager

常见现象：

现象	方向
ceph -s 卡住	MON 不可达、认证文件缺失、网络问题
OSD down	节点、磁盘、容器、网络
PG degraded	OSD 不足、恢复中、CRUSH 分布异常
写入慢	OSD 延迟、磁盘、网络、恢复任务
nearfull	数据分布不均、容量不足、某些 OSD 太小
Dashboard 打不开	MGR 模块、端口、防火墙、证书
OSD 一直无法删除	仍有 PG 副本依赖，查看 safe-to-destroy
恢复很慢	backfill/recovery 参数、网络、目标 OSD 延迟

Ceph 的“健康”包含进程、PG、OSD、容量和恢复状态。systemctl 全绿但 PG degraded、OSD nearfull，业务读写一样会受影响。