有些朋友一看這個(gè)問題可能會(huì)有些不知所云，如果SDN控制器不管物理交換機(jī)，那么它管什么呢?答案是只管理虛擬交換機(jī)。這里，博主需要插入一個(gè)簡(jiǎn)短的科普。自從云計(jì)算盛行以來，主機(jī)虛擬化技術(shù)已經(jīng)深入人心。任何一臺(tái)物理主機(jī)上都可以同時(shí)運(yùn)行多個(gè)虛擬機(jī)(docker是另外一個(gè)話題)。那么問題來了，一臺(tái)虛擬機(jī)的網(wǎng)絡(luò)接口是如何接入到物理網(wǎng)絡(luò)的呢?最初，人們會(huì)在物理主機(jī)上跑一個(gè)軟件hub，所有虛擬機(jī)的網(wǎng)口都會(huì)接入到這個(gè)軟件hub。這個(gè)hub會(huì)有一些端口和物理主機(jī)的網(wǎng)卡相連。隨著主機(jī)虛擬化技術(shù)的不斷完善，這個(gè)軟件hub逐漸被軟件交換機(jī)(software switch)所取代，其中***代表性的是open virtual switch(OVS)。雖然叫交換機(jī)，但其實(shí)它也可以做三層路由，訪問控制(ACL)甚至是一些動(dòng)態(tài)的路由協(xié)議。在SDN和OpenFlow的概念最初被提出時(shí)，它的原型系統(tǒng)就是由一個(gè)SDN控制器集中控制多個(gè)OVS，在OVS之間建立全互聯(lián)的隧道(full mesh tunnel)。在這樣的架構(gòu)下，SDN控制器和OVS都是普通的軟件，不需要任何特殊的硬件支持。于是SDN控制器和OVS都得到了快速的迭代。這種SDN架構(gòu)也成就了Nicira。時(shí)至今日，Nicira的SDN解決方案仍然是用控制器控制所有的OVS。物理網(wǎng)絡(luò)仍然采用傳統(tǒng)的二層三層協(xié)議。業(yè)界往往稱Nicira的SDN架構(gòu)為overlay方案。這種方案***的好處有兩點(diǎn)：首先，所有的OVS流表都裝在服務(wù)器內(nèi)存里，理論上可以支持巨大的流表。第二，overlay方案根本不控制物理交換機(jī)，部署靈活，就如同在服務(wù)器上裝一個(gè)軟件，單憑這一點(diǎn)就可以快速贏得客戶。

 [[140429]]

用SDN控制器管理物理交換機(jī)最早出現(xiàn)在2008年的Sigcomm上。與overlay方案對(duì)應(yīng)， 博主把這種方案成為underlay。由于絕大多數(shù)硬件交換芯片是為二層和三層交換設(shè)計(jì)的，而OpenFlow的轉(zhuǎn)發(fā)模型卻是wildcard match + action，導(dǎo)致在很長(zhǎng)的一段時(shí)間以內(nèi)人們只能把OpenFlow消息轉(zhuǎn)化為TCAM表項(xiàng)。即便到了今天，最成熟的商用硬件交換芯片也僅僅支持10^3數(shù)量級(jí)的TCAM表項(xiàng)，這成為了使用SDN控制器控制物理交換機(jī)***的瓶頸。圍繞這個(gè)瓶頸，世界各地的專家們前赴后繼。目前主要分為兩個(gè)陣營(yíng)。Nick McKeown教授作為SDN的發(fā)起人之一，主張徹底重新設(shè)計(jì)硬件交換芯片，目的是讓硬件交換芯片支持多級(jí)流表，每一級(jí)流表都支持match + action。另外一個(gè)陣營(yíng)則以Rob Sherwood為代表，主張挖掘現(xiàn)有硬件交換芯片的潛力，充分的排列組合OpenFlow協(xié)議中的match和action，盡量把match+action在二層和三層的流表中實(shí)現(xiàn)。TCAM流表僅僅用來應(yīng)對(duì)一些復(fù)雜ACL。無獨(dú)有偶，盛科張衛(wèi)峰總的主張也和這個(gè)觀點(diǎn)不謀而合?？磥韺W(xué)院派的人士充滿了理想主義情懷，工業(yè)界人士?jī)A向于漸進(jìn)式的創(chuàng)新。

科普完畢，業(yè)界有人在采用overlay的方案，也有人在嘗試underlay的方案。那么那個(gè)選擇更合理呢?在這里希望大家做個(gè)深呼吸，稍微深入的思考一下這個(gè)問題。博主的教訓(xùn)是無論選擇哪個(gè)技術(shù)流派，你都為自己挖下了一個(gè)巨大的坑，這個(gè)坑你逃不過。在某一個(gè)階段，你一定會(huì)或多或少的后悔：如果當(dāng)初做另外一個(gè)選擇就好了。我們不妨先看看業(yè)界大佬的觀點(diǎn)是啥。你會(huì)突然發(fā)現(xiàn)：大佬們?cè)瓉硪苍谂淖约和诘目永锱莱鰜戆　?/p>

Scott Shenker, 這位大神就沒必要介紹了，作為著作被引用最多的計(jì)算機(jī)科學(xué)家，作為SDN的發(fā)起人之一，ONF的發(fā)起人之一，他的觀點(diǎn)犀利且富有前瞻性。關(guān)于SDN他有兩次廣為流傳演講，分別在2011年(The Future of Networking, and the Past of Protocols)和2013年(Software-Defined Networking at the Crossroads)。對(duì)比這兩次演講，大家不難發(fā)現(xiàn)對(duì)于用SDN控制器管理整個(gè)物理網(wǎng)絡(luò)，Scott從堅(jiān)定的支持派變成了反對(duì)派。他轉(zhuǎn)變的主要原因其實(shí)只有一點(diǎn)：不計(jì)其數(shù)的網(wǎng)絡(luò)服務(wù)需要靈活部署，不計(jì)其數(shù)的網(wǎng)絡(luò)策略需要快速準(zhǔn)確的執(zhí)行，所有這些從網(wǎng)絡(luò)邊緣實(shí)施會(huì)更加容易高效，邊緣以內(nèi)的物理網(wǎng)絡(luò)僅僅需要扮演一個(gè)水管的角色，是否用SDN集中控制不重要。在他描述的世界中，SDN控制器控制OVS給網(wǎng)絡(luò)報(bào)文打上不同的tag，物理網(wǎng)絡(luò)只需要根據(jù)tag轉(zhuǎn)發(fā)就好了。

在另一個(gè)方面，雖然Nicira是overlay SDN解決方案的旗幟性公司，但Nicira也逐步開始管理物理交換機(jī)了，至少是開始管理top-of-rack(ToR)了。這里我們不妨看一下Nicira大神Bruce Davie的兩篇博客。在2011年，用open virtual switch打隧道棒極了，部署靈活，服務(wù)多樣，各種流表***大，性能也號(hào)稱沒有明顯的瓶頸[link]。但是在2013年,Bruce忽然話風(fēng)一轉(zhuǎn)，開始把隧道放在了ToR上，他把原因主要?dú)w結(jié)于支持bare metal服務(wù)器[link]。所謂bare metal服務(wù)器是指那些沒有采用虛擬化技術(shù)的主機(jī)，在這些主機(jī)上，沒有OVS，overlay方案自然也無計(jì)可施。為了在這種環(huán)境中部署overlay SDN解決方案，隧道被很自然的打在了ToR上。在Bruce 2013年那篇博客的結(jié)尾，他這樣總結(jié)了兩種方案的取舍“Our expectation is that software gateways will provide the greatest flexibility, feature-richness, and speed of evolution. Hardware VTEPs will be the preferred choice for deployments requiring greater total throughput and density”。博主我真是太佩服這些大神的說話技巧了。如果我們仔細(xì)揣摩它的后半句，不難發(fā)現(xiàn)，Bruce在暗指用OVS打隧道可能會(huì)成為吞吐量的瓶頸。兄弟這里沒有數(shù)據(jù)，于是斗膽引用盛科張衛(wèi)峰總的一篇微博“做VPC網(wǎng)絡(luò)性能對(duì)比測(cè)試的，發(fā)現(xiàn)單向打包測(cè)試的時(shí)候，1G情況下，軟硬件方案性能差異也就10%的差距，而一旦測(cè)試雙向打包，發(fā)現(xiàn)性能對(duì)比一下子明顯了，差不多有40%的差距。另外一個(gè)明顯的對(duì)比是10G下的時(shí)延測(cè)試，軟件是毫秒級(jí)，硬件方案是微秒級(jí)”。博主我猜這里的VPC是指“Virtual Private Cloud”而不是指其他東西，我不了解此項(xiàng)測(cè)試的具體內(nèi)容和方法，在此引用是希望讓廣大的工程獅兄弟們?cè)跊Q定跳入overlay大坑的時(shí)候?qū)π阅芤裢怅P(guān)注，特別是在決定要大規(guī)模部署之前。

在博主看來，優(yōu)秀的解決方案總是會(huì)最終趨同的。這種現(xiàn)象有些時(shí)候會(huì)被人誤解為抄襲。但事實(shí)往往是人們通過不同的路徑到達(dá)了同一個(gè)結(jié)論。在SDN的世界里，這個(gè)結(jié)論已經(jīng)呼之欲出了：我們需要SDN控制器同時(shí)管理overlay和underlay，博主把它稱作fullstack。也許這個(gè)名稱并不合適，但大家領(lǐng)會(huì)精神就好。在分析這個(gè)結(jié)論之前，我們看看各個(gè)廠家都在做什么。Cisco作為傳統(tǒng)的網(wǎng)絡(luò)設(shè)備提供商，早已經(jīng)把觸角伸到了overlay甚至是更上層的各種應(yīng)用，正在進(jìn)行的ACI與OpenStack的深度整合就是***的例證。VMWare在2014年10月份將Guido Appenzeller招致麾下，讓人對(duì)VMWare涉足物理網(wǎng)絡(luò)產(chǎn)生無盡聯(lián)想。Big Switch Networks的overlay和underlay解決方案都已經(jīng)成熟，目前正致力于將二者結(jié)合。各大廠家不約而同的開始向一個(gè)方向發(fā)力，也印證了fullstack是未來的方向。那么究竟是什么原因讓大家棄overlay和underlay而轉(zhuǎn)向fullstack呢?

先說說overlay方案的局限。首先，它太!貴!了!這個(gè)賬怎么算呢?比如我們要采用overlay的方案建立一個(gè)多租戶的數(shù)據(jù)中心。物理網(wǎng)絡(luò)的解決方案本身就需要花一筆錢。服務(wù)器虛擬化解決方案是第二筆錢(更高大上的術(shù)語是orchestration，比如OpenStack的nova)。這還不夠，我們還需要將overlay SDN解決方案和orchestration系統(tǒng)深度整合，用SDN控制器管理每個(gè)服務(wù)器上面的OVS，這是第三筆錢。如果采用fullstack，這三筆錢就會(huì)變成兩筆。***筆是用orchestration解決方案管理虛擬機(jī)和bare metal服務(wù)器，第二筆錢是用fullstack SDN方案管理整個(gè)網(wǎng)絡(luò)，物理網(wǎng)絡(luò)解決方案的開銷就完全省掉了。fullstack SDN控制器可以通過plugin的形式和orchestration系統(tǒng)深度整合，正如OpenStack的Nova和Neutron之間的關(guān)系，只是在這里Neutron plugin通過fullstack SDN控制器直接控制整個(gè)網(wǎng)絡(luò)，而不是像OpenStack Juno release那樣僅僅在OVS上做分布式路由(DVR)。

overlay方案的另外一個(gè)致命的問題是它并沒有完全的從物理網(wǎng)絡(luò)解耦合，仍然需要服務(wù)器管理團(tuán)隊(duì)和網(wǎng)絡(luò)管理團(tuán)隊(duì)的密切合作。一種最常用的多租戶解決方案是用vlan區(qū)別不同租戶，也就是說，在overlay方案中每增加一個(gè)租戶，網(wǎng)絡(luò)管理員就需要在物理網(wǎng)絡(luò)中人工配置一個(gè)vlan，這一個(gè)人工參與的環(huán)節(jié)就可能引發(fā)諸如配置錯(cuò)誤，網(wǎng)絡(luò)升級(jí)困難等問題。另外一種做法是采用vxlan，問題是vxlan需要物理網(wǎng)絡(luò)支持ip multicast，這個(gè)協(xié)議troubleshooting起來又相當(dāng)麻煩。在vxlan和非vxlan交界的地方還需要部署vxlan gateway，但這個(gè)vxlan gateway又往往成為性能瓶頸，飽受詬病。這里，博主可以舉出更多的例子。但核心觀點(diǎn)是: 本來只有一張網(wǎng)，引入overlay之后就需要維護(hù)兩張網(wǎng)，并且兩張網(wǎng)還需要彼此協(xié)調(diào)，運(yùn)維成本并不會(huì)便宜。

第三個(gè)overlay方案可能存在的問題是它的性能，這一點(diǎn)在之前的段落中已經(jīng)有所涉及。到2014年10月為止，博主并沒有做過overlay方案的性能測(cè)試，這一段留個(gè)空白，以后補(bǔ)齊。

下面我們來看一下underlay方案的不足?，F(xiàn)在市場(chǎng)上underlay的解決方案很多，大概分為兩類，一種是用控制器集中管理配置，交換機(jī)之間仍然采用分布式的二層三層協(xié)議。另外一種是用控制器直接控制所有的交換機(jī)的轉(zhuǎn)發(fā)行為，交換機(jī)之間不跑任何分布式協(xié)議。不論哪一類，它們離上層的應(yīng)用都太遠(yuǎn)了，正如博主在第二篇文章中舉的例子那樣，每新增一個(gè)租戶，每部署一個(gè)多級(jí)的應(yīng)用或者每插入一個(gè)網(wǎng)絡(luò)服務(wù)，都需要網(wǎng)絡(luò)管理員進(jìn)行仔細(xì)的規(guī)劃和手工的配置。其實(shí)overlay解決方案的產(chǎn)生以及NFV(network function virtualization，在以后的文章中會(huì)詳細(xì)討論)的興起本質(zhì)上都是由于underlay方案的這個(gè)不足。

好了，分析完overlay和underlay方案的不足，希望大家也開始理解為什么SDN誕生了那么久，但總給人一種雷聲大雨點(diǎn)兒小的感覺。因?yàn)楝F(xiàn)有的SDN解決方案不是overlay就是underlay，它們都有一些自身難以越過的局限。在經(jīng)歷了幾年痛苦的學(xué)習(xí)過程之后，業(yè)界終于意識(shí)到：如果再在overlay還是underlay這個(gè)問題上糾纏，情況不會(huì)有任何改觀。于是各大廠家都開始向fullstack轉(zhuǎn)型，用一個(gè)SDN控制器管理所有的物理交換機(jī)和OVS。因?yàn)橹挥羞@樣才能1) 用最經(jīng)濟(jì)的方式部署上層應(yīng)用和網(wǎng)絡(luò)服務(wù)，避免一切的box by box的手動(dòng)配置，2) 沒有overlay方案的性能瓶頸。成熟的fullstack方案已經(jīng)箭在弦上，對(duì)于SDN的大規(guī)模部署博主持非常樂觀的態(tài)度。