最近這大半年，博主花了不少精力在SDN與OpenStack neutron的集成上?？斓侥甑琢耍斜匾晕⒖偨Y一下這大半年來究竟都解決了些什么問題。拋磚引玉，希望同行們一起探討。
首先聊一個話題：各個SDN廠家都是做控制器和交換機操作系統的，干嘛去淌OpenStack的渾水?這個問題的確小困擾過博主一段時間。因為就在半年多前，博主面臨過一個選擇：是花時間在SDN控制器和交換機上做一個大feature，還是把neutron和我們的SDN產品集成起來?博主最終選擇了后者。想借這篇文章分享一下博主的想法。
OpenStack的強勁發展勢頭第一次教育了整個市場多租戶數據中心長什么樣子，也第一次比較徹底的顛覆了傳統數據中心的網絡設計和運維方式。SDN在這里找到了迄今為止最好的切入點：市場真實并且巨大。從這個意義上說，只有OpenStack繼續這樣強勁的發展勢頭，SDN廠家才會有更多的機會去占領市場。絕大多數客戶不會因為SDN是一種更優秀的技術而去采購SDN解決方案，反而是因為他們認可OpenStack的技術和商業模式而不得不去采購SDN解決方案。面對使用OpenStack的客戶，初創的SDN廠家和各個傳統交換機大廠第一次有了平等競爭的機會。從這個意義上來說，如果哪個SDN廠家還沒有涉足neutron，那么就已經犯了一個重大的戰略錯誤。
從戰術層面上來說，雖然neutron已經有了飛速的發展，但還有幾個大問題是reference implementation在現有的框架下很難解決漂亮的：比如如何管理過多的agent以及它們的HA，如何scale全相連的隧道，如何支持bare metal服務器以及bond，如何支持動態路由協議等等。這些問題不是說neutron upstream沒有解決方案，而是如果沒有對物理交換機的控制，針對這些問題的解決方案就會有各種各樣的局限。而SDN廠家卻有機會利用ml2 plugin和service plugin把這些問題從根本上解決掉。博主會專門寫文章討論為什么SDN廠商能夠更好的解決以上這些問題，這篇先聊一聊SDN和neutron集成的三個大問題。
1. Testing Matrix & CI
OpenStack和SDN的集成是一件很復雜的工程。需要砸大量的資源。首先是巨大的testing matrix，它有三個維度。第一個維度：OpenStack每半年一個release，而且還會cherry pick不少bug fix到上一個版本。第二個維度：操作系統至少要支持三到四家：ubuntu, redhat, centos, fedora。第三個維度：SDN解決方案的各個release。這三個維度相乘便是SDN和OpenStack集成的Testing Matrix。雖然各個廠家都會在這個三維坐標系里進行一些剪枝，但工作量仍然巨大。
解決以上問題的唯一辦法就是搭建CI進行測試的自動化。這個CI和一般應用的CI有兩點不同。第一，它有兩個moving targets: neutron upstream以及SDN solution upstream。來自任何一方的代碼變化都要引起CI進行一次測試。第二，在控制平面和數據平面都要進行測試。在控制平面，來自neutron的任何一個配置變化，SDN控制器都要作出正確的響應。在數據平面需要跑smoke test，比如在不同的compute nodes上起多臺虛擬機，配置floating ip，做full mesh ping。
這些都需要專人負責，偷不得懶。否則我們如何應對客戶這樣的問題：我們能在ubuntu 14.04上裝OpenStack kilo跑在你們x.y.z版本的SDN解決方案上嗎?
2. Multiple OpenStack Environments & One SDN controller
現有的SDN與OpenStack的集成方案大概都長這個樣子：租戶在OpenStack上建立了一個network/router/vm，neutron plugin會向SDN控制器發送相應的REST call，SDN控制器便會對物理交換機或者虛擬交換機進行流表下發或者配置更改。這個應用場景里面有一個隱藏的需求：一個SDN解決方案需要同時支持多個OpenStack環境。比如客戶用一個SDN控制器管理了幾個機架，在上面跑了多個OpenStack環境，那么這個SDN控制器是需要對這多個OpenStack環境進行區分的：環境1上的租戶老王和環境二上的租戶老王不能影響彼此在SDN控制器上做出的配置，即便他們在共享同樣的物理網絡資源并且都叫老王。
3. Consistency
OpenStack的每一個配置都會存在OpenStack的數據庫里，通過REST發給SDN控制器每一個配置也會被保存在SDN控制器的數據庫里。當由于某種的原因，兩個數據庫不一致怎么辦?這個時候，一定要以OpenStack數據庫的信息為準，更新SDN控制器的配置，因為OpenStack數據庫中的信息才是租戶真正希望的配置。這個道理很簡單，但實現起來卻有不少挑戰。比如，如何檢測到兩個schema完全不同的數據庫所存儲的信息不一致?用hash是最直接的辦法。但問題也隨之而來：hash計算昂貴，由誰來做?多頻繁?如果監測到不一致，如何能夠快速的定位并且僅僅更新不一致的地方?
一個成熟的SDN與OpenStack的集成方案，一定需要把以上這三個問題解決好，否則希望借助OpenStack的東風讓SDN落地會很困難。
本文系BigSwitch工程師吳鑫授權發布，如需轉載請注明出處和鏈接
京公網安備 11010502049343號