开源IaaS云平台的分析与比较

文/贾琨

　　作为云计算的一种重要形式，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 和云计算系统开发。精通资源调度管理和分布式计算技术。