Tungsten Fabric架构解析丨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）中运行，并且工作负载也在那里运行。

有关部署工具及其使用方法的更多详细信息

第五篇： vRouter的部署选项