[NSX-T 3.2.x] Integration with AVI ALB. What does it change with respect to the NSX native balancer?

As many of you know, VMware decided to discontinue the traditional NSX-T load balancer, to make way for the NSX Advanced Load Balancer, formerly known as AVI ALB or AVI Vantage.

This has led to uncertainty for many users, as this new product completely changes the topology and design of our NSX-T environment, introducing us to a product where many are not experts.

However, there is some good news, such as, for example, that although the NSX-T native balancer will be discontinued, there is still no retirement date or release, so we have a good margin of time to plan our migration or familiarize ourselves with the change. Anyways, this is a product that I have personally been able to work with a lot and I can confirm that it works very well and is very interesting for a possible future NSX-T cloud-native approach.

Additionally, as a result of this change, a “Basic” license is included for each NSX-T licensed instance, resulting in a balancer with very similar features to those we had with the NSX-T balancer, but with the option to upgrade to an “Enterprise” edition where we will also have features such as Web Application Firewall (WAF), GSLB, Active/Active balancing, or Datascripts (scripts that apply directly on the Dataplane, allowing us to create a very customized balancing policy, HAproxy style).

Similarly, if we do not have NSX-T, but we have Tanzu licenses, our license will be valid for the “Essentials” edition of AVI, which will allow us to expose services up to layer 4 through integration with AKO (Avi Kubernetes Operator).

But… What does it really change?

This is one of the most common questions, and the first one we will ask ourselves if we want to go to an AVI environment and we have not worked with this balancer previously.

Let’s take it one step at a time:

If we recall, the architecture of the traditional NSX-T load balancer is none other than a Stateful service running inside an EDGE VM, more specifically inside a T1.

This really brought us advantages, especially in terms of simplicity of deployment, since once our EDGE cluster was deployed, we could have our balancer up and running with a couple of clicks. Once our EDGE cluster was deployed, we could have our balancer up and running with a couple of clicks. However, it had some disadvantages, such as the fact that it was mounted on the Service Router (SR), which meant that all traffic coming through the Distributed Router (DR), such as traffic coming from another segment connected to the same T1, would not work unless SNAT was applied.

( VMware official documentation)

In the inline mode, the load balancer is in the traffic path between the client and the server. Clients and servers should not be connected to overlay segments on the same tier-1 logical router if SNAT on the load balancer is not desired. If clients and servers are connected to overlay segments on the same tier-1 logical router, SNAT is required.”

As well as having the scalability of the balancer itself limited to the size of our cluster of EDGEs without being able to grow in a more “flexible” manner.

Also, despite being a good balancer whose performance is very stable, sometimes, especially when it comes time to “go outside the box” or work at the scripting level, I found myself somewhat limited in features. Something that did not happen with the NSX-V balancer as it is a direct derivative of HAproxy.

Understanding the AVI Architecture

The AVI architecture is a modern architecture, defined by software and with its different decoupled planes, similarly as it happens with NSX-T, we find two main components:

• The controller cluster, usually composed of 3 AVI controllers to provide HA. The function of the controllers is to serve both the Control Plane and the Management Plane.
• AVI Service-Engines (SEs),will be the Data Plane of our balancing network, that is, the ones in charge of processing both incoming and outgoing balancing traffic. For their correct operation we will need them to have direct connectivity both with the Management network and with our FrontEnd network (publications) as well as with the Backend network, either by routing or with a direct leg.

Although the AVI balancer can work on its own as One-Arm or In-Line, for the moment the only topology considered valid for NSX-T is One-Arm, i.e. incoming and outgoing traffic must be routed through the same interface of the Service-Engine, and there may be a dedicated interface for each VRF.

AVI and NSX-T architecture example

What are the benefits of this?

• Decoupling of the EDGEs infrastructure from NSX-T, becoming an independent balancer.
• Scalability, basing our licensing strategy or placement of the SEs, as well as the resources consumed by them according to the services to be balanced.
• Possibility of balancing in Active/Active (Enterprise License)
• Possibility of 100% control from the API, greatly facilitating automation with respect to the NSX-T LB.
• Possibility of parameterization, logs and metrics in real time superior to those offered by NSX-T, increasing troubleshooting capacity.
• Scalability towards functionalities such as GSLB or WAF (Enterprise License).

The only question I still have is if VMware will provide a tool to migrate services in the “Migration coordinator” style so that we can easily take our loads to AVI.

I have already asked about it, but for the moment it is a secret, as soon as I know something I will bring it to you!

Please, if you liked the article feel free to share as well as leave feedback or doubts in the comments section.

Thanks for reading me!!!