Introduction to NSX Advanced Load Balancer and Deployment without NSX-T

We find plenty of tutorials on how to deploy and configure the NSX Advanced Load Balancer in conjunction with NSX-T. I am one of the few who do not have NSX-T in their HomeLab, so in this tutorial I would like to briefly show you the NSX ALB deployment without NSX-T. But first let us talk about the NSX Advanced Load Balancer (formaly known as avi networks).

The NSX Advanced Load Balancer makes it easy to apply load balancing, web application firewall, and container ingress to any application in any datacenter and cloud.

Main Features:

• Multi-Cloud Consistency – Simplify administration with centralized policies and unified operations across on-premises data centers and public clouds, including VMware, OpenStack, AWS, Azure, and Google Cloud Platform.
• Pervasive Analytics – Real-time application performance monitoring, closed-loop analysis capabilities, and deep learning and machine learning provide insight into network, user, and security.
• Full Lifecycle Automation – Free infrastructure teams from manual tasks and support DevOps teams with self-service. Application delivery automation toolkits include Python SDK, RESTful APIs, and Ansible and Terraform integrations
• Future Proof – Seamlessly extend application services like container ingress into cloudnative applications in Kubernetes and OpenShift environments via a single platform with modern distributed architecture.

The VMware NSX ALB has a software-defined architecture that separates the central control plane (Controller) from the distributed data plane (Service Engines).

NSX ALBController: NSX ALB Controller is the central repository for the configuration and policies and can be deployed in both on-prem environments or in the cloud. NSX ALB Controller is deployed in VM form factor and can be managed using its web interface, CLI, or REST API.

The controller handles the following tasks:

• All platform related configuration is done on controllers.
• Manage and store all policies related to services and management.
• Responsible for deploying Service Engines (sysin).
• Manage the placement of virtual services on SEs to load balance new applications or scale-up capacity of current applications.
• Facilitates UI console to perform the configuration and management.
• Host API services and the management plane cluster daemons.

Service Engines (SE): The Service Engines (SEs) are lightweight data plane engines that handle all data plane operations by receiving and executing instructions from the controller.

The responsibilities of Service Engines are:

• Perform load balancing and all client and server-facing network interactions.
• Collect real-time application telemetry from application traffic flows.
• Execute data plane application delivery controls operations, such as health monitoring and test the performance of the back-end servers.
• Protect against security threats (DoS, suspicious client IPs).

Why you should choose the NSX Advanced Load Balancer

Traditional hardware load balancers have the following limitations: 

• No Auto Scaling when load balancer runs out of capacity for the virtual service placement
• No Self-healing in a failure scenario
• Manual Virtual Service placement 
• Complex upgrade procedure
• Compatibility with various platforms/cloud infrastructure.

NSX ALB is a 100% software-defined solution designed to address the above challenges.

Now let us start with the NSX Advanced Load Balancer Deployment. First, we get the NSX ALB .ova from the Customer Connect portal. Do not be surprised, you will be redirected to the AVI webpage and get the .ova there. Then we deploy the .ova to the desired vCenter.

I will describe a few steps without screenshots and write you briefly in a list here below:

• Provide a VM name for the NSX ALB controller and select the desired folder.
• Select a compute resource
• Verify that it is the correct .ova:

I have deployed the NSX ALB controller as “thin”, at least to my knowledge nothing speaks against it. Continue with the todo list:

• Choose the right storage policy and datastore. In my case it is a VMware vSAN 2-node cluster with approx. 18TB
• Select the network in which the NSX ALB Controller Management should technically be on the road

Now let us move on to the penultimate step, where we exclude NSX-T from the deployment.

Mandatory fields are the following:

• Management Interface IP Address
• Management Interface Subnet Mask
• Default Gateway
• IPv6 (if desired)
• Hostname of Avi Controller

Everything else and especially what starts with NSX-T, you leave out – it is that simple! Last but not least, in step 8, look at the data you entered and click Deploy. The Deployment takes time and the NSX ALB controller also takes a while to become fully available. Do not be suprise if you get this message after powering on the NSX ALB VM:

The virtual console of the VM shows that there are services, which are getting started:

After a while we will get the welcome page and we can make some basic configurations:

Provide an Admin Password and (optional) an Email Address and create the admin account. On the welcome page you have to provide some more informations like DNS Servers,

(optional) Email/SMTP

and enter your Multi-Tenant settings, click the Setup Cloud After box and save.

Then you will land on the main page of the NSX ALB. Edit the Default-Cloud by clicking on the Pen icon next to the green Status.

At the General settings select the Type* VMware vCenter / vSphere ESX

Scroll down and Set Credentials for the VMware vCenter / vSphere ESX. The Access Permission has to stay on Write otherwise you will not be able to deploy Service Engine VMs.

Select the Management Network, add your DNS Resolvers and save:

Now at the Applications Dashboard, you are ready to deploy Service Engines for several UseCases, which closes this Blog post. For the next NSX ALB posts, we will talk about different UseCases.

So stay tuned and if you have any questions please left a comment below. 🙂