影响性能的关键部分-ceph的osd journal写

Posted 2020-10-11 多看多学多记多实践

在前面一篇文章中，我们看到，当使用filestore时，osd会把磁盘分成data和journal两部分。这主要是为了支持object的transaction操作。我的想法是，ceph需要具有数据保护功能，从client端写入的数据（以返回I/O Completion为标志）不能丢失。对于object为什么要使用journal，ceph官方也给出了解释：

• 速度：有了journal分区后，写数据速度更快。这主要是因为journal的写都是顺序写。

• 一致性：ceph要求I/O操作是原子性的，比如更新PG的元数据。

当然，有些人对此提出异议，因为以这种journal方式保持数据一致性的做法ext4也能干，为什么还要自己单独整一个？正好这个问题opennebula有一个讨论，正方的理由是ceph需要自己管理transaction，依赖文件系统没有办法独立自主，而且文件系统层面无法把ceph的数据和其元数据关联起来。

回到正题，我们先来看看一个I/O写是如何处理的，引用ceph.com一篇文章的说法（具体网址在参考资料处）：

大致的过程是先写primary osd的journal部分，使用libaio的DIO，然后使用writev向filesystem发起buffer-io。每隔一段时间fsync把buffer-io落盘。整个过程跟文件系统的journal处理方式类似。Replicated部分也是按照这个流程走。下面这个图更直观地描述了osd对I/O的处理。

不过上面并没有指出osd什么时候返回I/O Completion，根据代码分析，osd会在写完journal后完成本次的I/O操作（Replicated 部分也一样）。最后的落盘会有其他的线程来处理。

下面用一个例子来描述journal写的部分细节。

我们操作的osd所在的盘被按照如下方式配置

在client进行写操作时，可以看到这个osd上有3个线程在进行I/O，其中有两个是实际的落盘操作，1个是journal写。

进一步通过blktrace看看这个journal写，如果下发10个随机写I/O（4KB），则对应的有10个journal写。这10个写都是16个sector，即8KB。那么可以推断，多出来的4KB是journal的元数据。并且，这10个I/O都是按照LBA顺序写入。

通过对journal线程的分析，可以发现写请求都是通过io_submit发出的，说明使用的是AIO，并且类型是pwritev。

这在ceph的配置文件中也能看到：

从代码看，ceph直接使用libaio提供的API函数io_submit。

对比osd端和client端的I/O操作

client端在0.0135s处就完成了所有的写操作，而physical端这时候只完成了所有的journal操作，那么可以推断，写操作只是当journal完成后就立即返回给client：原因是physical端journal写之外的操作在0.56s才开始，这已经跟第一个写完成相隔50多ms。

从代码上看，当osd收到写请求后，会先进行journal transaction然后将实际的I/O queue起来。

不同的client i/o blocksize产生的日志写

blocksize为16KB 时=> 16KB+4KB

blocksize为32KB时=> 32KB+4KB

blocksize为64KB时=> 4KB+64KB+4KB

blocksize为128KB时=> 4KB+128KB+4KB

可以推断当bs<=32KB时，4KB日志与data放在一起，而当大于这个值后，变成2*4KB日志，并且与用户数据置于不同的vector。

从测试的数据可以看出，引入journal后，一次写：I/O至少为ReplicatedNum*2，数据量大于ReplicatedNum*2*（Blocksize+JournalMetaData）。当blocksize越大时，Overhead越小，那么可以通过在client端合并数据（比如使能rbd的cache功能）来减小overhead。

以SSD作为osd journal提升Ceph写性能

由于写入journal后I/O会立即返回，所以提高性能最简单的方法就是把journal放到SSD上。关于osd journal使用SSD的性能数据可以参考redhat和seagate的测试数据（具体来源见参考资料3）。

加入SSD后的4MB随机写带宽性能（一个DC S3700搭配4个osd），每节点大概提升2倍。

加入SSD后的4KB随机写IOPS性能（一个DC S3700搭配4个osd），每节点大概提升1.5到3倍。

总结

本文主要介绍了ceph的journal写，并通过实例说明journal带来的overhead；journal部分是用户优化的一个重点，可以将高性能的SSD作为journal的存储。不过，filestore并不是唯一选择，代表未来发展方向的Bluestore使用全新的设计能够更大地发挥SSD的性能，已经受到越来越多的关注。

说明

本文最先发布于公众号《存储技术最前线》 ，欢迎关注获取最新技术资讯！

参考资料

1，http://docs.ceph.com/docs/master/rados/configuration/journal-ref/

2，http://lists.opennebula.org/pipermail/ceph-users-ceph.com/2015-October/005479.html

3，https://www.redhat.com/en/files/resources/en-rhst-ceph-seagate-partner-tech-detail-INC0231356.pdf