从传统运维到云运维演进历程之软件定义存储(三)下

时间:2021-07-21 12:34:40

上回书讲到了运维小哥的调优方法论(上),对于Ceph运维人员来说最头痛的莫过于两件事:一、Ceph调优;二、Ceph运维。调优是件非常头疼的事情,下面来看看运维小哥是如何调优的。

关卡二:部署调优关之调优(二)

难度:五颗星

优化方法论

通过对网上公开资料的分析进行总结,对Ceph的优化离不开以下几点:

硬件层面

  • 硬件规划

  • SSD选择

  • BIOS设置

操作系统层面

  • Linux Kernel

  • 内存

  • Cgroup

网络层面

  • 巨型帧

  • 中断亲和

  • 硬件加速

Ceph层面

  • Ceph Configurations

  • PG Number调整

 

网络层面优化

这里把网络部分的优化独立出来写,主要原因是网络通信在Ceph的工作流程中被大量使用到。Ceph距今已经有10余年的历史,时至今日,Ceph各个组件间的通信依然使用10年前的设计:基于多线程模型的网络通信,每个终端包含读和写两个线程, 负责消息的接受和发送。在默认三副本的情况下,客户端的每次写请求需要至少6次网络通信。作为Ceph的基石,接下来我们将讨论网络优化在Ceph中的应用。

任何时候通过一个套接字(socket)来读写数据时,都会使用一个系统调用(system call),这个调用将触发内核上下文切换(Context Switch),下面描述了一个典型的系统调用流程:

1)Ceph进程调用send()函数发送消息。

2)触发0x80中断,由用户态切换至内核态。

3)内核调用system_call()函数,进行参数检查,根据系统调用好获得对应的内核函数。

4)执行内核函数,发送数据报文。

5)内核函数执行完毕,切换回内核态。

6)Socket()调用完成。

整个数据发送/接受需要触发两次上下文切换,以及若干次内存拷贝,这些操作会消耗大量的时间,我们优化的思路就是减少这些时间损耗。在处理网络IO时需要CPU消耗大量的计算能力,因此我们希望CPU尽可能少的处理这些琐碎的IO任务,有足够的处理能力运行Ceph集群,我们主要讨论使用巨型帧、中断亲和等技术加速网络IO。

1.巨型帧

以太网诞生以来,其帧结构一直就没有发生过大的改变。默认情况下,以太网的MTU(Maximum Transmission Unit)是1500字节。默认情况下以太网帧是1522 字节,包含1500字节的负载、14字节的以太网头部、4字节的CRC、4字节的VLAN Tag,超过该大小的数据包会在被拆封成更多数据包,巨型帧是长度大于1522字节的以太网帧,通过调整MTU(通常我们会调整到9000)来减少网络中数据包的个数,减轻网络设备处理包头的额外开销。设置MTU需要本地设备和对端设备同时开启,开启巨型帧后,可以极大地提高性能。

2.中断亲和

前面提到了当我们要进行网络IO时,会触发系统中断。默认情况下,所有的网卡中断都交由CPU0处理,当大量网络IO出现时,处理大量网络IO中断会导致CPU0长时间处于满负载状态,以致无法处理更多IO导致网络丢包等并发问题,产生系统瓶颈。Linux 2.4内核之后引入了将特定中断绑定到指定的CPU的技术,称为中断亲和(SMP IRQ affinity)。

Linux中所有的中断情况在文件/proc/interrupt中记录:

从传统运维到云运维演进历程之软件定义存储(三)下

 中断记录情况

 

3.硬件加速 

在大多数情况下,CPU需要负责服务器中几乎所有的数据处理任务,事实上CPU并不如我们想象中的那样强大,在大量的数据处理中往往显得力不从心,于是便有了硬件加速技术。硬件加速能够将计算量比较大的工作分配给专门的硬件设备处理,比如常见的使用视频硬件解码加速等,在Ceph中,我们主要使用网卡完成对于网络数据处理的加速。

TCP协议处理网络流量,需要占用大量CPU和内存资源,为了节省服务器资源的消耗,众多厂商开始在网卡中内置协处理器,将计算任务移交给协处理器完成,即TCP卸载引擎(TCP offload Engine,TOE)。TOE目前主要能协助完成以下工作:

(1)协议处理

普通网卡处理网络IO的很大一部分压力都来自于对TCP/IP协议的处理,例如对IP数据包的校验处理、对TCP数据流的可靠性和一致性处理。TOE网卡可以将这些计算工作交给网卡上的协处理器完成。

(2)中断处理

上面讲到,在通用网络IO的处理方式上,普通网卡每个数据包都要触发一次中断,TOE网卡则让每个应用程序完成一次完整的数据处理进程后才出发一次中断,显著减轻服务对中断的响应负担。

(3)减少内存拷贝

普通网卡先将接收到的数据在服务器的缓冲区中复制一份,经系统处理后分配给其中一个TCP连接,然后,系统再将这些数据与使用它的应用程序相关联,并将这些数据由系统缓冲区复制到应用程序的缓冲区。TOE网卡在接收数据时,在网卡内进行协议处理,因此,它不必将数据复制到服务器缓冲区,而是直接复制到应用程序的缓冲区,这种数据传输方式减少了部分内存拷贝的消耗。

在Linux中,可以使用ethtool查看网卡状态或设置网卡参数。

从传统运维到云运维演进历程之软件定义存储(三)下

使用ethtool查看网卡状态

使用命令ethtool -K em1 tso on打开tcp-segmentation-offload,查看tcp-segmentation-offload已经打开(on)。

从传统运维到云运维演进历程之软件定义存储(三)下

使用ethtool打开tcp-segmentation-offload

 

Ceph层面优化

以上部分主要围绕着硬件、操作系统、网络进行优化,下面围绕Ceph的本身参数进行调优,Ceph将很多运行参数作为配置项保存在配置文件中,Ceph为我们提供了相当详细的配置参数供用户在不同场景下的调整和优化。

1.Ceph Configurations

[global]全局参数以及参数描述,可以通过linux命令sysctl来设定max open files的值fs.file-max。

从传统运维到云运维演进历程之软件定义存储(三)下osd部分filestore参数,调整omap的原因主要是EXT4文件系统默认仅有4K。

filestore queue相关的参数对于性能影响很小,参数调整不会对性能优化有本质上提升

从传统运维到云运维演进历程之软件定义存储(三)下

[osd] -journal相关参数,Ceph OSD进程在往数据盘上刷数据的过程中,是停止写操作的。

从传统运维到云运维演进历程之软件定义存储(三)下

[osd] �C osd config tuning相关参数,增加osd op threads和disk threads会带来额外的CPU开销。

从传统运维到云运维演进历程之软件定义存储(三)下
[osd] �C recovery tuning相关参数。

从传统运维到云运维演进历程之软件定义存储(三)下
[osd] �C client tuning相关参数

从传统运维到云运维演进历程之软件定义存储(三)下


2.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。

ceph osd pool set volumes pg_num 512

ceph osd pool set volumes pgp_num 512

 

下面的Ceph参数配置是我们在使用过程中逐渐积累的一个优化后的配置,可以基于下面的配置对Ceph集群进行参数调优。

[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

 

因为优化部分涉及内容较多,所以分为两篇文章来讲述,至此Ceph部署调优关卡讲述完毕,希望本关卡能够给予Ceph新手参考,请读者见仁见智,预知后事如何,请期待《性能测试关卡》。


本文出自 “态度决定一切” 博客,请务必保留此出处http://devingeng.blog.51cto.com/6892345/1860807