企业官网建设流程全解析

简介：面向 Linux 运维、云平台存储与 Ceph 初学者及进阶读者的中文文档合集，聚焦 Ceph 存储集群从节点、网络到集群落地的部署知识，也覆盖对象存储、块设备与文件系统等典型场景，内容涉及集群架构、部署准备、存储池与归置组、对象网关及日常监控运维，适合作为搭建、查阅与排错时的案头参考。压缩包共 482 个文件，约 4.04MB，以 346 个 rst 文档为主体，辅以 76 个 txt 说明、9 个 conf 配置样例、8 个 sh 脚本及少量 png、jpg 图示和 html、py 等辅助文件，目录组织按主题分层，兼顾正文阅读、配置参考与脚本实践。已有 422 人学习。读者可从中获得较完整的 Ceph 中文知识脉络、集群部署配置示例与排错思路，并通过图示和脚本理解组件关系、参数含义及运维要点，便于按主题查阅、对照实践并降低检索成本。

1. 为什么我把一份 Ceph 中文文档当成部署前的必读件

第一次在三台 Linux 机器上敲cephadm bootstrap的人，通常会在十分钟内遇到同一个问题：命令跑通了，ceph -s也返回了HEALTH_OK，但接下来该做什么、那个偶尔冒出来的HEALTH_WARN到底要不要管，没人告诉你。Ceph 这套分布式存储的上游文档体量极大，按组件切成几十个章节，边读边译的成本很高，查一个 pool 参数往往要来回翻三四个页面。这份 linux-Ceph 中文文档把架构、部署、池与 CRUSH、日常运维、故障排查这些章节整站中文化后打包，适合两类人：一类是要在内网从零搭出一套能用的 Ceph 集群、又不想每读一段就切翻译的运维；另一类是集群已经在跑、需要一份能离线翻的排障手册的 Linux 开发。它不是速成教程，更像一份可以丢在/opt下随时 grep 的参考件，前提是你得先知道怎么用它。

2. 版本对齐先于一切：中文文档的章节地图与命令落差

拿到一份中文文档，多数人的第一反应是从第一页开始读。这个顺序对付考试有用，对付 Ceph 没用。Ceph 的文档是按“你要干什么”组织的，不是按学习路径组织的，从架构章节硬读下去，读到第五页还在讲 RADOS 的对象寻址，人已经走了。我一般的做法是先把目录当索引看一遍，确认它覆盖到哪一层，再去核对自己手里的二进制版本——这两件事做完，后面查任何一页都能定位得快。

2.1 一份整站中文化的 Ceph 文档，目录里有什么

Ceph 的文档体系大致分六块：架构与组件（MON、MGR、OSD、MDS、RGW 各自的职责和数据路径）、安装部署（从手工部署到 cephadm 编排）、存储策略（pool、PG、CRUSH、纠删码）、集群运维（守护进程管理、日志、监控、扩容缩容）、对外接口（RBD 块设备、CephFS 文件系统、RGW 对象网关）以及故障排查。中文文档把这几块翻完之后，最值钱的部分其实是“存储策略”和“故障排查”——这两块英文原版写得最密，术语最多，也是最容易读一半放弃的地方。

对照下面这张表看目录，能快速判断某个章节该在什么时机翻：

这张表的作用不是让你背下来，而是让你在慌乱的时候知道往哪翻。集群红了的时候没人有耐心从头读架构，直接跳到故障排查章节，按告警词查。

2.2 命令签名对不上：文档和二进制差一两个大版本时怎么办

中文文档最容易踩的坑不是翻译错，是版本滞后。Ceph 每半年左右出一个大版本，命令的推荐写法一直在变：早期版本建池要手写pg_num和pgp_num，后来推荐交给自动扩缩器；早期加 OSD 用ceph-volume lvm prepare/activate两步走，后来统一成ceph orch apply osd；Dashboard 的账号创建命令也换过入口。文档里写的命令，在你装的版本上不一定还能跑，或者能跑但已经不是推荐路径。

判断落差的办法很土但有效：先看自己装的是什么。

# 三个都看，缺一不可 ceph --version # 集群主版本 cephadm version # 编排工具版本，和主版本可能不一致 ceph versions # 各守护进程实际跑的版本，能看出有没有混装

ceph versions这条最容易被忽略。它的输出是按守护进程类型分组的版本清单，如果 mon 是 17.x 而某个 osd 还是 16.x，说明升级没做完，此时文档里任何涉及跨版本行为的描述都不能直接套。我见过一次升级到一半停下来的集群，ceph -s一直是HEALTH_WARN，查了半天是残留的旧版 mgr 在跑，用这条命令十秒就定位了。

版本落差的具体处理原则是：文档给的是“路径”，二进制给的是“签名”。路径（先建池再挂载再调副本）基本不会变，签名（具体参数名、是否还需要写死 pg_num）经常变。当你发现文档里的命令报invalid command或者参数不认识，去集群上查在线帮助，这是最权威的口径：

# 在线帮助永远比文档新，参数名以它为准 ceph osd pool create --help ceph orch apply osd --help ceph config set --help

在线帮助的输出是跟着二进制走的，文档跟不上，它跟得上。养成一个习惯：文档里抄下来的每条带参数的命令，第一次执行前先--help扫一眼，确认这个参数还在。

2.3 把文档变成能 grep 的本地索引

整站中文文档最大的价值是离线可搜。在线文档搜索要么依赖网络，要么搜索结果按页面权重排，找一个具体参数经常翻三页。解压到本地之后，用 ripgrep 或者 grep 直接全文检索，效率完全不是一回事。

# 解压到固定目录，后续所有检索都基于这里 mkdir -p /opt/ceph-doc tar -xf ceph-doc-zh.tar.gz -C /opt/ceph-doc # 装 ripgrep（Debian/Ubuntu 系），已有可跳过 apt-get install -y ripgrep # 建个别名，-n 带行号，-C 3 带上下文，排除图片和样式文件 alias cdg='rg -n -C 3 --no-heading -g "!*.png" -g "!*.css" -g "!*.js"'

-C 3是关键参数。Ceph 文档里一个参数的解释往往跨三四行，只给命中行等于没给上下文，你还得再打开文件跳过去。带上三行上下文，多数情况下一眼就能判断这页是不是你要的。

再进一步，把高频检索词固化成几个快捷命令，比每次现敲关键词快得多：

# 追加到 ~/.bashrc，重开终端生效 cdg_pg() { cdg "$1" /opt/ceph-doc | head -60; } # 查 PG 相关 cdg_crush(){ cdg "$1" /opt/ceph-doc | head -60; } # 查 CRUSH 规则 cdg_err() { rg -n -C 5 "HEALTH_|undersized|degraded|slow ops" /opt/ceph-doc; }

第三条cdg_err是我用得最多的。它不搜你的关键词，直接把文档里所有跟告警状态相关的段落捞出来。集群变黄的时候先跑这一条，比在搜索引擎里描述现象快得多，而且不会被无关结果带偏。

提示：这套索引只解决“查得到”，不解决“查得对”。文档版本和你集群版本的落差仍然要靠 2.2 的办法核对，别把过期参数当圣旨。

3. 照着文档把集群立起来：mon、mgr、osd 三段和 PG 归位

文档读完、索引建好，接下来是真正动手的部分。Ceph 集群的搭建在文档里通常被拆成一长串步骤，实际走下来可以压成三段：把前置条件弄干净、bootstrap 第一个 mon、把剩下的机器和磁盘吸进来。每一段都有它自己的失败模式，前置条件出问题会在第三段才炸出来，所以别跳。

3.1 四件前置事：主机名解析、时间、磁盘、防火墙

Ceph 对主机名的依赖比大多数分布式系统都重。MON 之间靠主机名互相找，OSD 的心跳里带主机名，ceph orch下发的编排任务也是按主机名寻址。用 DHCP 分配的临时名字，重启一次名字变了，集群就找不着自己了。三台机器先统一改掉：

# 三台机器分别执行，名字和 IP 要一一对应 hostnamectl set-hostname ceph-node1 # 每台都写全三行，别只写自己那行 cat >> /etc/hosts <<'EOF' 192.168.1.11 ceph-node1 192.168.1.12 ceph-node2 192.168.1.13 ceph-node3 EOF # 验证：三台机器上互相 ping 通，且解析到正确 IP getent hosts ceph-node1 ceph-node2 ceph-node3

第二件事是时间。MON 的选举对时钟偏差有硬性要求，偏差大到一定程度，集群会反复选主，表现是ceph -s里 mon 的 quorum 一直在变。文档里通常只写一句“确保 NTP 同步”，实际操作要落到 chrony：

# 统一指向内网时间源，没有内网源就指向上游 apt-get install -y chrony sed -i 's/^pool.*/pool 192.168.1.1 iburst/' /etc/chrony/chrony.conf systemctl enable --now chrony chronyc sources -v # 看 ^* 标记的那一行，确认已同步

第三件事是磁盘。Ceph 要的是裸盘或者未挂载的分区，已经被文件系统占用的盘，ceph orch device ls会标成available: False。跑一条命令看清楚：

# 列出所有节点的块设备及可用性，Available 列为 False 的先处理 ceph orch device ls --wide

第四件事是防火墙。Ceph 用的端口不少，MON 的 3300/6789、OSD 的 6800-7300 段、Dashboard 的 8443。内网环境里最省事的做法是关掉 firewalld 或者只放行网段，别一个个端口开——漏一个就是后面挂载失败、dashboard 打不开，排查半天。

注意：这四件事里只要有一样没做干净，症状都会延迟到 OSD 上线阶段才出现，那时候你面对的是 PG 不归位，不是“主机名不对”这么直白的报错。

3.2 bootstrap 第一个 mon 并接进两台新机器

第一台机器上执行 bootstrap，这条命令会同时做四件事：拉起第一个 mon 和 mgr、生成/etc/ceph/ceph.conf和 admin keyring、部署 Dashboard、把本机注册成编排主机。

# 在 ceph-node1 上执行，--mon-ip 必须是本机对外可达的地址 cephadm bootstrap \ --mon-ip 192.168.1.11 \ --cluster-network 192.168.1.0/24 \ --initial-dashboard-user admin \ --initial-dashboard-password 'ChangeMe_2024' \ --dashboard-ssl-port 8443

--mon-ip是必填项，写错的表现是 bootstrap 卡在 “Waiting for mon daemon to become available” 然后超时退出。--cluster-network指定集群内部心跳和复制流量走哪个网段，生产环境里建议单独走一张网卡，测试环境写不写都行。--initial-dashboard-password里如果带$或者引号，记得用单引号包住，这是 shell 层面的坑，不是 Ceph 的。

bootstrap 成功的标志是屏幕上打印出一段Ceph Dashboard is now available at并且ceph -s能返回HEALTH_OK。接下来把另外两台接进来，需要先打通 ssh：

# bootstrap 已生成本机的 root 公钥，复制到另外两台 ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-node2 ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-node3 # 加进编排集群，第三个参数是管理网地址 ceph orch host add ceph-node2 192.168.1.12 ceph orch host add ceph-node3 192.168.1.13 # 确认三台都在列表里，STATUS 应为 online ceph orch host ls

ceph orch host add失败最常见的原因是 ssh 不通或者目标机器上的 python 版本太老。cephadm 在远端跑编排任务依赖 python3，CentOS 7 这类默认 python2 的系统要先装 python3，否则加进去的主机会一直显示 offline。

3.3 OSD 上线与 PG 从 creating 走到 active+clean

OSD 是真正存数据的地方，也是整个搭建过程里最耗时的一步。磁盘多的时候别一个个加，直接让编排器接管所有可用设备：

# 把所有节点上可用且未使用的设备一次性做成 OSD ceph orch apply osd --all-available-devices # 观察进度，DRY-RUN 列能看到每个设备的处理阶段 ceph orch osd rm status 2>/dev/null watch -n 5 'ceph -s; ceph osd tree | head -30'

--all-available-devices是个开关型的声明，不是一次性动作。它的含义是“以后新插进来的可用盘也自动做成 OSD”，所以后续扩容时插盘基本不用敲命令。副作用是如果你有某块盘想留给别的用途，得先给它打上标签排除掉，否则会被吞进去。

OSD 上线之后，PG 会经历一段状态变化：从creating到active+undersized再到active+clean。整个过程视数据量和磁盘数量而定，几块盘的小集群一两分钟，几十块盘的集群可能十几分钟。这段时间里ceph -s显示HEALTH_WARN是正常的，不要手贱去重启守护进程。判断是不是真的卡住了，看这组命令：

# PG 总数和状态分布 ceph pg stat # 卡住不动的 PG，超过一定时间还在这几个状态才是真问题 ceph pg dump_stuck inactive,unclean,stale,undersized # 每个 OSD 的容量、利用率、PG 数量 ceph osd df tree

ceph osd df tree的输出里有一列%USE，如果某块盘的利用率明显高于其他盘，说明 PG 分布不均，通常是 CRUSH 权重没设对，可以单独调整某个 OSD 的权重再让数据重新平衡。

3.4 RBD 和 CephFS 各跑一次读写，别只看 ceph -s

集群active+clean只说明存储层自己觉得健康，不说明对外接口能用。验证要走一遍真实读写，块设备和文件系统各来一次。

RBD 这条路径：

# 建池、初始化、建镜像 ceph osd pool create rbdpool 64 64 rbd pool init rbdpool rbd create --size 10G rbdpool/demo # 映射到本地块设备并格式化挂载 rbd device map rbdpool/demo mkfs.xfs /dev/rbd0 mkdir -p /mnt/rbd && mount /dev/rbd0 /mnt/rbd # 写一坨数据再读回来校验 dd if=/dev/urandom of=/mnt/rbd/test.bin bs=1M count=200 oflag=direct md5sum /mnt/rbd/test.bin

oflag=direct绕开页缓存，测的是真实落盘速度。不加这个参数，200MB 数据全进了内存，看起来飞快，实际集群可能根本没写。rbd device map依赖内核的 rbd 模块，如果报modprobe: FATAL，先modprobe rbd，再检查内核版本是否带了这个模块。

CephFS 这条路径：

# 建文件系统，默认会顺带拉起 mds ceph fs volume create cephfs01 ceph fs status # 用 admin 的密钥挂载，生产环境应该单独建子卷和授权 mount -t ceph 192.168.1.11:/ /mnt/cephfs \ -o name=admin,secret=$(ceph auth get-key client.admin) # 验证 df -h /mnt/cephfs touch /mnt/cephfs/probe && ls -l /mnt/cephfs/probe

ceph fs volume create会同时建数据池和元数据池，并自动拉起 mds。ceph fs status里 mds 的状态要显示active，如果是standby说明主 mds 没起来，通常是元数据池的 PG 还没归位。挂载命令里的secret明文写在命令行里会进 shell history，正式环境改用secretfile=指向一个权限 600 的文件。

提示：这两条验证路径跑通之后再开始往集群里灌业务数据。跳过这一步直接上生产，后面出的问题你分不清是 Ceph 的锅还是业务的锅。

4. PG 数、CRUSH 规则、size 边界：文档里最容易被跳过的三页

集群能跑起来和集群能长期跑下去是两件事。文档里关于 PG、CRUSH、副本数的那几页，读起来最枯燥，恰恰是决定这套集群半年后会不会半夜炸的关键。这三块内容有一个共同点：改错了当时不报错，过几个月数据量上来才开始难受。

4.1 PG 数：公式还在，但别手算了

PG 是数据分布的基本单位，一个 pool 被切成若干个 PG，每个 PG 按 CRUSH 规则落到一组 OSD 上。PG 数太少，单个 PG 太大，重平衡的时候一个 PG 搬半天，恢复速度慢；PG 数太多，每个 OSD 上挂几百上千个 PG，心跳和状态维护本身就把内存和 CPU 吃掉了。

老公式是(OSD 总数 × 100) / 副本数，结果向上取到 2 的幂。九块盘、三副本，算下来是 300，取 512。这个公式现在还能用，但推荐的路径已经变成了交给自动扩缩器：

# 全局默认开启 PG 自动扩缩 ceph config set global osd_pool_default_pg_autoscale_mode on # 建池时显式声明，池级别覆盖全局设置 ceph osd pool create apppool --autoscale-mode on # 看自动扩缩器当前的建议值 ceph osd pool autoscale-status

autoscale-status的输出里有NEW PG_NUM和PROPOSED两列，前者是建议的新 PG 数，后者是当前是否采纳。自动扩缩不是立刻改，它会在低负载窗口慢慢挪，所以别指望建完池马上就看到最终值。

如果就是要手工定死，比如小集群或者对分布有强要求，那么pg_num和pgp_num必须一起改，而且pg_num只增不减：

# 先把 pg_num 提上去，等数据分布稳定再把 pgp_num 跟上 ceph osd pool set apppool pg_num 256 ceph osd pool set apppool pgp_num 256 # 随时看进度，PEERING 状态消失才算完成 ceph -s ceph pg stat

pgp_num才是真正控制数据迁移的参数。只改pg_num不改pgp_num，PG 会停在creating或者active+remapped，数据一点没动，这是新手最容易困惑的地方——命令返回成功，状态却不变。

4.2 CRUSH 故障域：写错一层等于副本白做

CRUSH 决定副本放在哪些 OSD 上。默认规则是host级别的故障域，意思是同一个 PG 的三个副本会落在三台不同的机器上，坏一台机器数据还在。这个默认值在大多数场景下是对的，问题是有人在只有两台机器加一块盘的测试环境里建三副本池，CRUSH 找不到三个不同的 host，PG 就会长期卡在active+undersized。

先看清楚集群的拓扑和现有规则：

# 看树状结构和 bucket 层级 ceph osd tree # 看现有规则都用了什么故障域 ceph osd crush rule dump # 导出 CRUSH map 看细节，反编译成可读文本 ceph osd getcrushmap -o /tmp/crush.bin crushtool -d /tmp/crush.bin -o /tmp/crush.txt

crushtool -d反编译出来的文本里，rule段会写清楚type host还是type rack。如果集群跨机架部署，把故障域提到rack更安全，代价是三副本至少要三个机架，机器少的时候根本没这个条件。

设备少的时候有个折中做法：建池时指定--crush-rule或者临时把副本数降到 2，但降副本之前必须确认min_size也跟着降，否则 PG 还是卡住：

# 两副本，允许一个副本失效后仍然可写 ceph osd pool set apppool size 2 ceph osd pool set apppool min_size 1

这个组合在测试环境能用，生产环境不要。min_size为 1 意味着任意一台机器挂了集群仍然接受写，但这个窗口里写进去的数据只有一份，再挂一台就丢。我见过一个团队为了消掉黄色告警这么干，后来真丢过一次数据，血泪经验。

4.3 size 和 min_size：集群什么时候会拒绝写

副本数size和最小副本数min_size是一对联动参数。size是目标副本数，min_size是“还剩几份副本时集群仍然认为这次写是安全的”。默认关系大致是min_size = size / 2 + 1，三副本对应 2，两副本对应 2，四副本对应 3。

这三个值决定了集群在故障时的行为边界：

修改这两个参数有一条硬规则：把size调到低于当前值，或者把min_size调到 1，必须带--yes-i-really-mean-it。这不是 Ceph 故意为难人，是它知道你在做危险操作。

# 正常扩容副本数，不需要确认参数 ceph osd pool set apppool size 3 # 降副本数会触发确认，看到报错别急着骂，先想清楚 ceph osd pool set apppool size 2 --yes-i-really-mean-it

改完size之后数据会立刻开始重平衡，集群 IO 会抖一阵。业务高峰别动这个参数，晚上十一点以后再改，改完盯着ceph -s看恢复进度。

注意：min_size调低虽然能让集群继续接受写，但它不会给你任何提示。真正的问题是恢复速度——集群在降级状态下还要处理业务写流量，重建副本的时间可能从几小时拉长到几天，这段时间里再坏一块盘就是数据丢失。

5. 避坑与排查：五个照着中文文档敲也会翻车的地方

文档写得再细，落到实际环境上总有意外。下面这五条是我在不同集群上反复遇到的，每一条都能写成“当时完全没往这个方向想”的复盘。

5.1 粘贴出来的命令报 invalid command

现象：从文档里复制一行ceph osd pool create mypool 64 64，粘贴到终端执行，返回Error EINVAL: invalid command或者命令被拆成好几段。

原因：中文文档排版时会把半角连字符-换成全角破折号—，把普通空格换成不换行空格。终端里看到的命令和实际字符不是一回事，ceph解析不了这些字符。另一种情况是文档为了排版把长命令折行，复制的时候漏掉了续行符。

解决：粘贴前先过一遍字符，用cat -A看不到的话，直接把命令里的-和空格重打一遍。更省事的办法是把常用命令写成脚本文件，用编辑器确认字符是 ASCII 之后再执行。我现在的习惯是所有ceph osd级别的操作都走脚本，不直接在终端里贴。

5.2 HEALTH_WARN 的 mon 时钟偏差反复出现

现象：ceph -s里偶尔出现mon clock drift is large，过一会儿自己消失，然后又出现，周而复始。

原因：chrony 同步了，但同步的源本身不准，或者虚拟机的时钟漂移比物理机严重。文档里“确保 NTP 同步”这句话，只覆盖了“有没有装”，没覆盖“同步得准不准”。虚拟化环境下宿主机的负载会传导到虚拟机时钟上。

解决：先看偏差的具体数值，ceph health detail会给出mon.node1 addr ... clock drift 0.05s，这个值超过 0.05 秒就该警觉。然后chronyc tracking看System time那行的偏移，如果长期在几十毫秒晃，换一个更近的时间源。极端情况下把mon_clock_drift_max适当放开，但那是治标，别当成常规操作。

5.3 OSD 加进去又 down 掉

现象：OSD 创建成功，ceph osd tree里up了几分钟，然后翻成down，重启也起不来。

原因：最常见的两种。一是用 loop 设备或者虚拟盘做 OSD，底层存储的性能撑不住 BlueStore 的 WAL 和 DB 写入，超时后被标记 down。二是 OSD 的内存不够，默认的osd_memory_target在某些环境里分配不到，进程直接被 OOM killer 干掉。

解决：先看日志确认是哪一种，cephadm部署的集群用这条：

# 看具体某个 OSD 的最近日志 ceph log last 50 debug-osd 2>/dev/null journalctl -u ceph-osd@1 --no-pager | tail -80 dmesg -T | grep -i "killed process"

如果dmesg里有 OOM 记录，就调低osd_memory_target；如果是 IO 超时，把这块盘换掉，别硬撑。虚拟盘做测试可以，别指望它承载业务。

5.4 PG 长期 active+undersized+degraded

现象：集群刚搭好或者刚加完机器，ceph -s一直是黄色，ceph pg stat显示有一部分 PG 卡在active+undersized+degraded不动。

原因：CRUSH 找不到足够的故障域放副本。三副本池加两台机器，或者所有 OSD 的crush weight是 0，都会导致这个结果。还有一种隐蔽情况：加了机器但没加进 CRUSH 树，ceph osd tree里这些 OSD 挂在default根下面，规则匹配不到。

解决：先确认 OSD 数量和主机数够不够，ceph osd tree看每台机器下面挂了几块盘。再看权重，ceph osd df tree里WEIGHT列为 0 的 OSD 等于没参与分配，用ceph osd crush reweight osd.3 1.0补上。如果确实是机器数量不够，要么加机器，要么按 4.2 的办法降副本。

5.5 Dashboard 的打不开与证书告警

现象：bootstrap 时打印了 Dashboard 地址，浏览器访问https://192.168.1.11:8443打不开，或者打开了提示证书不安全，点继续之后白屏。

原因：默认用的是自签证书，浏览器拦一道是正常的，点继续就能进。打不开多半是端口没放行，或者 mgr 的 dashboard 模块没启用。白屏通常是浏览器缓存了旧版本的静态资源。

解决：按顺序查三件事，模块有没有开、mgr 有没有在跑、端口通不通：

ceph mgr module ls | grep -i dashboard ceph mgr services ss -lntp | grep 8443

ceph mgr services会直接打印出 dashboard 的完整地址，如果这一行是空的，说明模块没启用，ceph mgr module enable dashboard补上。端口不通就回到 3.1 的防火墙那一步，别在 Ceph 里绕。

提示：这五条里有四条的现象都是HEALTH_WARN，但原因完全不同。看到黄色告警别急着搜“Ceph 黄色怎么消”，先ceph health detail把具体是哪个检查项报出来，再对症查。

6. 把文档用成习惯：三分钟体检脚本和一条强制动作

中文文档最实用的场景不是搭建，是排障。集群出问题的时候人在压力下记不住几十条命令，把高频的几条固化成一个脚本，比翻文档快得多。下面这个我放在每台管理节点上的/usr/local/bin/ceph-triage.sh，三分钟能把集群的底摸清：

#!/usr/bin/env bash # 三分钟体检：先看整体，再看谁在报，最后看盘和卡住的 PG set -u echo "===== 1. 集群概览 =====" ceph -s echo "===== 2. 告警明细 =====" ceph health detail echo "===== 3. 守护进程版本是否一致 =====" ceph versions echo "===== 4. OSD 容量与 PG 分布 =====" ceph osd df tree echo "===== 5. 卡住的 PG =====" ceph pg dump_stuck inactive,unclean,stale,undersized 2>/dev/null echo "===== 6. 慢请求 =====" ceph daemon osd.0 dump_slow_ops 2>/dev/null | head -40

脚本的逻辑是有顺序的：第 1 步给整体状态，第 2 步把HEALTH_WARN背后的具体检查项摊开，第 3 步排除版本混装这个干扰项，第 4 步看是不是某块盘快满了导致的重平衡，第 5、6 步才进入 PG 和慢请求这种深水区。跳过前四步直接查 PG，八成会查到无关的东西上。

第 6 步里的dump_slow_ops是很多人不知道的一条，它能直接列出哪些请求卡了超过 30 秒、卡在哪个 OSD、是什么操作类型。集群响应慢但ceph -s看着正常的时候，这条命令比任何监控图表都直白。前提是得知道 OSD 的编号，ceph osd tree里能查到，脚本里写死osd.0只是示例，实际用的时候换成报慢的那个。

三条验证路径可以总结成一句话：ceph -s看结论，ceph health detail看原因，ceph osd df tree加ceph pg dump_stuck看影响范围。这三条跑完，绝大多数问题都能定位到具体组件，剩下的才是翻文档查参数的事。

最后说一条强制动作。从那以后我每次拿到一份新的中文文档，第一件事不是读内容，是把文档封面或者修订记录里的版本号抓出来，和我准备操作的集群ceph --version输出对一遍，对不上就先在在线帮助里核一遍命令签名。这个动作花不到两分钟，但救过我至少三次——有一次文档里写的建池命令还是老写法，直接抄下去会在自动扩缩模式下建出一个固定 PG 数的池，后面扩容时想改都改不动。文档是好东西，但它记的是过去某一刻的正确，你得负责把它翻译成此刻的正确。希望帮到你。

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