概述
随着提供云服务的机房的增多，为了提供更高的可靠性，满足高可用客户的需求，跨机房灾备必须实现，本文档重点调研Ceph RBD的跨机房容灾方案。
当前状况
当前应用中，每个机房的Ceph都是独立的cluster，彼此之间没有任何关系。
比如我们在机房A和机房B上部署了两套Openstack+Ceph的环境，底层的Ceph就是ClusterA和ClusterB。每个Cluster独立提供自己的块存储RBD服务。
方案
方案1 - Snapshot
* Ceph版本要求
当前我们使用的Hammer 0.94.5版本即可
* 原理
异步备份，基于RBD的snapshot机制
* 介绍
Cluster A & B仍然是独立的Ceph集群，通过RBD的snapshot机制，在Cluster A端，针对image定期通过rbd创建image的snap，然后通过rbd export-diff, rbd import-diff命令来完成image备份到Cluster B。
* 命令和步骤
把 Cluster A 的 pool rbd 下面 image testimage 异步备份到 Cluster B 的 pool rbd 下的相同image上；
在Cluster A/B上创建rbd/testimage
rbd create -p rbd --size 10240 testimage在准备备份image前，暂停Cluster A端对testimage的IO操作，然后创建个snapshot
rbd snap create <snap-name>导出Cluster A端的testimage数据，不指定from-snap
rbd export-diff <image-name> <path>copy上一步中导出的文件到Cluster B，并导入数据到testimage
rbd import-diff <path> <image-name>
后续需周期性的暂停Cluster A端的testimage的IO，然后创建snapshot，通过 rbd export-diff <image-name> [--from-snap <snap-name>] <path>命令导出incremental diff，之后把差异数据文件copy到Cluster B上，然后通过命令rbd import-diff <path> <image-name>导入。
【注】：也可不暂停Cluster A端的IO，直接take snapshot；这样并不会引起image的数据不一致，只是有可能会使rbd export-diff时导出的数据在take snapshot之后
* 优缺点
优点：
- 当前Ceph版本就支持rbd snapshot的功能
- 命令简介方便，通过定制执行脚本就能实现rbd块设备的跨区备份
缺点：
- 每次同步前都需要在源端take snapshot
- 持续的snapshots可能导致image的读写性能下降
- 还要考虑后续删除不用的snapshots
- snapshot只能保证IO的一致性，并不能保证使用rbd块设备上的系统一致性；
【可以每次暂停image的IO，sync IO数据来保证rbd块设备上的系统一致性，但需要虚拟机支持qemu-guest-agent】
* 参考资料
https://ceph.com/dev-notes/incremental-snapshots-with-rbd/
https://www.rapide.nl/blog/item/ceph_-_rbd_replication.html
http://wiki.libvirt.org/page/Qemu_guest_agent
方案2 - One Ceph Cluster
* Ceph版本要求
当前我们使用的Hammer 0.94.5版本即可
* 原理
同步备份，跨机房的Ceph集群，底层存储的跨机房容灾
* 介绍
把两个机房的物理机搭建为一个Ceph Cluster，通过Ceph本身的写多份容灾
* 优缺点
优点：
- 一个Ceph集群，能保证实时的跨机房容灾
- 不需要额外开发
缺点：
- 部署相对麻烦
- 跨机房的时延较大，影响Ceph集群性能
* 步骤和参考资料
http://www.sebastien-han.fr/blog/2013/01/28/ceph-geo-replication-sort-of/
方案3 - RBD Mirroring
* Ceph版本要求
Jewel版本，最好是最新的10.2.2
* 原理
异步备份，Ceph新的rbd mirror功能
* 介绍
Ceph新的rbd mirror功能支持配置两个Ceph Cluster之间的rbd同步
* 优缺点
优点：
- Ceph新的功能，不需要额外开发
- 同步的粒度比较小，为一个块设备的transaction
- 保证了Crash consistency
- 可配置pool的备份，也可单独指定image备份
缺点：
- 需要升级线上Ceph到Jewel 10.2.2版本
- 不确定升级的影响和工作量
* 步骤和参考资料
http://docs.ceph.com/docs/jewel/rbd/rbd-mirroring/
https://www.sebastien-han.fr/blog/2016/03/28/ceph-jewel-preview-ceph-rbd-mirroring/
http://www.sebastien-han.fr/blog/2016/04/27/OpenStack-Summit-Austin-protecting-the-galaxy-Multi-Region-Disaster-Recovery-with-OpenStack-and-Ceph/
http://www.spinics.net/lists/ceph-devel/msg24169.html
https://www.zybuluo.com/zphj1987/note/328708
推荐方案
综合上面的描述和优缺点分析，方案3 - RBD Mirroring 会是一个比较好的选择。
这样我们不仅能跟随Ceph社区的节奏，也能很好的解决我们跨机房同步的需求，后续RBD Mirroring功能的升级，我们也能应用上。
