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

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

科普完畢，業(yè)界有人在采用overlay的方案，也有人在嘗試underlay的方案。那么那個選擇更合理呢?在這里希望大家做個深呼吸，稍微深入的思考一下這個問題。博主的教訓(xùn)是無論選擇哪個技術(shù)流派，你都為自己挖下了一個巨大的坑，這個坑你逃不過。在某一個階段，你一定會或多或少的后悔：如果當(dāng)初做另外一個選擇就好了。我們不妨先看看業(yè)界大佬的觀點是啥。你會突然發(fā)現(xiàn)：大佬們原來也在努力從自己挖的坑里爬出來啊。

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

在另一個方面，雖然Nicira是overlay SDN解決方案的旗幟性公司，但Nicira也逐步開始管理物理交換機了，至少是開始管理top-of-rack(ToR)了。這里我們不妨看一下Nicira大神Bruce Davie的兩篇博客。在2011年，用open virtual switch打隧道棒極了，部署靈活，服務(wù)多樣，各種流表無限大，性能也號稱沒有明顯的瓶頸[link]。但是在2013年,Bruce忽然話風(fēng)一轉(zhuǎn)，開始把隧道放在了ToR上，他把原因主要歸結(jié)于支持bare metal服務(wù)器[link]。所謂bare metal服務(wù)器是指那些沒有采用虛擬化技術(shù)的主機，在這些主機上，沒有OVS，overlay方案自然也無計可施。為了在這種環(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打隧道可能會成為吞吐量的瓶頸。兄弟這里沒有數(shù)據(jù)，于是斗膽引用盛科張衛(wèi)峰總的一篇微博“做VPC網(wǎng)絡(luò)性能對比測試的，發(fā)現(xiàn)單向打包測試的時候，1G情況下，軟硬件方案性能差異也就10%的差距，而一旦測試雙向打包，發(fā)現(xiàn)性能對比一下子明顯了，差不多有40%的差距。另外一個明顯的對比是10G下的時延測試，軟件是毫秒級，硬件方案是微秒級”。博主我猜這里的VPC是指“Virtual Private Cloud”而不是指其他東西，我不了解此項測試的具體內(nèi)容和方法，在此引用是希望讓廣大的工程獅兄弟們在決定跳入overlay大坑的時候?qū)π阅芤裢怅P(guān)注，特別是在決定要大規(guī)模部署之前。

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

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

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

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

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

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