vRA Cloud Assembly Load Balancer with NSX-T Deep Dive

The intention of this blog post is to provide a deep dive into vRA Load Balancer features with NSX-T. I will go over what objects and why they are created in NSX-T to support different types of load balancers. I will cover what network profile settings are required to provision different types of load balancers.

vRA Cloud Assembly supports provisioning one-arm and two-arm load balancers on VMware NSX. Load balancers can be provisioned using existing networks data collected from NSX-T or on-demand networks provisioned by Cloud Assembly. Cloud Assembly supports provisioning new Load Balancing service in NSX-T or reusing existing NSX-T Load Balancing service which was data collected from NSX-T or deployed by the administrator.

Blueprint schema

Load balancer is represented as Cloud.LoadBalancer component on the blueprint canvas. Cloud.LoadBalancer component schema consists of a collection of route settings, a reference to a machine component that will be used to configure load balancer pool members and a reference to a network component that will be used to configure load balancer VIP.

Every Cloud.LoadBalancer route configuration will be translated into a load balancing pool and VIP combination in NSX-T. If a route has a healthCheckConfiguration specified, a monitor will be created in NSX-T.

## Cloud.LoadBalancer schema
web_lb:
    type: Cloud.LoadBalancer
    properties:
      routes: 
        - protocol: HTTP
          port: 80
          instanceProtocol: HTTP
          instancePort: 80
          healthCheckConfiguration: 
            protocol: HTTP
            port: 80
            urlPath: /index.html
            intervalSeconds: 5
            timeoutSeconds: 15
            unhealthyThreshold: 5
            healthyThreshold: 2
      network: '${resource.prod_net.id}'
      instances: '${resource.web_server.id}'
      internetFacing: false

Note: “internetFacing” configuration is not used for NSX-T

Create New Two-Arm Load Balancer

Here is a blueprint example with a Two-Arm Load Balancer:

“web_net” is a Cloud.Network component with on-demand networkType (outbound, routed or private)
“prod_net” is a Cloud.Network component with existing networkType (existing or public)
“web_server” is a Cloud.Machine component
“web_lb” is a Cloud.LoadBalancer component
The order in which components of this blueprint will be provisioned is as follows:
“prod_net” and “web_net” → “web_server” → “web_lb”

NSX-T configurations for Two-Arm Load Balancer

1. Load balancing service is created in the NSX-T manager. Load balancing service is attached to the Tier-1 router of the “web_net” network.

Note: If “web_net” network type is private, a Tier-1 logical router is not created for it during network provisioning. This is because private networks don’t need any routing capabilities. In order to support load balancing for this blueprint, a Tier-1 router is created during “web_lb” provisioning. The Tier-1 logical router is attached the load balancing service as well as the “web_net” private network.

2. Virtual Server is created for the Cloud.LoadBalancer “route” configuration.

Virtual Server IP address is allocated from the static IP range configured for the network selected for “prod_net” component. Note: Network selected in the network profile must be configured with a static IP range.

3. Application profile is created for the Cloud.LoadBalancer “route” configuration.

4. Server Pool is created for the Cloud.LoadBalancer “route” configuration.

Server pool is configured with “Automap” “SNAT Translation Mode” to allow inline load balancing.

All machines provisioned for the “web_server” Cloud.Machine component are added to the pool as members.

5. Monitor is created for the “healthCheckConfiguration” of the Cloud.LoadBalancer “route” schema.

6. Tier-1 logical router is attached to the Edge cluster and the Tier-0 logical router which are selected in the network profile.

Tier-1 router is configured to advertise Load Balancer VIP address upwards to Tier-0 router.

Create New One-Arm Load Balancer

Here is a blueprint example with a One-Arm Load Balancer:

“prod_net” is a Cloud.Network component with existing networkType (existing or public)
“web_server” is a Cloud.Machine component
“web_lb” is a Cloud.LoadBalancer component
The order in which components of this blueprint will be provisioned is as follows:
“prod_net” → “web_server” → “web_lb”

NSX-T configurations for One-Arm Load Balancer

1. Load balancing service is created in the NSX-T manager. Similar to Two-Arm load balancer, “routes” are translated to virtual servers, application profiles, service pools and monitors in NSX-T.

2.Tier-1 logical router is created and attached to the new load balancing service. Tier-1 router is configured with edge cluster allocated from the network profile. Tier-1 router is NOT attached to a Tier-0 router. Instead, network selected for the “prod_net” component is attached to the Tier-1 router via a Centralised service port. Centralised service port allows attaching logical switch to more than one Tier-1 logical router and enables VIP advertisement without the need to attach Tier-1 router to Tier-0 router.

Re-Use Load Balancing Service

You can choose to re-use an existing NSX-T load balancer service for all application deployed within a project. You can create a Load balancer service directly in the NSX-T manager or you can deploy a new NSX-T load balancer service using a Cloud Assembly blueprint.

Select an existing load balancer service on the network profile Load Balancers tab. All blueprints with load balancer components that land on the network profile will use selected load balancer service to provision virtual servers, application profiles, service pools and monitors. Virtual servers, application profiles, service pools and monitors created for the deployment will be removed from the existing load balancing service when the deployment is destroyed, but the load balancing service itself will not be removed.

Note: Virtual Server IP address is allocated is always allocated from a static IP range configured for the network attached to the load balancer. Network selected in the network profile must be configured with a static IP range even if you reusing existing load balancer.

Note: If a blueprint with a load balancer component is provisioned with an on-demand outbound or private network, new load balancer service is always created in NSX-T. Load balancer selected in the network profile is not used for such applications. This is because machines provisioned with on-demand outbound or private networks will not be accessible from the Tier-1 router of the existing load balancer selected in the network profile. Tier-1 router created for the on-demand outbound or private networks are used to configure load balancing.

Deploy Re-Usable Load Balancer

In order to deploy a re-usable load balancer using a Cloud Assembly blueprint:

Create a blueprint with a Cloud.LoadBalancer component. You can set “instances” schema to an empty collection;
Deploy the blueprint;
When the deployment is created successfully, add the resulting Load Balancer to the network profile.

Note: Once the load balancer is used to deploy other applications, it will not be possible to destroy the deployment that created it. You will need to destroy all other deployments that use network profile load balancer before you can destroy the deployment that created it.

Network Profile

When Cloud.LoadBalancer object lands on an NSX-T network profile, a static IP address is allocated for the load balancer VIP. Existing or public Cloud.Network component attached to Cloud.LoadBalancer component must be allocated on network that has a static IP range configured.

You can configure existing or public network to support static IP allocation:

Click on the network name to edit network details;
Specify IPv4 CIDR, optionally configure other IPAM settings;
Click Save.

To create a static IP range for existing or public network:

Select a network that has CIDR configured and click “Manage IP Ranges” button;
Click “New IP Range”;
Give range a name, start IP address and end IP address;
Click Create.

Network Policies

Network profile → Network Policies → Network Resources section configures pre-exisitng NSX-T resources that are used to provision Cloud.LoadBalancer components. This section should be configured according to the load balancer type you would like to provision.

Two-Arm Load Balancer:

Tier-0 router is required to provision a two-arm load balancer. Tier-0 router is attached to the Tier-1 router created for the Load Balancer. Load Balancer VIP is advertised upwards to the Tier-0 router.
Edge cluster is required to provision a two-arm load balancer. Tier-1 router is configured with the edge cluster to support load balancing services.

One-Arm Load Balancer:

Tier-0 router is NOT required to provision one-arm load balancer. Instead of connecting the Tier-1 router to a Tier-0 router, load balancer network is attached to the Tier-1 router in “Centralised” mode which allows load balancer VIP advertisement without attaching Tier-1 router to Tier-0 router.
Edge cluster is required to provision one-arm load balancer. Tier-1 router is configured with the edge cluster to support load balancing services.

Note: It is not required to select either Tier-0 logical router or edge cluster if you choose to re-use existing load balancer service on the next tab.

Load Balancers

Alternatively, you can choose to re-use existing NSX-T load balancing service to provision load balancer applications. If you select an existing load balancer service on this tab, all on-demand load balancer will use existing load balancer service to configure service pools, VIPs, profiles and monitors.