Ceph 生产环境搭建 | 第 4 天：Monitor 节点部署与高可用配置

第 4/20 天

Monitor（监控节点，简称 MON）是 Ceph 集群的”大脑”，它维护着集群所有组件的元数据映射（Cluster Map），并基于 Paxos 协议在多个 MON 之间达成共识。在生产环境中，MON 的数量、部署位置和高可用配置直接决定了集群能否在节点故障时继续提供服务。本篇将深入讲解 Monitor 的工作原理、Paxos 共识机制、quorum 选举过程，并在 Ubuntu 24.04 LTS 上使用 cephadm 完成 3 节点 MON 高可用部署。

一、Monitor 架构与核心原理

1.1 Monitor 在 Ceph 集群中的定位

Ceph 是一个去中心化的分布式存储系统，OSD 之间通过 CRUSH 算法自主完成数据寻址，客户端通过与 MON 通信获取最新的 Cluster Map 后，即可直接与 OSD 通信读写数据，无需经过中间代理层。Monitor 的核心职责是维护并分发这些 Map：

Map 类型	内容	更新频率
MON Map	Monitor 节点列表、地址、quorum 状态	低（仅 MON 变更时）
OSD Map	所有 OSD 的状态（up/down/in/out）、CRUSH 拓扑	中（OSD 状态变化时）
PG Map	Placement Group 的映射关系、状态	高（数据分布变化时）
MDS Map	CephFS Metadata Server 列表（仅 CephFS）	低
CRUSH Map	存储拓扑规则、故障域定义	低（拓扑调整时）

关键点：Monitor 不参与数据 I/O 路径。客户端只需要在首次连接和 Map 版本过期时联系 MON，之后所有读写操作直接命中 OSD。这意味着 MON 的负载主要来自 Map 维护和分发，而非数据吞吐。

1.2 Paxos 共识与 Quorum 机制

多个 Monitor 之间通过 Paxos 分布式共识算法保证 Cluster Map 的一致性。Paxos 的核心目标是：即使部分节点故障或网络分区，集群仍能就 Map 的最新状态达成一致。

Leader / Peon / Probe 角色：在 quorum 中，一个 MON 被选举为 Leader，负责发起提案（proposal）；其余 MON 作为 Peon 参与投票。quorum 之外的 MON 处于 Probing 状态，尝试与集群建立连接。
Quorum 要求：要形成有效的 quorum，需要超过半数的 MON 在线。因此生产环境推荐部署 3 个或 5 个 MON（奇数），容忍 1 个或 2 个节点故障。
Paxos 轮次：每次 Map 更新（如 OSD 上下线）触发一个新的 Paxos 轮次，Leader 提议 → Peon 承诺 → Leader 提交 → 全体持久化。更新成功后才向客户端分发新版本 Map。

1.3 Monitor 数据存储

每个 MON 将 Cluster Map 和 Paxos 日志存储在本地 RocksDB（基于 LevelDB/RocksDB 的键值存储）中，数据目录通常位于 /var/lib/ceph/mon/。由于 Monitor 需要频繁进行小事务读写，对磁盘的随机 IOPS 和延迟敏感，生产环境强烈建议将 MON 数据目录放在 SSD 或 NVMe 上，与 OSD 数据盘物理隔离。

二、部署实战：3 节点 Monitor 高可用配置

2.1 环境规划

本篇延续第 3 天 cephadm 引导初始化后的环境，集群已有一个 bootstrap MON。现在将其扩展为 3 节点高可用：

节点	主机名	公网 IP	集群网络 IP	角色
node-01	ceph-mon01	192.168.10.11	192.168.20.11	MON (bootstrap)
node-02	ceph-mon02	192.168.10.12	192.168.20.12	MON
node-03	ceph-mon03	192.168.10.13	192.168.20.13	MON

2.2 查看当前 MON 状态

首先确认 bootstrap MON 的运行状态和集群健康度：

💻 代码示例

# 查看 Monitor quorum 状态

ceph mon stat

# 查看详细 MON 节点信息

ceph mon dump

# 检查集群健康状态

ceph -s

输出示例（单节点 bootstrap 状态）：

💻 代码示例

mon_stat: 1 mons

{

"epoch": 1,

"min_mon_release": 19,

"quorum": [0],

"quorum_names": ["ceph-mon01"],

…

}

HEALTH_OK

2.3 配置 MON 节点 placement spec

cephadm 通过 service spec 声明式地管理 MON 部署。以下 YAML 定义了在指定主机上部署 MON，并使用公共网络：

💻 代码示例

# mon-spec.yaml — Monitor 部署规格

service_type: mon

placement:

hosts:

– ceph-mon01

– ceph-mon02

– ceph-mon03

count: 3

spec:

# 公共网络：客户端和 MON 通信使用

public_network: 192.168.10.0/24

# 集群网络：OSD 间复制流量（第 13 天详解）

cluster_network: 192.168.20.0/24

2.4 应用 spec 并扩展 MON

将部署规格提交给 cephadm，它会自动在目标主机上以容器方式拉起 Monitor：

💻 代码示例

# 应用 Monitor 部署规格

ceph orch apply -i mon-spec.yaml

# 查看编排进度

ceph orch ls –service_type mon

# 观察 MON 加入 quorum 的过程（实时刷新）

watch -n 2 'ceph mon dump'

当 3 个 MON 都进入 quorum 后，ceph mon dump 输出应类似：

💻 代码示例

{

"epoch": 3,

"min_mon_release": 19,

"quorum": [0, 1, 2],

"quorum_names": ["ceph-mon01", "ceph-mon02", "ceph-mon03"],

"quorum_leader_name": "ceph-mon01",

"mons": [

{"rank": 0, "name": "ceph-mon01", "addr": "192.168.10.11:6789/0"},

{"rank": 1, "name": "ceph-mon02", "addr": "192.168.10.12:6789/0"},

{"rank": 2, "name": "ceph-mon03", "addr": "192.168.10.13:6789/0"}

]

}

2.5 验证高可用与故障切换

模拟一个 MON 故障，观察 quorum 自动收缩和恢复：

💻 代码示例

# 1. 在 ceph-mon02 上停止 MON 容器

ssh ceph-mon02 'cephadm unit stop ceph-$(hostname -s)-mon'

# 2. 在 admin 节点观察 quorum 变化

ceph -s # 应显示 quorum 从 3 收缩为 2，HEALTH_WARN（MON_DOWN）

# 3. 恢复 ceph-mon02

ssh ceph-mon02 'cephadm unit start ceph-$(hostname -s)-mon'

# 4. 等待 MON 重新加入 quorum

ceph mon stat # quorum 恢复为 [0, 1, 2]，HEALTH_OK

三、关键配置参数详解

💻 代码示例

# 查看 MON 当前所有运行时配置

ceph config dump | grep mon

# 核心 MON 参数调优

ceph config set mon mon_compact_on_trim true

ceph config set mon mon_clock_drift_allowed 0.05

ceph config set mon mon_clock_drift_warn_backoff 30

ceph config set mon paxos_propose_interval 1.0

ceph config set mon mon_sync_max_payload_size 1048576

参数	默认值	说明
`mon_clock_drift_allowed`	0.05s	MON 间允许的时钟偏移上限，超过会触发告警。生产环境建议 NTP/Chrony 同步精度 < 10ms
`mon_compact_on_trim`	true	在 RocksDB trim 后执行压缩，防止 MON 数据库膨胀
`paxos_propose_interval`	1.0s	Leader 发起 Paxos 提案的最小间隔，影响 Map 更新延迟
`mon_sync_max_payload_size`	1MB	MON 间同步数据的单次负载大小
`mon_max_pg_per_osd`	250	单 OSD 承载的最大 PG 数，防止 MON 因 PG 过载拒绝新 OSD 加入

四、生产环境注意事项与踩坑提示

4.1 时钟同步（最常见踩坑点）

Monitor 基于 Paxos 协议，对节点间时钟一致性极度敏感。时钟偏差超过 mon_clock_drift_allowed（默认 50ms）会导致：

MON 被踢出 quorum，触发 HEALTH_WARN: clock skew
Leader 频繁切换，Map 更新延迟飙升
极端情况下 quorum 无法形成，整个集群不可用

必须在所有 MON 节点部署 Chrony NTP 服务并指向同一时间源：

💻 代码示例

# 安装并配置 chrony

apt install -y chrony

# 编辑 /etc/chrony/chrony.conf，添加可靠时间源

# server ntp.aliyun.com iburst

systemctl enable –now chrony

chronyc tracking # 验证偏移 < 10ms

4.2 MON 数据盘隔离

不要将 MON 数据目录与 OSD 数据放在同一块磁盘上。OSD 在磁盘故障恢复时会产生大量 I/O，可能阻塞 MON 的 RocksDB 写入，导致该 MON 被 quorum 判定为超时。生产环境推荐为每个 MON 分配独立的 SSD 分区（至少 20GB）。

4.3 MON 数量选择

3 个 MON：适用于中小型集群（< 50 OSD），容忍 1 个故障
5 个 MON：大型集群（> 50 OSD）或跨机房部署，容忍 2 个故障
不建议偶数个：2 个 MON 时任一故障即导致 quorum 丢失；4 个 MON 也只能容忍 1 个故障，相比 3 个无收益
不建议 > 5 个：MON 数量过多会增加 Paxos 通信开销，且 Map 同步延迟上升

4.4 防止脑裂（Split-Brain）

在跨机房部署场景中，网络分区可能导致两个 MON 子群各自形成 quorum。Ceph 通过以下机制防止脑裂：

Paxos 要求严格多数派，网络分区时少数派一方无法形成 quorum
但如果 3 MON 中恰好 2 个在分区一侧，它们仍可形成 quorum
建议：将 MON 分散到 3 个不同的故障域/机房，确保任一机房故障不影响 quorum 多数

五、常见问题 FAQ

Q1：集群显示 HEALTH_WARN: mon ceph-mon02 is in quorum but not reachabl，怎么处理？

这是网络抖动导致的临时状态。先检查 ceph-mon02 的网络连通性和 chrony 时钟偏移。如果持续不恢复，可手动重置该 MON：ceph mon reset ceph-mon02，然后检查其容器日志 cephadm logs --name mon.ceph-mon02。

Q2：MON 数据库膨胀导致磁盘写满，如何处理？

执行手动压缩：ceph tell mon.* compact，这会触发 RocksDB 全量 compaction。长期方案是确保 mon_compact_on_trim=true，并定期监控 /var/lib/ceph/mon/ 目录大小。如果 MON 数据超过 50GB，通常意味着 OSD Map 变更过于频繁，需要排查是否有 OSD 频繁 flapping。

Q3：能否用 ceph mon add 手动添加 MON 而不用 cephadm？

可以，但不推荐。ceph mon add 是传统手动方式，需要自行管理 MON 服务的生命周期（systemd、容器）。cephadm 方式通过 service spec 声明式管理，自动处理部署、升级、故障恢复，且与集群整体编排一致。生产环境应统一使用 cephadm。

六、总结

本篇完成了 Ceph 集群从单节点 bootstrap MON 到 3 节点高可用 Monitor 的部署。Monitor 作为集群元数据的中枢，基于 Paxos 共识保证一致性，通过 quorum 机制实现容错。生产环境部署的核心要点：保证奇数个 MON、分散到不同故障域、严格时钟同步、MON 数据盘与 OSD 隔离。掌握这些，集群的”大脑”就有了可靠的高可用保障。