有些朋友一看這個(gè)問題可能會(huì)有些不知所云，如果SDN控制器不管物理交換機(jī)翻默，那么它管什么呢缸沃？答案是只管理虛擬交換機(jī)。這里修械，博主需要插入一個(gè)簡(jiǎn)短的科普和泌。自從云計(jì)算盛行以來(lái)，主機(jī)虛擬化技術(shù)已經(jīng)深入人心祠肥。任何一臺(tái)物理主機(jī)上都可以同時(shí)運(yùn)行多個(gè)虛擬機(jī)(docker是另外一個(gè)話題)。那么問題來(lái)了梯皿，一臺(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)就可以快速贏得客戶势就。

用SDN控制器管理物理交換機(jī)最早出現(xiàn)在2008年的Sigcomm上[link]泉瞻。與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ì)硬件交換芯片[link]，目的是讓硬件交換芯片支持多級(jí)流表幔荒，每一級(jí)流表都支持match + action糊闽。另外一個(gè)陣營(yíng)則以Rob Sherwood為代表，主張挖掘現(xiàn)有硬件交換芯片的潛力爹梁，充分的排列組合OpenFlow協(xié)議中的match和action右犹，盡量把match+action在二層和三層的流表中實(shí)現(xiàn)。TCAM流表僅僅用來(lái)應(yīng)對(duì)一些復(fù)雜ACL[link]姚垃。無(wú)獨(dú)有偶傀履，@盛科張衛(wèi)峰總的主張也和這個(gè)觀點(diǎn)不謀而合[link]±蚵看來(lái)學(xué)院派的人士充滿了理想主義情懷钓账，工業(yè)界人士?jī)A向于漸進(jìn)式的創(chuàng)新。

科普完畢絮宁，業(yè)界有人在采用overlay的方案梆暮，也有人在嘗試underlay的方案。那么那個(gè)選擇更合理呢绍昂？在這里希望大家做個(gè)深呼吸啦粹，稍微深入的思考一下這個(gè)問題偿荷。博主的教訓(xùn)是無(wú)論選擇哪個(gè)技術(shù)流派，你都為自己挖下了一個(gè)巨大的坑唠椭，這個(gè)坑你逃不過跳纳。在某一個(gè)階段，你一定會(huì)或多或少的后悔：如果當(dāng)初做另外一個(gè)選擇就好了贪嫂。我們不妨先看看業(yè)界大佬的觀點(diǎn)是啥寺庄。你會(huì)突然發(fā)現(xiàn)：大佬們?cè)瓉?lái)也在努力從自己挖的坑里爬出來(lái)啊。

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ù)多樣橄唬，各種流表無(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方案自然也無(wú)計(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ī)模部署之前急前。

在博主看來(lái)，優(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)生無(wú)盡聯(lián)想凌受。Big Switch Networks的overlay和underlay解決方案都已經(jīng)成熟，目前正致力于將二者結(jié)合思杯。各大廠家不約而同的開始向一個(gè)方向發(fā)力胜蛉，也印證了fullstack是未來(lái)的方向。那么究竟是什么原因讓大家棄overlay和underlay而轉(zhuǎn)向fullstack呢色乾？

先說說overlay方案的局限誊册。首先，它太暖璧！貴案怯！了！這個(gè)賬怎么算呢澎办？比如我們要采用overlay的方案建立一個(gè)多租戶的數(shù)據(jù)中心嘲碱。物理網(wǎng)絡(luò)的解決方案本身就需要花一筆錢。服務(wù)器虛擬化解決方案是第二筆錢(更高大上的術(shù)語(yǔ)是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起來(lái)又相當(dāng)麻煩棍厂。在vxlan和非vxlan交界的地方還需要部署vxlan gateway，但這個(gè)vxlan gateway又往往成為性能瓶頸超陆，飽受詬病牺弹。這里，博主可以舉出更多的例子时呀。但核心觀點(diǎn)是: 本來(lái)只有一張網(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ǔ)齊盆驹。

下面我們來(lái)看一下underlay方案的不足。現(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)度懦傍。