Ceph 是一个高度可扩展的分布式存储系统，最大的特点是统一存储架构：一套集群同时提供对象存储（RADOSGW）、块存储（RBD）和文件系统（CephFS）三种接口，底层都基于同一个分布式对象存储引擎 RADOS。这种设计避免了为不同存储类型单独建设系统，大幅降低了运维复杂度。本文将先拆解 Ceph 的架构设计，再给出一套完整的生产级部署流程。
一、Ceph 核心架构与关键组件
Ceph 的核心思想是一切皆对象。无论上层使用块设备、文件还是原生对象接口，数据最终都被切分为固定大小的对象，存储在 RADOS（Reliable Autonomic Distributed Object Store）集群中。理解这一点，是理解 Ceph 一切行为的基础。
Ceph 集群由几类核心组件构成：Monitor 负责维护集群拓扑地图（OSD Map、PG Map、Monitor Map 等），是集群的权威大脑，生产环境至少部署 3 个甚至 5 个以实现仲裁；OSD（Object Storage Daemon）是实际存储数据的守护进程，通常一个物理盘对应一个 OSD，它同时负责数据复制、故障检测和恢复；Manager 提供监控指标和对外管理接口；MDS 仅在需要 CephFS 文件系统时部署，管理元数据。对象网关 RADOSGW 则提供兼容 S3 和 Swift 的 HTTP 接口。
与传统集中式存储依赖元数据表不同，Ceph 使用 CRUSH 算法进行数据寻址。客户端写入数据时，先计算出对象所属的 PG（Placement Group，归置组），再通过 CRUSH 算法根据集群拓扑规则计算出该 PG 应落在哪些 OSD 上。整个过程是纯计算，不需要查询中心节点，因此不存在元数据性能瓶颈，集群规模可以线性扩展到数千个节点。
CRUSH 规则树还提供了故障域隔离能力。管理员可以定义 host、rack、row、datacenter 等层级结构，指定数据副本必须分布在不同层级，避免单机架断电导致数据全部丢失。这是生产环境规划中最容易被忽视但至关重要的一环。
二、生产环境硬件规划与系统调优
部署 Ceph 之前，硬件规划直接决定了集群的上限。OSD 节点建议每台配置双路 CPU、128GB 以上内存，每块数据盘独占一个 OSD 进程；同时必须配置独立的 NVMe 盘作为 WAL 和 DB 分区（BlueStore 的 block.wal 与 block.db），否则慢日志会拖垮整个集群的写入性能。网络方面强烈建议前后端分离：公共网络（客户端流量）与集群网络（副本同步流量）各走一套万兆甚至 25GbE 网卡，避免重建数据时挤占业务带宽。
操作系统层面有几项必须调整的参数。首先是关闭透明大页，否则会导致内存分配延迟抖动；其次是将
- 文件描述符上限调大到 65535 以上；
- 调整
pid_max避免进程号耗尽； - 每个 OSD 网卡队列开启中断绑核，减少上下文切换。
以下是一份常用的系统调优脚本：
#!/bin/bash # 关闭透明大页 echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag # 调整文件描述符 cat >> /etc/security/limits.conf <<EOF * soft nofile 655350 * hard nofile 655350 root soft nofile 655350 root hard nofile 655350 EOF # 内核参数 cat >> /etc/sysctl.conf <<EOF kernel.pid_max = 4194303 net.core.somaxconn = 32768 net.ipv4.tcp_max_syn_backlog = 8192 EOF sysctl -p # 时间同步（Monitor 对时钟敏感） yum install -y chrony systemctl enable --now chronyd
需要特别强调的是时间同步。Ceph Monitor 对时钟漂移非常敏感，偏差超过 mon_clock_drift_allowed 阈值（默认 0.05 秒）就会触发告警甚至将 Monitor 标记为异常，因此 NTP/Chrony 是所有节点的必备服务。
三、使用 cephadm 部署集群实战
从 Octopus 版本开始，官方推荐使用 cephadm 进行部署，它基于容器方式运行所有守护进程，通过 SSH 管理集群节点，摆脱了对 Ansible、Salt 等外部工具的依赖。下面以三节点集群为例演示完整流程。
假设三台服务器：node1（192.168.10.11）、node2（192.168.10.12）、node3（192.168.10.13），每台额外挂载一块 /dev/sdb 数据盘。首先在 node1 上安装引导程序：
# 安装 cephadm dnf install -y cephadm # 拉取引导镜像并初始化集群 cephadm bootstrap --mon-ip 192.168.10.11 # 初始化完成后输出 dashboard 访问信息 # 将公钥分发到其他节点 ssh-copy-id -f -i /etc/ceph/ceph.pub root@node2 ssh-copy-id -f -i /etc/ceph/ceph.pub root@node3 # 添加节点 ceph orch host add node2 192.168.10.12 ceph orch host add node3 192.168.10.13 # 查看 OSD 可用设备 ceph orch device ls # 以所有可用磁盘创建 OSD ceph orch apply osd --all-available-devices # 检查集群状态 ceph -s ceph osd tree
当 ceph -s 显示 HEALTH_OK 且三个 OSD 均为 up 状态时，说明集群基础层已经就绪。接下来创建存储池并验证数据读写。创建 POOL 时需要指定 PG 数量，官方建议根据 OSD 数量与副本数计算，公式为：PG 总数 = 每 OSD 100 个 PG × OSD 数量 ÷ 副本数，结果向上取最近的 2 的幂次：
# 创建 3 副本存储池，32 个 PG ceph osd pool create rbd_pool 32 32 ceph osd pool set rbd_pool size 3 ceph osd pool set rbd_pool min_size 2 rbd pool init rbd_pool # 创建块设备镜像并挂载到客户端 rbd create rbd_pool/disk01 --size 100G rbd map rbd_pool/disk01 # 格式化并使用 mkfs.xfs /dev/rbd0 mount /dev/rbd0 /mnt/ceph_rbd df -h /mnt/ceph_rbd
至此，一套具备容错能力的块存储服务已经可用。客户端写入的数据会被切分为 4MB 大小的对象，经 CRUSH 计算后分布到三个不同节点的 OSD 上，任意一台节点故障，集群会在秒级感知并自动触发数据重建，业务无感知。
四、常见踩坑点与性能优化建议
部署完成后，生产运行阶段还有几个高频问题值得注意。第一是full ratio 告警：默认在集群使用率达到 85% 时会阻止写入，95% 时进入只读，因此必须提前规划容量并配置告警，不要等到集群满了再扩容。第二是PG 数量不合理：PG 太少会导致单个 PG 数据倾斜，太多则加重 Monitor 负担，建议使用 ceph osd pool autoscale-status 检查并开启 pg_autoscale 自动调节。第三是重建风暴：一个节点宕机恢复后，大量数据同时回填会挤占业务 I/O，可以降低 osd_recovery_max_active 和 osd_max_backfills 来限速。
性能优化方面，几点经验值得参考：
- 启用 BlueStore 而非旧的 Filestore，前者直接管理裸盘，减少一层文件系统开销，写放大更小；
- 为 WAL 分配独立 NVMe 分区，通常 10GB 到 20GB 即可显著提升小块随机写性能；
- 将
osd_op_threads与 OSD 数量匹配，并确认ms_bind_ipv6等网络配置与实际环境一致； - 块存储场景在客户端开启 RBD 缓存，设置
rbd_cache = true与合理的rbd_cache_max_dirty阈值。
监控层面，建议同时启用 Ceph Dashboard 和 Prometheus 告警。Dashboard 可通过以下命令重置账户密码并开启模块：
ceph mgr module enable dashboard ceph dashboard ac-user-create admin administrator ceph dashboard ac-user-set-password admin YourStrongPassword ceph config set mgr mgr/dashboard/ssl false ceph mgr module disable dashboard && ceph mgr module enable dashboard
总体而言，Ceph 的部署难度并不算高，真正的挑战在于容量规划、故障域设计和日常运维调优。掌握 CRUSH 规则树的编写与 PG 分布的观察方法，理解 Monitor 仲裁机制与 OSD 数据恢复流程，才能让集群在长期运行中保持健康稳定。建议在正式上线前，主动演练节点宕机、磁盘损坏等故障场景，验证副本冗余是否真正生效，这是一套生产级 Ceph 集群上线前不可省略的验收步骤。