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

Author: Tatsuya Naganawa translator: TF compilation Group

Tungsten Fabric has implemented the integration of multiple choreographers. Internally, the choreographer integration component of Tungsten Fabric basically does the same for each choreographer, including:

Assign ports when the virtual machine or container starts.

"plug" it into a virtual machine or container.

Next I'll describe what each choreographer does. OpenStack

When used with OpenStack, neutron-plugin becomes the primary interface between OpenStack and Tungsten Fabric Controller. Neutron-plugin will be loaded directly into the neutron-api process (some modules need to be specified in neutron.conf), and the logic will perform operations related to Neutron's request/response, such as network-list or port-create, and so on. One feature of this module is that it does not use Neutron databases created in MySQL (in typical OpenStack settings). Because it uses Tungsten Fabric db directly, some functions, such as bridging allocation to virtual machines, will be difficult to implement.

As far as I know, since nova still uses the same vif allocation logic, it is not impossible to simulate Neutron responses to allocate specific vif-type that can be used for Neutron, although not all combinations have been tested.

SR-IOV is an exception because its simulation is well supported and tested.

Https://github.com/Juniper/contrail-controller/wiki/SRIOV

When a port is assigned a vif-type of vrouter, the operation will be done automatically by the "create port" API through neutron-plugin, which will use nova-vif-driver for vRouter to perform some tasks, rather than just creating a tap device when invoked, such as creating a vif on vRouter through a vrouter-port-control script. (see https://github.com/Juniper/contrail-nova-vif-driver)

In most cases, you don't need to delve into the details of these behaviors. Although in some cases (for example, live migration stops somewhere), you may need to pay attention to the status of vif.

Note: Tungsten Fabric also has plug-ins based on ml2.

Https://www.youtube.com/watch?v=4MkkMRR9U2s

Https://opendev.org/x/networking-opencontrail

Therefore, if you are already using ml2 in MySQL, you can first add vRouter as one of the network-type of ml2, use it in a specific virtual network, and then migrate from other ml2 plug-ins to vRouter through the detach and attach interfaces. (if all migrations are complete, you can choose to replace the Neutron core plug-in. In addition, some installation details have been added

Https://github.com/tnaganawa/tungstenfabric-docs/blob/master/TungstenFabricKnowledgeBase.md#vrouter-ml2-plugin

Kubernetes

When used with Kubernetes, its behavior is similar to that of OpenStack, although it uses nova-vif-driver 's CNI and neutron-api 's kube-manager.

Https://github.com/Juniper/contrail-controller/tree/master/src/container/cni

Https://github.com/Juniper/contrail-controller/tree/master/src/container/kube-manager

When you create a container, kube-manager creates a port in the Tungsten Fabric controller, and cni assigns the port to the container. VCenter

Because the module cannot be installed directly on ESXi, the integration of vCenter with Tungsten Fabric and kvm take a different approach. First, to make overlay available between ESXi, you need to create a vRouter VM on each ESXi (a simple CentOS vm inside). When you create a virtual machine on ESXi, it is attached to the dv-portgroup created by vcenter-plugin (see https://github.com/Juniper/contrail-vcenter-plugin). When creating a virtual network in a "vCenter" tenant, the vcenter-manager installed on each vRouter VM through ESXi's ip/user/pass (see https://github.com/Juniper/contrail-vcenter-manager) does two things:

Set a vlan-id for the dv-portgroup port of the VM connection.

Create a vif on a vRouter VM with an interface (vlan) that has the same vlan-id as the dv-portgroup port and the VRF of the virtual network.

In this way, when a virtual machine sends traffic, it first enters the dvswitch and marks it, then reaches the vRouter VM, then unmarks it, and then enters the specific VRF to which the virtual machine belongs.

Since traffic from each virtual machine will be marked with a different vlan-id, micro-segmentation can also be implemented.

After the traffic enters vRouter VM, its behavior is the same as that of kvm. Note that these behaviors are triggered only when the virtual machine is attached to the dv-portgroups created by the Tungsten Fabric controller, so the interfaces of the virtual machine can still be assigned to some vSS or vDS for underlay access.

You can even install the vCenter and Tungsten Fabric controllers on the same ESXi with vRouter (if assigned to "VM Network" instead of the dv-portgroup created by the Tungsten Fabric controller).

Because vRouter behaves the same as in other cases, sharing virtual networks between vCenter and OpenStack, or route leaks (route leak) between them, also becomes easy to obtain. Therefore, with Tungsten Fabric, it becomes much easier to share networks and network services (such as fw, lb, and so on) while using two VMI at the same time.

Series of articles on getting started with Tungsten Fabric

1. First-time startup and operation guide

2. Seven "weapons" of TF components

Series of articles on Tungsten Fabric Architecture Analysis--

Part I: main features and use cases of TF

Article 2: how TF works

Part 3: detailed explanation of vRouter architecture

Part IV: service chain of TF

Part 5: deployment options for vRouter

Part 6: how does TF collect, analyze, and deploy?

Chapter 7: how to arrange TF

Part 8: TF support API list

Article 9: how TF connects to the physical network

Part 10: TF Application-based Security Policy

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.