ceph 简单测试

预期目标

  • 在1024个客户端,并发2048个线程,块大小为64k,队列深度为32的情况下,需要什么样的硬件环境,才能保证读写稳定,iops延时不大于10ms,平均值在5ms。

实验环境

os:ubuntu 14.04
kernel version:3.16.0-30-generic
所有osd采用bluestore
8个ssd:三星850 pro 1TB
22个hdd:Seagate Barracuda ST2000DM001 2TB

ssd-node241 ssd-node242 hd-node243 hd-node244
ip 172.16.8.241 172.16.8.242 172.16.8.243 172.16.8.244
memory 128GB 32GB 64GB 64GB
cpu E5-2650 v3 @ 2.30GHz 34 core E5-2640 v3 @ 2.60GHz 32 core E5-2620 v3 @ 2.40GHz 24 core E5-2620 v3 @ 2.40GHz 24 core
  • 8个ssd:三星850 pro 1TB
  • 22个hdd:Seagate Barracuda ST2000DM001 2TB
    SSD.png
    HDD.png

    测试过程、数据

  1. 场景一:纯硬盘环境
    用4个HDD盘的osd做池,创建rbd卷,用fio测试这个rbd块设备的性能每次测好之后做记录并再向pool中添加两个HDD的osd
    测试命令:
    1
    fio -filename=/dev/rbd0 -bs=64k -ioengine=libaio -iodepth=32 -numjobs=4 -direct=1 -thread -rw=randwrite -size=200G -runtime=50 -group_reporting -name=test
osd iops lat(ms)
4 491 260.5
6 875 146.28
8 998 128.18
10 1206 106.07
12 1540 83.07
14 1789 71.51
16 1876 68.22
18 2023 63.24
20 1914 66.84
22 2201 58.14
  1. 场景二:纯SSD环境
    用4个SSD盘的osd做池,创建rbd卷,用fio测试这个rbd块设备的性能,每次测好之后做记录并再向pool中添加两个SSD的osd
    测试命令:
    1
    fio -filename=/dev/rbd0 -bs=64k -ioengine=libaio -iodepth=32 -numjobs=4 -direct=1 -thread -rw=randwrite -size=200G -runtime=50 -group_reporting -name=test
osd iops lat(ms)
4 12278 10.422
6 15682 8.16
8 18652 6.857
  1. 场景三:混合环境
    bluestore无法像filestore一样可以把journal 放到高速设备上的,因为bluestore根本没有journal,不过可以把wal和db放在高速设备上,这个方案当前版本暂时实现不了,需要下个版本才行,具体效果也不清楚。目前的混合环境采用cache tier的方案,把ssd pool 当成 hdd pool的缓存层,并使用wirteback方法把读和写io全部导向ssd pool,使读写hdd pool的数据和ssd pool一样

数据分析与总结

机械盘osd的延迟较大,不过好在随着硬盘个数的增多,延迟会逐渐减少,差不多每增加两个osd iops会增加200左右,延迟减少5ms左右
固态盘的延迟还算可以,每增加2个osd iops增加3000,延迟降低2ms
相对于hdd pool来说ssd pool 更加稳定,主要从测试过程中来看,hdd pool 测试的时候iops有时会出现抖动的情况,更神奇的是用相同的测试命令去测,两次的数值存在差异,会比上次测试差一点点,差异幅度最后会趋于平缓
samsung 850 pro 1TB 块大小64k 32QD 4 job能达到6000左右iops,8块就是48000,2副本就是24000iops,但现在实际只有18000iops,性能损失1/4左右

性能分析关注点:

IO系统性能相关指标

  1. 块大小
  2. 队列深度
  3. 并发线程数
  4. 客户端数量
  5. 存储内部性能关键指标

达到这样的性能做了哪些优化

调度:ssd使用noop,hd使用deadline
预读:默认值太低了(read_ahead_kb)
swap:不使用交换分区
网络:巨型帧
ceph配置文件的优化

ceph操作注意点

  1. ceph集群操作一定要先想清楚了,因为不恰当的操作可能导致pg出现问题,甚至osd down掉
  2. 在2副本的时候操作osd最好一个一个来,避免两个osd 同时down掉就直接导致health error
  3. 默认的crush_rule 0 最好不要动,而且rule对应的root不要放osd在里面,因为创建pool的同时如果没有指定crush_rule的话默认就是rule 0,如果rule 0里面有osd,ceph就会往里面创建pg对应关系

遇到的坑

  1. 重启osd出现osd无法启动的情况
  2. 创建rbd 卷成功但是ls看不到也无法map
  3. 一个osd down掉导致大量osd也跟着down
  4. 各种health warn

现在ceph的问题

  1. 不能发挥高速设备如固态硬盘的全部性能;
  2. io路径较长导致高延迟;
  3. 数据恢复占用极大的资源;
  4. 对整体延迟要求较高;
  5. 主流后端filestore存在写放大的问题;
  6. ssd使用寿命的问题;

对以后ceph的什么什么

主要是ceph全新的存储方式bluestore,可以直接对裸盘进行读写,避免了filestore写journal时的写放大问题,bluestore完全不需要journal,可以把更多的ssd投入到cache tier中,目前测试环境jewel的bluestore还只是预览版,最新的Luminous版还处于测试版,默认采用bluestore后端,稳定版本来2017 春季发布,但现在夏季了还没有发布。

spdk和dpdk

文章目录
  1. 1. 预期目标
  2. 2. 实验环境
  3. 3. 测试过程、数据
  4. 4. 数据分析与总结
    1. 4.1. 性能分析关注点:
  5. 5. 达到这样的性能做了哪些优化
  6. 6. ceph操作注意点
  7. 7. 遇到的坑
  8. 8. 现在ceph的问题
  9. 9. 对以后ceph的什么什么
|