本文作者：蒋清野

在架构方面，我们关心的是它包括哪些组件，各个组件之间的关系和通信方式，以及这样的设计会如何影响到整个系统的扩展性和伸缩性。这里所说的扩展性，是指为相关软件添加新的功能模块的能力。例如，当新的虚拟化技术出现时，云管理员能不能相对容易地为新的虚拟化技术提供支持。在伸缩性方面，我们关心的是相关软件究竟能够管理多大规模的数据中心，如果它不能够管理更大规模的数据中心，其性能瓶颈主要在什么地方。

在功能方面，我们关心它是否能够满足用户的需求。我们所说的用户包括两个类别，一个是IaaS服务的使用者，即终端用户，另一个是IaaS服务的提供者，也就是云管理员。对终端用户来说，他所关心的是能不能够通过这个系统方便地申请、创建、启动、休眠、唤醒、关闭、销毁虚拟机，以及方便地监控自己账户下所有虚拟机的处理器、内存、磁盘和网络使用状况。对于云管理员来说，他关心的是能不能够通过这个系统方便地监控整个数据中心(甚至是多个数据中心)所有物理机和虚拟机的资源使用状况，能不能在尽可能少的物理机上运行尽可能多的虚拟机以达到节能减排的目的。从理论上来讲，基础架构服务的终端用户只需要关心自己所使用的虚拟机资源而不必关心虚拟机后面的技术细节。但是当云服务出现故障的时候，我们会发现终端用户比云管理员更关心云服务的高可用性、数据备份策略等细节，并且迫切地希望存在某些途径让自己的虚拟机和别人的虚拟机得到特殊的照顾。从工程的角度来讲世界上不存在绝对不会失效的系统，但是这些需求可以转变成功能或者是产品，使得云服务提供商可以为不同的用户提供不同的服务。

为什么要关心社区?使用开源软件，出了问题就只能够找社区了。因此，我们需要专门讨论一下与这几个开源软件所关联的社区的规模、活跃度和参与度。

此外，开源软件的商业模式问题也值得关注。这个问题又可以分为两个方面，一方面是开源软件开发者如何盈利，另一方面是开源软件使用者如何获得专业支持和服务。对于基础架构服务这种关键性应用来说，在软件选型过程当中如果不考虑开源软件的商业模式问题，将来可能会遇到一些麻烦。

架构详解

1.OpenNebula 3.0

图1是OpenNebula的整体架构图。前端(FRONT-END)通过浏览器和Web Service向云管理员和终端用户提供服务。ONED是OpenNebula的核心服务进程，包括虚拟化管理模块和任务调度模块。ONED通过SSH方式连接到计算节点，并通过虚拟化驱动(Drivers)来调用计算节点上的虚拟化控制命令。当计算节点使用KVM或者是VMWare ESXi作为虚拟化技术时，OpenNebula使用libvirt所提供的接口远程调用计算节点上的虚拟化控制命令。当计算节点使用Xen作为虚拟化技术时，OpenNebula通过SSH登录到计算节点执行相关的虚拟化控制命令。计算节点通过前端的映像驱动(Images)获得需要运行的操作系统映像文件。需要说明的是，还有监控、用户界面和云服务API等一些前端模块没有出现在该图上。

图1 OpenNebula整体架构图

图2是OpenNebula的存储结构图。OpenNebula使用映像仓库(Image Repository)来保存操作系统映像文件。这个映像仓库要能够被OpenNebula的前端直接访问，可以是SAN、NAS或者是磁盘阵列等其他存储设备。我们创建虚拟机的时候，ONED首先通过任务调度器确定将要运行该虚拟机的计算节点，然后将相应的磁盘映像文件拷贝到计算节点上，最后通过虚拟化驱动调用相应的虚拟化技术创建虚拟机并启动运行。对于一个小型的私有云来讲，可以简单地使用类似于NFS的共享文件系统方式将同一个目录挂载到前端服务器和所有的计算节点上。通过使用共享文件系统，可以缩短部署虚拟机所需要的时间，还可以方便地实现虚拟机的在线迁移。使用共享文件系统的时候需要注意的是，如果某些虚拟机频繁地进行磁盘IO操作的话，部署在同一共享文件系统上的所有虚拟机都会受到影响。在这种情况下，可以考虑将磁盘I/O密集型虚拟机的磁盘映像文件缓存在计算节点上，这样只有运行在同一计算节点上的虚拟机会受到影响。

图2 OpenNebula存储结构图

在网络方面，OpenNebula通过在计算节点上配置网桥的方式为虚拟机提供网络连接。如图3所示，一个计算节点配置了两个网桥，其中一个连接到公网，另外一个连接到内网。需要注意的是，在同一个计算集群中，所有计算节点的网桥配置必须是同样的。另外，OpenNebula可以通过配置文件来指定某个网络可用的IP范围，并且在创建虚拟机的时候通过配置文件直接指定虚拟机的IP，因此OpenNebula可以在没有DHCP服务器的情况下为虚拟机分配IP。

图3 OpenNebula网络结构图

刚才我们所提到的架构、存储和网络，都属于虚拟化管理的范畴。在虚拟化管理的基础上，OpenNebula使用一个称为SunStone的用户界面，使得云管理员和终端用户都能够通过浏览器访问被OpenNebula所管理的基础架构，在各自的权限范围内执行虚拟机生命周期管理操作，就形成了一个完整的基础架构服务系统。

2.Nimbus 2.8

接下来我们看一看Nimbus这个项目。从架构图(图4)来看，Nimbus的架构设计和OpenNebula是非常相像的。用户通过浏览器界面访问Nimbus服务，管理节点通过SSH和libvirt调用计算节点上的Xen或者KVM命令。不同的地方主要有两个，一个是它通过DHCP服务器为虚拟机分配IP，另一个是它使用了一个名为Cumulus的云存储服务。

图4 Nimbus整体架构图

图5是Cumulus云存储的架构图。可以看出，Cumulus由多个功能模块组成。从顶层看，它是一个与Amazon S3相兼容的云存储服务;从底层看，它可以搭建在简单的本地硬盘或者是负责的HDFS上。在云计算这个领域，Amazon S3是事实上的云存储标准。Nimbus使用云存储来提供存储服务，从架构上来说比使用共享文件系统的OpenNebula更接近于Amazon EC2/S3。

图5 Cumulus云存储架构图

读者可能会问，用云存储来作为基础架构服务的关键组件，在性能上会不会有问题呢?我们测试过Culumus、scp、gridFtp和本地文件系统在上载和下载不同大小的文件时的吞吐量。测试结果显示，当被操作的文件较小的情况下，Culumus的性能较差，但是与scp和gridFtp的性能在同一水平上;当被操作的文件大小超过1GB的时候，Culumus的性能与本地文件系统接近。考虑到操作系统映像文件的大小通常会超过1 GB，可以认为使用Culumus来存储操作系统映像文件是没有问题的。

 

3.Eucalyp 2.0.3

Eucalyptus的架构(图6)和OpenNebula以及Nimbus相比有两个明显的不同。首先，在计算节点(Node Controller)和云控制器(Cloud Controller)之间，多了一个叫做集群控制器(Cluster Controller)的组件。其次，在Eucalyptus中有两个负责存储的组件，一个叫做Walrus存储控制器(Walrus Storage Controller，WS3)，另外一个叫做弹性块存储(Elastic Block Storage，EBS)。

图6：Eucalyp 2.0.3架构图

引入集群控制器这个组件后，Eucalyptus中的虚拟化管理功能就由集群控制器来承担。也就是说，当用户向Eucalyptus的云控制器请求计算资源的时候，Eucalyptus的云控制器根据各个计算集群的资源使用状况将用户的请求转发给某个计算集群的集群控制器，集群控制器再根据本集群中各个计算节点的资源使用状况决定在哪个计算节点上创建和运行虚拟机。

如果将Eucalyptus的架构和OpenNebula以及Nimbus的架构来做个比较，可以看出Eucalyptus的计算集群和OpenNebula以及Nimbus在功能上基本是等价的。我们知道，当计算节点的数量较多的时候，虚拟化管理模块，以及系统监控模块的压力就会比较大，可能会影响到整个系统的性能。假定Eucalyptus、OpenNebula以及Nimbus的虚拟化管理模块的实现水平是相当的，当OpenNebula和Nimbus由于计算节点数量增加而出现性能问题的时候，Eucalyptus可以通过增加计算集群的方法来实现横向扩展。从这个意义上说，Eucalyptus的架构设计提供了更大程度的扩展性，能够支撑更大规模的基础架构。

刚才我们说到，Eucalyptus中有两个负责存储的组件。一个是WS3，与Amazon的简单存储服务(Simple Storage Service，S3)相对应;另外一个是EBS，与Amazon的弹性块存储(Elastic Block Store，EBS)相对应。EBS可以被当做块设备挂载到虚拟机上，相当于云硬盘。EBS能够提供较大的容量，具有较好的I/O性能。S3则是一种基于Key-Value的网络存储，有人也把它叫做云存储。S3使得用户能够通过简单的API在网络上存储和读取数据。

在我们已经提到的三个IaaS软件中，OpenNebula直接使用共享文件系统作为存储，Nimbus使用了一个类似于S3的Cumulus存储服务，Eucalyptus则进一步将云硬盘和云存储分开。从架构上来看，Eucalyptus的架构和Amazon 的EC2/S3服务最为接近。

类似于S3的云存储服务使得用户能够通过简单的API在网络上存储和读取数据，但是对于数据密集型应用来说，使用S3服务可能会出现性能方面的问题。最近卡耐基梅隆大学的并行数据实验室基于Walrus云存储实现了pWalrus云存储服务。pWalrus实际上把数据存放在一个并行的文件系统上。对于互联网用户来讲，他可以通过简单的PUT和GET来读写数据;对于计算节点来讲，它既可以通过PUT和GET来读写数据，还可以直接用文件I/O的模式来读写数据。经过这样的改进后，pWalrus能够提供更好的I/O性能，也能够进一步保障数据的安全性。

4.OpenStack

OpenStack架构图(图7)看起来有点费劲，因为这张图里面的组件太多了。笔者给这些组件做一下分组，包含在橙色方框里面的是前端，包含在蓝色方框里面的是计算节点，包含在绿色方框里面的是存储服务。

图7 OpenStack架构图

在前端部分，终端用户通过nova-api访问OpenStack请求计算资源。OpenStack首先对用户进行身份认证，然后通过任务调度器(nova-scheduler)确定在哪一个计算节点上创建新的虚拟机。

在计算节点这个部分，OpenStack通过libvirt和Xen API来进行虚拟机生命周期管理。计算节点上的网络界面是通过nova-network这个组件来管理的。

在存储服务部分，OpenStack提供了两个存储组件。其中，nova-volume提供弹性块设备服务，相当于Amazon EBS;nova-objectstore提供简单存储服务，相当于Amazon S3。

OpenStack的各个组件之间不共享任何状态，各个组件之间通过中间这张图中间用红色圈出的消息队列(MQ)来进行异步通信。OpenStack中的任意组件可以安装在任意服务器上，只需要在配置文件里面指定MQ服务器的地址即可。因此，MQ可能成为整个系统的性能瓶颈。在这种情况下，可以通过增加一台MQ服务器来解决。

到现在为止，我们已经能够全面了解OpenNebula、Nimbus、Eucalyptus和OpenStack的架构。尽管每个软件的设计思路和实现细节各有千秋，但是都可以归结为三个比较大的模块：一是通常被称为云控制器的前端，包括用户界面、编程接口和任务调度组件;二是虚拟化管理，包括网络管理和虚拟机管理;三是存储服务，包括弹性块设备和简单存储服务。在这三大模块的基础上，还可以添加监控、报表、分析、计费等等外围组件。这些组件往往是运营方面的要求，不是基础架构服务的核心技术，本文就不作详细讨论了。

 功能综合比较

在了解过OpenNebula、Nimbus、Eucalyptus和OpenStack在架构上的差异之后，下面简单地比较一下这四个系统在功能上的差异。这里所说的功能，是指缺省的基本组件安装配置完毕后即可立即使用的功能，不包括尚未正式发布的试验性组件。

 

附表：四大开源IaaS软件在功能上的差异

 

首先，我们从终端用户的角度来看四大开源IaaS软件系统是不是有一个方便好用的门户或者是客户端去进行各种各样的操作。OpenNebula提供了基于浏览器的用户门户，Nimbus则提供了一个基于Java的桌面客户端，Eucalyptus和OpenStack则需要利用命令行工具或者是第三方解决方案。

在云主机、云硬盘和云存储着三类基础架构服务中，OpenNebula仅提供云主机服务，Nimbus增加了云存储服务，Eucalyptus和OpenStack都能够提供全面的服务。此外，OpenNebula的用户能够直接通过基于浏览器的VNC访问虚拟机的控制台，其他三个系统的终端用户暂时无法直接访问虚拟机的控制台。

四个系统的终端用户均可创建自定义的虚拟机模板，但是实现的难易程度有较大差别。

只有OpenNebula提供了简单的监控报表，能够报告虚拟机的处理器核内存使用状况。

在备份、恢复和用户账单等方面，四大开源软件基本还是空白。

由于缺少存储方面的某些组件，OpenNebula和Nimbus所提供的服务并不完全兼容于Amazon EC2/S3，Eucalyptus和Nimbus则是和Amazon EC2/S3完全兼容的。

其次，我们从云管理员的角度去考察这四种开源软件是不是有一个方便好用的门户或者是客户端去进行各种操作。只有OpenNebula通过SunStone提供了基本上能够用的管理门户，Nimbus干脆就没有管理员门户，Eucalyptus有一个管理员门户但是能够做的事情非常有限，OpenStack有一个正在开发中的Dashboard但是不能够算数。

在服务器监控、虚拟机监控和监控报表这个领域，只有OpenNebula提供了凑合能用的解决方案，其他三个系统都没有这方面的功能。有人会说服务器和虚拟机的监控可以通过Nagios或者是Zabbix等监控框架来实现,但是从基础架构服务的发展趋势来看，将监控组件纳入IaaS管理系统，是非常有必要的。

OpenNebula和OpenStack提供了基于命令行的虚拟机在线迁移功能，Nimbus和Eucalyptus则没有提供这个功能。

在物理机动态负载调整、虚拟机高可用性、备份与恢复、报警机制和运营计费等方面，这四个软件基本还是空白。

在一个成熟的虚拟化管理系统(例如ConVirt)中，必然会有对物理机和虚拟机的监控模块。监控模块以一定的频率记录物理机和虚拟机的处理器、内存、磁盘、网络使用状况，并以图表的方式展现给用户。当虚拟机的运行状况有问题的时候，可以自动地重启(甚至是在另外的物理服务器上重启)虚拟机，从而实现虚拟机的高可用性。在这些监控数据的基础上，可以手动甚至是自动地对物理机的负载进行调整，例如，通过在线迁移把某些负载比较轻的虚拟机整合到数量较少的服务器上，空闲出来的服务器就可以进入休眠状态从而达到节能目的。当虚拟机的负载比较重的时候，系统又可以自动唤醒某些处于休眠状态的服务器，并通过在线迁移把一些虚拟机迁移到新的服务器上。大多数VPS用户都知道他们的虚拟机是和别人的虚拟机共享一台物理机的，但是他们可能不知道在同一台物理机上所运行的虚拟机的处理器总和是超过这台物理机的处理器总和的。同样，运营商卖出去的内存总和，也是超过物理机的内存总和的。这种情况我们叫做超售，也就是over-commit。对于一个基础架构服务提供商来说，必须要有一套监控分析、在线迁移、负载调整的工具才能够在实现超售的同时提供较好的用户体验。

随着服务器性能的不断提高，数据中心虚拟化以及基础架构服务是一个不可阻挡的趋势。对于终端用户来说，他们需要的是一个简单易用的界面，只需要选择自己需要的软、硬件配置即可立即开通自己所需要的计算资源，并且随时可以看在自己账户下所有计算资源的使用状况。对于云管理员来说，他们同样需要一个的简单易用界面，能够管理一个跨越多个数据中心的基础架构，能够基于系统的运行情况自动地进行负载调整，从而实现最大的投资收益。从目前的状况来看，与其他几个IaaS软件相比较，OpenNebula能够给终端用户和云管理员提供更多的功能。但是从基础架构服务提供商的角度来看，开放源代码的IaaS解决方案要进入生产环境，还有很长的路要走。

透过社区与商业看趋势

1.数据

现在我们花一点时间从社区和商业的角度来对开源IaaS软件进行一下比较。由于Nimbus这个项目的社区规模很小，没有明显的商业诉求，我们暂时把它放在这个分析比较之外。

笔者在去年9 月份整理出2009年1月以来Eucalyptus、OpenNebula和OpenStack社区的邮件列表和论坛数据。数据显示，OpenNebula社区自2009年以来一直保持良好的发展势头，其讨论主题数、讨论帖子数和参与讨论的总人数都在稳步增长。但是该项目在 2011年4 月之后开始呈现衰落的势头。Eucalyptus社区在2010年6 月之前发展迅猛，无论是讨论主题数、讨论帖子数和参与讨论的总人数都是OpenNebula社区的两到三倍左右。但是Eucalyptus社区自2010 年6 月之后逐步衰落，尽管在2010年10月前后有过数次复兴的趋势，但是最终日渐式微并于2011年5 月前后降低到OpenNebula社区的同等水平。新兴的OpenStack社区在创立初期发展缓慢，但是从2011年1 月起呈现出爆发的势头。目前OpenStack社区的讨论主题数、讨论帖子数和参与讨论的总人数都在OpenNebula社区和Eucalyptus社区之上，但是尚未达到Eucalyptus社区在2010年6 月的规模。

通常来讲，一个讨论主题得到的回复数越多，表明该主题的讨论越深入。一个论坛或者邮件列表如果只有主帖而没有回复，说明这个社区的参与程度很低。因此，平均意义上的“讨论帖子数/讨论主题数”则反映了一个社区的参与程度。历史数据显示，OpenNebula社区和Eucalyptus社区的参与度基本上是接近的。在2010年8 月以前，Eucalyptus社区的参与度略高于OpenNebula社区。在2010年8 月以后，OpenNebula社区的参与度略高于Eucalyptus社区。但是OpenStack社区的参与度从2010年6 月项目开始之日起就高于OpenNebula社区和Ecualyptus社区。除了个别异常月份之外，OpenStack社区的参与度通常是其他两者的两倍甚至是更高。

2.人物

说到OpenStack社区的迅猛成长，就不能不提到OpenStack的社区经理(Community Manager)Stephen Spector。Stephen Spector在1997年到2010年之间一直在Citrix工作，负责软件联盟并担任Xen.org的社区经理，在社区管理方面可以说是拥有丰富的经验。他于2010年9 月跳槽到Rackspace担任OpenStack的社区经理，立即开始了一系列的广告、公关、宣传、结盟活动。通过论坛和邮件列表讨论OpenStack的人数，从无到有直到超越已经运营了两年多的Eucalyptus和OpenNebula社区，仅仅用了6 个月的时间。声明要参与OpenStack项目的公司和机构，在短短的12个月内就达到了140个之多。不过Stephen Spector在今年10月份跳槽到了戴尔负责产品和市场，未来OpenStack社区会朝哪个方向发展，还是个未知数。

Stephen Spector

很巧的是，Eucalyptus项目的社区经理Mark Atwood也是2010年9月入职的。在他入职之前，Eucalyptus社区已经开始呈现下滑的趋势。Mark Atwood入职之后，侧重于Eucalyptus企业版的宣传和推广，在开发者和用户社区这个领域并没有太大作为，导致Eucalyptus的社区活跃度进一步下滑。Eucalyptus显然已经注意到了这个问题，并且于今年10月雇佣了Greg DeKoenigsburg来负责社区方面的工作。Greg DeKoenigsburg在2004到2010年之间在RedHat工作，负责Fedora的社区工作。至于Greg DeKoenigsburg上任之后Eucalyptus社区的状况是否会有所改善，我们还需要一段时间来慢慢观察。

Mark Atwood

 

Greg DeKoenigsburg

在社区运营这一块，OpenNebula和Eucalyptus和OpenStack项目有所不同。OpenNebula项目的社区经理是一个志愿者的角色，从2009年9 月起一直由芝加哥大学的Borja Sotomayor担任。在2004到2010年之间，Borja Sotomayor在芝加哥大学计算机系读硕士和博士，并在拿到博士学位后在芝加哥大学担任讲师。可以认为，OpenNebula项目在社区建设方面的投入并不大，但它的社区发展显然是良性的，并且在近期逐步超越了曾经是如日中天的Eucalyptus社区。如果一定要为此寻找一个原因的话，我们只能够说是OpenNebula这个项目做得实在是太好了。

Borja Sotomayor

 

3.趋势

刚才我们在架构和功能的综合比较里面提到，开源IaaS解决方案要进入生产环境，还有很长的路要走。那么，开源IaaS软件将来会朝什么方向去发展，投资开发开源IaaS软件的机构的商业模式又是怎样的呢?

让我们看一看这几个开源IaaS背后的机构都在提供什么样的产品和服务吧。Eucalyptus公司一直在维护社区版和商业版两个不同的版本，今年8 月份刚刚发布的Eucalyptus 3企业版提供了高可用性、负载管理、RBAC(基于角色的访问控制)权限管理、配额管理、运营计费等等在社区版中缺失的功能。与此类似，拥有OpenNebula项目的C12G Labs同时在维护社区版和专业版两个不同的版本，并且在今年11月发布了可供商用的OpenNebula Pro 3.0。OpenStack项目的后台老板RackSpace则推出了称为RackSpace Cloud Private Edition的服务，既可以为客户建设数据中心，又可以提供私有云解决方案。

鸠摩罗什大师所译的《维摩诘所说经》中有这么一句话：“先以欲勾牵，后令入佛智。”我想，这句话完美地阐释了开源IaaS软件的发展趋势。

【作者简介】

蒋清野，Unix-Center.Net创始人。1999年获得清华大学学士学位，2000年获得美国伊里诺大学香槟分校硕士学位。曾就职于美国导航与控制公司、SUN等公司，目前供职于海南天涯在线网络科技有限公司，负责天涯云计算平台的规划和实施。蒋清野的个人博客地址为http://www.qyjohn.net/