作为云核算的一种重要办法，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和云核算体系开发。通晓资源调度办理和分布式核算技能。