【轉載】虛擬化、雲計算、開放源代碼及其餘

免責聲明：
    本文轉自網絡文章，轉載此文章僅爲我的收藏，分享知識，若有侵權，請聯繫 博主進行刪除。
    原文做者： 婉兮清揚
    原文地址： http://www.qyjohn.net/?p=1552

借國慶長假的機會寫了這篇長文，全面地整理了我的從虛擬化到雲計算各個層面的見解。主要的內容涉及虛擬化、虛擬化管理、數據中心虛擬化、雲計算、公有云與私有云、以及開放源代碼。本文的所有內容均屬於做者的我的觀點，而不表明任何公司的觀點。歡迎討論。

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 EC二、HP Cloud Services、盛大雲和阿里雲的性能測試結果代表，對於多種類型的應用來講，隨着虛擬機配置的提升，其性價比其實是不斷下降的。這樣的訂價策略，顯然不能達到鼓勵用戶使用更多計算資源的目的。

按照虛擬機的性能來訂價多是一個更加合適的作法。舉個例子說，某個牌子的肥皂有大小兩種包裝，小包裝有一塊肥皂而大包裝有兩塊肥皂。用戶願意花雙倍的錢購買大包裝，每每是由於大包裝可以洗兩倍的衣服而不是由於它看起來更大。同理，來自同一公有云服務提供商的不一樣虛擬機產品，應該儘量使其性價比維持在同一水平線上。問題在於，不一樣類型的應用對處理器、內存和存儲等計算資源的需求存在較大差別，其「性能–配置」變化曲線也各有不一樣。所以，在公有云服務領域須要一個對虛擬機性能進行綜合評估的框架，經過該框架得到的評估結果能夠表示一臺虛擬機的綜合處理能力，而不只僅是處理器、內存和存儲當中的任何一項。基於這樣一個測試框架，不只能夠對同一公有云服務提供商的產品進行比較，還能夠對不一樣公有云服務提供商的產品進行比較。

F、開放源代碼

近些年來，咱們在信息技術領域觀察到一個規律。當一個閉源的解決方案在市場上取得成功時，很快就會出現一個甚至是多個提供相似功能（或者服務）的開源或者閉源的追隨者。（首先出現開源軟件，而後出現與之競爭的閉源軟件的案例比較少見。）在操做系統領域，Linux逐漸達到甚至是超越了Unix的技術水平，進而取代Unix的市場地位。在虛擬化領域，Xen和KVM牢牢跟隨VMWare的技術發展並有所突破，逐步蠶食VMware的市場份額。在雲計算領域，Enomaly率先推出了以Amazon EC2爲藍本的閉源解決方案，緊跟着又出現了以Eucalyptus和OpenStack爲表明的開源解決方案。與此同時，傳統意義上的閉源廠商對開源項目和社區的態度也在發生轉變。例如，多年來對開源項目持敵視態度的微軟於今年四月組建了一家名爲「微軟開放技術」（Microsoft Open Technologies）的子公司，其目標是推動微軟向開放領域的投資，包括互操做性、開放標準和開源軟件。

咱們今天所處的商業環境，與上個世紀80年代自由軟件運動（Free Software 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搜索。除此以外，部分概念性內容參考了維基百科的相關條目進行了改寫。