4、跨集群数据复制技术:同步复制 vs 异步复制、基于Rook/Ceph的跨集群复制、基于Longhorn的灾备复制
在多集群 Kubernetes 架构中,数据复制是保障业务连续性和数据一致性的核心能力。本章聚焦三种主流复制模式:同步复制与异步复制的理论对比,以及基于 Rook/Ceph 和 Longhorn 的跨集群复制实践方案。
4.1 同步复制 vs 异步复制:核心差异与选型
跨集群数据复制的首要决策是选择同步还是异步模式。两者在数据一致性、延迟、可用性上存在根本性差异。
| 对比维度 | 同步复制 | 异步复制 |
|---|---|---|
| 数据一致性 | 强一致性(所有副本写入完成才返回成功) | 最终一致性(主副本写入即返回,后台同步) |
| 写入延迟 | 高(等待所有副本确认,受跨集群网络 RTT 影响) | 低(仅本地写入延迟,后台异步传输) |
| 吞吐量 | 受限于最慢副本的写入速度 | 接近本地存储性能 |
| 数据丢失风险 | 极低(所有副本同步后才确认) | 存在窗口期(主集群故障时未同步数据可能丢失) |
| 跨集群带宽要求 | 高(每次写入都需跨集群传输) | 中等(可批量压缩传输) |
| 典型场景 | 金融交易、数据库主备、强一致性要求 | 灾备、日志归档、大数据分析、内容分发 |
选型建议: 同步复制适用于跨集群延迟 < 5ms 且业务对数据零丢失有硬性要求的场景;异步复制更适合跨地域(延迟 > 20ms)或对性能敏感的场景。实际生产环境中,常采用“同步+异步”混合策略:本地集群内同步,跨集群异步。
4.2 基于 Rook/Ceph 的跨集群复制
Rook 是 Kubernetes 上运行 Ceph 的 Operator,Ceph 本身支持 RBD Mirroring(块设备镜像)和 RGW Multi-site(对象存储多站点)两种跨集群复制机制。
4.2.1 RBD Mirroring:同步与异步模式
RBD Mirroring 支持两种复制模式,通过 rbd mirror pool peer 命令配置。
- 同步模式(journal-based): 每个写操作先写入 journal 日志,由远程集群 replay 后确认。提供强一致性,但性能开销较大。
- 异步模式(snapshot-based): 基于定期快照差异同步,默认每 5 分钟同步一次。性能影响小,但存在数据窗口。
# 创建 RBD 镜像池并启用 mirroring
rbd pool create replicated-pool --size 10G
rbd mirror pool enable replicated-pool site-a
# 添加对端集群
rbd mirror pool peer add replicated-pool client.admin@site-b
# 为特定镜像启用 mirroring
rbd mirror image enable replicated-pool/my-image snapshot
4.2.2 RGW Multi-site:对象存储跨集群复制
RGW(RADOS Gateway)多站点配置支持 S3 兼容的对象存储跨集群同步。每个 zone 对应一个 Kubernetes 集群,数据通过 zonegroup 实现双向或单向同步。
关键配置参数:
sync_from_all:是否从所有 zone 同步数据sync_policy:定义同步方向(单向/双向)和过滤规则data_extra_pool:存储同步元数据的专用池
# RGW 多站点 zonegroup 配置示例(简化)
radosgw-admin zonegroup create --zonegroup=global \
--master-zone=site-a-zone --endpoints=http://rgw.site-a:80
radosgw-admin zone create --zonegroup=global --zone=site-b-zone \
--endpoints=http://rgw.site-b:80 --sync-from-all=true
4.3 基于 Longhorn 的灾备复制
Longhorn 是 CNCF 毕业项目,提供轻量级、Kubernetes 原生的分布式块存储。其灾备复制通过 DR Volume(Disaster Recovery Volume)功能实现跨集群异步复制。
4.3.1 DR Volume 工作原理
- 主集群(Active): 运行生产工作负载,定期对卷创建快照。
- 备集群(Standby): 创建 DR Volume,从主集群拉取快照差异。
- 恢复流程: 主集群故障时,将 DR Volume 激活为普通卷,挂载到 Pod 继续运行。
# 在主集群创建卷并启用灾备
kubectl create -f - <<EOF
apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
name: prod-data
spec:
size: 100Gi
numberOfReplicas: 3
disasterRecovery: true
disasterRecoverySecret: dr-secret
EOF
# 在备集群创建 DR Volume
kubectl create -f - <<EOF
apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
name: prod-data-dr
annotations:
disaster-recovery-volume: "true"
spec:
size: 100Gi
numberOfReplicas: 2
fromBackup: "s3://backup-bucket/prod-data/latest"
EOF
4.3.2 灾备复制关键参数
| 参数 | 说明 | 推荐值 |
|---|---|---|
snapshotInterval |
主集群快照创建间隔 | 5 分钟(生产) / 1 小时(归档) |
backupTarget |
备份存储目标(S3/NFS) | 跨地域 S3 Bucket |
recurringJobs |
定期备份和快照策略 | 每天保留 7 个快照 |
standbyTimeout |
DR Volume 等待激活的超时时间 | 30 分钟 |
4.4 复制方案对比与选型矩阵
| 方案 | 复制粒度 | 一致性模型 | 跨集群延迟要求 | 运维复杂度 | 适用场景 |
|---|---|---|---|---|---|
| RBD Mirroring(同步) | 块设备 | 强一致 | < 5ms | 中 | 数据库主备、有状态服务 |
| RBD Mirroring(异步) | 块设备 | 最终一致 | < 50ms | 中 | 灾备、开发测试环境 |
| RGW Multi-site | 对象存储 | 最终一致 | < 100ms | 高 | 内容分发、日志归档 |
| Longhorn DR Volume | 块设备 | 最终一致 | < 200ms | 低 | Kubernetes 原生灾备 |
生产注意事项:
- 同步复制场景下,务必监控跨集群网络延迟和丢包率,避免因网络抖动导致写入超时。
- Longhorn DR Volume 在激活前不会占用备集群的存储空间(仅元数据),但激活后需要预分配完整容量。
- RBD Mirroring 的 journal 模式会额外消耗约 20% 的写入 IOPS,建议在性能敏感场景使用 snapshot 模式。
- 所有跨集群复制方案都应配置独立的备份目标(如 S3),防止主备集群同时故障时数据完全丢失。