【編者按】在雲端計算生態系統中，有兩種型別的使用者需要使用雲端計算資源：傳統型(Traditional IT applications)和在網際網路大潮下逐漸崛起雲端計算應用型(Cloud-aware applications)。國外廣為流傳的一個比喻是：在傳統服務模式下，可以想象伺服器就是IT的寵物(Pets)，給他們取名字，精心撫養長大，當他們生病了，你得修復他們;在新形態的應用服務模型中，虛擬機器被看做是農場中的公牛(Cattle)，名字通常都是編號，當他們生病了，你就殺掉他，用一頭新牛代替。VMWare和OpenStack的雲端計算Vision、功能、特點對比正式這個戰爭或者說趨勢的一個生動寫照。未來的應用架構應該像對待農場中的公牛一樣：VMware的“保養”、保護虛擬機器的各種功能比較雲端計算型應用模式可能會逐漸變得越來越不那麼重要。本文在國外廣泛流傳，熱議不斷，中國社群意譯分享給大家，歡迎積極討論。

　　全文如下：

　　在Cloud領域，我們討論最多的就是VMware與OpenStack的對比。事實上，這也是那些想使用OpenStack的人們熱議的話題。我已經在SF Bay OpenStack會議中多次針對這個話題做了討論，會議中很多朋友都希望我把這些討論寫下來。為了讓讀者能夠更好地瞭解本文的內容，我決定通過兩大雲端計算產品在資料中心應用的關鍵點對比的方式去完成本文的內容，內容可能包括：開放與非開放的軟體系統，企業級傳統應用與雲端計算應用，自由軟體與授權軟體，通過嚴格功能測試的產品與開放性功能的產品等。

　　本文中內容具體包括以下幾個部分：設計、功能集、客戶用例和價值，每點都以十分來評價，最終我們將以總分來決定贏家。

　　第一回合：設計

　　VMware軟體套件是自底向上的架構，下端邊界為虛擬機器管理器。像VMware的vSphere和vCloud director產品都是依賴於免費的ESX(i) 虛擬機器管理器， ESX(i)虛擬機器管理器為他們提供了非常優秀的部署架構。本身VMware的軟體套件也是經過全面測試過的，並且都有單一部署框架。總的來說，VMware的產品由於其架構的健壯性，很多高規格使用者在多資料中心規模的環境中都有使用。換句話說，VMware的軟體系統是封閉的，並且軟體的發展路線是完全遵循VMware自己的發展目標，使用者或消費者在此方面沒有任何控制權。

　　OpenStack作為一個開源系統，沒有任何一家單獨的公司在控制OpenStack的發展路線。本身OpenStack是年輕的，還不滿三週歲，但是他卻具有巨大的市場動力，與此同時，很多大公司都在支援OpenStack發展(詳見：OpenStack支持者)。有了如此多公司的資源投入，OpenStack的發展是多元化的。然而這也帶來了問題，就是OpenStack部署和架構的實施和維護成本較比VMware有了陡然提高，與此同時，由於相對快速的版本更新速度，技術支援文件不能跟上產品的腳步。

　　VMware在設計方面稍佔優勢，這源於它優秀的文件資料以及便捷易用的部署和管理介面。OpenStack在這個方面也在緊追不捨，並且在硬體和虛擬機器管理層其保持了它自身的靈活性，更是提供了多廠商支援。

　　第二回合：功能

　　VMware vMotion

　　vMotion是vSphere DRS、DPM和主機維護三大功能的合集。其中虛擬機器動態遷移允許將一臺虛擬機器在零關機的情況下由一臺宿主機遷移到另一臺上，這原本是需要共享儲存的支援的，但在vSphere 5.1中，VMware已經不需要通過共享儲存實現動態遷移了。當一臺虛擬機器由一個宿主機遷移到另一個上時，虛擬機器的記憶體狀態和資料都要同步遷移過去。如果是共享儲存的情況，實際上資料是不需要進行遷移的，只需要變化指向資料儲存的連結而已。這在加速了遷移速度的同時也減少了在複製過程中網路的負載。

　　OpenStack 動態遷移

　　KVM動態遷移允許一個虛擬機器由一個虛擬機器管理器遷移到另一個，說的詳細一點，你可以來來回回將一臺虛擬機器在AMD架構主機與Intel架構主機上進行遷移，但是需要注意的是，64位的虛擬主機只能被遷移到64位的宿主機上，但是32位的則有32位和64位兩種選擇。在動態遷移過程中，不能再對虛擬機器進行操作，但是虛擬機器內的使用者還是可以在虛擬機器內部繼續進行工作的。KVM主要還是依賴於共享儲存，某種程度上，這相對來說是需要一些資金投入的。

　　動態遷移需求：

　　虛擬機器儲存需要放在分散式檔案系統之上，如NFS或在GlusterFSLibvirt必須要開啟listen flag每一個計算節點(虛擬機器管理器)都必須在同一個網路/子網當中計算節點間的認證必須提前完成配置DFS的掛載節點在每一個計算節點必須保持一致

　　OpenStack塊儲存遷移

　　在OpenStack當中，KVM支援塊儲存遷移，這也就是說虛擬機器遷移不是必須需要共享儲存的支援的。在塊遷移的場景下，虛擬機器的記憶體狀態與資料都將被遷移，但是遷移操作也需要消耗兩端的CPU資源並且操作花費時間較比共享儲存來說要長一些。在某些使用者場景當中，如果我們比較關注於主機的可維護性，並且不想花費過多經費，那麼應用塊儲存遷移將是好的解決方案。同時，如果在沒有共享儲存的環境中，我們想對計算節點進行核心維護、安全升級，那麼保證虛擬機器服務不被打斷，塊儲存遷移也是理想選擇。

　　使用者場景：

　　使用者沒有分散式檔案系統，可能是由於企業的資金支援或者網路延遲，但是卻想實現虛擬機器的高可用性。

　　VMware DRS 和 DPM

　　基於vMotion，DRS可以動態監控虛機機及宿主機的當前使用狀況，並且為宿主機的負載均衡提供支援。

　　使用者場景：

　　部署階段：可以對監控虛擬機器執行自定義自動化指令碼監控階段：DRS可以在ESX(i)主機上分散式部署虛擬機器，並且持續監控活躍虛擬機器和可用資源，以動態遷移虛擬機器來實現資源利用率最大化

　　基於vMotion， DPM將虛擬機器從低負載宿主機遷移掉，並且關閉以達到減少電能損耗。當負載增長，DPM將宿主機重啟，並且部署新的虛擬機器以滿足負載需要。

　　OpenStack 排程器

　　OpenStack包含了對於compute和volume的排程器，通過一系列的管理員設定的規則引數和過濾器，OpenStack排程器將虛擬機器部署到合適的宿主機上。在過濾器方面，排程器是非常靈活的，使用者可以自己完成JSON格式的過濾器，並且過濾器還包含很多預定義的過濾器。雖然OpenStack排程器非常靈活，但是還是不能完全替代DRS，原因如下：

　　VMware High Availability(高可用)

　　在vSphere中，虛擬機器級別的高可用性是允許在虛擬機器或者ESX(i)主機出錯時，在不同宿主機部署相同的虛擬機器。這裡不要和容錯(FT)機制混淆，高可用的意義在於當有一些東西出錯了，可以在一定時間內自我修復。高可用是在硬體出問題的時候保證虛擬機器的正常個工作，如果真的出錯了，那麼只能在不同的ESX(i)主機上啟動虛擬機器，這也可能造成服務的中斷。

　　OpenStack High Availability(高可用)

　　目前並沒有官方宣告OpenStack支援虛擬機器級別的高可用性，這個特性在Folsom版本被提出，但是後續又被放棄了。目前OpenStack有一個孵化專案Evacuate, 其作用是為OpenStack提供虛擬機器級別高可用支援。

　　VMware Fault Tolerance(容錯)

　　VMware容錯機制是通過監控虛擬機器的狀態和所有變化，將這些變化同步到第二臺備份ESX(i)伺服器之上。容錯的概念在於無論是主還是從宿主機出現問題，只要一方能正常工作，那麼宿主機上的虛擬機器都保持正常工作。拋開營銷中的噱頭，這種機制還是無法解決虛擬機器中的應用程式崩潰，因為一旦一方崩潰，則這個變化也會同步到從節點，當你停止虛擬機器的服務去修復它，從節點也會同樣停止服務。所以這個機制只能保證單點失效的問題不再出現，而真正的應用層面的容錯則需要MSCS或者WCS來解決。考慮到其他方面如最高資源使用、記憶體、硬碟、CPU、頻寬的容錯，這些方面都有侷限性，並且是使用量相對比較小的功能。如實現這些則這需要雙倍的記憶體，由於記憶體不能跨主機複製，並且還需要CPU lockstepping去同步每一個CPU指令。這將導致只有單獨一個虛擬CPU被容錯機制所監控。

　　OpenStack Fault Tolerance(容錯)

　　在OpenStack中沒有針對於容錯的功能，並且截至目前也沒有計劃去完成這些功能。未來，KVM也不再支援映象操作功能。

　　我們可以看到，在功能的支援方面和功能細節，OpenStack與VMware還是有差距的，但是這對OpenStack還是有優勢的，因為較比VMware的昂貴价格，OpenStack免費、開放的優勢顯現出來。VMware高投入帶來的功能，OpenStack大部分可以免費提供給客戶。

　　從VMware在功能方面的領先可以看出，VMware還在繼續研發除了vMotion、高可用、容錯以外其他的新功能去保護他們的虛擬機器;OpenStack一方面跟隨VMware的腳步，另一方面他們投入精力在支援更多硬體廠商解決方案的上面。

　　第三回合：用例

　　在我們評價上述功能的價值之前，首先我們需要考慮用例問題。在雲端計算生態系統中，有兩種型別的使用者需要使用雲端計算資源：傳統型和雲端計算應用型。雲端計算應用型使用者將自己處理HA和DR策略，而傳統型使用者將依賴於雲平臺提供的HA和DR。看下面出自VMware雲端計算架構文章的圖表。

　　雲端計算型應用共同特點

　　分散式無狀態、軟狀態失效切換在應用端擴充套件性在應用端

　　傳統型應用共同特點

　　客戶端-伺服器架構難以橫向擴充套件失效切換在服務端擴充套件性在服務端

　　傳統型應用將需要如FT、VM級別的高可用性、自動病毒掃描等功能，而云計算型應用則不需要，當一臺虛擬機器出問題後，新的一臺虛擬機器將替代它。

　　Pet vs. Cattle

　　換一種思路去想這件事，那就可以從微軟 William Baker的出名文章 Pets vs. Cattle 的比喻看出OpenStack和Vmware的關係。

　　比喻是這樣說的：在傳統服務模式下，你可以想象你的主機就是你的寵物，你給他們取名字，比如dusty、cern等等，他們被精心撫養長大。當他們生病了，你得修復他們。在雲端計算型應用服務模型中，虛擬機器被看做是農場中的公牛，他們的名字通常都是編號，牛和牛長得也差不多，當他們生病了，你就殺掉他，用一頭新牛代替。

　　未來的雲應用架構應該像對待農場中的公牛一樣。VMware的保養、保護虛擬機器的各種功能較比雲端計算型應用模式變得越來越不那麼重要了。

　　在這輪比賽中，OpenStack追了上來，雖然VMware有很多OpenStack所不具有的功能，但是針對雲端計算型應用，這些功能變得不那麼重要。未來，你很可能為那些你用不上的、不可控的VMware新增功能買單。

　　第四回合：價值

　　現在是最後一回合，我們將決定比賽結果。雖然，OpenStack還是VMware更有價值，這個問題並沒有很清晰的答案，並且答案也取決於部署規模。雖然OpenStack是免費使用的，但是他需要有大量工程資源和領域專家才行，並且他還需要很多架構和搭建方面的工作，因為它支援很多部署場景，並且安裝過程都不盡相同。VMware則需要花費一些經費購買許可權，並且相對來說更加容易安裝和執行，另外較比命令列，VMware則學習成本更低一些。

　　總得來說，OpenStack入門門檻較高，但是隨著專案規模的擴大，你將從中受益，因為不必支付高額的版權費用。VMware雖然在小規模安裝時相對容易，但是隨著規模擴大，事情就變了。這就是說，隨著雲應用大規模化，大家也更加熟悉OpenStack，那麼OpenStack的入門門檻就低得多了。

　　在雲端計算領域，OpenStack和VMware這兩位重量級玩家，VMware在功能和架構上稍微領先，但是OpenStack作為一隻弱旅，卻在第三回合迎頭趕上並在最後一回合給予對方毀滅性打擊。

　　後記

　　巧合的是，在寫這篇文章的時候，VMware股價在一月29日一天就下跌了22%,市場分析稱VMware缺乏清晰、優秀的雲端計算策略。

　　我也瞭解為什麼大家不同意我的給分，並且不明我為何在四輪對比中權重相同。說實話，這個評分不是那麼完美，也沒有那麼客觀，但是他有他的存在的意義，他讓這場雲端計算這場戰爭變得更加有趣，請大家積極評論並提出您的觀點。

　　譯者補充：針對此文章精華評論

　　OpenStack社群：Toby Ford

　　這是一篇非常出色的深入挖掘兩者區別的文章，比如 Pets vs. Cattle的比喻就非常好，另外，我認為評價標準應該再增加幾個緯度。

　　在DRS與OS Scheduler對比中，目前，DRS對比OpenStack Scheduler是有優勢的，因為DRS採用各種關鍵指標去決策部署虛擬機器時的主機節點選擇，另外，DRS還會對虛擬機器整個生命週期進行監控。

　　但是，DRS是封閉的，這些權重指標都無法配置，舉一個簡單的例子：如果在晚上很短的時間內，CPU的負載突然增高，這並不意味著我們需要將虛擬機器遷移到另一臺宿主機之上，或者如果管理員知道在未來一段時間將會虛擬機器將會發生一些問題而又不想DRS介入其中，這就變得非常難辦了。相反，OpenStack Scheduler則會逐步與DRS拉開距離，特別是當其變得更加可擴充套件。

　　針對為什麼說vMotion採用動態/全生命週期地去維護虛擬機器很重要：vMotion/DRS/HA都是處理傳統型虛擬機器的必備功能，顯而易見，這跟虛擬機器的類別其實沒什麼關係，而我要說的是vMotion/DRS 對於資源的最大化利用還是很重要的。

　　在我們的實際環境中，我就因為需要自定義排程規則而不得不關閉了DRS，雖然我們自定義了排程規則，但是VMware的升級使這種自定義的排程器變得非常難以維護。

　　我想要說的是，OpenStack不單單面向cattle模式的應用場景，對於處理pets模式的虛擬機器也會越來越好。

　　原文連結：http://www.mirantis.com/blog/cloud-prizefight-vmware-vs-openstack/