原文：http://www.qyjohn.net/?p=1552
By qyjohn,
October 12, 2012 9:43 am
借國慶長假的機會寫了這篇長文，全面地整理了個人從虛擬化到雲計算各個層面的看法。主要的內容涉及虛擬化、虛擬化管理、數據中心虛擬化、雲計算、公有云與私有云、以及開放源代碼。本文的全部內容均屬於作者的個人觀點，而不代表任何公司的觀點。歡迎討論。
A、虛擬化
虛擬化是指在同一臺物理機器上模擬多臺虛擬機的能力。每臺虛擬機在邏輯上擁有獨立的處理器、內存、硬盤和網絡接口。使用虛擬化技術能夠提高硬件資源的利用率，使得多個應用能夠運行在同一臺物理機上各自擁有彼此隔離的運行環境。
虛擬化的也有不同的層次，例如硬件層面的虛擬化和軟件層面的虛擬化。硬件虛擬化指的是通過模擬硬件的方式獲得一個類似於真實計算機的環境，可以運行一個完整的操作系統。在硬件虛擬化這個層面，又有Full Virtualization（全虛擬化，幾乎是完整地模擬一套真實的硬件設備。大部分操作系統無須進行任何修改即可直接運行在全虛擬化環境中。）、Partial Virtualization（部分虛擬化，僅僅提供了對關鍵性計算組件或者指令集的模擬。操作系統可能需要做某些修改才能夠運行在部分虛擬化環境中。）和Paravirtualization（半虛擬化，不對硬件設備進行模擬，虛擬機擁有獨立的運行環境，通過虛擬機管理程序共享底層的硬件資源。大部分操作系統需要進行修改才能夠運行在半虛擬化環境中。）等不同的實現方式。軟件層面的虛擬化，往往是指在同一個操作系統實例的基礎上提供多個隔離的虛擬運行環境，也常常被稱爲容器技術。
在硬件虛擬化的層面，現代的虛擬化技術通常是全虛擬化和半虛擬化的混合體。常見的虛擬化技術例如VMWare、Xen和KVM都同時提供了對全虛擬化和半虛擬化的支持。以硬件虛擬化的方式所提供的虛擬機，通常都在運行一個完整的操作系統，在同一臺宿主機上存在大量相同或者相似的進程和內存頁，從而導致明顯的性能損耗。目前，通過KSM等技術可以識別與合併含有相同內容的內存頁，但是還沒有對大量相同或者相似的進程進行優化處理的有效手段。因此，硬件虛擬化也往往被稱爲重量級虛擬化，在同一宿主機上能夠同時運行的虛擬機數量是相當有限的。在軟件虛擬化的層面，同一宿主機上的所有虛擬機共享同一個操作系統實例，不存在由於運行多個操作系統實例所造成的性能損耗。因此，軟件虛擬化也往往被稱爲輕量級虛擬化，在同一宿主機上能夠同時運行的虛擬運行環境數量是比較寬鬆的。以Solaris操作系統上的Container爲例，一個Solaris操作系統的實例理論上可以支持多達8000個Container（實際能夠運行的Container數量取決於系統資源和負載）。與此類似，Linux操作系統上的LXC可以輕鬆地在同一宿主機上同時支持數量可觀的虛擬運行環境。
在虛擬化這個領域，國內的公司對硬件虛擬化的興趣較大，在研發和生產環境中也大都採用硬件虛擬化技術。淘寶是國內較早地研究並應用軟件虛擬化技術的，他們在淘寶主站的實踐經驗表明使用cgroup替代Xen能夠提升資源利用率。至於在一個實際的應用場景中到底應該選擇硬件虛擬化還是軟件虛擬化，則應該重點考慮最終用戶是否需要對操作系統的完全控制權（例如升級內核版本）。如果最終用戶僅僅需要對運行環境的控制權（例如PaaS層面的各種App Engine服務），軟件虛擬化可能性價比更高。對於爲同一應用提供橫向擴展能力的應用場景，軟件虛擬化也是比較好的選擇。
對於需要深入瞭解虛擬化技術的技術人員來說，VMWare發表的白皮書《Understanding Full Virtualization, Paravirtualization, and Hardware Assist》是一份很好的參考資料。
通常來講，能夠直接使用虛擬化技術的用戶數量是比較少的。以Linux操作系統爲例，能夠進行虛擬機生命週期管理的用戶，一般就是具有訪問libvirt權限的用戶。在一個公司或者其他實體中，這些用戶通常是系統管理員。
B、虛擬化管理
早期的虛擬化技術，解決的是在同一臺物理機上提供多個相互獨立的運行環境的問題。當需要管理的物理機數量較小時，系統管理員可以手動登錄到不同的物理機上進行虛擬機生命週期管理（資源配置、啓動、關閉等等）。當需要管理的物理機數量較大時，就需要寫一些腳本／程序來提高虛擬機生命週期管理的自動化程度。以管理和調度大量物理／虛擬計算資源爲目的軟件，稱爲虛擬化管理工具。虛擬化管理工具使得系統管理員可以從同一個位置執行如下任務：（1）對不同物理機上的虛擬機進行生命週期管理；（2）對所有的物理機和虛擬機進行查詢甚至監控；（3）建立虛擬機命名與虛擬機實例直接的映射關係，使得虛擬機的識別和管理更加容易。Linux操作系統上的VirtManager是一個簡單的虛擬化管理工具。在VMWare產品家族中，VMWare vSphere是一個功能強大的虛擬化管理工具。
虛擬化管理工具是虛擬化技術的自然延伸。簡單的虛擬化管理工具，解決的是由於物理機數量增多所導致的工作內容繁雜問題。在這個層面，虛擬化管理通常和集羣的概念同時出現。一個虛擬化管理工具，往往需要獲得各臺物理機上的虛擬機生命週期管理權限（例如具有訪問libvirt權限的用戶名和密碼）。在同一個集羣當中，爲了方便起見，可能需要設定一個在整個集羣層面通用的管理用戶。可以認爲，虛擬化管理爲系統管理員提供了便利，但是並沒有將虛擬機生命週期管理的權限下放給其他用戶。
C、數據中心虛擬化
在數據中心的層面，系統管理員需要面對大量不同類型的硬件和應用。與小型的集羣相比較，數據中心的系統複雜度大大提高了。這時簡單的虛擬化管理工具已經無法滿足系統管理員的要求，因此在虛擬化管理工具的基礎上又發展出各種數據中心虛擬化管理系統。在硬件層面，數據中心虛擬化管理系統通過劃分資源池（一個資源池通常是一個集羣）的方式對硬件資源進行重新組織，並以虛擬基礎構架（Virtual Infrastructure）的方式將計算資源暴露給用戶。在軟件層面，數據中心虛擬化管理系統引入系統管理員和普通用戶兩種不同的角色，甚至是基於應用場景的需要設定顆粒度更細的基於角色的權限控制（Role Based Access Control，RBAC）。系統管理員對整個數據中心的物理機和虛擬機擁有管理權限，但是一般不對正常的虛擬機進行干涉。普通用戶只能在自己具有權限的資源池內進行虛擬機生命週期管理操作，不具有控制物理機的權限。在極端的情況下，普通用戶只能夠看到分配給自己的資源池，而不瞭解組成該資源池物理機細節。
在數據中心虛擬化之前，創建虛擬機的動作是需要系統管理員來完成的。在數據中心虛擬化管理系統中，通過基於角色的權限控制，虛擬機生命週期管理的權限被下放給所謂的“普通用戶”，在一定程度上可以減輕系統管理員的負擔。但是，出於系統安全的考慮，並不是公司裏所有的員工都能夠擁有這樣的“普通用戶”賬號。一般來說，這種“普通賬號”只能夠分配給某個團隊的負責人。可以認爲，一直到數據中心虛擬化這個層面，虛擬機的生命週期還是集中式管理的。
數據中心虛擬化管理系統是虛擬化管理工具的進一步延伸，它所解決的是由於硬件和應用規模上升所帶來的系統複雜度問題。具體的物理設備被抽象成資源池之後，公司高管只需要瞭解各個資源池的規模、負載和健康狀況，最終用戶只需要瞭解分配給自己的資源池的規模、負載和健康狀況。只有系統管理員還需要對每一臺物理設備的配置、負載和故障瞭如指掌，但是資源池的概念也從邏輯上對所有的物理設備進行了重新整理和分類，使得系統管理員的工作變得更加容易了。
現代的數據中心虛擬化管理系統，往往提供了大量有助於運維自動化的功能。這些功能包括 （1）基於模板快速部署一系列相同或者是相似的運行環境；（2）監控、報表、預警、會計功能；和（3）高可用性、動態負載均衡、備份與恢復等等。一些相對開放的數據中心虛擬化管理系統，甚至以開放API的方式使得系統管理員能夠根據自身的應用場景和流程開發額外的擴展功能。
在VMWare產品家族中，VMWare vCenter是一個數據中心虛擬化管理軟件。其他值得推薦的數據中心虛擬化管理軟件包括Convirt、XenServer、Oracle VM、OpenQRM等等。
D、雲計算
雲計算是對數據中心虛擬化的進一步封裝。在雲計算管理軟件中，同樣需要有云管理員和普通用戶兩種（甚至更多）不同的角色以及不同的權限。管理員對整個數據中心的物理機和虛擬機擁有管理權限，但是一般不對正常的虛擬機進行干涉。普通用戶可以通過瀏覽器自助地進行虛擬機生命週期管理 ，也可以編寫程序通過Web Service自動地進行虛擬機生命週期管理。
在雲計算這個層面，虛擬機生命週期管理的權限被徹底下放真正的普通用戶，但是也將資源池和物理機等等概念從普通用戶的視野中屏蔽了。普通用戶可以獲得計算資源，但是無需對其背後的物理資源有任何瞭解。從表面看，雲計算似乎就是以與Amazon EC2/S3相兼容的模式提供計算資源。在實質上，雲計算是計算資源管理的模式發生了改變，最終用戶不再需要系統管理員的幫助即可自助地獲得獲得和管理計算資源。
對於雲管理員來說，將虛擬機生命週期管理權限下放到最終用戶並沒有降低其工作壓力。相反，他有了更加令人頭疼的事情需要去處理。在傳統的IT架構中，往往 是一個應用配備一套計算資源，應用之間存在物理隔離，問題診斷也相對容易。升級到雲計算模式之後，多個應用可能共享同一套計算資源，應用之間存在資源競 爭，問題診斷就相對困難。因此，雲管理員往往希望選用的雲計算管理軟件能夠有相對全面的數據中心虛擬化管理功能。對於雲管理員來說，至關重要的功能包括 （1）監控、報表、預警、會計功能；（2）高可用性、動態負載均衡、備份與恢復等等；和（3）動態遷移，可以用於局部負載調整以及故障診斷。
顯而易見，從虛擬化到雲計算，對物理資源的封裝程度不斷提高，虛擬機生命週期的管理權限逐步下放。
在VMWare產品家族中，VMWare vCloud是一個雲計算管理軟件。其他值得推薦的雲計算管理軟件包括OpenStack、OpenNebula、Eucalyptus和CloudStack。雖然OpenStack、OpenNebula、Eucalyptus和CloudStack都是雲計算管理軟件，但是其功能有較大的差別，這些差異源於不同 的軟件具有不同的設計理念。OpenNebula和CloudStack最初的設計目標是數據中心虛擬化管理軟件，因此具有比較全面的數據中心虛擬化管理 功能。雲計算的概念興起之後，OpenNebula增加了OCCI和EC2接口，CloudStack則提供了稱爲CloudBridge的額外組件 （CloudStack從 4.0版本開始缺省地包含了CloudBridge組件），從而實現了與Amazon EC2的兼容。Eucalyptus和OpenStack則是以Amazon EC2爲原型自上而下地設計成雲計算管理軟件的，從一開始就考慮與Amazon EC2的兼容性（OpenStack還增加了自己的擴展），但是在數據中心虛擬化管理方面的功能尚有所欠缺。在這兩者當中，Eucalyptus項目由於起步較早，在數據中心虛擬化管理方面的功能明顯強於OpenStack項目。
E、私有云與公有云
如D 所述的雲計算，僅僅是一種狹義上的雲計算，或者是與Amazon EC2相類似的雲計算。 廣義上的雲計算，可以泛指是指各種通過網絡訪問物理／虛擬計算機並利用其計算資源的實踐，包括如D 所述的雲計算和如C 所述的數據中心虛擬化。這兩者的共同點在於雲計算服務提供商以虛擬機的方式向用戶提供計算資源，用戶無須瞭解虛擬機背後實際的物理資源狀況。如果某個雲平臺僅對某個集團內部提供服務，那麼這個雲平臺也可以被稱爲“私有云”；如果某個雲平臺對公衆提供服務，那麼這個雲平臺也可以被稱爲“公有云”。一般來說，私有云服務於集團內部的不同部門（或者應用），強調虛擬資源調度的靈活性（例如最終用戶能夠指定虛擬機的處理器、內存和硬盤配置）；公有云服務於公衆，強調虛擬資源的標準性（例如公有云服務提供商僅提供有限的幾個虛擬機產品型號，每個虛擬機產品型號的處理器、內存和硬盤配置是固定的，最終用戶只能夠選擇與自身需求最爲接近的虛擬機產品型號）。
對於公有云服務提供商來說，其業務模式與Amazon EC2相類似。因此，公有云服務提供商通常應該選擇如D 所述的雲計算管理軟件。對於私有云服務提供商來說，則應該根據集團內部計算資源的管理模式來決定選用的軟件。如果對計算資源進行集中式管理，僅僅將虛擬機生命週期管理的權限下放到部門經理或者是團隊負責人這個級別，那麼就應該選擇如C 所述的數據中心虛擬化管理系統。如果要將虛擬機生命週期管理的權限下放到真正需要計算資源的最終用戶，則應該選擇如D 所述的雲計算管理軟件。
傳統上，人們認爲私有云是建立在企業內部數據中心和自有硬件的基礎上的。但是硬件廠商加入雲計算服務提供商的行列之後，私有云與公有云之間的界限變得越來越模糊。Rackspace推出的私有云服務，客戶可以選擇使用自有的數據中心和硬件，也可以選擇租用Rackspace的數據中心和硬件。Oracle最近更進一步提出了“由Oracle擁有並管理”（ Owned by Oracle, Managed by Oracle）的私有云服務。在這種新的業務模式下，客戶所獨享的私有云是僅僅是雲服務提供商的公有云當中與其他客戶相對隔離的一個資源池（you got private cloud in my public cloud）。而對於雲服務提供商來說，用於提供公有云服務的基礎構架可能僅僅是其自有基礎構架（私有云）中的一個資源池，甚至是硬件廠商自有基礎構架（私有云）中的一個資源池（you got public cloud in my private cloud）。
對於客戶來說，使用基於雲服務提供商的數據中心和硬件的私有云服務在財務上是合理的。這樣做意味着自建數據中心和採購硬件設備的固定資產投入（CapEX）變成了分期付款的運營費用（OPEX），寶貴的現金則可以作爲用於拓展業務的週轉資金。即使長期下來擁有此類私有云的總體費用比自建數據中心和採購硬件設備要高，但是利用多出來的現金進行業務拓展所帶來的回報可能會超過兩個方案之間的費用差額。在極端的情況下，即使企業最終沒有獲得成功，也無需心疼新近購置的一大堆硬件設備。除非是房地產市場在短時間內有較大的起色，一家瀕臨倒閉的公司通常是不會爲沒有自建一個數據中心而感到後悔的。（需要指出的是，對於一家能夠長時間運作的公司來說，通過房地產來盈利是完全有可能的。在Sun 公司被Oracle公司收購之前，就曾經通過變賣祖業的方式使得財報扭虧爲盈。）
那麼，硬件廠商在這場遊戲裏面扮演的是什麼角色呢？當用戶的固定資產投入（CapEX）變成了分期付款的運營費用（OPEX）時，硬件廠商難道不是需要更長的時間才能夠收回貨款嗎？
1865年，英國經濟學家威廉傑文斯（Willian Jevons，1835-1882）寫了一本名爲《煤礦問題》（The Coal Question）的書。傑文斯描述了一個似乎自相矛盾的現象：蒸汽機效率方面的進步提高了煤的能源轉換率，能源轉換率的提高導致了能源價格降低，能源價格的降低又進一步導致了煤消費量的增加。這種現象稱爲傑文斯悖論，其核心思想是資源利用率的提高導致價格降低，最終會增加資源的使用量。在過去150年當中，傑文斯悖論在主要的工業原料、交通、能源、食品工業等多個領域都得到了實證。
公共雲計算服務的核心價值，是將服務器、存儲、網絡等等硬件設備從自行採購的固定資產變成了按量計費的公共資源。虛擬化技術提高了計算資源的利用率，導致了計算資源價格的降低，最終會增加計算資源的使用量。明白了這個邏輯，就能夠明白爲什麼HP會果斷加入OpenStack的陣營並在OpenStack尚未成熟的情況下率先推出基於基於OpenStack的公有云服務。固然，做雲計算不一定能夠拯救HP於搖搖欲墜之中，但是如果不做雲計算，HP恐怕就時日不多了。同樣，明白了這個邏輯，就能夠明白爲什麼Oracle會從對雲計算嗤之以鼻搖身一變稱爲雲計算的實踐者。收購了Sun 公司之後，Oracle一夜之間變成了世界領先的硬件提供商。當時雲計算的概念剛剛興起，Oracle不以爲然的態度說明它尚未充分適應自身地位的變化。如今雲計算已經從概念炒作進入實戰演習階段，作爲主要硬件廠商之一的Oracle如果不打算從雲計算中分一杯羹的話，那就是真正的反射弧過長了。
根據傑文斯悖論，對於用戶來說，價格降低是用量增加的前提。那麼，應該如何給雲計算資源定價呢？
目前，大部分公有云服務提供商的虛擬機產品都是按照配置定價的。以Amazon EC2爲例，其中型（Medium）虛擬機（3.75 GB內存，2 ECU計算單元，410 GB存儲，0.16美元每小時）的配置是小型（Small）虛擬機（1.7 GB內存，1 ECU計算單元，160 GB存儲，0.08美元每小時）的兩倍，其價格也是小型虛擬機的兩倍。新近推出的HP Cloud Services，以及國內的盛大雲和阿里雲，基本上都照搬Amazon EC2的定價方法。問題在於，虛擬機的配置提高之後，虛擬機的性能並沒有得到同比提高。一系列針對Amazon EC2、HP Cloud Services、盛大雲和阿里雲的性能測試結果表明，對於多種類型的應用來說，隨着虛擬機配置的提高，其性價比實際上是不斷降低的。這樣的定價策略，顯然不能達到鼓勵用戶使用更多計算資源的目的。
按照虛擬機的性能來定價可能是一個更加合適的做法。舉個例子說，某個牌子的肥皂有大小兩種包裝，小包裝有一塊肥皂而大包裝有兩塊肥皂。用戶願意花雙倍的錢購買大包裝，往往是因爲大包裝能夠洗兩倍的衣服而不是因爲它看起來更大。同理，來自同一公有云服務提供商的不同虛擬機產品，應該儘可能使其性價比維持在同一水平線上。問題在於，不同類型的應用對處理器、內存和存儲等計算資源的需求存在較大差異，其“性能–配置”變化曲線也各有不同。因此，在公有云服務領域需要一個對虛擬機性能進行綜合評估的框架，通過該框架獲得的評估結果可以表示一臺虛擬機的綜合處理能力，而不僅僅是處理器、內存和存儲當中的任何一項。基於這樣一個測試框架，不僅可以對同一公有云服務提供商的產品進行比較，還可以對不同公有云服務提供商的產品進行比較。
F、開放源代碼
近些年來，我們在信息技術領域觀察到一個規律。當一個閉源的解決方案在市場上取得成功時，很快就會出現一個甚至是多個提供類似功能（或者服務）的開源或者閉源的追隨者。（首先出現開源軟件，然後出現與之競爭的閉源軟件的案例比較少見。）在操作系統領域，Linux逐漸達到甚至是超越了Unix的技術水平，進而取代Unix的市場地位。在虛擬化領域，Xen和KVM緊緊跟隨VMWare的技術發展並有所突破，逐步蠶食VMware的市場份額。在雲計算領域，Enomaly率先推出了以Amazon EC2爲藍本的閉源解決方案，緊跟着又出現了以Eucalyptus和OpenStack爲代表的開源解決方案。與此同時，傳統意義上的閉源廠商對開源項目和社區的態度也在發生轉變。例如，多年來對開源項目持敵視態度的微軟於今年四月組建了一家名爲“微軟開放技術”（Microsoft Open Technologies）的子公司，其目標是推進微軟向開放領域的投資，包括互操作性、開放標準和開源軟件。
我們今天所處的商業環境，與上個世紀80年代自由軟件運動（Free Source Movement）剛剛興起的時候已經有了較大的不同。自1998年NetScape第一次提出開放源代碼（Open Source）這個術語起，開放源代碼就已經成爲一種新的軟件研發、推廣與銷售模式，而不再是與商業軟件相對立的替代品了。與傳統的閉源軟件商業模式相對比，基於開放源代碼的商業模式具有如下特點：
（1）在項目萌芽階段，通過開源軟件或者自由軟件等關鍵詞吸引潛在客戶以及合作伙伴。對於潛在客戶來說，選擇開源軟件能夠免費或者是低價獲得閉源軟件的（部分）功能。對於合作伙伴來說，其興趣點可能在於銷售基於開源軟件的增強版本（例如企業版），提供基於開源軟件的解決方案，或者是該開源軟件的成功可能對其自身的產品的銷售有促進作用。
（2）在項目成長階段，主要的研發人員來自發起項目的企業以及該項目的企業合作伙伴。雖然也有一些單純出於興趣而向開源項目貢獻代碼的個人開發者，但是其數量相對較少。我們在開源軟件的宣傳資料當中經常會見到類似於“由某某社區開發”的描述。最近10年來，各種“社區”中的主要研發力量始終來自數量極爲有限的企業合作伙伴。但是有些開源項目在宣傳中通常會有意無意地淡化企業合作伙伴的重要性，甚至是誤導受衆以爲社區的主要成分是個人開發者。
（3）在項目收割階段，項目發起者以及主要合作伙伴可以通過銷售增強版本或者是提供解決方案獲取財務回報。雖然其他廠商也可以提供類似的產品或者服務，但是開源項目的主要參與者往往在市場上擁有更大的話語權和權威性。關於開源項目的盈利問題，Marten Mickos（Eucalyptus的CEO）在擔任MySQL公司CEO期間曾指出：“如果要在開源軟件上取得成功，那麼你需要服務於：（A）願意花費時間來省錢的人；和（B）願意花錢來節約時間的人。”如果說一個公司在開源方面取得了成功，那麼它從開源軟件的銷售和服務方面獲得的回報至少應該大於在研發和推廣方面的投入。顯而易見，某些用戶之所以能夠免費使用開源軟件，一方面固然是因爲他們的參與降低了開源軟件在研發和推廣方面的投入，另一方面則是因爲付費用戶爲開源軟件付出了更多的錢。
那麼，爲什麼基於開源軟件的解決方案通常要比其閉源的競爭對手更便宜呢？通常來說，閉源軟件作爲一個領域的開創者，在市場研究、產品設計、研發測試、推廣銷售等等環節都面臨很大的挑戰。開源軟件作爲閉源軟件的追隨者，在市場研究方面有閉源軟件作爲成功案例，在產品設計方面有閉源軟件作爲參考模板，在推廣銷售方面也得益於閉源軟件的市場拓展。在研發方面，開源軟件出現的時間要稍晚於閉源軟件，在這個時間段裏發生的技術進步會明顯降低開源軟件進入相關領域的門檻。除此之外，開源軟件可能在某些特性方面超越閉源軟件，但在總體水平上其功能的完備性、易用性、穩定性、可靠性會稍遜於閉源軟件。因此，基於開源軟件的解決方案通常會採取“以閉源軟件30%的價格提供閉源軟件80%的功能”這樣的營銷思路。除此之外，基於開源軟件的解決方案的可定製性對於某些客戶來說也有特別的吸引力。
在中國的商業環境中，IT公司（或者說互聯網公司）通常是願意花費時間來省錢的，而非IT公司（或者說傳統行業）通常是願意花錢來節約時間的。需要指出的是，中國的非IT公司往往不在乎軟件是否開源，但是非常注重開源軟件的可定製性。
開放源代碼作爲一種新的商業模式，並不比傳統的閉源模式具有更高的道德水準。同理，在道德層面上對不同的開放源代碼實踐進行評判也是不合適的。在OpenStack項目的萌芽階段，Rackspace公司的宣傳文案聲稱OpenStack是“世界上唯一真正開放源代碼的IaaS系統”。CloudStack、Eucalyptus和OpenNebula等具有類似功能的開源項目由於保留了部分閉源的企業版（2012年4 月以前，CloudStack項目和Eucalyptus均同時發佈完全開源的社區版和部分閉源的企業版。2012年4 月之後，Eucalyptus項目宣佈全面開源，CloudStack項目被Citrix收購併捐贈給Apache基金會後也全面開源。）、或者是僅向付費客戶提供的自動化安裝包（OpenNebula Pro是一個包含了增強功能的自動化安裝包，但是其全部組件都是開放源代碼的。）而被Rackspace歸類爲“不是真正的開放源代碼項目”。類似的宣傳持續了接近兩年時間，直到Rackspace公司推出了基於OpenStack項目的Rackspace Private Cloud軟件 — 一個性質上與OpenNebula Pro類似的自動化包。OpenNebula Pro是一個僅向付費用戶提供的軟件包，但是任何用戶都可以免費地下載與使用Rackspace Private Cloud軟件。問題在於，當用戶所管理的節點數量超過20臺服務器時，就需要向Rackspace公司尋求幫助（購買必要的技術支持）。這裏我們暫且不討論將節點數量限制爲20臺服務器這部分代碼是否開源的問題。開源項目的發起者和主要貢獻者在其重新打包的發行版中添加了限制該軟件應用範圍的功能，從道德層面來看很難解釋，但是在商業層面來看就很正常。在過去兩年中，OpenStack項目在研發、推廣、社區等領域所採取的種種措施，都堪稱是基於開放源代碼的商業模式的經典案例。
前面我們提到，在同一領域往往存在多個相互競爭的開源項目。以廣義上的雲計算爲例，除了我們熟悉的CloudStack、Eucalyptus、OpenNebula、OpenStack之外，還有Convirt、XenServer、Oracle VM、OpenQRM等等諸多選擇。針對一個特定的應用場景，如何在衆多的開源方案中進行選型呢？根據我個人的經驗，可以將整個方案選型過程分爲需求分析、技術分析、商務分析三個階段。
（1）在需求分析階段，針對特定的應用場景深入挖掘該項目採用雲計算技術的真正目的。在中國，很多項目決策者對雲計算的認識往往停留在“提高資源利用率、降低運維成本、提供更多便利”的階段，並沒有意識到這個列表已經是大部分開源軟件均可提供的基本功能。除此之外，很多項目決策者缺省地將VMWare vCenter提供的全部功能作爲對開源軟件的要求，而沒有考慮特定項目是否需要這些功能。因此，非常有必要針對特定的應用場景進行調研，明確將其按照數據中心虛擬化和狹義上的雲計算歸類，並進一步挖掘項目在功能上的具體要求。在很多情況下，數據中心虛擬化和狹義上的雲計算均能夠滿足客戶的總體需求，那麼銷售的任務就是將客戶的具體需求往有利於自身的方向上引導。這個技巧，我們稱之爲客戶期望值管理（Expectation Management）。通過需求分析，明確特定應用場景的分類，可以過濾掉一部分選項。
（2）在技術分析階段，首先比較各個開源軟件的參考架構，重點考慮在特定應用場景下按照參考構架進行實施所面臨的困難。其次在功能的層面對各個開源軟件進行對比，並將必須具備的功能（Must Have）和能夠加分的功能（Good to Have）區別對待。除此之外，還可以對安裝配置的難易程度、具體功能的易用性、參考文檔的完備性、二次開發的可能性等等進行評估。通過技術分析，可以給各個開源軟件打分排名，在此基礎上可以淘汰掉得分最低的選項。
（3）在商務分析階段，必須明確決策者是否願意爲開源的解決方案付費。如果決策者不願意爲付費，那麼該項目就屬於“願意花費時間來省錢”的場景，反之則屬於“願意花錢來節約時間”的場景。對於願意花費時間來省錢的應用場景，主要依賴於開源社區獲得技術支持，可以將開源項目的社區活躍度作爲重要的參考數據。對於願意花錢來節省時間的應用場景，主要依賴於服務提供商獲得技術支持，應該重點考察服務提供商在業界的影響力以及在本地的服務能力，開源項目的社區活躍度則顯得無關緊要了。
在中國（狹義上）的雲計算市場， 對於願意付費的客戶來說，CloudStack和Eucalyptus是值得優先考慮的選項。這兩個項目的啓動時間比較早，具有更好的穩定性和可靠性，在業界有較大的影響力，並且在國內有團隊可以提供支持和服務。與此同時，國內一些創業團隊開始提供基於OpenStack的解決方案，但是在短時間內很難積累必要的實戰經驗，而具備豐富經驗的新浪SAE團隊尚未開拓對外提供技術支持的業務。國內雖然也有一些單位在使用OpenNebula，但是在近期內很難形成對第三方提供技術服務的能力。對於願意花時間的客戶來說，CloudStack和OpenStack的優勢較爲明顯，因爲兩者的社區活躍度相對較高。在這兩者當中，CloudStack的功能更加豐富，也有更多的企業級客戶以及成功案例，可能是短期內的更佳選擇。從長遠來看，基於OpenStack的解決方案會越來越流行，但是其他解決方案在技術和市場上也都在不斷取得進步，因此在未來三年內很難形成一統天下的局面。單純從商業上考慮，CloudStack和Eucalyptus獲得成功的機率可能會更大一些。
G、其他
有些朋友希望我補充一些雲計算在中國的現狀。坦率地說，目前我尚不掌握充足的數據，在這裏暫不展開論述。劉黎明（新浪微博@劉黎明3000）最近發佈了一篇題爲《點評阿里雲盛大雲代表的雲計算IaaS產業》的文章，值得參考。
關於不同開源項目的社區活躍度比較，可以參考我最近的一篇博客文章《CY12-Q3 OpenStack, OpenNebula，Eucalyptus，CloudStack社區活躍度比較》。另外，我在《HP Cloud Services性能測試》一文中，也初步提出了一個對公有云進行性能評測的方法。
本文中的所有插圖，全部來自Google搜索。除此之外，部分概念性內容參考了維基百科的相關條目進行了改寫。
