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 服务授权,允许它读取源桶并写入目标桶。

配置步骤(简化版):

  1. 在源桶和目标桶都开启版本控制。
  2. 创建 IAM 角色,授予跨区域复制权限。
  3. 在源桶的复制规则中指定目标桶和 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 核心逻辑图:存储层跨区复制架构

下面这张图展示了三种存储复制方案在跨区容灾中的位置和关系:

存储层跨区复制架构图 存储层跨区复制架构 源区域(主) 目标区域(备) Ceph RBD 镜像 DRBD 主节点 S3 源桶 Ceph RBD 镜像(备) DRBD 从节点 S3 目标桶 异步镜像 同步/异步复制 跨区域复制 三种方案覆盖块存储、文件系统、对象存储,满足不同业务场景的容灾需求 选择时需综合考虑 RPO、性能影响、网络条件和成本

3.6 选型建议

说了这么多,到底怎么选?我给出几条实际建议:

  • 虚拟机磁盘容灾:首选 Ceph RBD Mirroring。它和 OpenStack、Kubernetes 集成度高,管理方便。
  • 数据库容灾:用 DRBD Protocol C。数据库对数据一致性要求极高,零数据丢失是硬指标。
  • 静态文件、日志、备份:用对象存储跨区域复制。成本低,管理简单,RPO 分钟级完全够用。

最后提醒:不管选哪种方案,一定要做容灾演练。我曾经见过一个客户,DRBD 配置了三年没出过问题,结果真发生故障时发现网络带宽不够,同步延迟了 2 小时。演练能暴露这些隐藏问题。