Ceph将数据副本分布到不同的硬件，从而有效地避免由于硬件故障而导致数据丢失的问题，得以实现数据的高可用性。然而，这种分布式存储机制也导致传统的基于存储复制或CDP技术难以用于Ceph来实现跨数据中心的数据复制和恢复。
也许很多人可能想说，典型情况下既然Ceph保持3个副本，那么是否可以将副本放在异地数据中心。然而，这么做会导致Ceph读写数据的时延急剧上升。究其原因，Ceph采用的强一致性同步模型，只有等所有数据副本写操作完成才被认为一次操作完成，而两地数据中心之间通常有一定的网络延迟，从而导致整个ceph集群的写性能急剧下降。
基于上述问题，Ceph从Jewel版本开始引入了RBD Mirror功能来解决Ceph存储在数据备份容灾方面的需求。
RBD Mirror介绍
RBD mirror的原理，简单来说，就是利用日志（Journal）进行回放(replay)，来完成主从同步。有点类似于Mysql中的binlog。
当我们使用RBD Mirror功能时，需要打开RBDJournal功能（注：不是OSD Journal），此时，所有数据写操作会先写入RBDJournal，然后后台线程再把数据从Journal区域写入对应的image。
同时，还需要启动rbd-mirror服务，该服务负责监控远程Ceph集群的Journal，若有更新，则replay该Journal到本地RBD image。
具体的写IO过程如下：
1）写请求首先把数据写入RBD Journal；
2）Journal写入成功后，RBD再把数据写入RBD image，并回复Client ACK响应；
3）备份集群中的rbd-mirror发现主集群中的journal有更新，则从主集群中读取journal数据，写入备份集群的RBD image；
4）备份集群写入数据成功后，更新主集群的journal的元数据，表明该IO journal已经同步成功；
5）主集群定期检查并删除已经写入备份集群的journal数据。
RBD Mirror支持两种模式：RBD Image模式和Pool模式。RBD image模式下，会把指定的image进行镜像；而Pool模式则把该Pool中所有的image进行镜像。
总结
通过一个rbd-mirror的服务，依赖于image的journaling特性，来实现集群间的crash-consistent的image复制。
基于该机制，可以方便地实现两个OpenStack和Ceph集群的数据备份和灾难恢复。
