Basic Load Balancing With the NSX Advanced Load Balancer (ALB)
With vSphere with Tanzu in vSphere 7.0 Update 2 we got the ability to use the NSX Advanced Load Balancer (ALB), formerly known as AVI networks, as the load balancer in the Supervisor cluster. This opened up a bit of a new world for me as I had little to no experience with the product.
Although I think I'll mostly be dealing with the ALB through Tanzu I thought I'd test it as a regular Load Balancer as well to test, and understand how the stuff really works.
This will be a write up of how I set it up for basic load balancing of web traffic in my existing vSphere environment
First a few short words on how the ALB is working. This will by no means be very detailed, take a look at the documentation for more
The ALB consists of an Avi controller (cluster), and Avi Service engines. Load Balanced applications and services will be represented by a Virtual Service and a Server Pool.
All management is done through the UI, CLI or API on the Avi Controller. The controller is normally deployed as a three-node cluster which makes up the control plane. The controller works with underlying Orchestrators, which is a connection to supported Clouds (e.g. a vCenter server), for deploying Service Engines (SEs). The SEs perform the data plane operations and do the "actual" load balancing work. The SEs hosts Virtual Services which is the service a client/user connects to. The Virtual Service forwards the traffic to an applicable and available member of the Server Pool
The Avi controller requires 8 vCPU, 24 GB RAM and 128 GB of storage. In a production environment you'll need three of these. In my lab environment I'm running it with 4 vCPUs and 20 GB RAM, since it's a lab environment with limited resources.
The Avi Service Engines require 1 vCPU, 2GB RAM and 10 GB of storage. The number of SEs needed is based on how many applications that Avi is servicing, and the redundancy chosen for those. By default you'll get two SEs when you deploy your first Virtual Service
The ALB comes with an evaluation license installed that lets us test the full functionality of the product. Note that there are different licensing editions available that enables different feature sets. E.g. the Essentials license supports only L4 load balancing and legacy HA.
Check the License feature comparison for details.
The ALB is deployed as an OVA and the process is very easy. The only information needed is the management IP network details.
For deployment on other providers take a look at the documentation
After deploying the OVA and powering on the Avi controller we're met with the admin user setup. Choose a password, and optionally an email address, for the admin user.
Next step is the System settings which includes a Passphrase used for backups and config exports, DNS information, SMTP information, and Multi-tenancy. In my setup I'm only adding a Passphrase and the DNS info, I set the SMTP to none, and the Multi-tenancy info I leave at the defaults
That's all there is to the initial deployment.
Before we can start using the Avi Controller we need to connect it to some infrastructure components. This is done through the concept of Clouds, and by specifying the Networks we will use. Optionally we can also add in some routing, but we'll get to that.
Some of the setup is also done through different Profiles which we'll touch upon in due time.
After deploying you'll have one cloud created, the Default-Cloud. If you didn't select to configure this in the initial setup it will be of Type None like in my example
Let's edit the Default Cloud and connect it to our vCenter server.
We'll first select the type, which will be VMware vCenter in my case
Next step is to add the details about our vCenter. Note that we can add in IPAM and DNS profiles which will be used when deploying to this cloud. We'll do this in a later step.
Next we can configure which Data Center in vCenter to connect to, and also specify some IP settings. We'll leave these for now
Last step is to select the Management Network port fetched from vCenter. We can also set the template for the Service Engine Group
After selecting the network we can also specify the details of the Management network. I've set the subnet and gateway and a Static IP address pool of 10 addresses. These will be used for management addresses for the deployed SEs.
Note that I've also set the Template Service Engine Group to the built-in Default-Group, this is optional.
When the cloud has been configured we'll go ahead and set up the Networks.
The Network(s) we are configuring here are those for the Virtual Services, i.e. the IP addresses for our load balanced services/applications. These are actually
In my environment I'm using the network LAB-103 which corresponds to VLAN 103 and the subnet 192.168.103.0/24.
We'll edit the Network and hit Add subnet and then add the IP Subnet address, and also hit Add Static IP Address Pool
After we've entered our Network details we have the following configuration set
We can also confirm that the network have been configured and that we have 10 addresses available. Note that there's also 10 addresses available in the Management network
Now, let's create an IPAM profile which we'll use for automatically assigning IP addresses for our Virtual Services.
We'll give the Profile a name, and select the Network in the IPAM configuration. Note that the selection of Clouds are for listing the available networks
After the IPAM profile has been created we'll add it to the Cloud
Service Engine Group
Now lets take a quick look at the Default Service Engine Group. The configuration of the Service Engine Group will be used as a template for the deployed Service Engines.
The Basic Settings is covering things like Capacity and limits for the Service Engines, but also High Availability and Placement. Please note that some of the available settings (e.g. HA) depends on the license.
I'm leaving the default settings for now
The Advanced settings lets us set a specific prefix for the SE's and select a specific VM folder. We can also choose which clusters or hosts to use. In my case I'm selecting which Host cluster I want to use.
The last config we'll do is to set up routing
For our Service Engines on VLAN 103 to reach the services deployed on VLAN 150 we'll have to set up a specific route
Note that based on your (networking) environment the need of routing might be different than from my setup.
We want to specify that the SE's should use the virtual IP on 103 through it's gateway to reach the 150 network and for that we'll configure first a static route
Next, we'll tell our Cloud to prefer these static routes
Test Load Balancing of two Web servers
With all of this set we are ready to test our Load Balancer!
We have two Web servers configured. One yellow and one red which we'll use in our first test scenario. The servers are both residing on the 192.168.150.0/24 subnet, and have the .11 and .12 addresses respectively.
Create Virtual Service
To Load Balance these we'll create our first Virtual Service.
We'll give the service a name, and select to Auto-allocate an IP via the 103 network, and we'll add our web servers. The service will be of HTTP and on Port 80
Now the Virtual Service has been created, and since this is our first service the controller needs to deploy some Service Engines to run it on
After a few minutes our Service should be up and if we click on our Virtual Service we can get a few more details, like which Service Engine is the active
Service Engines deployed
The Service Engines should be deployed and running automatically and we can take a look at them from the Infrastructure menu.
We can also see the Service Engines as VMs in vCenter. Note that they are using management IP addresses from our configured static IP pool in that network
One thing to notice is that the VM has only two IP addresses even though it (the active one) has an IP address on my VLAN 103 as well.
Test load balancing
Everything looks great, let's test our load balanced application to see what happens
Let's test it with curl to see if we also get the other service in use
As we can see only the Red server is in use. Why is that?
Well, if we take a look at our Server Pool we can see the load balancing is set to Least Connections by default
Let's change it to Round Robin and see what happens
Now we can see that it alternates between the two servers!
This was a lengthy post, but I wanted to keep all of the initial setup for a basic load balancing scenario in one place.
As we've seen there's lots of possibilities in the NSX Advanced Load Balancer, much much more than I've touched upon in this post.
In upcoming post(s) I'll take a look at a few other scenarios as well.
Thanks for reading!