xen 不同后端存储方案的性能对比
概述
在xen平台下,一般使用文件来模拟一个磁盘。在xen中使用文件来模拟磁盘有3种方式,
- blkback 直接操作
- blktap2 直接将文件映射为一个裸块设备,这样vm可以直接用phy的方式进行文件访问。
- qdisk 使用qemu来将文件模拟成一个磁盘设备。
blkback
Blkback的数据交互流程如图1所示,在Domain U 中,用户态的应用程序发出读写系
统调用,在Domain U的操作系统中的普通读写请求,被块设备前端封装成Xen格式,接着
85 通过设备通道传送给块设备后端,块设备后端将读写请求经过一系列处理后,转化为一个或
多个bio结构,submit_bio提交。前后端通过事件通道(Event Chanel)、I/O 环(I/O Ring)
以及授权表(Grant Table)完成通信和数据交互。从Domain U的角度看,块设备可以是sda、
had或者xvda 等真实设备,只是读写请求被前端截获并转交给了Domain 0。从Domain 0中
操作系统的角度看,bio最后进入 I/O 调度层,Domain U的磁盘对应着相应的磁盘镜像。
图 2 是读写请求进入在块设备后端中的详细处理过程及函数。 RING_GET_REQUEST
从I/O环中取出块设备前端发送过来的读写请求(blkif_request格式),在dispatch_rw_block_io
中将blkif_request转化成pending_req和 phys_req,最后生成一个或多个通用的bio结构,之
后的处理流程与 Linux 读写系统调用相同:bio 进入 I/O 调度层最后由真实驱动完成读写。
同时,由end_block_io_op生成响应(blkif_response)。
blkback进行文件读写
blktap2
blktap2设备比较类似于loop设备,都是通过将文件映射成一个块设备来供虚拟机使用。 在启动时,需要在xl文件中配置为
disk = ['tap2:aio:file.vhd,xvda1,w']
将文件file.vhd 模拟成一个块设备/dev/xen/blktap-2/tapdev0
IO请求从blkfront到blkback之后,通过blktap2驱动交到user space的tapdisk2进程的地址空间。然后由tapdisk2进行文件的读写。
Blktap2的数据交互流程如图2所示,DomainU中流程与blkback类似,但domain 0中
用户态的功能更加丰富了,并将原本处于内核态的部分功能移至用户态。与blkback不同是,
blktap2从设备通道中取出Domain U发送过来的读写请求(blkif_request格式),交给处于
105 用户态的 tapdisk,tapdisk 要通过对应的磁盘格式的驱动来区分磁盘镜像的类型,并且可以
选择异步IO 或者典型 IO 两种不同方式,对读写请求和数据进行检查,封装成tio结构,对
tio进行合并优化后,通过系统调用提交 tio。Blktap2 与 tapdisk通过共享内存的方式交换数
据的权限,与设备/dev/xen/blktapX 对应。blktapctr 通过设备 blktap0 管理虚拟磁盘。blktap
仍需要blkback的帮助, blktap2以及最新的blktap3已经可以独立承担块设备后端的功能
qdisk
qdisk设备是通过qemu来把文件模拟成磁盘设备。启动时在xl文件中配置为
disk = ['tap:qcow:file.vhd,xvda1,w']
IO请求从blkfront发出后,直接发送到了进程空间中qemu进程,然后由qemu进程对文件进行读写。 这样明显的减少了io路径,提高了虚拟化磁盘的性能。
注意:blktap3采用了和qdisk几乎一致的架构,用来优化blktap2。在4.4版本中,blktap3还属于开发阶段,所以这里没有提及。
性能比较
了解了2种不同访问模式原理上的区别,我对两种存储虚拟化方式进行了测试 测试平台:
Host | cpu | Intel(R) Xeon(R) CPU E5645 @ 2.40GHz |
Memory | 44G | |
硬盘 | SATA | |
Hypervisor | Xen | 4.4.1 |
OS | suse11 sp3 | |
Guest | CPU | 4 |
Memory | 4G | |
OS | windows xp | |
磁盘格式 | vhd |
测试结果:
blktap2 | qdisk | |
---|---|---|
Total I/Os per Send | 69.04 | 78.20 |
Total MBs per Send | 1.08 | 1.22 |
Average I/O Response Time(ms) | 14.48 | 12.7855 |
Maxinum I/O Response Time(ms) | 82.48 | 93.8746 |
可以看出在qdisk模式在 IOPS、吞吐量、延迟方面均优于Blktap2。
转自:here
我在自己的设备上测试,结果与这篇文章所述一致: qdisk 的方式性能好于 blktap 的方式;而且少了一个tapdisk进程,只需要qemu-dm进程就够了。
qdisk的模式有两块关键代码: linux_gnttab_grant_map 函数,用于映射blkif protocol需要的内存; xen_blkdev_ops 结构体,实现了对img文件的操作。 上述代码都实现在qemu-xen-traditional代码里,最终编译为qemu-dm程序
xen社区负责存储性能优化的工程师的PDF:Storage-Performance-PDF.pdf
基于 Xen PVHVM 虚拟块设备的数据追踪及测试 : pvhvm块设备的数据追踪和测试