[[285987]]

瞻博網絡杰出工程師Sukhdev Kapur

大家好，我叫SukhdevKapur，來自Tungsten Fabric(以下簡稱TF)社區技術指導委員會，下面我為大家介紹一下TF的架構和技術的現狀，以及最新的進展。

TF架構與部署模式

我們可以看一下這張TF的宏觀架構圖，整體圖描述是設備的物理連接，而右上角有虛機之間的邏輯網絡，TF基本的工作原理和機制，就是你創建VM或者POD，然后(通過SDN)把它們放到這些邏輯網絡里。

在這些邏輯網絡中，你能夠以根據自己業務需要，放置任何虛機、PODS、或者裸服務器，它們的物理位置在哪里沒有關系，它們可能會在一個集群里，也可能在一個機架中，這都沒有關系。

大家再看一下它下面底層的部分，TF會利用虛擬的路由器(計算節點上)，來負責是這些虛擬的工作負載的轉發，而左邊是一個物理網絡的連接，例如一個裸機的物理網絡，一旦你做好了網絡定義，它可能會和實際網絡連接，也可能會和右邊邏輯網絡里頭虛擬網絡的虛機來進行連接

第四部分(上半部分)是CONTRAILController(SDN控制器)，是做配置控制分析和CSN的。

第五部分是網關的功能，它可能是一個物理網關，或者是一個虛擬的網關，當數據中心的虛機需要對外互聯的時候，通過IP的組網——也就是MPLS這種協議——進出骨干網絡。

所有這一切，都是通過一個ORCHESTRATOR編排器去管理，它可能是OpenStack、K8s或OpenShift，通過API來調度TF來工作。

TF中Vrouter的體系架構概述

這張圖說的是TF的路由vRouter的架構，左上角是vRouter的Agent，主要是控制的部分，在這里它會通過路由的學習，VRFs的定義，以及策略的定義，如果虛擬路由器要進行策略的執行，必須是由Agent去控制的：它來決定網絡的流量是允許通過,還是拒絕，如果允許的話，應該把它轉發到哪個位置。

你可以看到，vRouter有一個轉發的路徑，學習的路徑進行封裝，然后做二層或者三層的數據流量的轉發。

vRouter的部署模式

這是TF虛擬路由器的四種部署模式，左上角是默認的模式，在內核的vRouter部署。

右上角呢?如果你在一個高吞吐、高流量的狀態下，網絡支持DPPK的話，TF可以有的DPDKvRouter的部署。

左下角其實是一種混合部署的模式，如果你有好幾個VNF這種虛擬網絡的功能，可以用到SR-IOV的話，可以采用SR-IOV和內核的vRouter共存的混合模式。

第四種就是基于SmartNIC的vRouter，也就是說，這些VM可以充分地利用到所有處理器的能力。

TF與Kubernetes的集成

大家再來看一下TF和Kubernetes(以下簡稱K8s)的集成，首先，TF的CONTRAIL Controller會和K8s通過API進行通訊，那么，某一個指定的位置，它是如何得到IP地址以及策略的呢?首先，K8s會和TF的Scheduler也就是調度管理程序進行通訊，再通過調度管理程序和CNI Plugin插件進行聯系，在左上角就表示vRouter是如何獲得在K8s這邊的策略，去進行IPAM的讀取和執行的，簡單一點說，K8s的管理器會和TF的CONTRAIL Controller進行通訊，確定網絡的策略，然后TF的Controller會把這個策略發布到vRouter。

TF的微服務架構

TF的技術演進，一開始主要是基于虛機部署，后來開始支持容器技術，現在已經演進到了微服務(Microservices)的架構。目前我們的TF在部署是完全采用containers的方式進行部署，大概有27-30個左右的image。

K8s環境下的網絡隔離

K8s是一個非常扁平的網絡，租戶和租戶之間可以進行任意的溝通，工作負載之間也是這樣。

基于這樣的場景，我們就通過網絡策略的執行，去實現網絡中租戶的隔離，也就是說，只是在指定區域內的用戶之間，才可以進行溝通。

那么在TF這一層，我們把管理又向前推進了一步，即在一個租戶的空間之內，我們也可以決定哪個位置和哪個位置可以溝通，也就是哪個POD和哪個POD通訊。

TF提供的統一策略管理功能

下面為大家介紹一下TF的獨特的策略框架。假設我們有一個應用，該應用有三層，分成三層，分別是Web層、應用層和數據庫層。而這個應用的生命周期會有三個階段，分別是開發的階段，部署準備的階段，和最后的生產階段。

不同的階段可能部署在不同的網絡環境，甚至于不同的云平臺中，那么在最上面的開發階段，不同的層之間(層也是tie的概念)，會有一些安全的訪問策略(圖中P1的策略也)，而這個策略可能在部署準備階段也需要(圖中P2的策略)在生產階段也需要，在不使用TF的情況下，很有可能會出現重復的策略，而是用TF之后，我們可以只使用一個策略

我們所做的就是把策略的管理進行了簡化，首先就是降低了復雜性，簡化管理，提高了可伸縮度。一旦定義好了策略，你就可以在各種各樣的環境之下，進行規模性的、可伸縮的復用，包括公有云、私有云，以及多云的環境。

給大家介紹一個實際的策略框架用例。

假設我們有一個應用，我們允許它的Web層和應用層進行溝通，那么不管是在開發階段，還是在生產階段，我們都可以使用這樣一個定義，比如在開發階段的Web層，也可以和生產環境下的應用層進行溝通。

但是，也許我們并不希望有這樣的事情發生，我們不希望某一個開發人員能夠隨意修改在生產環境下的代碼。這時你不用去改變策略，只需要在策略里頭加上App Match Deployment的標簽，它可以去規定——比如說只有在開發階段的Web層和開發階段的應用層才可以進行通信。

同樣地，如果你的應用是一個地理分布式的應用，你可以《Tungsten Fabric架構和最新技術進展》（演講人：SK）通過定義策略，讓在地理區域A的Web層和在地理區域B的應用層之間進行通信。

如果你不希望這種跨層、跨區域的通信產生，就在AppMatch Deployment的后頭再加上End Site。所以說這個match，不光是它的部署，還有它的位置，你都要把它match一下。

我們再加一層，你看我們第二個策略的意思，就是說只要是這個站點我們match上了，匹配上了，那么它們都可以和數據庫進行訪問。

這樣的一種策略在管理方面非常的有用。如果你有一個非常大型的跨地理區域分布式的金融應用，它可能使用了多個網絡，網絡上還有數百種的應用，這個時候你只需要一個策略，就可以對整個分布式的金融應用進行管理。

一個界面，搞定多云部署

同時，TF還可以實現多云部署的自動化管理。比如說我們在駐地這里自動創建了一個叫做多云的網關MC-GW，它會建立一個通道，和在云端的(比如說AWS上的)同樣的部署，自動地進行安全的連接。

這里也要看，你在云上部署的工作負載到底是什么種類的。有了這個工作負載，你可以在本地云的環境下進行管理，而TF能夠給你一個多云的可視性。

大家可以看一下，如果你自己去進行多云管理，需要通過很多的流程來實現。而TF只需要一個單一的圖形用戶界面，就能夠輕松地進行多云管理，你需要做的，只是做幾下點擊的動作。

多云環境的服務鏈

下面來介紹一下TF的多云服務鏈。大家看到最上面有兩個網絡在駐地，左邊的是2.2.2.4，右邊的是3.3.3.5，然后有一個服務的實例，假設服務實例是POD的虛擬化服務，通過TF的服務鏈，可以將工作負載從左邊的網絡傳到右邊。

同樣地，如果要在不同的公有云上也去部署這樣的虛擬網絡，你可以通過TF，從駐地到多云建立這樣一個服務鏈。

我來總結一下，只需要一個SDN的控制器，就能夠去管理連接——不管是金屬裸機、K8s CNI、OpenStack，還是左邊的各種邊緣的站點——并且提供非常豐富的網絡功能。

TF與Akraino的集成

TF在邊緣計算的環境下也做出了自己的貢獻，這是另外一個開源的項目，TF實現了和Akraino的集成，能夠為邊緣計算這樣的場景提供支持，它是純基于K8s原生基礎架構的，非常適用于輕量級的，像工業自動化這種應用。基本上它部署的環境是非常小的，目標行業主要是電信運營商和企業級用戶。

這是另外一個Akraino和TF集成的用例，主要是打造電信云，目前美國電信運營商AT&T就做了這樣的一個架構部署。這里主要是使用SR-IOV這種虛擬化，我們所做的就是把TF作為一個單一的SDN，它的部署模式包含了以上所有類型。

這是第三個用例，它是一種叫做微云的軟件堆棧，主要應用于移動的場景，例如手機游戲，工作負載是移動化的這種架構。

在這里我們是怎么做的?首先，我們有一個DME(分布式的匹配引擎)，它知道有多少個設備或者多少個移動用戶接入進來，并根據移動用戶的數量，啟動微云資源管理器去做信息傳遞;然后微云資源管理器就會匹配到相應的資源;接下來CRM會和TF的控制器進行溝通，來進行這種資源的部署;再到下面一層，通過vRouter的轉發層，和TF的控制器進行聯系。

TF與OpenStack的集成

熟悉OpenStack的朋友都知道，它有兩種部署模式，一種是單一的插件方式，另一種是基于ML2的部署。

TF專門有一個Networking Open Contrail，可以將TF作為一個ML2的插件去啟動。這樣做有什么好處呢?我們可以同時去運行基于OVS、SR-IOV和vRouter的這工作。

你可以用OpenStack來運行OVS、SR-IOV的工作負載，并且在網絡層面使用我們的TF去進行管理。

接下來我們將為大家進行演示，看看如何把基于OVS的計算遷移到基于vRouter上面。大家也可以打開下面藍色的鏈接，自己去進行類似的實驗。

謝謝各位!