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

This article is based on the speech given by Sukhdev Kapur, an outstanding engineer of Juniper Network, on "the Establishment of TF Chinese Community and the first full meeting". The description of the function of TF is added. Pdf click to download. For more information about https://tungstenfabric.org.cn/assets/uploads/files/powering-edge-cloud-and-multi-cloud-with-tungsten-fabric-sukhdev-kapur.pdf, please reply to "Inaugural meeting" on the official account of "TF Chinese Community".

Sukhdev Kapur, Outstanding engineer of Juniper Network

Hello everyone, my name is SukhdevKapur, from the Tungsten Fabric (hereinafter referred to as TF) Community Technical steering Committee, now I would like to introduce to you the current situation of TF architecture and technology, as well as the latest progress.

TF Architecture and deployment Model

We can take a look at this macro architecture diagram of TF. The overall picture describes the physical connection of devices, while there are logical networks between virtual machines in the upper right corner. The basic working principle and mechanism of TF is that you create VM or POD, and then (through SDN) put them into these logical networks.

In these logical networks, you can place any virtual machine, PODS, or bare server according to your business needs, it doesn't matter where they are physically located, they may be in a cluster or in a rack, it doesn't matter.

Let's take a look at the bottom part of it. TF will use a virtual router (on the computing node) to forward these virtual workloads, while on the left is a connection to a physical network, such as a bare metal physical network. Once you have defined the network, it may connect to the actual network, or it may connect to the virtual machine in the logical network on the right.

The fourth part (the first part) is CONTRAILController (SDN controller), which is used for configuration control analysis and CSN.

The fifth part is the function of the gateway, which may be a physical gateway or a virtual gateway. When the virtual machines of the data center need to be interconnected, they enter and leave the backbone network through the networking of IP, that is, the protocol of MPLS.

All of this is managed through an ORCHESTRATOR choreographer, which may be OpenStack, K8s, or OpenShift, which schedules TF to work through API.

An Overview of the Architecture of Vrouter in TF

This picture shows the architecture of TF's routing vRouter, and in the upper left corner is the Agent of vRouter, mainly the control part, where it will learn routes, define VRFs, and define policies. If a virtual router wants to execute policies, it must be controlled by Agent: it determines whether network traffic is allowed or denied, and where it should be forwarded if allowed.

As you can see, vRouter has a forwarding path, the learning path is encapsulated, and then layer 2 or layer 3 data traffic is forwarded.

The deployment model of vRouter

These are the four deployment modes of the TF virtual router, and the default mode in the upper left corner is the vRouter deployment in the kernel.

What about the upper right corner? If you are in a high throughput, high traffic state, the network supports DPPK, TF can have the deployment of DPDKvRouter.

The lower left corner is actually a mixed deployment mode. If you have several virtual network functions of VNF and can use SR-IOV, you can use the mixed mode of coexistence of SR-IOV and kernel vRouter.

The fourth is SmartNIC-based vRouter, that is, these VM can make full use of the power of all processors.

Integration of TF and Kubernetes

Let's take a look at the integration of TF and Kubernetes (hereinafter referred to as K8s). First of all, TF's CONTRAIL Controller will communicate with K8s through API, so how does it get the IP address and policy at a given location? First of all, K8s will communicate with the Scheduler of TF, that is, the scheduling management program, and then contact the CNI Plugin plug-in through the scheduling management program. In the upper left corner, it shows how vRouter obtains the policy on the K8s side to read and execute the IPAM. To put it simply, the manager of K8s will communicate with the CONTRAIL Controller of TF to determine the network policy, and then the Controller of TF will publish the policy to vRouter.

Micro-service architecture of TF

TF technology evolution, at first mainly based on virtual machine deployment, and then began to support container technology, has now evolved to a micro-service (Microservices) architecture. At present, our TF is deployed entirely in the way of containers, with about 27-30 image.

Network isolation in K8s Environment

K8s is a very flat network that allows arbitrary communication between tenants, as well as between workloads.

Based on such a scenario, we can achieve the isolation of tenants in the network through the implementation of network policies, that is, we can communicate only among users in a specified area.

So at the TF level, we take management a step forward, that is, within the space of a tenant, we can also decide which location and which location can communicate, that is, which POD communicates with which POD.

Unified policy management provided by TF

Here's a look at TF's unique strategy framework. Suppose we have an application that has three layers, namely, the Web layer, the application layer, and the database layer. The life cycle of this application will have three stages, namely, the development stage, the deployment preparation stage, and the final production stage.

Different phases may be deployed in different network environments, or even different cloud platforms, so at the top of the development phase, there will be some secure access policies between different layers (also the concept of tie), and this strategy may also be needed in the deployment preparation phase (the P2 policy in the figure) in the production phase, without the use of TF. It is very likely that there will be a duplicate strategy, but after using TF, we can use only one policy

What we have done is to simplify the management of the strategy, first of all, to reduce complexity, simplify management, and improve scalability. Once you have defined the strategy, you can reuse it on a large scale and scalable in a variety of environments, including public, private, and cloudy environments.

I'd like to introduce you to an actual policy framework use case.

Suppose we have an application and we allow its Web layer to communicate with the application layer, then whether in the development phase or in the production phase, we can use such a definition, such as the Web layer in the development phase, and the application layer in the production environment.

However, maybe we don't want this to happen, and we don't want a developer to be able to modify code in a production environment at will. At this point, you don't have to change the strategy, just add the App Match Deployment tag to the policy, which can specify-for example, communication can only be made in the Web layer and the application layer in the development phase.

Similarly, if your application is a geographically distributed application, you can define policies to communicate between the Web layer in geographic area An and the application layer in geographic area B.

If you don't want this cross-layer, cross-region communication to occur, add End Site after AppMatch Deployment. So you have to match this match, not only its deployment, but also its location.

Let's add one more layer, you see what our second strategy means, that is, as long as this site is on match and matched, then they can all be accessed with the database.

Such a strategy is very useful in management. If you have a very large financial application that is distributed across geographic regions, it may use multiple networks, and there are hundreds of applications on the network, and you only need one strategy at this time. You can manage the entire distributed financial application.

An interface for multi-cloud deployment

At the same time, TF can also automate the management of multi-cloud deployment. For example, we automatically create a gateway called multi-cloud gateway MC-GW here, which will establish a channel and automatically make a secure connection with the same deployment on the cloud (such as AWS).

It also depends on what kind of workload you deploy on the cloud. With this workload, you can manage it in a local cloud environment, while TF can give you a cloudy visibility.

You can see that if you do multi-cloud management yourself, you need to go through a lot of processes to achieve it. TF can easily manage multiple clouds with a single graphical user interface, and all you need to do is do a few clicks.

Service chain in cloudy environment

Let's take a look at TF's multi-cloud service chain. You can see that there are two networks on the top, 2.2.2.4 on the left and 3.3.3.5 on the right, and then there is an instance of the service, assuming that the service instance is a virtualized service of POD. Through the service chain of TF, you can transfer the workload from the network on the left to the right.

Similarly, if you want to deploy such a virtual network on different public clouds, you can build such a service chain from resident to multi-cloud through TF.

To sum up, all it takes is a SDN controller to manage connections-- whether it's bare metal, K8s CNI, OpenStack, or various edge sites on the left-- and provide very rich network capabilities.

Integration of TF and Akraino

TF has also made its own contribution in the environment of edge computing, which is another open source project. TF integrates with Akraino to support scenarios such as edge computing. It is purely based on K8s native infrastructure and is very suitable for lightweight applications such as industrial automation. Basically, the environment in which it is deployed is very small, and the target industries are mainly telecom operators and enterprise users.

This is another use case for the integration of Akraino and TF, mainly to build a telecom cloud, and AT&T, a US telecom operator, has made such an architectural deployment. The main thing here is to use the virtualization of SR-IOV, and what we do is to treat TF as a single SDN, and its deployment model includes all of the above types.

This is the third use case, which is a software stack called Weiyun, which is mainly used in mobile scenarios, such as mobile games, where the workload is mobile.

How do we do it here? First of all, we have a DME (distributed matching engine), which knows how many devices or mobile users are connected, and according to the number of mobile users, start Weiyun resource manager to transfer information; then Weiyun resource manager will match the corresponding resource; then CRM will communicate with TF controller to deploy this kind of resource Then go to the lower layer and contact the controller of TF through the forwarding layer of vRouter.

Integration of TF and OpenStack

Friends who are familiar with OpenStack know that it has two deployment modes, one is a single plug-in, and the other is ML2-based deployment.

TF has a special Networking Open Contrail that can launch TF as a plug-in to ML2. What's the advantage of doing this? We can run this work based on OVS, SR-IOV, and vRouter at the same time.

You can use OpenStack to run OVS, SR-IOV workloads, and use our TF to manage at the network level.

Learn more about Tungsten Fabric

Introduction to TF Chinese Community

Main features and use cases of TF

How does TF work?

Detailed explanation of vRouter architecture

Follow Wechat: TF Chinese Community

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.