简介这份资料是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的几个核心组件必须先建立概念MONMonitor负责维护集群的映射信息和状态是集群的“大脑”一般至少部署3个形成奇数OSDObject Storage Daemon负责实际数据存储每块磁盘对应一个OSD进程MGRManager负责提供监控接口和部分管理功能一般部署2个MDSMetadata 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/SELINUXenforcing/SELINUXdisabled/ /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 showmappedmypool后面的128 128是PG数量和PGP数量。很多新手在这里栽跟头PG数量设置过大或者过小都会造成问题。过小单个PG承载的数据量太大数据分布不均匀过大PG本身的元数据开销高集群状态收敛慢。一个粗略的经验法则是每个OSD承载100200个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 # 等待集群状态变为activeclean后移除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状态异常处理PGPlacement 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 query4.3 常见问题速查表现象可能原因排查/处理建议ceph -s显示 HEALTH_WARN某个OSD down、PG分布不均、时钟偏移用ceph health detail查看具体告警源针对性处理osd tree中某个OSD为down磁盘故障、链路问题、进程被杀lsblk确认盘是否存在看系统日志重启OSD或更换硬件集群recovery时性能下降数据迁移占用了大量IO和网络带宽用ceph osd pool set调整backfill和recovery的限速参数MON时钟偏移告警未配置NTP或NTP失效检查chronyd状态确保所有节点时间同步修改配置不生效改了ceph.conf但未推送到所有节点cephadm部署用ceph config set修改不要手动改/etc/ceph/ceph.conf5. 避坑经验与操作心得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的状态信息结合起来分析排查效率会高很多。本文还有配套的精品资源点击获取