最近這大半年澳骤，博主花了不少精力在SDN與openstack neutron的集成上阀圾×⒈叮快到年底了灭红，有必要稍微總結(jié)一下這大半年來(lái)究竟都解決了些什么問(wèn)題。拋磚引玉口注，希望同行們一起探討变擒。

首先聊一個(gè)話題：各個(gè)SDN廠家都是做控制器和交換機(jī)操作系統(tǒng)的，干嘛去淌openstack的渾水疆导？這個(gè)問(wèn)題的確小困擾過(guò)博主一段時(shí)間赁项。因?yàn)榫驮诎肽甓嗲案瘐铮┲髅媾R過(guò)一個(gè)選擇：是花時(shí)間在SDN控制器和交換機(jī)上做一個(gè)大feature澈段，還是把neutron和我們的SDN產(chǎn)品集成起來(lái)悠菜？博主最終選擇了后者。想借這篇文章分享一下博主的想法败富。

openstack的強(qiáng)勁發(fā)展勢(shì)頭第一次教育了整個(gè)市場(chǎng)多租戶數(shù)據(jù)中心長(zhǎng)什么樣子悔醋，也第一次比較徹底的顛覆了傳統(tǒng)數(shù)據(jù)中心的網(wǎng)絡(luò)設(shè)計(jì)和運(yùn)維方式。SDN在這里找到了迄今為止最好的切入點(diǎn)：市場(chǎng)真實(shí)并且巨大兽叮。從這個(gè)意義上說(shuō)芬骄，只有openstack繼續(xù)這樣強(qiáng)勁的發(fā)展勢(shì)頭，SDN廠家才會(huì)有更多的機(jī)會(huì)去占領(lǐng)市場(chǎng)鹦聪。絕大多數(shù)客戶不會(huì)因?yàn)镾DN是一種更優(yōu)秀的技術(shù)而去采購(gòu)SDN解決方案账阻，反而是因?yàn)樗麄冋J(rèn)可openstack的技術(shù)和商業(yè)模式而不得不去采購(gòu)SDN解決方案。面對(duì)使用openstack的客戶泽本，初創(chuàng)的SDN廠家和各個(gè)傳統(tǒng)交換機(jī)大廠第一次有了平等競(jìng)爭(zhēng)的機(jī)會(huì)淘太。從這個(gè)意義上來(lái)說(shuō)，如果哪個(gè)SDN廠家還沒(méi)有涉足neutron规丽，那么就已經(jīng)犯了一個(gè)重大的戰(zhàn)略錯(cuò)誤蒲牧。

從戰(zhàn)術(shù)層面上來(lái)說(shuō)，雖然neutron已經(jīng)有了飛速的發(fā)展赌莺，但還有幾個(gè)大問(wèn)題是reference implementation在現(xiàn)有的框架下很難解決漂亮的：比如如何管理過(guò)多的agent以及它們的HA冰抢，如何scale全相連的隧道，如何支持bare metal服務(wù)器以及bond艘狭，如何支持動(dòng)態(tài)路由協(xié)議等等挎扰。這些問(wèn)題不是說(shuō)neutron upstream沒(méi)有解決方案，而是如果沒(méi)有對(duì)物理交換機(jī)的控制巢音，針對(duì)這些問(wèn)題的解決方案就會(huì)有各種各樣的局限鼓鲁。而SDN廠家卻有機(jī)會(huì)利用ml2 plugin和service plugin把這些問(wèn)題從根本上解決掉。博主會(huì)專門寫文章討論為什么SDN廠商能夠更好的解決以上這些問(wèn)題港谊，這篇先聊一聊SDN和neutron集成的三個(gè)大問(wèn)題骇吭。

1. Testing Matrix & CI

openstack和SDN的集成是一件很復(fù)雜的工程。需要砸大量的資源歧寺。首先是巨大的testing matrix燥狰，它有三個(gè)維度。第一個(gè)維度：openstack每半年一個(gè)release斜筐，而且還會(huì)cherry pick不少bug fix到上一個(gè)版本龙致。第二個(gè)維度：操作系統(tǒng)至少要支持三到四家：ubuntu, redhat, centos, fedora。第三個(gè)維度：SDN解決方案的各個(gè)release顷链。這三個(gè)維度相乘便是SDN和openstack集成的Testing Matrix目代。雖然各個(gè)廠家都會(huì)在這個(gè)三維坐標(biāo)系里進(jìn)行一些剪枝，但工作量仍然巨大。

解決以上問(wèn)題的唯一辦法就是搭建CI進(jìn)行測(cè)試的自動(dòng)化榛了。這個(gè)CI和一般應(yīng)用的CI有兩點(diǎn)不同在讶。第一，它有兩個(gè)moving targets: neutron upstream以及SDN solution upstream霜大。來(lái)自任何一方的代碼變化都要引起CI進(jìn)行一次測(cè)試构哺。第二，在控制平面和數(shù)據(jù)平面都要進(jìn)行測(cè)試战坤。在控制平面曙强，來(lái)自neutron的任何一個(gè)配置變化，SDN控制器都要作出正確的響應(yīng)途茫。在數(shù)據(jù)平面需要跑smoke test碟嘴，比如在不同的compute nodes上起多臺(tái)虛擬機(jī)，配置floating ip囊卜，做full mesh ping娜扇。

這些都需要專人負(fù)責(zé)，偷不得懶边败。否則我們?nèi)绾螒?yīng)對(duì)客戶這樣的問(wèn)題：我們能在ubuntu 14.04上裝openstack kilo跑在你們x.y.z版本的SDN解決方案上嗎袱衷？

2. Multiple Openstack Environments & One SDN controller

現(xiàn)有的SDN與openstack的集成方案大概都長(zhǎng)這個(gè)樣子：租戶在openstack上建立了一個(gè)network/router/vm，neutron plugin會(huì)向SDN控制器發(fā)送相應(yīng)的REST call笑窜，SDN控制器便會(huì)對(duì)物理交換機(jī)或者虛擬交換機(jī)進(jìn)行流表下發(fā)或者配置更改致燥。這個(gè)應(yīng)用場(chǎng)景里面有一個(gè)隱藏的需求：一個(gè)SDN解決方案需要同時(shí)支持多個(gè)openstack環(huán)境。比如客戶用一個(gè)SDN控制器管理了幾個(gè)機(jī)架排截，在上面跑了多個(gè)openstack環(huán)境嫌蚤，那么這個(gè)SDN控制器是需要對(duì)這多個(gè)openstack環(huán)境進(jìn)行區(qū)分的：環(huán)境1上的租戶老王和環(huán)境二上的租戶老王不能影響彼此在SDN控制器上做出的配置，即便他們?cè)诠蚕硗瑯拥奈锢砭W(wǎng)絡(luò)資源并且都叫老王断傲。

3. Consistency

openstack的每一個(gè)配置都會(huì)存在openstack的數(shù)據(jù)庫(kù)里脱吱，通過(guò)REST發(fā)給SDN控制器每一個(gè)配置也會(huì)被保存在SDN控制器的數(shù)據(jù)庫(kù)里。當(dāng)由于某種的原因认罩，兩個(gè)數(shù)據(jù)庫(kù)不一致怎么辦箱蝠？這個(gè)時(shí)候，一定要以openstack數(shù)據(jù)庫(kù)的信息為準(zhǔn)垦垂，更新SDN控制器的配置宦搬，因?yàn)閛penstack數(shù)據(jù)庫(kù)中的信息才是租戶真正希望的配置。這個(gè)道理很簡(jiǎn)單劫拗，但實(shí)現(xiàn)起來(lái)卻有不少挑戰(zhàn)间校。比如，如何檢測(cè)到兩個(gè)schema完全不同的數(shù)據(jù)庫(kù)所存儲(chǔ)的信息不一致页慷？用hash是最直接的辦法憔足。但問(wèn)題也隨之而來(lái)：hash計(jì)算昂貴胁附，由誰(shuí)來(lái)做？多頻繁滓彰？如果監(jiān)測(cè)到不一致控妻，如何能夠快速的定位并且僅僅更新不一致的地方？

一個(gè)成熟的SDN與openstack的集成方案找蜜，一定需要把以上這三個(gè)問(wèn)題解決好饼暑，否則希望借助openstack的東風(fēng)讓SDN落地會(huì)很困難稳析。