青云SDN/NFV2.0架构剖析
編者按：在ArchSummit北京2015大會上，來自青云的工程師陳海泉分享了《SDN/NFV 2.0架構(gòu)剖析》的議題。對于青云來說，SDN/NFV2.0是一個新的突破。早在2013年，青云在第一代公有云產(chǎn)品中就上線了SDN技術(shù)。隨著用戶量越來越大，私有網(wǎng)絡(luò)里面的 VM 數(shù)量超過一定的數(shù)量級的時候，性能問題逐漸成為瓶頸。在2015年下半年，青云經(jīng)過重點研發(fā)，推出了SDN/NFV 2.0。
\\SDN 就是軟件定義網(wǎng)絡(luò)。當然也不是所有網(wǎng)絡(luò)定制一定要軟件來實現(xiàn)，因為有很多硬件方案也可以做到 SDN 的效果。青云 QingCloud 用軟件定義來實現(xiàn)虛擬網(wǎng)絡(luò)。
\\VPC 是什么意思呢？VPC 網(wǎng)絡(luò)是 QingCloud 環(huán)境內(nèi)可以為用戶預(yù)配置出的一個專屬的大型網(wǎng)絡(luò)。在 VPC 網(wǎng)絡(luò)內(nèi)，用戶可以自定義 IP 地址范圍、創(chuàng)建子網(wǎng)，并在子網(wǎng)內(nèi)創(chuàng)建主機/數(shù)據(jù)庫/大數(shù)據(jù)等各種云資源。
\\正是因為云計算需要虛擬網(wǎng)絡(luò)，也需要 VPC 。所以我們還需要定義一個 SDN 方案解決這兩個需求，現(xiàn)有的 SDN 方案主要分成兩個方向：
\\- \\t
一是用軟件來定義，但是用硬件來實現(xiàn)。比如某些帶 SDN 功能的交換機，把它采購進來，部署到產(chǎn)品里，用硬件廠商提供的 API ，在上面提供 SDN 功能。
\\t\\t - \\t
二是NFV ，就是網(wǎng)絡(luò)功能虛擬化，用軟件的方式來實現(xiàn)，用軟件的交換機和路由器，把他們組織起來成為一個軟件實現(xiàn)的 SDN 。其代表有 VMware NSX、Juniper OpenContrail 等等。
\\t\
QingCloud 在 SDN 方案的選型上也做過討論，用軟件還是用硬件方案？其中考慮的問題主要是以下三個方面：
\\- 第一，成本。在公有云上面大家拼的是成本，誰的硬件成本低，誰就能把價格降到最低。如果我們采用現(xiàn)有的硬件方案，在網(wǎng)絡(luò)設(shè)備上面增加了很多投資，并且我要采購的不是一個或者兩個，而是一批。\\t
- 第二，設(shè)備依賴。我們的私有云賣的是軟件，客戶可以按照偏好選擇自己的硬件，假如QingCloud 的 SDN 綁定了某款硬件產(chǎn)品，那我們在面對用戶的時候，可能連招標的機會都沒有，因為人家壓根就沒有辦法用你的硬件。\\t
- 第三，情懷。對于工程師來說，大家都想把產(chǎn)品做得更優(yōu)秀。其實，軟件跟傳統(tǒng)快遞行業(yè)非常的接近，為什么這么說。因為網(wǎng)絡(luò)中的交換機、路由器，其實跟快遞行業(yè)里的快遞員和包裹集散中心非常相似，一般包裹給快遞員以后，快遞員會發(fā)給一個快遞集散中心，這里可以查詢包裹應(yīng)該被送到哪個地方，然后再將包裹交給快遞員，送到用戶那里。順豐在中國應(yīng)該是最好的快遞公司之一，因為它把轉(zhuǎn)運環(huán)節(jié)都做全了，只有方方面面都能夠控制才能實現(xiàn)壓倒性的優(yōu)勢。因此，我們?nèi)绻褦?shù)據(jù)包轉(zhuǎn)發(fā)的每個流程都控制到，就有可能在系統(tǒng)上面做到最優(yōu)，采用硬件設(shè)備使用這些功能的話，最后帶來的是同質(zhì)化，跟競爭對手相比不會有任何的優(yōu)勢。\
綜合以上三方面的原因，我們決定開發(fā)一套新的SDN/NFV 2.0 方案，取代 1.0 。
\\\\既然定了要自己做一套新的方案，怎么去實現(xiàn)？我們做了一些總結(jié)，新的產(chǎn)品需要滿足傳統(tǒng) SDN 的需求。第一，數(shù)據(jù)封裝。也就是實現(xiàn)一個基本的虛擬網(wǎng)絡(luò)；第二，實現(xiàn)控制平面。二層、三層的網(wǎng)絡(luò)數(shù)據(jù)進行路由規(guī)則的同步，然后下發(fā)到虛擬的交換機和路由器里面去，控制做到 ARP 泛洪抑制；第三，實現(xiàn)數(shù)據(jù)平面。除了 DVR 之外，還提供了虛擬邊界路由器。
\\除此之外，還需要增加我們需要的 2.0 方面的功能。
\\- 第一，VPC 主機直接綁定公網(wǎng) IP 。私有云用戶大量依賴基礎(chǔ)網(wǎng)絡(luò)，要求 VM 直接綁定公網(wǎng) IP ；\\t
- 第二，負載均衡器。可對進入流量進行分流，出流量經(jīng)由多臺 Virtual Gateway (虛擬網(wǎng)關(guān))分擔負載，單 IP 可承載 1 TB 出流量。同時，4—7層完全透明；\\t
- 第三，IP 不變。支持可以無限水平擴展的基礎(chǔ)網(wǎng)絡(luò)，并保持高可用及高性能，VM 任意遷移，IP 地址保持不變；\\t
- 第四， VPC 和物理網(wǎng)絡(luò)連接。\
下面分別解釋剛才說的那幾個基礎(chǔ)實現(xiàn)。
\\\\首先解釋虛擬網(wǎng)絡(luò)。在一些大公司里會提供一種叫內(nèi)部郵遞的服務(wù)。公司員工之間可以發(fā)送一種快遞，比如要給財務(wù)部門某同事發(fā)一個報價單，會查他的工位，知道他坐在哪，比如 184-323-534 。然后準備一個大信封，把要填的單子放在里面。我不需要知道這個人是在北京，還是在上海，我把這個信封交給公司的收發(fā)室，這個收發(fā)室會對這個信封進行重新封裝，因為他有此員工的具體地址，然后把具有新地址的信封交給外包快遞公司。放到云計算里，這就是一個虛擬網(wǎng)絡(luò)。可以允許用戶自己定義一個地址，然后進行傳輸，為了讓它在三層網(wǎng)絡(luò)里傳輸，可以再進行封裝，再套一個包，寫上新的地址。根據(jù)外包的內(nèi)容和里層包的內(nèi)容把這個數(shù)據(jù)包發(fā)送到對應(yīng)的信息那里。
\\虛擬網(wǎng)絡(luò)依賴于拆包、分包。現(xiàn)在采用的方案主要是比較流行的 VXLAN，因為 VXLAN 有一系列的優(yōu)勢。第一，隧道連接一組物理機，由于 VXLAN 的數(shù)據(jù)包在整個轉(zhuǎn)發(fā)過程中保持了內(nèi)部數(shù)據(jù)的完整，因此 VXLAN 的數(shù)據(jù)平面是一個基于隧道的數(shù)據(jù)平面；第二，使用 UPD 協(xié)議，當數(shù)據(jù)包交給網(wǎng)卡的時候，網(wǎng)卡根據(jù)這個數(shù)據(jù)的包頭，用不同的網(wǎng)卡隊列。這樣把包交給不同的CPU處理，提升性能；第三， 是比較有爭議的 Flood \u0026amp; Learn 自動管理虛擬網(wǎng)絡(luò)，VXLAN 可以進行泛洪學(xué)習(xí)，當 VTEP 收到一個 UDP 數(shù)據(jù)報后，會檢查自己是否收到過這個虛擬機的數(shù)據(jù)，避免組播學(xué)習(xí)。
\\通過以上幾點，我們覺得 VXLAN 不錯，但是仔細的去想，就發(fā)現(xiàn)它有兩個非常大的不足。一個是組播協(xié)議，大規(guī)模部署會受硬件設(shè)備組播路由限制；第二，泛洪學(xué)習(xí)的機制，會把原來在二層廣播的 ARP 包擴大到三層網(wǎng)絡(luò)，這樣隨著規(guī)模擴大，廣播越來越多，會嚴重的浪費帶寬資源。所以，我們既要使用 VXLAN ，又要消滅它的不足，所以我們設(shè)置了 SDN 控制器，通過我們自己設(shè)置的規(guī)則，取代它自有的泛洪學(xué)習(xí)規(guī)則。
\\那么這個控制器需要多少個呢？我之前曾經(jīng)了解過一些用戶生產(chǎn)環(huán)境里用到的控制器，通常只有一個。它負責整個集群中所有節(jié)點的規(guī)則，這么做造成一個問題，當集群創(chuàng)建、銷毀、遷移的時候，需要把規(guī)則同步到整個集群所有的節(jié)點中，這樣隨著用戶秒級創(chuàng)建資源的需求，同步規(guī)則的流量就會相當相當大。所以我們做了一個分布式控制器，不僅把控制器分布到 VPC ，還分布到虛擬網(wǎng)絡(luò)里頭。每個 VPC 有 253 個虛擬網(wǎng)絡(luò)。
\\\\剛才說了虛擬網(wǎng)絡(luò)和控制器，第三點 SDN 需要做的就是控制數(shù)據(jù)平面，其作用就是把數(shù)據(jù)包真的從一個地方拷貝到另外一個地方。傳統(tǒng)的數(shù)據(jù)平面，比如 OpenStack 通常會用 OVS ，OVS 會有一個問題，它會把數(shù)據(jù)交給另外一個程序，這樣會帶來一個性能的下降，而我們的方案完全改變了這個問題，自己做了一些 Kernel 的改動，將轉(zhuǎn)發(fā)放到 Linux Kernel 上，而且我們是用 NFV 來實現(xiàn)的。
\\\\同時我們引入了一個新的功能叫做 DVR （分布式虛擬路由器）。通過上面的圖解釋一下我們?yōu)槭裁葱枰狣VR。左邊是這張是物理拓撲圖，物理世界中 A 和 B 通信，需要把信息發(fā)送到 A 的交換機，然后到路由器，然后路由器轉(zhuǎn)給 B 的交換機，B 的交換機再發(fā)送給 B ，A 和 B 通常需要 4 跳才能發(fā)一個數(shù)據(jù)包。
\\我們 1.0 的時候，也是用 NFV 實現(xiàn)的 SDN ，我們會模仿物理世界，虛擬出虛擬的路由器和交換機提供給用戶。如果 A、B、C、D、E 這五個設(shè)備分別位于五個不同的虛擬機上，在邏輯上 A 的包經(jīng)過C、E、D、B 才能到，邏輯上是四跳。但是虛擬設(shè)備每一跳都要通過物理設(shè)備去交換，而物理設(shè)備每一條四跳，這樣總得轉(zhuǎn)發(fā)量實際上需要 16 跳。這也就是為什么 1.0 的性能總是上不去。為了解決這個問題，我們引入了 DVR ，從 A 到 B 還是這樣，兩個 DVR 之間直接交換一下數(shù)據(jù)就可以了，因為在邏輯上有一跳，所以總數(shù)跟原來物理設(shè)備一樣，四跳完成一個數(shù)據(jù)包的轉(zhuǎn)換，這樣性能就可以非常接近物理機的性能，從而可以組成一個大的虛擬網(wǎng)絡(luò)。
\\\\QingCloud 的 DVR 除了實現(xiàn) VPC 簡單的功能之外，它實際上是一個復(fù)雜的東西。因為除了保持自己跟自己的虛擬網(wǎng)絡(luò)，還需要有其他四個方向：第一個就是網(wǎng)關(guān)需求，我們需要提高公網(wǎng) IP 存儲量，希望 DVR 把包發(fā)到公網(wǎng)網(wǎng)關(guān)；第二是 VPC 的虛擬機要能跟硬件設(shè)備進行高度的互訪。因為我們私有云用戶的機房里，不止有 QingCloud 的東西，還有 Oracle 的數(shù)據(jù)庫、F5 的路由器等等，假如我們讓用戶把這些業(yè)務(wù)放到虛擬網(wǎng)絡(luò)里，虛擬網(wǎng)絡(luò)就要跟硬件網(wǎng)絡(luò)進行高速的互訪。第三是VPC，可以讓用戶定義 255 個 C 段，加起來可以有 60000 多個虛擬機。第四是，我們還提供了一個邊界路由器，可以讓用戶虛擬資源跟遠程的 IDC 之間做一個互通。最后一個就是一個負載均衡器集群，我們的 DVR 就是一個平臺，讓用戶的主機和負載均衡器直接相連。
\\\\我們做的最后一個功能就是負載均衡器集群。設(shè)計是這樣，我們有一個網(wǎng)關(guān)集群連著因特網(wǎng)。比如我有一個 IP 1.1 ，實際上是綁定在 VG 1 這里，VG 1 會做第一次的流量轉(zhuǎn)發(fā)，會把流量按照用戶定義的負載均衡器節(jié)點數(shù)量轉(zhuǎn)發(fā)到自己私有的負載均衡器節(jié)點里（1、2、3），它的特點就是，返回流量不需要經(jīng)過進來的這個網(wǎng)關(guān)，而是經(jīng)過自己對應(yīng)的不同物理網(wǎng)關(guān)發(fā)送到因特網(wǎng)。因為當 VG 1 能力受到限制的時候，假如我們所有流量都從它回去的時候，它自己的網(wǎng)絡(luò)帶寬實際上就是整個集群的能力。而我們把它分散之后，就可以做到，出去的流量幾乎是沒有限制。只要我們的 VG 設(shè)備有多少，它的帶寬就會有多少，因為流量不需要從默認的線路回去。同時隨著用戶拓展負載均衡器節(jié)點的數(shù)量，也擴展了 HTTPS 的卸載能力，并且我們做到了 4 層/ 7 層的完全透明，也就是說用戶通過因特網(wǎng)訪問到他們業(yè)務(wù)的時候，我們在所有轉(zhuǎn)發(fā)過程中，都會保留其原地址，用戶這邊得到的包是直接來自因特網(wǎng)用戶的 IP 地址。
\\感謝魏星對本文的審校。
\\給InfoQ中文站投稿或者參與內(nèi)容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號：InfoQChina）關(guān)注我們，并與我們的編輯和其他讀者朋友交流（歡迎加入InfoQ讀者交流群（已滿），InfoQ讀者交流群（#2））。
總結(jié)
以上是生活随笔為你收集整理的青云SDN/NFV2.0架构剖析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： SharePoint 2013 Desi
- 下一篇： 时间轴CSS的Demo