Tungsten Fabric架构解析系列文章，由TF中文社区为你呈现，旨在帮助初入TF社区的朋友答疑解惑。我们将系统介绍TF有哪些特点、如何运作、如何收集/分析/部署、如何编排、如何连接到物理网络等话题。
Tungsten Fabric的收集和分析
Tungsten Fabric从云基础架构（计算、网络和存储）及其上运行的工作负载收集信息，以便于运营监控、故障排除和容量规划。
成都创新互联主营莲湖网站建设的网络公司,主营网站建设方案,手机APP定制开发,莲湖h5小程序开发搭建,莲湖网站营销推广欢迎莲湖等地区企业咨询
数据以多种格式收集，例如系统日志，结构化消息（称为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网站 (
www.tungsten.io)
中文网站（
www.tungstenfabric.org.cn）
更多Tungsten Fabric解析文章
第二篇：
TF怎么运作
第三篇：详解vRouter体系结构
第四篇：
TF的服务链
第五篇：
vRouter的部署选项
关注微信：TF中文社区
邮箱：tfzw001@163.com
