Author: Tatsuya Naganawa Translator: TF compilation group
Tungsten Fabric Getting Started Collection series of articles, from practical experience taught by technical experts, compiled and presented by the TF Chinese community for you, aiming to help novices to deeply understand the whole process of TF operation, installation, integration, debugging and so on. If you have relevant experience or questions, welcome to interact with us and further communicate with community geeks. For more TF technical articles, please click the button at the bottom of the public account> learning> article collection.
Tungsten Fabric has achieved the integration of multiple orchestrators.
Internally, Tungsten Fabric's orchestrator integration component basically performs the same operations on each orchestrator, including:
- Ports are assigned when the virtual machine or container starts.
- Plug it into a virtual machine or container.
Next I describe what each orchestrator needs to do.
OpenStack
When used with OpenStack, neutron-plugin will become the main interface between OpenStack and Tungsten Fabric Controller.
Neutron-plugin will be directly loaded into the neutron-api process (some modules need to be specified in neutron.conf), and this logic will perform operations related to Neutron's request / response, such as network-list or port-create, etc. .
One feature of this module is that it will not use the Neutron database created in MySQL (in a typical OpenStack setup).
Since it directly uses Tungsten Fabric db, certain functions (such as bridge distribution 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-types 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 the vif-type of vrouter, the operation will be automatically completed by the "create port" API through neutron-plugin, which will use nova-vif-driver for vRouter to perform some tasks, not just in Create a tap device when calling, for example, create a vif on the vRouter through the vrouter-port-control script. (See https://github.com/Juniper/contrail -nova-vif-driver)
- In most cases, you do not need to delve into the details of these behaviors. Although in some cases (such as live migration stopped at some point), you may need to pay attention to the status of vif.
Note: Tungsten Fabric also has plugins based on ml2.
Therefore, if users already use ml2 in MySQL, they can first add vRouter as one of ml2's network-type, use it in a specific virtual network, and then migrate from other ml2 plugins to vRouter through the detach and attach interfaces. (If all migrations are completed, you can choose to replace the Neutron core plugin.)
In addition, some installation details have been added.
Governors
When used with Kubernetes, its behavior is similar to that of OpenStack, although it uses CNI with nova-vif-driver and kube-manager with neutron-api.
- https://github.com/Juniper/contrail-controller/tree/master/src/container/cni
- https://github.com/Juniper/contrail-controller/tree/master/src/container/kube-manager
When creating a container, kube-manager will create a port in the Tungsten Fabric controller, and cni will assign the port to the container.
vCenter
Since the module cannot be directly installed on ESXi, the integration of vCenter with Tungsten Fabric and the approach taken by kvm are different.
First, to achieve overlay availability between ESXi, you need to create a vRouter VM (a simple CentOS vm inside) on each ESXi.
When creating a virtual machine on ESXi, it will be attached to the dv-portgroup created by vcenter-plugin (see https://github.com/Juniper/contrail-vcenter-plugin). When creating a virtual network in the "vCenter" tenant, install the vcenter-manager on each vRouter VM via ESXi ip / user / pass (see https://github.com/Juniper/contrail-vcenter-manager), Two things will be done:
- Set a vlan-id for the dv-portgroup port to which the VM is connected.
- 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 the virtual machine sends traffic, it first enters the dvswitch and marks it, then reaches the vRouter VM, then cancels the mark, and then enters the specific VRF to which the virtual machine belongs.
- Since the traffic from each virtual machine will be marked with a different vlan-id, micro-segmentation is also achieved.
After the traffic enters the vRouter VM, its behavior is the same as that of kvm.
Please note that these behaviors are only triggered when the virtual machine is attached to the dv-portgroups created by the Tungsten Fabric controller, so the virtual machine's interface can still be assigned to certain vSS or vDS to use underlay access.
- It is even possible to install vCenter and Tungsten Fabric controllers on the same ESXi with vRouter (if assigned to "VM Network" instead of dv-portgroup created by Tungsten Fabric controller).
Because the behavior of vRouter is the same as in other cases, sharing a virtual network between vCenter and OpenStack, or a route leak between them, becomes easy to obtain. Therefore, with Tungsten Fabric, it is much easier to use two VMIs simultaneously by sharing the network and network services (such as fw, lb, etc.).
Tungsten Fabric entry series of articles-
1. The first start-up and operation guide
Tungsten Fabric architecture analysis series articles-
Part 1: TF main features and use cases
Part 2: How TF works
Part 3: Detailed vRouter architecture
Part 4: TF service chain Part
5: vRouter deployment options Part
6: How TF is collected, analyzed, deploy?
Chapter 7: How TF arranges
Chapter 8: List of TF support APIs
Chapter 9: How TF connects to the physical network
Chapter 10: TF application-based security policy
