存储性能优化方向整理


0概述

0.1 存储性能优化指标

io速率:速率提升数值和百分比

iops:iops提升数值和百分比

 

0.2 优化方向概述

块存储优化方向:优化的工作,基本上都是在底层,上层只是一些配置。

这些底层的技术适用于ceph块设备,主要是ceph还有自身的一些配置、缓存方案可以拿过来用,在最后补充一下。

底层包括qemu/kvm/kernel三个层面,kernel又主要是filesystem、scsi和block这部分和存储关系最大,也是存储系统由上而下的三部分。我认为如果优化的话,主要工作在这几个方面。内核中的部分还可以分为配置级的(makemenuconfig选择重新编译即可),以及代码级的优化。上面的qemu/kvm也可以包括配置级和代码级的优化。

 

以下内容中:

(1)qemu的配置,包括运行时的配置,编译时的配置

(2)qemu/kvm/kernel最新版本代码的合入

(3)第三方cache驱动flashcache+SSD+RAID的分层存储方案

以上三点都是短期内可以实现的,难度不大

并且性能应该可以得到不少的提升

至于源码研究性的改进可以作为一项长期积累来做

0.3 参考资料

http://blog.csdn.net/wsfdl/article/details/41980055

http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=7934175&id=5679365

http://qemu.weilnetz.de/qemu-doc.html

《深度实践KVM》(肖力,机械工业出版社)

 

1.   软件优化之qemu配置与编译选项

磁盘的一些选项:

 

 

-drivefile=/var/lib/nova/instances/ebde34e7-a188-4d66-8bb1-011347f5e25a/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none

1.1 qemu cache设置

设置方法:

nova-compute.conf:

[DEFAULT]

compute_driver=libvirt.LibvirtDriver

 

[libvirt]

disk_cachemodes ="file=writeback"

说明:

http://blog.csdn.net/wsfdl/article/details/41980055

kvm 支持多种虚拟机多种 IO Cache 方式:writeback, none, writethrough 等。性能上:writeback > none > writethrough,安全上 writeback < none < writethrough

1.2 qemu中aio

编译时增加--enable-linux-aio

功能:进行异步IO操作,减少IO请求次数,提高IO的效率。

1.3 qemu使用virtio_blk

功能:提高块IO性能

原理:virtio-blk-data-plane是在原来virt-blk的基础上,通过给每个io device创建一个专门的线程来负责设备的io操作,目的是允许不同设备的IO能够并发的进行。由于每个io设备的io都由单独的线程来处理,一方面,减少了多个io设备之间的同步问题,另一方面,减少了io操作与qemu主进程之间的同步。另外,io线程采用了io eventfd/irqfd机制,使得io处理与guest os的执行解耦,充分利用了host os 的AIO,因此,极大的提高了guest osio性能。

 

设置前:

file=/var/lib/nova/instances/a9afc9bb-8ac8-4050-b10e-2ea0c7e9a859/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none

设置后:

从虚拟机对应的xml文件来看,是已经使用virtio的:

    <disk type='file' device='disk'>

      <driver name='qemu' type='qcow2'cache='writeback'/>

      <sourcefile='/var/lib/nova/instances/2cbbcc2a-dcbc-422e-8044-8722d6e9ba6f/disk'/>

      <target dev='vda' bus='virtio'/>

      <address type='pci' domain='0x0000'bus='0x00' slot='0x04' function='0x0'/>

    </disk>

1.4  CPU优化:配置项

我们目前的CPU配置:

-cpuSandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme-m 16384 -realtime mlock=off

-smp 8,sockets=2,cores=4,threads=1

 

配置CPU的线程数

-smpn[,maxcpus=cpus][,cores=cores][,threads=threads][,sockets=sockets]

n 指逻辑CPU数量

maxcpus 最大可能使用的CPU数量,适用于热插拔

sockets CPUsocket数量

cores 每个CPU socket上的cores数量

threads 每个CPU CORE的线程数

n=sockets*cores*threads

1.5 CPU优化:CPU绑定

可以解决生产环境CPU利用率严重不平均的问题。Qemu可以进行相关操作。

1.6         CPU优化:CPU采用NUMA架构

Qemu中可以进行相关配置。采用NUMA操作,每个CPU有自己的存储器,访问自己的存储器比访问别的存储器快很多,速度相差10~100倍。使用NUMA调优的目标就是让处理器尽量访问自己的存储器,以提高处理速度。

1.7 内存优化:采用巨型页(透明巨型页)

http://book.51cto.com/art/201509/490483.htm

采用巨型页可以提升内存的分配效率,提升系统性能。巨型页可以手工配置,也可以使用透明巨型页技术。

 

使用透明巨页内存的好处:

可以使用swap,内存页默认大小是2MB,需要使用swap的时候,内存被分割为4KB。

对用户透明,不需要用户做特殊配置。

不需要root权限。

不需要依赖某种库文件。

 

1.8 KSM技术(测试可用,生产慎用)

http://blog.csdn.net/summer_liuwei/article/details/6013255

可以合并相同内存页面,节省出更多的内存。

 

1.9 配置内存气球(virtio_ballon)

http://blog.chinaunix.net/uid-26000137-id-3725174.html

优点:内存可以超用

1.10 EPT

http://blog.csdn.net/beginning1126/article/details/41983547

intel提供了EPT技术,将两次地址转换变成了一次。这个EPT技术是在bios中,随着VT技术开启一起开启的。

 

2. 软件调优之qemu源码

2.1 block/virtio层的优化/最新代码合入(到最新版本中间做了哪些优化)

官方代码合入,难度小,风险小。可作为中期/短期任务来做。

主要优化代码存在如下目录:

qemu/block

qemu/hw/block

qemu/hw/block/dataplane

qemu/hw/virtio

其他可以暂时不动

优化方向:

要么直接用最新版本,要么合入和最新版本的差异。

可以看到,每一次主版本号之间,对block设备和virtio的修改都是非常大的,另外pcie部分也都有不少修改和优化。另外也会根据intel出的新架构来支持最新的CPU型号和架构。

1.      对比最新版本的block部分的改动,apt-get的目前还是2.2.0版本的qemu,最新版本为2.6.0-rc4

2.2.0~2.6.0版本的改动:

2.2.0为2014年下半年的版本

中间版本的修改:

http://wiki.qemu.org/ChangeLog/2.3

12.3的修改(block部分):

22.4.1部分的修改

http://wiki.qemu.org/ChangeLog/2.4

(3)2.5.1的优化

http://wiki.qemu.org/ChangeLog/2.5

(4)2.6.0的优化

http://wiki.qemu.org/ChangeLog/2.6#virtio

 

2.2 自研部分代码,针对性能优化算法

可能开源的考虑比较多,我们可以根据特殊需求,牺牲其他方面,针对代码进行修改。

这部分难度和风险稍大,需要时间也会长一些,需要对代码有深入的理解。

这里可作为长期任务来做。

可以优先优化的部分:

qemu/block

qemu/hw/block

qemu/hw/block/dataplane

qemu/hw/virtio

 

3. 软件优化之kvm驱动

Kvm可以看做内核代码的一部分,实际上就是内核中的一个驱动。但一般都单独将这个驱动拿出来进行重点修改与优化。

3.1 kvm驱动的优化-合入官方修改(kernel中)

我们使用的内核是:

root@ubuntu:/etc/lvm# uname -a

Linux ubuntu 3.13.0-68-generic #111-UbuntuSMP Fri Nov 6 18:17:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

这个应该已经用了两年,最新的版本是linux-4.5,中间差了3.15~3.19,4.0~4.5.2,十几个大版本,上百个小版本。

 

建议拿最新的内核和驱动来用,或者将官方内核或者kvm驱动部分的代码合入。

替换新版本最快,风险也比较小。

合入也可以做为中期或短期任务。

 

3.2 kvm驱动优化-自研优化(kernel中)

对io、block部分进行优化或定制。

可以

难度稍大,可作为长期任务。

可以研究/合入的部分:

Linux/virt/kvm

Linux/arch/x86/kvm (kvm-intel.ko、kvm.ko)

 

另外,kvm官方有一套单独的代码,也可以看下有何不同,应该代码更新,因为内核合入肯定会落后kvm官方的代码,才敢合入内核。

3.3 kvm官方驱动(非kernel)的对比与使用

Kvm官方的代码肯定先于内核的修改,所以尽可能用最新的kvm官方的代码。

Kvm项目地址:

http://www.linux-kvm.org/page/Main_Page

git:

git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git

http://www.linux-kvm.org/page/Downloads

KVM kernel modules are part of the Linux kernel package

Userspace tools are usually called "qemu-kvm" or "kvm"

Linux guest drivers are part of the Linux kernel package

Windows guest drivers are available here

我们通常使用的就是KVM kernel modules

这里我下载了一下:git://git.kernel.org/pub/scm/virt/kvm/kvm.git

其实就是一套kernel的代码,不如直接用release的kernel代码。

4. 软件优化之服务器kernel

同样:采用最新的内核,或者合入新增的代码,或者根据需要合入新增的部分代码。

合入代码可以作为中短期任务,自研代码可以作为长期任务。

4.1 内核:block层的优化

方向:

linux/block/

linux/drivers/block/virtio_blk.c

4.2 内核:SCSI层优化

方向:linux/drivers/scsi

4.3 内核:文件系统级优化(ext4、ceph)

方向:

主要对linux/fs/ext4部分,合入或优化,如果我们使用的是ext4文件系统

目前ceph的fs部分应该用不到,挂载的话才会用到。

目前ceph的fs部分应该用不到,挂载的话才会用到。

4.4 内核:virtio驱动

方向:linux/drivers/virtio

 

4.5 dm设备优化(RAID、DeviceMapper)

代码:linux/drivers/md

4.6 淘宝内核组的优化

淘宝内核组对文件系统、IO部分做了很多优化,我们也可以移植一下,另外也可以看一下他们写的内核月报,很有参考价值。

kernel.taobao.org/

5     Cache方案(软硬件结合,SSD做缓存,分层存储方案)

这种分层存储的方案,是云计算必备,性价比也非常高。既可以满足容量,又可以满足性能,成本又不会太高,每台服务器加1~2块SSD即可。

5.1 flashcache + SSD

Flashcache是一款针对linux系统的块设备缓存工具,可以编译为内核模块,使用Device Mappoer实现。原理是用高速设备做缓存,把数据先缓存到高速设备上,到一定阈值,再写到低速设备上。

参考《深度实践KVM》5.5.3(page117)

5.2 dm-cache + SSD

Dm-cache是一个device-mapper级别的,用高速设备做低速存储设备缓存的解决方案,主要是用SSD做机械硬盘的缓存,达到容量和性能的平衡。

 

5.3 LVM cache

Lvm cache是在dm-cache的基础上基于lvm做配置,也是通过SSD做分层存储的方案。

6     Openstack中的配置优化

这个参考官方的配置文档来重点研究:

config-reference-icehouse.pdf

或者看网页版本,最好下载个pdf版。

7.   硬件/整体方案

7.1              SSD做缓存,分层存储方案

SSD + 软件flashcache驱动,参考5.1,做分层存储方案,既满足容量又满足性能,性价比非常高。比单纯使用

7.2 RAID

RAID5利用率比较高,硬盘越多利用率越高

SSD缓存+RAID5+单盘热备

RAID5/RAID10可以多盘并发IO,也可以在一定程度上提升存储性能

7.3 (SSD+flashcache驱动)缓存盘+ RAID方案

分层存储方案:

Cache 内存缓存

SSD + flashcache驱动 做缓存盘,可用单SSD,也可以采用多SSD组RAID

RAID10/RAID5 底层磁盘

 

Xuyao:

优势:

1,性能很不错,可以大幅度提升用户体验,而且缓存写在磁盘中,即使掉电缓存中的数据也能继续使用。

劣势:

1,缓存无法热插拔。无法动态增减ssd缓存。想要增加ssd就要将原来的磁盘格式化。

2,在共享存储应用场景中,如果使用本地的ssd做缓存,这个缓存无法在主机之间同步缓存。

      这就造成一个问题,如果存储是共享的,不同的计算节点之间无法共享缓存,读取到的硬盘数据内容就不同。

 

ceph中的有一个cache tile,按照文档里面说的,应该是将ssd作为缓存,然后共享出来,这样即使是共享存储的应用场景应该也能用。

 

针对共享存储的应对策略:

可能这种做法不是特别好,但可以解决该问题

compute节点和storage节点绑定,部署在同一台服务器上,然后修改nova的调度器,只调度在本compute节点。

7.4 后端采用ceph rbd存储时的SSD cache方案

参考http://blog.chinaunix.net/uid-535090-id-4815846.html

 

7.4.1 使用SSD作为ceph 的日志盘

Ceph使用日志来提高性能及保证数据一致性。使用快速的SSD作为OSD的日志盘来提高集群性能是SSD应用于Ceph环境中最常见的使用场景。

由于OSD日志读写的特点,在选择SSD盘时,除了关注IOPS性能外,要重点注意以下3个方面:

1)写密集场景

OSD日志是大量小数据块、随机IO写操作。选购SSD作为日志盘,需要重点关注随机、小块数据、写操作的吞吐量及IOPS;当一块SSD作为多个OSD的日志盘时,因为涉及到多个OSD同时往SSD盘写数据,要重点关注顺序写的带宽。

2)分区对齐

在对SSD分区时,使用Parted进行分区并保证4KB分区对齐,避免分区不当带来的性能下降。

3)O_DIRECT和O_DSYNC写模式及写缓存

由Ceph源码可知(ceph/src/os/FileJournal.cc),OSD在写日志文件时,使用的flags是:

flags |= O_DIRECT | O_DSYNC

O_DIRECT表示不使用Linux内核Page Cache;O_DSYNC表示数据在写入到磁盘后才返回。

由于磁盘控制器也同样存在缓存,而Linux操作系统不负责管理设备缓存,O_DSYNC在到达磁盘控制器缓存之后会立即返回给调用者,并无法保证数据真正写入到磁盘中,Ceph致力于数据的安全性,对用来作为日志盘的设备,应禁用其写缓存。(# hdparm -W 0 /dev/hda 0)

7.4.2SSD作为Ceph CacheTiering技术中的Cache层

Cache Tiering的基本思想是冷热数据分离,用相对快速/昂贵的存储设备如SSD盘,组成一个Pool来作为Cache层,后端用相对慢速/廉价的设备来组建冷数据存储池。

    Ceph Cache Tiering Agent处理缓存层和存储层的数据的自动迁移,对客户端透明操作透明。

 


你可能感兴趣的:(存储性能优化方向整理)