開源雲平臺的分析與比較

做爲雲計算的一種重要形式，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修改過]