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.

You add a cloud agnostic load balancer by using the Cloud Agnostic > Load Balancer resource on the cloud template design page. The resource displays in the cloud template code as a Cloud.LoadBalancer resource 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.

You add an NSX load balancer by using the NSX > Load Balancer resource. The resource displays in the cloud template code as a Cloud.NSX.LoadBalancer resource 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

Adding one or more load balancer resources to your cloud template allows you to specify the following settings. Some examples are available at Networks, security resources, and load balancers in vRealize Automation.

The HTTP protocol is supported for all on-demand load balancers.

The HTTPS protocol is supported only for on-demand load balancers that are associated to an NSX-T cloud account whose NSX mode is set to Policy. NSX-T cloud accounts whose NSX mode is set to Manager cannot use the HTTPS protocol.

  • 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 (Cloud.NSX.LoadBalancer) only.

    • resource.Cloud_Machine_1.id

      Specifies that the load balancer include the machine identified in the cloud template code as Cloud_Machine_1.

    • resource.Cloud_Machine_2.networks[2].id

      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[2].

  • 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.

  • Type

    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.

    • Small

      Correlates to compact in NSX-V and small in NSX-T.

    • Medium

      Correlates to large in NSX-V and medium in NSX-T.

    • Large

      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 available for the NSX load balancer resource (Cloud.NSX.LoadBalancer).

  • 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.

    • IP_HASH

      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.

    • LEAST_CONNECTION

      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.

    • ROUND_ROBIN

      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.

    • WEIGHTED_LEAST_CONNECTION

      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.

    • WEIGHTED_ROUND_ROBIN

      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.

    • URI

      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 uriLength=<len> and 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.

    • HTTPHEADER

      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 headerName=<name>.

      Correlates to HTTPHEADER in NSX-V. There is no correlation in NSX-T.

    • URL

      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 urlParam=<url>.

      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.

  • Health monitor

    Use the health monitor options to test whether a server is available. Active health monitoring for HTTP, ICMP, TCP, and UDP protocols is supported. Passive health monitoring is available for NSX-T only.

    This option is specific to NSX.

    • httpMethod

      HTTP method to use to detect server status for the health check request. Methods are GET, HOST, OPTIONS, HEAD, or PUT.

    • requestBody

      Health check request body content. Used, and required, by HTTP, TCP, and UDP protocols.

    • responseBody

      Health check expected response body content. If the received string matches this response body, the server is considered healthy. Used, and required, by HTTP, TCP, and UDP protocols.

    Note: If you use the UDP monitor protocol, the UDP Data Sent and UDP Data Expected parameters are required. The requestBody and responseBody properties map to these parameters.

    This option is available for the NSX load balancer resource (Cloud.NSX.LoadBalancer).

    For related information, see topics such as Configure an Active Health Monitor in NSX product documentation.

  • Health check

    Use health check options to specify how the load balancer performs its heath checks.

    This option is only available for the NSX load balancer resource (Cloud.NSX.LoadBalancer).

    For a sample of available heath check settings, see Networks, security resources, and load balancers in vRealize Automation.

NSX-V and NSX-T network types 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 network

    If the load balancer computes are attached to an on-demand network, 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 existing network. If an on-demand network is configured for DHCP, the on-demand network and load balancer share the Tier-1 router.

  • Existing network

    If the load balancer is attached to an existing network, 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 existing network 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.

    vRealize Automation does not support an NSX-T two-arm load balancer (inline load balancer) on two different existing networks. Note that in a two-arm load balancer scenario, the VIP uplink is on an existing network while the pool member machines are connected to an on-demand network. To specify load balancing when using an existing network, you must configure a one-arm load balancer where the same existing network is used for the load balancer VIP and the pool member machines. However starting with vRealize Automation 8.4.2, if you are using a load balancer that you've selected in the network profile, you can load balance between machines on two different existing networks if there is connectivity between the two existing networks.

  • Network isolation defined in the network profile

    For network types of outbound or 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.

NSX-T load-balancer profile persistence

vRealize Automation cloud templates and deployments support NSX-T load balancer persistence profile options for SOURCE_IP and COOKIE settings. For information about how to configure these settings in NSX-T so that they can be consumed by vRealize Automation cloud templates and deployments, see Add a Persistence Profile in NSX-T documentation.

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 What actions can I run on Cloud Assembly deployments.

Learn more

For information about defining load balancer settings in a network profile, see Learn more about network profiles in vRealize Automation.

For examples of cloud template designs that include load balancers, see Networks, security resources, and load balancers in vRealize Automation.