OpenStack是一個開源云計算管理平臺(確切來說是平臺框架)，現在很多廠商都基于OpenStack來結合相應Linux操作系統(CentOS、SUSE或Ubuntu等)來做公有云或私有云的云計算操作系統，比如華為、海云捷訊、UnitedStack、九州云等;當然每個廠商做法不同，比如Redhat的RDO完全開源，而且其云計算管理平臺的投入不僅僅是OpenStack。

由于OpenStack各個組件成熟度不一、底層Driver技術完善度不同，特別是Neutron，所以任何基于OpenStack玩云計算的廠家，都面臨一個問題：在日新月異的OpenStack開源代碼下，如何發布自己穩定的發行版并通過快速迭代跟上社區的步伐?

軟件開源碼和硬件開架構確實是最近技術界的趨勢，非常有利于技術共享和積累傳播，也為初學者提供了大量的細節資料，從而在開源基礎上構建生態圈來打破私有封閉性;但是大家不得不面臨的一個問題是，開源的實現相當一部分源碼考慮的是可行性及Demo級別的實現(當然也有一些實現非常優良)，達到商用級別通常需要內部加固和優化;即對于OpenStack而言都需要在保持OpenStack開放性的同時，不斷增強底層實現;那么就會面臨發行版和開源社區版本有很多不一致的地方，這個是否破壞了OpenStack的開放性哪?

首先客戶為什么需要云計算平臺有開放的架構哪?和SDN非常類似，因為云平臺涉及存儲、計算和網絡等等硬件設備的選型及采購，每一家云平臺的搭建過程廠商都是一個集成商角色，無論其自己是否能對云平臺所需的硬件設備和軟件工具來自產滿足，云平臺的開放性便于其不斷的特性疊加或升級;而當云平臺廠商需要購買大量硬件設備或軟件工具搭建云平臺時，不希望這些被一家提供商控制，而是在整體架構解耦的條件下將每個模塊拆分而分別多個提供商競標，這樣來降低總體成本和對特定廠商的依賴性。

那么這里還要區分下開放性是什么，開放性應是通過標準的API和文檔說明等手段，讓周邊生態圈能很容易構建，這個和開源有很大的不同;這點和網絡中使用網絡協議來使得不同廠商的交換機能夠互通和兼容是一致的(舉個例子，現在Neutron中用Vxlan做隔離時，Vxlan協議RFC中UDP的DPort標準值使用4789，但是并不是強制的而是可以配置選擇的，Neutron中通過 vxlan_udp_port配置項來生效，對OpenvSwitch控制)，SDN的特點之一也是有開發的北向接口和標準的南向接口，說白了也是要SDN及其網元有開放性。換句話說，OpenStack只是通過Plugin/Driver的方式提供了一個整體解耦的架構，但是其底層實現需要各家廠商自己選擇、優化甚至重新實現，這個也是OpenStack提供這種架構的初衷，以及得到這么多廠商和開源愛好者支持的很大一個原因，雖然開源社區也提供了基礎的實現，不過目的多是體現思想和趨勢方面的東西。

所以OpenStack開放性個人認為若能夠保證這種解耦的框架和一致的北向接口，對于OpenStack的開放性即便是有了保證，而無需和社區實現保持一致;實話而言，任何一家廠商都沒有辦法與社區發布的相應版本實現保持完全一致，這個也是沒有必要的。而廠商對OpenStack的優化有著非常大的意義，下面通過優化手段來具體談下相應作用的理解：

第一，OpenStack運行穩定的基礎是服務器操作系統，所以必須有一種穩定的操作系統來對OpenStack的運行提供保障;任何一家OpenStack廠商都要選擇一種操作系統來集成，操作系統現在基本都是某種Linux發布版，而優化則主要是計算節點針對Hypervisor層、網絡節點主要針對協議棧等對Linux Kernel進行選型，并不斷升級其Patch或新特性來加固;

第二，OpenStack整體框架的優化是其可用性方面的基礎，主要包括OpenStack管理面和控制面的性能和高可用方面的優化，這方面為OpenStack的商用穩定性及大規?？蓴U展等提供了必要性;

第三，使用穩定且成熟的Plugin和底層Driver實現，為OpenStack的底層提供了有效的集成，尤其是Neutron的現狀來看，必須要進行大量的優化和加固才能商用，包括Iptables的性能、L3 router的性能及高可用、OpenvSwitch等，例如Dvr等特性很多廠商都還沒有使用;必須為Neutron提供可商用的底層Driver實現，才能Hold住網絡的高可用和高性能，包括集成SDN架構、Driver用硬件網元實現相應的網絡功能等;

第四，第三方工具或平臺的集成，一方面包括底層實現各種特性的輔助工具比如多種虛擬化資源池融合、統計和計費平臺集成等，網絡方面還包括Haproxy、防DDos攻擊設備、安全防護等方面集成等，都為OpenStack的商用保駕護航;而對客戶而言(尤其是私有云)則是流程IT的集成，包括其已有的審批流程和工單系統等;

第五，OpenStack商用平臺必須有不斷的合并Patch和新特性的能力，來保持OpenStack的安全性和穩定性，并不斷滿足用戶的新需求;這點和Linux的發行版類似，Linux的內核廠商除了對其內核編譯優化外，也提供不斷的補丁升級等維護服務;

第六，OpenStack的運行必須與傳統DC內的監控及運維向結合，才能讓云平臺運維人員對OpenStack良好的運維能力;OpenStack的復雜性對傳統的運維人員來說是個壓力，對運維人員的技能有較高的要求，如何將已有的工具盡快結合或開發新的適用工具，是運維人員對OpenStack云平臺運維需要回答的問題;從Devops角度講，也是運維人員將已有云平臺工具快速復制部署，為實現運算穩定運營提供了重要保障;

第七，OpenStack的部署升級需要通過專業的工具來保證其平滑性，是上線業務對云平臺的訴求;現在公有云或私有云的規模越來越大，部署時不通過專業的工具，非常容易出錯，以及后續的升級也是很困難;

所以從上面七點(為什么是七點，因為集齊七龍珠有神龍)意義上說，OpenStack 保持標準API北向(可以適當擴展補充但需兼容)、穩定的架構框架和持續集成能力，是對OpenStack商用落地很多客戶提出的要求。

而那些非開源的云計算操作平臺或云計算操作系統(典型的有UCloud/AWS/阿里云等，其他國內知名云計算廠商的公有云和私有云大多是基于OpenStack)，如果是北向API等能夠保持足夠開放性，也并不會對其生態圈構建有太大的技術妨礙;只是當大家都關注OpenStack并為其做嫁衣時，會沒有精力再投入到其他云平臺上而已。

【本文來源：KVM虛擬化實踐微信公眾號】