本文作者：蔣清野

在架構方面，我們關心的是它包括哪些組件，各個組件之間的關系和通信方式，以及這樣的設計會如何影響到整個系統的擴展性和伸縮性。這里所說的擴展性，是指為相關軟件添加新的功能模塊的能力。例如，當新的虛擬化技術出現時，云管理員能不能相對容易地為新的虛擬化技術提供支持。在伸縮性方面，我們關心的是相關軟件究竟能夠管理多大規模的數據中心，如果它不能夠管理更大規模的數據中心，其性能瓶頸主要在什么地方。

在功能方面，我們關心它是否能夠滿足用戶的需求。我們所說的用戶包括兩個類別，一個是IaaS服務的使用者，即終端用戶，另一個是IaaS服務的提供者，也就是云管理員。對終端用戶來說，他所關心的是能不能夠通過這個系統方便地申請、創建、啟動、休眠、喚醒、關閉、銷毀虛擬機，以及方便地監控自己賬戶下所有虛擬機的處理器、內存、磁盤和網絡使用狀況。對于云管理員來說，他關心的是能不能夠通過這個系統方便地監控整個數據中心(甚至是多個數據中心)所有物理機和虛擬機的資源使用狀況，能不能在盡可能少的物理機上運行盡可能多的虛擬機以達到節能減排的目的。從理論上來講，基礎架構服務的終端用戶只需要關心自己所使用的虛擬機資源而不必關心虛擬機后面的技術細節。但是當云服務出現故障的時候，我們會發現終端用戶比云管理員更關心云服務的高可用性、數據備份策略等細節，并且迫切地希望存在某些途徑讓自己的虛擬機和別人的虛擬機得到特殊的照顧。從工程的角度來講世界上不存在絕對不會失效的系統，但是這些需求可以轉變成功能或者是產品，使得云服務提供商可以為不同的用戶提供不同的服務。

為什么要關心社區?使用開源軟件，出了問題就只能夠找社區了。因此，我們需要專門討論一下與這幾個開源軟件所關聯的社區的規模、活躍度和參與度。

此外，開源軟件的商業模式問題也值得關注。這個問題又可以分為兩個方面，一方面是開源軟件開發者如何盈利，另一方面是開源軟件使用者如何獲得專業支持和服務。對于基礎架構服務這種關鍵性應用來說，在軟件選型過程當中如果不考慮開源軟件的商業模式問題，將來可能會遇到一些麻煩。

架構詳解

1.OpenNebula 3.0

圖1是OpenNebula的整體架構圖。前端(FRONT-END)通過瀏覽器和Web Service向云管理員和終端用戶提供服務。ONED是OpenNebula的核心服務進程，包括虛擬化管理模塊和任務調度模塊。ONED通過SSH方式連接到計算節點，并通過虛擬化驅動(Drivers)來調用計算節點上的虛擬化控制命令。當計算節點使用KVM或者是VMWare ESXi作為虛擬化技術時，OpenNebula使用libvirt所提供的接口遠程調用計算節點上的虛擬化控制命令。當計算節點使用Xen作為虛擬化技術時，OpenNebula通過SSH登錄到計算節點執行相關的虛擬化控制命令。計算節點通過前端的映像驅動(Images)獲得需要運行的操作系統映像文件。需要說明的是，還有監控、用戶界面和云服務API等一些前端模塊沒有出現在該圖上。

圖1 OpenNebula整體架構圖

圖2是OpenNebula的存儲結構圖。OpenNebula使用映像倉庫(Image Repository)來保存操作系統映像文件。這個映像倉庫要能夠被OpenNebula的前端直接訪問，可以是SAN、NAS或者是磁盤陣列等其他存儲設備。我們創建虛擬機的時候，ONED首先通過任務調度器確定將要運行該虛擬機的計算節點，然后將相應的磁盤映像文件拷貝到計算節點上，最后通過虛擬化驅動調用相應的虛擬化技術創建虛擬機并啟動運行。對于一個小型的私有云來講，可以簡單地使用類似于NFS的共享文件系統方式將同一個目錄掛載到前端服務器和所有的計算節點上。通過使用共享文件系統，可以縮短部署虛擬機所需要的時間，還可以方便地實現虛擬機的在線遷移。使用共享文件系統的時候需要注意的是，如果某些虛擬機頻繁地進行磁盤IO操作的話，部署在同一共享文件系統上的所有虛擬機都會受到影響。在這種情況下，可以考慮將磁盤I/O密集型虛擬機的磁盤映像文件緩存在計算節點上，這樣只有運行在同一計算節點上的虛擬機會受到影響。

圖2 OpenNebula存儲結構圖

在網絡方面，OpenNebula通過在計算節點上配置網橋的方式為虛擬機提供網絡連接。如圖3所示，一個計算節點配置了兩個網橋，其中一個連接到公網，另外一個連接到內網。需要注意的是，在同一個計算集群中，所有計算節點的網橋配置必須是同樣的。另外，OpenNebula可以通過配置文件來指定某個網絡可用的IP范圍，并且在創建虛擬機的時候通過配置文件直接指定虛擬機的IP，因此OpenNebula可以在沒有DHCP服務器的情況下為虛擬機分配IP。

圖3 OpenNebula網絡結構圖

剛才我們所提到的架構、存儲和網絡，都屬于虛擬化管理的范疇。在虛擬化管理的基礎上，OpenNebula使用一個稱為SunStone的用戶界面，使得云管理員和終端用戶都能夠通過瀏覽器訪問被OpenNebula所管理的基礎架構，在各自的權限范圍內執行虛擬機生命周期管理操作，就形成了一個完整的基礎架構服務系統。

2.Nimbus 2.8

接下來我們看一看Nimbus這個項目。從架構圖(圖4)來看，Nimbus的架構設計和OpenNebula是非常相像的。用戶通過瀏覽器界面訪問Nimbus服務，管理節點通過SSH和libvirt調用計算節點上的Xen或者KVM命令。不同的地方主要有兩個，一個是它通過DHCP服務器為虛擬機分配IP，另一個是它使用了一個名為Cumulus的云存儲服務。

圖4 Nimbus整體架構圖

圖5是Cumulus云存儲的架構圖。可以看出，Cumulus由多個功能模塊組成。從頂層看，它是一個與Amazon S3相兼容的云存儲服務;從底層看，它可以搭建在簡單的本地硬盤或者是負責的HDFS上。在云計算這個領域，Amazon S3是事實上的云存儲標準。Nimbus使用云存儲來提供存儲服務，從架構上來說比使用共享文件系統的OpenNebula更接近于Amazon EC2/S3。

圖5 Cumulus云存儲架構圖

讀者可能會問，用云存儲來作為基礎架構服務的關鍵組件，在性能上會不會有問題呢?我們測試過Culumus、scp、gridFtp和本地文件系統在上載和下載不同大小的文件時的吞吐量。測試結果顯示，當被操作的文件較小的情況下，Culumus的性能較差，但是與scp和gridFtp的性能在同一水平上;當被操作的文件大小超過1GB的時候，Culumus的性能與本地文件系統接近。考慮到操作系統映像文件的大小通常會超過1 GB，可以認為使用Culumus來存儲操作系統映像文件是沒有問題的。

 

3.Eucalyp 2.0.3

Eucalyptus的架構(圖6)和OpenNebula以及Nimbus相比有兩個明顯的不同。首先，在計算節點(Node Controller)和云控制器(Cloud Controller)之間，多了一個叫做集群控制器(Cluster Controller)的組件。其次，在Eucalyptus中有兩個負責存儲的組件，一個叫做Walrus存儲控制器(Walrus Storage Controller，WS3)，另外一個叫做彈性塊存儲(Elastic Block Storage，EBS)。

圖6：Eucalyp 2.0.3架構圖

引入集群控制器這個組件后，Eucalyptus中的虛擬化管理功能就由集群控制器來承擔。也就是說，當用戶向Eucalyptus的云控制器請求計算資源的時候，Eucalyptus的云控制器根據各個計算集群的資源使用狀況將用戶的請求轉發給某個計算集群的集群控制器，集群控制器再根據本集群中各個計算節點的資源使用狀況決定在哪個計算節點上創建和運行虛擬機。

如果將Eucalyptus的架構和OpenNebula以及Nimbus的架構來做個比較，可以看出Eucalyptus的計算集群和OpenNebula以及Nimbus在功能上基本是等價的。我們知道，當計算節點的數量較多的時候，虛擬化管理模塊，以及系統監控模塊的壓力就會比較大，可能會影響到整個系統的性能。假定Eucalyptus、OpenNebula以及Nimbus的虛擬化管理模塊的實現水平是相當的，當OpenNebula和Nimbus由于計算節點數量增加而出現性能問題的時候，Eucalyptus可以通過增加計算集群的方法來實現橫向擴展。從這個意義上說，Eucalyptus的架構設計提供了更大程度的擴展性，能夠支撐更大規模的基礎架構。

剛才我們說到，Eucalyptus中有兩個負責存儲的組件。一個是WS3，與Amazon的簡單存儲服務(Simple Storage Service，S3)相對應;另外一個是EBS，與Amazon的彈性塊存儲(Elastic Block Store，EBS)相對應。EBS可以被當做塊設備掛載到虛擬機上，相當于云硬盤。EBS能夠提供較大的容量，具有較好的I/O性能。S3則是一種基于Key-Value的網絡存儲，有人也把它叫做云存儲。S3使得用戶能夠通過簡單的API在網絡上存儲和讀取數據。

在我們已經提到的三個IaaS軟件中，OpenNebula直接使用共享文件系統作為存儲，Nimbus使用了一個類似于S3的Cumulus存儲服務，Eucalyptus則進一步將云硬盤和云存儲分開。從架構上來看，Eucalyptus的架構和Amazon 的EC2/S3服務最為接近。

類似于S3的云存儲服務使得用戶能夠通過簡單的API在網絡上存儲和讀取數據，但是對于數據密集型應用來說，使用S3服務可能會出現性能方面的問題。最近卡耐基梅隆大學的并行數據實驗室基于Walrus云存儲實現了pWalrus云存儲服務。pWalrus實際上把數據存放在一個并行的文件系統上。對于互聯網用戶來講，他可以通過簡單的PUT和GET來讀寫數據;對于計算節點來講，它既可以通過PUT和GET來讀寫數據，還可以直接用文件I/O的模式來讀寫數據。經過這樣的改進后，pWalrus能夠提供更好的I/O性能，也能夠進一步保障數據的安全性。

4.OpenStack

OpenStack架構圖(圖7)看起來有點費勁，因為這張圖里面的組件太多了。筆者給這些組件做一下分組，包含在橙色方框里面的是前端，包含在藍色方框里面的是計算節點，包含在綠色方框里面的是存儲服務。

圖7 OpenStack架構圖

在前端部分，終端用戶通過nova-api訪問OpenStack請求計算資源。OpenStack首先對用戶進行身份認證，然后通過任務調度器(nova-scheduler)確定在哪一個計算節點上創建新的虛擬機。

在計算節點這個部分，OpenStack通過libvirt和Xen API來進行虛擬機生命周期管理。計算節點上的網絡界面是通過nova-network這個組件來管理的。

在存儲服務部分，OpenStack提供了兩個存儲組件。其中，nova-volume提供彈性塊設備服務，相當于Amazon EBS;nova-objectstore提供簡單存儲服務，相當于Amazon S3。

OpenStack的各個組件之間不共享任何狀態，各個組件之間通過中間這張圖中間用紅色圈出的消息隊列(MQ)來進行異步通信。OpenStack中的任意組件可以安裝在任意服務器上，只需要在配置文件里面指定MQ服務器的地址即可。因此，MQ可能成為整個系統的性能瓶頸。在這種情況下，可以通過增加一臺MQ服務器來解決。

到現在為止，我們已經能夠全面了解OpenNebula、Nimbus、Eucalyptus和OpenStack的架構。盡管每個軟件的設計思路和實現細節各有千秋，但是都可以歸結為三個比較大的模塊：一是通常被稱為云控制器的前端，包括用戶界面、編程接口和任務調度組件;二是虛擬化管理，包括網絡管理和虛擬機管理;三是存儲服務，包括彈性塊設備和簡單存儲服務。在這三大模塊的基礎上，還可以添加監控、報表、分析、計費等等外圍組件。這些組件往往是運營方面的要求，不是基礎架構服務的核心技術，本文就不作詳細討論了。

 功能綜合比較

在了解過OpenNebula、Nimbus、Eucalyptus和OpenStack在架構上的差異之后，下面簡單地比較一下這四個系統在功能上的差異。這里所說的功能，是指缺省的基本組件安裝配置完畢后即可立即使用的功能，不包括尚未正式發布的試驗性組件。

 

附表：四大開源IaaS軟件在功能上的差異

 

首先，我們從終端用戶的角度來看四大開源IaaS軟件系統是不是有一個方便好用的門戶或者是客戶端去進行各種各樣的操作。OpenNebula提供了基于瀏覽器的用戶門戶，Nimbus則提供了一個基于Java的桌面客戶端，Eucalyptus和OpenStack則需要利用命令行工具或者是第三方解決方案。

在云主機、云硬盤和云存儲著三類基礎架構服務中，OpenNebula僅提供云主機服務，Nimbus增加了云存儲服務，Eucalyptus和OpenStack都能夠提供全面的服務。此外，OpenNebula的用戶能夠直接通過基于瀏覽器的VNC訪問虛擬機的控制臺，其他三個系統的終端用戶暫時無法直接訪問虛擬機的控制臺。

四個系統的終端用戶均可創建自定義的虛擬機模板，但是實現的難易程度有較大差別。

只有OpenNebula提供了簡單的監控報表，能夠報告虛擬機的處理器核內存使用狀況。

在備份、恢復和用戶賬單等方面，四大開源軟件基本還是空白。

由于缺少存儲方面的某些組件，OpenNebula和Nimbus所提供的服務并不完全兼容于Amazon EC2/S3，Eucalyptus和Nimbus則是和Amazon EC2/S3完全兼容的。

其次，我們從云管理員的角度去考察這四種開源軟件是不是有一個方便好用的門戶或者是客戶端去進行各種操作。只有OpenNebula通過SunStone提供了基本上能夠用的管理門戶，Nimbus干脆就沒有管理員門戶，Eucalyptus有一個管理員門戶但是能夠做的事情非常有限，OpenStack有一個正在開發中的Dashboard但是不能夠算數。

在服務器監控、虛擬機監控和監控報表這個領域，只有OpenNebula提供了湊合能用的解決方案，其他三個系統都沒有這方面的功能。有人會說服務器和虛擬機的監控可以通過Nagios或者是Zabbix等監控框架來實現,但是從基礎架構服務的發展趨勢來看，將監控組件納入IaaS管理系統，是非常有必要的。

OpenNebula和OpenStack提供了基于命令行的虛擬機在線遷移功能，Nimbus和Eucalyptus則沒有提供這個功能。

在物理機動態負載調整、虛擬機高可用性、備份與恢復、報警機制和運營計費等方面，這四個軟件基本還是空白。

在一個成熟的虛擬化管理系統(例如ConVirt)中，必然會有對物理機和虛擬機的監控模塊。監控模塊以一定的頻率記錄物理機和虛擬機的處理器、內存、磁盤、網絡使用狀況，并以圖表的方式展現給用戶。當虛擬機的運行狀況有問題的時候，可以自動地重啟(甚至是在另外的物理服務器上重啟)虛擬機，從而實現虛擬機的高可用性。在這些監控數據的基礎上，可以手動甚至是自動地對物理機的負載進行調整，例如，通過在線遷移把某些負載比較輕的虛擬機整合到數量較少的服務器上，空閑出來的服務器就可以進入休眠狀態從而達到節能目的。當虛擬機的負載比較重的時候，系統又可以自動喚醒某些處于休眠狀態的服務器，并通過在線遷移把一些虛擬機遷移到新的服務器上。大多數VPS用戶都知道他們的虛擬機是和別人的虛擬機共享一臺物理機的，但是他們可能不知道在同一臺物理機上所運行的虛擬機的處理器總和是超過這臺物理機的處理器總和的。同樣，運營商賣出去的內存總和，也是超過物理機的內存總和的。這種情況我們叫做超售，也就是over-commit。對于一個基礎架構服務提供商來說，必須要有一套監控分析、在線遷移、負載調整的工具才能夠在實現超售的同時提供較好的用戶體驗。

隨著服務器性能的不斷提高，數據中心虛擬化以及基礎架構服務是一個不可阻擋的趨勢。對于終端用戶來說，他們需要的是一個簡單易用的界面，只需要選擇自己需要的軟、硬件配置即可立即開通自己所需要的計算資源，并且隨時可以看在自己賬戶下所有計算資源的使用狀況。對于云管理員來說，他們同樣需要一個的簡單易用界面，能夠管理一個跨越多個數據中心的基礎架構，能夠基于系統的運行情況自動地進行負載調整，從而實現最大的投資收益。從目前的狀況來看，與其他幾個IaaS軟件相比較，OpenNebula能夠給終端用戶和云管理員提供更多的功能。但是從基礎架構服務提供商的角度來看，開放源代碼的IaaS解決方案要進入生產環境，還有很長的路要走。

透過社區與商業看趨勢

1.數據

現在我們花一點時間從社區和商業的角度來對開源IaaS軟件進行一下比較。由于Nimbus這個項目的社區規模很小，沒有明顯的商業訴求，我們暫時把它放在這個分析比較之外。

筆者在去年9 月份整理出2009年1月以來Eucalyptus、OpenNebula和OpenStack社區的郵件列表和論壇數據。數據顯示，OpenNebula社區自2009年以來一直保持良好的發展勢頭，其討論主題數、討論帖子數和參與討論的總人數都在穩步增長。但是該項目在 2011年4 月之后開始呈現衰落的勢頭。Eucalyptus社區在2010年6 月之前發展迅猛，無論是討論主題數、討論帖子數和參與討論的總人數都是OpenNebula社區的兩到三倍左右。但是Eucalyptus社區自2010 年6 月之后逐步衰落，盡管在2010年10月前后有過數次復興的趨勢，但是最終日漸式微并于2011年5 月前后降低到OpenNebula社區的同等水平。新興的OpenStack社區在創立初期發展緩慢，但是從2011年1 月起呈現出爆發的勢頭。目前OpenStack社區的討論主題數、討論帖子數和參與討論的總人數都在OpenNebula社區和Eucalyptus社區之上，但是尚未達到Eucalyptus社區在2010年6 月的規模。

通常來講，一個討論主題得到的回復數越多，表明該主題的討論越深入。一個論壇或者郵件列表如果只有主帖而沒有回復，說明這個社區的參與程度很低。因此，平均意義上的“討論帖子數/討論主題數”則反映了一個社區的參與程度。歷史數據顯示，OpenNebula社區和Eucalyptus社區的參與度基本上是接近的。在2010年8 月以前，Eucalyptus社區的參與度略高于OpenNebula社區。在2010年8 月以后，OpenNebula社區的參與度略高于Eucalyptus社區。但是OpenStack社區的參與度從2010年6 月項目開始之日起就高于OpenNebula社區和Ecualyptus社區。除了個別異常月份之外，OpenStack社區的參與度通常是其他兩者的兩倍甚至是更高。

2.人物

說到OpenStack社區的迅猛成長，就不能不提到OpenStack的社區經理(Community Manager)Stephen Spector。Stephen Spector在1997年到2010年之間一直在Citrix工作，負責軟件聯盟并擔任Xen.org的社區經理，在社區管理方面可以說是擁有豐富的經驗。他于2010年9 月跳槽到Rackspace擔任OpenStack的社區經理，立即開始了一系列的廣告、公關、宣傳、結盟活動。通過論壇和郵件列表討論OpenStack的人數，從無到有直到超越已經運營了兩年多的Eucalyptus和OpenNebula社區，僅僅用了6 個月的時間。聲明要參與OpenStack項目的公司和機構，在短短的12個月內就達到了140個之多。不過Stephen Spector在今年10月份跳槽到了戴爾負責產品和市場，未來OpenStack社區會朝哪個方向發展，還是個未知數。

Stephen Spector

很巧的是，Eucalyptus項目的社區經理Mark Atwood也是2010年9月入職的。在他入職之前，Eucalyptus社區已經開始呈現下滑的趨勢。Mark Atwood入職之后，側重于Eucalyptus企業版的宣傳和推廣，在開發者和用戶社區這個領域并沒有太大作為，導致Eucalyptus的社區活躍度進一步下滑。Eucalyptus顯然已經注意到了這個問題，并且于今年10月雇傭了Greg DeKoenigsburg來負責社區方面的工作。Greg DeKoenigsburg在2004到2010年之間在RedHat工作，負責Fedora的社區工作。至于Greg DeKoenigsburg上任之后Eucalyptus社區的狀況是否會有所改善，我們還需要一段時間來慢慢觀察。

Mark Atwood

 

Greg DeKoenigsburg

在社區運營這一塊，OpenNebula和Eucalyptus和OpenStack項目有所不同。OpenNebula項目的社區經理是一個志愿者的角色，從2009年9 月起一直由芝加哥大學的Borja Sotomayor擔任。在2004到2010年之間，Borja Sotomayor在芝加哥大學計算機系讀碩士和博士，并在拿到博士學位后在芝加哥大學擔任講師。可以認為，OpenNebula項目在社區建設方面的投入并不大，但它的社區發展顯然是良性的，并且在近期逐步超越了曾經是如日中天的Eucalyptus社區。如果一定要為此尋找一個原因的話，我們只能夠說是OpenNebula這個項目做得實在是太好了。

Borja Sotomayor

 

3.趨勢

剛才我們在架構和功能的綜合比較里面提到，開源IaaS解決方案要進入生產環境，還有很長的路要走。那么，開源IaaS軟件將來會朝什么方向去發展，投資開發開源IaaS軟件的機構的商業模式又是怎樣的呢?

讓我們看一看這幾個開源IaaS背后的機構都在提供什么樣的產品和服務吧。Eucalyptus公司一直在維護社區版和商業版兩個不同的版本，今年8 月份剛剛發布的Eucalyptus 3企業版提供了高可用性、負載管理、RBAC(基于角色的訪問控制)權限管理、配額管理、運營計費等等在社區版中缺失的功能。與此類似，擁有OpenNebula項目的C12G Labs同時在維護社區版和專業版兩個不同的版本，并且在今年11月發布了可供商用的OpenNebula Pro 3.0。OpenStack項目的后臺老板RackSpace則推出了稱為RackSpace Cloud Private Edition的服務，既可以為客戶建設數據中心，又可以提供私有云解決方案。

鳩摩羅什大師所譯的《維摩詰所說經》中有這么一句話：“先以欲勾牽，后令入佛智。”我想，這句話完美地闡釋了開源IaaS軟件的發展趨勢。

【作者簡介】

蔣清野，Unix-Center.Net創始人。1999年獲得清華大學學士學位，2000年獲得美國伊里諾大學香檳分校碩士學位。曾就職于美國導航與控制公司、SUN等公司，目前供職于海南天涯在線網絡科技有限公司，負責天涯云計算平臺的規劃和實施。蔣清野的個人博客地址為http://www.qyjohn.net/