看了一篇ceph性能优化的文章，其中对HDD和ceph的性能进行了比较，对FileStore的写操作进行了耗时分析，并提出了针对journal和osd都放在同一磁盘场景的优化策略。
1.背景
1.块存储在IaaS占有重要地位，通常用来存储虚拟机的images，在虚机关机后提供持久的存储服务。Ceph作为openStack常用的存储后端，将块设备转化成大小相同的objects，并保存在本地文件系统。Ceph提供的块设备性能在很多场景下都是普通硬盘的30%，通常认为是三副本造成了性能的下降，但该研究发现，副本策略并不是性能下降的真实原因。 该文优化了ceph的存储引擎，提供了比普通硬盘更快的IO性能。
2.分布式存储系统如Amazon的S3提供了更廉价的存储服务，$0.023/per GB，但是write throughput只有33MB/s，远远低于硬盘的150MB/s。
存储引擎分析
1.Ceph rbd广泛用于云计算平台的存储后端，但是其性能却不够理想。主要原因是ceph的objects存储在上层的文件系统而非本地磁盘，因此，优化策略是减少本地文件系统的存储。
2.该文的三个重点：
（1）通过分析写操作，发现副本策略并不是IO慢于硬盘的real reason
（2）Ceph通过使用journal方法保证系统的可靠性，但是这个是一个不重要的操作（why？需要阐述），并征明了为什么journal对于block 接口是meaningless。
（3）该文团队开发了一个nojournal-block 属性的Ceph引擎（架构是怎样的？），实现了2倍的性能提升。
3.对于存储引擎的简要回顾
Sheepdog是为QEMU/KVM和iSCSI提供存储服务的分布式存储系统。
GlusterFS是一个scalable NFS，通过整合QEMU来提供块级存储能力。
但是以上两种都缺乏灵活性，并且，对于块设备的优化有限。与之相比，Ceph尤其在块接口方面有更优的性能和可扩展性，使得其成为使用广泛的存储后端。有许多单参数可以影响其性能，比如caching size，recovery settings，journal settings 或者logging【2】。Wang et al. 【3】在HPC环境测试了Ceph的性能，发现Ceph在object level可以达到接近原始硬件（硬盘）70%的带宽，在file system可以达到62%。他们还指出，Ceph的元数据加数据日志设计是其一个弱点。The performance of ceph block devices only can reach 13 of original hard disks used by OSD.（怎么得到的13，文中未有阐述）
motivation（为什么有必要做rbd的优化？）根据2015年openstack summit的统计，62%的openstack平台用ceph做存储后端，ceph rbd服务对于使用qemu-rbd的VM来说是十分重要的。但是，qemu-rbd并不能达到与硬盘相当的性能。
下图比较了FileStore-rbd，BlueStore-rbd，local-hdd随机读写，顺序读写的IOPS
HDD和rbd的iops比较
（1）除了随机读，rbd的整体性能低于hdd
（2）读和小块的顺序写性能bluestore略微低于filestore，随机写性能高于filestore
（3）整体来讲，在qemu-rbd场景下，filestore低于bluestore
4.分析ceph的设计
Filestore需要记录每个object的写操作的states和data，因此，会产生大量的磁盘操作，造成性能下降，尤其是在journal和osd在同一块盘的情况下（默认配置）。osd和journal在一块盘上，original request写两次，吞吐量减少到磁盘带宽的一半，并且object的写操作和journal的写操作混合，增加了磁盘查找。
写操作耗时分析
（1）clients需要选择一个池为rbd image申请空间（1G的数据会被分割成255个object）
（2）所有rbd data objects有同样的名字前缀
（3）根据crush规则找到对应的osd，写journal和object data
5.优化点
保留metadata的journal操作，对于object data，跳过其journal操作，直接写盘。
这样的优化可能带来的疑问：会否影响写操作的原子性和可靠性？
FileStore的写操作是通过事务完成的，写的原子性通过journal来保障，意味着，写事务的joural操作一旦成功，数据会被持久化到块设备，对object file的修改通过journal可以安全回退，否则，写操作被认为是失败的。因此，写操作的更新要么成功，要么失败，没有中间态。但是这种原子性是对象粒度的，这也就意味着，如果一个写操作包含更多的objects时，FileStore不能保证所有相关的objects都被更新。数据可靠性方面，ceph cluster对每个object采用三副本保存，这样，每个对象都可以从副本中恢复。
但是在一些场景中，不需要保存这些meaningless的操作，比如，rbd，仅仅梯控类似硬盘的块存储接口，是具有天生的原子性：应用写一个block（就像写一个扇区），要么写all，要么nothing，没有中间态，因此，块设备不需要journal来支持原子性。另外一方面，如果数据写一个object文件并立刻同步，数据丢失最多一个object（默认4M），并且概率很小，而副本策略可以增强可靠性来保证数据一致。因此，该文的优化在一些场景（rbd）中并没有影响写操作的原子性和可靠性。
6.评估
The Ceph version is 10.1.1
6 physical hosts (12个osd，每个host可以有2个osd，1个作为hdd测试用)
-2个 6-core 1.87GHz Intel Xeon CPUs
-256GB RAM
-10Gigabit Ethernet
-3 hard disks （3TB 7.2K RPM）【分析：这种硬盘应该<1000MB/s】
Ubuntu 14.04 x86 64 server with the Linux kernel 3.13
3副本+128PG（PG数与卷数据相同）
HDD和优化之后rbd的iops比较
HDD和优化之后rbd的throughout比较
测试方法：
Fio 2.1.3
-direct=1 -iodepth=1 -ioengine=psync
-bs：I/O request size of Fio is configured by parameter “-bs” that ranges from 4 KB to 4MB
虚机的IO mode 设置为writethrough，尽可能减少系统cache的影响
dirty background ratio 设为0用来保证，系统进程的脏数据尽可能地刷到磁盘
==================================================================
插楼：关于磁盘性能指标iops和throught
常见磁盘平均物理寻道时间为：
7200转/分的STAT硬盘平均物理寻道时间是9ms
10000转/分的STAT硬盘平均物理寻道时间是6ms
15000转/分的SAS硬盘平均物理寻道时间是4ms
常见硬盘的旋转延迟时间为：
7200 rpm的磁盘平均旋转延迟大约为60*1000/7200/2 = 4.17ms
10000 rpm的磁盘平均旋转延迟大约为60*1000/10000/2 = 3ms，
15000 rpm的磁盘其平均旋转延迟约为60*1000/15000/2 = 2ms。
最大IOPS的理论计算方法:IOPS = 1000 ms/ (寻道时间 + 旋转延迟)。可以忽略数据传输时间。
7200 rpm的磁盘IOPS = 1000 / (9 + 4.17) = 76 IOPS
10000 rpm的磁盘IOPS = 1000 / (6+ 3) = 111 IOPS
15000 rpm的磁盘IOPS = 1000 / (4 + 2) = 166 IOPS
已知该文用的是7200RPM的磁盘，理论上iops为76，以2M数据来看，吞吐量为2M*76=152MB/s，和上图是差不多的，该数据比较可信。
==================================================================
该优化为什么会有这么多的提升？
（1）去掉了rbd data的journal操作，减少了写操作中大量的journal操作
（2）使得磁盘有更多的顺序写
（3）因为每个osd对于大部分objects来说都是primary osd，因此增加大部分写的并发性，从而提高了osd的速度。
但是对于小于1M数据的顺序读，rbd性能还是要小于hdd，这是因为，小于1M的顺序读可以利用磁盘的local cache，有很高的命中率，但是对于rbd来说，它的read request随机分布在各个osd。增加osd的数量可以减少这一差异，数据大于1M后，磁盘cache打满，达到瓶颈，吞吐量不再上升，165MB/s，但是rbd可以持续增长，因为read request是全部osd并行支持的，osd磁盘的瓶颈没有那么快达到。
对于随机读来说，local hdd产生了很多磁盘寻道时间，尽管rbd也需要磁盘寻道，但是是osd并行进行的，自然要快的多。
思考：
FileStore与BlueStore的比较中说明在SSD-based的ceph cluster，FileStore绝对碾压的优势，而在HDD-based的ceph cluster，BlueStore的时延优势使其在时延敏感场景（云硬盘，主要是块存储）有绝对优势。可见BlueStore在小的顺序读写，随机读写优势不明显，而针对与本文的比较，本文针对FileStore的优化是去掉了rbd data的journal写操作，只保留元数据的journal，就已经带来了较大的IO性能提升，那么BlueStore已经直接写裸盘了，为何没有很高的性能提升呢？
ceph后端存储引擎该文中介绍的BlueStore中可知，在其架构设计上，HDD（<64KB）,SSD（<16KB）的数据依旧存在双写，要先写入rockdb，再持久化到磁盘。那么如果在HDD based 的ceph cluster集群，把这个minimum allocation size设置成0，岂不是达到了和本文优化一样的效果？可是这样的话，就失去了从数据库中读数据的优势，时延的优势会下降。
将本文针对FileStore跳过journal步骤，在BlueStore适合使用的场景，并不适用，会得到更好的IO性能，却会失去时延的优势。而对FileStore本身的优化是否有必要呢？如果是时延敏感场景，那么直接选用BlueStore，甚至FileStore直接上全闪，不需要优化，因为SSD本身没有HDD的瓶颈（不需要寻道时间）。那么针对对象存储场景呢？已知对象存储大都是HDD based场景，而journal无论是单独给一个SSD放置，还是HDD划一个分区放置，性能差异都不大，可见磁盘还是瓶颈，那可以应用本文跳过data跳过journal的步骤么？本文针对场景是rbd，已论证这样的操作不会破坏原子性和可靠性，如果应用在对象存储，需要论证（或咨询或查阅）。不过我觉得对象存储中metadata的journal保留下来，三副本策略，数据应该不会丢，就看对象存储中写操作是否具有原子性了。【4】中也有人提到，“非常大或者对象存储的工作场景下，跳过 FileJournal 直接落盘是用户期待的方式，因此社区会重起一个新的 Backend 来解决这些问题。 ”BlueStore已经到来，就看更差的时延对象存储场景是否能够接收，如果可以，不需要像本文一样针对FileStore跳过journa，直接修改配置(64KB->0，即全部落盘)即可，是这样的么？
参考
【1】A New Approach to Double I/O performance for Ceph Distributed File System in Cloud Computing 【2019 IEEE】
【2】S. Meyer and J. P. Morrison, “Impact of single parameter changes on ceph cloud storage performance,” Scalable Computing: Practice and Experience, vol. 17, no. 4, pp. 285–298, 2016.
【3】F. Wang, N. Mark, O. Sarp, A. Scott, W. Sage, W. S. Bradley, C. Blake, and H. Jason, “Performance and scalability evaluation of the ceph parallel file system,” in Proceedings of the ACM 8th Parallel Data Storage Workshop, 2013.
网友评论