Shulou(Shulou.com)06/02 Report--

Tungsten Fabric architecture analysis series of articles, presented by TF Chinese community for you, aims to help new TF community friends answer questions. We will systematically introduce TF features, how it works, how it is collected/analyzed/deployed, how it is orchestrated, how it connects to physical networks, etc.

Collection and analysis of Tungsten Fabric

Tungsten Fabric collects information from cloud infrastructure (compute, network, and storage) and the workloads running on it for operational monitoring, troubleshooting, and capacity planning.

Data is collected in a variety of formats, such as system logs, structured messages (called Sandesh), IPfix, Sflow, and SNMP. Objects such as vRouters, physical hosts, virtual machines, interfaces, virtual networks, and policies are modeled as user-visible entities (UVE), and attributes of a UVE can come from a variety of sources in different formats.

The architecture of the analysis collection is shown in the following figure:

The IP address of the target collector can be configured for the data source, or the Load Balancer configured for the collector. The responsibility for SNMP polling is distributed among different nodes by Zookeeper.

The analytics node formats incoming data into a common data format and sends it to the Cassandra database via the Kafka service.

API URLs can be load balanced using ha-proxy or some other Load Balancer.

Responsibility for collecting UVE data is distributed among Analytics nodes using Zookeeper, so API queries for UVE data are copied by the receiving node to other Analytics nodes, and those queries that save data related to the request return responses to the original node, which collates the responses and sorts them into the reply the requester will receive.

Responsibility for alert generation is also distributed among nodes, so alert generation subscribes to the Kafka bus in the Analyticsdb node to observe the data needed to calculate whether alert conditions are met, as this data may be collected by other nodes.

The UVE is hashed in multiple Kafka topics, which are distributed across the Alarm Gen function to effectively spread the load.

Tungsten Fabric

The latest versions of Tungsten Fabric (5.0 and later) use a Docker container-based microservices architecture. Microservices are grouped into pods, which are assigned to servers during deployment based on roles.

The relationship between microservices and pods is shown below:

The architecture is composable, meaning that each Tungsten Fabric role can be individually extended with multiple pods running on different servers to support the resiliency and performance requirements of a particular deployment.

Due to the nature of the algorithm used to select active nodes in Zookeeper, the number of pods deployed in Controller and Analytic nodes must be odd, but may vary between pod types.

Nodes are logical groupings whose pods can be deployed on different servers that can run pods from different node types.

API and Web GUI services can be accessed through a Load Balancer deployed during Contrail installation or a third-party Load Balancer. Using a third-party Load Balancer allows pods to be in different subnets, a common situation that requires pods to be placed in different racks in the data center for resiliency.

The Control pod can increase or decrease depending on the number of compute nodes in the cluster, up to 1000 nodes per control node. Additions of control nodes may be deployed in certain use cases where the controller node may remotely deploy the management compute node.

The number of compute nodes is adjusted based on the expected workload requirements deployed by the orchestrator. Within the compute node, the forwarder functionality is not implemented in containers (see Part 5 of this series,"Deployment Options for vRouter").

The layout of Tungsten Fabric services across servers, controlled by profiles read by deployment tools, can be Ansible (using playbooks) or Helm (using diagrams). Sample manuals and diagrams can be used to cover simple all-in-one deployments where all services run in the same VM, as well as high availability examples involving multiple VMs or bare metal servers. Also provided are examples where orchestrator and Tungsten Fabric run in public clouds (e.g. Amazon Web Services, Google Cloud Engine, Microsoft Azure) and workloads run there as well.

More details about deployment tools and how to use them

Visit Tungsten Fabric website (www.tungsten.io)

Chinese website (www.tungstenfabric.org.cn)

More Tungsten Fabric Analysis Articles

Part 1: TF Main Features and Use Cases

Part 2: How TF Works

Part 3: Detailed explanation of vRouter architecture

Part 4: TF's Service Chain

Part 5: Deployment Options for vRouter

Follow WeChat: TF Chinese Community

Email: tfzw001@163.com

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.