① 如何使用OpenStack，Docker和Spark打造一個雲服務
從一項顛覆性的技術成果轉化並衍生出一整套社區體系，Docker在發展速度上打破了一個又一個歷史紀錄。然而，Docker項目在採納與普及方面表現出驚人態勢的同時，也給我們帶來了一系列疑問與困惑。在今天的文章中，我希望將注意力集中在朋友們最為關注的評論議題身上。隨著Docker項目在人氣方面的持續飆升，很快剛剛接觸這一新生事物的讀者在實踐過程中不禁產生了這樣的疑問：如果已經決定使用Docker，是否還有必要同時使用OpenStack？在給出自己的觀點之前，我打算首先就背景信息入手為各位進行講解，從而更為透徹地認清這個命題背後所隱藏的理論基礎。背景信息從最為簡單的構成形式出發，Docker實際上旨在提供一套能夠在共享式基礎設施之上對軟體工作負載進行管理的容器環境，但同時又確保不同負載之間彼此隔離且互不影響。以KVM為代表的虛擬機系統所做的工作也差不多：創建一套完整的操作系統堆棧，通過虛擬機管理程序將與該系統相關的設備囊括進來。然而與虛擬機解決方案的區別在於，Docker在很大程度上依賴於Linux操作系統所內置的一項功能——名為LXC（即Linux容器）。LXC利用內置於操作系統當中的各項功能將不同進程的內存進行劃分，甚至能夠在一定程度上拆分CPU與網路資源。Docker鏡像不需要像一套全新操作系統那樣進行完整的引導過程，這樣一來軟體包的體積就能得到大幅壓縮、應用程序運行在共享式計算資源之上時也將具備更為顯著的輕量化優勢。除此之外，Docker還允許工作負載直接訪問設備驅動程序、從而帶來遠超過虛擬機管理程序方案的I/O運行速度。在這種情況下，我們得以直接在裸機設備上使用Docker，而這就帶來了前面提到的核心問題：如果已經使用了Docker，我們還有必要同時使用OpenStack等雲方案嗎？前面的結論絕非信口開河，BodenRussell最近針對Docker與KVM等虛擬機管理程序在性能表現上的差異進行了基準測試，並在DockerCon大會上公布了測試結果。本次基準測試提供相當詳盡的具體數據，而且如預期一樣，測試結果顯示引導KVM虛擬機管理程序與引導Docker容器之間存在著顯著的時間消耗差異。本次測試同時表明，二者之間在內在與CPU利用率方面同樣存在著巨大區別，具體情況如下圖所示。紅色線條為KVM，藍色線條為Docker。這種在性能表現上的顯著區別代表著兩套目的相近的解決方案在資源密度與整體利用率方面大相徑庭。而這樣的差異也將直接體現在運行特定工作負載所需要的資源總量上，並最終反映到實際使用成本當中。結論整理·上述結論並不單純指向OpenStack，但卻適用於OpenStack以及其它與之類似的雲基礎設施解決方案。在我看來，之所以問題的矛頭往往最終會被指向OpenStack，是因為OpenStack項目事實上已經在私有雲環境領域具備相當高的人氣，同時也是目前我們惟一會考慮作為Docker替代方案的技術成果。·問題的核心不在於OpenStack，而在於虛擬機管理程序！很多性能基準測試都將Docker與KVM放在了天秤的兩端，但卻很少將OpenStack牽涉於其中。事實上，前面提到的這次專項基準測試同時將OpenStack運行在KVM鏡像與Docker容器環境之下，結果顯示這兩類技術成果能夠帶來理想的協作效果。考慮到這樣的情況，當我們選擇將OpenStack運行在基於Docker的Nova堆棧當中時——正如OpenStack說明文檔提供的下圖所示——那些資源利用率參數將變得無關緊要。·在這種情況下，雲基礎設施能夠在容器或者虛擬機管理程序當中提供一套完整的數據中心管理解決方案，而這僅僅屬於龐大系統整體當中的組成部分之一。以OpenStack為代表的雲基礎設施方案當中包含多租戶安全性與隔離、管理與監控、存儲及網路外加其它多種功能設置。任何雲/數據中心管理體系都不能脫離這些服務而獨立存在，但對於Docker或者是KVM基礎環境卻不會做出過多要求。·就目前來講，Docker還不算是一套功能全面的虛擬化環境，在安全性方面存在多種嚴重局限，缺乏對Windows系統的支持能力，而且因此暫時無法作為一套真正可行的KVM備用方案。盡管正在持續進行當中的後續開發工作將逐步彌合這些差距，但抱持著相對保守的心態，這些問題的解決恐怕也同時意味著容器技術將在性能表現方面有所妥協。·另外需要注意的是，原始虛擬機管理程序與經過容器化的實際應用程序性能同樣存在著巨大差異，而且下面這幅來自基準測試的圖表清楚地說明了這一點。目前可能合理的解釋在於，應用程序通常會利用緩存技術來降低I/O資源開銷，而這大大影響了測試結果對真實環境中運行狀態的准確反映。·如果我們將Docker容器打包在KVM鏡像當中，那麼二者之間的差異將變得可以忽略不計。這套架構通常利用虛擬機管理程序負責對雲計算資源的控制，同時利用Heat、Cloudify或者Kubernetes等流程層在虛擬機資源的容納范圍之內進行容器管理。總結由此我得出了這樣的結論：要想正確地看待OpenStack、KVM以及Docker三者之間的關系，正確的出發點是將其視為一整套輔助堆棧——其中OpenStack扮演整體數據中心管理方案的角色，KVM作為多租戶計算資源管理工具，而Docker容器則負責與應用部署包相關的工作。在這樣的情況下，我們可以匯總出一套通用型解決模式，其中Docker分別充當以下幾種角色：·Docker提供經過認證的軟體包，並保證其能夠與穩定不變的現有基礎設施模型順利協作。·Docker為微服務POD提供出色的容器化運行環境。·在OpenStack之上使用Docker，並將其作用與裸機環境等同的運行平台。前面說了這么多，我確實親眼見證過不少經過精確定義的工作負載實例，對於它們來說是否使用雲基礎設施僅僅是種自由選項而非強制要求。舉例來說，如果我出於DevOps的目的而考慮建立一套小型自動化開發與測試環境，那麼我個人更傾向於在裸機環境上直接使用Docker機制。而虛擬機與容器這兩類環境之間，流程層將成為一套絕佳的抽象對接工具。將流程框架與Docker共同使用的一大優勢在於，我們能夠根據實際需求、隨時在OpenStack以及裸機環境之間進行切換。通過這種方式，我們將能夠選擇任意一種解決選項——只要其切實符合我們流程引擎對於目標環境的具體需要。OpenStackOrchestration（即Heat）在最新發布的Icehouse版本當中已經明確表示支持Docker環境。Cloudify作為一款基於TOSCA的開源流程框架，原本適用於OpenStack以及VMware、AWS乃至裸機等雲環境，而最近也開始將Docker支持納入自身。谷歌Kubernetes主要面向的是GCE協作目標，但我們也能夠通過自定義來使其適應其它雲或者運行環境。
② 5歲的OpenStack為什麼這么火
OpenStack的兩面性
雖然OpenStack誕生不過5歲，如果用人類的標准衡量還是一名嬰兒，但是它在簡化雲的部署、構建應用和服務、可擴展性、可管理性等諸多方面，都展現出了與其實際年齡不相稱的強大力量。不久前，在遍布全球的169家機構和1500名開發者的集體貢獻下，OpenStack剛發布了其第11個迭代版本kilo。除了大家耳熟能詳的IBM、Rackspace、惠普、紅帽等十幾家IT巨頭之外，就連VMware也成為了全球第一批通過OpenStack基金會官方互操作性測試認證的廠商。
作為一個新生項目，OpenStack為什麼能夠得到如此迅猛的發展？紅帽大中華區總裁張先民博士一語道破：「因為眾人拾柴火焰高。」
既然是做開源項目，那就絕對不能單打獨斗，而是應該聯合更多的合作夥伴通過建立生態系統來把市場做大做強。譬如紅帽在中國就聯合了英特爾、華為、聯想、華勝天成等眾多合作夥伴，一起來構建OpenStack生態系統。
③ openstack基金會是什麼組織
概述
OpenStack基金會是OpenStack的全球獨立家園，旨在推動OpenStack雲操作系統在全球的發展、傳播和使用。OpenStack基金會的目標是在全球范圍內服務開發者、用戶及整個生態系統，為其提供共享資源，以擴大OpenStack公有雲與私有雲的成長，從而幫助技術廠商選擇平台，助力開發者開發出行業最佳的雲軟體。
OpenStack基金會它是一家非盈利組織，在2012年成立，SUSE的行業創新總監Alan Clark擔任OpenStack基金會主席這一要職。OpenStack基金會分為個人會員和企業會員兩大類。OpenStack基金會個人會籍是免費無門檻的，他們可憑借技術貢獻或社區建設工作等參與到OpenStack社區中。而公司參與的會根據各司贊助會費的情況，分成白金會員、黃金會員、企業贊助會員以及支持組織者，其中白金和黃金會員的話語權最大，目前，OpenStack基金會的董事會有兩名成員是來自於中國的公司，而整個基金會中黃金會員級別的公司中中國企業已經占據到3家，他們分別是華為、EasyStack和UnitedStack有雲。
董事會成員選拔
OpenStack基金會董事成員包括24位，白金會員在董事會里的8名席位是固定的，不用參與競選，而剩餘的16位將是競選得出，其中的8位要在所有黃金會員里進行角逐，方式是由黃金會員們在1天內投票決定，並且不對社區進行公開。另外的8位被稱作個人獨立董事，他們是由千萬社區個人會員經過1周投票最終決定的。席位在基金會董事會里是可以影響OpenStack發展和建設方向的，重要性不言而喻，所以這也就成為了企業們對會員級別和董事會席位趨之若鶩的原因。
基金會企業會員的劃分
說完了董事會成員的劃分，再來看看企業會員都有誰，准確來講，OpenStack基金會只允許最多8家白金會員資格和24家黃金會員資格。
白金會員僅限的8個席位已被AT&T、Canonical、惠普、IBM、英特爾、Rackspace、紅帽和SUSE這8家囊括。
而黃金會員僅限24個席位，如下圖所示包括了Aptira、CCAT、思科、戴爾、DreamHost、EasyStack、EMC、愛立信、富士通、日立、華為、inwinStack、Juniper Networks、Mirantis、NEC、NetApp、賽門鐵克，UnitedStack 以及Virtuozzo這19家，目前尚有5個空缺位置。
OpenStack基金會主席Alan Clark告訴我們，社區對於個人會員而言是非常開放的，基本上向任何人敞開。但如果想要成為金牌會員的話，那麼就必須要通過一系列的標准對後備公司進行審核，並且必須經由基金會、董事會成員批准。考核的首要一點就是要看他們是否對OpenStack社區做出了貢獻。
④ Cloud Foundry是贏家嗎
PaaS供應商Cloud Foundry已經正式從Pivotal分離出來，OpenStack背後廠商紛紛支持Cloud Foundry，甚至連OpenStack旗下的PaaS項目Solum主導者RackSpace也支持它，那麼Cloud Foundry會是這場PaaS平台之爭的贏家嗎？
企業PaaS供應商Cloud Foundry 2月下旬已經正式從Pivotal分離出來，Cloud Foundry將通過Cloud Foundry基金會繼續發展，旨在創建開源平台即服務（PaaS）產品，包括針對OpenStack和紅帽的OpenShift平台開發的產品。Cloud Foundry作為一個開源項目已經獲得Apache 2.0許可，這意味著Cloud Foundry的發展將會更加規范有序。
Cloud Foundry最近非常受歡迎，運行在OpenStack上，事實上其他一些PaaS系統也運行在OpenStack上，例如IBM的BlueMix PaaS解決方案是基於Cloud Foundry，而Cloud Foundry本身就是運行在OpenStack之上的。
現在OpenStack背後的重要支持者例如IBM、HP、Rackspace都加入了CF基金會，這是不是意味著OpenStack社區只滿足於IaaS而不思進取了呢？——有趣的是Rackspace在不久前才宣布了自己的開源PaaS項目Solum。
有人認為Cloud Foundry基金會的發展，對於努力營造OpenStack PaaS的人而言就像是喪鍾。OpenStack PaaS項目Solum成為這場爭論的核心。Solum項目是由Rackspace推出的，但是現在連Rackspace也加入到了Cloud Foundry基金會中，因此，很多客戶可能認為連Rackspace自己也支持Cloud Foundry，它的Solum項目會不會因此而廢棄？
Rackspace副總裁John Igoe認為現在有兩種類型的服務層受到我們客戶的歡迎，關鍵取決於你是以PaaS為中心還是以IaaS為中心。以PaaS為中心的客戶可能青睞Cloud Foundry的跨雲可移植，而以IaaS為中心的客戶可能看重Solum能夠充分利用現有基礎設施。
有意思的是，在眾多廠商高調支持Cloud Foundry當中，唯獨沒有RedHat，Solum的命運對於Red Hat來說至關重要，Red Hat一直在推銷自己的PaaS產品OpenShift，它希望藉助Solum將OpenShift遷移到OpenStack，就憑這一點，Red Hat就是OpenStack的堅定支持者，所以這次它缺席Cloud Foundry基金會也就不足為怪了。
Piston的Josh McKenty建議Red Hat徹底關閉OpenShift加入Cloud Foundry。觀察者認為Cloud Foundry基金會對它造成了威脅，由於Red Hat的OpenShift目前還沒有獲得任何大財團的支持，甚至有人推測RedHat最終將放棄OpenShift轉投Cloud Foundry。因此與開源競爭對手OpenShift相比，Cloud Foundry現階段無疑是PaaS項目中的贏家。
但眾商圍繞PaaS平台之爭，歸根結底都是受到商業利益驅使，OpenStack的PaaS項目Solum並不會因為CloudFoundry的剝離而停滯不前，RedHat的Openshift項目也不會因此被拋棄，直到荒蕪，相反，它們還將繼續向前發展，PaaS市場的競爭將更加激烈、更加多元，在這場競爭中唯一決定勝負的就是真正打動客戶的產品。就像OpenStack的成員之間很難有真正的朋友，圍繞在OpenStack和CloudFoundry兩個生態系統之間的關系也是愛恨交加。
轉載，僅供參考。
⑤ 重啟openstack需要先關閉所有虛擬機嗎
在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有了陡然提高，與此同時，由於相對快速的版本更新速度，技術支持文檔不能跟上產品的腳步。
設計評分
設計 功能 用例 價值
OpenStack 7
VMware 8
VMware在設計方面稍占優勢，這源於它優秀的文檔資料以及便捷易用的部署和管理介面。OpenStack在這個方面也在緊追不舍，並且在硬體和虛擬機管理層其保持了它自身的靈活性，更是提供了多廠商支持。
第二回合：功能
VMware vMotion
vMotion是vSphere DRS、DPM和主機維護三大功能的合集。其中虛擬機動態遷移允許將一台虛擬機在零關機的情況下由一台宿主機遷移到另一台上，這原本是需要共享存儲的支持的，但在vSphere 5.1中，VMware已經不需要通過共享存儲實現動態遷移了。當一台虛擬機由一個宿主機遷移到另一個上時，虛擬機的內存狀態和數據都要同步遷移過去。如果是共享存儲的情況，實際上數據是不需要進行遷移的，只需要變化指向數據存儲的鏈接而已。這在加速了遷移速度的同時也減少了在復制過程中網路的負載。
OpenStack 動態遷移
KVM動態遷移允許一個虛擬機由一個虛擬機管理器遷移到另一個，說的詳細一點，你可以來來回回將一台虛擬機在AMD架構主機與Intel架構主機上進行遷移，但是需要注意的是，64位的虛擬主機只能被遷移到64位的宿主機上，但是32位的則有32位和64位兩種選擇。在動態遷移過程中，不能再對虛擬機進行操作，但是虛擬機內的用戶還是可以在虛擬機內部繼續進行工作的。KVM主要還是依賴於共享存儲，某種程度上，這相對來說是需要一些資金投入的。
動態遷移需求：
虛擬機存儲需要放在分布式文件系統之上，如NFS或在GlusterFS
Libvirt必須要開啟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，原因如下：
調度器用於選擇哪個宿主機進行虛擬機部署的靜態參考數據來源於Nova的資料庫。換句話說，就是發現宿主機已經有了4台虛擬機了，那麼我們需要選擇一個新的宿主機去部署下一台虛擬機。
調度器只能在虛擬機部署階段影響部署的位置，一旦部署完成，虛擬機運行後則無法挪動虛擬機了。如果需要基於動態數據進行調度，那麼調度器需要與外部監控解決方案如Nagios合作。總而言之，目前OpenStack調度器將只會對部署虛擬機環節有影響。
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 7
6
VMware 8 9
我們可以看到，在功能的支持方面和功能細節，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的關系。
比喻是這樣說的：在傳統服務模式下，你可以想像你的主機就是你的寵物，你給他們取名字，比如sty、cern等等，他們被精心撫養長大。當他們生病了，你得修復他們。在雲計算型應用服務模型中，虛擬機被看做是農場中的公牛，他們的名字通常都是編號，牛和牛長得也差不多，當他們生病了，你就殺掉他，用一頭新牛代替。
未來的雲應用架構應該像對待農場中的公牛一樣。VMware的保養、保護虛擬機的各種功能較比雲計算型應用模式變得越來越不那麼重要了。
用例評分
設計 功能 用例 價值
OpenStack 7
6 8
VMware 8 9 6
在這輪比賽中，OpenStack追了上來，雖然VMware有很多OpenStack所不具有的功能，但是針對雲計算型應用，這些功能變得不那麼重要。未來，你很可能為那些你用不上的、不可控的VMware添加功能買單。
第四回合：價值
現在是最後一回合，我們將決定比賽結果。雖然，OpenStack還是VMware更有價值，這個問題並沒有很清晰的答案，並且答案也取決於部署規模。雖然OpenStack是免費使用的，但是他需要有大量工程資源和領域專家才行，並且他還需要很多架構和搭建方面的工作，因為它支持很多部署場景，並且安裝過程都不盡相同。VMware則需要花費一些經費購買許可權，並且相對來說更加容易安裝和運行，另外較比命令行，VMware則學習成本更低一些。
總得來說，OpenStack入門門檻較高，但是隨著項目規模的擴大，你將從中受益，因為不必支付高額的版權費用。VMware雖然在小規模安裝時相對容易，但是隨著規模擴大，事情就變了。這就是說，隨著雲應用大規模化，大家也更加熟悉OpenStack，那麼OpenStack的入門門檻就低得多了。
⑥ 華為 fusion cube 存儲虛擬化用的是什麼技術
OpenStack峰會在法國巴黎如期舉行，各界共商雲軟體的未來。OpenStack會執行總監Jonathan Bryce提到「被動的技術應用已經成為歷史，取而代之的是由軟體定義的存儲、網路及數據中心」。這一簡短有力的發言引起了強烈的共鳴和反響。
Jonathan Bryce的主題發言的指出了一個不可否認的事實，即：越來越多的企業使用了按需分配資源的雲系統。軟體帶來了經濟的不斷發展，創新不再是掌握所有權的大型機構的專利了，而真正的創新是來自不同國家的數百家公司成千上萬的人一起合作的成果。
Openstack提供開源軟體的框架，簡化了基於雲系統的管理模式。雖然只有短短四年，但無論是從齊聚巴黎分享優秀實踐的峰會創下與會人數的歷史記錄——4,600開發者及用戶，還是將首個Superuser大獎授予了CERN——World Wide Web的創始者，用3000個伺服器7萬核組成了全球最大的OpenStack集群，這些無一不證明了OpenStack的成功。顯然，企業用戶已經認識到了這一點，並利用OpenStack來實現企業規則的改革。
基於OpenStack的FusionSphere
華為是應用OpenStack架構的公司之一，而且OpenStack已經被深度融合進華為的一系列IT產品。 OpenStack滿足了雲時代這類公司針對日益靈活的IT系統的管理需求。在步入雲計算領域時面對系統日益靈活的管理需求。
華為雲計算產品線營銷總監張建華提到「隨著計算能力、存儲及網路對硬體的依賴性下降，我們正在創建我們自己的軟體來滿足基於軟體定義資源的需求。」
他指出，Openstack雖然可以像膠水一樣將整個系統粘合在一起，但它只是個基礎。華為FusionSphere雲操作系統產品在OpenStack框架的基礎上還增加了不同的安全級別，並且使用戶能充分利用OpenStack提供的互通特性最新的FusionSphere 5.0還允許私有雲用戶連接像亞馬遜這樣的公共雲。
通過使用OpenStack，華為FusionSphere能夠管理來自不同廠家的虛擬伺服器、存儲、網路資源以及虛擬安全與負載均衡等設備。FusionSphere可以兼容作為雲計算基礎的異構虛擬化層，且物理伺服器虛擬化使FusionSphere能夠根據企業當前的需求完成不同的任務。如hypervisor，一個虛擬化多個物理系統的虛擬化層軟體，可以由不同供應商提供，使FusionSphere能夠很好地與已有設備或軟體配合完成相應任務。
軟體定義的基礎設施
和傳統的基於硬體的系統相比，軟體定義的數據中心具有很多優勢。軟體定義數據中心可以分解為軟體定義計算、軟體定義存儲和軟體定義網路。例如，軟體定義網路將網路的管理和只能路由功能抽取到軟體實體中，並且提供API供用戶按照應用的需要對網路進行編程，從而實現業務驅動網路；而實際數據交換功能則交付給專用的數據交換硬體設備，交換設備只專注於數據交換，這樣大大提高了數據交換的效率。軟體定義的數據中心具備很強的系統自愈能力。
那些對上述雲計算的保障機制需求強烈的企業，軟體定義的數據中心無疑具有強烈的吸引力。張建華還提到了電信運營商，「通常，這些公司很依賴硬線技術，但是目前的大量流量都不是通過傳統的電信網路傳輸。運營商需要改變來提供更多的IP服務」。Openstack與FusionSphere提供了像互聯網一樣的架構，從而能夠解決這些問題。他還補充到「運營商需要一個既懂得傳統架構又懂得新模式的合作夥伴才能邁進新紀元。他們還需要開放架構的解決方案，以避免受限於某一單一模式。」
OpenStack實現電信NFV變革
Telefonica意識到華為正是這樣的合作夥伴。因為這個原因，電信巨頭Telefonica決定採用華為FusionSphere集中管理其軟體、硬體以及數據中心。鑒於FusionSphere的統一調度與管理優勢，Telefonica在英國的運營商O2，在部署FusionSphere後的TCO大幅降低了約30%。FusionSphere通過三個方面實現客戶價值：運營維護（O&M）、業務管理、以及業務控制。另外，FusionSphere架構也將支持Telefonica的後續升級。
另外一個電信巨頭，沃達豐，也部署了FusionSphere來管理其基於PLEX系統的數據中心，以便管理不同廠商的資源和未被充分利用的資源，降低操作維護費用。公有雲和私有雲都在以這種模式進行管理，資源按需求動態分配，必要時業務也可以跨雲遷移。
除了電信領域外，OpenStack也為其他領域帶來了好處。匯港資訊有限公司採用華為OpenStack連通了香港經紀人與上海證券交易所。中國的一些政府部門的業務系統也通過部署華為雲產品，體驗到了這種IT架構的優勢，華為的雲產品可以為其消減成本、提高效率。
在OpenStack 峰會最後，華為的雲計算產品線首席技術官，王海鷹，上台分享了華為成為OpenStack會金牌會員的前景。他講到「從長遠看，華為將會繼續促進OpenStack與NFV的融合。我們也希望與所有領域夥伴合作構建一個健康的OpenStack系統」。我們正在進步。OpenStack已經有17,141個個人會員，432個支撐公司，以及兩千萬行代碼，這也證明了企業已經准備好迎接更敏捷的IT方案。這個方案將不僅能夠滿足當前需求，而且能夠靈活地控制未來的方案。華為FusionSphere，FusionCube（軟硬體雲管理一體機）以及其他的雲產品正是這樣一套既適應今天又能管理未來的強大的工具。
評論
請先登錄，再發表評論
敬請讀者發表評論，本站保留刪除與本文無關和不雅評論的權力。
OpenStack開發雲計算
OpenStack目標：解決實施中的瓶頸問題
OpenStack Neutron：雲服務中的開放網路
Salesforce或「登陸」OpenStack
Gartner分析師再次抨擊OpenStack「太嫩」
紅帽：Havana增強OpenStack的開發動力
雲計算疆場烽煙：OpenStack叫板Amazon
OpenStack你了解生態系統的價值嗎？
企業對OpenStack Havana熱情高漲 期待Icehouse
OpenStack是否已為IPv6做好准備？
OpenStack Havana新增雲網路功能
企業部署OpenStack：該做與不該做的事
DIY雲計算：OpenStack當積木
OpenStack私有雲滿足高IO需求
OpenStack互操作駕到：開源雲平台選擇更自由
失敗案例！OpenStack沒你想的那麼簡單！
SUSE OpenStack Cloud 5簡化私有雲管理
如何構建OpenStack存儲雲
企業用戶為何選擇OpenStack
使用OpenStack能開發企業私有雲嗎？
OpenStack在混合雲戰略中位置在哪？
OpenStack雲功能激發廠商支持
雲計算開源運動：廠商爭先公開源代碼
OpenStack私有雲DR的益處比其TCO更顯而易見
OpenStack企業~~進程舉步維艱
EMC收購Cloudscaling對OpenStack應用意義何在？
紅帽1.75億美元收購Inktank
紅帽 9,500萬美元收購eNovance
思科收購Metacloud
惠普1億美元收購Eucalytpus
EMC 5,000萬美元收購Cloudscaling
2014 OpenStack收購案盤點
華為持續重磅投入OpenStack 巴黎峰會全面展示開放雲
誰還敢於挑戰OpenStack的權威？出列！
預測到2018年OpenStack市場規模將達到33億美元
網易OpenStack部署運維實戰
紅帽公司發布 OpenStack Platform 5
開源雲平台：頂級OpenStack廠商一覽
OpenStack為技術宅提供了「拯救世界」的平台
OpenStack之小企業使用技巧
OpenStack現狀：四年後仍「不溫不火」
小型企業如何成功牽手OpenStack？
OpenStack：叫好不叫座
IBM Cloud Manager將OpenStack與伺服器關聯
OpenStack現在可配置NoSQL
雲計算戰爭OpenStack vs VMware:設計與功能
雲操作系統OpenStack：優勢與問題並存
Riverbed加入OpenStack社區：協作開發基於開源標准雲解決方案的優化先鋒
Rackspace將拆分開源雲計算軟體OpenStack
如何使用Puppet安裝OpenStack Nova雲？
Cloud.com將要合並OpenStack代碼庫
如何建立高可用OpenStack雲？
OpenStack里的三種存儲
OpenStack Grizzly發布 推進可擴展性和高可用性
OpenStack最新版本Grizzly新增部分功能一覽
面對雲鎖定的抉擇：OpenStack還是專有雲平台?
四種方案將OpenStack部署到Hadoop
如何成功實施OpenStack和CloudStack項目
Mark Collier：OpenStack API兼容AWS
三載風雨鑄就Openstack今日輝煌
⑦ 關於OpenStack的未來，你還會繼續看好嗎
不會繼續看好了，OpenStack基金會成立，專門有一個TC，技術委員會，負責OpenStack的技術方向，經過幾年的發展，基本已經成為的養老院和老油條。從2015搞的big tent，大帳篷項目，就是信心過於膨脹，項目從10個暴漲到50多個，不到1年的時間，問題就暴露出來。一直到今天，OpenStack項目還是在不斷增加，項目參與人手在不斷減少。大量的僵屍項目，沒人願意站出來當醜人，直接把項目砍掉。對比CNCF基金會，目前據說有500多個項目在排隊等待孵化批准，批准進入孵化階段門檻都是非常高，更別說畢業。
⑧ openstack為什麼需要整合ceph
Ceph 是一個符合 POSIX (Portable Operating System for UNIX®)、開源的分布式存儲系統，依據 GNU 次通用公共許可而運行。該項目最初由 Sage Weill 於 2007 年開發，該項目的理念是提出一個沒有任何單點故障的集群，確保能夠跨集群節點進行永久數據復制。
與在任何經典的分布式文件系統中一樣，放入集群中的文件是條帶化的，依據一種稱為 Ceph Controlled Replication Under Scalable Hashing (CRUSH) 的偽隨機的數據分布演算法放入集群節點中。
Ceph 是一種有趣的存儲替代方案，這得益於它實現的一些概念，比如元數據分區，以及一種復制或放置組策略（將一系列對象聚合到一個分組中，然後將該分組映射到一系列對象存儲後台進程 (OSD)）。
這些特性支持自動擴展、恢復和自主管理集群，因為他們使用以下綁定（在不同的級別上）提供了與您的 Ceph 集群的交互方式：
Reliable Autonomic Distributed Object Store (RADOS) 網關是一種 RESTful 介面，您的應用程序可與其通信，以便將對象直接存儲在集群中。
librados 庫是一種訪問 RADOS 的便利方式，它支持 PHP、Ruby、Java™、Python 和 C/C++ 編程語言。
Ceph 的 RADOS 塊設備 (RBD) 是一個完全分布式的塊設備，它使用一個 Linux® 內核和一個 Quick EMUlator (QEMU)/基於內核的虛擬機 (KVM) 驅動程序。
原生 CephFS 是一個分布式文件系統，全面支持 Filesystem in Userspace (FUSE)。
如 圖 1 中所示，Ceph 生態系統可分解為 5 個組成部分：
librados 庫
RADOS 網關
RBD
CephFS
集群中的各種節點
圖 1. Ceph 生態系統
Ceph 生態系統原生支持許多與其交互的方式，這使得在已運行的基礎架構中集成它變得既輕松又便捷，即使它執行的是一個在統一項目文件中提供塊和對象存儲功能的復雜任務。
接下來我們來看一下組成 Ceph 的各個部分以及它們在 Ceph 中分別扮演的角色。
RADOS 對象存儲
圖 1 表明 RADOS 對象存儲是存儲集群的基礎。對於通過眾多客戶端或網關（RADOSGW、RBD 或 CephFS）執行的每個操作，數據會進入 RADOS 或者可以從中讀取數據。圖 2 顯示了 RADOS 集群，它包含兩個後台守護進程：Ceph 對象存儲後台進程 (OSD) 和維護集群映射的主要副本的 Ceph 監視器。
圖 2. The RADOS 對象存儲
集群映射描述了對象塊的物理位置，以及一個將設備聚合到物理位置的 「桶」 列表。該映射由 Ceph 的高級放置演算法控制，該演算法在物理位置上建模邏輯位置。圖 3 描繪了集群內的 「池」，即存儲對象的邏輯分區。每個池被動態映射到 OSD。
圖 3. RADOS 位置分組
現在讓我們看看第一組後台進程 OSD，然後再看看監視器，最後看看屬於 CephFS 分布式文件系統的 Ceph 元數據伺服器。
回頁首
OSD
OSD 是訪問文件系統並向其中寫入數據的後台進程，它提供了通過集群網路訪問文件系統的能力。要讓集群正常運行，Ceph 開發人員建議使用 XFS（Silicon Graphics 日誌文件系統）或 B 樹文件系統 (Btrfs) 作為用於對象存儲的文件系統。也可使用第 4 代擴展文件系統 (ext4)，但它未提供 XFS 和 Btrfs 為 Ceph 提供的功能。
在本示例中，XFS 部署在所有存儲節點上。圖 4 演示了 Ceph OSD 如何與物理存儲交互。
⑨ 在openstack虛擬機和swift什麼關系
OpenStack其實有三個與存儲相關的組件，這三個組件被人熟知的程度和組件本身出現時間的早晚是相符的，按熟悉程度排列如下：Swift——提供對象存儲（ObjectStorage），在概念上類似於AmazonS3服務，不過swift具有很強的擴展性、冗餘和持久性，
⑩ 為什麼容器對 OpenStack 來說很重要
容器化不是一個革命性想法——容器技術已經存在很多年並且被大量應用程序所使用，但現在，容器幾乎不考慮系統體結構。
今天，相信很多人都聽說過Docker。一年多以來，很多公司都在評估Docker，也有很多公司想要使用Docker，但是很少公司真正把Docker應用在生產環境中。那這一年發生了什麼變化呢？
Docker讓容器化變得更加簡單。
在Docker出現之前，運行容器需要成群的駭客，需要對整個系統有深入的理解，還需要一定的勇氣。進程隔離或者網路堆棧是存在已久的一些技術，想想FreeBSD中的Jails或者其他類似的工具。但現在有了Docker，只需要使用（ docker）命令就能在幾秒鍾內讓一些東西運行起來。
即時滿足感不是Docker成功的唯一原因。大量免費應用程序的鏡像能夠吸引很多想要快速部署微服務以達到更大體系架構的人，但這些人不希望每次都重新部署虛擬化堆棧。
事實上，避免了虛擬化堆棧，相對於虛擬機幾分鍾的啟動時間，容器能夠在數秒之內啟動，這加快了整個基礎設施的部署。
當然，容器也不是完全沒有問題，例如安全性和其他一些不夠成熟技術帶來的問題。在關鍵系統上運行容器之前這些問題都需要被解決，但容器化對於所有人來說都是一種期待。
容器是什麼，容器的結構是什麼，它們和虛擬機的關系是什麼 很多人將容器比作虛擬化，但是容器並不能運行所有的東西。例如，你不能在一個容器中設置iptables的防火牆規則；因為容器共享了宿主機的內核，它們不像虛擬機一樣抽象化了硬體層。由於缺乏經驗，在你開始使用容器之前，將容器看成一種「簡單虛擬化」工具會給你的業務層埋下潛在的危險。
顯然我們需要花時間更好地理解容器，那他們是什麼？
容器是一種技術，這種技術讓開發者下載一些基礎鏡像，載入他們的應用程序，拆分成幾個組件，在持續集成系統上一一部署和測試，然後將這些組件注冊到倉庫中，讓系統工程師在現存的基礎設施上進行部署，然後發布給外界使用。
一個容器是操作系統層虛擬化特徵的一種抽象。通過開拓這些特徵，容器系統能夠將進程和網路隔離成類似於系統沙盒的東西，因此將一個應用程序載入一個容器就好像把它從操作系統上隔離出來一樣：在容器中的進程是獨立的；它們看到的是自己的文件系統，也能夠與外界進行通信等等。很多能夠跑在虛擬機里的應用程序也能夠跑在容器裡面。
容器和虛擬機的不同在於解耦了虛擬化堆棧；虛擬機將內核到用戶空間二進制文件與庫文件再到應用程序本身的一切都壓入了堆棧中進行隔離和獨立存放。而容器管理程序則讓容器使用相同的內核，共享相同的用戶空間二進制文件，共享其他的庫文件，然後讓應用程序直接運行在這些層上。
一個鏡像可以作為其他鏡像的Base。在Docker中，在一個鏡像之上構建新鏡像來獲得功能結果非常正常。你也許會在一個Ubuntu鏡像上添加Apache 2.4 web伺服器來構建一個基於Web的微服務，然後生成新的鏡像。
鏡像是容器運行的基礎，你需要在鏡像（building block）上啟動一個容器（runtime）。鏡像中包括了容器的應用程序，類似於一個快照但是還具備兩個額外的特徵。首先，它們在用戶空間文件系統之上進行構建，能夠進行堆疊和共享一些內容。其次，它們可移植。這就允許用戶在不同的系統上使用相同的鏡像，重新利用這些鏡像或者通過公共倉庫提供給其他用戶使用，並且能夠輕松地更新這些鏡像，然後存放到任何地方。
容器類型 最開始的時候是chroot。Chroot()是*NIX操作系統內核的一個系統調用，用來改變當前運行進程的root目錄。進程運行在chroot jail（環境名稱）上並不知道真實文件系統的root目錄，但知道user choice的表層root目錄。
這個函數能夠讓你隔離應用程序，讓進程將其他目錄視為根目錄，例如將 /mnt/root視為 /。這就意味著應用程序只能看到 /mnt/root上的文件，因此構建一個完整的環境來運行這個應用程序需要 /mnt/root目錄下構建軟體完整目錄樹的操作權。包括存放二進制文件的 /bin目錄，存放用戶空間程序與庫文件的 /usr目錄，存放配置的 /etc目錄等等。這些操作沒那麼容易，特別是對於更加復雜的應用程序來說，就更難了。
LXC是歷史上第一個試圖普及容器化技術的工具。和Linux容器生態系統的其他工具一起，LXC成為了容器化系統中被廣泛採用的工具。它完成了一套系統API讓Linux內核的容器特徵能夠被用戶層使用：在不脫離Linux標准下通過共享內核，LXC在chroots和虛擬機之間構建了一個體系結構。
Docker Docker是最具有吸引力的一種容器技術，它易於理解，可快速啟動，運行方式簡單，同時帶來了容器編排工具的一個巨大生態系統。
從工程角度，Docker通過API實現，它有自己的服務端（daemon），命令行客戶端以及從注冊中心到精美UI界面等大量可以使用的工具。
Docker的強大在於之前提到的chroot、進程分組、進程隔離等功能都可以通過它的一些命令來實現。在其他容器化技術中開發人員或者管理人員需要頻繁手動操作的一些事情，例如拉取補丁、工具與部署等，在Docker中已經不在需要，因為所有的操作都封裝在了命令行客戶端工具 docker中。
客戶端和REST API都是與Docker服務端進行交互，它是可以遠程訪問的一個標准可接入守護進程，用來接收和處理所有的請求。這個守護進程負責在Docker宿主機之上操控鏡像和容器，並已經通過IANA官方確認，將埠綁定到tcp/2375和tcp/2376。
Docker最初基於LXC，但現在放棄了LXC，而使用Libcontainer。Libcontainer通過GO完全重寫了用來抽象Linux內核虛擬化機制的基礎庫和API。
Open Container Initiative的細節 隨著Docker的成功，引發了更多類似產品的出現：CoreOS的Rkt、亞馬遜的容器服務（Amazon Container Service）、Apcera的Kurma等等。這種分化發展不由讓人擔心容器技術領域的分裂，好在通過今年在舊金山舉辦的DockerCon15，這些組織已經開始共同努力，期望為容器創建統一的格式。這就是 Open Container Initiative的由來，它基於Linux基金會，致力於為容器鏡像和容器的運行制定標准化。通過Open Container規定格式創建的容器可以在不同的生態環境中共存。Open Container Initiative的成員包括了所有的容器參與者，例如亞馬遜（Amazon）、CoreOS、谷歌、Oracle等等，當然也包括Docker。
Open Container的規格說明書（github地址為 https://github.com/opencontainers/specs）還在制定過程中，鼓勵所有的組織或者個人都可以參與其中。到目前為止依據不同平台和內容、工業級別交付流程以及自動化最小需求，規格說明書已經定義了一些容器的統一介面和標准。支持Open Container的所有企業將完全依賴這些規格說明書來製作容器。
同時，開發RunC運行庫（github地址為 https://github.com/opencontainers/runc）也是為了給各種容器提供統一運行庫命令行工具的頂級封裝器（而不是使用專有的命令，例如Docker的 docker或者Rocket的 rkt）。
微服務 隨著雲計算的不斷發展該利用容器做什麼？在雲計算中我們能看到的的微服務的不斷發展。
在雲上，整體的應用程序開發已經是過去的事情了，新的範例稱為微服務體系結構。利用微服務，龐大的應用程序可以根據其諸多的功能進行解耦，分成多個微小且只有單一目的的服務，這些服務之間通過規定的介面進行通信，例如API。微服務被稱為雲計算中的樂高積木玩具。
在許多方面，容器都是實現微服務的一種傑出的技術：每一個容器化的微服務具有唯一的角色（資料庫、隊列、web伺服器），然後使用容器編排工具（在許多容器開發生態系統中是非常有用的）使所有的容器相互通信來組裝成整個應用程序。
上述方式有很多好處：可組合性、更快的工作流、功能的分離、可維護性和可升級性。進一步來講，對微服務框架進行擴容變得更加容易。在不影響系統其他功能的前提下，微服務能夠更加快速、更加容易地置換到更加高效的對等服務上，或者是當遇到問題時進行回滾處理。多種不同的技術都可以用來分離微服務，不同的團隊可以根據自身手頭上的任務來選擇更加合適的技術。
一些大公司，像Amazon或者Netflix，在生產環境中已經有了一些基於微服務的應用程序。
因此，我們所具備的是藉助容器技術能夠在雲環境上實現一種完美的程序設計範式，即微服務。
總結 對於軟體程序和依賴關系來說，容器是一種輕量的可移植的工具。這么說看起來有些繁瑣，但是容器真的改變了我們開發、部署和運行軟體程序的方式。