1. 为什么 14.2.11 这个版本至今仍有人在装
先把结论摆在前面：Ceph 14.2.11 Nautilus 是一个已经进入生命周期末期的版本，但它在很多内网环境、教学实验环境、老旧硬件集群里依然活跃。原因不复杂——Nautilus 是 Ceph 历史上第一个把 Dashboard 做得"能看"、把cephadm之外的传统部署方式打磨得足够稳的版本，而 14.2.11 又是 Nautilus 系列里补丁相对齐全的一个点版本。很多人手头有一批跑着 CentOS 7 或者 Ubuntu 18.04 的机器，内核版本不高，硬件也不新，直接上 Pacific 或 Quincy 反而会遇到一堆依赖和内核特性问题，于是回头装 14.2.11 成了最省事的选择。
这篇内容面向的是需要在一批已有机器上从零搭起一个可用 Ceph 集群的人。不管你是想搭个三节点的小集群做分布式存储实验，还是要在内网里给一批虚拟机提供块存储，下面的流程都能直接照着走。我会用传统的手动部署方式来讲，也就是基于ceph-deploy的那套流程，而不是cephadm。原因很直接：14.2.11 时代cephadm还不够成熟，而ceph-deploy在 Nautilus 上的文档和社区案例最多，出问题最容易搜到答案。
需要提前说清楚一件事：Nautilus 已经停止维护，官方不再推送安全补丁。如果你的集群要暴露在不可信网络里，或者承载核心生产业务，请认真评估升级到受支持版本的必要性。本文的场景定位是内网、实验、教学、以及那些短期内不打算动的存量环境。
关键词方面，围绕这个标题最常被搜到的无非是：ceph 安装、nautilus 部署、ceph-deploy、mon/mgr/osd 配置、PG 数量计算、集群健康检查。这些我都会在对应章节里展开，不会只给命令不给解释。
2. 装之前必须想清楚的几件事：版本、拓扑与硬件底线
2.1 为什么锁定 14.2.11 而不是随便一个 Nautilus 小版本
Nautilus 系列从 14.2.0 一路走到 14.2.22 左右，中间修掉了大量 OSD 崩溃、PG 卡在 inactive、Dashboard 登录异常之类的问题。14.2.11 处在一个比较微妙的位置：它比早期版本稳定得多，又不像最后几个版本那样在某些老发行版上出现依赖包找不到的情况。我实测过在 CentOS 7.9 上装 14.2.11，yum源里对应的el7包齐全，ceph-deploy也能正常拉起来。如果你手上的系统更新一些，比如 Ubuntu 20.04，那 14.2.11 的focal包同样存在。
选版本这件事有个通用原则：在一个已经 EOL 的系列里，尽量选靠后的点版本，但要确认你的操作系统能拿到对应的软件包。不要盲目追最新的 14.2.x，因为越往后，老系统的包可能越难找。
2.2 集群拓扑：三个 MON 是底线，不是建议
很多人搭实验集群时图省事，只放一个 MON。单 MON 在实验环境里能跑，但它意味着没有仲裁能力，一旦这个节点挂了，整个集群直接不可用，而且恢复起来很麻烦。Ceph 的 MON 使用 Paxos 做一致性，奇数个 MON 才能形成有效多数派，所以最小可用拓扑是三个 MON。
一个典型的三节点起步拓扑是这样的：
| 节点角色 | 主机名示例 | 运行组件 |
|---|---|---|
| 节点一 | node1 | MON + MGR + OSD |
| 节点二 | node2 | MON + MGR + OSD |
| 节点三 | node3 | MON + OSD |
MGR 建议至少起两个，因为 Dashboard 和很多监控模块跑在 MGR 上，单 MGR 挂了虽然不影响数据读写，但管理面会瞎掉。OSD 的数量取决于你的磁盘，每个数据盘对应一个 OSD。
2.3 硬件与系统的最低要求
CPU 和内存这块，MON 和 MGR 对资源要求不高，2 核 4G 就能跑。真正吃资源的是 OSD，尤其是做恢复（recovery）的时候。经验值是每 TB 原始容量配 1GB 内存，这是底线，不是舒适值。如果你有 4 块 4TB 盘，那这台机器至少 16GB 内存起步，32GB 会更从容。
磁盘方面，强烈建议数据盘用独立磁盘，不要和系统盘混在一起。系统盘做 RAID1 保证可用性，数据盘用 JBOD（直连，不做 RAID），让 Ceph 自己管副本。这一点和传统存储思路相反，很多人第一反应是给数据盘做 RAID，结果反而破坏了 Ceph 的副本机制，得不偿失。
网络是另一个容易被忽视的点。Ceph 区分公共网络（public network）和集群网络（cluster network）。公共网络承载客户端流量和 MON 通信，集群网络专门跑 OSD 之间的数据复制和恢复。如果条件允许，给集群网络单独走一块万兆网卡，能显著降低恢复时对客户端的影响。实验环境里两块网卡合一也能跑，但要知道这是妥协。
系统时间必须同步。Ceph 对时间漂移很敏感，MON 之间时间差太大会导致仲裁异常。装之前确认chronyd或ntpd在跑，并且所有节点指向同一个时间源。
3. 从裸机到集群：分阶段的实操链路
3.1 前置准备：主机名、hosts 与免密登录
这一步看着琐碎，但后面所有命令都依赖它，做错了会浪费大量排查时间。
先给每台机器设置固定的、可解析的主机名。不要用localhost，也不要用 DHCP 分配的随机名。假设三台机器分别叫node1、node2、node3，在每台的/etc/hosts里都写上完整的映射：
# 三台机器都要有这份内容 192.168.1.11 node1 192.168.1.12 node2 192.168.1.13 node3然后配置 SSH 免密。ceph-deploy是从一台管理节点（通常就是 node1）通过 SSH 去操作其他节点的，所以需要 node1 能免密登录到所有节点，包括它自己。
# 在 node1 上生成密钥（如果还没有） ssh-keygen -t rsa -b 4096 -N "" -f ~/.ssh/id_rsa # 分发到所有节点 for host in node1 node2 node3; do ssh-copy-id root@$host done注意：
ceph-deploy默认用 root 操作，或者用有 sudo 权限的用户。用普通用户的话，要确保该用户能免密 sudo，否则中途会卡在权限上。实验环境直接用 root 最省事。
关闭防火墙和 SELinux 是实验环境的常规操作，但生产环境要按需放行端口而不是一关了之。Ceph 需要的端口不少，MON 默认 6789 和 3300，OSD 用 6800-7300 一段，MGR 用 6800-7300 里的若干。实验环境图快，可以先关掉：
systemctl stop firewalld && systemctl disable firewalld setenforce 0 sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config3.2 配置软件源并安装 ceph-deploy
ceph-deploy本身是个 Python 工具，装在管理节点上就行，不需要装到所有节点。但所有节点都需要配置好 Ceph 的软件源，因为ceph-deploy会远程在各节点上装包。
以 CentOS 7 为例，先加 EPEL 源，再加 Ceph 的 Nautilus 源：
yum install -y epel-release cat > /etc/yum.repos.d/ceph.repo <<'EOF' [ceph] name=Ceph packages for $basearch baseurl=https://download.ceph.com/rpm-nautilus/el7/$basearch enabled=1 gpgcheck=1 type=rpm-md gpgkey=https://download.ceph.com/keys/release.asc [ceph-noarch] name=Ceph noarch packages baseurl=https://download.ceph.com/rpm-nautilus/el7/noarch enabled=1 gpgcheck=1 type=rpm-md gpgkey=https://download.ceph.com/keys/release.asc EOF这里有个细节：rpm-nautilus这个目录下会持续更新到该系列的最新点版本。如果你要精确锁定 14.2.11，需要在安装时指定版本号，比如yum install ceph-14.2.11。不指定的话，装到的可能是 14.2.x 里更新的版本。在 EOL 系列里，我倾向于不锁死小版本，让包管理器拿到该系列最后一个可用版本，因为那些版本通常修了更多 bug。但如果你有严格的版本一致性要求，那就锁。
在管理节点上装ceph-deploy：
yum install -y ceph-deploy ceph-deploy --version3.3 创建集群并部署 MON
找一个干净的工作目录，ceph-deploy会在里面生成一堆配置文件，别在/root下乱跑，建个专门的目录：
mkdir -p /opt/ceph-cluster && cd /opt/ceph-cluster第一步是new，它会生成初始的ceph.conf和密钥环：
ceph-deploy new node1 node2 node3这一步之后，目录里会出现ceph.conf、ceph.mon.keyring、ceph-deploy-ceph.log。打开ceph.conf，根据你的网络情况补充几行关键配置：
[global] fsid = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 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 cluster_network = 192.168.2.0/24 osd_pool_default_size = 3 osd_pool_default_min_size = 2public_network和cluster_network一定要写对网段。如果只有一块网卡，cluster_network可以不写，或者和public_network写成一样。osd_pool_default_size = 3表示默认三副本，实验环境如果磁盘紧张可以改成 2，但要知道这降低了容错能力。
然后安装 Ceph 软件包到所有节点：
ceph-deploy install --release nautilus node1 node2 node3这一步会通过 SSH 在各节点上跑yum install，耗时取决于网络。如果卡住，多半是源的问题或者 SSH 不通，先手动在某个节点上yum install ceph试试能不能通。
接着部署 MON：
ceph-deploy mon create-initial成功的话，当前目录会多出一堆ceph.client.admin.keyring、ceph.bootstrap-*.keyring之类的文件。这些密钥环后面要用，别删。
3.4 部署 MGR 与 OSD
MGR 部署很简单：
ceph-deploy mgr create node1 node2起两个 MGR，一个 active 一个 standby。Dashboard 默认在 active MGR 上，端口 8443（Nautilus 里是 https）。
OSD 是重头戏。先确认每台机器上哪些盘是空的、没被使用的：
lsblk假设 node1 上有/dev/sdb、/dev/sdc两块数据盘，node2、node3 类似。用zap清掉磁盘残留的分区表和文件系统签名：
ceph-deploy disk zap node1 /dev/sdb ceph-deploy disk zap node1 /dev/sdc # 其他节点同理然后创建 OSD：
ceph-deploy osd create --data /dev/sdb node1 ceph-deploy osd create --data /dev/sdc node1 # 其他节点同理实操心得：
osd create这一步如果报错说磁盘已被占用，八成是zap没清干净，或者磁盘上有 LVM 残留。用wipefs -a /dev/sdb再清一遍，必要时用dd把磁盘头部清零。另外，如果数据盘和系统盘在同一块物理盘上（不推荐），要格外小心别把系统盘给 zap 了。
OSD 创建完成后，把配置文件和密钥环推到所有节点，这样各节点上的 Ceph 命令才能正常工作：
ceph-deploy admin node1 node2 node33.5 验证集群状态
到这里集群应该起来了。在任意节点上执行：
ceph -s正常的话会看到HEALTH_OK，以及 MON、MGR、OSD 的数量。如果看到HEALTH_WARN，别慌，先看具体警告内容。刚建好的集群最常见的警告是osd count相关的，比如 PG 还没完全 active+clean，等几分钟通常会自己恢复。
ceph osd tree # 看 OSD 分布 ceph mon stat # 看 MON 仲裁状态 ceph df # 看容量4. 存储池与 PG 数量：最容易算错也最容易埋雷的地方
4.1 创建存储池的正确姿势
集群健康之后，第一件事是建存储池（pool）。存储池是存放数据的逻辑容器，块存储、对象存储、文件存储最终都落在池上。
ceph osd pool create mypool 128 128后面两个数字是 PG（归置组）数量和 PGP 数量。这里先不展开，下一节专门讲。建完池之后，要把它和某个应用关联起来，否则新版本会警告：
ceph osd pool application enable mypool rbdrbd表示这个池用于块存储。如果是对象存储用rgw，文件存储用cephfs。
4.2 PG 数量到底怎么算
PG 数量是 Ceph 里最经典的计算题，也是最容易配错的地方。配少了会导致单个 PG 过大、恢复慢、数据分布不均；配多了会消耗大量内存和 CPU，MON 处理 PG 映射的压力也会上升。
官方给的经验公式是：
PG 总数 = (OSD 总数 × 100) / 副本数然后向上取到 2 的幂。举个例子，假设你有 6 个 OSD，三副本：
(6 × 100) / 3 = 200向上取到 2 的幂是 256。这 256 是整个集群所有池的 PG 总数，不是单个池。如果你只建一个池，那这个池就是 256 个 PG。如果建多个池，要把 256 按比例分给各个池。
单个池的 PG 数同样建议取 2 的幂，这样 CRUSH 算法分布更均匀。常见的取值是 64、128、256、512。
| OSD 数量 | 三副本建议 PG 总数 | 单池常见取值 |
|---|---|---|
| 3 | 128 | 64 或 128 |
| 6 | 256 | 128 或 256 |
| 12 | 512 | 256 或 512 |
| 24 | 1024 | 512 或 1024 |
注意：PG 数量建池之后可以调，但调整过程会触发数据重平衡，对生产集群有影响。所以建池时尽量一次算对，别抱着"先随便建，以后再调"的心态。实验环境无所谓，生产环境要慎重。
4.3 副本数与最小副本数的取舍
osd_pool_default_size控制副本数，默认 3。osd_pool_default_min_size控制写入所需的最小副本数，默认 2。这两个参数的关系是：当可用副本数低于min_size时，池会停止写入，进入只读或者不可用状态。
三副本配 min_size=2 是标准做法。含义是：允许一个 OSD 挂掉，集群继续正常读写；如果挂掉两个，写入停止，但已有数据还能读。如果你把 min_size 设成 1，那挂两个 OSD 还能写，但数据丢失风险陡增，不推荐。
实验环境磁盘紧张时，有人用两副本（size=2, min_size=1）。这能省一半空间，但容错能力只剩一个 OSD。两副本在单盘故障时没有余量，恢复期间再挂一块就丢数据，心里要有数。
5. 那些文档不写、但一定会遇到的坑
5.1 MON 起不来：先查时间，再查端口，最后查磁盘
MON 部署失败是最常见的开局问题。排查顺序我总结成三步：
第一，查时间同步。chronyc sources看时间源是否正常，节点之间date差多少。差超过几秒就可能出问题。
第二，查端口占用。ss -lntp | grep 6789看 6789 和 3300 是否被别的进程占了。有时候之前装过 Ceph 没清干净，残留进程还在。
第三，查磁盘空间。MON 的/var/lib/ceph/mon/目录所在分区如果满了，MON 直接起不来。这个坑很隐蔽，因为 MON 数据量不大，但如果你把/var单独分区且给得很小，就容易中招。
5.2 OSD 创建后一直 down：多半是权限或磁盘问题
OSD 创建成功但状态是down，先看日志：
journalctl -u ceph-osd@0 -n 100常见原因有几个。一是/var/lib/ceph/osd/目录权限不对，ceph用户读不了。二是磁盘本身有坏道或者之前的分区表没清干净。三是ceph.conf里的cluster_network写错了，OSD 找不到集群网络。
我遇到过一次特别隐蔽的：磁盘是之前做过 RAID 的，虽然zap过了，但 RAID 元数据还在磁盘末尾，导致 OSD 启动时读到脏数据。解决办法是用wipefs -a清所有签名，再用dd把磁盘头尾各清 100MB。
5.3 HEALTH_WARN 的各种花样与处理
HEALTH_WARN是常态，不是所有警告都要立刻处理。列几个高频的：
| 警告信息 | 含义 | 处理方式 |
|---|---|---|
application not enabled | 池没关联应用 | ceph osd pool application enable |
osds have slow ops | OSD 操作慢 | 查磁盘 IO、网络、内存 |
clock skew | 时间漂移 | 修时间同步 |
pg degraded | PG 降级 | 等恢复，或查 down 的 OSD |
mon clock drift | MON 时间漂移 | 同上 |
pg degraded在刚建集群或者刚加 OSD 时很常见，通常是数据在重平衡，等一会儿就好。如果长时间不恢复，就要查是不是有 OSD 真的挂了。
5.4 Dashboard 打不开的排查路径
Nautilus 的 Dashboard 默认在 active MGR 上，https 8443 端口。打不开的话：
ceph mgr module ls # 看 dashboard 模块是否 enabled ceph mgr services # 看 dashboard 的实际地址如果模块没启用：
ceph mgr module enable dashboard如果启用了但访问不了，检查 MGR 所在节点的防火墙和端口监听。Dashboard 默认用自签证书，浏览器会报警告，这是正常的，继续访问即可。要改端口或者换证书，可以在ceph.conf里配mgr/dashboard/server_port等参数。
6. 集群跑起来之后：日常维护与扩容思路
6.1 加 OSD 和加节点的区别
扩容分两种。一种是给现有节点加盘，直接ceph-deploy osd create --data /dev/sdX node1就行，新 OSD 会自动加入 CRUSH 并开始接收数据。另一种是加全新节点，需要先在新节点上装 Ceph 包、推配置和密钥环，再创建 OSD。
加节点时有个顺序问题：先把新节点纳入 MON 或者至少让它能通信，再加 OSD。如果新节点的网络配置和现有集群不一致，OSD 加进去也会是 down 的。
扩容后 PG 数量可能需要调整。如果 OSD 数量翻倍，PG 总数也该相应增加，否则单个 PG 会变大。调整命令：
ceph osd pool set mypool pg_num 512 ceph osd pool set mypool pgp_num 512pg_num和pgp_num要一起调，且pgp_num不能大于pg_num。调整会触发数据迁移，建议在业务低峰期做。
6.2 监控该看哪些指标
集群跑起来不是终点，得盯着。最基础的几个命令：
ceph -s # 总览 ceph osd perf # OSD 延迟 ceph osd df # OSD 容量使用率 ceph pg stat # PG 状态统计ceph osd df里如果某个 OSD 的使用率明显高于其他，说明数据分布不均，可能是 CRUSH 规则或者 PG 数量的问题。ceph osd perf里如果某个 OSD 的 apply/commit 延迟特别高，那块盘可能有问题。
6.3 备份与恢复的基本认知
Ceph 本身靠副本保证数据安全，但"副本"不等于"备份"。误删池、误删 RBD 镜像这类操作，副本是救不了的。重要的池要单独做快照或者导出。
RBD 镜像可以做快照：
rbd snap create mypool/myimage@snap1 rbd snap ls mypool/myimage快照是增量的，占用空间不大，但也不能当长期备份用。真正的备份要把数据导出到集群之外的地方。
7. 关于这套流程，我踩过之后想说的几句
装 Ceph 这件事，命令本身不难，难的是环境准备和排错。我见过太多人卡在 SSH 免密、时间同步、磁盘没清干净这几个点上，然后以为是 Ceph 本身有问题。实际上把前置条件做扎实，后面的流程会顺得让你意外。
还有一个心态问题：Nautilus 是 EOL 版本，遇到问题去搜，很多答案都是几年前的，命令和现在的略有出入。这时候别死磕某个博客，直接看官方文档对应版本的章节，或者去社区翻 issue，通常更靠谱。
最后提醒一句，实验环境里怎么折腾都行，但如果你打算把这套东西用到有真实数据的地方，请务必先想清楚：这个版本没有安全更新，你的数据丢了没人能帮你兜底。该升级的时候，别拖。
