NSX ALB (Advanced Load Balancer) Design

I wrote three (3) blogs on Avi Load Balancing, now rebranded as VMware NSX ALB (Advanced Load Balancer). These were around the basic concepts, base configuration, and that configuration using API.

I noticed it was difficult to find a single post that discusses the different types of design solutions. In this post, I want to discuss the design decisions when deploying an ALB solution and expand on my previous blogs.

Management Components

The management components in the ALB solution are the controllers. The controllers are what the users interact with that which pushes instructions to the data plane components. They can be deployed in one (1) of two (2) ways:

Single Controller:
- A single controller is deployed in either a management or collpased compute/management cluster.
- The controller uses vSphere protection mechanisms (e.g. DRS) for recoverability.
- Lower resources are used in comparison to a HA deployment (below).
- No HA is available due to a single controller.
HA Controllers:
- Three (3) controllers are deployed (as a cluster) in either a management or collpased compute/management cluster.
- Each controller uses vSphere protection mechanisms (e.g. DRS) for recoverability.
- Higher resources are used in comparison to a single controller deployment (above).
- HA is available due to three (3) controllers being deployed.

In a production environment, I’d obviously recommend the HA controller deployment model. The quorum of controllers provides HA for the management and control plane. The additional resources required for the quorum are outweighed by the need for a HA in the management/control plane in almost all production use cases.

Single controllers are almost always used in PoC (Proof of Concepts), Dev/Test environments, and Labs.

Cloud Types

Setting up an ALB Cloud is a logical construct that contains SE Groups, SEs, Virtual Servers, and Pools. Some Cloud types link to either vCenter, NSX, neither, or both. As we go through the different Cloud types it’s key to understand some decisions are made based on requirements and some are made on constraints.

No Orchestrator

No Orchestrator Cloud is the least automated type of Cloud. There is no link to vCenter or NSX, which means the SEs are deployed manually. After the SE is deployed manually, they are then adopted by the ALB Cloud. The sizing and placement of the SEs are manual user tasks.

This type of deployment requires a basic licensing model.

vCenter

The vCenter Cloud will automatically deploy SEs in the linked vCenter. After linking the ALB Cloud to the vCenter a cluster and storage array can be selected when creating SE groups. The SE groups in turn will allow for the automatic provisioning of the SEs. This allows for autoscaling or recovery of SEs if/when required.

This type of deployment requires an enterprise licensing model.

NSX

The NSX Cloud will automatically deploy the SEs in the linked vCenter, much like the vCenter model. It also populates inventory (IP, Groups, etc.) in NSX for ease of security design/deployment. This Cloud model also allows for the automatic deployment of SEs.

This type of deployment requires a basic licensing model.

Cloud Selection

It’s important to note that the type of Cloud you deploy does not determine the data plane delivery. You can deploy a No Orchestrator Cloud with an ECMP delivery model. It can sometimes be a little more convoluted to deploy, but the option is there. The main decision behind the Cloud type is:

How much product automation do you want/are able to use. What products do you have in your datacenter. After reading the above, you may think the obvious choice would be the NSX Cloud. While I would agree as it comes with the auto-deployment of SEs and security groups pushed to NSX. It’s not always possible.

Data Plane Components

The data plane is delivered by the ALB SEs (Service Engines). These can be deployed in standalone, HA (active/standby), or ECMP (active/active). Each SE or group of SEs are deployed in an SE Group which couples SE resources together.

Standalone:
- Single SE to a SE group.
- No HA in the solution.
- Typically deployed in PoC’s and Labs.
HA (active/standby):
- Dual SEs to an SE group.
- HA achieved by device failover.
- Typically depoyed in Test/Dev and Production.
ECMP:
- Two (2) or more SEs to an SE group. Maximum of eight (8) SEs.
- Active/active deployments help with fast failover and increased throughput.
- Typically deployed in Production.

The SE deployment models almost always depend on the type of license bought. Basic licensing will allow for standalone and HA deployments, but not ECMP. Enterprise is all-inclusive.

The basic licensing is only available when converting NSX licensing into ALB licensing. The NSX license is applied to the ALB controllers in a four (4) to one (1) ratio, meaning four (4) NSX cores equal one (1) ALB SE license. One (1) ALB SE license, means one (1) SE core, or vCPU.

Enterprise licensing is purchased from VMware and is feature-rich, allowing for ECMP deployment models and much more. This type of licensing is purchased in cores, each core equalling an SE vCPU.

There is also a Tanzu essentials license which is coupled with the purchase of Tanzu and can’t be bought separately. While not discussed in this post, it is very similar to a toned-down basic license.

N.B. When deploying an ALB solution, the licensing type has to be the same. You cannot mix basic and enterprise licensing in a single controller deployment.

Network Design

One of the more interesting things I’ve found when working with the ALB product is the type of Network deployments you can have. In the No Orchestrator or vCenter Clouds, the deployment model is that of a normal Load Balancer. The SEs would connect to VLANs and/or segments in either a one-armed or in-line deployment model.

The No Orchestrator mode would require you to perform the vNIC to Networking mapping manually, while the vCenter deployment would allow for some level of automation.

The NSX Cloud, however, has a unique type of deployment model I’ve not seen before. It is assumed, all VMs are either connected to segments or bridged to segments. The SEs will then connect to a dedicated NSX segment hanging off the same T1 which serves the endpoint VMs.

N.B. SEs can also sit on the same Network as the VMs if it’s preferred/required.

This is where the magic happens! The SEs will host VIPs in one of two (2) ways.

The VIPs will use IP addresses from the dedicated SE Network and the pool members will be IPs within the VM workload segments. Typically used in greenfield deployments.
The VIPs will use IP addresses from the VM workload segments and the T1 will steer traffic from the T1 to the SE for Load Balancing if the VIP is targeted. Typically used in brownfield deployments.

In the first instance, the routing is obvious. However, in the second instance, it seems somewhat odd. How does the T1 steer VIP traffic to the SE when the Network is directly connected? The Controllers add /32 static routes to the T1 for the VIP addresses pointing towards the SEs Load Balancing that VIP. I’d not seen this before but I can tell you it’s very effective and scalable. Even more so when coupled with an ECMP deployment.

https://avinetworks.com/docs/latest/nsx-t-design-guide/ I want to point out that like all technology, this can be adjusted and manipulated to fit a wide variety of solutions and designs. I’ve not covered every possible design. Just make sure it is supported!

Notable Mentions

There are other elements to the ALB solution that provide more flexibility when designing and delivering. VRFs or tenant Clouds can be used to satisfy segregation requirements. While I’ve not deployed it for any of my customers, I can see it being very useful in the MSP space. Something to keep an eye on if you are running a Cloud environment.

Design Delivery

When looking to Load Balancing within NSX, you’d be interested to know that the ALB is the VMware direction. As I understand, the native NSX Load Balancing solution will be phased out (timeline unknown). Whether you look into it now or later, eventually you’ll be getting exposure to the NSX ALB solutions.

While most people will aim for the NSX Cloud solution, you may need to make adjustments to the design, using either a different Cloud model or adjusting the standard deployment. It’s important to look at the requirements and constraints before trying to push a design.