Updated Feb, 2021
The final blog in my series on network automation with Cloud Assembly and NSX will focus on creating on-demand load balancers, using existing load balancers, and reconfiguring load balancers after deployment. I recommend going through part 1, part 2, and part 3 of this blog series if you’re new to Cloud Assembly.
On-Demand Load Balancers
On demand load balancers can be created with or without attached VMs. Load balancers are defined within a cloud template and can be used for other deployments similarly to how on-demand networks can be used. At deploy time, a load balancer, virtual server, server pool, and monitor are added to NSX except with provider load balancers. A load balancer created without an attached VM in the cloud template is called a provider load balancer. When a provider load balancer is created in NSX, the virtual server, server pool, and monitor aren’t created until VMs are associated. The example in the screenshot shows a cloud template configured to create a provider load balancer. You can add either a cloud agnostic load balancer or NSX load balancer to the canvas. The main difference is an NSX load balancer supports UDP in addition to TCP. The load balancer configuration is highlighted in blue on the YAML portion of the cloud template.
Attaching VMs to on-demand load balancers is handled in a cloud template. After adding a load balancer to the canvas, simply hover the mouse cursor over the left edge of the load balancer object on the canvas until a blue circle appears and click drag to the VM you want to associate. You will see a visual connection line appear between the load balancer and object similarly to what is displayed in the screenshot. Once connected, the instances property will update with the machine name that will be added to the load balancer server pool at deployment time.
With the August 2020 release of vRealize Automation Cloud and vRA 8.2, you can now set a load balancer’s size, logging level, and algorithm. These configurations are set within the YAML code of a Cloud Template.
To set the new YAML configurations, under the load balancer properties, add loggingLevel, type, and algorithm. These are defined based on NSX configurations and will be set at deployment time.
Existing Load Balancers
Existing load balancers are added from the network profile that is used for the deployment. Within the network profile choose Load Balancers -> Add Load Balancer and choose the discovered or deployed load balancers in your environment. Exactly like networks, Discovered origin means the load balancer was created manually or through other methods in NSX. A Deployed origin indicates the load balancer was deployed by Cloud Assembly. In the example, I choose the provider load balancer that was created using the first cloud template. You can also use constraint tags to determine the load balancer. If a load balancer is selected in the network profile and defined in the cloud template, as shown above, a new virtual server is created for the existing load balancer with the YAML configurations.
All load balancers that are discovered or deployed can be viewed within the Infrastructure -> Resources -> Networks -> Load Balancers tab. Using this interface, you can quickly learn more about the load balancers that are under Cloud Assembly management, including Cloud Account/Region, whether the load balancer is Internet facing, the Origin, and associated constraint tags.
Selecting a load balancer name opens a details page. The details page provides further information on IP address, usage, routes, custom properties, health check configuration, and the ability to add a constraint tag.
Day-2 Reconfiguration of Load Balancers
Cloud Assembly also supports reconfiguring load balancers as a day-2 action. To reconfigure a load balancer navigate to the Deployments screen, select a deployment which includes a load balancer, click the load balancer in the Topology view, then click the Actions dropdown and select Reconfigure.
A reconfigure window opens. You can adjust the load balancer size, set the logging level, and add or adjust the routes, including the algorithm, plus delete the load balancer.
Protocol, port, and health check configuration can be added or modified. Once submitted, a reconfigure operation runs and makes the desired changes in NSX. Public cloud load balancer reconfiguration is supported as well.
For the August 2020 release of vRealize Automation Cloud and vRA 8.2, you can also set the load balancer size and logging level as a day-2 action.
NSX Sizing
Load balancers are a core part of NSX and Cloud Assembly. If the goal is to use Cloud Assembly to create on-demand load balancers, make sure to size your NSX architecture accordingly, particularly Edge VM sizing. Sizing NSX is critical to support the needed number of load balancer instances, virtual servers, pools and pool members. If you found that your Edge VM sizing is too small, it’s very straightforward to replace existing Edges with larger Edge sizes in NSX-T. Our VMware LiveFire team put together a great blog post on replacing Edges in NSX-T with the desired VM size. NSXv allows a change appliance size operation for existing Edges, versus a full replacement, this can be accomplished in the networking and security -> NSX Edges interface in the vSphere Web Client.
This blog post wraps up my four part series on Network Automation with Cloud Assembly and NSX. I hope the information has been valuable as you build out NSX and Cloud Assembly in your environment. I will be updating the series as we introduce new features in each product. Stay tuned!
Network Automation with Cloud Assembly and NSX part 1 – Network Automation with Cloud Assembly and NSX part 2 – Network Automation with Cloud Assembly and NSX part 3
