Tungsten Fabric入門寶典丨編排器整合

TF中文社群發表於2020-04-10
Tungsten Fabric入門寶典系列文章 ，來自技術大牛傾囊相授的實踐經驗，由TF中文社群為您編譯呈現，旨在幫助新手深入理解TF的執行、安裝、整合、除錯等全流程。如果您有相關經驗或疑問，歡迎與我們互動，並與社群極客們進一步交流。更多TF技術文章，請點選公號底部按鈕＞學習＞文章合集。

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


Tungsten Fabric已經實現了多個編排器的整合。

在內部，Tungsten Fabric的編排器整合元件基本上對每個編排器都執行相同的操作，包括：

  1. 在虛擬機器或容器啟動時分配埠。

  2. 將其“插入（plug）”虛擬機器或容器。


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


OpenStack

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

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

該模組的一個特性是它不會使用在MySQL中建立（在典型的OpenStack設定中）的Neutron資料庫。

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

  • 據我所知，由於nova仍使用相同的vif分配邏輯，模擬Neutron響應來分配可用於Neutron的特定vif-type並非是不可能的，儘管不是所有組合全都經過測試。

  • SR-IOV是一個例外，因為它的模擬得到很好的支援和測試。


當一個埠被分配了vrouter的vif-type時，將透過neutron-plugin由“create port”API自動完成該操作，它將為vRouter使用nova-vif-driver來將執行一些任務，而不僅僅是在呼叫時建立一個tap裝置，例如透過vrouter-port-control指令碼在vRouter上建立vif等。（參見 -nova-vif-driver）

  • 在大多數情況下，你無需深入研究這些行為的細節。儘管在某些情況下（例如實時遷移在某處停止），你可能需要注意vif的狀態。


注意：Tungsten Fabric也有基於ml2的外掛。

  • https://opendev.org/x/networking-opencontrail


因此，如果使用者已經在MySQL中使用ml2，那麼可以首先將vRouter新增為ml2的network-type之一，在特定的虛擬網路中使用它，然後透過detach和attach介面，從其它ml2外掛遷移到vRouter。（如果所有遷移完成，則可以選擇替換Neutron核心外掛。）

此外，還新增了一些安裝的詳細資訊。


Kubernetes

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

  • -controller/tree/master/src/container/cni


  • -controller/tree/master/src/container/kube-manager


在建立容器時，kube-manager將在Tungsten Fabric控制器中建立一個埠，而cni會將埠分配給該容器。

vCenter

由於無法將模組直接安裝在ESXi上，因此vCenter與Tungsten Fabric的整合和kvm採取的方法有所不同。

首先，要在ESXi之間實現overlay可用，需要在每個ESXi上建立一個vRouter VM（內部是一個簡單的CentOS vm）。

在ESXi上建立虛擬機器時，將會附加到由vcenter-plugin（參見 -vcenter-plugin ）建立的dv-portgroup上。當在“vCenter”租戶中建立虛擬網路時，透過ESXi的ip/user/pass安裝在每個vRouter VM上的vcenter-manager（參見 -vcenter-manager ），將要完成兩件事：

  1. 為VM連線的dv-portgroup埠設定一個vlan-id。

  2. 在具有介面（vlan）的vRouter VM上建立一個vif，該介面具有與該dv-portgroup埠以及該虛擬網路的VRF相同的vlan-id。


這樣，當虛擬機器傳送流量時，先進入dvswitch並進行標記，然後到達vRouter VM，接著取消標記，再進入該虛擬機器所屬的特定的VRF。

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


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

請注意，只有當虛擬機器附加到Tungsten Fabric控制器建立的dv-portgroups時，這些行為才會被觸發，因此虛擬機器的介面仍可以分配給某些vSS或vDS，以使用underlay訪問。

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


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


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

1. 首次啟動和執行指南

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

  Tungsten Fabric 架構解析 系列文章——



來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69957171/viewspace-2685506/，如需轉載，請註明出處，否則將追究法律責任。

相關文章