如何“计算”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、文件系统存储cephFS、当然还有我们自研的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 = R*N*0.7
2．4K随机写IOPS = W*N*0.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 = R*N*0.7
2．4K随机写IOPS = W*N*0.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 = R*N*0.7
2．4K随机写IOPS = W*N*0.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 = R*N*0.7
2．4K随机写IOPS = W*N*0.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 = R*N*0.7
2．4K随机写IOPS = W*N*0.7*2*K/(K+M)
BlueStore + 纠删码
有了前文的铺垫后，相信到这一步大家能够自己推演出BlueStore在纠删码策略下的写入性能推导公式。由于解决了journaling of journal问题，每次写入不再需要通过文件系统，因此WAF最终将会收敛于(K+M)/M。
在不考虑网络瓶颈和CPU瓶颈的情况下，Ceph存储池的IOPS估算公式是：
1．4K随机读IOPS = R*N*0.7
2．4K随机写IOPS = W*N*0.7K/(K+M)
目标是星辰大海
通过上述计算得出的结果就可以直接用来作为参考了么？答案当然是否定的。
以上的计算我们仅仅是考虑了磁盘这一单一变量，除此之外还有网络、cpu资源等都需要列入计算。
ceph是一个分布式的系统，任何一个短板都会影响集群的对外输出性能。
例如网络资源：假设单节点有10块SATA磁盘，每块的读带宽是100MB/s，按照上面的公式，单节点的读带宽大概是100*10*8=8G/s。假设此时机器上面只有两个千兆端口，即使是做了RR捆绑，也只能提供2G/s，带宽，此时集群的性能参考可能就是网络端口的极限值了。
再例如CPU资源：按照经验值单核处理的写IO大概是2000左右，假设一台机器配置了20块50K IOPS的SSD，此时的性能极限就很有可能被CPU限制了。
总之，如何在纷繁的选择中，描绘出最美“画面”，是一件很“艺术”的事情。