Tungsten Fabric架構(gòu)和最新技術進展

作者：bing 2019-12-18 23:06:48

本文整理自瞻博網(wǎng)絡杰出工程師Sukhdev Kapur在“TF中文社區(qū)成立暨第一次全員大會”上的演講，增加了對于TF功能的描述。

瞻博網(wǎng)絡杰出工程師Sukhdev Kapur

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

TF架構(gòu)與部署模式

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

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

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

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

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

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

TF中Vrouter的體系架構(gòu)概述

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

你可以看到，vRouter有一個轉(zhuǎn)發(fā)的路徑，學習的路徑進行封裝，然后做二層或者三層的數(shù)據(jù)流量的轉(zhuǎn)發(fā)。

vRouter的部署模式

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

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

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

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

TF與Kubernetes的集成

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

TF的微服務架構(gòu)

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

K8s環(huán)境下的網(wǎng)絡隔離

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

基于這樣的場景，我們就通過網(wǎng)絡策略的執(zhí)行，去實現(xiàn)網(wǎng)絡中租戶的隔離，也就是說，只是在指定區(qū)域內(nèi)的用戶之間，才可以進行溝通。

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

TF提供的統(tǒng)一策略管理功能

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

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

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

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

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

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

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

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

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

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

一個界面，搞定多云部署

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

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

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

多云環(huán)境的服務鏈

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

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

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

TF與Akraino的集成

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

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

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

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

TF與OpenStack的集成