As you create or edit your vRealize Automation cloud templates, use the most appropriate load balancer resources for your objectives.
You can use NSX and cloud-agnostic load balancer resources in a cloud template to control load balancing in a deployment.
The cloud-agnostic load balancer can be deployed across multiple clouds. A cloud-specific load balancer can specify advanced settings and features that are available only to a specific cloud/topology. Cloud-specific properties are available in the NSX load balancer (Cloud.NSX.LoadBalancer) resource type. If you add these properties on a cloud-agnostic load balancer (Cloud.LoadBalancer), they are ignored if, for example, an Amazon Web Services or Microsoft Azure load balancer is provisioned, but are respected if an NSX-V or NSX-T load balancer is provisioned. Choose one of the available load balancer resource types based on conditions in your vRealize Automation cloud template.
You cannot connect a load balancer resource directly to a security group resource in the design canvas.
Cloud agnostic load balancer resource
Use a cloud agnostic load balancer when you want to specify networking characteristics for any type of target machine.
Cloud.LoadBalancerresource type. The default resource displays as:
Cloud_LoadBalancer_1: type: Cloud.LoadBalancer properties: routes:  network: '' instances:  internetFacing: false
NSX load balancer resource
Use an NSX load balancer when your cloud template contains characteristics that are specific to NSX-V or NSX-T (either Policy API or Manager API methods). You can attach one or more load balancers to an NSX-V or NSX-T network or to machines that are associated to an NSX-V or NSX-T network.
Cloud.NSX.LoadBalancerresource type. The default resource displays as:
Cloud_NSX_LoadBalancer_1: type: Cloud.NSX.LoadBalancer properties: routes:  network: '' instances: 
Load balancer options in cloud template code
- Machine specification
You can specify named machine resources to participate in a load balancing pool. Alternatively you can specify that a specific machine NIC participate in the load balancer pool.
This option is available for the NSX load balancer resource (
This option is available for
publicnetwork types. On-demand
outboundnetwork types are also supported.
Specifies that the load balancer include the machine identified in the cloud template code as Cloud_Machine_1.
Specifies that the load balancer only include the machine identified in the cloud template code as Cloud_Machine_2 when it is deployed to machine NIC Cloud_Machine_2.networks.
- Logging level
The logging level value specifies a severity level for the error log. The options are NONE, EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, INFO, DEBUG, and NOTICE. The logging level value applies to all load balancers in the cloud template. This option is specific to NSX. For load balancers that have a parent, the parent logging level setting overrides any logging level setting in its children.
For related information, see topics such as Add Load Balancers in NSX product documentation.
Use a load balancer type to specify a scaling size. The default is small. This option is specific to NSX. For load balancers that have a parent, the parent type setting overrides any type setting in its children.
Correlates to compact in NSX-V and small in NSX-T.
Correlates to large in NSX-V and medium in NSX-T.
Correlates to quad-large in NSX-V and large in NSX-T.
- Extra Large
Correlates to xlarge in NSX-V and large in NSX-T.
For related information, see topics such as Scaling Load Balancer Resources in NSX product documentation.
This option is only available for the NSX load balancer resource (
- Algorithm (server pool)
Use an algorithm balancing method to control how incoming connections are distributed among the server pool members. The algorithm can be used on a server pool or directly on a server. All load balancing algorithms skip servers that meet any of the following conditions:
- The Admin state is set to DISABLED.
- The Admin state is set to GRACEFUL_DISABLED and there is no matching persistence entry.
- The active or passive health check state is DOWN.
- The connection limit for the maximum server pool concurrent connections is reached.
This option is specific to NSX.
Selects a server based on a hash of the source IP address and the total weight of all the running servers.
Correlates to IP-HASH in NSX-V and NSX-T.
Distributes client requests to multiple servers based on the number of connections already on the server. New connections are sent to the server with the fewest connections. Ignores the server pool member weights even if they are configured.
Correlates to LEASTCONN in NSX-V and LEAST_CONNECTION in NSX-T.
Incoming client requests are cycled through a list of available servers capable of handling the request. Ignores the server pool member weights even if they are configured. Default.
Correlates to ROUND_ROBIN in NSX-V and NSX-T.
Each server is assigned a weight value that signifies how that server performs relative to other servers in the pool. The value determines how many client requests are sent to a server compared to other servers in the pool. This load balancing algorithm focuses on using the weight value to distribute the load among the available server resources fairly. By default, the weight value is 1 if the value is not configured and slow start is enabled.
Correlates to WEIGHTED_LEAST_CONNECTION in NSX-T.There is no correlation in NSX-V.
Each server is assigned a weight value that signifies how that server performs relative to other servers in the pool. The value determines how many client requests are sent to a server compared to other servers in the pool. This load balancing algorithm focuses on fairly distributing the load among the available server resources.
Correlates to WEIGHTED_ROUND_ROBIN in NSX-T. There is no correlation in NSX-V.
The left part of the URI is hashed and divided by the total weight of the running servers. The result designates which server receives the request. This ensures that a URI is always directed to the same server if no server goes up or down. The URI algorithm parameter has two options
uriDepth=<dep>. The length parameter range should be
1<=len<256. The depth parameter range should be
1<=dep<10. Length and depth parameters are followed by a positive integer number. These options can balance servers based on the beginning of the URI only. The length parameter indicates that the algorithm should only consider the defined characters at the beginning of the URI to compute the hash. The depth parameter indicates the maximum directory depth to be used to compute the hash. One level is counted for each slash in the request. If both parameters are specified, the evaluation stops when either is reached.
Correlates to URI in NSX-V. There is no correlation in NSX-T.
HTTP header name is looked up in each HTTP request. The header name in parentheses is not case-sensitive. If the header is absent or does not contain any value, the round robin algorithm is applied. The HTTPHEADER algorithm parameter has one option
Correlates to HTTPHEADER in NSX-V. There is no correlation in NSX-T.
URL parameter specified in the argument is looked up in the query string of each HTTP GET request. If the parameter is followed by an equal sign = and a value, then the value is hashed and divided by the total weight of the running servers. The result designates which server receives the request. This process is used to track user identifiers in requests and ensure that a same user ID is always sent to the same server as long as no server goes up or down. If no value or parameter is found, then a round robin algorithm is applied. The URL algorithm parameter has one option
Correlates to URL in NSX-V. There is no correlation in NSX-T.
For related information, see topics such as Add a Server Pool for Load Balancing in NSX product documentation.
NSX-V and NSX-T networks and load balancer options
Load balancer options depend on the network that the load balancer resource is associated to in the cloud template. You can configure a load balancer relative to the network type and network conditions.
- On-demand outbound network
If the load balancer computes are attached to an on-demand
outboundnetwork, a load balancer is created for the Tier-1 router of the on-demand network.
- On-demand private network
If the load balancer computes are attached to an on-demand
privatenetwork, a new Tier-1 router is created and attached to the Tier-0 router specified in the network profile. The load balancer is then attached to the Tier-1 router. The Tier-1 router VIP advertisement is enabled if the VIP is on an
existingnetwork. If a
privatenetwork is configured for DHCP, the private network and load balancer share the Tier-1 router.
- Existing network
If the load balancer is attached to an
existingnetwork, the load balancer is created with the Tier-1 router of the existing network. A new load balancer is created if there is no load balancer attached to the Tier-1 router. If the load balancer already exists, new virtual servers are attached to it. If the
existingnetwork is not attached to a Tier-1 router, a new Tier-1 router is created and attached to a Tier-0 router defined in the network profile, the Tier-1 router VIP advertisement is not enabled.
- Network isolation defined in the network profile
For network types of
private, you can specify network isolation settings in a network profile to emulate a new security group. Because machines are attached to an existing network and isolation settings are defined in the profile, this option is similar to a load balancer created on an existing network. The difference is that to enable the data path, the Tier-1 uplink port IP is added to the isolation security group.
You can specify load balancer settings for NSX-associated networks by using an NSX load balancer resource in the cloud template design.
To learn more, see VMware blog post vRA Cloud Assembly Load Balancer with NSX-T Deep Dive.
Reconfiguring logging level or type settings when multiple load balancers share an NSX-T Tier 1 or NSX-V Edge
When using a cloud template that contains multiple load balancers which share a Tier-1 router in the NSX-T endpoint or an Edge router in the NSX-V endpoint, reconfiguring the logging level or type settings in one of the load balancer resources does not update the settings for the other load balancers. Mismatched settings cause inconsistencies in NSX. To avoid inconsistencies when reconfiguring these logging level and/or type settings, use the same reconfiguration values for all the load balancer resources in the cloud template which share a Tier 1 or Edge in their associated NSX endpoint.
Available day 2 operations
When you scale in or scale out a deployment that contains a load balancer, the load balancer is configured to include newly added machines or to stop load balancing machines that are targeted for tear down.
For a list of common day 2 operations that are available for cloud templates and deployments, see Welke acties kan ik op vRealize Automation Cloud Assembly-implementaties uitvoeren.
For information about defining load balancer settings in a network profile, see Meer informatie over netwerkprofielen in vRealize Automation
For examples of cloud template designs that include load balancers, see Network, security, and load balancer examples in vRealize Automation cloud templates.