開源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來實現具體的功能。 整體系統只有一個核心部件，故在開發平臺上做得很少。