开源云平台的分析与比较

做为云计算的一种重要形式，IaaS服务有各类开源和商业云平台方案。本文立足于使用开源IaaS云平台来开发公有云和私有云管理平台的角度，介绍和比较了Eucalyptus、OpenNebula、CloudStack和OpenStack等开源IaaS云平台。
从AWS当作功云平台的特色

AWS是当前最成功的云计算平台，其系统架构最大的特色就是经过Web Service接口开放数据和功能，一切以服务为第一位；并经过SOA的架构使系统达到松耦合。

AWS 提供的Web Service栈，由访问层（API、管理控制台和各类命令行等），通用服务层（身份认证、监控、部署和自动化等），PaaS层服务（并行处理、内容传输 和消息服务等），IaaS层服务（计算EC二、存储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。

从分层的角度来看，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接口，同时实现了EC二、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在分层和框架加插件设计这两点作得很好。

 

在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。

与OpenNebula相似，CloudStack自己也未采用SOA的设计，一样没有将计算/存储/网络部分从核心引擎中分离出来，所以在松耦合和组件设计上须要进一步增强。

从开发平台来看，ClousStack使用Java开发API、Management Server和Agent等部分，运行时部署为Tomcat的Serverlet。另外，还大量使用Python开发与网络和系统管理相关的部分。值得注 意的是，CloudStack代码中包括一套独立的Java代码库，涵盖通讯、数据管理、 事件管理、任务管理和插件管理等部分，基本造成了开发平台。

 

OpenStack

OpenStack是开源IaaS云平台的新兵，只有2年时间，却拥有最好的社区和生态环境，吸引了大量的公司和开发者围绕其进行云计算开发。图4为最新发布的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次之。

 

实际需求设计比较

让咱们用一个真实需求来看４个开源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和云计算系统开发。精通资源调度管理和分布式计算技术。[该贴被thinkjava于2013-02-06 23:43修改过]