这一套幻灯片是应CSDN的邀请为12月16-17日在北京举行的软件开发2.0技术大会准备的。文字部分是在幻灯片制作完毕后起草的发言稿。由于会议延期的原因，就先把幻灯片和文字内容通过博客发布出来，请各位同行不吝指教。
【讲座主题】
大家好。感谢CSDN所提供的这个机会，使我能够和在座各位就基础构架服务方面的技术进行交流。
【个人介绍】
首先做个简单的自我介绍。我叫蒋清野，是个半路出家的程序员。在过去10年中，我为四家公司提供过服务，并且在每一家公司所做的事情都跟上家有很大的不同。在座有一些朋友认识我，可能是参加过我在Sun 公司工作期间组织的各种技术推广活动，也可能是使用过我所提供的Unix-Center.Net服务。在过去9 个月中，我短暂地为天涯社区工作，参与了天涯云计算平台的规划和实施。在这段时间里，我学习了一些与云计算 — 尤其是基础构架服务 — 有关的知识，也借助天涯社区的硬件条件做了一些测试和评估。今天这个讲座的内容，可以说是对过去9 个月里所学内容的一个总结。虽然这些总结还比较粗浅甚至是幼稚，我还是愿意通过CSDN所提供的这个平台与大家分享，希望能够得到大家的批评和指正。
（2 分钟）
【议题介绍】
今天这个讲座，主要是从构架、功能、社区和商业的角度来对OpenNebula、Nimbus、OpenStack和Eucalyptus这四个开源IaaS软件进行比较。
在构架方面，我们关心的是它包括哪些组件，各个组件之间的关系以及通讯方式，以及这样的设计会如何影响到整个系统的扩展性和伸缩性。这里我们所说的扩展性，是指为相关软件添加新的功能模块的能力。举个例子说，当新的更好的虚拟化技术出现时，云管理员能不能相对容易地为新的虚拟化技术提供支持。在伸缩性方面，我们更关心的则是相关软件能够管理多大规模的数据中心。如果它不能够管理更大规模的数据中心，其性能瓶颈主要在什么地方。
在功能方面，我们关心的是它是否能够满足用户的需求。 我们所说的用户又可以分成两个类别，一个是IaaS服务的使用者也就是终端用户，另一个是IaaS服务的提供者也就是云管理员。对于终端用户来说，他所关心的是能不能够通过这个系统方便地申请、创建、启动、休眠、唤醒、关闭、销毁虚拟机，以及方便地监控自己账户下所有虚拟机的处理器、内存、磁盘和网络使用状况。对于云管理员来说，他所关心的是能不能够通过这个系统方便地监控整个数据中心 — 甚至是多个数据中心 — 所有物理机和虚拟机的资源使用状况，能不能在尽可能少的物理机上运行尽可能多的虚拟机以达到节能减排的目的。从理论上来讲，基础构架服务的终端用户只需要关心自己所使用的虚拟机资源而不必关心虚拟机后面的技术细节。但是当云服务出现故障的时候，我们会发现终端用户比云管理员更关心云服务的高可用性、数据备份策略等等细节，并且迫切地希望存在某些途径让自己的虚拟机和别人的虚拟机得到特殊的照顾和祝福。从工程的角度来讲世界上不存在绝对不会失效的系统，但是这些需求可以转变成功能或者是产品，使得云服务提供商可以为不同的用户提供不同的服务。
为什么要关心社区？我们知道，大部分企业在选择解决方案的时候，成本是一个很重要的影响因子。最近几年“总体拥有成本”（Total Cost of Ownership, TCO）这个概念非常流行，意思就是说一个解决方案的成本包括两个部分，一个是初期的购置和安装成本，另外一个是后期的维护和服务成本。卖商业软件的通常会跟我们讲：“你买我们的解决方案，出了问题我们给你解决。你用那些开源软件，出了问题怎么办？”做我们这一行的都知道，后期的维护和服务成本类似于买保险，在大多数时候起的是心理安慰和推卸责任的作用。但是如果这个保险没有买，出了问题就只能够找社区了。因此，我们在这里专门讨论一下与这几个开源软件所关联的社区的规模、活跃度和参与度。
最后我们会花一点时间讨论一下开源软件的商业模式问题。这个问题又可以分为两个方面，一方面是开源软件开发者如何盈利，另一方面是开源软件使用者如何获得专业支持和服务。对于基础构架服务这种关键性应用来说，在软件选型过程当中如果不考虑开源软件的商业模式问题，将来可能会遇到一些意想不到的麻烦和困难。
（6 分钟）
【构架/功能 — 概述】
首先我们从构架的角度来看看基础构架服务由哪几个层面的技术组成。
左上角这个图片是虚拟化技术示意图。通过虚拟化技术，一台计算机可以被虚拟成多台计算机，每台虚拟机拥有独立的处理器、内存、硬盘和网络接口。使用虚拟化技术能够提高硬件资源的利用率，使得多个应用能够运行在同一台物理机上但是彼此隔离，各自拥有独立的操作系统和其他运行环境。这张幻灯片上所提到的Xen、KVM和VMWare等等，是已经被业界广泛认可的几种虚拟化技术。还有一些比较小众的虚拟化技术，在这里就不一一列出了。经过这么多年的发展，虚拟化技术已经非常成熟。越来越多的公司正在将虚拟机部署到生产环境中。
当我们需要在多台物理机上创建多个虚拟机并且维护多个运行环境时，我们就需要一个工具来帮助我们对物理机和虚拟机进行管理，也就是右上角这个图片里的虚拟化管理。一个相对完整的虚拟化管理系统通常会提供如下几个方面的功能。（1）通过资源池的方式对物理资源进行重新组织；（2）虚拟机生命周期管理，例如创建、启动、休眠、唤醒、关闭、迁移、销毁虚拟机；（3）将常用的运行环境保存为虚拟机模板，可以方便地创建一系列相同或者是相似的运行环境；（4）在计算资源允许的情况下提供高可用性、动态负载均衡、备份与恢复；（5）对所有的物理机和虚拟机进行监控，生成报表并在必要的情况下发出预警。这张幻灯片上所提到的Oracle VM、CloudStack和ConVirt等等，是一些比较有代表性的虚拟化管理软件。由于空间有限，很多优秀的虚拟化管理软件我就不在这里一一列出了。
虚拟化管理软件的用户，通常是运维人员，也就是管理服务器、交换机、存储和数据中心的工程师。对于实行的是集中式IT资源管理的组织来说，虚拟化管理软件大大地提高了运维部门的效率。在互联网这个行业，大家经常抱怨的就是基础设施的建设跟不上项目建设的需要，计算资源申请、采购、安装、上架、开通的流程太长。现在运维人员不再给业务部门分配物理机，而是通过虚拟化管理软件分配虚拟机，因此这个流程被大大缩短了。但是对于需要经常性地重装系统的开发和测试团队来说，他们还是需要经常性地麻烦运维人员给他们重新分配虚拟机、安装操作系统以及配置运行环境。他们迫切地希望有一个环境，能够自己完成创建、启动、休眠、唤醒、关闭、迁移、销毁等虚拟机生命周期管理任务。不仅如此，他们还希望能够通过一系列自定义的程序来自动地完成这些任务，或者是将这些功能和自己日常使用的一些工具整合在一起。与此同时，拥有大量物理服务器的单位在使用虚拟化技术以后突然发现自己的服务器买得太多了，希望通过虚拟机的方式将多余的计算资源租赁给其他单位使用。为了满足这样的需求，就出现了终端用户通过浏览器自助式申请、开通、管理计算资源的解决方案，以及通过Web Service API将虚拟机生命周期管理操作暴露给第三方应用的解决方案。终端用户绕过了运维工程师，以自助服务的方式申请、开通、管理计算资源，就是我们所谓的基础构架服务。这张幻灯片上所提到的OpenNebula、Nimbus、OpenStack和Eucalyptus是一些开源的基础构架服务软件，而Amazon、DreamHost和Linode是一些业界比较知名的基础构架服务提供商。
现在我们总结一下这张幻灯片上的内容：虚拟化技术利用单台物理机的计算资源提供多台相互独立的虚拟机，虚拟化管理软件使得运维人员能够方便地在大规模的数据中心实施虚拟化技术。而在虚拟化管理软件的基础上进行封装，使终端用户能够以自助服务的方式获得计算资源，就是我们所谓的基础构架服务。为了让大家进一步了解基础构架服务都是怎么实现的，我们接下来以OpenNebula、Nimbus、OpenStack和Eucalyptus为例子，分析一下他们的构架和功能。
（7 分钟）
【构架/功能 — OpenNebula 3.0】
接下来我们通过四张图片来展示OpenNebula 3.0在不同层次上的设计思路。
左上角这张图片是 OpenNebula的整体构架图。（1）前端（FRONT-END）通过浏览器和Web Service向云管理员和终端用户提供服务。（2）ONED是OpenNebula的核心服务进程，包括虚拟化管理模块和任务调度模块。（3）ONED通过SSH方式连接到计算节点，并通过虚拟化驱动（Drivers）来调用计算节点上的虚拟化控制命令。当计算节点使用KVM或者是VMWare ESXi作为虚拟化技术时，OpenNebula使用libvirt所提供的接口远程调用计算节点上的虚拟化控制命令。当计算节点使用Xen作为虚拟化技术时，OpenNebula通过SSH登录到计算节点执行相关的虚拟化控制命令。（4）计算节点通过前端的映像驱动（Images）获得需要运行的操作系统映像文件。需要说明的是，还有一些前端模块没有出现在这个图上。这些前端模块包括监控、用户界面和云服务API。
左下角这张图片是OpenNebula的存储结构图。OpenNebula使用映像仓库（Image Repository）来保存操作系统映像文件。这个映像仓库要能够被OpenNebula的前端直接访问，可以是SAN、NAS或者是磁盘阵列等其他存储设备。我们创建虚拟机的时候，ONED首先通过任务调度器确定将要运行该虚拟机的计算节点，然后将相应的磁盘映像文件拷贝到计算节点上，最后通过虚拟化驱动调用相应的虚拟化技术创建虚拟机并启动运行。对于一个小型的私有云来讲，可以简单地使用类似于NFS的共享文件系统方式将同一个目录挂载到前端服务器和所有的计算节点上。通过使用共享文件系统，可以缩短部署虚拟机所需要的时间，还可以方便地实现虚拟机的在线迁移。使用共享文件系统的时候需要注意的是，如果某些虚拟机频繁地进行磁盘IO操作的话，部署在同一共享文件系统上的所有虚拟机都会受到影响。在这种情况下，可以考虑将磁盘IO密集型虚拟机的磁盘映像文件缓存在计算节点上，这样只有运行在同一计算节点上的虚拟机会受到影响。
在网络方面，OpenNebula通过在计算节点上配置网桥的方式为虚拟机提供网络连接。在右上角的这张示意图上，一个计算节点配置了两个网桥，其中一个连接到公网，另外一个连接到内网。需要注意的是，在同一个计算集群中，所有计算节点的网桥配置必须是同样的。另外，OpenNebula可以通过配置文件来指定某个网络可用的IP范围，并且在创建虚拟机的时候通过配置文件直接指定虚拟机的IP，因此OpenNebula可以在没有DHCP服务器的情况下为虚拟机分配IP。除此之外，我想在座的各位对网桥的设置都不陌生了，在这里我就不再重复这些常识了。
刚才我们所提到的构架、存储和网络，都属于虚拟化管理的范畴。在虚拟化管理的基础上，OpenNebula使用一个称为SunStone的用户界面，使得云管理员和终端用户都能够通过浏览器访问被OpenNebula所管理的基础构架，在各自的权限范围内执行虚拟机生命周期管理操作，就形成了一个完整的基础构架服务系统。
（7 分钟）
【构架/功能 — Nimbus 2.8】
接下来我们看一看Nimbus这个项目。从左上角的构架图来看，Nimbus的构架设计和OpenNebula是非常相像的。用户通过浏览器界面访问Nimbus服务，管理节点通过SSH和libvirt调用计算节点上的Xen或者KVM命令。不同的地方主要有两个，一个是它通过DHCP服务器为虚拟机分配IP，另外一个是它使用了一个名为Cumulus的云存储服务。
左下角这张图是Cumulus云存储的构架图。可以看出，Cumulus由多个功能模块组成。从顶层看，它是一个与Amazon S3相兼容的云存储服务； 从底层看，它可以搭建在简单的本地硬盘或者是负责的HDFS上。在云计算这个领域，Amazon S3是事实上的云存储标准。Nimbus使用云存储来提供存储服务，从构架上来说比使用共享文件系统的OpenNebula更接近于Amazon EC2/S3。
各位可能会问，用云存储来作为基础构架服务的关键组件，在性能上会不会有问题呢？右边这两张图展示的分别是Culumus、scp、gridFtp和本地文件系统在上载和下载不同大小的文件时的吞吐量。从这两张图可以看出，当被操作的文件较小的情况下，Culumus的性能较差，但是与scp和gridFtp的性能在同一水平上；当被操作的文件大小超过1 GB的时候，Culumus的性能与本地文件系统接近。考虑到操作系统应先文件的大小通常会超过1 GB，可以认为使用Culumus来存储操作系统映像文件是没有问题的。
（3 分钟）
【构架/功能 — Eucalyptus 2.0.3】
接下来我们看一看Eucalyptus这个项目。Eucalyptus的构架和OpenNebula以及Nimbus相比有两个明显的不同。首先，在计算节点（Node Controller）和云控制器（Cloud Controller）之间，多了一个叫做集群控制器（Cluster Controller）的组件。其次，在Eucalyptus中有两个负责存储的组件，一个叫做Walrus存储控制器（Walrus Storage Controller，缩写成WS3），另外一个叫做弹性块存储（Elastic Block Storage，缩写成EBS）。
引入集群控制器这个组件后，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能够提供较大的容量，具有较好的IO性能。S3则是一种基于Key-Value的网络存储，有人也把它叫做云存储。S3使得用户能够通过简单的API在网络上存储和读取数据。
在我们已经提到的三个IaaS软件中，OpenNebula直接使用共享文件系统作为存储，Nimbus使用了一个类似于S3的Cumulus存储服务，Eucalyptus则进一步将云硬盘和云存储分开。从构架上来看，Eucalyptus的构架和Amazon 的EC2/S3服务最为接近。
类似于S3的云存储服务使得用户能够通过简单的API在网络上存储和读取数据，但是对于数据密集型应用来说，使用S3服务可能会出现性能方面的问题。最近卡耐基梅隆大学（Carnegie Mellon University，CMU）的并行数据实验室（Parallel Data Labs）基于Walrus云存储实现了pWalrus云存储服务。大家看幻灯片上右下角这张图，可以看出pWalrus把数据存放在一个并行的文件系统上。对于互联网用户来讲，他可以通过简单的PUT和GET来读写数据；对于计算节点来讲，它既可以通过PUT和GET来读写数据，还可以直接用文件IO的模式来读写数据。经过这样的改进后，pWalrus能够提供更好的IO性能，也能够进一步保障数据的安全性。
（8 分钟）
【构架/功能 — OpenStack】
接下来我们看一看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的构架。尽管每个软件的设计思路和实现细节各有千秋，但是都可以归结为三个比较大的模块：一是通常被称为云控制器的前端，包括用户界面、编程接口和任务调度组件；二是虚拟化管理，包括网络管理和虚拟机管理；三是存储服务，包括弹性块设备和简单存储服务。在这三大模块的基础上，还可以添加监控、报表、分析、计费等等外围组件。这些组件往往是运营方面的要求，不是基础构架服务的核心技术，在这里我们就不详细讨论了。
（4 分钟）
【构架/功能 — 综合比较】
在了解过OpenNebula、Nimbus、Eucalyptus和OpenStack在构架上的差异之后，我们简单地比较一下这四个系统在功能上的差异。这里所说的功能，是指缺省的基本组件安装配置完毕后即可立即使用的功能，不包括尚未正式发布的试验性组件。
首先我们从终端用户的角度来看，这个系统是不是有一个方便好用的门户或者是客户端去进行各种各样的操作。OpenNebula提供了基于浏览器的用户门户，Nimbus则提供了一个基于Java的桌面客户端，Eucalyptus和OpenStack则需要利用命令行工具或者是第三方解决方案。
在云主机、云硬盘和云存储着三类基础构架服务中，OpenNebula仅提供云主机服务，Nimbus增加了云存储服务，Eucalyptus和OpenStack都能够提供全面的服务。此外，OpenNebula的用户能够直接通过基于浏览器的VNC访问虚拟机的控制台（console），其他三个系统的终端用户暂时无法直接访问虚拟机的控制台。
四个系统的终端用户均可创建自定义的虚拟机模板，但是实现的难易程度有较大差别。
只有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解决方案要进入生产环境，还有很长的路要走。
（8 分钟）
【社区/商业 — 数据】
现在我们花一点时间从社区和商业的角度来对开源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社区的参与度通常是其他两者的两 倍甚至是更高。
（5 分钟）
【社区/商业 — 人物】
说到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月份跳槽到了戴尔（DELL）负责产品和市场，未来OpenStack社区会朝哪个方向发展，还是个未知数。
很巧的是，Eucalyptus项目的社区经理Mark Atwood也是2010年9月入职的。在他入职之前，Eucalyptus社区已经开始呈现下滑的趋势。Mark Atwood入职之后，侧重于Eucalyptus企业版的宣传和推广，在开发者和用户社区这个领域并没有太大作为，导致Eucalyptus的社区活跃度进一步下滑。Eucalyptus显然已经注意到了这个问题，并且于今年10月雇佣了Greg DeKoenigsburg来负责社区方面的工作。Greg DeKoenigsburg在2004到2010年之间在RedHat工作，负责Fedora的社区工作。至于Greg DeKoenigsburg上任之后Eucalyptus社区的状况是否会有所改善，我们还需要一段时间来慢慢观察。（很有意思的是，在Greg DeKoenigsburg加盟Eucalyptus的一个月之前，Mark Atwood就跑到Red Hat去负责开发者社区了，可见这个圈子真的是很小很小。）
在社区运营这一块，OpenNebula和Eucalyptus和OpenStack项目有所不同。OpenNebula项目的社区经理是一个志愿者的角色，从2009年9 月起一直由芝加哥大学（University of Chicago）的Borja Sotomayor担任。在2004到2010年之间，Borja Sotomayor在芝加哥大学计算机系读硕士和博士，并在拿到博士学位后在芝加哥大学担任讲师。可以认为，OpenNebula项目在社区建设方面的投入并不大，但它的社区发展显然是良性的，并且在近期逐步超越了曾经是如日中天的Eucalyptus社区。如果一定要为此寻找一个原因的话，我们只能够说是OpenNebula这个项目做得实在是太好了。
（5 分钟）
【社区/商业 — 趋势】
刚才我们在构架和功能的综合比较里面提到，开源IaaS解决方案要进入生产环境，还有很长的路要走。那么，开源IaaS软件将来会朝什么方向去发展，投资开发开源IaaS软件的机构的商业模式又是怎样的呢？让我们看一看这几个开源IaaS背后的机构都在提供什么样的产品和服务吧。Eucalyptus公司一直在维护社区版和商业版两个不同的版本，今年8 月份刚刚发布的Eucalyptus 3企业版提供了高可用性、负载管理、RBAC权限管理、配额管理、运营计费等等在社区版中缺失的功能。与此类似，拥有OpenNebula项目的C12G Labs同时在维护社区版和专业版两个不同的版本，并且在今年11月发布了可供商用的OpenNebula Pro 3.0。OpenStack项目的后台老板RackSpace则推出了称为RackSpace Cloud Private Edition的服务，既可以为客户建设数据中心，又可以提供私有云解决方案。
鸠摩罗什大师所译的《维摩诘所说经》中有这么一句话：“先以欲勾牵，后令入佛智。”我想，这句话完美地阐释了开源IaaS软件的发展趋势。
（2 分钟）
【致谢/参考资料】
今天我的讲座到这里就结束了。各位如果需要更多的资料，包括今天这个讲座的幻灯片和文本，都可以从我的博客获得。
谢谢大家
