CN110442646A - 一种ceph数据同步模块主端写性能优化系统及方法 - Google Patents

Abstract

一种ceph数据同步模块主端写性能优化系统及方法，通过在rbd journal落盘和数据落盘之间增加一层内存cache，在rbd journal落盘后先将数据写入cache而不是直接数据落盘，等到业务不忙时再从cache回刷到磁盘。这样即使在数据没有落盘之前，上层应用也可以从cache读到新写入的数据，不会读到旧的数据。之前两次落盘就变成了一次落盘和一次写内存cache，因为写内存的速度要远远快于写磁盘的速度，一次IO写的延迟只增加写内存的时间，因此写性能也可以从下降50%以上提高到只下降10%左右。

Description

一种ceph数据同步模块主端写性能优化系统及方法

技术领域

本发明属于分布式存储领域，涉及在开源分布式存储系统ceph中数据同步模块rbd mirror主端写性能优化。

背景技术

云存储是由云计算概念延伸发展出来的一个新兴的概念，它指通过集群应用、网络技术或分布式文件系统等网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作共同对外提供数据存储和业务访问功能的一个系统，保证数据的安全性和高扩展性。

rbd mirror是分布式存储软件ceph的rbd块存储数据同步模块，rbd mirror实现了两个以及多个ceph集群之间数据的准实时同步，成为ceph实现多数据中心灾备的存储基础。rbd mirror的实现原理如下：

1、第一次打开rbd mirror同步时，对主端的rbd做一个快照，rbd mirror进程通过主端的快照从主端同步数据到备端恢复出一个备份的rbd；

2、之后主端写入数据时，先追加写入rbd journal，在rbd journal落盘后一方面在主端完成数据落盘，另一方面通知rbd mirror进程同步数据到备端回放。

rbd journal是ceph在librbd中实现的一种类似于数据库write-ahead-log的技术。rbd mirror进程读取rbd journal在备端回放从而实现数据的同步；另外主端也可以在异常场景下从rbd journal回放数据实现数据修复，比如在数据落盘前节点掉电。

考虑到存储集群在写数据时，集群可能发生多种异常情况，为了保证rbd journal数据的安全性，rbd journal也需要和其他数据一样保存在ceph集群中直到主备两端数据都落盘成功才能够删除。

从主端考虑，为了保证数据的一致性，rbd journal落盘和数据落盘必然需要是一个串行的过程，以保证只有rbd journal落盘成功后数据才开始落盘，如果在数据落盘的过程中集群掉电，就可以通过完整的rbd journal回放来修复未完成落盘的数据。

rbd mirror和rbd journal的结合使用完成了多个ceph集群之间数据准实时同步，并且很好的保证了数据的安全性。但是同时引入了主端写数据性能下降的问题，由于主端写数据时需要先写rbd journal再数据落盘并且是一个串行的过程，所以相比于之前现在一个IO需要两次落盘，延迟增加了一倍，导致主端集群性能下降50%以上。

发明内容

本发明针对现有技术中的不足，提供一种ceph数据同步模块主端写性能优化系统及方法，为ceph集群在rbd mirror同步打开后主端集群写性能提供一个优化方案。

ceph集群打开rbd mirror同步需要在主端打开rbd journal特性，主端一次IO需要两次落盘，导致主端集群性能下降50%以上。本发明通过在rbd journal落盘和数据落盘之间增加一层内存cache，在rbd journal落盘后先将数据写入cache而不是直接数据落盘，等到业务不忙时在从cache回刷到磁盘。这样即使在数据没有落盘之前，上层应用也可以从cache读到新写入的数据，不会读到旧的数据。

之前两次落盘就变成了一次落盘和一次写内存cache，因为写内存的速度要远远快于写磁盘的速度，一次IO写的延迟只增加写内存的时间，因此写性能也可以从下降50%以上提高到只下降10%左右。

为实现上述目的，本发明采用以下技术方案：

一种ceph数据同步模块主端写性能优化系统，其特征在于，包括：客户端和ceph集群，所述客户端包括虚拟机和Librbd块存储库，其中Librbd块存储库包括rbd日志和内存，所述ceph集群包括日志池和数据池；所述虚拟机生成写IO请求并发送至rbd日志；所述rbd日志用于将写IO请求包装成事件并通过网络落盘到日志池中，以及将写IO请求发送到内存中；所述日志池在事件落盘后生成回执并通过网络返回到rbd日志；所述内存用于将rbd日志发送过来的写IO请求通过网络落盘到数据池中；所述数据池在写IO请求落盘后生成回执并通过网络返回到内存。

为优化上述技术方案，采取的具体措施还包括：

进一步地，还包括共享内存，所述共享内存用于监控单个节点的所有Librbd块存储库使用内存情况，每个节点包括一个或多个客户端。

进一步地，所述日志池采用SSD。

同时，本发明还提出了一种如上所述的ceph数据同步模块主端写性能优化系统的优化方法，其特征在于，包括：

步骤1：虚拟机中的业务生成写IO请求并发送至rbd日志；

步骤2：rbd日志将写IO请求包装成事件并通过网络落盘到日志池中；

步骤3：日志池在事件落盘后生成回执并通过网络返回到rbd日志；

步骤4：rbd日志在接收到日志池的回执后，将写IO请求发送到内存中，写完内存后，返回虚拟机写IO请求完成；

步骤5：判断业务请求是否繁忙：当业务请求繁忙时，内存中的写IO请求先不落盘到数据池；当业务请求不繁忙时，内存将写IO请求通过网络落盘到数据池中；其中，若内存使用达到阈值，则忽略业务繁忙，强制内存将写IO请求通过网络落盘到数据池中；

步骤6：数据池在写IO请求落盘后生成回执并通过网络返回到内存；

步骤7：在内存接收到数据池的回执后，删除日志池中保存的事件。

进一步地，步骤2中，rbd日志针对写IO请求生成元数据，将元数据增加到写IO请求中并一同包装成事件。

进一步地，步骤2中，元数据包括类型、offset、length。

进一步地，步骤2中，rbd日志将事件变成4K对齐再写入日志池。

进一步地，步骤5中，共享内存监控每个节点的所有Librbd块存储库使用内存情况，当内存使用超过设置的阈值时，强制内存将写IO请求通过网络落盘到数据池中。

进一步地，在步骤5的内存将写IO请求落盘到数据池中之前，若用户发起了对写IO请求的读请求，则直接读取内存里的写IO请求并返回。

进一步地，在步骤5的内存将写IO请求落盘到数据池中之前，若节点或者ceph集群发生了掉电，系统重新启动时从rbd日志中回放事件并重新落盘到日志池。

本发明的有益效果是：本发明使用后，ceph集群打开rbd mirror时主端的写性能由原来的下降50%以上优化到下降10%左右，极大的提高了主端集群的写性能，并且不需要担心引入的内存cache会消耗完节点内存容量引发问题。

附图说明

图1是ceph数据同步模块主端写性能优化系统的框架图。

图2是共享内存监控单个节点所有rbd使用内存情况的示意图。

具体实施方式

现在结合附图对本发明作进一步详细的说明。

一种ceph数据同步模块主端写性能优化系统及方法，具体实施方式如下：

1、增加SSD做journal-pool（日志池）

从最上层来分析，一次写入请求需要两次数据落盘rbd journal（rbd日志）和data（即写IO数据）落盘才能完成，最直观的方法就是添加SSD。只有物理上面增加了ceph集群固有的IO能力，才有可能抵消两次写入对整体集群造成的性能影响。

2、异步data落盘

即使有了SSD的方案，可以在极限IOPS上面达到关闭Journal的水平，但是只是增大了集群的极限场景下的IOPS，对于单个IO的latency并没有缩小。增加了SSD之后还是不能满足要求，所以需要降低latency。在IO分析过程中，一次写入IO需要两次数据落盘，方案修改为写入journal后写内存cache返回，在业务不繁忙时再从cache回刷落盘，这里引入cache的原因是为了解决读请求响应的问题。

这样一次IO latency的时间就可以由两次落盘的时间优化为一次落盘和一次写内存，因为写内存的速度远远大于写磁盘，所以IO latency缩小了。

3、对齐优化

通过方案1和2在架构上来分析应该已经和不打开Journal的IO路径差不多，但是还有一个小细节需要考虑：IO路径相似，但是IO大小不同。对于data数据的写入，只需要将VM（虚拟机）请求的数据存储就可以，但是对于journal我们需要加入一个journal event的header，里面记录着这个event（事件）的各种元数据，包括类型，offset，length等等。所以需要引入对齐方案，让增加了journal元数据的event变成4K对齐再写入journal pool。

4、回刷策略

多线程的场景下，client和flusher同时通过ImageCtx进行objectrequest的发送，会造成资源竞争从而影响性能。所以需要引入回刷策略，当业务请求繁忙时先不进行cache数据的回刷从而保业务优先。

5、全局cache限制

因为每一个虚拟机或者云盘都分配了一个cache，这样就会面临一个问题，在不能预测每一个node（节点）上面的image（镜像）使用数量情况下无法准确判断配置每一个image的cache大小。所以引入全局cache限制的方案，当一个节点上所有image使用的cache大小大于设置值时，强制cache开始回刷，以防cache太大耗尽节点内存。

如图1所示，当用户（或其它结构、进程等）需要写时产生写IO请求，rbd journal会对这个写IO请求增加元数据，之后会落盘到ceph集群的journal-pool中；在rbd journal落盘后，将写IO请求的数据写入到内存cache中，之后通知用户客户端IO完成；同时通知rbdmirror进程读取rbd journal在备端回放数据。

数据写入到cache后不是直接回刷到ceph集群的data pool中，而是先判断现在业务请求是否繁忙（由IO数量决定，如默认8个及以上为繁忙，以下为空闲），如果繁忙就先不回刷而是等到业务空闲时回刷。如果数据还没有回刷时，用户发起了这部分数据的读请求，这时就会读到cache里的数据并返回。如果在数据还没有回刷时，节点或者ceph集群发生了掉电，重新启动时就会从rbd journal中回放数据重新落盘，以保证数据在异常场景下的安全性和一致性。

如图2所示，在每一个节点上使用共享内存（global cache）监控单个节点所有rbd使用内存cache情况，当内存使用超过设置的阈值时，就忽略业务繁忙而强制cache回刷数据到data-pool中，以保证内存cache使用容量在允许范围内。

需要注意的是，发明中所引用的如“上”、“下”、“左”、“右”、“前”、“后”等的用语，亦仅为便于叙述的明了，而非用以限定本发明可实施的范围，其相对关系的改变或调整，在无实质变更技术内容下，当亦视为本发明可实施的范畴。

以上仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，应视为本发明的保护范围。

Claims (10)

1.一种ceph数据同步模块主端写性能优化系统，其特征在于，包括：客户端和ceph集群，所述客户端包括虚拟机和Librbd块存储库，其中Librbd块存储库包括rbd日志和内存，所述ceph集群包括日志池和数据池；所述虚拟机生成写IO请求并发送至rbd日志；所述rbd日志用于将写IO请求包装成事件并通过网络落盘到日志池中，以及将写IO请求发送到内存中；所述日志池在事件落盘后生成回执并通过网络返回到rbd日志；所述内存用于将rbd日志发送过来的写IO请求通过网络落盘到数据池中；所述数据池在写IO请求落盘后生成回执并通过网络返回到内存。

2.一种如权利要求1所述的ceph数据同步模块主端写性能优化系统，其特征在于：还包括共享内存，所述共享内存用于监控单个节点的所有Librbd块存储库使用内存情况，每个节点包括一个或多个客户端。

3.一种如权利要求2所述的ceph数据同步模块主端写性能优化系统，其特征在于：所述日志池采用SSD。

4.一种如权利要求2或3所述的ceph数据同步模块主端写性能优化系统的优化方法，其特征在于，包括：

步骤1：虚拟机中的业务生成写IO请求并发送至rbd日志；

步骤2：rbd日志将写IO请求包装成事件并通过网络落盘到日志池中；

步骤3：日志池在事件落盘后生成回执并通过网络返回到rbd日志；

步骤4：rbd日志在接收到日志池的回执后，将写IO请求发送到内存中，写完内存后，返回虚拟机写IO请求完成；

步骤5：判断业务请求是否繁忙：当业务请求繁忙时，内存中的写IO请求先不落盘到数据池；当业务请求不繁忙时，内存将写IO请求通过网络落盘到数据池中；其中，若内存使用达到阈值，则忽略业务繁忙，强制内存将写IO请求通过网络落盘到数据池中；

步骤6：数据池在写IO请求落盘后生成回执并通过网络返回到内存；

步骤7：在内存接收到数据池的回执后，删除日志池中保存的事件。

5.如权利要求4所述的优化方法，其特征在于：步骤2中，rbd日志针对写IO请求生成元数据，将元数据增加到写IO请求中并一同包装成事件。

6.如权利要求5所述的优化方法，其特征在于：步骤2中，元数据包括类型、offset、length。

7.如权利要求5所述的优化方法，其特征在于：步骤2中，rbd日志将事件变成4K对齐再写入日志池。

8.如权利要求4所述的优化方法，其特征在于：步骤5中，共享内存监控每个节点的所有Librbd块存储库使用内存情况，当内存使用超过设置的阈值时，强制内存将写IO请求通过网络落盘到数据池中。

9.如权利要求4所述的优化方法，其特征在于：在步骤5的内存将写IO请求落盘到数据池中之前，若用户发起了对写IO请求的读请求，则直接读取内存里的写IO请求并返回。

10.如权利要求4所述的优化方法，其特征在于：在步骤5的内存将写IO请求落盘到数据池中之前，若节点或者ceph集群发生了掉电，系统重新启动时从rbd日志中回放事件并重新落盘到日志池。