本文探讨了基于XEN的分布式虚拟块存储设计方案，利用blktap虚拟块设备框架结合HDFS和Hbase实现虚拟机数据的安全存储，旨在提高数据可靠性和负载均衡。
说明：这篇文章非常有借鉴意义！要非常深入去查一下资料！
1. 引言
随着互联网的发展、互联网用户的增加、互联网中的数据也急剧膨胀。而为了满足广大用户的需求，互联网企业需要去保存与挖掘这些数据。如此海量的数据也 极大的增加了各大互联网企业的运营压力。他们需要建立一个规模极大的集群来服务他们的应用。据报道，世界互联网巨头Google 已经拥有超过40 万台服务器，而在国内，盛大、阿里巴巴、QQ 等国内互联网巨头的线上服务器都已经开始超过2 万台。
为了降低企业的运营成本，基于虚拟机的云计算技术也得到很好的发展，也就是说将这些服务器移植到更具可扩展性的虚拟机上。由于数据的重要性，存储的虚 拟化也很自然的成为了这些云计算技术的核心。为了保证虚拟机数据的安全性，本文创新性的提出来基于XEN的分布式虚拟块存储的设计，也就是将虚拟机的虚拟 块存储设备实现于分布式文件系统上。
在虚拟块设备的模拟上，本文采用的XEN 自带的blktap 这个虚拟块设备的。而在分布式文件系统以及分布式数据库上，本文选择了著名开源软件hadoop 中的HDFS 以及配套的Hbase。虚拟块设备会将所有的虚拟机数据存放到实现于HDFS 上的Hbase 上，以保证了数据的安全性。
2.背景技术概述
2.1 Xen blktap 原理分析
Blktap 是XEN 提供给我们的一套实现虚拟块设备的框架，它是运行在用户控件的，所以他能给我们提供和平常一样的文件I/O 操作接口，该特性也决定了Blktap 能使我们的块存储设备系统具有更好的可兼容性。因此它可以使我们更加轻松的去实现我们的fileSystem，例如vhd、qcow 等，它使我们摆脱了复杂而又易错的kernel 程序。当然和普通的后端驱动类似，blktap 也需要一个内核模块运行在Dom-0 上。现在我们来描述下blktap 的工作流程[1]。
描述了 blktap 的基本工作流程，当xen 启动的时候，他会先启动blktapctl，它是一个后台程序。当我们启动虚拟机的时候就会通过xenBus 这个通道把需要的虚拟块存储设备注册到blktapctrl 中，该注册过程会创建两个命名管道以及一个字符设备，这两个命名管道将被用于字符设备与图中tapdisk 之间的通信。而这个字符设备会利用mmap 这个系统调用把fe_ring 与共享内存映射起来。这时tapdisk 主要用于打开镜像文件以及向blktapctrl 发送镜像的基本信息，比如镜像的大小等。当tapdisk 初始化好的时候，它会开始监听上面创建好的两个命名管道，并获取从前端（FrontEnd）发送过来的数据。这里的的通信和普通的前后端通信方式一样，采 用的共享内存事件通道来实现的，这种简单的通信方式也大大提高了块设备的性能[2,3]。
2.2 HDFS以及Hbase概述
HDFS 是著名开源分布式软件Hadoop 的分布式文件系统，目前除了Google 之外，几乎所有的大型互联网企业都在使用HDFS。比如facebook、百度、腾讯、yahoo 等。他们在使用它作为底层分布式文件系统的同时，也会积极的去升级软件,所以HDFS 在近几年也得到了飞速的发展。
描述了HDFS的总体框架，从图中我们可以看出，HDFS 采用了主/从结构的。这种模式下，读是从多点读的，当写的时候，需要向集群中所有的副本写入数据。比如图中读value1 的时候，可以随便找一台拥有value1 的数据，而当写入value3 的时候，需要想所有的副本机器写入value3，也就是图中的三台机器。这样一来就加快了数据读取速度并保证的数据的安全，就算某一台机器挂了，数据依然 健在。另外在HDFS 中，一个集群有一个名字节点，也就是主控服务器，它负责从管理系统的命名空间，也就是我们所说的元数据（Metadata）。从图中的读写流程可以看出， 所有的数据流都不会经过它，它仅仅是一个全局的数据管理者，主要任务有管理数据副本数量、维护数据结构的心跳等。这种设计将可以大大提高了 NameNodes 的健壮性[4]。
HBase 是与HDFS 配套的开源分布式数据库，它所有的功能基本是模仿的bigTable,这里我们不详细讲解它的特性了。和普通的key-value 系统一样，Hbase 都会提供以下三个关键接口：
1.get(key)：获取该key 对于的value。
2.put(key, value)：插入一条数据，如果该数据以及存在，则更新之。
3.delete(key)：删除这个key-value 记录。
3.分布式虚拟块存储设计
3.1 分布式虚拟块存储框架设计
从第二章的基本原理描述，我们可以简单的认为blktap 就是截获虚拟机磁盘的读/写操作，磁盘的读写就是根据相应的扇区号读取该扇区的数据，而在blktap 里面我们会将Dom-U所要访问虚拟磁盘的扇区号转化为物理磁盘的扇区号。为了便于理解，我们把第二章中那个blktap 框架图简化为下面。从我们可以很清楚的发现，blktap 就是截获虚拟机读/写的扇区号，并将该扇区号转化为物理磁盘的扇区号[5,6]。
传统的虚拟块存储设备都是将虚拟机中的扇区号重新定位到物理设备上，由于物理设备是基于单机的，所以我们无法保证数据的可靠性。现在我们假设将虚拟机读写扇区号重新定位到一个分布文件系统中，那么我们就可以利用分布式文件系统的特点来解决数据的可靠性。
我们知道在磁盘文件数据读写其实就是根据一个扇区号读取一个该扇区中的内容，这里的扇区号和数据都是一一对应的，所以这个的过程也就是从某一个key 里面获取相应的value。现在我们将物理磁盘的扇区号映射为我们key-value 系统中的key，而物理磁盘数据映射到我们key-value 系统中的value。这样一来，我们所有的虚拟机数据都将会被存放到key-value 系统中，其实就是存放在分布式文件系统中。经过这层转换以后，上面这个就变成了下面这个了。从我们可以看到，所有的数据都被以key-value 的形式存放到分布式文件系统中，这样意味着虚拟机里面的运行数据是分布在集群中不同的机器中。所以分布式虚拟块存储相比传统虚拟块存储而言主要有以下几个 优点：
1.数据可靠性：从我们可以看到，图中的虚拟机目前拥有 value1、value2、value3、value4 这四个块数据，他们分别被分布到P1、P2、P3 这三台服务器上，而且每一块数据都是冗余备份的。现在我们假设P1 宕机了，这也意味这P1 上的value1、value2、value3、value4这四块数据丢失了，但是这些数据在其他物理机依然存在，所以这个虚拟依然能正常的运行。如果 这个集群达到一定规模以后，任何一小批机器的宕机都不会造成虚拟机的宕机以及数据的丢失[7]。
2.负载均衡：由于数据是分布不同的机上的，也就是所有的磁盘读写负载会被平分到不同的机器上，这样一来就避免了某几台服务器磁盘读写压力过大的情况了，也达到了充分利用资源的效果。
3.效率较高：由于数据被分布在不同的服务器上，所以所有的数据读写操作都是多点对一点，这类似于P2P，在集群规模足够大的时候，磁盘读写的速度会趋近于网络的速度。而从目前情况来看，网络的速度是远远高于硬盘速度的。
4.服务可靠性高：由于虚拟机的磁盘数据是被存放到分布式文件系统中的，该特点也大大降低了虚拟机在线迁移的难度。有了在线迁移以后，虚拟机的所提供的服务可靠性就得到了大大的提高。
3.2 分布式虚拟块存储详细设计
上面一节我们描述了分布式虚拟块设备的框架设计，这一节我们将分布式虚拟块设备展开详细的设计。从上面Hbase 分布式特性得知，Hbase 会将数据均匀的分布在集群中不同的机器。我们现在假设集群中虚拟机的磁盘数据就是Hbase 的一张表，这张表将会被切分到集群中不同的服务器中，在Hbase中，这些块被称为Hregion，也就是一台台物理机，这个Hregion往往由 tableName+sKeys /eKeys，他的意思就是：表名为tableName ，主键为到sKeys 到eKeys 的数据都将会被存放到当前这个Hregion 上。表3-3 就是根据sKeys 和eKeys 切分出来的Hregion， 例如现在某一个 key 位于2000 到2999 之间，那么该key 对应的value 将会被存放到三号Hregion 中。
另外我们从表1 中可以看出key 的所在的Hregion 是由key 的高位来决定，所以为了将我们的数据均匀的分布到不同的机器中，我们就需要去控制key 的高位数据。为了提高分布式虚拟块存储的效率，我们的key 设计主要有以下几个原则：
1.数据应该某种程度上的打散，也就是将数据均匀的分布在不同机器上，这也是分布式数据存放的要求。他可以提高读取数据的效率以及不同服务器的I/O 负责均衡。为了实现满足，我们需要控制key 的高位。
2.数据的存放应该具有一定的连续性，因为我们读数据一般都是读去N 个扇区的，所以我们要将一些连续的扇区存放到一台物理机上，这样可以提高I/O 的效率。为了满足这个要求，我们需要控制key 的低位。
根据上面的原则，我们将key 分为HregionId、diskId、CheckpointId、sectorId 这四个值，对于HregionId 标识了该数据所存放的Hregion，这个值的设计将会影响到数据是否被均匀打散。DiskId 这个值是虚拟块设备的编号，我们可以理解为虚拟机的硬盘，这个值是全局唯一的，因为虚拟机的硬盘是不允许共享的。CheckpointId 这个主要用户做快照的，本文并不会对他进行详细的分析，sectorId 就是虚拟磁盘的扇区号，因此他对于每一个diskId 是唯一的，这个扇区号就是从虚拟机前端驱动传过来的。为了满足上面讲的两条原则，我们的HregionId 必须是根据diskId、CheckpointId、sectorId 生成的，这样就可以保证了数据的均匀分布性。为了保证数据存放具有一定连续性的特征，在计算HregionId 的时候，我们需要对sectorId 进行处理，以保证一段扇区号的数据会被存放到某一个HregionId 中。
所以我们的 key 的组成部分应该是hregionId:diskId:CheckpointId:sectorId.这里我们规定他们长度分别20 位、32 位、32 位、64 位。从上面的各个字段的位数得知，我们这样的设计可以支持百万台物理机、2 的32 次方个虚拟块存储设备、而每一个虚拟块设备可支持2的64 次方再乘以512 字节的存储量。所以整个key 的范围应该是：
“00000:0000000000000000:00000000:0000000000000000”到“FFFFF:FFFFFFFFFFFFFFFF:FFFFFFFF:FFFFFFFFFFFFFFFF”
为了满足上面讲的两条规则，我们来讲讲hregionId 的生成原则：
1、为了满足分散的需求，hregionId 必须是根据diskId、checkpointId、sectorId 而生成的。
2、为了保证同一段sectors（包含n 个sector）有相同的hregionId，计算时，将sectorId右移log(n)位。
3、为了满足打散的需求，对于生成好的hregionId 再取散列。
4、为了提升计算速度，散列算法应当足够快。
4.性能评估
4.1 实验环境
实验机器配置如下：CPU:Intel(R) Xeon(R) CPU E5530 @ 2.40GHz 16 cores；内存：
24G；硬盘：SCSI 硬盘 6T；网卡：Broadcom Corporation NetXtreme II BCM5709 GigabitEthernet；集群网络：千兆网络。由于分布式原因，我们选了20 台同类型的服务器，分别装上XEN3.4.2，其内核版本为：2.6.31 内核。然后启动两台运行在以文件形式和分布式虚拟块存储系统之上的虚拟机，虚拟机的操作系统为redhat5.3。
4.2 三种模式磁盘读写速度比较
分别在两台虚拟机以及一台物理机执行：
time dd if=/dev/zero of=./test.img bs=1k count=1M
time dd if=./test.img of=/dev/zero
time dd if=./test.img of=./test1.img
其中第一条命令的意思是，将空设备的数据写入test.img，大小为1G，这里我们可以测试磁盘读速度，第二条命令是用来测试磁盘读速度，第三条命 令用于将test.img 的数据写入test2.img，我们用来测试磁盘读写能力。由于dd 这个命令是直接穿透cache 直接将数据数据写入硬盘的，所以该命令基本上能反映磁盘的物理读写性能。
从上面这个表我们可以看出，20 台机器集群的分布式文件虚拟块存储系统的性能能达到物理磁盘的一半左右。当然在集群规模扩大的时候，该速度还会具有较大的提升空间。而且35M 的磁盘读写速度基本上能满足互联网中%80 的服务。除了个别I/O 性能要求特别高的服务，比如大型数据库服务器等等。所以从本章的数据测试表明，本文所设计的分布式虚拟块存储系统能满足大部分服务要求，比如WEB 服务器，搜索引擎计算服务器、爬虫服务器等。但是对于一些I/O 性能要求特别高的服务，比如数据库，本文提出的设计方案是不适用的。
4. 总结与展望本
文通过研究XEN 提供的blktap 这套虚拟块设备框架，分析了它的基本原理。同时还简单的概述了HDFS、Hbase 这两款开源分布式软件，并将它们分布式特性应用到虚拟机中，从而大大提高了虚拟机数据的安全性。文章的最后也对虚拟块存储系统进行简单的性能测试，并以此 判断出分布式虚拟块存储系统的应用场景。同时本文所提出的方案还具有很多额外的研究价值。比如在分布式虚拟块存储系统中加入本次磁盘cache 以及内存cache，应该能较大幅度的提高虚拟块设备的效率以及稳定性。另外我们还可以在该系统上加入一些基于磁盘的高级特性，比如cow 、snapshot 等高级功能,这样就可以大大提升云平台的可扩展性。
1. 引言
随着互联网的发展、互联网用户的增加、互联网中的数据也急剧膨胀。而为了满足广大用户的需求，互联网企业需要去保存与挖掘这些数据。如此海量的数据也 极大的增加了各大互联网企业的运营压力。他们需要建立一个规模极大的集群来服务他们的应用。据报道，世界互联网巨头Google 已经拥有超过40 万台服务器，而在国内，盛大、阿里巴巴、QQ 等国内互联网巨头的线上服务器都已经开始超过2 万台。
为了降低企业的运营成本，基于虚拟机的云计算技术也得到很好的发展，也就是说将这些服务器移植到更具可扩展性的虚拟机上。由于数据的重要性，存储的虚 拟化也很自然的成为了这些云计算技术的核心。为了保证虚拟机数据的安全性，本文创新性的提出来基于XEN的分布式虚拟块存储的设计，也就是将虚拟机的虚拟 块存储设备实现于分布式文件系统上。
在虚拟块设备的模拟上，本文采用的XEN 自带的blktap 这个虚拟块设备的。而在分布式文件系统以及分布式数据库上，本文选择了著名开源软件hadoop 中的HDFS 以及配套的Hbase。虚拟块设备会将所有的虚拟机数据存放到实现于HDFS 上的Hbase 上，以保证了数据的安全性。
2.背景技术概述
2.1 Xen blktap 原理分析
Blktap 是XEN 提供给我们的一套实现虚拟块设备的框架，它是运行在用户控件的，所以他能给我们提供和平常一样的文件I/O 操作接口，该特性也决定了Blktap 能使我们的块存储设备系统具有更好的可兼容性。因此它可以使我们更加轻松的去实现我们的fileSystem，例如vhd、qcow 等，它使我们摆脱了复杂而又易错的kernel 程序。当然和普通的后端驱动类似，blktap 也需要一个内核模块运行在Dom-0 上。现在我们来描述下blktap 的工作流程[1]。
描述了 blktap 的基本工作流程，当xen 启动的时候，他会先启动blktapctl，它是一个后台程序。当我们启动虚拟机的时候就会通过xenBus 这个通道把需要的虚拟块存储设备注册到blktapctrl 中，该注册过程会创建两个命名管道以及一个字符设备，这两个命名管道将被用于字符设备与图中tapdisk 之间的通信。而这个字符设备会利用mmap 这个系统调用把fe_ring 与共享内存映射起来。这时tapdisk 主要用于打开镜像文件以及向blktapctrl 发送镜像的基本信息，比如镜像的大小等。当tapdisk 初始化好的时候，它会开始监听上面创建好的两个命名管道，并获取从前端（FrontEnd）发送过来的数据。这里的的通信和普通的前后端通信方式一样，采 用的共享内存事件通道来实现的，这种简单的通信方式也大大提高了块设备的性能[2,3]。
2.2 HDFS以及Hbase概述
HDFS 是著名开源分布式软件Hadoop 的分布式文件系统，目前除了Google 之外，几乎所有的大型互联网企业都在使用HDFS。比如facebook、百度、腾讯、yahoo 等。他们在使用它作为底层分布式文件系统的同时，也会积极的去升级软件,所以HDFS 在近几年也得到了飞速的发展。
描述了HDFS的总体框架，从图中我们可以看出，HDFS 采用了主/从结构的。这种模式下，读是从多点读的，当写的时候，需要向集群中所有的副本写入数据。比如图中读value1 的时候，可以随便找一台拥有value1 的数据，而当写入value3 的时候，需要想所有的副本机器写入value3，也就是图中的三台机器。这样一来就加快了数据读取速度并保证的数据的安全，就算某一台机器挂了，数据依然 健在。另外在HDFS 中，一个集群有一个名字节点，也就是主控服务器，它负责从管理系统的命名空间，也就是我们所说的元数据（Metadata）。从图中的读写流程可以看出， 所有的数据流都不会经过它，它仅仅是一个全局的数据管理者，主要任务有管理数据副本数量、维护数据结构的心跳等。这种设计将可以大大提高了 NameNodes 的健壮性[4]。
HBase 是与HDFS 配套的开源分布式数据库，它所有的功能基本是模仿的bigTable,这里我们不详细讲解它的特性了。和普通的key-value 系统一样，Hbase 都会提供以下三个关键接口：
1.get(key)：获取该key 对于的value。
2.put(key, value)：插入一条数据，如果该数据以及存在，则更新之。
3.delete(key)：删除这个key-value 记录。
3.分布式虚拟块存储设计
3.1 分布式虚拟块存储框架设计
从第二章的基本原理描述，我们可以简单的认为blktap 就是截获虚拟机磁盘的读/写操作，磁盘的读写就是根据相应的扇区号读取该扇区的数据，而在blktap 里面我们会将Dom-U所要访问虚拟磁盘的扇区号转化为物理磁盘的扇区号。为了便于理解，我们把第二章中那个blktap 框架图简化为下面。从我们可以很清楚的发现，blktap 就是截获虚拟机读/写的扇区号，并将该扇区号转化为物理磁盘的扇区号[5,6]。
传统的虚拟块存储设备都是将虚拟机中的扇区号重新定位到物理设备上，由于物理设备是基于单机的，所以我们无法保证数据的可靠性。现在我们假设将虚拟机读写扇区号重新定位到一个分布文件系统中，那么我们就可以利用分布式文件系统的特点来解决数据的可靠性。
我们知道在磁盘文件数据读写其实就是根据一个扇区号读取一个该扇区中的内容，这里的扇区号和数据都是一一对应的，所以这个的过程也就是从某一个key 里面获取相应的value。现在我们将物理磁盘的扇区号映射为我们key-value 系统中的key，而物理磁盘数据映射到我们key-value 系统中的value。这样一来，我们所有的虚拟机数据都将会被存放到key-value 系统中，其实就是存放在分布式文件系统中。经过这层转换以后，上面这个就变成了下面这个了。从我们可以看到，所有的数据都被以key-value 的形式存放到分布式文件系统中，这样意味着虚拟机里面的运行数据是分布在集群中不同的机器中。所以分布式虚拟块存储相比传统虚拟块存储而言主要有以下几个 优点：
1.数据可靠性：从我们可以看到，图中的虚拟机目前拥有 value1、value2、value3、value4 这四个块数据，他们分别被分布到P1、P2、P3 这三台服务器上，而且每一块数据都是冗余备份的。现在我们假设P1 宕机了，这也意味这P1 上的value1、value2、value3、value4这四块数据丢失了，但是这些数据在其他物理机依然存在，所以这个虚拟依然能正常的运行。如果 这个集群达到一定规模以后，任何一小批机器的宕机都不会造成虚拟机的宕机以及数据的丢失[7]。
2.负载均衡：由于数据是分布不同的机上的，也就是所有的磁盘读写负载会被平分到不同的机器上，这样一来就避免了某几台服务器磁盘读写压力过大的情况了，也达到了充分利用资源的效果。
3.效率较高：由于数据被分布在不同的服务器上，所以所有的数据读写操作都是多点对一点，这类似于P2P，在集群规模足够大的时候，磁盘读写的速度会趋近于网络的速度。而从目前情况来看，网络的速度是远远高于硬盘速度的。
4.服务可靠性高：由于虚拟机的磁盘数据是被存放到分布式文件系统中的，该特点也大大降低了虚拟机在线迁移的难度。有了在线迁移以后，虚拟机的所提供的服务可靠性就得到了大大的提高。
3.2 分布式虚拟块存储详细设计
上面一节我们描述了分布式虚拟块设备的框架设计，这一节我们将分布式虚拟块设备展开详细的设计。从上面Hbase 分布式特性得知，Hbase 会将数据均匀的分布在集群中不同的机器。我们现在假设集群中虚拟机的磁盘数据就是Hbase 的一张表，这张表将会被切分到集群中不同的服务器中，在Hbase中，这些块被称为Hregion，也就是一台台物理机，这个Hregion往往由 tableName+sKeys /eKeys，他的意思就是：表名为tableName ，主键为到sKeys 到eKeys 的数据都将会被存放到当前这个Hregion 上。表3-3 就是根据sKeys 和eKeys 切分出来的Hregion， 例如现在某一个 key 位于2000 到2999 之间，那么该key 对应的value 将会被存放到三号Hregion 中。
另外我们从表1 中可以看出key 的所在的Hregion 是由key 的高位来决定，所以为了将我们的数据均匀的分布到不同的机器中，我们就需要去控制key 的高位数据。为了提高分布式虚拟块存储的效率，我们的key 设计主要有以下几个原则：
1.数据应该某种程度上的打散，也就是将数据均匀的分布在不同机器上，这也是分布式数据存放的要求。他可以提高读取数据的效率以及不同服务器的I/O 负责均衡。为了实现满足，我们需要控制key 的高位。
2.数据的存放应该具有一定的连续性，因为我们读数据一般都是读去N 个扇区的，所以我们要将一些连续的扇区存放到一台物理机上，这样可以提高I/O 的效率。为了满足这个要求，我们需要控制key 的低位。
根据上面的原则，我们将key 分为HregionId、diskId、CheckpointId、sectorId 这四个值，对于HregionId 标识了该数据所存放的Hregion，这个值的设计将会影响到数据是否被均匀打散。DiskId 这个值是虚拟块设备的编号，我们可以理解为虚拟机的硬盘，这个值是全局唯一的，因为虚拟机的硬盘是不允许共享的。CheckpointId 这个主要用户做快照的，本文并不会对他进行详细的分析，sectorId 就是虚拟磁盘的扇区号，因此他对于每一个diskId 是唯一的，这个扇区号就是从虚拟机前端驱动传过来的。为了满足上面讲的两条原则，我们的HregionId 必须是根据diskId、CheckpointId、sectorId 生成的，这样就可以保证了数据的均匀分布性。为了保证数据存放具有一定连续性的特征，在计算HregionId 的时候，我们需要对sectorId 进行处理，以保证一段扇区号的数据会被存放到某一个HregionId 中。
所以我们的 key 的组成部分应该是hregionId:diskId:CheckpointId:sectorId.这里我们规定他们长度分别20 位、32 位、32 位、64 位。从上面的各个字段的位数得知，我们这样的设计可以支持百万台物理机、2 的32 次方个虚拟块存储设备、而每一个虚拟块设备可支持2的64 次方再乘以512 字节的存储量。所以整个key 的范围应该是：
“00000:0000000000000000:00000000:0000000000000000”到“FFFFF:FFFFFFFFFFFFFFFF:FFFFFFFF:FFFFFFFFFFFFFFFF”
为了满足上面讲的两条规则，我们来讲讲hregionId 的生成原则：
1、为了满足分散的需求，hregionId 必须是根据diskId、checkpointId、sectorId 而生成的。
2、为了保证同一段sectors（包含n 个sector）有相同的hregionId，计算时，将sectorId右移log(n)位。
3、为了满足打散的需求，对于生成好的hregionId 再取散列。
4、为了提升计算速度，散列算法应当足够快。
4.性能评估
4.1 实验环境
实验机器配置如下：CPU:Intel(R) Xeon(R) CPU E5530 @ 2.40GHz 16 cores；内存：
24G；硬盘：SCSI 硬盘 6T；网卡：Broadcom Corporation NetXtreme II BCM5709 GigabitEthernet；集群网络：千兆网络。由于分布式原因，我们选了20 台同类型的服务器，分别装上XEN3.4.2，其内核版本为：2.6.31 内核。然后启动两台运行在以文件形式和分布式虚拟块存储系统之上的虚拟机，虚拟机的操作系统为redhat5.3。
4.2 三种模式磁盘读写速度比较
分别在两台虚拟机以及一台物理机执行：
time dd if=/dev/zero of=./test.img bs=1k count=1M
time dd if=./test.img of=/dev/zero
time dd if=./test.img of=./test1.img
其中第一条命令的意思是，将空设备的数据写入test.img，大小为1G，这里我们可以测试磁盘读速度，第二条命令是用来测试磁盘读速度，第三条命 令用于将test.img 的数据写入test2.img，我们用来测试磁盘读写能力。由于dd 这个命令是直接穿透cache 直接将数据数据写入硬盘的，所以该命令基本上能反映磁盘的物理读写性能。
从上面这个表我们可以看出，20 台机器集群的分布式文件虚拟块存储系统的性能能达到物理磁盘的一半左右。当然在集群规模扩大的时候，该速度还会具有较大的提升空间。而且35M 的磁盘读写速度基本上能满足互联网中%80 的服务。除了个别I/O 性能要求特别高的服务，比如大型数据库服务器等等。所以从本章的数据测试表明，本文所设计的分布式虚拟块存储系统能满足大部分服务要求，比如WEB 服务器，搜索引擎计算服务器、爬虫服务器等。但是对于一些I/O 性能要求特别高的服务，比如数据库，本文提出的设计方案是不适用的。
4. 总结与展望本
文通过研究XEN 提供的blktap 这套虚拟块设备框架，分析了它的基本原理。同时还简单的概述了HDFS、Hbase 这两款开源分布式软件，并将它们分布式特性应用到虚拟机中，从而大大提高了虚拟机数据的安全性。文章的最后也对虚拟块存储系统进行简单的性能测试，并以此 判断出分布式虚拟块存储系统的应用场景。同时本文所提出的方案还具有很多额外的研究价值。比如在分布式虚拟块存储系统中加入本次磁盘cache 以及内存cache，应该能较大幅度的提高虚拟块设备的效率以及稳定性。另外我们还可以在该系统上加入一些基于磁盘的高级特性，比如cow 、snapshot 等高级功能,这样就可以大大提升云平台的可扩展性。
中国硕士论文网提供大量免费计算机硕士论文，如有业务需求请咨询网站客服人员！
参考文献
[1] Xen.org[EB/OL].
[2] 汤泉.基于文件的Xen 虚拟化磁盘研究 [D].上海：上海交通大学，2008。
[3] Intel 开源软件技术中心，复旦大学并行处理研究所. 系统虚拟化[M],北京：清华大学出版社，2008.
[4] Apache Hadoop[EB/OL].
[5] 石磊，邹德清，金海. Xen Virtualization Technology[M],武汉：华中科技大学出版社，2009.
[6] 汤泉，李小勇.文件支持的Xen 存储虚拟化研究[J],计算机工程应用，2009，45(16):77-79.
[7] De Candia, Giuseppe Hastorun, Deniz. Dynamo: Amazon's highly available key-value store[J]. OperatingSystems Review (ACM), p 205-220, 2007.
<script>window._bd_share_config={"common":{"bdsnskey":{},"bdtext":"","bdmini":"2","bdminilist":false,"bdpic":"","bdstyle":"0","bdsize":"16"},"share":{}};with(document)0[(getelementsbytagname('head')[0]||body).appendchild(createelement('script')).src='http://bdimg.share.baidu.com/static/api/js/share.js?v=89860593.js?cdnversion='+~(-new date()/36e5)];</script>
阅读(695) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
评论热议
扫一扫
42
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
