3.1.3 远程复制
Ceph 在 Jewel 版引入了 rbd-mirror 新功能，它可以将数据从主集群异步复制到备份集群，备份集群往往规划在不同的地理位置，以此提升存储集群数据的安全性。这种架构具备了异地灾备的特性，对一些安全性和实时性要求较高的应用提供了解决方案。
1. Ceph 常用的备份技术及存在的问题
目前，在 Ceph 中主要是通过快照、备份技术来构建数据的备份副本，在故障时通过数据的历史副本恢复用户数据。Ceph 自身也采用了多副本冗余方式，来提升服务的可用性和数据的安全性。但这 3 种技术都存在着自身的不足。
快照与源卷存放在同一个集群，在源卷误删除场景下可以恢复，但如果遇到断电、火灾、地震等整机房级别的故障，该方案就显得无能为力。且 Ceph 快照采用的 COW 技术会影响源卷的写入性能。
备份虽然可以将数据复制到对象存储或者其他备份存储系统中，但是备份和恢复的时间可能要数分钟到十几小时，无法保证业务的连续性。
而多副本方式采用的是强一致性同步模型，所有副本都必须完成写入操作才算一次用户数据 I/O 写入成功，这导致了 Ceph 存储集群在跨域部署时性能表现欠佳，因为如果副本在异地，网络时延就会增大，拖垮整个集群的 I/O 写入性能。生产实践中，Ceph 存储集群不建议跨地域部署。
对数据安全性和业务连续性要求高的场景，需要存储系统支持异地容灾功能。异地容灾需要具备以下两大特性。
（1）备用站点和主站点规模一致，且分布在不同区域，具有一定的安全距离。
（2）备用站点和主站点数据一致，可以在短时间内进行故障切换，对业务影响小。Ceph 的 rbd-mirror 新特性具备以下特点，可以较好地满足上面的要求。
◆ 维护主卷和备份卷的崩溃一致性；
◆ 备份集群的数据能随主集群更新而更新；
◆ 支持故障切换。
2. rbd-mirror 原理
rbd-mirror 有两种同步方式：Event 模式和 Image 模式。
Event 模式是常用方式，Event 方式借助 RBD 的 journaling 特性，rbd-mirror 进程负责监控远程伙伴集群的 Image Journal 缓冲区，并重回放日志事件到本地，这种方式和MySQL 的主从同步原理较为类似。RBD Image Journaling 特性会顺序记录发生的修改事件，可以保证 image 和备份卷之间数据的崩溃一致性。
远程异步复制需要额外部署 rbd-mirror 进程服务，根据备份方式的不同，rbd-mirror进程可以在单个集群上或者互为主备的两个集群上运行。
◆ 单向备份，当数据从主集群备份到备用集群的时候，rbd-mirror 进程仅在备份群集上运行，如图 3-7 所示。
◆ 双向备份，如果两个集群互为备份的时候，rbd-mirror 进程需要在两个集群上都运行。
图 3-7 rbd-mirror 进程在数据中心的部署位置（单向备份）
当 RBD Journal 功能打开后，所有的数据更新请求会先写入 RBD Journal 缓冲区，然后后台线程再把数据从 Journal 缓冲区刷新到对应的 Image 区域。RBD Journal 提供了比较完整的日志记录、读取、变更通知以及日志回收和空间释放等功能，可以认为是一个分布式的日志系统。rbd-mirror 的工作原理见图 3-8。
图 3-8 rbd-mirror 的工作原理
3. rbd-mirror 使用方法
目前 Ceph 支持两种模式的异步复制，分别为 Pool 模式和 Image 模式：
◆ Pool 模式，如果配置为 Pool 模式，那么存储池中所有 RBD 卷都会备份到远端集群；
◆ Image 模式，如果配置为 Image 模式，表示只会对特定的某些卷开启异步复制功能。
rbd-mirror 进程可以部署在独立的节点上，也可以和存储集群混合部署。独立部署时，需要确保该节点和两个存储集群的业务网（Public 网段）畅通，且带宽要足够大，以免成为数据同步的性能瓶颈。
rbd-mirror 配置步骤主要分为以下几步。
（1）处理 Ceph 配置文件和 keyring ；
（2）设置备份模式：Image 或 Pool 模式；
（3）两个集群的同名 Pool 进行 Peer 配对；
（4）在主集群中创建带有 Journaling 属性的 RBD 卷；
（5）如果为 Image 备份模式，对该卷进行 rbd-mirror enable 设置；
（6）开启 rbd-mirror 进程。如果是双向备份，两个集群都需要启动该进程。
备 份 的 RBD Image 存 在 两 种 状 态：primary 和 non-primary。Image 只 有 处 在primary 状态才能进行读写操作和属性更改，要想对备份卷进行读写操作和属性更改时，需要进行主备切换，使备份卷变成主卷才能操作。当第一次对 RBD 镜像进行异步复制时，
Image 会自动晋升为 primary。
rbd-mirror 在备份集群选择存储池规则如下。
◆ 如果目标群集已配置了默认存储池（参照 rbd_default_data_pool 配置选项），则将使用它。
◆ 如果源镜像使用单独的存储池，并且目标集群上存在具有相同名称的池，则将使用该池。
◆ 如果以上两个都不成立，则不会使用任何存储池。
4. 卷的 Promotion 和 Demotion
在一些场景下，如主集群性能差、磁盘故障、机房维护等，需要对主备集群进行故障切换，primary 级别的 RBD 镜像需要切换到备份的 Ceph 集群，并停止所有的访问请求。切换流程如下。
（1）查看数据的同步完成情况，确保数据已同步完成；
（2）将 primary 级别的 Image 降级为 non-primary，可以针对单个卷，也可以对整个Pool ；
（3）将备份集群中对应的非主 Image 提升为 primary。
当降级无法传播到对等 Ceph 群集时（例如，Ceph 群集故障，通信中断），需要使用 --force 选项强制升级。
rbd-mirror 仅提供了便于镜像有序迁移的工具，由于采用异步复制策略，无法实现双活，无法实现故障的自动切换，还需要外部机制来协调整个故障转移过程。
5. 脑裂处理
在主备切换时，如果强制使用 --force 选项升级，或者因操作不当，系统中出现两个primary 时，会导致两个对等方之间出现脑裂情况，并且在发出强制重新同步命令之前，逻辑卷将不再处于同步状态。
一旦同步出现脑裂情况，rbd-mirror 将停止同步操作，此时必须手动决定哪边的 Image是权威的，然后通过手动执行 rbd-mirror image resync 命令恢复同步。因为要人为选择一边作为 primary，所以存在一定的数据丢失的风险。
6. 目前存在的问题和展望
rbd-mirror 存在如下两个问题。
（1）性能问题
当 RBD Journal 属性打开后，所有的数据会先写到 Journal，造成了双写，导致性能大幅下降。通过测试，性能下降幅度会超过 40%。虽然使用独立的 SSD Pool 存放 RBD Journal 可以提升性能，但是经实测，作用有限，性能问题是很多人对 rbd-mirror 有所顾忌的最大因素。
（2）部署和维护复杂
目前 rbd-mirror 进程需要独立部署和配置，配置步骤多，运维操作复杂，自带的管理平台使用起来不友好，还需进一步提升。
针对 Journal 模式存在的性能大幅下降问题，Ceph 在 O 版推出了基于 snapshot 模式的卷的异步复制，此模式使用定期计划或手动创建 RBD 快照，然后基于快照将主集群的数据异步复制到备份集群的策略。借助 RBD 的 fast-diff 功能，无须扫描整个 RBD 卷即可快速确定更新的数据块。备份集群根据两边快照之间的数据或元数据差异，将增量数据快速同步到本地。该模式目前刚推出，使用的较少，后续还要在使用中不断完善。
