TungstenFabric入門寶典丨編排器集成

作者：Tatsuya Naganawa 譯者：TF編譯組

創(chuàng)新互聯(lián)服務項目包括襄城網(wǎng)站建設、襄城網(wǎng)站制作、襄城網(wǎng)頁制作以及襄城網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，襄城網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到襄城省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！

Tungsten Fabric已經(jīng)實現(xiàn)了多個編排器的集成。

在內(nèi)部，Tungsten Fabric的編排器集成組件基本上對每個編排器都執(zhí)行相同的操作，包括：

在虛擬機或容器啟動時分配端口。
將其“插入（plug）”虛擬機或容器。

接下來我描述一下每個編排器要做的事。

OpenStack

當與OpenStack一起使用時，neutron-plugin將成為OpenStack和Tungsten Fabric Controller之間的主要接口。

Neutron-plugin將直接加載到neutron-api進程中（某些模塊需要在neutron.conf中指定），并且該邏輯將執(zhí)行與Neutron的request/response相關的操作，例如network-list或port-create等等。

該模塊的一個特性是它不會使用在MySQL中創(chuàng)建（在典型的OpenStack設置中）的Neutron數(shù)據(jù)庫。

由于它直接使用Tungsten Fabric db，因此某些功能（例如到虛擬機的橋接分配）將難以實現(xiàn)。

據(jù)我所知，由于nova仍使用相同的vif分配邏輯，模擬Neutron響應來分配可用于Neutron的特定vif-type并非是不可能的，盡管不是所有組合全都經(jīng)過測試。
SR-IOV是一個例外，因為它的仿真得到很好的支持和測試。
https://github.com/Juniper/contrail-controller/wiki/SRIOV

當一個端口被分配了vrouter的vif-type時，將通過neutron-plugin由“create port”API自動完成該操作，它將為vRouter使用nova-vif-driver來將執(zhí)行一些任務，而不僅僅是在調(diào)用時創(chuàng)建一個tap設備，例如通過vrouter-port-control腳本在vRouter上創(chuàng)建vif等。（參見https://github.com/Juniper/contrail -nova-vif-driver）

在大多數(shù)情況下，你無需深入研究這些行為的細節(jié)。盡管在某些情況下（例如實時遷移在某處停止），你可能需要注意vif的狀態(tài)。

注意：Tungsten Fabric也有基于ml2的插件。

https://www.youtube.com/watch?v=4MkkMRR9U2s
https://opendev.org/x/networking-opencontrail

因此，如果用戶已經(jīng)在MySQL中使用ml2，那么可以首先將vRouter添加為ml2的network-type之一，在特定的虛擬網(wǎng)絡中使用它，然后通過detach和attach接口，從其它ml2插件遷移到vRouter。（如果所有遷移完成，則可以選擇替換Neutron核心插件。）

此外，還添加了一些安裝的詳細信息。

https://github.com/tnaganawa/tungstenfabric-docs/blob/master/TungstenFabricKnowledgeBase.md#vrouter-ml2-plugin

Kubernetes

當與Kubernetes一起使用時，其行為類似于OpenStack的情況，盡管它使用nova-vif-driver的CNI，以及使用neutron-api的kube-manager。

https://github.com/Juniper/contrail-controller/tree/master/src/container/cni

https://github.com/Juniper/contrail-controller/tree/master/src/container/kube-manager

在創(chuàng)建容器時，kube-manager將在Tungsten Fabric控制器中創(chuàng)建一個端口，而cni會將端口分配給該容器。

vCenter

由于無法將模塊直接安裝在ESXi上，因此vCenter與Tungsten Fabric的集成和kvm采取的方法有所不同。

首先，要在ESXi之間實現(xiàn)overlay可用，需要在每個ESXi上創(chuàng)建一個vRouter VM（內(nèi)部是一個簡單的CentOS vm）。

在ESXi上創(chuàng)建虛擬機時，將會附加到由vcenter-plugin（參見 https://github.com/Juniper/contrail-vcenter-plugin ）創(chuàng)建的dv-portgroup上。當在“vCenter”租戶中創(chuàng)建虛擬網(wǎng)絡時，通過ESXi的ip/user/pass安裝在每個vRouter VM上的vcenter-manager（參見 https://github.com/Juniper/contrail-vcenter-manager ），將要完成兩件事：

為VM連接的dv-portgroup端口設置一個vlan-id。
在具有接口（vlan）的vRouter VM上創(chuàng)建一個vif，該接口具有與該dv-portgroup端口以及該虛擬網(wǎng)絡的VRF相同的vlan-id。

這樣，當虛擬機發(fā)送流量時，先進入dvswitch并進行標記，然后到達vRouter VM，接著取消標記，再進入該虛擬機所屬的特定的VRF。

由于來自每個虛擬機的流量將使用不同的vlan-id進行標記，因此微分段（micro-segmentation）也得以實現(xiàn)。

在流量進入vRouter VM后，其行為就與kvm的情況一樣了。

請注意，只有當虛擬機附加到Tungsten Fabric控制器創(chuàng)建的dv-portgroups時，這些行為才會被觸發(fā)，因此虛擬機的接口仍可以分配給某些vSS或vDS，以使用underlay訪問。

甚至可以將vCenter和Tungsten Fabric控制器安裝到帶有vRouter的同一個ESXi上（如果已分配給“VM Network”，而不是由Tungsten Fabric控制器創(chuàng)建的dv-portgroup）。

由于vRouter的行為與其它情況相同，因此在vCenter和OpenStack之間共享虛擬網(wǎng)絡，或它們之間的路由泄漏（route leak）也變得很容易獲得。因此，借助Tungsten Fabric，通過共享網(wǎng)絡和網(wǎng)絡服務（例如fw、lb等），同時使用兩個VMI，就變得容易得多。

Tungsten Fabric入門寶典系列文章——

1. 首次啟動和運行指南

2. TF組件的七種“武器”

Tungsten Fabric 架構(gòu)解析 系列文章——

第一篇： TF主要特點和用例
第二篇： TF怎么運作
第三篇：詳解vRouter體系結(jié)構(gòu)
第四篇： TF的服務鏈
第五篇： vRouter的部署選項
第六篇： TF如何收集、分析、部署？
第七篇： TF如何編排
第八篇： TF支持API一覽
第九篇： TF如何連接到物理網(wǎng)絡
第十篇： TF基于應用程序的安全策略

Tungsten Fabric入門寶典丨編排器集成