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

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

Tungsten Fabric中有很多不同的元件。接下來我簡要描述它們的用法。

概覽

總體而言，Tungsten Fabric中包含7種角色和（多達）30個微服務，其中角色部分如下：

vRouter
control
config
config-database
analytics（從TF 5.1開始，可被進一步分為analytics、analytics-snmp和analytics-alarm）
analytics-database
webui

儘管元件很多，但在簡單的用例中，只需要4種角色：vRouter，control，config，config-database。當然在大多數情況下，webui也是需要的。

如果你只對Tungsten Fabric的控制平面/資料平面部分感興趣，也可以省略analytics。只是在這種情況下，某些功能（如v1服務鏈，haproxy負載均衡器及k8s ingress，SNAT等）將無法正常工作。

control, vRouter

Control和vRouter構成了Tungsten Fabric的控制平面和資料平面，因此可以說，這是Tungsten Fabric系統最重要的部分。

由於control和vRouter都在內部使用MPLS-VPN，因此我建議至少在深入研究它們的細節之前，先略讀一下這些材料：

由於大多數高階功能都在control當中，而vRouter是MPLS所固有的，因此這些資料將有助於弄清它們正在嘗試做些什麼。

由於control和vrouter-agent都在內部使用VPNV4 BGP，因此vRouter及其內部VRF將根據extended community屬性（也稱為路由目標route-target）裝載所需的字首。因此，在vRouter上建立容器或虛擬機器時，它可以將VPNV4路由的訊號傳送給control，並將所有路由對映到其它的vRouter，從而資料平面可以知道自動將報文傳送到何處。

有趣的是，vRouter的虛擬網路可能具有多個預設閘道器，並且具有相同的IP和相同的MAC！（用Junos的術語來說，與virtual-gateway-address的行為類似。）

由於不需要VRRP來為每個虛擬網路提供預設閘道器，因此它消除了瓶頸，並使一切變得完全分散式。

vRouter還可以為某些功能（例如基於狀態的防火牆、NAT、基於流的ECMP等）進行基於流的處理。這是一個重要的區別，因為這種行為會引入一些調整點，例如每秒的連線數和最大流數。（在基於包的系統中，PPS（每秒資料包）和吞吐量（以及某些情況下的延遲）是關鍵。）如果這些引數對你的系統非常重要，也許你還需要檢查這些引數。

注意：可以選擇在“ports”配置中使用“packet-mode”引數禁用此行為。

config

Config同樣包含幾個元件。Config-api為Tungsten Fabric的配置提供了一個API端點，該端點使用了許多元件，例如control、analytics等。

vRouter不會直接使用它，因為只有需要的資料才會（透過XMPP）由control傳遞。

其中，schema-transformer和svc-monitor這兩個程式做的事情都很重要，所以讓我對其進行詳細描述。

schema-transformer

這個程式將logical-router、network-policy、service-chain等一些抽象的config引數轉換為L3 VPN的語言。它是Tungsten Fabric的核心元件之一，完成了MPLS-VPN不能簡單解釋的大部分工作。

例如，logical-router在內部建立一個新的route-target ID，該ID將具有虛擬網路的所有字首。因此，如果將虛擬網路連線到logical-router，它將接收logical-router所具有的所有路由。該行為在內部使用MPLS-VPN，但route-target配置由schema-transformer控制。

因此，配置以下面的方式傳送到資料平面：


edit config -> (rabbitmq) -> schema-transformer, which creates 
new route-target -> (internally edit config) -> (rabbitmq) -> control -> (xmpp) -> vrouter-agent -> (netlink) -> vrouter.ko

Schema-transformer還負責與服務鏈（service-chain）相關的所有事情。我不會深入研究服務鏈的所有細節，因為這並沒有簡單的DC用例（即使AWS VPC當前也不提供類似的服務）。儘管，從內心來說，這是對VRF收到的所有字首的有趣處理，並且我個人認為值得一讀。

注意：你可以在書中獲得所有詳細資訊。

svc-monitor

這個程式提供了一些服務，這些服務必須在內部使用外部程式，例如haproxy負載均衡器，基於nova API的v1服務鏈例項，用於SNAT的iptables MASQUERADE等。

在內部，vrouter-agent具有一些邏輯來啟動haproxy或設定iptables MASQUERADE，當相關服務被定義的時候，svc-monitor將啟動這些邏輯。

Svc-monitor選擇一些vRouter來建立這些服務，例項化一些網路功能並對這些元素進行流量處理。在使用analytics-api的輸出（analytics/uves/vrouter）中選擇一個，然後選點選“Functional”。

儘管將來的版本可能會改變，但是目前這樣的行為是Tungsten Fabric安裝時需要analytics的原因之一。

config-database

Tungsten Fabric使用多個資料庫。大部分資料都儲存在Cassandra中，如果發生了更改，將通知RabbitMQ更改的內容以傳遞到其它元件，例如control、schema-transformer、svc-monitor等。

ZooKeeper僅用於需要鎖定以保持一致性的操作。例如，建立一個埠需要分配一個IP地址，其一致性由ZooKeeper來管理，因此IP地址分配始終是一對一的。

nodemgr

我認為到目前為止，大多數重要元件都已涵蓋，因此我將介紹其它部分。首先來看一下nodemgr是什麼。

Nodemgr基本上是每個節點狀態的源頭，因此它檢查使用情況、docker ps或CPU的使用情況，併傳送analytics UVE NodeStatus。

該值可能是contrail-status以及其它邏輯（例如analytics-alarm或svc-monitor）的來源，它們在選擇vRouter時會檢查此值是否為Functional。保持這些Functional的狀態，對確保Tungsten Fabric正常執行非常重要。

如果分配了不同的角色，則此元件的行為會有所不同。因此，它會以不同的行為安裝在每個節點上。

另外，它還會對每個節點進行第一次配置（provision），這意味著要通知config-api該IP已分配了xxx角色。因此，即使不需要analytics功能，該模組也必須存在，至少在第一次啟動節點時。

device-manager

此過程用於配置physical-router（基於config-database中的物件）。

在內部，它使用與schema-transformer和svc-monitor相同的邏輯，它們訂閱RabbitMQ以檢視config是否被更改，當發生更改時，AMQP客戶端會啟動一些邏輯：

對於schema-transformer，它將更新更多config；
對於svc-monitor，它將在vRouters中新增一些邏輯；
對於device-manager，它將更新physical-router的配置。

此行為由reaction_map控制，它定義了某些config物件上的某些更改會怎樣傳遞到其它的配置上進行更改。

https://github.com/Juniper/contrail-controller/blob/master/src/config/device-manager/device_manager/device_manager.py#L59

例如，當更新bgp-router時，

基於“self”的定義，它將透過對原始bgp-router物件的引用，傳遞到bgp-router和physical-router。

對於bgp-router，表示與原始bgp-router所對等（peer）的bgp-router物件

之後，更新的bgp-router會將其傳遞到bgp-router物件所在的physical-router。

由於從bgp-router傳遞事件時，physical-router不會更新任何內容，因此事件在那裡停止，並且具有原始bgp-router的physical-router config以及對等（peer）的bgp-router將被更新。

當physical-router收到更新的事件時，它將從外掛中呼叫push_conf函式，基於config-database中的物件建立路由config。

當前，只有MX/QFX具有開源外掛： https://github.com/Juniper/contrail-controller/tree/master/src/config/device-manager/device_manager/plugins/juniper

要啟用此功能，需要在/etc/contrail/common_config.env中配置此旋鈕：DEVICE_MANAGER__DEFAULTS__push_mode = 0。

以下連結描述了配置過程：

https://www.juniper.net/documentation/en_US/contrail5.0/topics/concept/using-device-manager-netconf-contrail.html

analytics

Tungsten Fabric analytics具有很多功能，但大部分功能都是可選的，因此我會跳過大多數的元件。如果有興趣，請查閱以下連結以獲取SNMP、LLDP、警報等的資訊：

Analytics本身具有有趣的架構，其中涵蓋了logs、flows和stats。

據我所知，它們通常涉及不同的系統，例如用於logs/flows的EFK和用於stats的Prometheus。

如果你需要一個工具，方便地使用所有系統，Tungsten Fabric analytics將是一個很好的選擇。

大多數重要的指標和分析服務都被標記為UVE（使用者可見實體），並具有一個URL以提供JSON格式的資料。

http://(analytics-ip):8081/analytics/uves 提供了所有可提供的數值。

如果你需要將Tungsten Fabric與其它監視系統整合在一起，那可能是一個很好的起點。

analytics-database

Analytics還使用了多個資料庫，例如Redis、Cassandra、Kafka（在內部，它還使用ZooKeeper進行HA選件的部署）。

如果僅使用analytics，則僅需要Redis資料庫，即使在此設定中，大多數webui功能都是可用的。

大多數視覺化的功能都使用UVE，因此即使未安裝Cassandra也是可用的。

如果你需要webui的“Query”功能，則需要使用Cassandra，該功能可檢索Cassndra資料庫中的logs/flows或stats資訊。

Kafka用於將UVE傳遞到analytics-alarms，因此，如果要使用警報功能，Kafka是必要的。

webui

最後，我們來說說webui。基本上，這就只是一個簡單的webui，用於檢視元件的狀態，並配置Tungsten Fabric的引數。

它使用AJAX行為來更新一些需要對analytics-api進行長時間查詢的圖形（例如Monitor > Dashboard access），同時由webui-job程式涵蓋了非同步作業，這一點還挺有趣的。

·END·

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

1.首次啟動和執行指南

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

Tungsten Fabric入門寶典丨TF元件的七種“武器”

相關文章