3.1.1    远程复制

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进程负责监控远程伙伴集群的 ImageJournal 缓冲区，并重回放日志事件到本地，这种方式和MySQL 的主从同步原理较为类似。RBDImageJournaling 特性会顺序记录发生的修改事件，可以保证 image和备份卷之间数据的崩溃一致性。

远程异步复制需要额外部署 rbd-mirror 进程服务，根据备份方式的不同，rbd-mirror进程可以在单个集群上或者互为主备的两个集群上运行。

◆  单向备份，当数据从主集群备份到备用集群的时候，rbd-mirror进程仅在备份群集上运行，如图 3-7所示。

◆  双向备份，如果两个集群互为备份的时候，rbd-mirror进程需要在两个集群上都运行。

 

 

图 3-7rbd-mrror进程在数据中、的部署位置(单向备份)

 

当 RBDJournal 功能打开后，所有的数据更新请求会先写入 RBDJournal缓冲区，然后后台线程再把数据从 Journal缓冲区刷新到对应的 Image区域。RBDJournal提供了比较完整的日志记录、读取、变更通知以及日志回收和空间释放等功能，可以认为是一个分布式的日志系统。rbd-mirror的工作原理见图 3-8。

图 3-8rbd-mrror的工作原理

 

具体步骤如下。

（1） I/O 会写入主集群的 ImageJournal 缓冲区；

 

（2）  Journal 缓冲区写入成功后，回复客户端响应，然后写到主集群的RBD卷中；

（3）  备份集群的rbd-mirror进程发现主集群的Journal缓冲区有更新后，从主集群的Journal缓冲区读取数据，写入备份集群；

（4）  备份集群写入成功后，会更新主集群 Journal 缓冲区中的元数据，表示该 I/O的Journal缓冲区数据已经同步完成；

（5）  主集群会定期或根据容量阈值检查，删除已经写入备份集群Journal缓冲区的数据。RBDJournal缓冲区默认和卷存储在同一个 Pool中，也可以存放在不同的 Pool中。

例如将 Journal缓冲区存放在由SSD组成的 Pool中， 一方面避免占用数据池的 I/O资源，另一方面，使用 SSD提升了 RBDJournal的性能，可以全面提升写入性能。也可以将 Journal缓冲区存放在 ECPool 中，来节省空间，JournalPool和后端数据 Pool没有大小和存储策略的一致性要求。JournalPool 中除了存放数据，还需要记录一些元数据信息，包括：

pool_id：Journal数据存放的 Pool；

journal_object_prefix：JournalPool 中对象存放时加的前缀；positions：（区域、对象数、偏移）按区域索引的元组；object_size：每个对象的大小；

object_num_begin：当前 Journal中，最小的对象编号，即下一个读取的Object；object_num_end：当前 Journal中，最大的对象编号。

Image方式则通过 syncpoint来实现，它主要用在存量卷的异步复制上。在每次同步的时候做一个 snapshot，作为 syncpoint，然后进行数据复制。由于存量卷没有完整的Journal来进行 replay，比如将一个使用了很久的 Image加入到 mirroring里面，就必须使用syncpoint的方式来进行 Image同步。使用 Image 模式时，同步完成后，后台自动创建的 snapshot也会自动删除。

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-mirrorenable设置；

（6）  开启 rbd-mirror进程。如果是双向备份，两个集群都需要启动该进程。

备 份 的 RBDImage存 在 两 种 状 态：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-mirrorimageresync 命令恢复同步。因为要人为选择一边作为 primary，所以存在一定的数据丢失的风险。

6.  目前存在的问题和展望

 

rbd-mirror 存在如下两个问题。

（1）性能问题

当 RBDJournal属性打开后，所有的数据会先写到 Journal，造成了双写，导致性能大幅下降。通过测试，性能下降幅度会超过 40%。虽然使用独立的 SSDPool存放 RBDJournal可以提升性能，但是经实测，作用有限，性能问题是很多人对rbd-mirror有所顾忌的最大因素。

（2）部署和维护复杂

目前rbd-mirror进程需要独立部署和配置，配置步骤多，运维操作复杂，自带的管理平台使用起来不友好，还需进一步提升。

针对 Journal 模式存在的性能大幅下降问题，Ceph在 O版推出了基于 snapshot模式的卷的异步复制，此模式使用定期计划或手动创建 RBD 快照，然后基于快照将主集群的数据异步复制到备份集群的策略。借助 RBD的 fast-diff功能，无须扫描整个RBD卷即可快速确定更新的数据块。备份集群根据两边快照之间的数据或元数据差异，将增量数据快速同步到本地。该模式目前刚推出，使用的较少，后续还要在使用中不断完善。