Skip to content

Chapter 2

Dedicated Load Balancer

In order to handle the situation of rate-limiting and balancing the load internally, Mulesoft offers dedicated load balancers (DLBs) as an optional component of the Anypoint Platform that enables you to route external and internal HTTP and HTTPS traffic to multiple Mule applications deployed to CloudHub. It works like Shared Load Balancer but you will have much more control over it, like scalability, vanity domain, your very own SSL certificates, and two-way TLS configuration.

As you can see from the VPC architecture of CloudHub with a Dedicated Load Balancer (Diagram 3), the DLB sits inside of your VPC and while routing incoming traffic, it will route to 8091 and 8092 ports. So, don’t forget to remove the default firewall rules of the VPC that allows the traffic to 8081 and 8082 ports from (Anywhere). That will rule out the Shared Load Balancer and accessing your Mule Workers will only be possible over the DLB and Mapping Rules.

You can create and manage your Dedicated Load Balancers via Anypoint Platform > Runtime Manager or CloudHub API or Anypoint CLI.

Technical Aspects of a DLB

You might wonder, what will you get when you have this optional component? Every Dedicated Load Balancer license must be associated with a VPC, therefore you cannot use a DLB for more than 1 VPC. That is only logical since the DLB will sit inside of a VPC and is going to balance the traffic throughout the  VPC. 

Each DLB by default runs in a highly available configuration with 2 workers (instances). Every one of the instance’s sizes is configured as 2 vCores + 3.5 GB Memory. About the scalability; you can scale your DLBs horizontally, but unfortunately, at the moment, not vertically. There is no way you can upsize or downsize the workers.  Also, you can only use even numbers for the worker count due to HA, meaning your DLB can run on 2, 4, 6, or 8 workers. Most of the time 2 instances of workers will be sufficient. However, based on your incoming traffic (number of requests hitting the DLB), total application number behind the DLB, size of the data for requests, the response time of your Mule Applications or back-end applications (longer the response time, longer the DLB resources consumed), you may still need more than 2 workers. Just a reminder, every 2 workers will consume 1 DLB license.

DLBs mainly use the round-robin mechanism to distribute the load, but not always. Algorithms try to do it evenly but sometimes need to adapt, depending on the application’s performance. DLB’s response timeout is 300 seconds as default and can be changed. Connect timeout is 4 seconds per worker (4 times it tries for a TCP handshake and waits for 1 second per try). If the attempt fails for one worker, it gets another IP from the internal DNS for subsequent workers. When there are no more workers left, it responds with a Connect Timeout.

You can observe an example communication diagram for DLB and the workers(Diagram 4).