The NSX LB AutoScale Automation Tool is a PowerNSX script developed by Dimitri Desmidt, NSX Senior Technical Product Manager @ VMware.
The tool is opensource and you can find it on VMware PowerNSX Github: https://github.com/vmware/powernsx/tree/master/Examples
It’s super-easy to configure but very powerful.
In an environment based on vCenter and NSX-v, you can easily leverage this tool to auto-scale (growing and shrinking aka “Elastic LB”) your load balanced pools of VMs based on their load.
What the script does?
- It checks the load (CPU and RAM) on all LB Pool members;
- If the load is above a threshold:
- vCenter Server deploys a new VM (from a template configured like the LB Pool members);
- NSX Manager adds this new VM to the LB Pool as a new member;
- When the load is below a threshold:
- NSX Manager removes a VM from the pool;
- vCenter Server deletes the VM.
To test the tool I want to use a 3-tier application made by 2 load balanced Web Servers, an Application Server and a DB Server.
I’ll artificially create load on one of the Web Servers to trigger a condition where the AutoScale Tool will deploy a new VM and add it the LB Pool.
As a second step, I’ll reset CPU load to a normal condition to trigger the deletion of the new VM.
This is the high-level architecture of my infrastructure for the 3-tier app:
To leverage the AutoScale Tool, it is important to note the relevant objects in the vCenter inventory.
We will use these elements to configure the PowerNSX script later.
My 3-tier App is hosted in a vSphere Cluster named “Compute Cluster A“.
In the following screenshot you can see the VMs that make the App: 2 Web Servers, 1 Application Server and 1 Database Server.
Highlighted you can see the 2 Web Servers, web-01a and web-02a, members of the Load Balancer Pool we’ll monitor and extend when needed using the AutoScale Tool.
A template VM, configured like the Web Servers already members of the Load Balancer Pool, has been prepared and will be used as a baseline for all new LB Pool members when needed.
The Edge Gateway providing the Load Balancing Services for my 3-tier App is named “OneArm-LoadBalancer-01“.
I’ve configured a Load Balancing Pool named Web-Tier-Pool-01. The 2 Web Servers of my application, web-01a (172.16.10.11) and web-02a (172.16.10.12), are configured as members of the Pool.
In my scenario, the Load Balancing algorithm has been set to Round Robin, but this doesn’t affect the behavior of the Tool.
The Web-Tier-Pool-01 LB Pool is configured as the default Pool for the Virtual Server Web-Tier-VIP-01. The configured Virtual IP is 172.16.10.10.
My application is registered in the DNS as webapp.corp.local, resolved in the Virtual IP address of the LB Virtual Server.
Access to the application shows me that the Web Server web-02a is serving my request.
To test the AutoScale Tool, I artificially create a 100% CPU Usage on web-01a. The expected behavior is that the AutoScale Script will detect the anomaly and will trigger the deploy of a new Web Server that will be added to the Pool.
The Script can be easily scheduled to run as frequently as needed (for example every 1 minute), check the Load Balancer pool members performance and trigger the needed action.
The AutoScale Script is structured with a custom section where you can configure all the needed variables to connect to your environment and define the expected behavior.
The expected settings are very well explained, you can see the details in the following screenshot where I’m showing my configuration.
Note the name of the target Compute Cluster, the name of the Template VM, the name of the Edge Gateway, LB Pool and LB Virtual Server are the one I’ve highlighted in my vCenter and NSX inventory screenshots.
Let’s wait for the next scheduled run.
The Tool detects an 87% average load on web-01a CPU and trigger the creation of a new VM named Web_Clone1.
Here you can see the vCenter task that is creating the Web_Clone1 VM deploying it from the template named Web-Template.
The Script ends with the addition of the new VM to the Load Balancing Pool for my 3-tier application.
I’ve configured the script for a maximum of 3 Pool members and a minimum of 2, this means that starting from the next run it will monitor for the need to shrink the Pool if load will decrease, but it will not add any additional member even if I’ll have additional load. This configuration can be easily change editing the $VM_Min and $VM_Max variables.
Here you can see the additional member (Web_Clone1) added to the LB Pool.
Access to the application shows me that Web_Clone1 is actively serving content for my App.
On the next run of the Tool, web-01a CPU usage is still high. No actions are triggered because my $VM_Max variable is set to 3.
At this point I stop the process causing CPU load on web-01a and wait for the next run of the Tool.
As soon as CPU load is below the threshold, the removal of Web_Clone1 from the LB Pool and its deletion from vCenter are triggered.
My 3-tier App is now back in normal state with 2 Load Balanced Web Servers.
Conclusion: if you’re looking for a simple and very powerful way to manage the Auto-Scaling of your load balanced workloads in a vCenter+NSXv environment, you definitely have to try the NSX Load Balancer AutoScale Automation Tool.