2016 CCS企業云計算高峰論壇（ccs.d1net.com）于6月15日在北京國際會議中心盛大舉行，這是國內面向政企客戶的最重要的一個云計算會展。CCS企業云計算高峰論壇上，云與大型企業的兼容性將成為主要議題。
以下是現場速遞。（聲明：本稿件來源為現場速記，可能有筆誤和別字，僅供參考）
主持人：感謝寧總的精彩分享。開源、開放、共享是IT產業發展的趨勢，OpenStack正是以這樣的核心理念讓更多的企業，尤其是用戶通過軟件定義的方式參與到下一代數據中心的建設當中去。接下來有請華為云計算網絡首席架構師申思講講“基于OpenStack公有云網絡云平臺的實踐”，掌聲有請。
華為 云計算網絡首席架構師 申思
申思：各位領導，各位同事大家好。我今天講三部分，第一需求和驅動力。第二，對OpenStack級聯技術的介紹。第三，我們在公有云和企業云實踐案例的分享。
首先，我們識別的云計算的一個精髓，就是融合共享，對資源池的融合共享，對物理資源，包括計算資源，存儲資源，網絡資源的一種抽象，然后給用戶提供一個敏捷、開放的，迅速能夠集中上線它的業務的這樣一種平臺能力。解決多個異構資源池的問題。
OpenStack實際上現在由于它自身的開放性、靈活性、兼容，以及多個廠商對他們的支持，已經成為云計算管理平臺的一個標準，華為今年成為OpenStack的國內首家黃金董事席職位。我們提供OpenStack為企業用戶或者運營商用戶搭建公有云、私有云的時候其中有這么幾個問題。
重點的幾個問。第一，跨DC融合的問題，但是對于跨DC的實踐，基于傳統的OpenStack能力很難做到大規模擴展，因為單做OpenStack實際的管理規模，站點規模可能也就是500臺左右，不會超過1000臺。不同的DC管理的時候，傳統的方式就是通過協同層，通過搭一個協同層，拉通資源整體的分配，拉通資源，特別是網絡層面的互通。這種方式帶來的一個問題，它破壞了OpenStack原生的，最核心的數據模型和開放生態的API的能力，變成相對來說廠商綁定的一個私有云方案。
另外一個思路，是不是可以通過集成之后仍然提供標準的OpenStack原生的能力，保持OpenStack開源的生態。這個是客戶的一個關鍵的訴求。同時在一個站點內，也有多種不同類型的資源池，像vMware，特別是資源池規模不斷增長，不斷擴展的時候，傳統的以主機方式很難滿足這個問題，同時網絡層面客戶訴求也是非常多，客戶有跨DC的訴求，支撐一些容災備份這樣的能力，也有三層的訴求，通過集中式的節點。這么多的訴求用傳統的OpenStack解決存在這么幾個比較大的問題。首先，單個OpenStack的管理規模是有限的，第二，OpenStack在服務器和控制節點之間跑的是私有的RPC協議，這個協議很難管理，很難單獨運維，單獨控制。其次，像升級故障定位，故障率很難隔離到一個具體的域，保證發生故障的時候其他業務不受影響。這個問題促進我們怎么解決這些訴求，因為華為在OpenStack上非常清晰的就是源于開源，基于OpenStack解決客戶的訴求，跟廠商合作，跟社區合作，同時回饋社區。
所以，我們考慮OpenStack的級聯技術，這個技術從最早的思考，到它實際落地以及商用也經歷了一個過程。我們基于現在正在做的級聯商用的案例，正在不斷把補充的代碼貢獻到社區。
那么，我們最初的考慮是什么?既然OpenStack是用戶所關注的一個重點，那么我是不是能夠用OpenStack進行多站點，多OpenStack，多資源池的編排，這是最初的一個想法。這樣解決的問題就是保證OpenStack的一個獨立性和API，同時多站點的融合，成為開源OpenStack的編排能力，可以防止被廠商鎖定。
那么，這個想法非常好，是不是可行，我們考慮是不是可以把OpenStack作為一個編排的節點。經過驗證和分析，我們發現這個方案是完全可行的，因為OpenStack本身就是一個驅動插件，在座可能有對OpenStack比較熟悉的，以Nova為例，調度到計算機點之通過計算機的Driver實現對KVM的虛擬機的生命周期感覺。相對Vmware來說，也一樣是通過Driver方式實現，Driver既然可以管理這個節點，是不是可以管理OpenStack，這是我們最初的想法，而且不會修改OpenStack原生主體，只是通過外圍的插件進行對接。對于網絡也是一樣的，OpenStack二層要實現OVS上的掃描插拔。這些接口也是可以通過對接下層的OpenStack實現網絡業務的下發。
經過驗證我們有了OpenStack的級聯方案，還有一部分加固能力我們逐漸往社區貢獻。整個加固分成兩層，第一層是上層編排層，是完整的OpenStack的服務，對底層所有的實踐客戶并不感知。在多個DC內通過實際的業務OpenStack實現對DC內的OpenStack的資源池的關聯，用級聯層的OpenStack，上層的OpenStack有一層插件層，這層插件層完全以插件的形式控制到社區，這個插件負責在兩層之間打通業務，并且把計算存儲網絡都打通，這樣用戶在上層的OpenStack發放業務的時候只要選擇在哪個OpenStack部署這個業務，整個計算存儲業務的下發都是自動的完成，利用OpenStack原生的這個能力。
這里面舉個例子，比較實際的一個例子，當用戶發放一個虛擬機的時候，通過上層的API調度，然后決定分布到哪個OpenStack。然后，OpenStack接觸到的也是同樣的API的接口，在下層主機這側進行調度，網絡、計算、虛擬機掛在那兒，網絡自動會同步。在兩個DC之間通過OpenStack流程原生的機制，通過級聯層做廣播，實現跨地區的虛擬機和虛擬機業務的互動。
總結一下OpenStack級聯的價值，首先是一個開源的編排層，沒有廠商綁定的問題，是標準的OpenStack。可以解決故障率隔離的問題，比如一個站點、業務出現故障，一個站點宕掉，其他站點的業務不受影響。其次，站點間故障隔離。同時，可以水平擴展，并且每個OpenStack都是可以獨立進行升級維護管理的，具備比較好的故障隔離性和獨立性。這個是我們的項目，主要解決單OpenStack本身的擴展性和容量的問題，通過分布式控制技術，通過DB的訂閱減少RPC量的本地緩存，這個也是比較受關注的項目，解決了原生的RPC的擴展性的問題。通過這個分布式控制技術，仍然是開源的項目，但是它可以解決單個OpenStack最大到一萬臺物理服務器的規模。
我們現在在華為企業云，以及跟國外的一些運營商，國內的運營商合作，大的公有云部分已經上線了，現在已經開始用基于OpenStack級聯這個架構進行整個業務的實現。我們現在通過OpenStack級聯這個技術，我們最多能夠支持的被級聯的站點是100個，目前是100個。每個站點可以有1000到10000臺虛擬機，我們理論上的規格在10萬臺物理機，支持一百萬的虛擬機。當然，我們現在正在朝這個方向做商用，規模大了之后，包括商用加固、運維管理的復雜性會變的非常高，這部分商用的加固其實難度比較高，所以我們也朝這個方向在努力，也希望大家可以和我們一起基于這個項目構筑一個大規模的企業云，或者私有云。
最后，是我們在公有云和企業云的一些實踐，簡單分享一下。我們現在在華為企業云，去年7月份上線，以及國外的像德國、西班牙，還有國內的一些運營商也已經有合作，開始大規模的上線公有云項目。我們用的架構是一套基于軟件的Overlay架構，這個跟華為傳統做設備，做盒子這種印象完全不同，完全是通過軟件實現的，解決我們對接入交換機，匯聚交換機完全是一個異構的，不需要華為提供設備，也一樣可以實現Overlay這種能力。同時對高級的服務，防火墻服務，VPN，也是通過軟件現的，整個架構是用X86搭起來的，沒有任何廠商鎖定的問題，所以這個對客戶來講是非常有價值的點，不管是國內還是國外的企業運營商客戶，他們非常認可純軟件實現的Overlay運算的這種能力。
我們在定義試圖的時候，一部分是租戶的視圖，一個是物理的視圖。物理視圖就是有多個物理的DC，DC內部劃分多個具體的逃路，物理的小隔離，這是整個資源視圖。
我們從邏輯架構上來講，有接口/業務層，提供商業的編排能力，業務編排下發能力，提供計費、單點認證，安全。然后有標準的自動化編排層，基于OpenStack級聯層的編排能力，提供OpenStack標準的API。下面就是IaaS層，通過不同的OpenStack實現實際業務的管理和下發。虛擬化層，有開源的KVM站的支持，也可以針對Vmware進行。基礎設施完全是X86服務器實現的，沒有用任何私有的綁定的硬件。整個全局視圖是這樣的結構，跨地區實現業務的高可能性。跨DC實現整個網絡業務的存儲的拉動。整個資源可以是零擴展，擴展任何一個DC的時候，只需要在這個DC內進行部署，不需要對其他業務有任何影響。
我們在跨DC的VxLAN Overlay互通，具體的虛擬機可以調度到不同的DC內部，虛擬機通過底層的Overlay技術三層互通。四到七的服務能力包括面向虛擬的負載均衡服務，虛擬的路由服務，防火墻的服務這些都是通過軟件實現的。通過這個集群跨DC實現業務的LB，我們Web服務器和企業里的服務器，可以在不同的地區內部署，保障高可能性。用戶訪問的時候調度策略也是可以配，這個提供了一個跨DC的負載均衡服務。這是兩個比較典型的一個使用案例。我的分享就到這兒，謝謝大家!
京公網安備 11010502049343號