1. 环境准备与需求评估
1.1 系统与硬件要求
在 Linux 下搭建 Ceph 集群，首要任务是明确<系统版本与内核版本、CPU、内存和存储介质的底层硬件条件。一个稳定的部署通常需要多节点、对称带宽充足的服务器集群，以及合适的 NVMe 或 SATA 存储介质来支撑 OSD 的 I/O。建议采用 双网卡或以上的设计，将管理网络与存储数据网络分离，以提升吞吐与稳定性。
关键要点包括：选择支持 Ceph 的发行版（如 CentOS/Red Hat系或 Ubuntu），确保内核版本和依赖包与 Ceph 版本兼容，以及为每台机器配置一致的基础环境。对虚拟化环境需要额外留意 CPU 亲和性和网络虚拟化性能，避免虚拟机对 Ceph 的干扰。
为了快速落地，推荐在初期使用少量节点进行试点，随后逐步扩容。容量规划应覆盖原始容量、冗余系数和未来扩展空间，避免在后续阶段频繁变更结构导致数据迁移负担增大。
1.2 网络与拓扑设计
Ceph 的高性能很大程度上取决于网络拓扑的设计。公开网络用于客户端与 MON 的连接，集群网络用于 OSD 之间的数据传输。确保网络互联性与低延迟是关键，MTU 设置应统一为 1500（或 9000 的 Jumbo Frame），并在交换机层实现对分段和排队的优化。
网络分段可以采用两网分离策略：一张网做客户端/MON，一张网做 OSD 间的后端通讯。严格控制防火墙策略，开放 ceph 的必需端口，确保集群内节点之间的心跳与数据传输不被干扰。
在拓扑设计阶段，明确 单点故障的风险点，如 MON 节点的冗余、OSD 的分布，以及 CRUSH 规则的分布策略。良好的拓扑有助于实现高可用和高吞吐。
1.3 存储介质与容量规划
Ceph 集群中的性能通常由 OSD 的数量与分布决定，因此在存储介质选型上应结合工作负载类型。对写入密集型工作负载，优先部署 NVMe 作为日志/缓存层，并以 HDD/SSD 作为大容量数据盘，以实现性价比与性能的平衡。
容量规划方面，设置 副本因子（size）以及是否采用纠删编码（EC）是关键决策。初期可先以 3 或 2 的副本系数进行试运行，后续再根据容量增长和可靠性需求调整。对 Pools 的分配需要考虑 PG 数量的合理计算，避免过多 PG 导致的元数据开销过大。
在创建数据池前，建议先完成 CRUSH 规则设计，确保数据在不同 OSD、HOST、机架之间均衡分布，降低热点和单点风险。
1.4 安全与权限准备
Ceph 集群的日常管理通常需要对多台主机进行远程操作，因此 无密码 SSH 配置、密钥管理和最小权限原则尤为重要。确保 SSH 公钥在各节点可用，并建立一个受控的管理员账户来执行运维任务。
此外，启用对 Ceph Dashboard 的访问控制、TLS 加密传输和证书轮换策略，是实现集群长期稳定运行的基础。访问控制清晰、证书管理规范化，是避免潜在中间人攻击和凭据泄露的关键。
在上线前，整理一份 运维清单，涵盖节点注册、镜像源、依赖版本、时间同步策略与备份方案，以确保后续操作可控且可追溯。
2. Ceph 集群部署实战
2.1 环境准备检查与依赖安装
在正式开始 Ceph 部署前，先完成环境自检与依赖安装，确保各节点具备一致的运行时环境。安装基础组件、如 Python3、OpenSSH、rsync、libselinux 等，并确保 apt/yum 源可用，以便获取 Ceph 组件与工具。
同时，进行一次 时钟同步，避免因为时间偏差导致证书和数据的一致性问题。NTP 服务应在所有节点上正确运行，确保 时间一致性，这是分布式系统稳定性的基础。
下面给出一个示例流程，演示从准备到安装的常规步骤。关键步骤集中在：创建无密码 SSH、安装 Cephadm、准备初始节点清单。
# 1) 在管理节点生成 SSH Key
ssh-keygen -t ed25519 -f ~/.ssh/ceph_key -N ""# 2) 将公钥分发到目标节点
for h in node1 node2 node3; dossh-copy-id -i ~/.ssh/ceph_key.pub $h
done# 3) 安装 Cephadm（以单台管理节点为起点引导部署）
sudo curl --silent --remote-name https://raw.githubusercontent.com/ceph/ceph/master/src/cephadm/cephadm
sudo chmod +x cephadm
sudo mv cephadm /usr/local/bin/# 4) 进行初始集群引导（mon 初始节点）
sudo cephadm bootstrap --mon-ip 10.0.0.10 --dashboard-user admin --dashboard-password # 5) 将其他节点加入集群（通过 cephadm 提供的 join 机制）
2.2 使用 Cephadm 部署核心组件（MON、OSD、MGR）
Cephadm 提供容器化的部署方式，能够统一管理 MON、OSD、MGR、MDS 等守护进程。通过 Cephadm 的命令，可以把多个节点注册为集群成员，并在需要时弹性添加/移除 OSD。
核心要点包括：确保 MON、OSD、MGR 的角色分布均衡，避免单点过载；在系统层面限制资源使用，避免单个容器占满节点资源；对启用的服务，启用 Dashboard 以实现可观测性。
以下代码示例展示了如何给额外节点打上标记、部署 MGR、以及为 OSD 指定使用的磁盘。请将 真实主机名、磁盘标识 替换为实际环境中的值。
# 1) 将新节点加入集群并标记为 osd 主机
sudo ceph orch host add node4 10.0.0.14# 2) 在新节点上部署 OSD，假设使用 /dev/nvme0n1 作为 OSD
sudo ceph orch daemon add osd node4:/dev/nvme0n1# 3) 在集群中部署/启动 MGR
sudo ceph orch apply mgr --placement="node3"
2.3 面向集群的存储池与 CRUSH 规则配置
创建数据池时，需考虑副本策略、分布与故障域。通过 CRUSH 规则实现数据分布的细粒度控制，确保不同机架、不同节点之间的数据冗余与均衡。
示例要点：创建一个名为 rbd-pool 的池，设置副本大小、规则及慢速路径。随后把应用数据映射到该池，确保数据持久化与可用性。
下面给出创建池及设置 CRUSH 规则的示例，帮助你在 Ceph 集群中实现高可用的数据分布。
# 1) 创建数据池
ceph osd pool create rbd-pool 128# 2) 设置副本大小，例如对象需要 3 副本
ceph osd pool set rbd-pool size 3# 3) 创建并应用一个简单的 replicated CRUSH 规则，与默认规则等效
ceph osd crush rule create-replicated myrule default 3
ceph osd pool set rbd-pool crush_rule myrule
2.4 数据冗余与故障演练
部署完成后，进行必要的故障演练和冗余检查，确保在单点故障发生时系统能够自动平衡并保持服务可用性。监控集群健康状态，利用 ceph -s、ceph health detail 等命令逐步排查。
演练要点包括：模拟一个 OSD 下线、MON 宕机或网络分区，观察 PGState、HEALTH_WARN/HEALTH_OK 的变化，确保 Ceph 动态重平衡机制能够正常工作。
在演练过程中，记录关键指标，如吞吐、延迟、PG 数、PG 回滚情况，以及重新平衡所需时间，以便未来扩容或故障恢复时做基线对比。
3. 运行与维护要点
3.1 监控与告警
持续的监控与告警是 Ceph 集群稳定运行的关键。通过 Ceph Dashboard、Prometheus、Grafana 等工具，可以对 OSD、MON、MGR、PG、RBD、RGW 等组件进行可观测性.management。
要点是开启 Prometheus 指标暴露、配置告警规则，以及在 Grafana 上搭建直观的仪表盘，以便运维团队快速定位异常。
开启示例：Mgr 指标暴露与仪表盘集成，以及常见告警项如健康状态、IO 吞吐下降、OSD 宕机等。
# 1) 启用 Prometheus 指标
ceph mgr module enable prometheus# 2) 将 Ceph Dashboard 与 Prometheus 数据源结合（按实际环境配置）
# 需在 Prometheus/Grafana 侧完成数据源和仪表盘配置
3.2 日志与故障排查
日志是排查故障的重要线索。Ceph 的日志分布在各个守护进程上，要求运维人员具备集中化日志分析能力。通过 ceph -s 与 ceph health detail 可快速定位问题所在。
排查步骤通常包含：检查 OSD 状态、查看 CRUSH 规则执行情况、分析 PG 迁移日志、核对磁盘健康状况以及网络连接性。
常见排查命令示例：
# 查看总体健康状态
ceph -s# 查看详细健康信息
ceph health detail# 查看某个 OSD 的状态与日志
ceph osd tree
ceph osd perf | head -n 20
3.3 升级与扩容策略
Ceph 集群的升级通常通过 Cephadm 进行滚动升级，确保服务连续性。升级前应完成备份、基线测试与版本兼容性评估，避免新版本带来的兼容性风险。
升级要点包括：准备合适的镜像版本、安排维护窗口、分阶段执行升级、监控升级进度并快速回滚。
升级示例：通过 Cephadm 指定镜像进行升级，确保 MON/OSD/MGR 的连续性和服务可用性。
# 1) 查看可用镜像与当前版本
cephadm --version
cephadm shell -- ceph version# 2) 升级 Ceph 集群镜像（滚动升级）
cephadm upgrade --image
3.4 备份与灾难恢复
在云原生与分布式对象存储场景中，灾难恢复是体系能力的一部分。对于 Ceph 集群，通常侧重于数据冗余、快照、跨区域复制以及可恢复性测试。
实践要点包括：对关键数据进行 RBD 快照、使用 RGW/对象网关实现对象版本控制、设置跨区域复制策略，以及演练灾难恢复流程以验证数据可恢复性。
以下是一个创建 RBD 快照的示例，帮助快速实现数据点的快照备份能力：
# 对名为 myvolume 的 RBD 映像创建快照
rbd snap create myvolume@snap-20250824
