TungstenFabric入门宝典丨TF组件的七种“武器”

Tungsten Fabric入门宝典系列文章 ，来自技术大牛倾囊相授的实践经验，由TF中文社区为您编译呈现，旨在帮助新手深入理解TF的运行、安装、集成、调试等全流程。如果您有相关经验或疑问，欢迎与我们互动，并与社区极客们进一步交流。更多TF技术文章，请点击公号底部按钮＞学习＞文章合集。

我们提供的服务有：网站设计、网站制作、微信公众号开发、网站优化、网站认证、文县ssl等。为上千企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的文县网站制作公司

作者：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，因此我建议至少在深入研究它们的细节之前，先略读一下这些材料：

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同样包含几个组件。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收到的所有前缀的有趣处理，并且我个人认为值得一读。

注意：你可以在书中获得所有详细信息。 https://mplsinthesdnera.net/

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”。

https://github.com/Juniper/contrail-controller/blob/master/src/config/svc-monitor/svc_monitor/scheduler/vrouter_scheduler.py#L149

尽管将来的版本可能会改变，但是目前这样的行为是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。

https://github.com/Juniper/contrail-controller/blob/master/src/nodemgr/common/linux_sys_data.py

该值可能是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时，

Tungsten Fabric入门宝典丨TF组件的七种“武器”

基于“self”的定义，它将通过对原始bgp-router对象的引用，传递到bgp-router和physical-router。

对于bgp-router，表示与原始bgp-router所对等（peer）的bgp-router对象

之后，更新的bgp-router会将其传递到bgp-router对象所在的physical-router。

Tungsten Fabric入门宝典丨TF组件的七种“武器”

由于从bgp-router传递事件时，physical-router不会更新任何内容，因此事件在那里停止，并且具有原始bgp-router的physical-router config以及对等（peer）的bgp-router将被更新。

Tungsten Fabric入门宝典丨TF组件的七种“武器”

当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、警报等的信息：

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。

据我所知，它们通常涉及不同的系统，例如用于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 架构解析 系列文章——

第一篇： TF主要特点和用例
第二篇： TF怎么运作
第三篇：详解vRouter体系结构
第四篇： TF的服务链
第五篇： vRouter的部署选项
第六篇： TF如何收集、分析、部署？
第七篇： TF如何编排
第八篇： TF支持API一览
第九篇： TF如何连接到物理网络
第十篇： TF基于应用程序的安全策略

Tungsten Fabric入门宝典丨TF组件的七种“武器”

重庆分公司，新征程启航

TungstenFabric入门宝典丨TF组件的七种“武器”

其他资讯