Ceph性能优化总结


优化方法论

做任何事情还是要有个方法论的,“授人以鱼不如授人以渔”的道理吧,方法通了,所有的问题就有了解决的途径。通过对公开资料的分析进行总结,对分布式存储系统的优化离不开以下几点:

1. 硬件层面

  • 硬件规划
  • SSD选择
  • BIOS设置

2. 软件层面

  • Linux OS
  • Ceph Configurations
  • PG Number调整
  • CRUSH Map
  • 其他因素

硬件优化

1. 硬件规划

  • Processor

ceph-osd进程在运行过程中会消耗CPU资源,所以一般会为每一个ceph-osd进程绑定一个CPU核上。当然如果你使用EC方式,可能需要更多的CPU资源。

ceph-mon进程并不十分消耗CPU资源,所以不必为ceph-mon进程预留过多的CPU资源。

ceph-msd也是非常消耗CPU资源的,所以需要提供更多的CPU资源。

  • 内存

ceph-mon和ceph-mds需要2G内存,每个ceph-osd进程需要1G内存,当然2G更好。

  • 网络规划

万兆网络现在基本上是跑Ceph必备的,网络规划上,也尽量考虑分离cilent和cluster网络。

2. SSD选择

硬件的选择也直接决定了Ceph集群的性能,从成本考虑,一般选择SATA SSD作为Journal,Intel® SSD DC S3500 Series基本是目前看到的方案中的首选。400G的规格4K随机写可以达到11000 IOPS。如果在预算足够的情况下,推荐使用PCIE SSD,性能会得到进一步提升,但是由于Journal在向数据盘写入数据时Block后续请求,所以Journal的加入并未呈现出想象中的性能提升,但是的确会对Latency有很大的改善。

如何确定你的SSD是否适合作为SSD Journal,可以参考SÉBASTIEN HAN的Ceph: How to Test if Your SSD Is Suitable as a Journal Device?,这里面他也列出了常见的SSD的测试结果,从结果来看SATA SSD中,Intel S3500性能表现最好。

3. BIOS设置

  • Hyper-Threading(HT)

基本做云平台的,VT和HT打开都是必须的,超线程技术(HT)就是利用特殊的硬件指令,把两个逻辑内核模拟成两个物理芯片,让单个处理器都能使用线程级并行计算,进而兼容多线程操作系统和软件,减少了CPU的闲置时间,提高的CPU的运行效率。

  • 关闭节能

关闭节能后,对性能还是有所提升的,所以坚决调整成性能型(Performance)。当然也可以在操作系统级别进行调整,详细的调整过程请参考链接,但是不知道是不是由于BIOS已经调整的缘故,所以在CentOS 6.6上并没有发现相关的设置。

1
for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -f $CPUFREQ ] || continue; echo -n performance > $CPUFREQ; done

简单来说,NUMA思路就是将内存和CPU分割为多个区域,每个区域叫做NODE,然后将NODE高速互联。 node内cpu与内存访问速度快于访问其他node的内存,NUMA可能会在某些情况下影响ceph-osd。解决的方案,一种是通过BIOS关闭NUMA,另外一种就是通过cgroup将ceph-osd进程与某一个CPU Core以及同一NODE下的内存进行绑定。但是第二种看起来更麻烦,所以一般部署的时候可以在系统层面关闭NUMA。CentOS系统下,通过修改/etc/grub.conf文件,添加numa=off来关闭NUMA。

1
kernel /vmlinuz-2.6.32-504.12.2.el6.x86_64 ro root=UUID=870d47f8-0357-4a32-909f-74173a9f0633 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM   biosdevname=0 numa=off

软件优化

1. Linux OS

  • Kernel pid max
1
echo 4194303 > /proc/sys/kernel/pid_max
  • Jumbo frames, 交换机端需要支持该功能,系统网卡设置才有效果
1
ifconfig eth0 mtu 9000

永久设置

1
2
echo "MTU=9000" | tee -a /etc/sysconfig/network-script/ifcfg-eth0
/etc/init.d/networking restart
  • read_ahead, 通过数据预读并且记载到随机访问内存方式提高磁盘读操作,查看默认值
1
cat /sys/block/sda/queue/read_ahead_kb

根据一些Ceph的公开分享,8192是比较理想的值

1
echo "8192" > /sys/block/sda/queue/read_ahead_kb
  • swappiness, 主要控制系统对swap的使用,这个参数的调整最先见于UnitedStack公开的文档中,猜测调整的原因主要是使用swap会影响系统的性能。
1
echo "vm.swappiness = 0" | tee -a /etc/sysctl.conf
  • I/O Scheduler,关于I/O Scheculder的调整网上已经有很多资料,这里不再赘述,简单说SSD要用noop,SATA/SAS使用deadline。
1
2
echo "deadline" > /sys/block/sd[x]/queue/scheduler
echo "noop" > /sys/block/sd[x]/queue/scheduler
  • cgroup

这方面的文章好像比较少,昨天在和Ceph社区交流过程中,Jan Schermer说准备把生产环境中的一些脚本贡献出来,但是暂时还没有,他同时也列举了一些使用cgroup进行隔离的原因

  • 不在process和thread在不同的core上移动(更好的缓存利用)
  • 减少NUMA的影响
  • 网络和存储控制器影响 - 较小
  • 通过限制cpuset来限制Linux调度域(不确定是不是重要但是是最佳实践)
  • 如果开启了HT,可能会造成OSD在thread1上,KVM在thread2上,并且是同一个core。Core的延迟和性能取决于其他一个线程做什么。

这一点具体实现待补充!!!

2. Ceph Configurations

[global]

参数名描述默认值建议值
public network客户端访问网络 192.168.100.0/24
cluster network集群网络 192.168.1.0/24
max open files如果设置了该选项,Ceph会设置系统的max open fds0131072

  • 查看系统最大文件打开数可以使用命令
1
cat /proc/sys/fs/file-max

[osd] - filestore

参数名描述默认值建议值
filestore xattr use omap为XATTRS使用object map,EXT4文件系统时使用,XFS或者btrfs也可以使用falsetrue
filestore max sync interval从日志到数据盘最大同步间隔(seconds)515
filestore min sync interval从日志到数据盘最小同步间隔(seconds)0.110
filestore queue max ops数据盘最大接受的操作数50025000
filestore queue max bytes数据盘一次操作最大字节数(bytes)100 << 2010485760
filestore queue committing max ops数据盘能够commit的操作数5005000
filestore queue committing max bytes数据盘能够commit的最大字节数(bytes)100 << 2010485760000
filestore op threads并发文件系统操作数232

  • 调整omap的原因主要是EXT4文件系统默认仅有4K
  • filestore queue相关的参数对于性能影响很小,参数调整不会对性能优化有本质上提升

[osd] - journal

参数名描述默认值建议值
osd journal sizeOSD日志大小(MB)512020000
journal max write bytesjournal一次性写入的最大字节数(bytes)10 << 201073714824
journal max write entriesjournal一次性写入的最大记录数10010000
journal queue max opsjournal一次性最大在队列中的操作数50050000
journal queue max bytesjournal一次性最大在队列中的字节数(bytes)10 << 2010485760000

  • Ceph OSD Daemon stops writes and synchronizes the journal with the filesystem, allowing Ceph OSD Daemons to trim operations from the journal and reuse the space.
  • 上面这段话的意思就是,Ceph OSD进程在往数据盘上刷数据的过程中,是停止写操作的。

[osd] - osd config tuning

参数名描述默认值建议值
osd max write sizeOSD一次可写入的最大值(MB)90512
osd client message size cap客户端允许在内存中的最大数据(bytes)5242880002147483648
osd deep scrub stride在Deep Scrub时候允许读取的字节数(bytes)524288131072
osd op threadsOSD进程操作的线程数28
osd disk threadsOSD密集型操作例如恢复和Scrubbing时的线程14
osd map cache size保留OSD Map的缓存(MB)5001024
osd map cache bl sizeOSD进程在内存中的OSD Map缓存(MB)50128
osd mount options xfsCeph OSD xfs Mount选项rw,noatime,inode64rw,noexec,nodev,noatime,nodiratime,nobarrier

  • 增加osd op threads和disk threads会带来额外的CPU开销

[osd] - recovery tuning

参数名描述默认值建议值
osd recovery op priority恢复操作优先级,取值1-63,值越高占用资源越高104
osd recovery max active同一时间内活跃的恢复请求数1510
osd max backfills一个OSD允许的最大backfills数104

[osd] - client tuning

参数名描述默认值建议值
rbd cacheRBD缓存truetrue
rbd cache sizeRBD缓存大小(bytes)33554432268435456
rbd cache max dirty缓存为write-back时允许的最大dirty字节数(bytes),如果为0,使用write-through25165824134217728
rbd cache max dirty age在被刷新到存储盘前dirty数据存在缓存的时间(seconds)15

关闭Debug

3. PG Number

PG和PGP数量一定要根据OSD的数量进行调整,计算公式如下,但是最后算出的结果一定要接近或者等于一个2的指数。

Total PGs = (Total_number_of_OSD * 100) / max_replication_count

例如15个OSD,副本数为3的情况下,根据公式计算的结果应该为500,最接近512,所以需要设定该pool(volumes)的pg_num和pgp_num都为512.

1
2
ceph osd pool set volumes pg_num 512
ceph osd pool set volumes pgp_num 512

4. CRUSH Map

CRUSH是一个非常灵活的方式,CRUSH MAP的调整取决于部署的具体环境,这个可能需要根据具体情况进行分析,这里面就不再赘述了。

5. 其他因素的影响

在今年的(2015年)的Ceph Day上,海云捷迅在调优过程中分享过一个由于在集群中存在一个性能不好的磁盘,导致整个集群性能下降的case。通过osd perf可以提供磁盘latency的状况,同时在运维过程中也可以作为监控的一个重要指标,很明显在下面的例子中,OSD 8的磁盘延时较长,所以需要考虑将该OSD剔除出集群:

1
ceph osd perf
osd fs_commit_latency(ms) fs_apply_latency(ms)
  0                    14                   17
  1                    14                   16
  2                    10                   11
  3                     4                    5
  4                    13                   15
  5                    17                   20
  6                    15                   18
  7                    14                   16
  8                   299                  329

ceph.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
[global]
fsid = 059f27e8-a23f-4587-9033-3e3679d03b31
mon_host = 10.10.20.102, 10.10.20.101, 10.10.20.100
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
osd pool default size = 3
osd pool default min size = 1

public network = 10.10.20.0/24
cluster network = 10.10.20.0/24

max open files = 131072

[mon]
mon data = /var/lib/ceph/mon/ceph-$id

[osd]
osd data = /var/lib/ceph/osd/ceph-$id
osd journal size = 20000
osd mkfs type = xfs
osd mkfs options xfs = -f

filestore xattr use omap = true
filestore min sync interval = 10
filestore max sync interval = 15
filestore queue max ops = 25000
filestore queue max bytes = 10485760
filestore queue committing max ops = 5000
filestore queue committing max bytes = 10485760000

journal max write bytes = 1073714824
journal max write entries = 10000
journal queue max ops = 50000
journal queue max bytes = 10485760000

osd max write size = 512
osd client message size cap = 2147483648
osd deep scrub stride = 131072
osd op threads = 8
osd disk threads = 4
osd map cache size = 1024
osd map cache bl size = 128
osd mount options xfs = "rw,noexec,nodev,noatime,nodiratime,nobarrier"
osd recovery op priority = 4
osd recovery max active = 10
osd max backfills = 4

[client]
rbd cache = true
rbd cache size = 268435456
rbd cache max dirty = 134217728
rbd cache max dirty age = 5

总结

优化是一个长期迭代的过程,所有的方法都是别人的,只有在实践过程中才能发现自己的,本篇文章仅仅是一个开始,欢迎各位积极补充,共同完成一篇具有指导性的文章。

展开阅读全文

没有更多推荐了,返回首页