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

TF中文社群發表於2020-04-03

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 架構解析 系列文章——



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

相關文章