本文整理自瞻博網路傑出工程師Sukhdev Kapur在“TF中文社群成立暨第一次全員大會”上的演講，增加了對於TF功能的描述，資料下載： http://tungstenfabric.org.cn/assets/uploads/files/powering-edge-cloud-and-multi-cloud-with-tungsten-fabric-sukhdev-kapur.pdf

更多會議資料，請在“TF中文社群”公眾號後臺回復“成立大會”獲取。

瞻博網路傑出工程師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層和開發階段的應用層才可以進行通訊。

同樣地，如果你的應用是一個地理分散式的應用，你可以透過定義策略，讓在地理區域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上面。大家也可以開啟下面藍色的連結，自己去進行類似的實驗。

更多瞭解Tungsten Fabric

關注微信：TF中文社群
郵箱：tfzw001@163.com

Tungsten Fabric架構和最新技術進展丨TF成立大會演講實錄

相關文章