3、存储层跨区复制:块存储复制、文件系统复制与对象存储跨区域复制
存储层的跨区复制,说白了就是给数据做一份「异地备份」。我做了这么多年容灾,最深的体会就是:存储是容灾的基石。计算层挂了可以快速拉起,网络断了可以切换线路,但数据丢了,一切归零。
这一章我们重点聊三种主流存储的跨区复制方案:块存储、文件系统、对象存储。每种方案适用的场景不同,坑也不一样。我一个个说。
核心观点:存储层跨区复制的本质是「数据冗余」+「地理位置分散」。没有地理分散,就不叫容灾。
3.1 块存储复制:Ceph RBD Mirroring
块存储复制,最典型的场景就是虚拟机磁盘镜像的跨区同步。Ceph RBD Mirroring 是我个人比较推荐的开源方案。
它的工作模式分两种:
- Journal-based(基于日志):每个写操作先写日志,再异步同步到远端。一致性高,但性能损耗大。
- Snapshot-based(基于快照):定期打快照,增量同步。性能好,但 RPO 取决于快照频率。
我在项目中遇到过一个问题:某客户用了 Journal-based 模式,结果跨区网络延迟 50ms,写性能直接掉了 40%。后来我们改成 Snapshot-based,RPO 控制在 5 分钟以内,性能影响降到 10%。
我的建议:如果业务对 RPO 要求极高(秒级),用 Journal-based;如果允许分钟级 RPO,Snapshot-based 更实用。
配置示例(Ceph RBD Mirroring 启用):
# 在源集群启用 mirroring
rbd mirror pool enable {pool-name} image
# 在目标集群配置 peer
rbd mirror pool peer add {pool-name} {peer-uuid}
# 查看同步状态
rbd mirror image status {image-name}
嗯,这里要注意:两个集群的 Ceph 版本必须一致。我曾经因为版本不匹配,折腾了两天才发现是兼容性问题。
3.2 文件系统复制:DRBD
DRBD(Distributed Replicated Block Device)是 Linux 内核级别的块设备复制方案。它工作在块设备层之上,文件系统层之下。说白了,它把磁盘的每一次写操作都同步到远端。
DRBD 有三种复制协议:
| 协议 | 写入确认时机 | RPO | 性能影响 |
|---|---|---|---|
| Protocol A | 本地写入完成即确认 | 可能丢失最后写入 | 低 |
| Protocol B | 本地写入完成 + 数据到达远端内存 | 远端宕机可能丢失 | 中 |
| Protocol C | 本地写入完成 + 远端写入磁盘完成 | 零数据丢失 | 高 |
我个人习惯用 Protocol C 做核心业务容灾。虽然性能损耗大,但数据安全是第一位的。你想想看,如果容灾系统本身就有数据丢失风险,那还容什么灾?
避坑指南:我曾经在 DRBD 配置中忽略了 net 段的 sndbuf-size 和 max-buffers 参数,导致跨区同步时频繁超时。后来调大了缓冲区,问题解决。记住:跨区网络延迟高,缓冲区一定要调大。
DRBD 配置示例(双主模式):
resource r0 {
protocol C;
net {
sndbuf-size 512k;
max-buffers 8000;
}
on node-a {
device /dev/drbd0;
disk /dev/sda1;
address 192.168.1.10:7788;
}
on node-b {
device /dev/drbd0;
disk /dev/sdb1;
address 192.168.2.10:7788;
}
}
3.3 对象存储跨区域复制:AWS S3 CRR
对象存储的跨区域复制,最典型的就是 AWS S3 的 Cross-Region Replication(CRR)。它把 S3 桶里的对象自动复制到另一个区域的桶里。
CRR 的核心机制:
- 异步复制:写入源桶后,S3 异步复制到目标桶。RPO 通常在 15 分钟以内。
- 版本控制:源桶和目标桶都必须开启版本控制。
- IAM 权限:需要给 S3 服务授权,允许它读取源桶并写入目标桶。
配置步骤(简化版):
- 在源桶和目标桶都开启版本控制。
- 创建 IAM 角色,授予跨区域复制权限。
- 在源桶的复制规则中指定目标桶和 IAM 角色。
我的经验:CRR 只复制新写入的对象,不会复制历史数据。如果需要迁移历史数据,得用 aws s3 sync 或者 S3 Batch Operations。我曾经踩过这个坑,以为 CRR 会自动同步所有数据,结果历史数据全没过去。
CRR 的适用场景:
- 合规要求:数据必须存储在多个地理区域。
- 低延迟访问:把数据复制到离用户更近的区域。
- 容灾备份:主区域故障时,从备用区域读取数据。
但 CRR 也有局限性:
- 不支持跨账号复制(除非使用 S3 Batch Replication)。
- 复制过程中不会保留对象的元数据修改时间。
- 复制是单向的,不能自动双向同步。
3.4 三种方案对比
我把这三种方案放在一起对比,方便你选型:
| 维度 | Ceph RBD Mirroring | DRBD | AWS S3 CRR |
|---|---|---|---|
| 存储类型 | 块存储 | 块设备 | 对象存储 |
| 复制粒度 | RBD 镜像 | 块设备 | 对象级别 |
| 同步模式 | 异步 | 同步/异步 | 异步 |
| 典型 RPO | 秒级到分钟级 | 零数据丢失(Protocol C) | 分钟级 |
| 性能影响 | 中 | 高(同步模式) | 低 |
| 适用场景 | 虚拟机磁盘、容器存储 | 数据库、关键业务 | 静态文件、备份数据 |
3.5 核心逻辑图:存储层跨区复制架构
下面这张图展示了三种存储复制方案在跨区容灾中的位置和关系:
3.6 选型建议
说了这么多,到底怎么选?我给出几条实际建议:
- 虚拟机磁盘容灾:首选 Ceph RBD Mirroring。它和 OpenStack、Kubernetes 集成度高,管理方便。
- 数据库容灾:用 DRBD Protocol C。数据库对数据一致性要求极高,零数据丢失是硬指标。
- 静态文件、日志、备份:用对象存储跨区域复制。成本低,管理简单,RPO 分钟级完全够用。
最后提醒:不管选哪种方案,一定要做容灾演练。我曾经见过一个客户,DRBD 配置了三年没出过问题,结果真发生故障时发现网络带宽不够,同步延迟了 2 小时。演练能暴露这些隐藏问题。