|
三、在XEN环境中如何实施网络存储
熟悉XEN当前架构的朋友一定知道VM的I/O请求是通过device model (qemu)或者前后端虚拟设备转到domain0处理的。Dom0的处理方式要么将I/O请求存在于本地的镜像文件中(如raw格式、qcow格式、vhd格式镜像)、块设备中(如physical磁盘)、要么存再于远程网络存储中(如nbd、nfs、iscsi等)。 我们推敲一下，看如何将我们理想的网络存储集成进来呢。 假设我们使用前后端方式，且采用目前流行的blktap2用户态后端驱动 —— qemu方式也大同小异，这里不在赘述。 方式 1 —— blktap + tapdisk + 虚拟块设备(DOM0中) + 用户态 I/O请求转发精灵(DOM0中) + 远程存储系统。 显然这里使用的是”physical 设备”方式挂载了VM磁盘镜像，因此“dom0加载虚拟块 设备”目的是模拟一个假的”physical设备”, 这个虚拟块设备作用仅仅是将写入的I/O请求，截获下来，然后转发(把数据从内核倒腾到用户空间)到dom0上本地运行的“I/O请求转发精灵”，最后再由转发精灵真正实现写到远程存储系统 —— 之所以在用户态使用转发精灵写远程系统是因为还是在用户态开发调试来的方便，况且多数远程系统也只提供用户空间的访问API。 方式 2 —— blktap + tapdisk (block-device api) + 远程存储系统。 显然方式1如果不经过内核态这层(这层实在是多余的)转发数据，而是经tapdisk直接将数据从用户空间发送到远程存储系统岂不妙斋。有兴趣的话试验一下qemu-nbd,借鉴其思路在tapdisk里实现一个tapdisk-nbd就成啦。 无论方式1还是方式2都只能使采用挂在“physical 设备”的方式，如果要使用目前颇为流向的镜像文件——如vhd格式的磁盘镜像—— 方式又该如何做呢? 挂载镜像文件和挂载设备最大不同在于：镜像文件属于文件范畴，因此需要存在于文件系统之上。那么好吧，我们想法子在整个文件系统放上去! 方式 3 blktap + tapdisk + 虚拟块设备(DOM0中) + filesystem (虚拟块设备中) + disk image + I/O请求转发精灵(DOM0中) + 远程存储系统 好长呀!但说白了就是在方式1基础上——虚拟块设备上在去创建一个文件系统(ext2呀3呀，随你啦，只要支持dio就可——VHD为了安全使用DIO方式操作文件)，然后在其上在创建景象image文件即可。 方式 4 blktap + tapdisk (posix-like api / libaio-like api ) + 远程存储系统 不用说拉，方式4就是去掉数据和内核层的通讯，和方式2一样直接从tapdisk用户态直接将请求发送到远程存储系统。不过因为tapdisk操作vhd是调用posix文件系统的访问接口(如open文件，write文件)，或者是调用libaio的异步请求(如sumbmit_io等)，因此远程存储系统就需要提供posix-like api 或者是libaio-like api。如果一切具备，那么我个人认为这便是最理想的集成方式。(如图中红线所示) 总结 ： 这次先唠叨这么多把，存储的基本需求算是梳理了一便。其他高级需求，比如存储上的基于内容的去重功能;文件的内拷贝功能(拷贝过程数据不再经过VM客户端，直接走内部存储节点直接的链路)等我现在也还没想清楚怎么搞，等我想清楚了再和大家分享吧。
|
|
|
