跳转至

规划与 cephadm 部署

生产规划原则

Ceph 的可靠性来自跨故障域的数据冗余，不来自“安装了三个服务”。节点、磁盘、电源、交换机和机架必须与 CRUSH 规则对应。

节点与角色

  • 生产集群通常部署 3 或 5 个 MON，分散在不同故障域并保持奇数成员。
  • 至少准备两个 MGR，由一个 Active 和其他 Standby 提供管理服务连续性。
  • OSD 分布在多台存储节点，副本数不能超过可用故障域数量。
  • 使用 CephFS 时部署 Active MDS 及 Standby MDS。
  • 使用 RGW 时部署多个网关并通过负载均衡提供统一入口。

三节点是具备基本冗余的常见起点，不代表任何三台机器都适合生产。节点故障后的剩余容量、恢复带宽和业务性能必须提前计算。

磁盘

  • OSD 使用独立数据盘，不在已有文件系统或系统盘目录上简单划文件。
  • 记录每块盘的序列号、槽位、设备类型和对应 OSD ID。
  • 同一 Pool 的 OSD 容量差异不宜过大，否则大盘能力难以充分利用。
  • HDD 场景可将 BlueStore DB/WAL 放在独立 SSD/NVMe，但必须计算容量与故障影响。
  • RAID 控制器应采用符合 Ceph 设计的 HBA/JBOD 模式，避免不透明的写缓存和双重 RAID 策略。

网络

Ceph 使用 Public Network 承载客户端、MON 和部分守护进程通信；可选的 Cluster Network 主要承载 OSD 复制、恢复和心跳流量。

  • 所有节点需要稳定的主机名解析和时间同步。
  • 根据业务吞吐、OSD 数量和恢复窗口设计带宽，生产环境通常从 10GbE 及以上评估。
  • 双网并不自动高可用，需要交换机、Bond/LACP、路由和 MTU 全链路一致。
  • Jumbo Frame 只有在客户端、主机、交换机和所有路径统一支持时才启用。
  • 恢复流量和客户端流量会竞争网络，应监控并按业务窗口调节恢复参数。

容量计算示例

假设 4 台节点，每台 6 块 8 TB 数据盘：

原始容量 = 4 × 6 × 8 TB = 192 TB
三副本理论逻辑容量 ≈ 192 / 3 = 64 TB

64 TB 仍不是可承诺容量，还需扣除格式化开销、对象与元数据、容量不均衡以及故障恢复预留。应根据最满 OSD、业务增长速度和扩容交付周期设置告警，避免运行到 backfillfull 或 full 才扩容。

cephadm 部署流程

cephadm 使用容器运行 Ceph 守护进程，并由 Ceph Orchestrator 统一管理服务生命周期。以下命令用于说明流程，发行版、Ceph 版本、容器运行时和软件源必须先按官方支持矩阵确认。

1. 主机准备

所有节点统一完成：

  • 固定主机名、管理地址、DNS 或 /etc/hosts。
  • 时间同步、SSH、容器运行时和 LVM 工具。
  • 防火墙端口和节点间网络连通。
  • 数据盘清空确认及硬件健康检查。
  • 操作系统、内核和 Ceph 版本兼容性确认。

2. 引导首个节点

cephadm bootstrap --mon-ip <MON_IP>

Bootstrap 会创建首个 MON 和 MGR，生成 cephadm SSH Key，并写入管理配置与 client.admin Keyring。client.admin 权限极高，必须限制文件访问并纳入凭据备份。

ceph -s
ceph orch status
ceph orch ps

单机试验可使用官方的单机参数，但不能据此验证主机故障、MON 多数派和跨节点数据恢复。

3. 加入其他主机

ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-02
ceph orch host add ceph-02 10.10.10.12
ceph orch host add ceph-03 10.10.10.13
ceph orch host ls --detail

加入时使用的主机名应与远端 hostname 一致。建议显式提供管理 IP，避免 DNS 变化造成管理异常。

4. 部署 MON 与 MGR

ceph orch apply mon --placement="3 ceph-01 ceph-02 ceph-03"
ceph orch apply mgr --placement="2 ceph-01 ceph-02"
ceph quorum_status

生产环境要确认 MON 分散在不同故障域，而不只是进程数量达到三个。

5. 识别并部署 OSD

ceph orch device ls --wide
ceph orch daemon add osd ceph-01:/dev/sdb
ceph orch daemon add osd ceph-02:/dev/sdb
ceph orch daemon add osd ceph-03:/dev/sdb

ceph orch apply osd --all-available-devices 会消费所有满足条件的空闲设备，并且服务规格可能持续匹配以后出现的新设备。生产环境应优先使用明确的设备清单或 DriveGroup 规格，确认序列号和用途后再创建 OSD。

6. 创建业务服务

根据用途继续创建 RBD Pool、CephFS 或 RGW，配置最小权限客户端，并由应用执行读写和故障切换验证。

投产验收

测试 验收重点
停止一个 MON 多数派仍成立，集群管理可用
停止一个 OSD PG 降级后能恢复，业务延迟在可接受范围
停止一台存储节点 数据保持可用且剩余容量足以恢复
网络链路故障 Bond/交换机切换符合预期，无持续丢包
容量告警 能在 nearfull 前触发扩容流程
客户端权限 RBD/CephFS/RGW 账号只能访问授权资源
恢复演练 快照、备份或异地副本能够按目标恢复

官方参考：使用 cephadm 部署新集群、Host Management、OSD Service。