Ceph中文文档与集群部署运维实战：从cephadm到排障

简介：这份资料是Ceph存储集群部署的完整中文参考文档包，面向Linux运维工程师、云平台架构师及希望深入理解Ceph对象存储、块设备与文件系统的技术人员。内容围绕节点部署、网络配置和存储集群初始化展开，覆盖配置示例、脚本工具与排错思路，适合从入门到进阶的读者按需查阅。压缩包共482个文件，大小约4.04MB，其中以346个rst格式文档为主，辅以txt说明、conf配置文件、sh脚本、png/jpg架构图及少量代码文件，便于对照学习和实际部署。已有419人学习下载。借助这份资料，读者可系统掌握Ceph集群的配置要点、常用命令与最佳实践，节省自行摸索的时间，快速搭建稳定可用的存储环境。 搞Ceph的人应该都有个相同的痛点：官方文档全是英文，中文资料又散落在各个博客和个人笔记里，年代久远版本还对不上。尤其是第一次接触分布式存储的运维，光是在CentOS上敲ceph-deploy装个集群，就能被各种依赖和版本问题搞得怀疑人生。我这两年经手了不少Ceph集群的搭建和排障，踩过的坑比写过的文档都多，这篇就把Ceph中文文档怎么用、集群怎么部署、日常怎么运维、出了问题怎么排查，一次说清楚。不管是刚入行的新人，还是被Ceph折磨得睡不着的运维老哥，这篇应该都能帮上忙。

1. 内容整体设计与思路拆解

1.1 先把“中文文档”这件事想明白

很多人一上来就问“Ceph中文文档在哪”，其实这个问题本身就有点误区。Ceph的官方文档地址是docs.ceph.com，官方提供了多语言版本，中文翻译一直都在推进，但翻译进度和更新时效永远赶不上英文原版。我之前对比过，中文版在核心架构、基础运维这些章节还算完整，到了新版本的功能特性、某些冷门组件的配置参数，中文文档就缺胳膊少腿了。

所以我的建议是：中文文档用来建立整体认知和入门理解，英文文档用来查具体参数和排障细节，两者搭配着看，不要指望某一方解决所有问题。另外一个很容易踩的坑是版本对应关系。Ceph的文档地址里一般会标出版本，比如docs.ceph.com/en/quincy/、/en/reef/、/en/squid/，不同版本的配置项、命令语法、甚至默认行为都会有差异。你在CentOS 7上装的是Luminous，结果照着Pacific的文档去敲命令，那不出问题才怪。

提示：打开官方文档第一步先确认右上角版本号对不对，这个细节能帮你避开大量“文档和版本不匹配”的坑。

1.2 方案选型背后的逻辑

在部署方案上，很多老教程还在教ceph-deploy，这个工具其实已经停止维护了，新版本Ceph根本不再支持。我最早学Ceph的时候也是从ceph-deploy入门的，那时候装个集群要手动配一堆东西，每台机器敲好几条命令，装完还经常因为SSH权限、hostname解析之类的问题起不来。后来Ceph官方推出了cephadm，这玩意儿才是现在的主流部署方式。它通过容器方式部署和管理集群，一条命令就能拉起MON和MGR，对整个集群做健康检查、升级、扩容，都能从命令行直接操作，比老古董省心太多。

所以在设计这篇内容的时候，我决定采用“以cephadm为主、兼顾旧版本迁移场景”的思路来讲部署，同时在日常运维和排障环节，把最常用的命令和判断思路梳理出来。这样既能让新手走一条最平坦的路，也能让正在维护老集群的人找到参考。

2. 核心细节解析与实操要点

2.1 部署前必须搞清楚的基础概念

Ceph的几个核心组件必须先建立概念：MON（Monitor）负责维护集群的映射信息和状态，是集群的“大脑”，一般至少部署3个形成奇数；OSD（Object Storage Daemon）负责实际数据存储，每块磁盘对应一个OSD进程；MGR（Manager）负责提供监控接口和部分管理功能，一般部署2个；MDS（Metadata Server）只有在用CephFS文件系统时才需要。

打个比方，MON就像小区物业的登记本，谁在哪栋楼几号房都记录得清清楚楚；OSD就是那一栋栋的储物间，数据就存在里面；MGR是物业的监控大屏，方便你随时看整个小区的运行状态。理解了这几个角色，后面所有命令和操作都围绕它们展开，逻辑就顺了。

部署规划时还有几个硬指标要提前想清楚：网卡建议至少千兆，有条件直接上万兆，因为数据复制和恢复都在内网跑，带宽不够的话，一个OSD挂掉再恢复，能把整个集群拖到卡死。时间同步必须做，Ceph对时钟偏移极其敏感，MON之间的时间偏差超过阈值就会导致集群状态异常，我见过不少集群莫名其妙报错，最后发现就是没有配置NTP。

2.2 使用cephadm部署的完整步骤

如果你用的是CentOS 7以上的系统，先把系统基础环境搞定。以CentOS Stream 9为例，基本的流程是这样的：先确保各节点hostname唯一且能互相解析，关闭防火墙和SELinux，配好时间同步，然后在第一台机器上安装cephadm工具。

# 设置hostname hostnamectl set-hostname ceph-node1 # 关闭防火墙和SELinux（生产环境根据安全策略决定，测试环境建议关闭） systemctl stop firewalld && systemctl disable firewalld sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config # 安装cephadm dnf install -y python3 curl --silent --remote-name --location https://download.ceph.com/rpm-reef/el9/noarch/cephadm chmod +x cephadm ./cephadm add-repo --release reef ./cephadm install

接下来就是引导集群。这里要注意，cephadm bootstrap会在当前节点上自动部署第一个MON和MGR，并生成一个dashboard的登录地址和密码。引导之后，就可以用ceph orch host add把其他节点加进来，再用ceph orch apply osd来创建OSD。

# 在当前节点引导集群 cephadm bootstrap --mon-ip 192.168.1.10 # 把其他节点加进集群 ceph orch host add ceph-node2 192.168.1.11 ceph orch host add ceph-node3 192.168.1.12 # 给所有可用磁盘创建OSD ceph orch apply osd --all-available-devices

这里有个细节值得单独说：--all-available-devices会把节点上所有没有分区的裸盘都做成OSD，如果你机器上有系统盘之外的数据盘，没问题；但如果机器上还有其他不想交给Ceph的磁盘，一定要用ceph orch device zap先清盘，或者在apply的时候用--dry-run看看它打算拿哪些盘下手，别一个命令下去把自己不想交出去的盘全给格式化了。我之前就见过有人把存着备份数据的盘给Ceph吞了，那场面，真的欲哭无泪。

3. 实操过程与核心环节实现

3.1 日常巡检常用命令集合

集群部署完成后，绝大多数时间都花在日常巡检和状态查看上。我每次上服务器，固定流程就是几条命令走一遍：ceph -s看集群整体状态，ceph osd tree看OSD的层次结构和在线状态，ceph osd df看各OSD的容量使用情况，ceph df看存储池的用量和配额。

这里重点说说ceph osd tree，因为很多人第一次看到它的输出会有点懵。它输出的是一个树状结构，大致分为几层：host表示物理节点，下面挂着的就是该节点上的OSD。每行最后的状态字段很重要，up表示OSD进程活着，down表示进程挂了，in表示该OSD在集群中参与数据分布，out表示被移出集群。正常状态的组合是up和in同时存在，如果你看到down或者out，就需要进一步排查了。

# 查看集群整体状态 ceph -s # 查看OSD树状结构和状态 ceph osd tree # 查看OSD容量使用情况 ceph osd df # 查看存储池用量 ceph df

还有一个命令是ceph osd perf，可以看每个OSD的提交延迟和操作延迟。正常情况延迟应该很低，如果在某个OSD上看到延迟飙高，那这块盘的IO大概率有问题了，建议提前关注，别等到它彻底挂了才处理。日常巡检我基本上一天跑一次这几条命令，再配合Prometheus监控长期趋势，小问题基本都能在发酵成大故障之前处理掉。

3.2 配置与应用场景的核心实现

再说说存储池的应用。Ceph三大接口——块存储RBD、文件存储CephFS、对象存储RGW，分别对应不同的使用场景。我接触最多的是RBD，也就是给OpenStack或者虚拟化平台提供块设备。通过ceph osd pool create创建存储池后，用rbd create创建块设备，再通过rbd map映射到宿主机上，就能像一个普通磁盘一样使用了。

# 创建存储池 ceph osd pool create mypool 128 128 # 在存储池中创建块设备 rbd create --size 10G mypool/test-image # 映射块设备到宿主机 rbd map mypool/test-image # 查看映射后的设备名 rbd showmapped

mypool后面的128 128，是PG数量和PGP数量。很多新手在这里栽跟头：PG数量设置过大或者过小都会造成问题。过小，单个PG承载的数据量太大，数据分布不均匀；过大，PG本身的元数据开销高，集群状态收敛慢。一个粗略的经验法则是：每个OSD承载100～200个PG，然后按总PG数反推。比如你有10个OSD，那1000到2000个PG大概就是比较合理的范围。这个计算方式不算严谨，但作为初始设定够用了，后面可以通过ceph osd pool set动态调整PG数量。

3.3 OSD故障后的标准处理流程

运维中遇到最多的问题，就是“ceph osd tree”里某个OSD的状态变成了down。处理步骤我总结成一套固定的流程，照着走基本不会乱。

第一步，先看磁盘能否识别。登录到对应的节点上，执行lsblk查看磁盘是否还在，再用ceph orch device ls查看ceph是否还能监控到该设备信息。如果磁盘整个消失了，大概率是硬件层面的问题，比如线松了、盘坏了、卡识别不到了，该报修报修。

第二步，确认是单盘故障还是整节点故障。如果整个节点的多个OSD全部down，那就不是盘的问题，而是节点宕机或者网络隔离了。这种时候先恢复节点，节点恢复后OSD一般会自动重新上线。

第三步，如果单盘故障确定，可以尝试强制重启OSD进程：

# 重启指定OSD ceph orch daemon restart osd.5

重启不起作用的时候，说明磁盘确实有问题，需要走替换流程：先把故障OSD标记为out，让集群开始数据迁移，等数据在其他OSD上重新分布完成后再把该OSD从集群中移除，然后换上新的磁盘重新创建OSD。

# 将OSD标记为out，触发数据迁移 ceph osd out osd.5 # 等待集群状态变为active+clean后，移除OSD ceph osd purge osd.5 --yes-i-really-mean-it

注意：purge命令一定要确认数据已经迁移完成再执行，否则会造成数据副本数量不足甚至数据丢失。判断标准是执行ceph -s后，PG状态里没有degraded或backfilling，整体回到HEALTH_OK。

4. 常见问题与排查技巧实录

4.1 “osd tree down”的典型案例复盘

有一次巡检，我看到一个生产集群的ceph -s报了HEALTH_WARN，点开ceph osd tree发现osd.7的状态是down。我第一反应是磁盘挂了，但登上去lsblk一看，盘还在，smart信息也正常。这就奇怪了。

后来仔细看节点的系统日志，发现是内核报了一堆IO错误，磁盘的SATA链路出了间歇性故障，导致OSD进程因为IO等待超时被Ceph判定为down。这种问题有个特点：你重启OSD它又能起来，但过一段时间又会重复掉下去。最后的处理方案是更换SATA数据线，同时把该OSD强制重新上线观察一段时间，确认问题不再复发。

这个案例说明一个问题：osd tree down并不等于磁盘物理损坏，有可能只是链路问题、驱动问题或者节点资源不足导致的进程被杀。在动手替换磁盘之前，先把日志翻一遍，能省下很多不必要的盘体更换成本。

4.2 常见的PG状态异常处理

PG（Placement Group）是Ceph数据分布的基本单位，PG状态异常是排障时的另一个大头。ceph -s里如果看到PG状态是peered、degraded、backfilling、recovery这些词，都不用太慌，这通常是数据在重新分布的必经阶段。但如果你看到stuck inactive、stuck unclean，那就是有问题了，说明某些PG长期无法恢复。

处理思路是：先用ceph pg dump_stuck找出卡死的PG，再用ceph pg map <pgid>看它对应的OSD组合，然后重点检查这些OSD的状态。很多卡死问题都是因为某个OSD不可用又没有被标记为out，导致PG无法完成peering。把故障OSD标记为out或者直接purge之后，PG通常能自动恢复。

# 找出卡死的PG ceph pg dump_stuck # 查看某个PG的分布和状态 ceph pg map 1.2c # 查看PG的详细状态 ceph tell 1.2c query

4.3 常见问题速查表

5. 避坑经验与操作心得

5.1 文档记录与版本管理的心得

我自己的习惯是，在搭建和维护集群的过程中，把所有关键操作、命令、参数和踩坑记录整理成一份内部的中文运维手册。这份手册以官方文档为骨架，以实际操作为血肉，记录每一台机器的配置差异、每一次故障的处理过程、每一条命令在真实环境下的输出表现。坚持了一年多之后，这份手册的价值已经超过了网上能找到的绝大多数Ceph中文文档，因为它完全贴合自己的环境。

这里也想给新人一个建议：不要死记命令，而是要理解命令背后查的是什么。ceph -s输出的每一项代表什么状态，ceph osd tree里的每个字段是什么含义，把这些底层逻辑搞清楚了，遇到问题才能举一反三。

5.2 几条保命的运维习惯

第一条，任何涉及数据删除、OSD移除的操作，先在测试环境演练一遍。purge、osd out这类命令在生产环境的破坏力比我见过的大多数误操作都强，演练一遍能让你熟悉参数含义，也能顺带确认自己的操作流程没有遗漏。

第二条，磁盘更换之前先备份OSD的标识信息。虽然Ceph的重建机制能自动把新盘拉进集群，但如果数据副本数不够，重建期间一旦再坏一块盘，就是数据丢失级别的灾难。所以操作之前，先ceph osd tree截图留底，确认当前集群健康状况，再动手。

第三条，关注磁盘的剩余寿命。smartctl定时任务跑起来，结合Ceph自身的延迟监控，把潜在的磁盘故障提前预判。多数磁盘故障不是瞬间发生的，前兆往往在smart信息里已经体现出来了，定期查看能帮你避开半夜被电话叫醒的悲剧。我个人的经验习惯是每周自动跑一次smart检查，把结果发到运维群，小问题早发现早处理，集群寿命能长不少。

最后再分享一个小技巧：遇到Ceph相关的问题，先用ceph log看日志，不要一上来就乱猜。日志路径一般在/var/log/ceph/，里面有每个组件单独的日志文件，重点看ceph-mon和ceph-osd的日志，基本上90%的问题根因都能在日志里找到线索。把日志和ceph -s的状态信息结合起来分析，排查效率会高很多。

本文还有配套的精品资源，点击获取