如何“计算”CEPH读写性能

CEPH 作为 SDS 的杰出代表，借着云计算的东风，可谓是红遍大江南北，老少皆知（这个有点扯，回家问问你爷爷听过 CEPH 没）。不管是 SDS 也好，还是 SDN 也好，所谓 SDX 系列均是以高度灵活性著称，这就给玩家一个广阔的想象空间。所有的部件均是灵活自主可控的，你可以自己随意组装，就像自己装电脑一样。

那么问题来了，这样搭建出来的集群到底能达到什么水平呢？读写性能有多高？不要告诉我搭建出来测试一下不就知道了，如果测试结果不满足业务需求呢，再建一套？那客户还留你何用！

进化三部曲

1、最近一直在思考一个存储集群的读写性能到底能达到什么水平？

2、跟构成集群所用单块磁盘到底是怎样的关系？

3、能不能通过计算得出集群的性能指标？

路人甲的思考

在了解 CEPH 的原理之前，大脑中有这样一个概念：既然集群是有很多块磁盘构成的，那么集群的性能应该就是所有磁盘的性能之和，假如一个集群由 100 块磁盘构成，那么集群的整体性能应该就是这 100 块磁盘之和。例如单块磁盘的 IO 有 500，那么集群的 IO 应该就是 500*100=50K。想到这里，心里还挺满意的，这意味着使用 CEPH 集群不但能够获得大容量，而且性能也是成倍的增加，于是内心暗自窃喜！

与君初见

慢慢了解到一些 CEPH 的基础知识以后发现，好像现实并不是想象中的那么美好，特别是看了一遍陈导总结的《 CEPH 读写性能估算方法》之后，发现原来这里面还有很多值得思考的点，例如：三副本（一份文件存三份，只有 1/3 的空间利用率）、waf（写放大，二次写 journal 导致写 IO 减半）、还有各种元数据、DB、wal 占用集群空间。这样算下来，我组装的集群可用容量减到三分之一，磁盘 IO 减半，最后集群的性能还不如单块磁盘的性能高。难道 CEPH 是江湖骗子拿来忽悠的？

无形胜有形

听君一席话，胜读十年文档，经过高人点拨之后茅塞顿开。从容量上来说， CEPH 可以灵活配置副本数量，合理规划空间使用。如果你觉得默认的三副本策略太浪费磁盘，也可以配置两副本数来实现 50%的磁盘空间使用率，或者单副本（不过我还是劝你等到头脑清醒的时候再做决定）实现 100%。

除了副本策略外， CEPH 还支持纠删码策略，通过灵活配置 K+M 比例，合理规划磁盘冗余度，来实现整个集群的高可靠性。例如，按照 K=3, M=2 配置纠删码冗余策略，当有一组数据写入时，该数据会被分成 3 份分别写入 3 个 OSD 中，同时 CEPH 也会生成 2 个编码块写入到另外 2 个 OSD 中，一次写入操作，实际上会产生(K+M)/K 倍的实际写入量，在保证集群高可靠性的同时大大提高磁盘使用率。

从读写性能上来说，并不是上文所说的创建集群之后由于写放大的缘故，导致整个集群的性能下降为单块磁盘的 50%。大家都知道 CEPH 是一种分布式的存储系统，同时也是一种对象存储。当然这里所说的对象并不是指对用户提供对象存储的功能，这里的对象是 CEPH 或者说 rados 在内部处理数据的方式。通过外部接口（对象存储接口 RGW、块存储接口 RBD、文件系统存储 CEPH FS、当然还有我们自研的 HDFS 接口、流媒体接口等）写入的数据分片，生成许多小的对象，然后再把这些小的对象均匀的写入到各个物理磁盘上面。

了解过 CEPH 的人应该都听过 PG 的概念，这些内部的小对象就是通过 PG 这个模块来进行分组，属于同一组的内部小对象会有相同的物理磁盘位置。例如第一组小对象的三个副本会写入到 osd1、2、3 上面，第二组小对象写入到 osd2、3、4 上面。如果集群内部的 PG 数量足够多，用户数据就会均匀的分布到各个物理磁盘上面，这样同一时刻用户存入的数据就会同时在不同的物理磁盘上面进行写入。虽然集群写入速度不是所有磁盘之和，但也是多块磁盘性能累加的，最后用户感知到的性能也是可观的。

预测“未来”

了解了大概原理以后，如何根据用户提供的硬件资源来预估集群的性能呢？

一、FileStore + 多副本

条件假设一：

（1）假设每块磁盘作为一个 OSD，这个 OSD 的 journal 和 data 都放在这块磁盘上。所有数据都是先写到 journal 上，然后再写到 data 上，也就是单 OSD 的写放大系数是 2；

（2）假设 OSD 个数为 N；

（3）假设副本数是 M，数据直到写入 M 个 OSD 之后才响应，因此对于多副本存储池，写放大系数是 M；

（4）因为 CEPH 软件会损耗 CPU 资源，也会损耗一些性能，损耗系数定为 0.7；

（5）假设单块 SSD 的 4K 随机读 IOPS 是 R，4K 随机写 IOPS 是 W。

在不考虑网络瓶颈和 CPU 瓶颈的情况下， CEPH 存储池的 IOPS 估算公式是：

1、4K 随机读 IOPS = RN0.7

2、4K 随机写 IOPS = WN0.7/(2*M)

条件假设二：

（1）假设每块 SATA 磁盘作为一个 OSD，有一块 NVME 磁盘专门作为 journal。所有数据都是先写到 journal 上，然后再同步到 data 上，也就是单 OSD 的写放大系数就变成 1（假设 NVME 性能大于所有本机 SATA 盘之和）；

（2）假设 OSD 个数为 N；

（3）假设副本数是 M，数据直到写入 M 个 OSD 之后才响应，因此对于多副本存储池，写放大系数是 M；

（4）因为 CEPH 软件会损耗 CPU 资源，也会损耗一些性能，损耗系数定为 0.7；

（5）假设单块 SSD 的 4K 随机读 IOPS 是 R，4K 随机写 IOPS 是 W。

在不考虑网络瓶颈和CPU瓶颈的情况下， CEPH 存储池的IOPS估算公式是：

1、4K随机读IOPS = RN0.7

2、4K随机写IOPS = WN0.7/(M)

二、BlueStore + 多副本

条件假设一：

（1）假设每块磁盘作为一个 OSD，该磁盘划为 2 块分区：一个分区作为裸盘来写入数据，另一块做 BlueFS 用来跑 RocksDB。因此我们一次写入的流程可以简化成下图：数据会被直接写入到 data 分区(裸盘）中，而对象元数据会被写到 RocksDB 和 RocksDB 的 WAL 中，随后 RocksDB 将数据压缩后存放到磁盘中。我们不再需要在文件系统层做 journal，而 WAL 只在覆写操作时才会用到，因此在副本数量为 N 的条件下，我们可以推测 WAF 将收敛于 N，也就是单 OSD 的写放大系数是 1。

（2）假设 OSD 个数为 N；

（3）假设副本数是 M，数据直到写入 M 个 OSD 之后才响应，因此对于多副本存储池，写放大系数是 M；

（4）由于 CEPH 软件会损耗 CPU 资源，也会损耗一些性能，损耗系数定为 0.7；

（5）假设单块 SSD 的 4K 随机读 IOPS 是 R，4K 随机写 IOPS 是 W。

在不考虑网络瓶颈和CPU瓶颈的情况下， CEPH 存储池的IOPS估算公式是：

1、4K随机读IOPS = RN0.7

2、4K随机写IOPS = WN0.7/(M)

注意：在BlueStore中，磁盘分区会以‘bluestore_min_alloc_size’的大小分配管理，这个数值默认为64KiB。也就是说，如果我们写入< 64KiB的数据，剩余的空间会被0填充，也即是‘Zero-filled data’，然后写入磁盘。也正是这样，BlueStore的小文件随机写性能并不好，因此在小文件计算式可以适量减少损耗系数。

条件假设二：

（1）假设每块 SATA 磁盘作为一个 OSD，有一块 NVME 磁盘专门作跑 RocksDB。数据会被直接写入到 data 分区(裸盘）中，而对象元数据会被写到 RocksDB 和 RocksDB 的 WAL 中，也就是单 OSD 的写放大系数就变成 1；

（2）假设 OSD 个数为 N；

（3）假设副本数是 M，数据直到写入 M 个 OSD 之后才响应，因此对于多副本存储池，写放大系数是 M；

（4）因为 CEPH 软件会损耗 CPU 资源，也会损耗一些性能，损耗系数定为 0.7；

（5）假设单块 SSD 的 4K 随机读 IOPS 是 R，4K 随机写 IOPS 是 W。

在不考虑网络瓶颈和CPU瓶颈的情况下， CEPH 存储池的IOPS估算公式是：

1、4K随机读IOPS = RN0.7

2、4K随机写IOPS = WN0.7/(M)

三、FileStore + 纠删码

相比较多副本冗余策略，纠删码的出现大大节省了磁盘空间，如果我们有 N 个 OSD，并且按照 K=3, M=2 配置纠删码冗余策略。一次写入操作，实际上会产生(K+M)/K 倍的实际写入量。而由于这里使用的存储后端是 FileStore，journaling of journal 问题会让写放大两倍，因此结合纠删码本身特性，WAF 最终会收敛于(K+M)/K*2。

在不考虑网络瓶颈和CPU瓶颈的情况下， CEPH 存储池的IOPS估算公式是：

1、4K随机读IOPS = RN0.7

2、4K随机写IOPS = WN0.72K/(K+M)

四、BlueStore + 纠删码

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

在不考虑网络瓶颈和CPU瓶颈的情况下， CEPH 存储池的IOPS估算公式是：

1、4K随机读IOPS = RN0.7

2、4K随机写IOPS = WN0.7K/(K+M)

目标是星辰大海

通过上述计算得出的结果就可以直接用来作为参考了么 ？答案当然是否定的。以上的计算我们仅仅是考虑了磁盘这一单一变量，除此之外还有网络、cpu 资源等都需要列入计算。 CEPH 是一个分布式的系统，任何一个短板都会影响集群的对外输出性能。

例如网络资源：假设单节点有 10 块 SATA 磁盘，每块的读带宽是 100MB/s，按照上面的公式，单节点的读带宽大概是 100108=8G/s。假设此时机器上面只有两个千兆端口，即使是做了 RR 捆绑，也只能提供 2G/s 带宽，此时集群的性能参考可能就是网络端口的极限值了。

再例如 CPU 资源：按照经验值单核处理的写 IO 大概是 2000 左右，假设一台机器配置了 20 块 50K IOPS 的 SSD，此时的性能极限就很有可能被 CPU 限制了。

总之，如何在纷繁的选择中，描绘出最美“画面”，是一件很“艺术”的事情。

本文转载自公众号 UCloud 技术（ID：ucloud_tech）。

原文链接：

https://mp.weixin.qq.com/s/BmUjEV1wTRI-T-CuC-2Nbw