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

In the enterprise cloud service in the multi-cloud era, we often encounter the problems of hybrid cloud and heterogeneous resources. As the representative of open source SDN, Tungsten Fabric can well achieve SDN interworking and open up heterogeneous resource pools at the network level.

On July 9, in the online live broadcast event [TF Live] of TF Chinese Community, Wang Jun, a network architect from Huasheng Tiancheng, communicated with you online and demonstrated how to realize the interworking of heterogeneous resource pools among vCenter, OpenStack and K8s based on the open source SDN function of Tungsten Fabric, as well as the drainage function of service chain.

This event is jointly organized by TF Chinese Community and SDNLAB.

[download pdf document]

Https://tungstenfabric.org.cn/assets/uploads/files/tf-live4-sdn.pdf

[live video playback]

Https://v.qq.com/x/page/m31138leucf.html

Wang Jun, Huasheng Tiancheng Network architect. Has more than 10 years of experience in the network industry, has participated in the design and construction of large bank backbone network, Internet government cloud and other projects. During the TF Live live broadcast and question and answer session on July 9, Wang Jun also shared her practical experience, as well as the role and performance of Tungsten Fabric in enterprise cloud computing applications.

Realization of resource pool interworking based on Tungsten Fabric

As a veteran cloud computing integrated service provider and cloud computing operator, Huasheng Tiancheng has developed a unified management platform suitable for multi-cloud heterogeneous resources in the process of serving customers' cloud computing business. Through a unified cloud management platform, it can dock different resource pools such as OpenStack, K8s, vCenter, PowerVC, Ironic/xCAT, bare metal, public cloud and so on.

However, at the network level, each type of resource pool actually has its own set of network architecture and plug-ins. For the cloud management platform, the network layer becomes more complex, so we need to find a unified network management solution to meet the needs of customers to support heterogeneous resource pools. At the same time, many customers do not want to be bound by vendors and want to build a decoupled architecture.

According to Wang Jun, after a lot of research and comparison, Huasheng Tiancheng's cloud development team chose Tungsten Fabric as the technical direction of unified network management in the future after comprehensive consideration in terms of multi-cloud environment coverage, network application orchestration of mixed resource pools, SDN features, friendly device support, open source architecture, and professional network support.

From the overall architecture of Tungsten Fabric, whether it is the resource pool of OpenStack, the resource pool of K8s, or the resource pool of VMware, it is implemented through the vRouter in the Tungsten Fabric computing node.

QA question and answer

In practical applications, what are the scenarios where such multiple heterogeneous resources will appear?

From the perspective of many projects today, customers themselves have been using virtualization through VMWARE, and then on OpenStack, which is a lot of cases, but the management on both sides is fragmented. For customers, on the one hand, they want to decouple and do not want to bind manufacturers; on the other hand, for example, Internet exports have internal and external firewalls, which also need to be made heterogeneous, which are more common in the financial industry.

It turns out that if you want to use the OpenStack scheme of a certain factory, is it too much to change?

The changes should be relatively big. I don't know which version of their SDN you are using. Like manufacturers, they all distribute the corresponding configuration based on the hardware, and then do a VLAN-to-VXLAN conversion on the border. While Tungsten Fabric is mainly open source software, we can see that all our vRouter is installed on the host, and then it has nothing to do with underlay's network, as long as it is interconnected.

V r outer has replaced OVS, and the architecture has changed a lot.

Yes. The change is really big. VRouter is equivalent to something that is routed. For example, I create a virtual machine in vCenter and connect it to a distributed switch. Even if we use the same network, Tungsten Fabric will assign different VLAN tag. This will cause all traffic to be uploaded to vRouter and will not be forwarded on this vSwitch.

Demonstration of interworking of three resource pools

Next, Wang Jun conducted a detailed demonstration, based on the implementation of Tungsten Fabric in vmware (the integration of Tungsten Fabric and vCenter) to further illustrate the functions of Tungsten Fabric.

L Tungsten Fabric deploys network and security policies by monitoring the event created by VM

L Tungsten Fabric assigns a vlan id to each VM, and each VM has a separate vlan id

L vRouter A port is connected to the distributed switch of vCenter through trunk. All VM traffic is connected to the switch with the corresponding tag, sent to vRouter through trunk, and entered into the corresponding vrf. Then the processing method is the same as that of openstack and K8s.

The other port of vRouter connects to the physical network card through a standard port group, and establishes a tunnel for MPLSoverUDP with other ESXi and KVM resource pools.

In practice, a manager of vCenter will be installed in vRouter to manage the tag of VLAN.

In the live demonstration environment, there are three resource pools: OpenStack, K8s and vCenter. By deploying two machines on vCenter: one is Controller for TF and the other is ESXi with vRouter deployed, the latter creates a virtual machine and then interoperates with K8s and OpenStack.

After the completion of the demonstration of interworking among the three resource pools, Wang Jun also demonstrated data flow tracking, tracking data flow through commands on vRouter, and viewing the intermediate forwarding process and the implementation of interworking.

QA question and answer

Each resource pool has a vRouter. Who provided this?

For example, we have two computing nodes in OpenStack, both of which have corresponding vRouter on the host, which is responsible for the forwarding of its host. If you look at the Pod in K8s, there is vRouter on both node. For vCenter, there is a vRouter on every ESXi.

Did all the operations demonstrated just now be done on a host machine?

No, our OpenStack and K8s are nested virtualization, and we have built an environment on the existing virtualization platform. VCenter is also built with a workstation, and there is a vCenter environment, and the router exported by VMX is on a vCenter environment.

Tungsten Fabric can only be used in layer 2 networks to connect several resource pools, right?

In fact, it is essentially three layers. Each of your virtual machines is on the vRouter. Just now we also saw tracking routes. After the virtual machine is connected, the virtual machine will assign it a corresponding virtual interface and delimit it into the corresponding VRF. Just now I saw that the routing table in the VRF will generate a 32-bit route. In essence, I think it is still a route, but it is a 32-bit route.

Function and drainage of service chain

In addition to the interconnection of heterogeneous resource pools, Wang Jun also shares the drainage function of the service chain.

Virtual machines usually go to the gateway through vRouter, and then go out to access the Internet, but in order to protect the security of virtual machines, a firewall may be added to the path. At this time, the firewall may be in the OpenStack, KVM resource pool, so you need to direct the traffic to the firewall, then come out from the firewall, and then go out to the Internet through the gateway.

In other words, when we need to add some NFV-related functions to the path, such as firewalls or detected devices, and then direct traffic, we need to use the function of the service chain.

For the demonstration of service chain drainage, first create a pod in K8s, then connect it to a custom network and bind it to pod through Floating IP.

Next, the firewall is a VSRX in the vCenter environment, there are two VN, through RT, to connect the Floating IP network and the left network (trust interface), and direct traffic to the firewall.

Finally, through the right network, connect with the vmx boundary, and then access the external network.

QA question and answer

Have you ever encountered any problems that are more difficult to solve? What kind of hole did you step on in the process of running?

The deployment process was fine, but because of the lack of vCenter documents, our team found a lot of things and ran into some trouble. In fact, as far as vCenter is concerned, the support of Tungsten Fabric is not very good. For example, when the firewall imports a file image, you can only choose one network card. After the import is successful, you need to add a new network card (need three interfaces: management, left, right). At this time, Tungsten Fabric cannot recognize it and can only solve it manually for the time being. For example, if the new network is associated, or the original associated network has been changed, the changes cannot be synchronized and must be changed manually in order to be consistent with each other.

What is the direction of Tungsten Fabric management of bare metal?

At present, Tungsten Fabric can not perfectly implement bare metal things, we can register with OpenStack, and then deploy the operating system, but there is no way to switch to the tenant network, and some improvements are needed.

Is the underlay in the experimental environment in a local area network? Can it be implemented on the wide area network?

In fact, there is a better solution for the WAN. In our current environment, all exports are through a VMX, so it is impossible for two data centers to go out through the same exit. I think a more reasonable solution is that each data center will have an exit, and then the two sides will be interconnected through the exit. The tunnel should be interoperable, and we will test this scenario in the next stage.

During the live broadcast, Wang Jun also mentioned that there is still a lot of room for improvement in Tungsten Fabric, but as Huasheng Tiancheng's next development direction of network technology, the team will, like everyone else, do a good job of research and development, actively communicate in the community, and explore how to better apply Tungsten Fabric to create a higher availability of heterogeneous hybrid cloud architecture.

Review of previous periods

KK/ Jianxun: cloudy, SDN, and the theory of evolution of Internet workers

Yang Yu: how does Tungsten Fabric enhance the network performance of Kubernetes

Frank Wu: when OpenStack meets Tungsten Fabric

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.