企业官网建设流程全解析

简介：面向Linux运维与云存储方向的学习者，这份Ceph中文文档资源围绕存储集群的落地部署展开，覆盖对象存储、块设备与文件系统等典型使用场景，适合刚接触Ceph、需要系统梳理节点规划、网络配置与集群搭建思路的初中级工程师。压缩包共482个文件，以346个rst文档为主体，辅以76个txt说明、9个conf配置样例、8个sh脚本及若干png、jpg图示，另有少量py、html、json等辅助文件，整体约4.04MB，体量轻便、结构清晰。内容从Ceph节点与网络准备讲起，延伸至集群部署与配置示例，rst文档便于按章节顺序阅读，conf与sh文件可作为环境搭建时的对照参考，图示则帮助理解组件关系与部署流程。已有422人学习，适合作为日常查阅与入门实践的手册型资料。

1. 一份能当案头手册用的 Ceph 中文文档，到底解决了什么

分布式存储这块，Ceph 是绕不开的名字，但真正让人卡住的往往不是概念，而是那套散落在官方文档、邮件列表和零碎博客里的操作细节。手上这份 linux-Ceph 中文文档，本质是把集群部署、OSD 管理、CRUSH 调优、故障恢复这些高频动作整理成了一套可查可抄的中文资料。它适合两类人：一类是刚接手一套 Ceph 集群、需要照着步骤把 MON 和 OSD 拉起来的新手；另一类是已经在跑生产、想搞清楚 PG 状态异常和恢复限速怎么调的老手。文档不是教程，是手册，价值在于你出问题时能快速定位到对应章节，而不是从头读到尾。

2. 从零搭一套最小可用集群：部署流程与关键参数

Ceph 的部署方式这几年变化不小，早期靠 ceph-deploy，后来主流转向 cephadm 和容器化。这份文档覆盖的是偏传统的手工部署路径，对理解组件关系反而更友好，因为每一步你都知道自己在装什么。下面按最小可用集群来走一遍，三个节点，一个 MON，若干 OSD，先把东西跑起来再谈调优。

2.1 节点规划与前置依赖

最小集群我一般用三台机器，角色分配如下。注意 MON 建议奇数个，三个节点各放一个 MON 是最稳的起步姿势，单 MON 只适合实验环境。

前置依赖主要是时间同步、主机名解析和免密登录。时间不同步是后面 MON 选举出问题的头号元凶，血泪经验，别省这一步。

# 三台机器都执行：主机名与 hosts 解析 hostnamectl set-hostname node1 cat >> /etc/hosts <<'EOF' 192.168.1.11 node1 192.168.1.12 node2 192.168.1.13 node3 EOF # 时间同步（以 chrony 为例） yum install -y chrony systemctl enable --now chronyd chronyc sources -v # 确认有可用源 # node1 上生成密钥并分发，实现免密 ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa for h in node1 node2 node3; do ssh-copy-id $h; done

这段脚本做三件事：固定主机名保证 Ceph 各组件能互相解析，chrony 保证时钟偏差在容忍范围内，免密登录让后续批量下发命令不用反复输密码。chronyc sources -v输出里如果源前面带^*才说明同步正常，只有^?就是没连上，得先解决网络或源配置。

2.2 安装与 MON 初始化

装包用发行版自带的仓库即可，版本一致性比版本新旧更重要，混版本是自找麻烦。

# 三台都装基础包 yum install -y ceph ceph-radosgw # node1 上初始化 MON（fsid 自己生成一个 uuid） FSID=$(uuidgen) monmaptool --create --add node1 192.168.1.11 \ --add node2 192.168.1.12 --add node3 192.168.1.13 \ --fsid $FSID /etc/ceph/monmap # 生成初始配置 cat > /etc/ceph/ceph.conf <<EOF [global] fsid = $FSID mon_initial_members = node1, node2, node3 mon_host = 192.168.1.11,192.168.1.12,192.168.1.13 auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx public_network = 192.168.1.0/24 EOF # 初始化并启动 MON ceph-mon --mkfs -i node1 --monmap /etc/ceph/monmap systemctl enable --now ceph-mon@node1

monmaptool生成的是 MON 的成员地图，--fsid必须和 ceph.conf 里一致，否则后面组件握手会失败。public_network写的是客户端访问网段，如果集群有独立的后端存储网络，还要加cluster_network，这个参数配错会导致 OSD 之间复制走错网卡，带宽直接打满业务网。MON 起来后用ceph -s看状态，能返回集群信息就说明 MON 通了，此时 HEALTH 大概率是 ERR，因为还没有 OSD，正常。

2.3 OSD 创建与 CRUSH 初步

OSD 是真正存数据的地方，创建方式有 ceph-volume 和手动 prepare 两种，文档里两种都提了，实操优先用 ceph-volume，它对 LVM 和蓝储设备的处理更规范。

# 查看可用磁盘 ceph-volume lvm list # 用整盘创建 OSD（node1 上执行，/dev/sdb 换成实际盘） ceph-volume lvm create --data /dev/sdb # 批量创建时可以先 prepare 再 activate，便于排查 ceph-volume lvm prepare --data /dev/sdc ceph-volume lvm activate --all

lvm create一步到位做了 prepare 和 activate，适合盘干净的情况。如果盘上残留旧分区，先wipefs -a /dev/sdb清掉，否则 ceph-volume 会报设备已被占用。OSD 起来后ceph osd tree能看到层级结构，默认 CRUSH 规则是 replicated_rule，副本数 3。小集群只有三台机器时，副本 3 意味着每个 PG 在三台各放一份，任何一台挂了都不丢数据，但也意味着可用容量只有总量的三分之一，这个账要提前算清楚。

3. PG 状态与 CRUSH 规则：读懂集群的体检报告

集群跑起来只是开始，日常运维里你盯得最多的就是ceph -s和ceph pg stat的输出。PG 状态是 Ceph 最诚实的体检报告，但它的状态码多到让人头大，文档里对常见状态的解释值得反复翻。

3.1 常见 PG 状态的含义与处置

先看几个高频状态，理解它们的成因比死记状态码有用得多。

active+undersized+degraded是最常见的组合，通常是一块盘掉了，集群还在用剩余副本提供服务。这时候别急着动，先确认故障盘是不是真坏了，ceph osd tree里对应 OSD 会显示 down。如果只是临时抖动，OSD 自己会回来；如果确认坏盘，走换盘流程，新盘上线后回填自动开始。

# 定位异常 PG 及其所在 OSD ceph pg dump_stuck inactive ceph pg 2.1 query # 查具体 PG 的详细状态 # 查看 OSD 状态与权重 ceph osd tree ceph osd df # 各 OSD 使用率，找热点

pg dump_stuck能筛出卡在某个状态的 PG，query则给出这个 PG 的完整协商历史，包括哪个 OSD 没响应。osd df里的%USE列如果出现明显不均，说明 CRUSH 分布有问题或者某块盘容量不一致，需要调权重。

3.2 CRUSH 规则调整与权重管理

CRUSH 是 Ceph 的数据分布算法，规则决定了副本往哪放。默认规则按 host 做故障域，三节点集群够用。但如果你有机架概念，就得自定义 failure domain，否则同机架两台机器同时断电就丢副本了。

# 查看现有规则 ceph osd crush rule ls ceph osd crush rule dump replicated_rule # 自定义按机架分布的规则 ceph osd crush add-bucket rack1 rack ceph osd crush add-bucket rack2 rack ceph osd crush move node1 rack=rack1 ceph osd crush move node2 rack=rack2 ceph osd crush rule create-replicated rack_rule default rack # 调整 OSD 权重（容量大的盘权重高） ceph osd crush reweight osd.0 2.0

create-replicated的最后一个参数rack就是故障域，意思是同一 PG 的副本不会落在同一机架。reweight改的是 CRUSH 权重，影响数据分布比例，改完会触发数据迁移，生产环境要挑低峰期做，并且配合ceph osd set norebalance先冻结再逐步放开。权重不是随便设的，一般按磁盘容量比例来，1TB 盘设 1.0，4TB 盘设 4.0，这样各盘使用率才均衡。

4. 避坑与排查：那些文档里一句话带过、实操能卡半天的地方

手册的好处是全面，坏处是有些坑它只写了一句“注意”，而你恰恰就栽在那句上。下面几条是我在实际环境里反复遇到的，按现象、原因、解决拆开说。

4.1 MON 起不来，日志报 clock skew

现象：ceph-mon启动失败，日志里出现clock skew或monitor clock drift。原因：节点间时间偏差超过默认容忍值（0.05 秒），MON 拒绝加入集群。解决：先chronyc tracking看偏差，把 chrony 源配好并强制同步chronyc makestep，确认三台偏差都在毫秒级再重启 MON。别去调mon_clock_drift_allowed这个参数掩盖问题，时间不同步后面会引发更诡异的选举问题。

4.2 OSD 创建报设备已被占用

现象：ceph-volume lvm create报Device /dev/sdb is already in use。原因：盘上有残留的分区表、LVM 元数据或旧文件系统签名。解决：wipefs -a /dev/sdb清签名，dd if=/dev/zero of=/dev/sdb bs=1M count=100抹掉头部，再重新 create。如果盘之前属于别的集群，还要ceph-volume lvm zap /dev/sdb --destroy彻底清理。

4.3 PG 长期卡在 peering 不动

现象：某几个 PG 一直peering，集群整体可用但部分对象读写超时。原因：通常是某个 OSD 处于半死状态，进程在但磁盘 IO 卡死，MON 收不到心跳又没判定 down。解决：ceph pg 2.x query看是哪个 OSD 没响应，ceph osd tree确认状态，必要时systemctl restart ceph-osd@N强制拉起，或标记ceph osd out让它先退出再排查磁盘。别直接osd down了事，那只是把问题藏起来。

4.4 恢复期间业务被拖垮

现象：换盘后回填开始，业务侧延迟飙升。原因：恢复流量没有限速，占满了磁盘带宽和网络。解决：提前设好osd_recovery_max_active和osd_max_backfills，回填时段用ceph osd set noscrub和ceph osd set nodeep-scrub暂停巡检，把资源让给恢复。恢复完再逐个 unset，别一次性全放开。

# 恢复限速的常用组合 ceph config set osd osd_recovery_max_active 3 ceph config set osd osd_max_backfills 1 ceph config set osd osd_recovery_sleep 0.1 ceph osd set noscrub ceph osd set nodeep-scrub

osd_recovery_max_active控制每个 OSD 同时进行的恢复操作数，osd_max_backfills控制回填并发，osd_recovery_sleep让每次恢复后歇一下，三个参数配合能把恢复对业务的影响压到可接受范围。数值没有标准答案，按你集群的盘数和业务敏感度试，从保守值往上调。

5. 用文档做验证：把手册变成自己的排错清单

文档最大的价值不是读一遍，而是把它变成你自己的检查清单。我现在的习惯是，每次集群出问题，先按文档对应章节走一遍标准排查路径，再动手。比如遇到 HEALTH_WARN，先ceph health detail拿到具体告警项，对照文档里的状态表定位到章节，而不是凭记忆瞎猜。

一个具体技巧是把文档里的关键命令抽出来做成脚本，定期跑一遍做巡检。下面这个巡检脚本覆盖了容量、PG 状态、OSD 健康和慢请求，输出直接能看出异常。

#!/bin/bash # ceph 日常巡检，输出异常项 echo "=== 集群总体 ===" ceph -s | grep -E "health|mon|osd|pg" echo "=== 容量水位 ===" ceph df | awk 'NR>1 && $5+0 > 80 {print "警告: "$1" 使用率 "$5}' echo "=== 异常 PG ===" ceph pg stat | grep -v "active+clean" echo "=== down 的 OSD ===" ceph osd tree | awk '$4=="down" {print $0}' echo "=== 慢请求 ===" ceph osd perf | awk 'NR>1 && ($3+0 > 100 || $4+0 > 100) {print "慢盘: "$0}'

脚本里ceph df的第五列是使用率百分比，超过 80 就告警，这是给扩容留缓冲。ceph osd perf的 commit 和 apply 延迟超过 100ms 基本可以判定该盘有问题，值得单独查。这套巡检我挂在定时任务里每天跑，输出发到自己的邮箱，比等业务报警再动手从容得多。

从那以后我每次接手一套新集群，第一件事不是急着调参数，而是先把文档里的状态表和命令过一遍，跑一次基线巡检，把“正常长什么样”记下来。有了基线，后面任何偏离都能第一时间发现。希望这份文档也能帮你在下一次 PG 告警时不慌。

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