In this article, I will take you through the architecture of Anypoint Dedicated and Shared Load Balancers. I also will discuss the key difference between Dedicated and Shared Load Balancer.
Two types of Load Balancers
MuleSoft provides 2 types of load balancers:
- Shared Load Balancer
- Dedicated Load Balancer
Whenever you deploy your application to CloudHub, it provides a default load balancer which is a multitenant and known as Shared Load Balancer. Shared Load Balancer provides basic functionalities like TCP load balancing but it is not possible to implement custom domains or custom SSL certificates on Shared Load Balancer. Shared Load Balancer also comes with rate limiting. To access the application over a Shared Load Balancer, we can use <app_name>.region.cloudhub.io
To overcome the limitation of the Shared Load Balancer (SLB), MuleSoft provides another load balancer that is known as a Dedicated Load Balancer. Dedicated Load Balancer is the optional component of the Anypoint Platform which allows you to route traffic to applications deployed on CloudHub within Anypoint Virtual Private Cloud.
To create a Dedicated Load Balancer, there must be at least one Anypoint Virtual Private Cloud existing and associated with one or more environments.
Each Dedicated Load Balancer exposes an external CNAME record lb-name.lb.anypointdns.net that resolves to the two or more public IP addresses and internal CNAME internal-lb-name.lb.anypointdns.net.
The importance of Dedicated Load Balancer
- One of the limitations of SLB is the lower rate limit. To avoid that issue, you can use a Dedicated Load Balancer (DLB).
- All applications can be hosted under a single domain.
- Custom SSL certificates can be configured on DLB.
- Handle load balancing among the different Cloudhub workers that run your application.
- To access APIs publicly or whitelisted clients deployed within VPC.
- To support Mutual Authentication (Two Way SSL).
Whitelisted CIDRs
To allow Dedicated Load Balancers to be used by a set of IP addresses or single IP addresses, you need to add those IP addresses in the form of CIDR notations (e.g. 192.168.1.0/24).
By default, all the public traffic allowed on DLB as default CIDR allowed is 0.0.0.0/0. In case if you want to allow public traffic from a few clients, you can delete the default CIDR and allow the only CIDR from which DLB has to accept the traffic.
HTTP Inbound Mode
- Off: Causes the load balancer to silently drop the request.
- On: Accepts the inbound request on the default SSL endpoint using the HTTP protocol.
- Redirect: Redirects the request to the same URL using the HTTPS protocol.
Dedicated Load Balancer: Mapping Rules
Mapping rules are used on Dedicated Load Balancers to translate input URI to call applications deployed on CloudHub. A pattern is a string that defines a template for matching an input text. Whatever value is placed within curly brackets ({ }) is treated as a variable. Variable names can contain only lowercase letters (a-z) and no other characters, including slashes.
- Input Path (inputUri) – It is the Uri that the client requests for example, /{app}/
- Target App (appName) – It is the name of the application deployed in CloudHub within the Anypoint VPC.
- Output Path (appUri) – It is the Uri string that passes to the application
- Protocol – It is the protocol on which the application is listening for example, http, https, or ws
Example 1
We are receiving requests on the DLB https://api-dev.example.com/ecommerce/v1.0/invoices and need to redirect them to http://org-ecommerce-api.cloudhub.io/v1.0/invoices (the Cloudhub application name will be org-ecommerce-api)
We can use this mapping rule to achieve this.
| Input Path | Target App | Output Path | Protocol |
| /{app} | org-{app}-api | /v1.0 | HTTP |
This rule will be applied when requests come on DLB and route to the Cloudhub application in the VPC.
https://api-dev.example.com/ecommerce/v1.0/invoices ==> http://org-ecommerce-api.us-e1.cloudhub.io:8091/v1.0/invoices
Example 2
In this case, we will be using a subdomain for routing the request to the correct environment from DLB.
Our application name format must be org-app-subdomain (e.g. org-ecommerce-api-dev for dev environment and org-ecommerce-api-test for test environment) when deploying to CloudHub workers in VPC .
So, our mapping rule will look like this.
| Input Path | Target App | Output Path | Protocol |
| /{app} | org-{app}-{subdomain} | /v1.0 | HTTP |
subdomain is variable to map any subdomain.
- https://api-dev.example.com/ecommerce/v1.0/invoices (DLB) ==> http://org-ecommerce-api-dev.us-e1.cloudhub.io:8091/v1.0/invoices (CloudHub Dev Environment)
https://api-test.example.com/ecommerce/v1.0/invoices (DLB) ==> http://org-ecommerce-api-test.us-e1.cloudhub.io:8091/v1.0/invoices (CloudHub Test Environment)
Other Configurations
- Disable Static IPs specify to use dynamic IPs, which do not persist when the DLB restarts.
- Keep URL encoding specifies the DLB passes only the %20 and %23 characters as is.
If you deselect this option, the DLB decodes the encoded part of the request URI before passing it to the CloudHub worker.
Support TLS 1.0 specifies to support TLS 1.0 between the client and the DLB. - Upstream TLS 1.2 specifies to force TLS 1.2 between the DLB and the upstream CloudHub worker.
Dedicated Load Balancer: Certificates
Configure SSL certificate to enable HTTPS (Public Key and Private Key). For two-way authentication, you can configure a Client Certificate and that is optional. The Dedicated Load Balancer must be associated with at least a pair of one certificate.
Generally, we configure the certificates on the Dedicated Load Balancer from the CA authority. For testing purposes, you can use self-signed certificates.
Note: – Always use CA-signed certificates instead of self-signed certificates. It is not recommended to use self-signed certificates as it is not secure and even not recognized by browsers and few or more clients.
As discussed above, Dedicated Load Balancer can be accessed publicly and privately as it provides internal and external CNAME.
Below is the diagram that typically shows how a request comes to a dedicated load balancer and it applies mapping rules and forward requests to the CloudHub application deployed within Anypoint Virtual Private Cloud.
Dedicated Load Balancer provides internal URLs that can be used by internal applications or clients. Typically, the URL looks like internal-lb-name.lb.anypointdns.net
Dedicated Load Balancer provides a public URL that resolves to two or more IP Addresses (i.e. depending on the number of workers allocated to the Dedicated Load Balancer). Typically, the URL looks like lb-name.lb.anypointdns.net
This external CNAME of Dedicated Load Balancer can be mapped with custom domains, this can be used by external clients to send requests to applications deployed within Anypoint Virtual Private Cloud on the private port.
Conclusion
Anypoint Dedicated Load Balancer is a very important component in the MuleSoft ecosystem for configuring custom domains, routing the traffic to applications deployed to CloudHub within Anypoint Virtual Private Cloud, enabling Mutual Authentication, etc. At Devoteam, we support the clients to identify the use cases for implementing the Anypoint DLB in a secure manner with best practices and guidelines.
Our 25+ years of integration experience in projects within every sector you can think of, combined with a strong partnership with MuleSoft, enable us to guide your organization through every API-related challenge. Looking for help with setting up Anypoint iPaaS platforms, implementing Hybrid Architecture including Anypoint VPC, DLB, and VPN? Feel free to contact us and we’ll see how we can help out.
