openstack中國社群編者按：在雲計算生态系統中，有兩種類型的使用者需要使用雲計算資源：傳統型(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有了陡然提高，與此同時，由于相對快速的版本更新速度，技術支援文檔不能跟上産品的腳步。
vmotion是vsphere drs、dpm和主機維護三大功能的合集。其中虛拟機動态遷移允許将一台虛拟機在零關機的情況下由一台主控端遷移到另一台上，這原本是需要共享存儲的支援的，但在vsphere 5.1中，vmware已經不需要通過共享存儲實作動态遷移了。當一台虛拟機由一個主控端遷移到另一個上時，虛拟機的記憶體狀态和資料都要同步遷移過去。如果是共享存儲的情況，實際上資料是不需要進行遷移的，隻需要變化指向資料存儲的連結而已。這在加速了遷移速度的同時也減少了在複制過程中網絡的負載。
kvm動态遷移允許一個虛拟機由一個虛拟機管理器遷移到另一個，說的詳細一點，你可以來來回回将一台虛拟機在amd架構主機與intel架構主機上進行遷移，但是需要注意的是，64位的虛拟主機隻能被遷移到64位的主控端上，但是32位的則有32位和64位兩種選擇。在動态遷移過程中，不能再對虛拟機進行操作，但是虛拟機内的使用者還是可以在虛拟機内部繼續進行工作的。kvm主要還是依賴于共享存儲，某種程度上，這相對來說是需要一些資金投入的。
動态遷移需求：
在openstack當中，kvm支援塊存儲遷移，這也就是說虛拟機遷移不是必須需要共享存儲的支援的。在塊遷移的場景下，虛拟機的記憶體狀态與資料都将被遷移，但是遷移操作也需要消耗兩端的cpu資源并且操作花費時間較比共享存儲來說要長一些。在某些使用者場景當中，如果我們比較關注于主機的可維護性，并且不想花費過多經費，那麼應用塊存儲遷移将是好的解決方案。同時，如果在沒有共享存儲的環境中，我們想對計算節點進行核心維護、安全更新，那麼保證虛拟機服務不被打斷，塊存儲遷移也是理想選擇。
使用者場景：
使用者沒有分布式檔案系統，可能是由于企業的資金支援或者網絡延遲，但是卻想實作虛拟機的高可用性。
基于vmotion，drs可以動态監控虛機機及主控端的目前使用狀況，并且為主控端的負載均衡提供支援。
基于vmotion， dpm将虛拟機從低負載主控端遷移掉，并且關閉以達到減少電能損耗。當負載增長，dpm将主控端重新開機，并且部署新的虛拟機以滿足負載需要。
openstack包含了對于compute和volume的排程器，通過一系列的管理者設定的規則參數和過濾器，openstack排程器将虛拟機部署到合适的主控端上。在過濾器方面，排程器是非常靈活的，使用者可以自己完成json格式的過濾器，并且過濾器還包含很多預定義的過濾器。雖然openstack排程器非常靈活，但是還是不能完全替代drs，原因如下：
在vsphere中，虛拟機級别的高可用性是允許在虛拟機或者esx(i)主機出錯時，在不同主控端部署相同的虛拟機。這裡不要和容錯（ft）機制混淆，高可用的意義在于當有一些東西出錯了，可以在一定時間内自我修複。高可用是在硬體出問題的時候保證虛拟機的正常個工作，如果真的出錯了，那麼隻能在不同的esx(i)主機上啟動虛拟機，這也可能造成服務的中斷。
目前并沒有官方聲明openstack支援虛拟機級别的高可用性，這個特性在folsom版本被提出，但是後續又被放棄了。目前openstack有一個孵化項目evacuate, 其作用是為openstack提供虛拟機級别高可用支援。
vmware容錯機制是通過監控虛拟機的狀态和所有變化，将這些變化同步到第二台備份esx(i)伺服器之上。容錯的概念在于無論是主還是從主控端出現問題，隻要一方能正常工作，那麼主控端上的虛拟機都保持正常工作。抛開營銷中的噱頭，這種機制還是無法解決虛拟機中的應用程式崩潰，因為一旦一方崩潰，則這個變化也會同步到從節點，當你停止虛拟機的服務去修複它，從節點也會同樣停止服務。是以這個機制隻能保證單點失效的問題不再出現，而真正的應用層面的容錯則需要mscs或者wcs來解決。考慮到其他方面如最高資源使用、記憶體、硬碟、cpu、帶寬的容錯，這些方面都有局限性，并且是使用量相對比較小的功能。如實作這些則這需要雙倍的記憶體，由于記憶體不能跨主機複制，并且還需要cpu lockstepping去同步每一個cpu指令。這将導緻隻有單獨一個虛拟cpu被容錯機制所監控。
在openstack中沒有針對于容錯的功能，并且截至目前也沒有計劃去完成這些功能。未來，kvm也不再支援鏡像操作功能。
在我們評價上述功能的價值之前，首先我們需要考慮用例問題。在雲計算生态系統中，有兩種類型的使用者需要使用雲計算資源：傳統型和雲計算應用型。雲計算應用型使用者将自己處理ha和dr政策，而傳統型使用者将依賴于雲平台提供的ha和dr。看下面出自vmware雲計算架構文章的圖表。
雲計算型應用共同特點
傳統型應用共同特點
傳統型應用将需要如ft、vm級别的高可用性、自動病毒掃描等功能，而雲計算型應用則不需要，當一台虛拟機出問題後，新的一台虛拟機将替代它。
換一種思路去想這件事，那就可以從微軟 william baker的出名文章 pets vs. cattle 的比喻看出openstack和vmware的關系。
比喻是這樣說的：在傳統服務模式下，你可以想象你的主機就是你的寵物，你給他們取名字，比如dusty、cern等等，他們被精心撫養長大。當他們生病了，你得修複他們。在雲計算型應用服務模型中，虛拟機被看做是農場中的公牛，他們的名字通常都是編号，牛和牛長得也差不多，當他們生病了，你就殺掉他，用一頭新牛代替。
未來的雲應用架構應該像對待農場中的公牛一樣。vmware的保養、保護虛拟機的各種功能較比雲計算型應用模式變得越來越不那麼重要了。
現在是最後一回合，我們将決定比賽結果。雖然，openstack還是vmware更有價值，這個問題并沒有很清晰的答案，并且答案也取決于部署規模。雖然openstack是免費使用的，但是他需要有大量工程資源和領域專家才行，并且他還需要很多架構和搭建方面的工作，因為它支援很多部署場景，并且安裝過程都不盡相同。vmware則需要花費一些經費購買權限，并且相對來說更加容易安裝和運作，另外較比指令行，vmware則學習成本更低一些。
總得來說，openstack入門門檻較高，但是随着項目規模的擴大，你将從中受益，因為不必支付高額的版權費用。vmware雖然在小規模安裝時相對容易，但是随着規模擴大，事情就變了。這就是說，随着雲應用大規模化，大家也更加熟悉openstack，那麼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模式的虛拟機也會越來越好。