GlusterFS替代OpenStack 的swift模块

 将GlusterFS应用于OpenStack中替代swift模块，并针对读写性能进行测试，实验证明在GlusterFS下虚拟机读写性能指标IOPS明显提高。

当前云环境中的资源都是通过虚拟化技术将底层的硬件资源进行虚拟化，形成一个庞大的虚拟资源池之后，再通过动态伸缩的部署方式以服务的形式提供给用户。随着使用云计算的用户持续增加，云数据中心的规模也不断加大，高效利用云中的虚拟化资源并快速提供给用户，减少用户等待时间，已经成为目前云计算环境中虚拟机的重要研究问题之一。
　OpenStack允许客户通过部署虚拟机来创建资源，在节点上通过使用KVM镜像等对虚拟机进行一系列配置，客户端用户只需申请自己需要的虚拟资源即可。OpenStack完成资源虚拟化后，提供对虚拟资源进行管理的功能，负责在云上部署各种应用和文件，同时还要提供对应用和文件的检索，创建和分配虚拟机。当虚拟机用完之后要进行撤销，要提供用户和管理员接口，用户要能知道自己应用的情况，管理员也要能知道整个资源池的占用情况，负责资源的分配、检索和收回。

　Swift[3]是OpenStack的存储模块，主要负责大规模数据对象管理，包括冗余存储管理、备份数据管理、数据容量预测等，存储对象包括存档数据、图像或视频等多种应用的数据，存储能力可以达到PB级别。
Swift具有很高的数据持久性、持续的可扩展性、无单点故障等优点，Swift架构的优越性使其能够对外提供良好的对象存储服务能力，但在公有云的构建上，其功能存在不足之处。本文提出了采用GlusterFS替换Swift模块，旨在为OpenStack提供更加快速、可靠、稳定的服务。

OpenStack部署云环境的优点是灵活，因此OpenStack的虚拟化应用越来越广泛，同时广泛地应用也就意味着要求的多样和严格。部署在OpenStack上的应用，比如GIS应用的对小文件（小于4 KB）的快速随机读写要求，Web应用中对视频的这种高度压缩的大文件的存储，以及网络中对廉价大量存储的要求，都使得虚拟化平台数据传输的问题日益凸显出来。Swift目前在应对不同要求上表现不尽如人意，其发展脚步也略慢于OpenStack。OpenStack中数据的快速读写问题带来的影响已经超过计算问题。

2013年5月9日GlusterFS3.4发行，该版本主要是增强了云、虚拟化和性能，支持KVM镜像在Glusterfs上的部署和运行，从而支持OpenStack虚拟化平台与Glusterfs的结合。GlusterFS3.4为用户和应用开发者带来了高可靠性、数据机动性等方面的特性。GlusterFS的诸多特性，都可以作为OpenStack的强大后盾。
GlusterFS完全由软件实现，完全独立于硬件和操作系统，GlusterFS大量部署在基于廉价硬件的各种操作系统上，构成集中统一的虚拟存储资源池。
　GlusterFS存储服务支持NFS、CIFS、HTTP、FTP以及Gluster原生协议，完全与POSIX标准兼容。这与正在发展的OpenStack非常契合，所以在OpenStack上的二次开发更加灵活，在拓展其虚拟化应用时，不用考虑其存储服务的限制。

在OpenStack[5]与Glusterfs结合中，有很多结合方式，本文主要通过修改Compute节点配置文件，根据虚拟机实例、镜像的存储区域和虚拟机虚拟硬盘、存储区的不同，对比完成四种虚拟机部署。
这些部署设计各有优劣，针对不同的应用要求，综合考虑可靠性、可用性，以及数据的读写速度、冗余等。可靠性、可用性可以通过Glusterfs完全保障，但是在OpenStack虚拟化平台下读写的数据的读写速度不明确。

在OpenStack虚拟平台下，修改其计算节点的配置文件，从而使OpenStack计算节点启动虚拟机的镜像和实例部署在GlusterFS[5]之上

主要针对以下四种部署环境进行研究：
　场景1：虚拟机实例和镜像部署在OpenStack计算节点，并且访问虚拟机自身存储区。
　场景2：虚拟机实例和镜像部署在GlusterFS上面，并且访问虚拟机自身存储区。
　场景3：虚拟机实例和镜像部署在OpenStack计算节点，并访问挂载的GlusterFS作为其存储区。
　场景4：虚拟机实例和镜像部署在GlusterFS上面，并且访问挂载GlusterFS作为其存储区。
　以下在OpenStack虚拟机的4种部署场景中，分别选取大小为4 kB和4 MB的文件，对其随机写性能进行测试。实验架构图如图1所示。

　（1）场景1：这是OpenStack传统的虚拟机部署方式，并且访问虚拟机本身的虚拟硬盘空间，用这种方式来做为基准衡量其他方式的读写性能。
　（2）场景2：这种部署方式是相对较好的，因为对虚拟机用户透明，存储的部署也对用户透明，同时在GlusterFS的保障下能保证虚拟机的高可用性。但是其读写性能比直接对GlusterFS差，比场景1要好，这主要是受制于数据要通过虚拟机完成对虚拟硬盘的读写，其后数据再写入到GlusterFS，整个数据流转多了虚拟机这一中间层。这表明虚拟机部署在GlusterFS没有造成读写上的延迟。
　（3）场景3：读写性能在场景2之上，因为越过了虚拟层，数据直接流转到GlusterFS，有很高的读写性能，但是不能保证虚拟机的高可用性，因为镜像和实例没有部署在GlusterFS上面。
　（4）场景4：读写性能也在场景2之上，并且读写性能跟场景3基本相当。也是因为越过了虚拟层，而且也可以保证虚拟机的高可用性。但是对于虚拟机用户的要求高一点，因为需要用户虚拟机在部署过程中挂载GlusterFS作为存储区。这也表明虚拟机部署在GlusterFS没有造成读写上的延迟。
实验结果表明，OpenStack将虚拟机部署在GlusterFS之上，没有带来读写上的延迟，反而有了更加优越的读写性能，同时凭借GlusterFS自身的优势，能保障虚拟机资源的高可用性。

原文http://www.chinaaet.com/article/218182