作为云计算的一种重要形式，IaaS服务有各种开源和商业云平台方案。本文立足于使用开源IaaS云平台来开发公有云和私有云管理平台的角度，介绍和比较了Eucalyptus、OpenNebula、CloudStack和OpenStack等开源IaaS云平台。
从AWS看成功云平台的特点
AWS是当前最成功的云计算平台，其系统架构***的特点就是通过Web Service接口开放数据和功能，一切以服务为***位；并通过SOA的架构使系统达到松耦合。
AWS 提供的Web Service栈，由访问层（API、管理控制台和各种命令行等），通用服务层（身份认证、监控、部署和自动化等），PaaS层服务（并行处理、内容传输 和消息服务等），IaaS层服务（计算EC2、存储S3/EBS、网络服务VPC/ELB等以及数据库服务）几部分组成。用户应用使用IaaS基础IT资 源，将PaaS和通用服务作为应用架构中的组件来构建自己的服务。综合来看，AWS生态环境中系统架构的核心思想为SOA、分层和服务组合。
私有云的需求
除了AWS这类公有云平台，私有云和混合云也是IaaS的重要形式。企业对于私有云平台通常会有以下几个需求。
- 计算虚拟技术的多样选择（KVM、XEN、ESX、ESXi、Hyper-V和XenServer等）。
- 存储技术/设备的多样支持（交换机、路由器和防火墙等）。
- 网络技术/设备的多种支持（NAS、IP-SAN和FC-SAN等）。
- 多种API的支持。
前三个需求要求IaaS平台能屏蔽底层的具体技术/设备的差别对外呈现基本一致的能力与接口。这一般要采用抽象框架加插件的设计来实现。另外，基于计算虚拟化、网络和存储等技术自成体系的原因，整个架构设计中须考虑将计算虚拟化、网络和存储独立成三个子系统或服务。
因此，云平台至少应包含三层：API或接入层提供各种不同API或访问方式，核心虚拟化管理层整合底层服务来对外提供IaaS服务，计算/存储/网络服务层屏蔽技术差异。
技术团队开发需求
小型技术团队精英化，每个人都能够参与整体设计。大型团队则为金字塔结构，只有少数人能够参与整体设计，多数人员因能力和职责的原因只能接触到单个功能或模块。
为满足这两种团队的要求，云平台的整体软件架构必须做到松耦合，通过组合组件、模块和服务来构成整个系统；同时需要组件、模块和服务功能内聚以便于小团队独立维护，方便独立的设计、开发和演进。
另外，云平台需要考虑提供基础共享组件在各个服务中重用。典型的可重用组件为数据库ORM、消息通信、服务端基础框架、配置管理系统、日志系统和错误定位系 统等。很多大型团队会整合这些基础共享服务，通过领域描述语言自动化生成基础框架代码，使开发人员可以专注于具体的服务实现和关键技术研究。
云平台的介绍和比较
下面从系统架构要分层、组件化，采用SOA以达到系统松耦合；组件服务使用框架插件化设计；开发平台化等方面来比较4个开源IaaS云平台。
Eucalyptus
Eucalyptus 是最早试图克隆AWS的开源IaaS云平台，整体架构如图1的左半部分所示。Eucalyptus由云控制器（CLC）、Walrus、集群控制器 （CC）、存储控制器（SC）和节点控制器（NC）组成，它们相互协作共同提供所需的云服务。组件间使用支持WS-Security的SOAP消息实现安 全的通信。Eucalyptus对外提供兼容AWS的SOAP和Query接口，不提供其他API。
图1 Eucalyptus系统架构和CLC逻辑架构
从分层的角度来看，Eucalyptus缺乏API层设计， CLC是全局资源管理层，集群服务（CC和SC）为底层资源管理层。CLC、CC和NC三层结构不是软件架构层面的分层，只能看作一种为了管理较大规模集群的工程化方法。
从组件服务角度看，每个集群中将计算和存储服务设计为独立服务，网络仍为与计算服务的一部分。尽管Eucalyptus在代码实现上是将网络部分独立出来的，但整体上并未按照独立的服务来设计，整体设计解耦不够。
CLC 是Eucalyptus的核心，包括虚拟机控制、存储卷管理、网络资源（Address）管理、镜像管理、快照管理、Keypair管理和元数据管理等服 务模块。开源ESB Mule将所有的服务编排起来，通过Eucalyptus服务对外统一提供EC2和EBS服务，如图1的右半部分所示。由此可以看 到，Eucalyptus在SOA层面上做得较好。但ESB技术门槛高，对设计开发人员要求较高。同时因为Eucalyptus只在很少的地方支持插件 （如多Hypervisor支持的插件），所以整体上对抽象框架和插件的设计做得不多。
从开发平台的角度来看，Eucalyptus的主要 开发语言为Java和C；CLC采用开源ESB Mule为核心编排服务，架构较新颖；但CC和NC采用Apache +CGI的软件架构，基于Axis/C来实现Web Service。整体来看，Eucalyptus还没有开发平台化的趋势。
OpenNebula
OpenNebula是Reservoir项目的一部分，是2005年欧洲研究学会发起的虚拟基础设备和云端运算计划的虚拟化管理层的开源实现。OpenNebula的核心部分是Front End，即ONE。其架构如图2所示。
OpenNebula明显分为三层，即接口层、核心层和驱动层。接口层提供了原生的XML-RPC接口，同时实现了EC2、OCCI和OpenNebula Cloud API（OCA）等多种API，为用户提供了多种选择。
核心层的OpenNebula core提供统一的Hook插件管理、Request请求管理、VM生命周期管理、Hypervisor管理、网络资源管理和存储资源管理等核心功能。core配合Scheduler对外提供计算和存储网络资源管理服务。
***层是由各种Driver构成的驱动层与虚拟化软件（KVM、XEN）和物理基础设施交互。需要说明的是，图2中的驱动层没有画出DataStore、 NetworkManager等多个驱动。一些前端模块如监控、用户界面（Sunstone Portal和Self Service Portal）也未在图2中画出。很明显，OpenNebula在分层和框架加插件设计这两点做得很好。
图2 OpenNebula系统架构
在OpenNebula中，计算、存储和网络部分是ONE中独立的模块，资源调度也被分离出来通过requirement和matcher支持多种可选的策略和资源额度管理，也支持调度引擎Haizer来提供lease（租约）的高级资源调度能力。
显然，OpenNebula没有采用SOA的设计，没有将计算、存储和网络设计为独立组件，解耦做得还不够。值得注意的是，OpenNebula用 Libvirt所提供的接口远程调用计算节点上的虚拟化控制命令。这种Agentless的设计在系统安装部署阶段会减少很多软件安装配置工作，是一个设 计亮点。
从开发平台的角度来看，OpenNebula采用C++实现核心ONE，使用Ruby开发的各种Driver来实现具体的功能。整体系统只有一个核心部件，故在开发平台上做得很少。
CloudStack
CloudStack是Cloud.com开发的开源IaaS软件，被Citrix收购后贡献给Apache基金会。它已为全球多个公有云提供IaaS平台技术，如英国电信（BT）、日本电报电话公司（NTT）和韩国电信（KT）等。
图 3中的左半部分为CloudStack的总体架构，可以看到其包括Dashboard/CLI层、CLoudStack API、核心引擎层和计算/网络/存储控制器层，是典型的分层架构。具体来看，CloudStack提供原生自定义API， 也通过cloud bridge支持AWS兼容API。
图3 CloudStack系统架构和Management Server架构
与OpenNebula类似，CloudStack本身也未采用SOA的设计，同样没有将计算/存储/网络部分从核心引擎中分离出来，因此在松耦合和组件设计上需要进一步加强。
从开发平台来看，ClousStack使用Java开发API、Management Server和Agent等部分，运行时部署为Tomcat的Serverlet。另外，还大量使用Python开发与网络和系统管理相关的部分。值得注 意的是，CloudStack代码中包括一套独立的Java代码库，涵盖通信、数据管理、 事件管理、任务管理和插件管理等部分，基本形成了开发平台。
OpenStack
OpenStack是开源IaaS云平台的新兵，只有2年时间，却拥有***的社区和生态环境，吸引了大量的公司和开发者围绕其进行云计算开发。图4为***发布的Essex的逻辑架构图。
图4 OpenStack Essex逻辑架构
OpenStack 整体架构分3层，最上层为应用程序和管理Portal（Horizon）、 API等接入层；核心层包括计算服务（Nova）、存储服务（包括对象存储服务Swift和块存储服务cinder）和网络服务（Quantum）；第3 层为共享服务，现在为账户权限管理服务（keystone）和镜像服务（Glance）。其中Quantum和cinder是***加入核心服务中的 OpenStack孵化项目。
在Essex及以前版本，存储EBS（Elastic Block Service，弹性块存储服务）和Nova-Volume耦合在一起，网络服务也与Nova-Network绑定。在正在开发的Folsom版本 中，EBS和Network从Nova中独立为新的服务（cinder和Quantum）。Nova通过API来调用新的cinder和Quantum服 务。我们可以看到，OpenStack在SOA和服务化组件解耦上是做得***的。
Nova包含API Server（含CloudController）、Nova-Scheduler、Nova-Compute、Nova-Volume和Nova- Network等几部分，所有组件通过RabbitMQ来通信，使用数据库来保存数据。同时Nova中大量采用了框架与插件的设计，如Scheduler 支持插件开发新的调度算法，Compute部分支持通过插件使用不同的Hypervisor，Network和Volume部分也通过插件支持不同厂商的 技术和设备。cinder和Quantum等服务也采取了与Nova类似的整体架构和插件设计。
从开发平台的角度来看，OpenStack 做得也很好。首先，OpenStack所有服务均采用Python开发；其次，所有服务采用类似的软件架构和内部实行技术，如服务端程序使用WSGI，数 据库ORM使用SQLAlchemy，配置文件解析和日志等也采用相同的组件。基于OpenStack有很好的开发平台，我们看到开发人员可以很容易参与 多个组件的开发。
综合比较
前面分别介绍了各IaaS开源云平台在分层、SOA、组件化、解耦及开发平台等方面的情况。
从表1的对比中可以看出，所有的开源IaaS云平台在分层上做得都比较好；在SOA/组件化/解耦这点上来看，OpenStack和Eucalyptus有 优势；在框架和插件设计上，除Eucalyptus较差外，其他平台均有很好的设计——OpenStack的开发平台做得***，CloudStack次 之。综合来看，目前OpenStack的设计是***的，Eucalyptus和CloudStack次之。
表1 IaaS开源云平台比较
实际需求设计比较
让我们用一个真实需求来看４个开源IaaS平台在开发支持上的表现。此需求来自私有云场景，云平台需要对不同用户的资源请求（如VM和公网IP等）按优先级排序后进行处理，并提供任务的管理功能，如统计各状态的任务数量等。
需求的设计有两个关键点：一为如何对任务进行统一调度管理，二为任务状态转变信息的收集。
任务的统一调度管理方案分别为：OpenNebula和OpenStack都提供独立的Scheduler组件并支持扩展Scheduler的插件机 制；CloudStack有Job Manager但不提供扩展，需修改Job Manager核心代码；Eucalyptus内部流程主要由Mule总线来驱动，需修改核心流程代码增加新的模块。比较来看，OpenStack和 OpenNebula的实现方式对现有系统影响最小。
对于任务状态转变信息，由于信息遍布在系统多个地方，***的设计是通过消息发送状态变 化给负责任务管理/统计的模块统一处理。在这一点上采用Message Bus的OpenStack和采用Mule的Eucalyptus有明显优势。综合来看，OpenStack为二次开发提供了很好的支持。
技术之外
上述比较主要是在设计方面，OpenStack优势显著。但从其他方面来看：
- Eucalyptus由于出现最早，同时与AWS签订相关API兼容协议，在面向AWS生态环境的私有云市场处于领先地位；
- CloudStack在经过大量商业客户公有云的部署后，其功能已趋于稳定成熟，成为Apache开源项目后，其松耦合设计也已排上日程，设计上大有迎头赶上的趋势；
- OpenStack现状是功能不够完整且商业支持不够，另其转为基金会运作后能否保持现在的发展趋势也是大家非常关注的。在实际的云平台选择过程中，大家要从自身的角度出发综合考虑功能和系统的架构与设计、未来发展等。
作者简介：作者贾琨，天云融创云平台开发工程师和架构师。从2005年起从事Web、分布式、网格、HPC和云计算系统开发。精通资源调度管理和分布式计算技术。
