首页 > 代码库 > 新存储结构(thin lvm)下flashcache效率测试

新存储结构(thin lvm)下flashcache效率测试

flashcache有两种安装方式:

1.普通的编译安装,目前似乎不支持3.x内核

2.动态内核模块编译(DMKS),这种方式相对简单,而且支持3.x高版本内核。

 

普通编译安装

1.首先安装必要的工具:
编译flashcache的时候需要内核头文件,这里要注意的是:

如果直接使用 yum install kernel-devel 安装的话,可能会导致 内核版本 和 内核头文件 版本不一致,在编译flashcache的时候就会出错。比如,centos6.3初装后内核版本是2.6.32-279.el6.x86_64,而直接按以上命令会安装成2.6.32-279.9.1.el6版本的头文件。

有三种方法解决这个问题:

i). 更新内核:yum update kernel(需要重启系统生效!推荐!)
ii). 直接安装和当前内核版本对应的头文件包:yum install kernel-devel-$(uname -r) (无需重启)
iii). 编译flashcache时,将头文件路径作为参数传递进去(具体看flashcache说明文档)

接下来安装各种编译软件:

yum install -y gcc gcc-c++ make autoconf cmake

 

安装git(flashcache托管在git上):

yum install -y git

 

2.获取flashcache源文件

git clone https://github.com/facebook/flashcache.git

 

3.编译安装

cd flashcache
make
make install

 

4.安装flashcache统计脚本(可选)

复制 utils/flashstat 文件到系统程序(/usr/bin,/usr/local/bin等)目录以便查看flashcache读写情况。

 

DKMS安装

dkms包是放在rpmforge库里,所以首先我们需要导入 rpmforge 库:

rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
rpm -i http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

yum -y install dkms

然后下载 flashcache 源文件(见面上)并进入源文件目录,执行编译安装:

make -f Makefile.dkms
make install

flashcache使用

flashcache是一种将ssd作为缓存,普通硬盘作为后备,然后将他们合二为一作为单个整体来使用的技术。

 

1.选择一个未挂载的普通盘(或分区)作为后备盘。比如,/dev/sdb

注:必须保证选中的分区没有在使用中,并且未挂载在任何地方。

 

2.选择ssd盘,比如,/dev/sdc 作为缓存。

注:必须保证选中的ssd分区没有在使用中,并且未挂载在任何地方。

 

3.创建flashcache盘:

flashcache_create -p back flashcache /dev/sdc /dev/sdb
 
上述命令中的flashcache是盘的名字,可以任意选取。

注:这里的名字对《flashcahce安装》中所说的flashstat脚本有影响,需要将该脚本中的cachedev替换成这里的名字)

 

-p 后面跟缓存的写模式,back是指回写式(write-back),与 直写式(write-through) 对应

 

4.为flashcache盘创建文件系统:

mkfs.ext4 /dev/mapper/flashcache
(这里使用ext4文件系统以达到更好的ssd支持。)

 

5.挂载创建好的flashcache盘:

mount -o discard,noatime,nobarrier /dev/mapper/flashcache /data
-o 后面接各种文件系统参数,这里的 discard,noatime,nobarrier都是为了增强flashcache盘的IO性能,虽然对文件系统的健壮性有一定损害。

 

6.重启系统后的操作:

默认情况下,开机是不会自动生成flashcache设备的。用

ls /dev/mapper 可以看到,没有/dev/mapper/flashcache这个设备。

这时候就要用到flashcache_load命令了:

flashcache_load /dev/sdc

然后,flashcache设备就重新生成。(注:不需要再次flashcache_create)

接下来就挂载使用了。

 

7. 添加启动脚本(可选):

a) 复制flashcache源文件目录下的 utils/flashcache 脚本到 /etc/init.d 目录。

b) 加入启动项目:

chkconfig --add /etc/init.d/flashcache

 

另外,要注意的是一定要修改该脚本中的部分参数才能正常生效!

 

比如:

SSD_DISK=/dev/sdb
BACKEND_DISK=/dev/sda4
CACHEDEV_NAME=flashcache
MOUNTPOINT=/data
FLASHCACHE_NAME=sdb+sda4

 

比较麻烦点的是FLASHCACHE_NAME这个变量的值,可以通过
sysctl -a | grep flashcache
判断出来。

 

然后是 挂载文件系统的参数(discard,noatime,nobarrier), 需要自行添加到脚本的相应位置。

比如, 找到一行:

/bin/mount /dev/mapper/$CACHEDEV_NAME $MOUNTPOINT
修改成:
/bin/mount -o discard,noatime,nobarrier /dev/mapper/$CACHEDEV_NAME $MOUNTPOINT


flashcache性能测试

对新的存储结构做了一些测试。

 

以下测试结果有几点需要特别注意:

1)测试工具只是简单的 dd,都是连续读写,

2)测试是在文件系统上进行,不是裸设备

3)测试的是吞吐量(thoroughput),而不是IOPS!

4)整个物理机上只有一个DomU。这意味着瘦卷的块在物理盘上的分布是比较集中的。真实的生产环境下,瘦卷块位置通常会比较分散,因此读写速度应该会有一定下降。

5)在下面的flashcache测试中,ssd物理盘空间是非常充足的,仅使用了 5% 左右。但实际生产环境中,ssd空间使用率一般会达到70%以上,这时候ssd写性能通常会有较明显下降。

 

表1. 瘦卷和普通卷速度对比(底层是普通磁盘做物理卷)

 

瘦卷(thin lvm)

普通卷(lvm)

dom0,读350 ~ 360 MB/s390 ~ 400 MB/s
dom0,写250 ~ 260 MB/s399 ~ 409 MB/s
domU,读344 ~ 350 MB/s390 ~ 400 MB/s
domU,写350 ~ 370 MB/s[1]390 ~ 400MB/s

[1] 以瘦卷作为domU的磁盘时,在domU中对于已经存在的文件的覆盖写速度下降很明显:约为 100 ~ 130 MB/s。 普通卷无此现象。

 

表2. flashcache测试 (ssd缓存为10GB,后备盘为普通逻辑卷)

 

flashcache做在dom0中

flashcache做在domU中

flashcach做在dom0,并挂载到 domU 中

第一次写[1]302 MB/s341 MB/s165 MB/s [2]
第二次写183 MB/s293 MB/s166 MB/s
第三次写206 MB/s265 MB/s169 MB/s
第四次写189 MB/s257 MB/s169 MB/s
第一次读[1]160 MB/s150 MB/s ~ 170MB/s168 MB/s [2]
后续读370 MB/s[3]231 MB/s ~ 280 MB/s274 MB/s

[1] 这里说的“第一次”是指 ssd 缓存为空 或者说 刚做完 flashcache 的情况。

[2] 看起来,似乎 flashcache 做好后挂到 domU,第一次和后续写是没有区别的。

[3] 通过观察可以发现不论在domU中还是dom0中,flashcache的后续读都是由ssd缓存来满足的。但是似乎domU无法使得ssd盘满载,所以导致后续读在dom0上要快于domU。

 

根据上表结果推测

1.第一次写全部由ssd缓存住了,因此速度实际上是 ssd 的写速度。后面的第二,第三次测试时,由于ssd缓存已经满了,必须先清空部分缓存,回写到普通盘上,然后再将新数据写入清空的那缓存部分,所以速度有所下降。这一点可以通过在 dom0 观察 iostat 数据得到印证。

注:上述flashcache测试中,由于事先没考虑周全,所以测试是对一个 10g 多一点 的文件做读写操作,而 ssd 缓存实际上只有 10g 差点。导致io有一小部分会做 读ssd缓存->写入hdd->再写ssd 的过程。所以结果不是特别准确(比实际稍微低一点)。

 

2.第一次读需要首先读取普通盘上的数据,然后再写入ssd中。而且,flashcache会自动将所有读写操作都分解为4k的块,这样导致ssd的写入吞吐量较低,因此总体速度明显比较慢。而后续的读直接由缓存满足,因此相当快。


新存储结构(thin lvm)下flashcache效率测试