Ceph 生产环境搭建 | 第 18 天：Ceph 高可用与容灾设计：多副本、跨机房与异地灾备

第 18/20 天

引言：为什么 Ceph 高可用与容灾是生产环境的生命线

在前 17 天的系列中，我们从架构选型一路走到集群扩容，已经构建了一个功能完整的 Ceph 生产集群。但一个关键问题始终悬在头顶：当整个机房断电、网络骨干中断或遭遇自然灾害时，你的数据还在吗？业务能多快恢复？

Ceph 作为分布式存储系统，其核心设计理念就是「没有单点故障」（No Single Point of Failure）。但「集群内高可用」和「跨站点容灾」是两个不同层级的课题。前者依靠多副本和 CRUSH 故障域分布解决单磁盘、单节点、单机架故障；后者则需要跨机房、跨地域的复制拓扑来应对整站级灾难。

本篇将系统讲解 Ceph 在生产环境中的三层高可用与容灾体系：

第一层：集群内高可用 —— 多副本与纠删码、CRUSH 故障域隔离
第二层：跨机房容灾 —— Stretch Mode 拉伸集群、CRUSH 跨域分布
第三层：异地灾备 —— RBD 异步镜像、RGW 多站点、CephFS 快照远程复制

架构与原理：Ceph 高可用的三层防御体系

第一层：集群内高可用机制

Ceph 的集群内高可用建立在两个核心机制之上：

1. 多副本（Replication）

每个 PG（Placement Group）的数据会被复制到 N 个 OSD 上（由 size 参数决定）。当某个 OSD 故障时，CRUSH 会自动选择剩余副本继续服务读写请求，同时后台触发数据恢复（Recovery/Backfill）将数据重新均衡到新的 OSD。

2. 纠删码（Erasure Coding）

对于冷数据或大容量场景，纠删码以 (k+m) 配置将数据分片并计算校验块，可在丢失 m 个块的情况下仍然恢复数据，存储效率远高于多副本。

机制	存储开销	容错能力	适用场景	性能
3 副本	3x	可丢失 2 个 OSD	热数据、RBD	高（本地副本直接读）
2 副本	2x	可丢失 1 个 OSD	开发测试环境	中
EC 4+2	1.5x	可丢失 2 个块	冷数据、对象存储	低（需计算恢复）
EC 8+3	1.375x	可丢失 3 个块	归档存储	低

第二层：跨机房容灾——Stretch Mode 拉伸集群

Ceph 从 Reef 版本开始引入了 Stretch Mode（拉伸模式），在 Squid v19 中进一步成熟。其核心思想是将一个 Ceph 集群跨越两个或三个物理数据中心部署，通过 CRUSH 规则确保数据副本分布在不同机房。

Stretch Mode 的关键设计：

两个数据站点（Data Sites）：各承载数据副本
一个仲裁站点（Tiebreaker Site）：部署一个轻量 Monitor，仅参与 quorum 投票，不存储数据
5 个 Monitor：Data Site A 放 2 个，Data Site B 放 2 个，Tiebreaker Site 放 1 个
CRUSH 跨域分布：确保每个 PG 的副本分布在不同的 Data Site

当 Data Site A 整体宕机时，Data Site B 的 2 个 Monitor 加上 Tiebreaker 的 1 个 Monitor 仍能组成 quorum（3/5），集群继续运行。

第三层：异地灾备——异步复制方案

当两地距离超过 100ms 延迟时，Stretch Mode 的同步写入性能将严重退化。此时应采用异步复制方案：

RBD Mirroring（块存储镜像）

基于 Journal（日志）的异步复制
主集群将写入操作记录到 journal pool
备集群的 rbd-mirror 守护进程拉取 journal 并重放
支持 one-way（单向）和 two-way（双向）模式
RPO（恢复点目标）：秒级到分钟级

RGW Multisite（对象存储多站点）

基于 metadata log 和 data log 的异步同步
支持 zone 之间的完全双向同步
每个 zone 独立存储完整数据副本
RPO：秒级（metadata）/ 分钟级（data）

CephFS Disaster Recovery

通过快照定期导出到远程集群
基于 cephfs-journal-tool 进行日志回放
Squid v19 支持异步快照同步（实验性）

部署实战：构建跨机房高可用与异地灾备

场景一：启用 Stretch Mode（跨双机房拉伸集群）

假设我们有两个机房 DC-A 和 DC-B，以及一个仲裁站点 DC-Witness。

💻 代码示例

# 查看当前 MON 分布

ceph mon stat

# 查看当前 crush rule

ceph osd crush rule list

# 确认集群版本支持 stretch mode（需 Reef v18 或 Squid v19+）

ceph versions | grep ceph

首先定义 CRUSH 层级结构，将 OSD 按 datacenter 分组：

💻 代码示例

# 创建 bucket 结构：root -> datacenter -> host -> osd

ceph osd crush add-bucket dc-a datacenter

ceph osd crush add-bucket dc-b datacenter

ceph osd crush move dc-a root=default

ceph osd crush move dc-b root=default

# 将各机房的主机移入对应 datacenter

# 假设 node01-node04 在 DC-A，node05-node08 在 DC-B

ceph osd crush move node01 root=dc-a

ceph osd crush move node02 root=dc-a

ceph osd crush move node03 root=dc-a

ceph osd crush move node04 root=dc-a

ceph osd crush move node05 root=dc-b

ceph osd crush move node06 root=dc-b

ceph osd crush move node07 root=dc-b

ceph osd crush move node08 root=dc-b

创建跨机房副本规则，确保每个 PG 的副本分布在不同 datacenter：

💻 代码示例

# 创建 replicated 规则，chooseleaf 以 datacenter 为故障域

ceph osd crush rule create-replicated

stretch_rule default datacenter host

# 将存储池应用 stretch_rule

ceph osd pool set rbd crush_rule stretch_rule

ceph osd pool set cephfs_data crush_rule stretch_rule

# 验证规则

ceph osd crush rule dump stretch_rule

启用 Stretch Mode 并设置仲裁 MON：

💻 代码示例

# 将集群切换到 stretch mode

ceph mon stretch enable

–tiebreaker mon.tiebreaker

–crush-rule stretch_rule

–dividing-bucket datacenter

# 验证 stretch mode 状态

ceph mon stat

ceph status | grep -i stretch

# 查看 PG 跨机房分布情况

ceph osd pool autoscale-status

验证数据跨机房分布：

💻 代码示例

# 查看 PG 在各 OSD 的映射，确认副本跨 DC

ceph osd map rbd test_image_001 0

# 查看 crush tree 确认拓扑正确

ceph osd crush tree –show-shadow

# 查看 PG 分布统计

ceph pg dump pgs | head -20

场景二：RBD 异步镜像（异地灾备）

在主集群（Site-A）配置 journal pool 和镜像功能：

💻 代码示例

# === 主集群 Site-A 操作 ===

# 启用 RBD journaling 特性（对已有镜像需逐个启用）

ceph osd pool create rbd_journal 64

ceph osd pool application enable rbd_journal rbd

# 对存储池开启镜像功能

rbd mirror pool enable rbd image

rbd mirror pool enable rbd_journal pool

# 为存储池启用 journaling

rbd feature enable rbd –image –journaling –exclusive-lock

在备集群（Site-B）配置 rbd-mirror 守护进程并建立对等关系：

💻 代码示例

# === 备集群 Site-B 操作 ===

# 创建同名的存储池

ceph osd pool create rbd 64

ceph osd pool application enable rbd rbd

# 部署 rbd-mirror 守护进程

ceph orch apply rbd-mirror –placement="node-mirror-01"

# 在主集群创建 bootstrap token（peer token）

rbd mirror pool peer bootstrap create

–site-name site-a rbd > /tmp/peer_token_a.txt

# 在备集群导入 token 建立对等关系

cat /tmp/peer_token_a.txt |

rbd mirror pool peer bootstrap import

–site-name site-b rbd

对特定 RBD 镜像启用镜像并验证同步状态：

💻 代码示例

# 对单个镜像启用镜像

rbd mirror image enable rbd/vm-disk-001

# 查看镜像同步状态

rbd mirror image status rbd/vm-disk-001

# 查看存储池级别的镜像概览

rbd mirror pool info rbd

rbd mirror pool status rbd –verbose

场景三：RGW 多站点配置（对象存储灾备）

在主站点创建 realm 和 master zone：

💻 代码示例

{

"name": "multisite-realm",

"current_period": "2026-10-12-001",

"epoch": 1,

"zones": [

{

"name": "site-a-zone",

"endpoints": ["https://rgw.site-a.example.com:8080"],

"log_meta": "true",

"log_data": "true",

"tier_type": "",

"index_type": 0,

"role": "master"

{

"name": "site-b-zone",

"endpoints": ["https://rgw.site-b.example.com:8080"],

"log_meta": "true",

"log_data": "true",

"tier_type": "",

"index_type": 0,

"role": "slave"

}

]

}

💻 代码示例

# === 主站点 Site-A ===

# 创建 realm 并设置为主 master

radosgw-admin realm create –rgw-realm=multisite-realm –default

# 创建 master zonegroup

radosgw-admin zonegroup create

–rgw-realm=multisite-realm

–master

–endpoints=https://rgw.site-a.example.com:8080

# 创建 master zone

radosgw-admin zone create

–rgw-zonegroup=default

–rgw-zone=site-a-zone

–master

–endpoints=https://rgw.site-a.example.com:8080

# 创建 period 并提交

radosgw-admin period update –commit

在备站点配置 secondary zone 并建立同步：

💻 代码示例

# === 备站点 Site-B ===

# 使用主站点生成的 period 文件拉取配置

radosgw-admin realm pull

–url=https://rgw.site-a.example.com:8080

–access-key=SYSTEM_ACCESS_KEY

–secret=SYSTEM_SECRET_KEY

# 创建 secondary zone

radosgw-admin zone create

–rgw-zonegroup=default

–rgw-zone=site-b-zone

–endpoints=https://rgw.site-b.example.com:8080

–access-key=SYSTEM_ACCESS_KEY

–secret=SYSTEM_SECRET_KEY

# 提交 period 更新（触发同步初始化）

radosgw-admin period update –commit

# 重启 RGW 守护进程以加载新配置

ceph orch restart rgw.site-b

验证 RGW 多站点同步状态：

💻 代码示例

# 查看同步状态

radosgw-admin sync status –rgw-zone=site-b-zone

# 查看 data sync 进度

radosgw-admin data sync status

# 查看 metadata sync 进度

radosgw-admin meta sync status

配置参数详解

💻 代码示例

# /etc/ceph/ceph.conf —— Stretch Mode 关键参数

[mon]

# Stretch mode 的 min_size 自动调整为 2

# 确保在单 DC 存活时仍可写入

mon_stretch_mode_enabled = true

mon_stretch_seed_count = 5

[osd]

# 恢复参数：跨机房恢复需要控制带宽

osd_recovery_op_priority = 1

osd_max_backfills = 1

osd_recovery_max_active = 3

# 跨机房恢复间隔，避免同时大量恢复冲击网络

osd_recovery_sleep = 0.1

[client]

# 客户端读写优先选择本 DC 副本

rbd_prefer_primary = true

参数	默认值	生产建议	说明
`osd_recovery_op_priority`	3	1（跨DC）	恢复操作优先级，降低以保护正常 IO
`osd_max_backfills`	1	1-2	同时进行 backfill 的 PG 数
`osd_recovery_max_active`	3	3	每 OSD 同时活跃恢复请求数
`mon_stretch_mode_enabled`	false	true	启用拉伸模式
`rbd_mirror_journal_pool`	—	rbd_journal	RBD 镜像日志专用池
`rgw_sync_require_all_ops`	false	true	RGW 同步是否要求所有操作完成

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

1. Stretch Mode 的网络延迟红线

跨机房同步写入意味着每次客户端写操作都要等待跨 DC 网络往返。当 RTT 超过 5ms 时，写入延迟会显著上升；超过 10ms 则严重影响用户体验。建议：

Stretch Mode 仅用于 RTT < 5ms 的同城双机房（通常物理距离 < 50km）
跨城（RTT > 10ms）场景必须使用异步方案（RBD Mirroring / RGW Multisite）
使用 ceph tell osd.* bench 测试跨 DC 网络延迟

2. RBD Mirroring 的 Journal 池容量规划

Journal 池存储所有写入操作的日志记录。如果备站点长时间离线，journal 会持续增长，可能导致主集群磁盘耗尽：

💻 代码示例

# 监控 journal 池使用率

rados df -p rbd_journal

# 设置 journal 池配额（防止单点耗尽）

ceph osd pool set-quota rbd_journal max_bytes 500G

# 查看 journal 积压情况

rbd mirror pool status rbd –verbose | grep entries

3. RGW Multisite 的 metadata 与 data 同步分离

RGW 同步分两阶段：metadata（bucket/user 等元数据）和 data（实际对象数据）。metadata 同步通常很快，但 data 同步取决于对象大小和网络带宽。大对象场景下，data sync 可能严重滞后于 metadata sync，导致备站点能列出对象但无法访问内容。

4. 故障切换（Failover）流程标准

跨站点故障切换必须遵循严格流程，避免脑裂（Split-Brain）：

RBD Mirroring failover：先在主站点停止 IO → 在备站点执行 rbd mirror image demote + promote → 切换客户端到备站点
RGW Multisite failover：在备站点执行 radosgw-admin zone modify --master → period update --commit → 修改 DNS 指向
Stretch Mode 降级运行：单 DC 存活时集群自动降级为 degraded 状态，min_size 自动调整，但恢复后必须检查数据一致性

5. 踩坑：CRUSH 规则与 PG 亲和性冲突

在跨机房场景中，如果 CRUSH 规则配置不当，可能出现「所有副本集中在同一 DC」的致命问题。务必使用 chooseleaf 以 datacenter 为故障域：

💻 代码示例

# 错误：以 host 为故障域（无法保证跨 DC 分布）

# ceph osd crush rule create-replicated bad_rule default host

# 正确：以 datacenter 为故障域

# ceph osd crush rule create-replicated stretch_rule default datacenter host

6. 监控跨站点同步健康

生产环境必须持续监控复制链路健康度。推荐使用第 15 天介绍的 Prometheus + Grafana 监控以下指标：

ceph_rbd_mirror_snapshot_sync_bytes —— RBD 镜像同步速率
rgw_sync_status —— RGW 同步状态
ceph_pg_degraded —— PG 降级计数（Stretch Mode 下正常）

常见问题

Q1：Stretch Mode 和传统多机房 CRUSH 分布有什么区别？

Stretch Mode 是 Ceph 官方支持的跨 DC 部署模式，它在 MON quorum 层面做了特殊处理（5 MON + 仲裁站点），当单 DC 故障时集群仍能维持 quorum 并自动调整 min_size。传统的手动 CRUSH 跨 DC 分布无法处理 MON quorum 问题——如果 3 个 MON 中 2 个在故障 DC，集群将失去 quorum 而停止服务。

Q2：RBD Mirroring 的 RPO 到底能到多少？

理论上 RBD Mirroring 的 RPO 在秒级，因为 journal 是实时写入的。但实际 RPO 取决于网络带宽和写入速率。高峰期如果写入速率超过网络带宽，journal 会积压，RPO 可能退化到分钟级甚至更长。建议为镜像链路预留至少 1.5 倍峰值写入带宽的网络容量。

Q3：异地灾备中数据校验怎么做？

建议定期执行数据一致性校验。RBD 镜像可使用 rbd diff 对比主备镜像的校验和；RGW 多站点可对 bucket 执行 radosgw-admin bucket list --stats 对比对象数量和总大小。对于关键数据，建议每季度执行一次全量校验，及时发现静默数据损坏（Silent Data Corruption）。