Ceph RBD mirror数据异步备份的具体实践

备份是灾备的基础。在当今的灾备体系中，为了保证备份数据的可靠性以及可用性，备份数据往往都是独立于生产数据而存在，这也就使得的备份方式更多是通过在生产系统上部署客户端或Agent来完成数据的复制以及向备端的传输，然后通过备端完成数据的存储及归档等。

而软件定义存储则采用的是分布式架构，数据是以多副本的形式分散在几十成百甚至上千节点的集群进行存储的，凭借多副本机制以及后台校验等机制，软件定义存储可以提升集群数据的可靠性保护，在单个硬件发生故障时，节点可以做到动态的负载均衡，并且可以凭借分布在不同的机器上的副本及算法完成数据的恢复，实现高可用性。

但这种分布式存储机制，也导致了一个问题，就是很难用传统的基于存储复制或CDP等技术来完成对整个集群数据的异地复制以及传输。

本文就从此出发，以杉岩数据基于Ceph的RBD mirror上的具体实践为例，来谈谈软件定义存储的数据备份问题：

因为Ceph采用的是强一致性同步模型，即必须所有副本都完成写操作才算一次写入成功。而如果副本在异地的话，由于网络延迟的存在，那么整个集群的写性能就会比较差，也就无法有效支撑异地复制，较早的ZoneGroup和联合集群概念也并没有很好的解决这个问题。

于是从2015年开始启动的新功能——RBD Mirror进了大家的视线，用以解决两个集群间异步备份的问题。

RBD Mirror原理其实和MySQL的主从同步原理非常类似，简单地说就是利用日志进行回放(replay)：通过在存储系统中增加Mirror组件，采用异步复制的方式，实现异地备份。

在说Mirror之前，我们需要首先了解一下Ceph的journal机制。这里说明一下，此处的journal是指Ceph RBD的journal，而不是OSD的journal。

当RBD Journal功能打开后，所有的数据更新请求会先写入RBD Journal，然后后台线程再把数据从Journal区域刷新到对应的image区域。RBD journal提供了比较完整的日志记录、读取、变更通知以及日志回收和空间释放等功能，可以认为是一个分布式的日志系统。

具步骤如下：

1.I/O会写入主集群的Image Journal

2. Journal写入成功后，RBD再把数据写入主集群回复响应

3.备份集群的mirror进程发现主集群的Journal有更新后，从主集群的Journal读取数据，写入备份集群。

4.备份集群写入成功后，会更新主集群Journal中的元数据，表示该I/O的Journal已经同步完成

5.主集群会定期检查，删除已经写入备份集群的Journal数据。

这种方式的优点包括：

1、当副本在异地的情况下，减少了单个集群不同节点间的数据写入延时；

2、减少本地集群或异地集群由于意外断电导致的数据丢失。

目前社区的RBD mirror正在不断完善中，相信未来随着Ceph的不断发展，mirror在技术上也将为更为成熟，同时，由于Ceph可以作为OpenStack后端存储，因此mirror的逐步成熟，也将使得OpenStack在块设备的异地容灾方面有所提升。

其他方式：

软件定义存储实现了软硬件的分离，在硬件存储上独立出一个软件的管理层，而数据复制的这一动作就可以在这里完成，这就回避了前面所提到的由于存储节点分散而难以复制的问题。例如，利用SDS平台的Storage Management API允许备份系统生成一份对生产数据的静态拷贝，比如对生产数据做快照（snapshot），或者提供对多副本历史数据访问功能实现灾备，但这相当于在SDS中增加了CDP功能，对SDS的性能会有不小的影响，因此，目前并未看到有具体的实践产品。

另一种和SDS类似的方式则是通过在软件定义存储上一层搭建的分布式数据库进行数据的复制。所谓的分布式数据库，就是指分布式存储系统中各节点上数据库的逻辑集合，具体的复制机制类似SDS，这里就不再赘述。

从目前实际情况来看，不管是较为热门的云灾备理念还是两地三中心理念，网络的限制对异地灾备系统的限制依然较为明显，这个问题的解决任重而道远。世上没有100%的安全，也没有100%的灾备，黑天鹅事件总会发生，相比于“预防”，想想如何从黑天鹅事件中提升自己的反脆弱性而不仅仅是坚韧性同样重要。