Ceph读写性能估算方法

  • Post author:
  • Post category:其他



前言

最近在做Ceph性能测试相关工作,在测试初期由于没有得到理想的测试结果,因此对Ceph集群进行了优化,但是一直有个问题萦绕在我的脑海:基于当前硬件配置,这个Ceph集群的极限是多少?

由于这个问题和Ceph的配置息息相关,为了简化问题,在本文中我们只会会讨论3个变量:冗余策略(纠删码、多副本),读/写,ObjectStore。我们将会基于磁盘、网络、CPU性能来估算出一个集群的性能,除此以外的参数影响均归并到损耗系数μ这个变量。本文会分别解释写性能公式推演、读性能公式推演,并且在每个推演中加入冗余策略和ObjectStore的讨论。


ObjectStore简介

Ceph目前提供了三种存储后端:

  • FileStore
  • KStore
  • BlueStore

而KStore由于接纳程度不高,目前很少有厂商使用,因此在本文中只介绍和对比FileStore和BlueStore。


FileStore

在FileStore中,每个Ceph对象都被保存在本地文件系统中(XFS, ZFS等)。Ceph为了保证一致性,要求读写操作都是atomic的,因此会需要在Ceph内部做一次Journal,也就是说,每次客户端数据写入时,首先会采用Append-only的模式将数据写入到Journal中去,随后再执行真正的数据写入操作。然而在本地文件系统又会做一次Journal,因此就会产生Journaling of journal问题,也就是记录了2次Journal。为了提高写入性能,一般在部署Ceph集群时,会将单独划分SSD给Ceph journal。


BlueStore

为了提高Ceph的写入性能,社区开发了BlueStore这一存储后端,让数据绕开了本地文件系统直接裸盘,从而解决了Journaling of journal问题。BlueStore采用RocksDB来管理对象元数据,因此为了跑RocksDB,BlueStore内部有一个微型用户态的文件系统-BlueFS。得益于RocksDB,Ceph可以很方便的获取和枚举所有的对象。


读性能公式推演

读性能公式目前推测较为简单,无论在FileStore还是BlueStore下,均推断为 W

n

μ

W: 单块裸盘读带宽

n: OSD数量

μ:损耗系数 一般为0.7~0.8

下面注重来介绍一下写性能公式推演:我们会逐一探讨:

  • FileStore + 多副本 写性能公式推演
  • BlueStore + 多副本 写性能公式推演
  • FileStore + 纠删码 写性能公式推演
  • BlueStore + 纠删码 写性能公式推演


写性能公式推演


FileStore + 多副本

在当前情况下,我们假设Ceph集群的ObjectStore是FileStore, 并且对应的Pool的冗余策略为多副本,SSD作为一个OSD,其journal和data都放在这块SSD上。因此我们一次写入的流程可以简化成下图:数据先写到Ceph的journal上,然后再写入data中,并且在本地文件系统会再做一次journal,由于journaling of journal问题,单个OSD的WAF(写放大系数)为2。在当前冗余策略下,一个文件写入需要产生多个副本N,因此集群放大系数为2*N。

然而在写入对象时,我们写入的不单单是数据本身,在Ceph RBD的journal中,RBD写操作是变成transaction操作,transaction会包含一些元数据用于描述transaction,这些元数据也写到journal上,这就也会导致写放大。因此一次写入的WAF不仅仅需要考虑多副本、journaling of journal问题,还需要考虑transaction元数据。

韩国成均馆大学曾经对Ceph存储后端对写入放大系数的影响做过一定的研究,在其发表的《Understanding Write Behaviors of Storage Backends in Ceph Object Store》论文中,测试了在3副本+FileStore情况下,用Ceph RBD写入不同数据块与WAF的关系。从Figure 5我们可以看到,当数据写入量较大时,WAF逐渐收敛于6,符合我们上文WAF=2*N的推理;但是当写入对象很小时,WAF则会很大。

这是因为当数据量很小时,同时完成的transaction元数据量所占比重会很大,根据上图数据,我推测每次写入所产生的transaction元数据大概在5KiB左右,因此可以推断,在包含transaction元数据的情况下,WAF为:


WAF=[(X+5)*2*N]/X


  • X为写入数据块大小(KiB)

  • N为副本数

随着数据块增大,在FileStore、多副本冗余策略下WAF最终将向2N收敛。假设我们知道了一块SSD的写性能可以达到W MB/s的带宽,那么在理想情况下,我们可以很容易推断出,一个大小为n的SSD集群的写带宽能达到 W*n  MB/s。

如果考虑外部因素多带来的损耗为μ,我们最终可以推断出BlueStore+多副本情况下,写性能可以达到:

BW=[(W*n)/

WAF]*

μ


WAF=[(X+5)*2*N]/X


  • WAF为写放大系数

  • X为写入数据块大小(KiB)

  • N为副本数

  • n为OSD数量

  • μ为损耗系数 一般为0.7~0.8


BlueStore + 多副本

在当前情况下,我们假设Ceph集群的ObjectStore是BlueStore, 并且对应的Pool的冗余策略为多副本,SSD作为一个OSD,划分为2块分区,一个分区作为裸盘来写入数据,另一块做BlueFS用来跑RocksDB。 因此我们一次写入的流程可以简化成下图:数据会被直接写入到data分区(裸盘)中,而对象元数据会被写到RocksDB和RocksDB的WAL中,随后RocksDB将数据压缩后存放到磁盘中。我们不再需要在文件系统层做journal,而WAL只在覆写操作时才会用到,因此在副本数量为N的条件下,我们可以推测WAF将收敛于N。

值得注意的一点,在BlueStore中,磁盘分区会以‘bluestore_min_alloc_size’的大小分配管理,这个数值默认为64KiB。也就是说,如果我们写入<64KiB的数据,剩余的空间会被0填充,也即是Zero-filled data,然后写入磁盘,也正是这样,BlueStore的小文件随机写性能并不好。

这里同样引用《Understanding Write Behaviors of Storage Backends in Ceph Object Store》论文中针对BlueStore在三副本策略下,不同数据块写入时WAF的变化图:

可以看到,当写入数据块很小时,WAF的数值很大。灰色曲线正是做了前文所说的‘小文件随机写’,因此性能较差;覆写操作时,由于Ceph为了保证一致性,会将数据先写入到RocksDB WAL中去,然后再由RocksDB WAL将数据落到磁盘上去,因此覆盖性能也会稍差一些。随着数据块的增大,所有曲线最终收敛于3,符合我们前文中推断的

WAF=N。

综上所述,在多副本策略下,BlueStore的WAF的推演公式需要考虑:

数据块大小,RocksDB压缩数据大小, Zero-filled数据大小以及副本数量。

当随机写入小数据块的时候,会产生较多的Zero-filled数据,同时RocksDB压缩数据大小所占比重也会较大;当顺序写入大数据时,Zero-filled数据则基本为0,并且RocksDB压缩数据所占比重也可以忽略不计,因此公式整理如下:


WAF=[(X+20)*N]/X       X < 16KiB(HDD)|64KiB(SSD)


WAF=[(X+5)*N]/X     X >= 16KiB(HDD)|64KiB(SSD)

这里的推算主观性较强,当写入数据量小的时候(

X < 16KiB(HDD)|64KiB(SSD)

),估算ceph会产生的zero-filled数据15kib和rocksdb压缩后存入磁盘的数据量5kib,共计20kib;而当写入数据量大时(

X >= 16KiB(HDD)|64KiB(SSD)

),Zero-filled数据几乎为0,剩余RocksDB压缩后存入磁盘的数据量的5KiB。

如果考虑外部因素多带来的损耗为μ,我们最终可以推断出BlueStore+多副本情况下,写性能可以达到:

BW=[(W*n)/WAF]*μ


WAF=[(X+20)*N]/X       X < 16KiB(HDD)|64KiB(SSD)


WAF=[(X+5)*N]/X     X >= 16KiB(HDD)|64KiB(SSD)


  • WAF为写放大系数

  • X为写入数据块大小(KiB)

  • N为副本数

  • n为OSD数量

  • μ为损耗系数 一般为0.7~0.8


FileStore + 纠删码

相比较多副本冗余策略,纠删码的出现大大节省了磁盘空间,以下图举例,如果我们有5个OSD,并且按照K=3, M=2配置纠删码冗余策略,当有一组数据写入时(ABCDEFGHI),该数据会被分成3份分别写入3个OSD中,同时Ceph也会生成2个编码块写入到另外2个OSD中,写就是说,一次写入操作,实际上会产生(K+M)/K倍的实际写入量。而由于这里使用的存储后端是FileStore,journaling of journal问题会让写放大两倍,因此结合纠删码本身特性,WAF最终会收敛于:

(K+M)/K*2

由FileStore+多副本的公式推演可知,在FileStore写入时,同时还需要考虑transaction元数据,每个对象大概是5KiB左右,因此在FileStore+纠删码策略下,集群可以达到的写性能为:

BW=[(W*n)/WAF]*μ


WAF=[(X+20)*N]/X       X < 16KiB(HDD)|64KiB(SSD)


WAF=[(X+5)*2*(K+M)/K]/X


  • WAF为写放大系数

  • X为写入数据块大小(KiB)

  • N为副本数

  • n为OSD数量

  • μ为损耗系数 一般为0.7~0.8

  • K为数据块的个数

  • M为校验块的个数


BlueStore + 纠删码

有了前文的铺垫后,相信到这一步大家能够自己推演出BlueStore在纠删码策略下的写入性能推导公式。由于解决了journaling of journal问题,每次写入不再需要通过文件系统,因此在WAF最终将会收敛于:

(K+M)/M

结合BlueStore+3副本的写入性能公式推导,我们可以大致推断出,BlueStore+纠删码的写入性能公式:

BW=[(W*n)/WAF]*μ


WAF=[(X+20)*(K+M)/K]/X       X < 16KiB(HDD)|64KiB(SSD)


WAF=[(X+5)**(K+M)/K]/X     X >= 16KiB(HDD)|64KiB(SSD)


  • WAF为写放大系数

  • X为写入数据块大小(KiB)

  • N为副本数

  • n为OSD数量

  • μ为损耗系数 一般为0.7~0.8

  • K为数据块的个数

  • M为校验块的个数


Ceph写入性能公式总结

结合上文4个小节,我们最终得到了Ceph冗余策略和ObjectStore为变量的WAF推导公式:


Ceph集群写入性能可以大致推导为:


BW=[(W*n)/WAF]*μ


  • W: 单块裸盘写入带宽

  • n: OSD数量

  • WAF:写放大系数

  • μ:损耗系数

  • X: 写入数据块大小(KiB)

  • N: 多副本Size大小

  • K: 纠删码K值

  • M:纠删码M值

  • FileStore 5: 5KiB, FileStore中transaction元数据的数据量大小(推测值)

  • BlueStore 5: 5KiB, BlueStore中RocksDB的WAL数据大小(推测值)

  • BlueStore 20: 20KiB, BlueStore小文件写入时产生的Zero-filled数据块大小


转自:


Ceph读写性能估算方法 – 知乎



版权声明:本文为weixin_42319496原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。