陳海泉：SDN/NFV 2.0 架構的網(wǎng)絡技術實踐

arron劉

分享人： 陳海泉，青云QingCloud 系統(tǒng)工程師

大家好，我是 QingCloud 的工程師陳海泉，今天給大家分享一些 SDN/NFV 2.0 架構的網(wǎng)絡技術。

首先，說一下什么是 SDN，SDN 就是軟件定義網(wǎng)絡。當然也不是所有網(wǎng)絡定制一定要軟件來實現(xiàn)，因為有很多硬件方案也可以做到 SDN 的效果。

青云QingCloud 用軟件定義來實現(xiàn)虛擬網(wǎng)絡，我們 2013 年的時候，在公有云上線了第一代產(chǎn)品。當時 SDN 還是一個比較新鮮的事情，用戶用的還比較少，隨著用戶量越來越大，私有網(wǎng)絡里面的 VM 數(shù)量超過一定的數(shù)量級的時候，我們發(fā)現(xiàn)性能就有一個比較大的損失，已經(jīng)無法滿足用戶的需求。所以我們在去年下半年的時候，花了很大功夫去做 SDN/NFV 2.0 的事情。

VPC 是什么意思呢？VPC 網(wǎng)絡是 QingCloud 環(huán)境內(nèi)可以為用戶預配置出的一個專屬的大型網(wǎng)絡。在 VPC 網(wǎng)絡內(nèi)，用戶可以自定義 IP 地址范圍、創(chuàng)建子網(wǎng)，并在子網(wǎng)內(nèi)創(chuàng)建主機/數(shù)據(jù)庫/大數(shù)據(jù)等各種云資源。

正是因為云計算需要虛擬網(wǎng)絡，也需要 VPC 。所以我們還需要定義一個 SDN 方案解決這兩個需求，現(xiàn)有的 SDN 方案主要分成兩個方向：

• 一是用軟件來定義，但是用硬件來實現(xiàn)。比如某些帶 SDN 功能的交換機，把它采購進來，部署到產(chǎn)品里，用硬件廠商提供的 API ，在上面提供 SDN 功能。
• 二是NFV ，就是網(wǎng)絡功能虛擬化，用軟件的方式來實現(xiàn)，用軟件的交換機和路由器，把他們組織起來成為一個軟件實現(xiàn)的 SDN 。其代表有 VMware NSX、Juniper OpenContrail 等等。
  
  

QingCloud 在 SDN 方案的選型上也做過討論，用軟件還是用硬件方案？其中考慮的問題主要是以下三個方面：

• 第一，成本。在公有云上面大家拼的是成本，誰的硬件成本低，誰就能把價格降到最低。如果我們采用現(xiàn)有的硬件方案，在網(wǎng)絡設備上面增加了很多投資，并且我要采購的不是一個或者兩個，而是一批。
• 第二，設備依賴。我們的私有云賣的是軟件，客戶可以按照偏好選擇自己的硬件，假如QingCloud 的 SDN 綁定了某款硬件產(chǎn)品，那我們在面對用戶的時候，可能連招標的機會都沒有，因為人家壓根就沒有辦法用你的硬件。
• 第三，情懷。對于工程師來說，大家都想把產(chǎn)品做得更優(yōu)秀。其實，軟件跟傳統(tǒng)快遞行業(yè)非常的接近，為什么這么說。因為網(wǎng)絡中的交換機、路由器，其實跟快遞行業(yè)里的快遞員和包裹集散中心非常相似，一般包裹給快遞員以后，快遞員會發(fā)給一個快遞集散中心，這里可以查詢包裹應該被送到哪個地方，然后再將包裹交給快遞員，送到用戶那里。順豐在中國應該是最好的快遞公司之一，因為它把轉(zhuǎn)運環(huán)節(jié)都做全了，只有方方面面都能夠控制才能實現(xiàn)壓倒性的優(yōu)勢。因此，我們?nèi)绻�把�?shù)據(jù)包轉(zhuǎn)發(fā)的每個流程都控制到，就有可能在系統(tǒng)上面做到最優(yōu)，采用硬件設備使用這些功能的話，最后帶來的是同質(zhì)化，跟競爭對手相比不會有任何的優(yōu)勢。
  

綜合以上三方面的原因，我們決定開發(fā)一套新的SDN/NFV 2.0 方案，取代 1.0 。

既然定了要自己做一套新的方案，怎么去實現(xiàn)？我們做了一些總結，新的產(chǎn)品需要滿足傳統(tǒng) SDN 的需求。**第一，數(shù)據(jù)封裝。**也就是實現(xiàn)一個基本的虛擬網(wǎng)絡；**第二，實現(xiàn)控制平面。**二層、三層的網(wǎng)絡數(shù)據(jù)進行路由規(guī)則的同步，然后下發(fā)到虛擬的交換機和路由器里面去，控制做到 ARP 泛洪抑制；**第三，實現(xiàn)數(shù)據(jù)平面。**除了 DVR 之外，還提供了虛擬邊界路由器。

除此之外，還需要增加我們需要的 2.0 方面的功能。

• 第一，VPC 主機直接綁定公網(wǎng) IP 。私有云用戶大量依賴基礎網(wǎng)絡，要求 VM 直接綁定公網(wǎng) IP ；
• 第二，負載均衡器�？蓪�進入流量進行分流，出流量經(jīng)由多臺 Virtual Gateway (虛擬網(wǎng)關)分擔負載，單 IP 可承載 1 TB 出流量。同時，4—7層完全透明；
• 第三，IP 不變。支持可以無限水平擴展的基礎網(wǎng)絡，并保持高可用及高性能，VM 任意遷移，IP 地址保持不變；
• 第四， VPC 和物理網(wǎng)絡連接。
  

下面分別解釋剛才說的那幾個基礎實現(xiàn)。

首先解釋虛擬網(wǎng)絡。在一些大公司里會提供一種叫內(nèi)部郵遞的服務。公司員工之間可以發(fā)送一種快遞，比如要給財務部門某同事發(fā)一個報價單，會查他的工位，知道他坐在哪，比如 184-323-534 。然后準備一個大信封，把要填的單子放在里面。我不需要知道這個人是在北京，還是在上海，我把這個信封交給公司的收發(fā)室，這個收發(fā)室會對這個信封進行重新封裝，因為他有此員工的具體地址，然后把具有新地址的信封交給外包快遞公司。放到云計算里，這就是一個虛擬網(wǎng)絡�？梢栽试S用戶自己定義一個地址，然后進行傳輸，為了讓它在三層網(wǎng)絡里傳輸，可以再進行封裝，再套一個包，寫上新的地址。根據(jù)外包的內(nèi)容和里層包的內(nèi)容把這個數(shù)據(jù)包發(fā)送到對應的信息那里。

虛擬網(wǎng)絡依賴于拆包、分包。現(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 & Learn 自動管理虛擬網(wǎng)絡，VXLAN 可以進行泛洪學習，當 VTEP 收到一個 UDP 數(shù)據(jù)報后，會檢查自己是否收到過這個虛擬機的數(shù)據(jù)，避免組播學習。

通過以上幾點，我們覺得 VXLAN 不錯，但是仔細的去想，就發(fā)現(xiàn)它有兩個非常大的不足。一個是組播協(xié)議，大規(guī)模部署會受硬件設備組播路由限制；第二，泛洪學習的機制，會把原來在二層廣播的 ARP 包擴大到三層網(wǎng)絡，這樣隨著規(guī)模擴大，廣播越來越多，會嚴重的浪費帶寬資源。所以，我們既要使用 VXLAN ，又要消滅它的不足，所以我們設置了 SDN 控制器，通過我們自己設置的規(guī)則，取代它自有的泛洪學習規(guī)則。

那么這個控制器需要多少個呢？我之前曾經(jīng)了解過一些用戶生產(chǎn)環(huán)境里用到的控制器，通常只有一個。它負責整個集群中所有節(jié)點的規(guī)則，這么做造成一個問題，當集群創(chuàng)建、銷毀、遷移的時候，需要把規(guī)則同步到整個集群所有的節(jié)點中，這樣隨著用戶秒級創(chuàng)建資源的需求，同步規(guī)則的流量就會相當相當大。所以我們做了一個分布式控制器，不僅把控制器分布到 VPC ，還分布到虛擬網(wǎng)絡里頭。每個 VPC 有 253 個虛擬網(wǎng)絡。

剛才說了虛擬網(wǎng)絡和控制器，第三點 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 這五個設備分別位于五個不同的虛擬機上，在邏輯上 A 的包經(jīng)過C、E、D、B 才能到，邏輯上是四跳。但是虛擬設備每一跳都要通過物理設備去交換，而物理設備每一條四跳，這樣總得轉(zhuǎn)發(fā)量實際上需要 16 跳。這也就是為什么 1.0 的性能總是上不去。為了解決這個問題，我們引入了 DVR ，從 A 到 B 還是這樣，兩個 DVR 之間直接交換一下數(shù)據(jù)就可以了，因為在邏輯上有一跳，所以總數(shù)跟原來物理設備一樣，四跳完成一個數(shù)據(jù)包的轉(zhuǎn)換，這樣性能就可以非常接近物理機的性能，從而可以組成一個大的虛擬網(wǎng)絡。

QingCloud 的 DVR 除了實現(xiàn) VPC 簡單的功能之外，它實際上是一個復雜的東西。因為除了保持自己跟自己的虛擬網(wǎng)絡，還需要有其他四個方向：第一個就是網(wǎng)關需求，我們需要提高公網(wǎng) IP 存儲量，希望 DVR 把包發(fā)到公網(wǎng)網(wǎng)關；第二是 VPC 的虛擬機要能跟硬件設備進行高度的互訪。因為我們私有云用戶的機房里，不止有 QingCloud 的東西，還有 Oracle 的數(shù)據(jù)庫、F5 的路由器等等，假如我們讓用戶把這些業(yè)務放到虛擬網(wǎng)絡里，虛擬網(wǎng)絡就要跟硬件網(wǎng)絡進行高速的互訪。第三是VPC，可以讓用戶定義 255 個 C 段，加起來可以有 60000 多個虛擬機。第四是，我們還提供了一個邊界路由器，可以讓用戶虛擬資源跟遠程的 IDC 之間做一個互通。最后一個就是一個負載均衡器集群，我們的 DVR 就是一個平臺，讓用戶的主機和負載均衡器直接相連。

我們做的最后一個功能就是負載均衡器集群。設計是這樣，我們有一個網(wǎng)關集群連著因特網(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)關，而是經(jīng)過自己對應的不同物理網(wǎng)關發(fā)送到因特網(wǎng)。因為當 VG 1 能力受到限制的時候，假如我們所有流量都從它回去的時候，它自己的網(wǎng)絡帶寬實際上就是整個集群的能力。而我們把它分散之后，就可以做到，出去的流量幾乎是沒有限制。只要我們的 VG 設備有多少，它的帶寬就會有多少，因為流量不需要從默認的線路回去。同時隨著用戶拓展負載均衡器節(jié)點的數(shù)量，也擴展了 HTTPS 的卸載能力，并且我們做到了 4 層/ 7 層的完全透明，也就是說用戶通過因特網(wǎng)訪問到他們業(yè)務的時候，我們在所有轉(zhuǎn)發(fā)過程中，都會保留其原地址，用戶這邊得到的包是直接來自因特網(wǎng)用戶的 IP 地址。