admin管理员组文章数量:1655377
一般基准测试原则
基准测试的主要测试案例是:
线性读写(大块,长队列),单位MB/s
IOPS(每秒输入/输出操作数)中的小块(4-8kb,iodepth=32-128)的高度并行随机读写
IOPS中的单线程事务性随机写入(4-8kb,iodepth = 1)和读取(尽管单线程读取更为罕见
测试您的磁盘
在部署Ceph之前在驱动器上运行fio:
WARNING!对于那些不明白问题的人——写测试是破坏性的。不要在包含重要数据的磁盘上运行它,例如OSD日志分区。
在测试之前尝试禁用驱动器缓存:
hdparm -W 0 /dev/sdX
(SATA驱动器),sdparm --set WCE=0 /dev/sdX
(SAS驱动器)。通常,这是服务器固态硬盘(例如Micron 5100或Seagate Nytro)绝对需要的(请参阅#Drive缓存正在使您变慢),因为它使随机写入iops 增加了两个数量级以上(从288 iops到18000 iops!)。在某些情况下,它可能没有任何改善,因此请同时尝试使用-W0和-W1选项。线性读取:
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=read -runtime=60 -filename=/dev/sdX
线性写入:
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=write -runtime=60 -filename=/dev/sdX
峰值并行随机读取:
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randread -runtime=60 -filename=/dev/sdX
单线程读取延迟:
fio -ioengine=libaio -sync=1 -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randread -runtime=60 -filename=/dev/sdX
峰值并行随机写入:
fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=60 -filename=/dev/sdX
日志写入延迟:
fio -ioengine=libaio -sync=1 -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=write -runtime=60 -filename=/dev/sdX
。还可以使用-fsync=1
而不是-sync=1进行
尝试,并记下最差的结果,因为有时sync
或fsync
会被杂乱的硬件忽略。单线程随机写入延迟
fio -ioengine=libaio -sync=1 -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randwrite -runtime=60 -filename=/dev/sdX
您想问为什么这么慢?见下文。
一个有用的习惯是在您部署Ceph OSD的每个SSD上留一个空的分区,以便以后进行基准测试,因为某些SSD用满后会变慢。
测试您的Ceph集群
推荐的基准测试工具:
fio -ioengine=rbd。运行以下命令:
fio -ioengine=rbd -direct=1 -name=test -bs=4M -iodepth=16 -rw=write -pool=rpool_hdd -runtime=60 -rbdname=testimg
fio -ioengine=rbd -direct=1 -name=test -bs=4k -iodepth=1 -rw=randwrite -pool=rpool_hdd -runtime=60 -rbdname=testimg
fio -ioengine=rbd -direct=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -pool=rpool_hdd -runtime=60 -rbdname=testimg
然后重复执行rw=read/randread
。
这是为了进行如下测试:
可能的最佳延迟
线性带宽
随机访问iops
从空的RBD镜像读取非常快,因此在测试之前预先填满rbd镜像磁盘。
从您的实际RBD用户所在的节点运行测试。当您从单独的物理服务器运行测试时,结果通常会稍好一些。
从VM内部或通过内核RBD驱动程序(krbd)是相同的:
fio -ioengine=libaio -direct=1 -name=test -bs=4M -iodepth=16 -rw=write -runtime=60 -filename=/dev/rbdX
fio -ioengine=libaio -direct=1 -sync=1 -name=test -bs=4k -iodepth=1 -rw=randwrite -runtime=60 -filename=/dev/rbdX
fio -ioengine=libaio -direct=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=60 -filename=/dev/rbdX
不要错过添加的
-sync=1
选项。它是有意添加的,以匹配ioengine=rbd
测试。ioengine=rbd
没有同步的概念,所有内容始终与其保持“同步”。总体而言,这种写模式(事务性单线程写)对应于DBMS。请注意,不管将数据移入和移出内核的假定开销如何,内核客户端实际上都应该更快。
ceph-gobench
或者使用工具https://github/vitalif/ceph-bench。最初的想法来自俄语Ceph Chat中的“ Mark's bench”(https://github/socketpair/ceph-bench)。两者都使用non-replicated的Ceph池(size=1),在每个单独的OSD中创建几个4MB对象(默认为16个),并对一个OSD中随机选择的对象执行随机单线程4kb写操作。这模仿了对RBD的随机写入,并允许通过分别对它们进行基准测试来确定有问题的OSD。
要创建non-replicated的基准池,请使用
ceph osd pool create bench 128 replicated; ceph osd pool set bench size 1; ceph osd pool set bench min_size 1
。只需注意128(PG数量)就足以让所有OSD至少获得一个PG。
Notes:
切勿使用dd测试磁盘性能。
不要使用
rados bench
。它创建少量对象(每个线程1-2个),因此所有对象始终驻留在缓存中,并且改善了结果,超出了应有的范围。您可以使用
rbd bench
,但是fio更好。
为什么这么慢
首先:
对于线性读写,Ceph并不慢。
Ceph在HDD上并不慢:理论上,Bluestore的单线程随机写入性能是驱动器IOPS的66%(2/3)(当前实际为33%,但是如果您在此后版本将此自动或者手动修复的话:https://github/ceph/ceph/pull/26909,性能将恢复到66%),而多线程read/write性能几乎是原始驱动器速度的100%。
但是,大家总认为当使用用SSD替换HDD并使用高速网络时,Ceph的速度应该几乎一样快。每个人都习惯了I/O速度慢而软件速度快的想法。对于Ceph,通常情况并非如此。
Ceph是一个软件定义的存储系统,其“软件”是巨大的开销。当前的一般规则是:无论使用什么驱动器或网络,使用 Ceph都很难实现0.5ms以下的随机读取延迟和1ms以下的随机写入延迟。使用一个线程,这仅代表2000个随机读取iops和1000个随机写入iops,即使您设法实现此结果,也已经处于良好状态。使用最好的硬件并进行一些调整,您也许可以进一步改进它,但只能进行两次左右。
但是延迟重要吗?是的,当涉及到单线程(synchronous)随机read/write时,它确实可以。基本上,所有希望数据持久的软件都执行fsync调用,以序列化写入。例如,所有DBMS都可以。因此,要了解这些应用程序的性能极限,您应该使用iodepth=1
对群集进行基准测试。
延迟不随服务器或每个SSD的OSD或RAID0中的两个RBD的数量而定。当您使用iodepth=1
对集群进行基准测试时,您一次只能对一个放置组进行基准测试(PG是一个三元组或一对OSD)。结果仅受单个OSD处理单个请求的速度影响。实际上,iodepth=1
时,IOPS=1/latency
。尼克·菲斯克(Nick Fisk)的演讲题目为 «Low-latency Ceph»。«Low-latency Ceph»指出0.7毫秒,仅约1500 iops。
Micron设置案例
这是Micron的案例。他们使用了2倍replication,非常昂贵的CPU(每台服务器2x28核Xeon Platinum),高速的网络(2x100G,实际上是2x2x100G ——两张带有2个端口的卡)和10倍于四个节点的最佳NVMe:https:/ /www.micron/resource-details/30c00464-e089-479c-8469-5ecb02cfe06f
在100%CPU负载下,它们仅获得了350000的具有高并行度的峰值写入iops。它看起来似乎很多,但是如果将其除以NVMe的数量(350000/40 NVMe),则每个NVMe仅8750 iops。如果我们考虑2个副本和WAL,则每个驱动器得到8750 * 2 * 2 = 35000 iops。因此,Ceph仅从可以单独提供260000 iops的NVMe 中压缩了35000 iops 。这就是Ceph的开销。
在该文章中也没有单线程延迟测试。这样的测试可能非常有趣。
更新资料
https://www.micron/-/media/client/global/documents/products/other-
版权声明:本文标题:Ceph性能测试、优化及硬件选型详解|万字长文 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://www.elefans.com/dongtai/1729694931a1210429.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论