带你读《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD(三)-阿里云开发者社区

开发者社区> 人民邮电出版社> 正文
登录阅读全文

带你读《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD(三)

简介: 带你读《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD

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进程需要在两个集群上都运行。

 

 image.png

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

 

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

image.png

图 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卷即可快速确定更新的数据块。备份集群根据两边快照之间的数据或元数据差异,将增量数据快速同步到本地。该模式目前刚推出,使用的较少,后续还要在使用中不断完善。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: