NSX Advanced Load Balancer (NSX ALB) emerges as the cutting-edge solution to revolutionize load balancing within the NSX platform. Boasting dozens of advanced features such as Global Load Balancer, Web Application Firewall (WAF), auto-scaling, comprehensive analytics, and much more.
Naturally, VMware Aria Automation paves the way for seamless integration with NSX ALB, enriching its portfolio with native capabilities. With the release of Aria Automation 8.16.1, this much-anticipated integration has finally arrived, empowering customers to leverage load balancing on-demand alongside their applications.
While the official documentation offers an extensive array of samples, it's my belief that none of them encapsulate a simple yet fully functional use case to kickstart your journey. Hence, I present my director's cut: an initial functional sample to set you on the right path.
Unveiling the Use Case:
My offer will create a generic web application distributed by the NSX ALB.
Front-end servers and VIP will be on the same network in a one-arm architecture. The application will be installed on demand. End users would allow some minor customizations.
Let's start with a few inputs to allow the customers to tailor their deployments
The first one is to allow the choice of how many front-end servers will be provisioned:
inp-web:
type: number
title: Front-End Servers
description: Amount of front-end servers to be provisioned
default: 1
maximum: 5
minimum: 1
Followed by the application port selection:
Remember: it's a generic application, so end-users are allowed to pick up the desired communication port. You might want to have it fixed if it's a defined application;
inp-port:
type: integer
title: Application port
description: Port number for the application. Allowed values are 10-65535
default: 80
minimum: 10
maximum: 65535
To define how server's health should be evaluated, I'm using some of the Health Monitors profiles already provided out of the box by NSX ALB. Aria Automation also allows you to create your own customized profiles on-demand.
inp_health:
type: string
title: Health Monitor
description: Verify Server health
default: System-Ping
enum:
- System-Ping
- System-TCP
- System-UDP
- System-HTTP
- System HTTPS
Load Balancing mechanism determine how the traffic will be spread between the front-end servers
Again: I'm giving some options, but not all of them;
inp-lbalg:
type: string
title: Load Balance Algorithm
default: LB_ALGORITHM_LEAST_CONNECTIONS
oneOf:
- title: Least Connections
const: LB_ALGORITHM_LEAST_CONNECTIONS
- title: Least Load
const: LB_ALGORITHM_LEAST_LOAD
- title: Fastest Response
const: LB_ALGORITHM_FASTEST_RESPONSE
- title: Fewest Servers
const: LB_ALGORITHM_FEWEST_SERVERS
- title: Round Robin
const: LB_ALGORITHM_ROUND_ROBIN
My last input is to allow end-users how they want the persistence connections to behave.
inp-per:
type: string
title: Persistence profile
description: Persistence will ensure the same user sticks to the same server for a desired duration of time
default: System-Persistence-Client-IP
oneOf:
- title: Client IP
const: System-Persistence-Client-IP
- title: HTTP Cookie
const: System-Persistence-Http-Cookie
Now that we are done with the inputs let's see how they fit within the resources;
I'm choosing my network based on an existing one, tagged with "net:fix"
This network is already configured on my network profiles with a desired IP address range to provide IPs for my front-end servers
Cloud_Network_1:
type: Cloud.Network
properties:
networkType: existing
constraints:
- tag: net:fix
My application (apache) will be installed on demand by Aria Config. But you can use any mechanism you want, have a dedicated template, leverage Ansible, Puppet, cloud-init, or any other way you can think off;
Cloud_SaltStack_1:
type: Cloud.SaltStack
properties:
hosts:
- ${resource.Cloud_vSphere_Machine_1.id}
masterId: saltstack_enterprise_installer
stateFiles:
- /linux/apache/init.sls
saltEnvironment: base
Nothing fancy for my front-end servers; just a regular VM provisioning, I'm not even selecting the cluster, it will use my default zone. I just tied the network with my network input and the number of front-end counts;
Cloud_vSphere_Machine_1:
type: Cloud.vSphere.Machine
properties:
image: CentOS
flavor: Small
networks:
- network: ${resource.Cloud_Network_1.id}
assignment: static
customizationSpec: Linux-customization
remoteAccess:
username: root
password: ${secret.passwd}
authentication: usernamePassword
count: ${input.inp-web}
Now it's time to review NSX ALB specific resources:
Since I have only one NSX ALB on my environment I'm giving it's account name in every resource. If you have more than one, you can leverage the Cloud Zone helper to allow selection based on constrains/tags, the samples have an example like that;
Starting with the VIP, which will provide the front-end IP address to access the application;
For the VIP address I'm using the option auto allocate, which will instruct NSX ALB to provide the IP based on their own IPAM mechanisms; Meaning you will have to configure the IP Address Range in the Cloud Resources/Network up front;
IPAM Network Subnet is the network where the VIP will reside, remember, I'm placing everything in the same network.
Also, you will have to provide the VIP network details under placement networks. Note the address is the network address, not the specific VIP address:
VIP:
type: Idem.AVILB.APPLICATIONS.VS_VIP
properties:
name: ${env.deploymentName}-${uuid()}
description: VIP created by ${env.deploymentName} deployment.
account: ALB-AVI
vip:
- vip_id: 0
auto_allocate_ip: true
ipam_network_subnet:
network_ref: ${resource.Cloud_Network_1.resourceName}
placement_networks:
- network_ref: ${resource.Cloud_Network_1.resourceName}
subnet:
ip_addr:
addr: 192.168.110.0
type: V4
mask: 24
Moving on to the pool object, which will be the pool of servers providing resources to the application:
Here I'm using my input application port, which communicates back with the server,s plus the health monitor, load balancing algorithm, and persistence profiles selected by the users as part of my inputs.
Also, I need to provide which network the servers are connected to, the same information from the placement networks as we did for VIP.
and map the Server's IP address to the server's properties;
POOL:
type: Idem.AVILB.APPLICATIONS.POOL
properties:
name: ${env.deploymentName}-${uuid()}
description: Pool created by ${env.deploymentName} deployment.
account: ALB-AVI
default_server_port: ${input.inp-port}
health_monitor_refs:
- ${input.inp_health}
lb_algorithm: ${input.inp-lbalg}
servers: ${map_to_object(resource.Cloud_vSphere_Machine_1[*].address, "ip", "addr")}
placement_networks:
- network_ref: ${resource.Cloud_Network_1.resourceName}
subnet:
ip_addr:
addr: 192.168.110.0
type: V4
mask: 24
application_persistence_profile_ref: ${input.inp-per}
Finally, we are tieing everything together with a Virtual Service Resource;
Again, I'm using my application port with the VIP resource and Pool Resource;
Virtual_Service:
type: Idem.AVILB.APPLICATIONS.VIRTUAL_SERVICE
properties:
name: ${env.deploymentName}-${uuid()}
account: ALB-AVI
description: Virtual Service created by ${env.deploymentName} deployment.
services:
- port: ${input.inp-port}
vsvip_ref: ${resource.VIP.name}
pool_ref: ${resource.POOL.name}
That's it, my version of NSX Advanced Load Balancer sample for VMware Aria Automation.
And if you made it up until here, thanks, here's the full code for your appreciation.
formatVersion: 1
inputs:
inp-web:
type: number
title: Front-End Servers
description: Amount of front-end servers to be provisioned
default: 1
maximum: 5
minimum: 1
inp-port:
type: integer
title: Application port
description: Port number for the application. Allowed values are 10-65535
default: 80
minimum: 10
maximum: 65535
inp_health:
type: string
title: Health Monitor
description: Verify Server health
default: System-Ping
enum:
- System-Ping
- System-TCP
- System-UDP
- System-HTTP
- System HTTPS
inp-lbalg:
type: string
title: Load Balance Algorithm
default: LB_ALGORITHM_LEAST_CONNECTIONS
oneOf:
- title: Least Connections
const: LB_ALGORITHM_LEAST_CONNECTIONS
- title: Least Load
const: LB_ALGORITHM_LEAST_LOAD
- title: Fastest Response
const: LB_ALGORITHM_FASTEST_RESPONSE
- title: Fewest Servers
const: LB_ALGORITHM_FEWEST_SERVERS
- title: Round Robin
const: LB_ALGORITHM_ROUND_ROBIN
inp-per:
type: string
title: Persistence profile
description: Persistence will ensure the same user sticks to the same server for a desired duration of time
default: System-Persistence-Client-IP
oneOf:
- title: Client IP
const: System-Persistence-Client-IP
- title: HTTP Cookie
const: System-Persistence-Http-Cookie
resources:
VIP:
type: Idem.AVILB.APPLICATIONS.VS_VIP
properties:
name: ${env.deploymentName}-${uuid()}
description: VIP created by ${env.deploymentName} deployment.
account: ALB-AVI
vip:
- vip_id: 0
auto_allocate_ip: true
ipam_network_subnet:
network_ref: ${resource.Cloud_Network_1.resourceName}
placement_networks:
- network_ref: ${resource.Cloud_Network_1.resourceName}
subnet:
ip_addr:
addr: 192.168.110.0
type: V4
mask: 24
Virtual_Service:
type: Idem.AVILB.APPLICATIONS.VIRTUAL_SERVICE
properties:
name: ${env.deploymentName}-${uuid()}
account: ALB-AVI
description: Virtual Service created by ${env.deploymentName} deployment.
services:
- port: ${input.inp-port}
vsvip_ref: ${resource.VIP.name}
pool_ref: ${resource.POOL.name}
POOL:
type: Idem.AVILB.APPLICATIONS.POOL
properties:
name: ${env.deploymentName}-${uuid()}
description: Pool created by ${env.deploymentName} deployment.
account: ALB-AVI
default_server_port: ${input.inp-port}
health_monitor_refs:
- ${input.inp_health}
lb_algorithm: ${input.inp-lbalg}
servers: ${map_to_object(resource.Cloud_vSphere_Machine_1[*].address, "ip", "addr")}
placement_networks:
- network_ref: ${resource.Cloud_Network_1.resourceName}
subnet:
ip_addr:
addr: 192.168.110.0
type: V4
mask: 24
application_persistence_profile_ref: ${input.inp-per}
Cloud_vSphere_Machine_1:
type: Cloud.vSphere.Machine
properties:
image: CentOS
flavor: Small
networks:
- network: ${resource.Cloud_Network_1.id}
assignment: static
customizationSpec: Linux-customization
remoteAccess:
username: root
password: ${secret.passwd}
authentication: usernamePassword
count: ${input.inp-web}
Cloud_SaltStack_1:
type: Cloud.SaltStack
properties:
hosts:
- ${resource.Cloud_vSphere_Machine_1.id}
masterId: saltstack_enterprise_installer
stateFiles:
- /admin/disablefirewall.sls
- /admin/allowssh.sls
- /linux/apache/init.sls
saltEnvironment: base
Cloud_Network_1:
type: Cloud.Network
properties:
networkType: existing
constraints:
- tag: net:fix
For sure it's a simple use case, but Aria Automation allows much more than this. I recommend checking the API documentation to learn about the all properties and functionalities available.
happy automation !!!
