场景分析
每个机房的Ceph都是独立的cluster，彼此之间没有任何关系。
多个机房都独立的提供对象存储功能，每个Ceph Radosgw都有自己独立的命名空间和存储空间。
这样带来两个问题：
-
针对Radosgw来说，我们的业务没法提供统一的命名空间；
-
没有机房级别的容灾，若一个机房Radosgw无法访问，则机房提供的对象存储瘫痪；
Realm：
Zonegroup： 理解为数据中心，由一个或多个Zone组成，每个Realm有且仅有 一个Master Zonegroup，用于处理系统变更，其他的称为Slave Zonegroup，元数据与Master Zonegroup保持一致；
Zone: Zone是一个逻辑概念，包含一个或者多个RGW实例。每个Zonegroup有且仅有一个Master Zone，用于处理bucket和user等元数据变更。
Period： 保存realm当前的配置信息，使用epoch维护版本信息。
Metadata Sync：Zone是一个逻辑概念，包含一个或者多个RGW实例。每个Zonegroup有且仅有一个Master Zone，用于处理bucket和user等元数据变更。
目前Ceph在多集群方案聚焦于接口层的方案，而不是在 RADOS 层面实现。比如 RADOS Object Storage在集群间通过Agent的方式进行数据同步，当然，在Jewel 版本中RADOS Object Storage V2种已经支持多读多写的机制，由于对象存储的弱语意，RADOS Object Storage的跨站仍然是最终一致性。其定义了 Zone，ZoneGroup 和联合集群概念，每个 Zone 可以理解为一个传统 Ceph 集群的部分，ZoneGroup 是多个Zone的集合，通常由不同地的Ceph集群中的Zone构成，而整个联合集群中只允许一个Master ZoneGroup 来进行写操作。因此从逻辑上来部署的话，Master ZoneGroup可以由多个Ceph集群构成，而Slave ZoneGroup也可以将这些Ceph集群的其他池作为Zone。这样就完成了多地多活的集群方案。
新版 Multi-Site 沿用记日志再同步的架构，代码基本重写，引入了boost 的协程框架，配置更清晰。同一个域下多 Zone之间的数据为多主模式，可以同时写；元数据为主从模式，由主Zone写入并同步到从Zone，保证元数据一致性。并且即将支持桶级同步。最近主线合并了同步模型的插件框架，用户可以自定义插件来对接 elasticsearch 实现元数据索引，或者自定义的向云端备份等操作。