上篇文章讲到了Ceph在灾备方面有三大神兵利器：故障域、RBD异地灾备、RGW异地灾备。那么本文讲述下剩下的两大利器RBD异地灾备和RGW异地灾备
关卡五：Ceph灾备神兵利器-RBD Mirroring & RGW异地灾备
重要度：五颗星
Ceph灾备神兵利器-RBD Mirroring
Ceph RBD异地灾备术语叫做Ceph RBD Mirroring，在Ceph Jewel版本中宣布可用。在此之前Ceph块存储解决方案（俗称RBD）还不能很好的跨地域复制（灾备）。这里需要提醒一下，由于Ceph是强一致性，所以只有在所有副本都写完的时候才认为一个写操作完成。这就是为什么建立一个跨很长距离地域的集群通常都不是一个好主意，因为这种情况延时一般都很高。集群必须等到所有的写操作都完成，所以客户端可能需要大量的时间来进行确认。
因此，我们需要一种机制来允许我们在不同地域的集群之间复制块设备。这种方法将帮助我们实现下面两个不同的目的:
灾难恢复
全局块设备分布
具体实现
一个新的守护进程：rbd-mirror将负责把一个集群的镜像同步到另一个集群。在这两集群中都需要配置守护进程，它会同时连接本地和远程集群。在当前Jewel版本中，主要是实现两个守护进程之间一对一的关系，而在未来将会扩展到1对N。这样，在Jewel以后的版本中，你将能够配置一个集群备份到多个目标备份集群中。
实现原理
RBD Mirror的实现依赖于RBD image的两个新特性:
日志特性: 为作用在image上的每一个事务启用日志
Mirror特性: 通过这个明确的告诉
rbd-mirror进程复制这个image
后续还会有命令和librbd接口来为一个特定的Mirror启用/禁用。日志维护着这个image上的所有事务的操作记录列表。它可以被视为存在于集群中的另一个rbd image(一系列RADOS对象)。一般来说，一个写操作首先到达日志，再返回到客户端，然后被写入底层rbd image中。由于性能的原因，这个日志可以存放在跟执行日志化的image不同的资源池中。目前，每一个rbd image都有一个日志。在为Ceph实现一致性组（consistency group）之前，可能会一直保持这种结构。对于不熟悉这些概念的人而言，可以这样理解：一致性组是一个实体，它管理着可以被视为是一个的一堆卷(如:rbd image)。这样，你就可以针对这个组内的所有卷执行一些操作，比如快照。有了一致性组，就可以保证所有卷在同一个一致的状态上。所以当一致性组在Ceph中实现后，将使用一个日志来记录所有的rbd image，同时作为这个组的一部分。
RBD Mirror功能的启用和禁用可以作用在整个Pool或者一个image上。如果在资源池级别启用了RBD Mirror功能，这样资源池中的每一个启用了日志特性的镜像将会被Mirror agent复制。
具体的操作步骤可用查看：
http://ceph.org.cn/2016/05/08/ceph-jewel-%E5%8A%9F%E8%83%BD%E9%A2%84%E8%A7%88-ceph-rbd-mirroring/
http://www.sebastien-han.fr/blog/2016/03/28/ceph-jewel-preview-ceph-rbd-mirroring/
Ceph灾备神兵利器-RGW异地灾备
通过在单个Ceph集群之上搭建RGW服务，可用很轻松的实现一套基于HTTP标准的对象存储解决方案，但是对象存储服务一般都是面向互联网一类的应用，互联网应用一方面要求较高的可靠性，另一方面还需要最大可能的跨越地域限制去提供高速稳定的接入服务。
而RGW异地同步方案，刚好就是为了解决互联网服务的上述需求，一方面在多个地理位置存放数据实现服务的高可靠和高可用，另一方面借助DNS负载均衡、CDN等成熟技术手段，提供近端访问从而实现客户端的高速接入。
RGW逻辑概念
Region：一般用来代表逻辑上的地理区域（比如省会、国家等较大规模的地理范围），一个Region可以包含一个或多个Zone。若如果一个Ceph集群隶属于多个Region，则必须指定其中一个Region为Master Region。
Zone：指一个或多个RGW服务实例的逻辑组合，每个Region需要指定一个Master Zone来负责处理所有来自客户端的请求。也就是说，写对象操作只能在Master Zone进行（可读写），读对象操作可以在其他的Zone中进行。（只读）但是读者需要注意的是目前RGW并未设置任何策略来阻止除Master Zone以外的Zone进行写入操作，请务必遵循规范。
数据同步：实现多个Ceph集群之间的对象数据的同步（对象数据可以简单理解为bucket内存放的object数据）。
元数据同步：实现多个Ceph集群之间的对象元数据信息的同步（元数据信息可以简单理解为用户uid、email、access-key、secret-key等一类的元数据信息）。
RGW服务实例：这个概念相对来讲比较抽象，可以简单理解为一个RGW服务实例就对应一个在操作系统上运行的RGW服务。确切来讲一个RGW服务实例应该是对应一组Region和Zone配置信息。
同步日志：记录各个RGW服务实例的数据和元数据的变更情况。
同步代理agent：同步代理agent是一组同步服务，通过轮询的方式比较多个RGW服务实例之间的同步日志，从而得到需要同步的数据列表，之后根据列表调用RGW服务的相关API来实现数据和元数据的同步。
RGW灾备原理
要实现RGW异地同步，首先需要将原本孤立零散的RGW服务，按照一定逻辑组成Region和Zone，从而打破物理地域的限制，在逻辑上形成统一的命名空间。之后启动同步代理agent，通过轮询方式比较多个RGW服务实例之间的同步日志，最终按照Region和Zone的逻辑关系，将同步日志中的差异部分的数据和元数据按照一定规则进行同步。
标注：RGW部分讲述的是H版
RGW 的 H 版多站点同步，由于需要起额外的 python 写的 agent，配置复杂，锁失败等问题被废弃，如 http://tracker.ceph.com/issues/14081。
新版 multisite 沿用记日志再同步的架构，代码基本重写，引入了 boost 的协程框架，配置更清晰。同一个域下多 zone之间的数据为多主模式，可以同时写；元数据为主从模式，由主zone写入并同步到从zone，保证元数据一致性。并且即将支持桶级同步。最近主线合并了同步模型的插件框架，用户可以自定义插件来对接 elasticsearch 实现元数据索引，或者自定义的向云端备份等操作。
通过简短的两篇文章简单介绍了Ceph在灾备方面的三大神兵利器以及实现原理解析。文章涉及的比较基础，加上作者水平有限，希望本关卡能够给予Ceph新手参考。转眼间第七篇文章也结束了，剩下最后的运维关卡了，预知后事如何，请期待最后的《 运维&演练》。
本文转自Devin 51CTO博客，原文链接:http://blog.51cto.com/devingeng/1884397
