這一套幻燈片是應CSDN的邀請爲12月16-17日在北京舉行的軟件開發2.0技術大會準備的。文字部分是在幻燈片製作完畢後起草的發言稿。由於會議延期的原因，就先把幻燈片和文字內容通過博客發佈出來，請各位同行不吝指教。
【講座主題】
大家好。感謝CSDN所提供的這個機會，使我能夠和在座各位就基礎構架服務方面的技術進行交流。
【個人介紹】
首先做個簡單的自我介紹。我叫蔣清野，是個半路出家的程序員。在過去10年中，我爲四家公司提供過服務，並且在每一家公司所做的事情都跟上家有很大的不同。在座有一些朋友認識我，可能是參加過我在Sun 公司工作期間組織的各種技術推廣活動，也可能是使用過我所提供的Unix-Center.Net服務。在過去9 個月中，我短暫地爲天涯社區工作，參與了天涯雲計算平臺的規劃和實施。在這段時間裏，我學習了一些與雲計算 — 尤其是基礎構架服務 — 有關的知識，也藉助天涯社區的硬件條件做了一些測試和評估。今天這個講座的內容，可以說是對過去9 個月裏所學內容的一個總結。雖然這些總結還比較粗淺甚至是幼稚，我還是願意通過CSDN所提供的這個平臺與大家分享，希望能夠得到大家的批評和指正。
（2 分鐘）
【議題介紹】
今天這個講座，主要是從構架、功能、社區和商業的角度來對OpenNebula、Nimbus、OpenStack和Eucalyptus這四個開源IaaS軟件進行比較。
在構架方面，我們關心的是它包括哪些組件，各個組件之間的關係以及通訊方式，以及這樣的設計會如何影響到整個系統的擴展性和伸縮性。這裏我們所說的擴展性，是指爲相關軟件添加新的功能模塊的能力。舉個例子說，當新的更好的虛擬化技術出現時，雲管理員能不能相對容易地爲新的虛擬化技術提供支持。在伸縮性方面，我們更關心的則是相關軟件能夠管理多大規模的數據中心。如果它不能夠管理更大規模的數據中心，其性能瓶頸主要在什麼地方。
在功能方面，我們關心的是它是否能夠滿足用戶的需求。 我們所說的用戶又可以分成兩個類別，一個是IaaS服務的使用者也就是終端用戶，另一個是IaaS服務的提供者也就是雲管理員。對於終端用戶來說，他所關心的是能不能夠通過這個系統方便地申請、創建、啓動、休眠、喚醒、關閉、銷燬虛擬機，以及方便地監控自己賬戶下所有虛擬機的處理器、內存、磁盤和網絡使用狀況。對於雲管理員來說，他所關心的是能不能夠通過這個系統方便地監控整個數據中心 — 甚至是多個數據中心 — 所有物理機和虛擬機的資源使用狀況，能不能在儘可能少的物理機上運行儘可能多的虛擬機以達到節能減排的目的。從理論上來講，基礎構架服務的終端用戶只需要關心自己所使用的虛擬機資源而不必關心虛擬機後面的技術細節。但是當雲服務出現故障的時候，我們會發現終端用戶比雲管理員更關心雲服務的高可用性、數據備份策略等等細節，並且迫切地希望存在某些途徑讓自己的虛擬機和別人的虛擬機得到特殊的照顧和祝福。從工程的角度來講世界上不存在絕對不會失效的系統，但是這些需求可以轉變成功能或者是產品，使得雲服務提供商可以爲不同的用戶提供不同的服務。
爲什麼要關心社區？我們知道，大部分企業在選擇解決方案的時候，成本是一個很重要的影響因子。最近幾年“總體擁有成本”（Total Cost of Ownership, TCO）這個概念非常流行，意思就是說一個解決方案的成本包括兩個部分，一個是初期的購置和安裝成本，另外一個是後期的維護和服務成本。賣商業軟件的通常會跟我們講：“你買我們的解決方案，出了問題我們給你解決。你用那些開源軟件，出了問題怎麼辦？”做我們這一行的都知道，後期的維護和服務成本類似於買保險，在大多數時候起的是心理安慰和推卸責任的作用。但是如果這個保險沒有買，出了問題就只能夠找社區了。因此，我們在這裏專門討論一下與這幾個開源軟件所關聯的社區的規模、活躍度和參與度。
最後我們會花一點時間討論一下開源軟件的商業模式問題。這個問題又可以分爲兩個方面，一方面是開源軟件開發者如何盈利，另一方面是開源軟件使用者如何獲得專業支持和服務。對於基礎構架服務這種關鍵性應用來說，在軟件選型過程當中如果不考慮開源軟件的商業模式問題，將來可能會遇到一些意想不到的麻煩和困難。
（6 分鐘）
【構架/功能 — 概述】
首先我們從構架的角度來看看基礎構架服務由哪幾個層面的技術組成。
左上角這個圖片是虛擬化技術示意圖。通過虛擬化技術，一臺計算機可以被虛擬成多臺計算機，每臺虛擬機擁有獨立的處理器、內存、硬盤和網絡接口。使用虛擬化技術能夠提高硬件資源的利用率，使得多個應用能夠運行在同一臺物理機上但是彼此隔離，各自擁有獨立的操作系統和其他運行環境。這張幻燈片上所提到的Xen、KVM和VMWare等等，是已經被業界廣泛認可的幾種虛擬化技術。還有一些比較小衆的虛擬化技術，在這裏就不一一列出了。經過這麼多年的發展，虛擬化技術已經非常成熟。越來越多的公司正在將虛擬機部署到生產環境中。
當我們需要在多臺物理機上創建多個虛擬機並且維護多個運行環境時，我們就需要一個工具來幫助我們對物理機和虛擬機進行管理，也就是右上角這個圖片裏的虛擬化管理。一個相對完整的虛擬化管理系統通常會提供如下幾個方面的功能。（1）通過資源池的方式對物理資源進行重新組織；（2）虛擬機生命週期管理，例如創建、啓動、休眠、喚醒、關閉、遷移、銷燬虛擬機；（3）將常用的運行環境保存爲虛擬機模板，可以方便地創建一系列相同或者是相似的運行環境；（4）在計算資源允許的情況下提供高可用性、動態負載均衡、備份與恢復；（5）對所有的物理機和虛擬機進行監控，生成報表並在必要的情況下發出預警。這張幻燈片上所提到的Oracle VM、CloudStack和ConVirt等等，是一些比較有代表性的虛擬化管理軟件。由於空間有限，很多優秀的虛擬化管理軟件我就不在這裏一一列出了。
虛擬化管理軟件的用戶，通常是運維人員，也就是管理服務器、交換機、存儲和數據中心的工程師。對於實行的是集中式IT資源管理的組織來說，虛擬化管理軟件大大地提高了運維部門的效率。在互聯網這個行業，大家經常抱怨的就是基礎設施的建設跟不上項目建設的需要，計算資源申請、採購、安裝、上架、開通的流程太長。現在運維人員不再給業務部門分配物理機，而是通過虛擬化管理軟件分配虛擬機，因此這個流程被大大縮短了。但是對於需要經常性地重裝系統的開發和測試團隊來說，他們還是需要經常性地麻煩運維人員給他們重新分配虛擬機、安裝操作系統以及配置運行環境。他們迫切地希望有一個環境，能夠自己完成創建、啓動、休眠、喚醒、關閉、遷移、銷燬等虛擬機生命週期管理任務。不僅如此，他們還希望能夠通過一系列自定義的程序來自動地完成這些任務，或者是將這些功能和自己日常使用的一些工具整合在一起。與此同時，擁有大量物理服務器的單位在使用虛擬化技術以後突然發現自己的服務器買得太多了，希望通過虛擬機的方式將多餘的計算資源租賃給其他單位使用。爲了滿足這樣的需求，就出現了終端用戶通過瀏覽器自助式申請、開通、管理計算資源的解決方案，以及通過Web Service API將虛擬機生命週期管理操作暴露給第三方應用的解決方案。終端用戶繞過了運維工程師，以自助服務的方式申請、開通、管理計算資源，就是我們所謂的基礎構架服務。這張幻燈片上所提到的OpenNebula、Nimbus、OpenStack和Eucalyptus是一些開源的基礎構架服務軟件，而Amazon、DreamHost和Linode是一些業界比較知名的基礎構架服務提供商。
現在我們總結一下這張幻燈片上的內容：虛擬化技術利用單臺物理機的計算資源提供多臺相互獨立的虛擬機，虛擬化管理軟件使得運維人員能夠方便地在大規模的數據中心實施虛擬化技術。而在虛擬化管理軟件的基礎上進行封裝，使終端用戶能夠以自助服務的方式獲得計算資源，就是我們所謂的基礎構架服務。爲了讓大家進一步瞭解基礎構架服務都是怎麼實現的，我們接下來以OpenNebula、Nimbus、OpenStack和Eucalyptus爲例子，分析一下他們的構架和功能。
（7 分鐘）
【構架/功能 — OpenNebula 3.0】
接下來我們通過四張圖片來展示OpenNebula 3.0在不同層次上的設計思路。
左上角這張圖片是 OpenNebula的整體構架圖。（1）前端（FRONT-END）通過瀏覽器和Web Service向雲管理員和終端用戶提供服務。（2）ONED是OpenNebula的核心服務進程，包括虛擬化管理模塊和任務調度模塊。（3）ONED通過SSH方式連接到計算節點，並通過虛擬化驅動（Drivers）來調用計算節點上的虛擬化控制命令。當計算節點使用KVM或者是VMWare ESXi作爲虛擬化技術時，OpenNebula使用libvirt所提供的接口遠程調用計算節點上的虛擬化控制命令。當計算節點使用Xen作爲虛擬化技術時，OpenNebula通過SSH登錄到計算節點執行相關的虛擬化控制命令。（4）計算節點通過前端的映像驅動（Images）獲得需要運行的操作系統映像文件。需要說明的是，還有一些前端模塊沒有出現在這個圖上。這些前端模塊包括監控、用戶界面和雲服務API。
左下角這張圖片是OpenNebula的存儲結構圖。OpenNebula使用映像倉庫（Image Repository）來保存操作系統映像文件。這個映像倉庫要能夠被OpenNebula的前端直接訪問，可以是SAN、NAS或者是磁盤陣列等其他存儲設備。我們創建虛擬機的時候，ONED首先通過任務調度器確定將要運行該虛擬機的計算節點，然後將相應的磁盤映像文件拷貝到計算節點上，最後通過虛擬化驅動調用相應的虛擬化技術創建虛擬機並啓動運行。對於一個小型的私有云來講，可以簡單地使用類似於NFS的共享文件系統方式將同一個目錄掛載到前端服務器和所有的計算節點上。通過使用共享文件系統，可以縮短部署虛擬機所需要的時間，還可以方便地實現虛擬機的在線遷移。使用共享文件系統的時候需要注意的是，如果某些虛擬機頻繁地進行磁盤IO操作的話，部署在同一共享文件系統上的所有虛擬機都會受到影響。在這種情況下，可以考慮將磁盤IO密集型虛擬機的磁盤映像文件緩存在計算節點上，這樣只有運行在同一計算節點上的虛擬機會受到影響。
在網絡方面，OpenNebula通過在計算節點上配置網橋的方式爲虛擬機提供網絡連接。在右上角的這張示意圖上，一個計算節點配置了兩個網橋，其中一個連接到公網，另外一個連接到內網。需要注意的是，在同一個計算集羣中，所有計算節點的網橋配置必須是同樣的。另外，OpenNebula可以通過配置文件來指定某個網絡可用的IP範圍，並且在創建虛擬機的時候通過配置文件直接指定虛擬機的IP，因此OpenNebula可以在沒有DHCP服務器的情況下爲虛擬機分配IP。除此之外，我想在座的各位對網橋的設置都不陌生了，在這裏我就不再重複這些常識了。
剛纔我們所提到的構架、存儲和網絡，都屬於虛擬化管理的範疇。在虛擬化管理的基礎上，OpenNebula使用一個稱爲SunStone的用戶界面，使得雲管理員和終端用戶都能夠通過瀏覽器訪問被OpenNebula所管理的基礎構架，在各自的權限範圍內執行虛擬機生命週期管理操作，就形成了一個完整的基礎構架服務系統。
（7 分鐘）
【構架/功能 — Nimbus 2.8】
接下來我們看一看Nimbus這個項目。從左上角的構架圖來看，Nimbus的構架設計和OpenNebula是非常相像的。用戶通過瀏覽器界面訪問Nimbus服務，管理節點通過SSH和libvirt調用計算節點上的Xen或者KVM命令。不同的地方主要有兩個，一個是它通過DHCP服務器爲虛擬機分配IP，另外一個是它使用了一個名爲Cumulus的雲存儲服務。
左下角這張圖是Cumulus雲存儲的構架圖。可以看出，Cumulus由多個功能模塊組成。從頂層看，它是一個與Amazon S3相兼容的雲存儲服務； 從底層看，它可以搭建在簡單的本地硬盤或者是負責的HDFS上。在雲計算這個領域，Amazon S3是事實上的雲存儲標準。Nimbus使用雲存儲來提供存儲服務，從構架上來說比使用共享文件系統的OpenNebula更接近於Amazon EC2/S3。
各位可能會問，用雲存儲來作爲基礎構架服務的關鍵組件，在性能上會不會有問題呢？右邊這兩張圖展示的分別是Culumus、scp、gridFtp和本地文件系統在上載和下載不同大小的文件時的吞吐量。從這兩張圖可以看出，當被操作的文件較小的情況下，Culumus的性能較差，但是與scp和gridFtp的性能在同一水平上；當被操作的文件大小超過1 GB的時候，Culumus的性能與本地文件系統接近。考慮到操作系統應先文件的大小通常會超過1 GB，可以認爲使用Culumus來存儲操作系統映像文件是沒有問題的。
（3 分鐘）
【構架/功能 — Eucalyptus 2.0.3】
接下來我們看一看Eucalyptus這個項目。Eucalyptus的構架和OpenNebula以及Nimbus相比有兩個明顯的不同。首先，在計算節點（Node Controller）和雲控制器（Cloud Controller）之間，多了一個叫做集羣控制器（Cluster Controller）的組件。其次，在Eucalyptus中有兩個負責存儲的組件，一個叫做Walrus存儲控制器（Walrus Storage Controller，縮寫成WS3），另外一個叫做彈性塊存儲（Elastic Block Storage，縮寫成EBS）。
引入集羣控制器這個組件後，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能夠提供較大的容量，具有較好的IO性能。S3則是一種基於Key-Value的網絡存儲，有人也把它叫做雲存儲。S3使得用戶能夠通過簡單的API在網絡上存儲和讀取數據。
在我們已經提到的三個IaaS軟件中，OpenNebula直接使用共享文件系統作爲存儲，Nimbus使用了一個類似於S3的Cumulus存儲服務，Eucalyptus則進一步將雲硬盤和雲存儲分開。從構架上來看，Eucalyptus的構架和Amazon 的EC2/S3服務最爲接近。
類似於S3的雲存儲服務使得用戶能夠通過簡單的API在網絡上存儲和讀取數據，但是對於數據密集型應用來說，使用S3服務可能會出現性能方面的問題。最近卡耐基梅隆大學（Carnegie Mellon University，CMU）的並行數據實驗室（Parallel Data Labs）基於Walrus雲存儲實現了pWalrus雲存儲服務。大家看幻燈片上右下角這張圖，可以看出pWalrus把數據存放在一個並行的文件系統上。對於互聯網用戶來講，他可以通過簡單的PUT和GET來讀寫數據；對於計算節點來講，它既可以通過PUT和GET來讀寫數據，還可以直接用文件IO的模式來讀寫數據。經過這樣的改進後，pWalrus能夠提供更好的IO性能，也能夠進一步保障數據的安全性。
（8 分鐘）
【構架/功能 — OpenStack】
接下來我們看一看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的構架。儘管每個軟件的設計思路和實現細節各有千秋，但是都可以歸結爲三個比較大的模塊：一是通常被稱爲雲控制器的前端，包括用戶界面、編程接口和任務調度組件；二是虛擬化管理，包括網絡管理和虛擬機管理；三是存儲服務，包括彈性塊設備和簡單存儲服務。在這三大模塊的基礎上，還可以添加監控、報表、分析、計費等等外圍組件。這些組件往往是運營方面的要求，不是基礎構架服務的核心技術，在這裏我們就不詳細討論了。
（4 分鐘）
【構架/功能 — 綜合比較】
在瞭解過OpenNebula、Nimbus、Eucalyptus和OpenStack在構架上的差異之後，我們簡單地比較一下這四個系統在功能上的差異。這裏所說的功能，是指缺省的基本組件安裝配置完畢後即可立即使用的功能，不包括尚未正式發佈的試驗性組件。
首先我們從終端用戶的角度來看，這個系統是不是有一個方便好用的門戶或者是客戶端去進行各種各樣的操作。OpenNebula提供了基於瀏覽器的用戶門戶，Nimbus則提供了一個基於Java的桌面客戶端，Eucalyptus和OpenStack則需要利用命令行工具或者是第三方解決方案。
在雲主機、雲硬盤和雲存儲着三類基礎構架服務中，OpenNebula僅提供雲主機服務，Nimbus增加了雲存儲服務，Eucalyptus和OpenStack都能夠提供全面的服務。此外，OpenNebula的用戶能夠直接通過基於瀏覽器的VNC訪問虛擬機的控制檯（console），其他三個系統的終端用戶暫時無法直接訪問虛擬機的控制檯。
四個系統的終端用戶均可創建自定義的虛擬機模板，但是實現的難易程度有較大差別。
只有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解決方案要進入生產環境，還有很長的路要走。
（8 分鐘）
【社區/商業 — 數據】
現在我們花一點時間從社區和商業的角度來對開源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社區的參與度通常是其他兩者的兩 倍甚至是更高。
（5 分鐘）
【社區/商業 — 人物】
說到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月份跳槽到了戴爾（DELL）負責產品和市場，未來OpenStack社區會朝哪個方向發展，還是個未知數。
很巧的是，Eucalyptus項目的社區經理Mark Atwood也是2010年9月入職的。在他入職之前，Eucalyptus社區已經開始呈現下滑的趨勢。Mark Atwood入職之後，側重於Eucalyptus企業版的宣傳和推廣，在開發者和用戶社區這個領域並沒有太大作爲，導致Eucalyptus的社區活躍度進一步下滑。Eucalyptus顯然已經注意到了這個問題，並且於今年10月僱傭了Greg DeKoenigsburg來負責社區方面的工作。Greg DeKoenigsburg在2004到2010年之間在RedHat工作，負責Fedora的社區工作。至於Greg DeKoenigsburg上任之後Eucalyptus社區的狀況是否會有所改善，我們還需要一段時間來慢慢觀察。（很有意思的是，在Greg DeKoenigsburg加盟Eucalyptus的一個月之前，Mark Atwood就跑到Red Hat去負責開發者社區了，可見這個圈子真的是很小很小。）
在社區運營這一塊，OpenNebula和Eucalyptus和OpenStack項目有所不同。OpenNebula項目的社區經理是一個志願者的角色，從2009年9 月起一直由芝加哥大學（University of Chicago）的Borja Sotomayor擔任。在2004到2010年之間，Borja Sotomayor在芝加哥大學計算機系讀碩士和博士，並在拿到博士學位後在芝加哥大學擔任講師。可以認爲，OpenNebula項目在社區建設方面的投入並不大，但它的社區發展顯然是良性的，並且在近期逐步超越了曾經是如日中天的Eucalyptus社區。如果一定要爲此尋找一個原因的話，我們只能夠說是OpenNebula這個項目做得實在是太好了。
（5 分鐘）
【社區/商業 — 趨勢】
剛纔我們在構架和功能的綜合比較裏面提到，開源IaaS解決方案要進入生產環境，還有很長的路要走。那麼，開源IaaS軟件將來會朝什麼方向去發展，投資開發開源IaaS軟件的機構的商業模式又是怎樣的呢？讓我們看一看這幾個開源IaaS背後的機構都在提供什麼樣的產品和服務吧。Eucalyptus公司一直在維護社區版和商業版兩個不同的版本，今年8 月份剛剛發佈的Eucalyptus 3企業版提供了高可用性、負載管理、RBAC權限管理、配額管理、運營計費等等在社區版中缺失的功能。與此類似，擁有OpenNebula項目的C12G Labs同時在維護社區版和專業版兩個不同的版本，並且在今年11月發佈了可供商用的OpenNebula Pro 3.0。OpenStack項目的後臺老闆RackSpace則推出了稱爲RackSpace Cloud Private Edition的服務，既可以爲客戶建設數據中心，又可以提供私有云解決方案。
鳩摩羅什大師所譯的《維摩詰所說經》中有這麼一句話：“先以欲勾牽，後令入佛智。”我想，這句話完美地闡釋了開源IaaS軟件的發展趨勢。
（2 分鐘）
【致謝/參考資料】
今天我的講座到這裏就結束了。各位如果需要更多的資料，包括今天這個講座的幻燈片和文本，都可以從我的博客獲得。
謝謝大家
