Deploying NSX Advanced Load Balancer (aka Avi) in my homelab

VMware acquired Avi Networks in the summer of 2019 to add Software-Defined ADC (Application Distribution Controller) capabilities to their Virtual Cloud Network portfolio. That’s a fancy way of saying they bought the most awesome load balancing, WAF and container ingress traffic management solution in the market. VMware rebranded Avi Networks Load Balancer to VMware NSX Advanced Load Balancer (NSX ALB or Avi) and I want to take away one common confusion I hear often: NSX Advanced Load Balancer is a standalone solution and does not require you to run VMware NSX at all. As a L4-L7 solution it is part of the NSX product family and, yes, it integrates with NSX but there is no requirement whatsoever for you to run NSX. NSX Advanced Load Balancer can also integrate with a wide range of cloud infrastructures and platforms, such as AWS, OpenStack, Tanzu, and so on by the way. With that out of the way, let’s first take a look at the solution.

PS. I feel obliged to put a large disclaimer here: I’m not a load balancer expert. This blogpost is not me being an authority on NSX Advanced Load Balancer but rather me being enthusiastic about this cool piece of technology and trying it out in my homelab. I’m mostly typing along as I go so this is not the best structured blogpost you’ll find about NSX Advanced Load Balancer. If you find any mistakes or that thing important things are missing, please let me know! Once I find my way around the product I will most likely also record a walkthrough for my YouTube channel. Stay tuned!

What makes NSX Advanced Load Balancer’s architecture unique?

NSX Advanced Load Balancer is a distributed and highly scalable cloud-native Application Distribution solution that takes network services that are typically tied to a physical box or virtual appliance (like Load Balancing and WAF), and distributes these functions across your x86 infrastructure. By decoupling the management/control plane and the data plane, NSX Advanced Load Balancer provides a scale out architecture that can scale horizontally. NSX Advanced Load Balancer comes with a Controller (Cluster) called Vantage Controller and uses Service Engines (VMs) to actually handle the data flows and host Virtual Services:

The centralized control and management plane (Vantage) and Service Engines distributed across data centers, clouds and platforms delivers a true multi-cloud solution for all your application delivery requirements.

Setting up NSX Advanced Load Balancer in my homelab

First of all, the license for the NSX Advanced Load Balancer is provided to me as part of the VMware vExpert program. If you are not part of the vExpert community but are actively contributing to the vCommunity, I highly recommend you apply! Now, on the deployment!

I deployed the Vantage Controller to my management network (VLAN 10). I’m using a fully nested homelab and to optimize performance I deployed the Controller directly onto my physical ESXi host using a typical OVF deployment. This part of the deployment is really straightforward.

NSX Advanced Load Balancer works with the concepts of “Clouds” with which NSX Advanced Load Balancer integrates through an Orchestrator. The Orchestrator takes care of all the automation around the integration with a specific cloud. It automatically deploys Service Engines and life cycles them through a desired state kind of model. Depending on the chosen cloud integration, the orchestrator can work in Read, Write or No Access mode.

In my homelab environment I have connected the controller directly to my vCenter Server and to NSX-T. This means I can deploy Service Engines that load balance traffic on vSphere networks and Service Engines that provide load balancing on NSX-T segments. I did this mainly from demonstration purposes because typically I guess you would standardize your virtual networking layer.

In the hamburger menu on the top left you select Infrastructure and then select Clouds:

My “Default-Cloud” is configured to connect to vCenter and “nsxtcloud” connects to, well … NSX-T. Before you can configure these integrations you need to make sure you have dealt with the prereqs:

• IP addresses for your controller and an IP pool (or DHCP setup) for all your Service Engines
• User accounts to access vCenter and NSX-T
• Content Library (if you want to use automated deployments of the Service Engines)

In production environments you would use a cluster of 3 controllers but in a lab environment, 1 controller is sufficient. The service engines have an interface in the management network and an interface in the application network. As you can see in this diagram, the Avi Controller connects to the (or a) management network and the Service Engines in the bottom connect to that same management network and a frontend network for the VIP interfaces:

Connecting to NSX-T

In order to connect NSX Advanced Load Balancer to an NSX-T environment, you first need to setup the credentials to connect to NSX Manager. This took me a “couple of minutes” to find because under Administration you have “Accounts” and “User Credentials”. Accounts are users for NSX Advanced Load Balancer itself and User Credentials are used to connect to other stuff like NSX-T. Obviously you need to create a User Credential, but it took longer than I would like to admit to find out. RTFM 😉

Next up is connecting to the NSX-T Cloud. Under Infrastructure, go to Clouds. Here you can configure the connection to NSX-T. You need to provide a name and provide the credentials. You also need to provide the Transport Zone, Overlay Segment and T1 Router for the Management Network. I’m not really sure what a good design practice is for deploying NSX Advanced Load Balancer but I created a dedicated T1 router and Overlay Segment:

You also need to configure the Overlay Segments on which you want to provide Virtual Services:

Finally, you need to configure your vCenter Server and provide a Content Library. The Controller will automatically upload the OVA for the Service Engines:

As part of the prerequisites you also need to create a User Credential for vCenter too, by the way.

DHCP or IP Address Pools

The Service Engines need IP addresses on their management network interfaces and their application network interfaces. You can either choose to use DHCP if you are running that in your environment, or you can configure IP Address Pools. I went for a mix of both because I’m not running DHCP on my management network but I am running it on my workload segments as part of a previous lab I did. To configure the IP Address Pool for the management network, go to Infrastructure, Networks and select the Avi-Management-Segment network. You can configure the IP Address Pool there:

On my Web segment, I simply checked “DHCP Enabled”:

Creating our first Virtual Service

In Applications, select Create Virtual Service. You can choose between Basic Setup and Advanced Setup. I’ll stick with Basic Setup for now. Next is to choose the Cloud for which to deploy the Virtual Service. I will deploy it on my NSX-T Cloud. In Basic Setup we can select the Application Type (HTTP/HTTPS/L4/L4 SSL/TLS) provide a FQDN or IPv4 Address for the VIP and of course we need to select the T1 router. For the destination servers you can provide an IP address/range, IP Group and NSX-T Security Groups. My test web servers are already in the NSX-T Security Group called Web-Prod so that makes configuration easy:

The creation of this Virtual Service kicked of the automatic deployment of two Service Engines. The Service Engine Group configuration defines how HA is provided for the Service Engines and you can control how the platform scales out. I will definitely need to read up on these details! Once the Service Engines are up and running, our Virtual Service is available and we’re load balancing traffic to the two webservers defined in my Security Group:

There is lots of information here and detailed, real-time and historical statistics to discover. From what I’ve learned so far about the solution, visibility and analytics are really strong and unique selling points for NSX Advanced Load Balancer as well. Truth be told, I don’t have a lot of experience working with traditional loadbalancing solutions like F5’s or Netscalers so I don’t have a good reference but every presentation I saw about NSX Advanced Load Balancer explains how the amount of insight NSX Advanced Load Balancer provides is unprecedented. I highly recommend watching the TechField Day recording of the NSX Advanced Load Balancer. There is also a second recording with a demo. Great stuff!

That’s it for now. Definitely not my most structured blogpost but I found it fun typing along while I was playing around with the product and learning along the way. Let me know what you think!