開源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 和云計算系統開發。精通資源調度管理和分布式計算技術。來自: www.programmer.com.cn