Contact Us 1-800-596-4880
  1. Homepage
  2. CloudHub

  3. Dedicated Load Balancers

Dedicated Load Balancers

CloudHub dedicated load balancers (DLBs) are an optional component of Anypoint Platform that enable you to route external HTTP and HTTPS traffic to multiple Mule applications deployed to CloudHub workers in a Virtual Private Cloud (VPC).

Dedicated load balancers enable you to:

  • Handle load balancing among the different CloudHub workers that run your application.

    If the target CloudHub application has multiple workers and they don’t respond within the defined timeout, the DLB makes requests to the next worker sequentially. The default timeout value is 300 seconds.

  • Define SSL configurations to provide custom certificates and optionally enforce two-way SSL client authentication.

  • Configure proxy rules that map your applications to custom domains.

    This enables you to host your applications under a single domain.

To use a dedicated load balancer in your environment, you must first create an Anypoint VPC. Because you can associate multiple environments with the same Anypoint VPC, you can use the same dedicated load balancer for your different environments.

You can view the load balancer and Anypoint VPC endpoints in your Anypoint Platform organization from the API portal.

Create and Configure a Dedicated Load Balancer

To create and configure a load balancer, you must be an administrator of the organization to which the load balancer is associated.

DLB names must be unique across all DLBs defined in Anypoint Platform (by all MuleSoft customers).

There are three ways to create and configure a dedicated load balancer for your Anypoint VPC:

For a full description of loadbalancers and vpcs endpoints, see the CloudHub API.

Dedicated Load Balancer Licensing

Each DLB unit that you purchase is the equivalent of two workers handling load balancing between CloudHub workers. You can assign up to four load balancer units to a DLB. A DLB with four load balancer units assigned has eight workers.

Static IP Addresses

If you enable static IP addresses for a DLB, the number of static IP addresses allocated to the DLB is equal to double the number of workers. For example, if your DLB has four workers, the DLB has eight associated static IP addresses.

Half the static IPs (equal to the number of worker instances) are in use at any given time. When you restart or update the DLB, the DLB switches to use the group of unused static IP addresses and transitions the first group of static IP addresses to the unused state.

Switching between the two groups of static IP addresses enables zero-downtime restarts and updates, ensuring that no transactions are dropped or lost as long as the transaction times are shorter than 600 seconds or the value of Mule Application Response Timeout (whichever is smaller).

Considerations

  • Because static IPs change when you restart or update your DLB, use the DLB’s DNS address rather than the IP addresses when calling the DLB from an external service. Ensure that the client includes the necessary retry mechanisms to account for the DNS switch.

  • To avoid connection issues when the load balancer is restarting, adhere to the DNS TTL (30 seconds), including connection keep alive. The connections are closed after the new workers are online and the TTL expires.

  • DLB uses DNS-based routing to distribute traffic across DLB workers and returns the IP address of all DLB workers to the calling client. A single DLB worker might receive all the client traffic within the TTL window regardless of the amount of transactions per second. To avoid this, ensure that you have granular load distribution between the DLB workers by alternating between the IP addresses returned in the DNS resolution.

  • When the DLB is stopped during configuration change, the DNS are deleted. If, at restart, there is DNS lookup, the NXDOMAIN error is cached for 15 minutes. To avoid this negative cache, ensure that you stop all API calls.

  • Proxy buffering is enabled by default in Anypoint Dedicated Load Balancers. This feature stores the response from a server in internal buffers as it comes in, and delays sending data to the client until the entire response is buffered. Proxy buffering helps optimizing performance with slow clients, as it allows the proxied server to return its response quickly and serve other requests. However, it is not ideal for small payload streaming, as the buffer bucket can take longer to fill in. To avoid performance problems in small payload streaming, disable proxy buffering by passing no in the X-Accel-Buffering response header field.

For DLBs created before October 2021, click Update to enable the feature. After clicking Update, the DLB uses the static IP model described earlier, and you cannot revert to the former model.

For information about updating DLBs, see Dedicated Load Balancer Updates.

See Also