CN104679574A

CN104679574A - 云计算中虚拟机镜像管理系统

Info

Publication number: CN104679574A
Application number: CN201310608382.1A
Authority: CN
Inventors: 谢蓉; 应奕彬; 田鹏; 汪一琛; 李欣琪; 马琳; 陈灿华; 王委; 孙跃良; 丁素芬; 俞天衍; 周子豪; 陶静; 李刚; 李月芹; 徐璡晶; 杨曙; 喻亚慧; 李智展; 国家佳
Original assignee: Individual
Current assignee: Individual
Priority date: 2013-11-26
Filing date: 2013-11-26
Publication date: 2015-06-03

Abstract

本发明提出云计算中虚拟机镜像管理系统，该系统包括有镜像库、镜像管理平台；所述的镜像管理平台内部设置有通用配置管理模块、源跟踪模块、版本库维护模块、过滤器模块；基于通用配置管理工具、源跟踪机制和版本库维护服务的虚拟机镜像文件管理的策略，从而实现虚拟机镜像文件管理的灵活性、高效性，设计新颖，是一项很好的设计方案，很有市场推广前景，方便用户使用，而且感观性能优。

Description

云计算中虚拟机镜像管理系统

技术领域

本发明涉及云计算领域，尤其涉及云计算中虚拟机镜像管理系统。

背景技术

云计算是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息可以按需求提供给计算机和其他设备，主要是基于互联网的相关服务的增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。云是网络、互联网的一种比喻说法。过去在图中往往用云来表示电信网，后来也用来表示互联网和底层基础设施的抽象。狭义云计算指IT基础设施的交付和使用模式，指通过网络以按需、易扩展的方式获得所需资源；广义云计算指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关，也可是其他服务。它意味着计算能力也可作为一种商品通过互联网进行流通。

目前，由于虚拟化技术的快速发展，IaaS云服务商通常提供独立的虚拟机方式为用户提供服务，用户通过远程的方式管理虚拟机。由于虚拟机的创建成本较低，用户往往为不同的任务创建不同的虚拟机。用户还可以克隆、快照、甚至可以回滚到以前的状态。这些功能为用户提供了极大的灵活性，但它们对云平台成了的巨大安全风险。而且随着云计算应用的深入发展，越来越多的虚拟机出现。这种现象被称为虚拟机蔓延，使得虚拟机管理与软件更新成为一件非常费时的任务。云计算平台提供商将虚拟机系统更新任务交给用户自己负责，而用户迫切期望供应商来完成这项任务。结果就导致大量的虚拟机（运行或休眠）由于没有及时进行软件漏洞修复而受到大量的安全威胁，降低了系统的安全性，在使用过程中存在一定的缺陷。

综上所述，针对云计算平台能耗较大的缺陷，提出云计算中虚拟机镜像管理系统，以解决现有技术的不足。

发明内容

本发明的目的是提供云计算中虚拟机镜像管理系统，基于通用配置管理工具、源跟踪机制和版本库维护服务的虚拟机镜像文件管理的策略，从而实现虚拟机镜像文件管理的灵活性、高效性，以解决现有技术中存在的不足。

本发明为解决其技术问题所采用的技术方案是，

云计算中虚拟机镜像管理系统，该系统包括有镜像库、镜像管理平台；

所述的镜像管理平台内部设置有通用配置管理模块、源跟踪模块、版本库维护模块、过滤器模块；

通用配置管理模块用于虚拟机镜像管理平台，能根据用户虚拟机镜像的不同需求进行自动化配置，并且能够达到大规模批量更新的要求；

源跟踪模块是对于虚拟机镜像的快照和回滚操作，需要通过建立源跟踪机制对其进行记录，当出现回滚操作时，及时通知版本库维护模块及过滤器模块进行更新；

版本库维护模块是创建一个中心数据库，这个数据库包含所有需要的检查更新的任务的信息，中心数据库中包括安装包的列表信息，软件包的版本信息，还有每一个虚拟机使用的升级站点（仓库）列表信息；

过滤器模块要实现虚拟机镜像的软件更新。

进一步，所述的源跟踪模块在基于Openstack的云计算平台中，通过Ceilometer API实现虚拟机镜像。

进一步，所述的通用配置管理模块对于虚拟机镜像配制包含有用户管理、软件包管理、网络管理、安全管理、系统配置管理、用户自定义配置管理。

本发明的优点在于，该系统基于通用配置管理工具、源跟踪机制和版本库维护服务的虚拟机镜像文件管理的策略，从而实现虚拟机镜像文件管理的灵活性、高效性，设计新颖，是一项很好的设计方案，很有市场推广前景，方便用户使用，而且感观性能优。

附图说明

下面结合附图和具体实施方式来详细说明本发明：

图1是本发明架构示意图；

图2是本发明模块关系示意图；

图3是本发明通用配置管理模块示意图；

图4是本发明版本库维护模块构框图；

图5是本发明过滤器分析流程图；

图6是本发明脚本分析与重写更新流程图；

图7是本发明脚本分析与重写机制图；

图8是本发明测试环境示意图；

图9是本发明虚拟机镜像通用软件初始化性能分析图；

图10是本发明虚拟机镜像通用软件初始化性能对比图；

图11是本发明镜像内已安装软件信息查询性能比较图；

图12是本发明不同包管理系统单个镜像更新性能对比图；

图13是本发明批量镜像更新性能对比图；

具体实施方式

为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，下面结合图示与具体实施例，进一步阐述本发明。

如图1、图2所示，本发明提出的云计算中虚拟机镜像管理系统，该系统包括有镜像库、镜像管理平台；镜像管理平台内部设置有通用配置管理模块、源跟踪模块、版本库维护模块、过滤器模块；在镜像发布环节，虚拟机镜像管理平台拦截用户发布的镜像文件，并且通过通用配置管理和用户自定义管理两种相结合的方式，首先对虚拟机镜像进行软件的初始化操作，实现隐私或保密数据的清理，并通过源跟踪、软件版本库维护和过滤器来对修改后的镜像进行跟踪与更新维护。

过滤器模块要实现虚拟机镜像的软件更新。仅仅获得软件包版本库信息还是不够的，还要将每一个软件包所依赖的信息也提取出来。本系统采用过滤器的机制解决包依赖等更新问题。

另外，通用配置管理模块对于虚拟机镜像配制包含有用户管理、软件包管理、网络管理、安全管理、系统配置管理、用户自定义配置管理。云平台用户创建的虚拟机镜像，会包含一些通用的软件及相应的配置。例如当用户创建一个跟Apache Web或者是Jboss应用服务器有关的虚拟机镜像时，首先会选择一个Linux镜像，然后再安装这些组件。然而安装的系统软件的配置在初始情况下都是默认配置，有些时候无法满足实际应用的需求。让这些机器部署实际的应用，还需要安装一些依赖的软件包，如dns、ssh等；同时还需要设置相关的配置，如根据IP段来设置dns；为了保证服务器的安全性需要禁止某些端口，这时候就需要设置iptables。

本系统以云平台中最为流行的管理工具Puppet为开发基础，设计并实现了虚拟机镜像的通用配置管理功能。基于Puppet的通用配置管理模块架构如图3所示。用户通过编写通用的配置管理信息以manifest的形式保存在Puppet服务端，当客户端下载manifest之后，可以根据manifest对虚拟机镜像进行初始化配置，例如软件包管理，用户管理和文件管理等。Puppetd通过调用facter，探测出虚拟机镜像的一些变量，例如主机名，内存大小，ip地址等。Puppetd把这些信息通过ssl连接发送到服务器端；服务器端的puppetmaster检测客户端的主机名，然后找到manifest里面对应的node配置，并对该部分内容进行解析，facter送过来的信息可以作为变量处理，node牵涉到的代码才解析，其他没牵涉的代码不解析。解析分为几个阶段，语法检查，如果语法错误就报错。如果语法没错，就继续解析，解析的结果生成一个中间的“伪代码”，然后把伪代码发给客户端；客户端接收到“伪代码”，并且执行，客户端把执行结果发送给服务器；服务器端把客户端的执行结果写入日志。

在配置过程中，为了保证安全，client和master之间是基于ssl和证书进行通信的；Puppet同时会检测虚拟机镜像的存活状态，如果检测到虚拟机镜像被删除，Puppet会自动结束相应的配置操作。

用户管理对于Linux这样的多用户操作系统而言，用户管理是系统管理中最重要的组成部分。作为虚拟机镜像的自动化配置系统，需要对创建用户、设定密码、设置用户组、设置用户shell、home目录的权限等常规操作进行初始化。通过创建Puppet的用户管理配置文件，可以对虚拟机用户的管理进行自动操作，从系统管理安全性的角度考虑，禁止用户直接使用用户名和密码登陆系统，而是采用SSHkey登陆系统。所以在创建用户时，为用户创建好SSH相关的配置信息，而key的内容则是由虚拟机镜像的用户来提供，因为这涉及到相应的隐私信息。

在网络配置管理中，一些常用的操作是设置服务器的域名，设置服务器的DNS，建立服务器的网络时钟服务以校准时间，在服务器上禁止ipv6(不部署ipv6应用的前提下）等。可以实现在大规模虚拟机镜像管理时配置不同的域名服务器，这样可以提高域名解析的速度。

安全配置作为虚拟机镜像的初始化安全配置，通常使用iptables来管理防火墙，建立一些数据包过滤机制和转发机制。通常情况下只打开应用程序所要用到的端口（比如80端口），以及一些系统管理中的常用服务的端口（比如SSH服务的端口），而禁止掉那些不需要使用到的端口。

而且，源跟踪模块在基于Openstack的云计算平台中，通过Ceilometer API实现虚拟机镜像。通过配置ceilometer.conf文件，启用Ceilometer对Openstack的支持。

通过Ceilometer提供的API，可以获取Openstack中的所有虚拟机镜像文件的状态，并且可以调用相关接口去查询数据，返回虚拟机镜像所处的生命周期类型。Notification负责在MQ中监听相关topic的消息（虚拟机快照、回滚等），并把它转换成Transformer。通过Pipeline定义了这些状态之间的数据流。

通过对代码建立对虚拟机镜像的跟踪，当出现相关的订阅事件后，将会产生一个通知消息，告知虚拟机镜像的状态发生了改变，需要调用版本库维护模块以及过滤器模块对虚拟机镜像的软件版本进行分析和处理，确保镜像包含依赖模块、补丁和修复程序，保持彼此之间的版本同步。

版本维护库模块，软件包版本库维护模块的工作原理主要是创建一个中心数据库，这个数据库包含所有需要的检查更新的任务的信息。中心数据库中包括安装包的列表信息，软件包的版本信息，还有每一个虚拟机使用的升级站点（仓库）列表信息。这些信息在虚拟机第一次注册的时候就需要导入中心数据库，并且每一次虚拟机发生变化的时候都需要更新。本方案的设计如4所示，包数据库和仓库数据库都分别有自己的收集器。这使得补丁信息收集器模块能够更好地适应其他软件管理解决方案。不同仓库可获得的包的信息储存在升级库数据库中。补丁信息收集器模块会从这些数据和升级库数据库中获取信息，并且去匹配已安装的包和可获得的包的信息来检查软件是否已经过期，之后将这些信息储存到离线补丁升级数据库中。

软件包分析模块主要包含两部分：

（1）虚拟机导入模块。Linux平台下有许多的软件包管理工具，如redhat的rpm，Debian的dpkg等。这些包管理工具使用特定格式的数据来保存已安装的软件的相关信息，如软件名，软件版本，软件包含哪些文件等。另外软件包管理工具特定格式的配置文件来保存软件升级库(repository)的相关的信息。因此使用不同的软件包管理工具的不同linux发行版必须使用不同的虚拟机导入模块来将前面提到的这些信息保存到补丁信息收集器中心数据库中。下面针对目前最流行的rpm/yum包管理工具的软件数据库及配置文件相关信息作具体分析。

rpm包数据库存放在/var/lib/rpm目录上，该目录下存了一组Berkeley数据库文件。这些Berkeley数据库文件没有办法直接提取相关信息。因此只能采用rpm-qa命令从Berkeley数据库文件内提取软件包的信息。使用这种方法可以将离线镜像文件挂载到镜像安全服务器上，然后使用rpm-qa命令并指定镜像文件内的相应数据库。rpm-qa命令输出已安装软件的列表。

Yum可以配置一组软件升级站点，这些配置文件保存在/etc/yum.repos.d目录内。每一个站点配置文件使用有键-值对的格式，每个站点配置文件都可以包含多个软件升级库的信息。

（2）升级软件库导入模块。和软件包管理器一样，不同的在线升级机制也需要使用不同的数据库来存储远程升级站点相关的信息。因此也需要对不同的升级机制的不同linux发行版必须使用不同的升级软件库导入模块来将站点信息保存到升级库信息数据库内。Yum升级站点信息是使用xml方式描述的，并且将不同的信息分类存放在不同的xml文件里，与升级站点存放的软件包的信息全部存放在repodata/repomd.xml文件内<data type="primary">元素描述所对应的xml文件中。下面的例子是fedora16yum升级站点下repodata/repomd.xml文件的信息。在这个例子中，可以通过查询datatype="primary"标签下的<location href/>元素来找到存放站点软件包信息的文件。

过滤器分析流程如图5所示：

（1）将上一级过滤器处理过的镜像（如果前面没有过滤器也没有关系）传递给镜像离线更新补丁过滤器；

（2）使用探针探测镜像文件。获取一些基本信息如操作系统类型、操作系统版本、使用的包管理方式等；

（3）基本探针探测的结果采用对应包管理方式进行相应的处理（以yum包管理方式为例)；

（4）从镜像文件中提取yum相关的数据库信息；

（5）将提取出来的yum相关的数据库与最新的yum补丁数据库进行对比；

（6）将差异部分的最新补丁下载到镜像安全服务器并将最新补丁打到镜像文件内；

（7）更新之前提取出来的yum数据库，更新好yum数据库后，将其同步到镜像服务器内；

（8）将经过镜像离线更新补丁过滤器处理过的镜像传给下一级过滤器处理。

在实施过程中，本系统采用了综合使用直接替换镜像内文件与脚本分析与重写结合的方法。具体的设计方案如图6所示。

（1）补丁信息收集器模块会将需要更新补丁的软件包信息传递给离线镜像补丁升级模块；

（2）离线镜像补丁升级模块先对升级软件包内的spec文件分析，如果spec文件的所有脚本代码都是安全的则使用直接替换镜像内文件的方法对镜像更新补丁；

（3）如果spec文件内存在不安全的脚本代码，则将spec文件传递给脚本分析与重写子模块；

（4）脚本分析与重写子模块对传递过来的spec文件进行分析，如果该spec文件中的所有不安全脚本代码都能成功转化为安全脚本代码。则将该spec文件进行重写。重写后再利用直接替换镜像内文件的方法对镜像更新补丁。如果该spec文件中的所有不安全脚本代码不能成功都转化为安全脚本代码（这种情况非常少）。则将该软件补丁包注入到镜像的特点目录，使用镜像下一次运行时更新补丁方法。因为只有少量的spec文件不能成功转化为安全的spec，所以该方法的效率非常高。

RPM软件升级机制：

RPM包管理器的工作主要是基于rpm SPEC文件。软件制作者通过定义SPEC文件来规定了RPM管理器所需要的所有信息。SPEC文件可以分成许多节，每一节可以定义一组的规则。下面是常见的几节：

(1)Preamle

这节中包含包的功能描述、包的软件版本、版权信息和所属的包组等信息。

(2)Prep

Prep节是预处理阶段为实际的打包准备工作，以前缀%prep表示，执行patch可以将更新文件加入解开的源程序中。

(3)Build

Build是用来编译源码的，使用%build表示前缀。

(4)Install

Install用于完成软件安装时所需要执行的命令，使用%install前缀表示。在用户所自行安装的操作系统中，为了验证一个包是否已经成功安装的验证脚本也可由这一节指定。

(5)Pre

RPM安装前执行的脚本。

(6)Post

RPM安装后执行的脚本。

(7)Preun

RPM卸载前执行的脚本，会在升级RPM的时候会执行。

(8)Postun

rpm卸载后执行的脚本，在升级RPM包的时候不会执行。

(9)Clean

这一节所描述的内容表示在完成包建立的工作之后，自动执行此节下的脚本进行附加的清除工作，它是使用节前缀%clean表示的。一般而言，这一节的内容是简单地使用rm-rf$RPM_BUILD_ROOT命令，不需要指定此节的其它内容。

(10)文件列表

这一节指定构成包的文件的列表，它是使用节前缀%files表示的。此外，它还包含一系列宏控制安装后的文件属性和配置信息。

(11)改动日志

这一节主要描述软件的开发记录，它是使用节前缀%changlog表示的。这个段的内容是为了开发人员能详细的了解该软件的开发过程，对于包的维护极有好处。

其中，spec文件中的Pre节、Post节、Preun节以及Postun节与软件更新有直接关联。RPM包管理器在升级rpm软件时会按如下的方式进行：

1.运行新包的%pre

2.安装新文件

3.运行新包的%post

4.运行旧包的%preun

5.删除新文件未覆盖的所有旧文件

6.运行旧包的%postun

本系统提出的基于安装脚本重写方法的技术基础就是基于spec文件的基本语法而提出的。

由于更新镜像主要是将新软件文件更新镜像内存在软件漏洞的旧文件。并且镜像离线更新补丁我们只关注在虚拟机映像的文件系统所做的更改。而许多运行时的变化并不直接作用于虚拟机镜像。因此使用直接替换镜像内文件的方法来解决这个问题，具体描述如下：

这个方法直接将另一台主机上（已打过补丁）的文件替换镜像内的文件。即将虚拟机镜像挂载到补丁服务器，经过挂载后，镜像文件成为补丁服务器文件系统的一部分。因此补丁服务器能直接访问镜像内的所有文件。然后使用chroot（chroot就是Change Root，也就是改变程式执行时所参考的根目录位置）机制将当前补丁服务器的根目录切换成镜像文件的根目录。然后补丁服务器就可以模拟虚拟机运行时的状态，再利用在线系统更新补丁的机制来更新这个经过模拟后的镜像。

直接替换镜像内文件的主要工作是在升级前执行升级脚本，然后再将软件包的文件放到特定目录内，接着运行升级后脚本，最后维护包管理器的相关数据库以保持其数据完整性。因此将补丁更新到离线镜像也要做相应的这些工作。

镜像文件在其镜像安全服务器上只表现为一个普通的经过打包的文件。因此在执行上面提出的四步时都有可能出问题使升级失败。这一步是实现离线镜像更新补丁的核心。在这一步主要会遇到如下的问题：

1、在线执行升级前/后脚本与离线状态下执行结果一致性的保证。

2、将补丁包合并到镜像内，合并后的镜像文件加载到虚拟机上不会破坏客户操作系统（Guest OS）的完整性并且补丁能够成功地反映出来。

3、保证客户操作系统（Guest OS）内的包管理软件数据库的一致性问题。

其中第一部分检测dbus线程是否在运行，如果运行则发重启信息给线程。第二部分重启打补丁后的dbus守护线程以使更新生效，这两部分都依赖于运行时的环境。

脚本分析与重写：

对软件包依赖的分析还可以通过基于安装脚本分析与脚本重写的方法来实现。脚本安全分析主要是检查更新脚本是否能在模拟环境下安全执行。脚本重写主要将升级脚本中一些不适用于离下升级的脚本转化为可以应用于离线升级的脚本，减少不必要的代码以及用安全的脚本代码代替不安全的脚本代码以实现相同的目的。大多数的不适用于离线升级的脚本可以转化适用于离线升级的脚本。

（1）脚本分析

脚本分析基于影响、依赖将常见的shell命令分类。本文将常见的脚本命令分为三类：第一类可以正确地在离线下执行的命令；第二类不能在离线环境下正确的执行的命令；第三类在离线环境下没有必要执行的命令。为了实现将命令分为上面所提到的三类，将运行系统分为“内存”部分和“文件”系统部分。然后分析哪个部分会影响或受影响于执行特点的命令。大部情况下影响“文件”系统部分的命令可以正确地在离线环境下使用，但是影响“内存”部分的命令一般不能在离线环境下正常地使用。如果一个命令需要从文件系统中读取数据或存在任何依赖于文件系统的输入则称该命令依赖于文件系统。如果一个命令的输出写入到文件系统或存在任何依赖于文件系统的输入则称该命令对文件系统有影响。表1列出一些影响文件系统的命令。

表1影响文件系统相关命令列表

命令类型	例子
		文件属性相关	chown,chmod,chgrp,touch
文件相关	cp,mv,mknode,mktemp,adduser,addgrp

如果一个命令需要获取系统运行时的信息（如列出当前运行的线程或读取/proc目录等）则称该命令依赖于内存。如果一个命令会影响运行时的状态信息（如列出当前运行的线程或读取/proc目录等）则称该命令对内存有影响。我们通过人工检查所有的补丁脚本中使用的命令，以确定其对的内存和文件系统的影响和依赖。使用这种方法看上去似乎是一项非常费时费力的事情，但事实上，脚本使用的命令命令非常的少。通过分析，1000多个软件包里面只有大约200个使用了不同的命令。这些信息可以通过检测命令执行来获取。在实践中，我们期望包维护者能够提供这些信息。

表2影响/依赖“内存”的命令列表

命令类型	例子
		服务的启动与关闭	invoke-rc.d,/etc/init.d/
线程状态	ps,kill
		查询系统信息	uname,lspci
内核模块	Lsmod,modprobe

一般情况下，一条命令在下面几种情况我们称该命令依赖于“内存“。

1）不知道该命令

2）该命令依赖于内存

3）存在一个或多个参数需要变量代替

4）通过管道做为命令的输入且该管道依赖于内存

5）存在来自设备，/proc目录下的文件或是一个变量代替的输入重定向的命令。

文件系统依赖的分析与内存依赖相似，这里就不列出了。下表列出常见命令的具体分类，表中的“适应命令“不依赖或影响于“内存”，这类的命令可以在离线下执行。脚本重写时会不修改这些命令。“不必要的命令”对文件系统无任何的影响，这些命令完全没有必要在离线情况下执行，因为他们不会影响影响。但是这类命令要是依赖或影响“内存“则脚本重写这些命令必须删除它们否则会出现错误。”不适应命令”在离线环境下不能正常的执行，因为他们依赖于运行环境。脚本重写会尝试着将这类命令换功能转化为“适用类命令“。如果脚本重写不能将其转化为“适用类命令”则对应的软件包只能在在线的环境下升级。

表3脚本命令的分类

依赖文件系统	依赖“内存”	影响“内存”	影响文件系统	适用性
					是/否	否	否	是/否	适用
是/否	否	是	是	不适用
					是/否	是	否	是	不适用
是/否	是	是	是	不适用
					是/否	否	是	否	不需要
是/否	是	否	否	不需要
					是/否	是	是	否	不需要

（2）脚本重写。图7所示为脚本分析与重写技术的整个流程图。

在执行离线更新脚本之前会通过脚本重写模块处理，重写一个升级脚本会改变脚本的“适用性”，因此在运行脚本重写模块之后会返回软件更新包的最终“适用性”。如果返回的结果是“适用”则执行离线升级，否则该包将会使用在线的方式升级。下面对具体的几种脚本重写技术的描述：

（A）不需要命令的消除。消除不需要的命令，即不直接或间接地作用于文件系统的命令。

（B）命令替换技术。该技术只要在获取系统运行时信息的命令并且这类信息也存在于文件系统里。该类命令依赖于运行环境，可以将该类的命令替换为依赖文件系统的命令。例如uname命令输出操作系统的名称、系统内核及体系架构相关信息。Uname命令通过内核的uname的系统调用。离线状态下无法调用该系统调用。但是uname命令返回的大部分信息可以在文件系统的特定文件内找到.消除不必要的语句控制块技术。

系统的组建：本系统通过Openstack搭建云平台，采用Glance作为虚拟机镜像服务器，对虚拟机镜像管理系统的核心模块功能进行测试与分析。如图8所标：

通用配置模块性能分析：

该模块主要包括初始化安装镜像内的相关软件包，以及完成相应的系统配置。如图9所示是fedora16(90个软件包)镜像和centos5.5(20个软件包)镜像的软件包安装及配置所需要时间的对比图。从图9可知镜像软件包初始化的时间与镜像内软件包的数据成一定的线性关系。对Fedora16与centos5.5分别进行了十次测试，每次测试的结果差别不大。Fedora16镜像软件包初始化平均需要12分钟左右的时间。Centos5.5镜像软件包初始化平均需要3分钟左右。在云平台环境中，镜像的操作系统一般会按照最小化的方式进行初始化安装，一般用户会安装的软件包数量基本上在20个左右，镜像软件初始化时间在3分钟左右的性能对用户而言是完全可以接受的。

如图10所示是fedora的三个发行版以及centos的两个发行版对应的软件包初始化性能对比情况。对于不同原始镜像的初始化操作，一般对一个特定的发行版只进行一次，之后每次有补丁更新才会进行相应的更新操作。从图10可以看出Fedora发行版（平均50个软件包）平均使用7分钟左右,centos发行版(平均15个补丁信息)初始化平均使用2分钟左右。软件包初始化耗费的时间与软件包数量之间的比例关系再次得到了验证。因此，对普通的云平台用户而言，通过通用配置管理模块进行软件初始化，具备良好的性能和用户体验。

版本库维护模块性能分析：

如图11所示是fedora16镜像与centos5.5镜像内已安装软件版本库维护服务性能对比。从图中可以发现，镜像内已安装软件版本库维护服务从中心数据库查询的效率是非常高的。并且软件包的数量对查询的效率影响非常小。从版本库中查询相应镜像内安装软件的版本信息要求延时短，否则会严重影响用户的体验。根据测试结果，版本库维护服务的性能基本能满足实时查询的需要。

过滤器模块性能分析：

1、单个镜像更新性能分析：

如图12所示为单个fedora16与ubuntu12虚拟机镜像使用过滤器解决包依赖更新虚拟机镜像所需要的时间对比图。Fedora16更新189个软件包平均需要16分钟，而ubuntu12更新171个软件包平均需要15分钟左右。出现这一结果是由以下两个因素导致。第一、fedora16的软件包更新数比ubuntu的软件包更新数多一些；第二、fedora使用rpm包管理器，使用Berkeley数据库存储包管理器的相关信息，而ubuntu使用文本文件来管理，解决fedora软件包依赖的过滤器操作比ubuntu的相对复杂。

2、批量镜像更新性能分析：

如图13所示为160个fedora14的镜像文件与ubuntu11的镜像文件进行批量更新补丁所需要时间和240个fedora14的镜像文件与ubuntu11的镜像文件进行批量更新所需时间。该测试采用了8个线程，每个线程对20个镜像进行更新操作。160个Fedora14镜像更新的总时间平均是215s，160个ubuntu11镜像更新的总时间平均是210s。240个Fedora14镜像更新的总时间平均是350s，240个ubuntu11镜像更新的总时间平均是330s。160个fedora镜像批量更新时平均每个镜像只需要1.34s，160个ubuntu镜像批量更新时平均每个镜像只需要1.31s，230个fedora镜像批量更新时平均每个镜像只需要1.45s，240个ubuntu镜像批量更新时平均每个镜像只需要1.37s。因此批量镜像补丁更新的效率远高于单个镜像补丁更新的效率。这对于云平台中虚拟机镜像的管理而言是非常有意义的。

以上显示和描述了本发明的基本原理、主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等同物界定。

Claims

1.云计算中虚拟机镜像管理系统，其特征在于，该系统包括有镜像库、镜像管理平台；

过滤器模块要实现虚拟机镜像的软件更新。

2.根据权利要求1所述的云计算中虚拟机镜像管理系统，其特征在于，所述的源跟踪模块在基于Openstack的云计算平台中，通过Ceilometer API实现虚拟机镜像。

3.根据权利要求1所述的云计算中虚拟机镜像管理系统，其特征在于，所述的通用配置管理模块对于虚拟机镜像配制包含有用户管理、软件包管理、网络管理、安全管理、系统配置管理、用户自定义配置管理。