前段時(shí)間有幸和國內(nèi)的同行們交流了一番奈应，發(fā)現(xiàn)形勢大好定躏。云挥转，openstack，VMWare共屈，SDN都開始有repeatable use case出現(xiàn)了绑谣，技術(shù)落地也越來越扎實(shí)。這是好事拗引，大家加油借宵。
這篇文章會用上篇文章中的概念繼續(xù)聊如何在多租戶數(shù)據(jù)中心里進(jìn)行數(shù)據(jù)包的轉(zhuǎn)發(fā)。在聊具體方案之前矾削，大家先嘗試回答一下這個(gè)問題：如果你是當(dāng)初第一個(gè)設(shè)計(jì)多租戶數(shù)據(jù)中心轉(zhuǎn)發(fā)平面的架構(gòu)師壤玫，openstack上的一個(gè)租戶起了一個(gè)router，你會如何實(shí)現(xiàn)這個(gè)router呢哼凯？想清楚這個(gè)問題欲间，多租戶數(shù)據(jù)中心數(shù)據(jù)平面的大框架就有了，剩下的都是在為這個(gè)大框架添磚加瓦断部，小修小補(bǔ)猎贴。目前工業(yè)界有兩大類方案，overlay和fabric蝴光。這兩個(gè)方案完全不同她渴，而他們之所以不同的最根本原因就是對上面這個(gè)問題的答案不同。
Overlay
這類方案的設(shè)計(jì)者是這樣回答以上問題的：既然用戶在orchestration系統(tǒng)上起了一個(gè)router蔑祟，那我們也對應(yīng)起一個(gè)router就好了趁耗。問題是這個(gè)router應(yīng)該起在哪兒呢？在一臺服務(wù)器上起一個(gè)軟件router是最直接的選擇(在多租戶的概念剛興起的時(shí)候疆虚，這甚至是唯一的選擇)苛败。于是這個(gè)orchestration系統(tǒng)中邏輯上的router就和一臺軟件router一一對應(yīng)了。這臺軟件router很自然的便成了那個(gè)租戶所有subnet的default gateway径簿。一個(gè)很自然的問題便是：如果一個(gè)租戶的vm和router不在同一臺物理服務(wù)器上罢屈，那這個(gè)vm要如何才能夠和這個(gè)router實(shí)現(xiàn)二層互聯(lián)呢？兩個(gè)最容易想到的選擇便是：1) 通過配置vlan直接實(shí)現(xiàn)二層互聯(lián)牍帚，2) 通過隧道實(shí)現(xiàn)layer2 over layer3儡遮。選項(xiàng)1)在實(shí)踐中一直是一個(gè)很頭疼的問題：給定任意的拓普乳蛾，都能夠動態(tài)的配置vlan暗赶，trunk和STP鄙币，這是整個(gè)網(wǎng)絡(luò)行業(yè)解決了20年都沒有解決好的問題。于是選項(xiàng)2)成了唯一的選擇蹂随。
接下來的故事就非常順理成章了：vxlan應(yīng)運(yùn)而生十嘿，用來打隧道以及通過VNI來區(qū)分更多數(shù)量的租戶；一個(gè)軟件router沒有HA岳锁，于是先引入VRRP做冗余绩衷，之后是DVR；軟件router的性能可能會成為瓶頸激率，于是DPDK相關(guān)的技術(shù)又迎來了春天咳燕。
博主還是堅(jiān)持一直以來的觀點(diǎn)：所有的技術(shù)都是上層應(yīng)用驅(qū)動的。如果最初的架構(gòu)師們對以上那個(gè)問題給出了不同的答案乒躺，vxlan招盲，DVR，DPDK這些技術(shù)就很可能不會有今天這樣火爆了嘉冒。
Fabric
這類方案的設(shè)計(jì)者對以上那個(gè)黑體字問題的回答完全不同：這個(gè)router應(yīng)該實(shí)現(xiàn)在交換機(jī)上曹货，因?yàn)檫@是交換機(jī)的專長。既然在多租戶的數(shù)據(jù)中心里subnet并不和機(jī)架綁定讳推，一個(gè)IP可能被orchestration系統(tǒng)分配到任何位置顶籽，那么這個(gè)router就應(yīng)該分布式的實(shí)現(xiàn)在所有交換機(jī)上。
這是一個(gè)非常合理同時(shí)也非常大膽的回答银觅。我們先來看看在這樣的回答之下礼饱，一臺交換機(jī)究竟在扮演怎樣的角色。我們首先把目光關(guān)注在第一跳的交換機(jī)上 (如果是VM究驴，那這第一跳交換機(jī)就是一臺軟件交換機(jī)慨仿；如果是bare metal服務(wù)器，那這第一跳交換機(jī)就是一臺硬件交換機(jī))纳胧。不管是軟件還是硬件交換機(jī)镰吆，如果服務(wù)器發(fā)出的是二層報(bào)文，這臺交換機(jī)就應(yīng)該能夠進(jìn)行二層轉(zhuǎn)發(fā)/廣播跑慕；如果服務(wù)器發(fā)ARP要gateway的mac万皿，這臺交換機(jī)就應(yīng)該做ARP reply；如果服務(wù)器發(fā)出的是三層報(bào)文核行，這臺交換機(jī)就應(yīng)該能夠進(jìn)行三層轉(zhuǎn)發(fā)牢硅。例子舉到這里，大家就會發(fā)現(xiàn)在fabric的解決方案里芝雪，一臺交換機(jī)究竟是二層還是三層已經(jīng)變得模糊减余，數(shù)據(jù)的轉(zhuǎn)發(fā)平面需要進(jìn)行精心的設(shè)計(jì)。在這類解決方案當(dāng)中惩系，最具代表性的是Big Cloud Fabric位岔。
比較到這里如筛，兩類方案最大的區(qū)別就講清楚了：在overlay方案里，default gateway往往在某一臺物理服務(wù)器上抒抬；在fabric方案里杨刨，default gateway在第一跳的交換機(jī)上。不少方案就是在這兩種極端的解決方案之間尋找一個(gè)折中：比如有些方案會把tunnel打在硬件交換機(jī)上擦剑，用來保證性能以及滿足bare metal用戶的需求妖胀。關(guān)于兩種方案的優(yōu)劣，博主之前已經(jīng)聊了不少(文章4惠勒，文章10)赚抡。從各個(gè)角度來看，博主依然堅(jiān)定的認(rèn)為fabric是在技術(shù)上更加優(yōu)秀的方案纠屋。在之后的文章中怕品，博主會對fabric方案中，default gateway之后究竟會發(fā)生什么進(jìn)行進(jìn)一步討論巾遭。
