Tungsten Fabric入門寶典系列文章
，來自技術大牛傾囊相授的實踐經驗，由TF中文社區為您編譯呈現，旨在幫助新手深入理解TF的運行、安裝、集成、調試等全流程。如果您有相關經驗或疑問，歡迎與我們互動，并與社區極客們進一步交流。更多TF技術文章，請點擊公號底部按鈕＞學習＞文章合集。
作者：Tatsuya Naganawa 譯者：TF編譯組
Tungsten Fabric中有很多不同的組件。接下來我簡要描述它們的用法。
總體而言，Tungsten Fabric中包含7種角色和（多達）30個微服務，其中角色部分如下：
盡管組件很多，但在簡單的用例中，只需要4種角色：vRouter，control，config，config-database。當然在大多數情況下，webui也是需要的。
如果你只對Tungsten Fabric的控制平面/數據平面部分感興趣，也可以省略analytics。只是在這種情況下，某些功能（如v1服務鏈，haproxy負載均衡器及k8s ingress，SNAT等）將無法正常工作。
Control和vRouter構成了Tungsten Fabric的控制平面和數據平面，因此可以說，這是Tungsten Fabric系統最重要的部分。
由于control和vRouter都在內部使用MPLS-VPN，因此我建議至少在深入研究它們的細節之前，先略讀一下這些材料：
-
https://www.juniper.net/uk/en/training/certification/certification-tracks/sp-routing-switching-track?tab=jncis-sp
-
https://www.juniper.net/uk/en/training/certification/certification-tracks/sp-routing-switching-track?tab=jncip-sp
由于大多數高級功能都在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-api為Tungsten Fabric的配置提供了一個API端點，該端點使用了許多組件，例如control、analytics等。
其中，schema-transformer和svc-monitor這兩個進程做的事情都很重要，所以讓我對其進行詳細描述。
這個進程將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收到的所有前綴的有趣處理，并且我個人認為值得一讀。
注意：你可以在書中獲得所有詳細信息。
https://mplsinthesdnera.net/
這個進程提供了一些服務，這些服務必須在內部使用外部進程，例如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的原因之一。
Tungsten Fabric使用多個數據庫。大部分數據都保存在Cassandra中，如果發生了更改，將通知RabbitMQ更改的內容以傳遞到其它組件，例如control、schema-transformer、svc-monitor等。
ZooKeeper僅用于需要鎖定以保持一致性的操作。例如，創建一個端口需要分配一個IP地址，其一致性由ZooKeeper來管理，因此IP地址分配始終是一對一的。
我認為到目前為止，大多數重要組件都已涵蓋，因此我將介紹其它部分。首先來看一下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功能，該模塊也必須存在，至少在第一次啟動節點時。
此過程用于配置physical-router（基于config-database中的對象）。
在內部，它使用與schema-transformer和svc-monitor相同的邏輯，它們訂閱RabbitMQ以查看config是否被更改，當發生更改時，AMQP客戶端會啟動一些邏輯：
-
對于schema-transformer，它將更新更多config；
-
對于svc-monitor，它將在vRouters中添加一些邏輯；
-
對于device-manager，它將更新physical-router的配置。
此行為由reaction_map控制，它定義了某些config對象上的某些更改會怎樣傳遞到其它的配置上進行更改。
基于“self”的定義，它將通過對原始bgp-router對象的引用，傳遞到bgp-router和physical-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。
要啟用此功能，需要在/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
Tungsten Fabric analytics具有很多功能，但大部分功能都是可選的，因此我會跳過大多數的組件。如果有興趣，請查閱以下鏈接以獲取SNMP、LLDP、警報等的信息：
-
https://tungsten.io/sandesh-a-sdn-analytics-interface/
-
https://tungsten.io/operational-state-in-the-opencontrail-system-uve-user-visible-entities-through-analytics-api/
-
https://tungsten.io/contrail-alerts/
-
https://tungsten.io/overlay-to-physical-network-correlation/
Analytics本身具有有趣的架構，其中涵蓋了logs、flows和stats。
如果你需要一個工具，方便地使用所有系統，Tungsten Fabric analytics將是一個很好的選擇。
大多數重要的指標和分析服務都被標記為UVE（用戶可見實體），并具有一個URL以提供JSON格式的數據。
如果你需要將Tungsten Fabric與其它監視系統集成在一起，那可能是一個很好的起點。
Analytics還使用了多個數據庫，例如Redis、Cassandra、Kafka（在內部，它還使用ZooKeeper進行HA選件的部署）。
如果僅使用analytics，則僅需要Redis數據庫，即使在此設置中，大多數webui功能都是可用的。
如果你需要webui的“Query”功能，則需要使用Cassandra，該功能可檢索Cassndra數據庫中的logs/flows或stats信息。
Kafka用于將UVE傳遞到analytics-alarms，因此，如果要使用警報功能，Kafka是必要的。
最后，我們來說說webui。基本上，這就只是一個簡單的webui，用于查看組件的狀態，并配置Tungsten Fabric的參數。
它使用AJAX行為來更新一些需要對analytics-api進行長時間查詢的圖形（例如Monitor > Dashboard access），同時由webui-job進程涵蓋了異步作業，這一點還挺有趣的。
Tungsten Fabric入門寶典系列文章——
Tungsten Fabric 架構解析
系列文章——
-
第一篇：
TF主要特點和用例
-
第二篇：
TF怎么運作
-
第三篇：詳解vRouter體系結構
-
第四篇：
TF的服務鏈
-
第五篇：
vRouter的部署選項
-
第六篇：
TF如何收集、分析、部署？
-
第七篇：
TF如何編排
-
第八篇：
TF支持API一覽
-
第九篇：
TF如何連接到物理網絡
-
第十篇：
TF基于應用程序的安全策略
