Hi！這裡是Tungsten Fabric架構解析內容的第六篇，介紹TF的收集和分析，以及部署。

Tungsten Fabric架構解析系列文章，由TF中文社群為你呈現，旨在幫助初入TF社群的朋友答疑解惑。我們將系統介紹TF有哪些特點、如何運作、如何收集/分析/部署、如何編排、如何連線到物理網路等話題。

Tungsten Fabric的收集和分析

Tungsten Fabric從雲基礎架構（計算、網路和儲存）及其上執行的工作負載收集資訊，以便於運營監控、故障排除和容量規劃。

資料以多種格式收集，例如系統日誌，結構化訊息（稱為Sandesh）、Ipfix、Sflow和SNMP。諸如vRouters、物理主機、虛擬機器、介面、虛擬網路和策略之類的物件被建模為使用者可見實體（UVE），並且UVE的屬性可以來自不同格式的各種源。

分析收集的體系結構如下圖所示：

為資料來源可以配置目標收集器的IP地址，或者為收集器配置的負載均衡器。SNMP輪詢的責任由Zookeeper分佈在不同的節點上。

分析節點將傳入的資料格式化為通用資料格式，然後透過Kafka服務將其傳送到Cassandra資料庫。

API URL可以使用ha-proxy或其他一些負載均衡器進行負載平衡。

收集UVE資料的責任使用Zookeeper在Analytics節點之間分配，因此UVE資料的API查詢由接收節點複製到其他Analytics節點，並且儲存與請求相關的資料的那些查詢，將響應返回到原始節點，該節點將核對響應，並整理到請求者將要接收的回覆中。

警報生成的責任也分佈在節點之間，因此警報生成功能訂閱Analyticsdb節點中的Kafka匯流排，以便觀察計算是否滿足警報條件所需的資料，因為此資料可能由其他節點收集。

UVE在多個Kafka主題中進行了雜湊，這些主題分佈在Alarm Gen功能中，以便有效地分散負載。

Tungsten Fabric的部署

最新版本的Tungsten Fabric（5.0及更高版本）使用基於Docker容器的微服務架構。微服務被分組到pod中，這些pod根據角色在部署期間分配給伺服器。

微服務與pod的關係如下圖所示：

該體系結構是可組合的，這意味著可以使用在不同伺服器上執行的多個pod單獨擴充套件每個Tungsten Fabric角色，以支援特定部署的彈性和效能要求。

由於Zookeeper中用於選擇活動節點的演算法的性質，在Controller和Analytic節點中部署的pod的數量必須是奇數，但是在pod型別之間可能會有所不同。

節點是邏輯分組，其pod可以部署在不同的伺服器上，伺服器可以執行來自不同節點型別的pod。

可以透過在Contrail安裝期間部署的負載均衡器或第三方負載均衡器來訪問API和Web GUI服務。使用第三方負載均衡器可以允許pod位於不同的子網中，這是一種常見情況，需要將pod放置在資料中心的不同機架中以實現彈性。

Control pod可以根據群集中的計算節點數量進行增減，每個控制節點最多有1000個節點。可以在特定使用情況下部署增加控制節點，其中控制器節點可以遠端地部署管理計算節點。

計算節點的數量根據預期，由編排器部署的工作負載的需求進行調整。在計算節點內，轉發器功能未在容器裡實現（請參閱本系列文章第五篇“ vRouter的部署選項”）。

跨伺服器的Tungsten Fabric服務的佈局，由部署工具讀取的配置檔案控制，可以是Ansible（使用playbooks）或Helm（使用圖表）。示例手冊和圖表可用於涵蓋所有服務在同一VM中執行的簡單一體化部署，以及涉及多個VM或裸機伺服器的高可用性示例。同時提供了示例，orchestrator和Tungsten Fabric在公有云（例如Amazon Web Services，Google Cloud Engine，Microsoft Azure）中執行，並且工作負載也在那裡執行。

有關部署工具及其使用方法的更多詳細資訊

請訪問Tungsten Fabric網站 (

中文網站（

更多Tungsten Fabric解析文章

關注微信：TF中文社群
郵箱：tfzw001@163.com