This blog will cover the architecture of the dedicated load balancer and the importance of the mapping rules in the dedicated load balancer with detailed examples. It’s important to understand how the mapping rules can be used within the dedicated load balancer in MuleSoft’s ecosystem. Mapping rules are important for routing the requests to the applications deployed to Cloudhub Runtime Manager within Anypoint Virtual Private Cloud (VPC).
MuleSoft provides two types of load balancers, shared load balancer and dedicated load balancer which will distribute the traffic among the cloud workers. Each application deployed to CloudHub will have a shared load balancer that is multitenant. Shared load balancer provides functionalities like TCP load balancing — but at the same time it has lower rate limits, and doesn’t allow you to configure custom SSL certificates, and configure custom DNS. To overcome the limitations of the shared load balancer, you can use the dedicated load balancer.
Dedicated load balancer is an optional component in Anypoint Platform and which accepts the HTTP/HTTPS requests from the clients and route the request to the application deployed in Anypoint VPC. It is one of the powerful components in Anypoint Platform ecosystems and provides more features and control as compared to shared load balancers.
To create a dedicated load balancer, you must first create an Anypoint VPC that can be associated with one or more environments. The same dedicated load balancer can be used with different environments within the same VPC.
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.
For example, dedicated load balancers created within Anypoint VPC are associated with the dev and test environments. There is a possibility that you can register two external DNS (api-dev.example.com for the dev environment and api-test.example.com for the test environment) that resolve to the same dedicated load balancer public IP addresses. Mapping rules are the attributes of the load balancer SSL endpoints and they are recognized by certificate common name (CN).
Lets understand with few use cases where dedicated load balancers can be used within Anypoint Platform.
Dedicated load balancer use cases
Use Case 1
We have the requirement that when we deploy the application in CloudHub, it gives a domain URL for accessing the application. Each application will have its own domain URL and typically it looks like <appName>.region.cloudhub.io. But the client wants to host all the applications deployed in the CloudHub under the same domain.
We can create a dedicated load balancer within VPC. Once a dedicated load balancer has been created, it can be used to accept the request over the same host and route the request to the upstream api deployed in CloudHub within Anypoint Virtual Cloud.
Use Case 2
We have a requirement that applications deployed within Anypoint VPC on the private port (8091/8092) and those applications need to be accessed by an external client.
In this case, when we deploy the application in Anypoint VPC, it cannot be directly accessed by the external client. To enable application access to the external client, we require to create a dedicated load balancer within the same Anypoint VPC.
Use Case 3
We have a requirement that currently applications deployed in CloudHub can be accessed by a shared load balancer, and is enabled with rate limit policies. Due to this, some of the client requests are rejected with 503 – Service Unavailable when the number of requests or traffic increases.
In this case, we can use the dedicated load balancer as it doesn’t have any rate limiting policies applied on it and it can allow any number of requests.
Dedicated load balancers provide few important concepts that need to be known while configuring the dedicated load balancer.
Classless inter-domain routers
To enable dedicated load balancers, they must be used by a set of IP addresses or single IP addresses. You will need to add those IP addresses in the form of CIDR notations such as 192.168.1.0/24. By default, all of the public traffic allowed on a DLB is 0.0.0.0/0. If you want to allow public traffic from a few clients, you can delete the default CIDR and allow only CIDR from which the dedicated load balancer has to accept traffic.
This is useful when there is a requirement that your dedicated load balancer can be accessed publicly by the fewer clients. Lets consider allowed CIDR is 192.168.1.0/24, in this case dedicated load balancer will allow traffic from that CIDR only and it will drop traffic from other IP ranges as shown in below diagram.
Certificates
It is mandatory to have at least one certificate associated with a dedicated load balancer. To enable the SSL endpoint to serve the client, there must be a private and public key configured on your dedicated load balancer. Dedicated load balancers can have one or more SSL endpoints, each identified by the Server Certificate Common name.
Certificates are important to enable the SSL handshake between client and dedicated load balancer. A dedicated load balancer also supports Mutual Authentication (Two Way SSL).
Certificates must be contained in one unencrypted, PEM file. It can support multiple DNS as well as wildcard certificates (e.g. *.example.com).
Inbound HTTP Mode
Inbound HTTP Mode basically defines the behavior of the load balancer when receiving the HTTP request. This is one of the most important settings in the dedicated load balancer configuration, as it defines whether dedicated load balancer can accept the request on HTTP or HTTPS protocol and do dedicated load balancer needs to perform SSL Offloading or SSL Tunneling. Below are the three options provided:
- Off – Dedicated load balancer will silently drop all HTTP requests. It will only accept traffic on HTTPS.
- On – Dedicated load balancer will accept the traffic on default SSL endpoints using the HTTP protocol.
- Redirects – Dedicated load balancer will redirect the traffic to the same url using HTTPS protocol.
Mapping rules
Mapping rules is one of the vital components in the dedicated load balancer as it is responsible for routing the request to the applications within the CloudHub environment. It is important to implement the mapping rules and those mapping rules will be associated with the certificates defined in the dedicated load balancer. Mapping rules may vary depending on the requirements, subdomain, naming conventions of applications deployed in the CloudHub and the environments.
To add mapping rules, we need to understand a few parameters:
- 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
The values defined within the curly brackets ({ }) are treated as variables and the variables cannot be used in the output path. Variable names can contain only the characters in lower case a-z and no other characters.
Mapping rules examples
Below are a few specific examples to help better understand all of the information discussed above:
Example 1
The application name can be passed as the input path and can be directly mapped to the application in CloudHub.
Examples include:
- Map requests the rules https://api-dev.example.com/{app} and redirects them to http://{app}.region.cloudhub.io/.
- Inbound requests https://api-dev.example.com/ecommerce-dev/invoices, redirect to https://ecommerce-dev.us-e1.cloudhub.io:8091/invoices
The {app} is thereby eCommerce. An example of the dedicated load balancer mapping rules can be seen below.
Example 2
Another common use case is using wildcard certificates (*.example.com). When using wildcard certificates, you can use a subdomain variable to map the subdomain.
Subdomain plays a critical role in routing the request to the right applications in a particular environment within Anypoint VPC. For example, a dedicated load balancer uses wildcard certificates and externally resolves them by the api-dev.example.com for the dev environment and the api-test.example.com for the test environment.
Applications deployed on a dev environment will be named appName-api-dev and applications deployed on a test environment will be named appName-api-test.
Let’s consider the below mapping rule which uses the subdomain to route the request to the right application in a particular environment.
Subdomain is the variable to map:
- Inbound request on https://api-dev.example.com/ecommerce/invoices (DLB) to http://ecommerce-api-dev.us-e1.cloudhub.io:8091/invoices (CloudHub Dev Environment)
- Inbound request on https://api-test.example.com/ecommerce/invoices (DLB) to http://ecommerce-api-test.us-e1.cloudhub.io:8091/invoices (CloudHub Test Environment)
Dedicated load balancer mapping rules priority
Dedicated load balancer will apply the first matching rule regardless of more exact matching rules available. A rule defined first, at index 0, has higher priority against other rules defined after it. The higher the index assigned, the less priority the mapping rule has.
There are three different ways of setting up dedicated load balancer
- Anypoint Platform Runtime Manager
- Anypoint CLI
- CloudHub load-balancer creates “mule-demo-vpc” “mule-demo-lb” “example-public.pem” “example-com-private.pem” –http off
- Anypoint CloudHub API
- https://anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers
Accessing dedicated load balancer publicly and internally
As we discussed above, when we create a dedicated load balancer it provides internal and external CNAME. So dedicated load balance can be accessed publicly and privately. Typically, the diagram below shows how a typical request comes to a dedicated load balancer and it applies mapping rules and access to the application deployed in the CloudHub within the VPC.
Dedicated load balancer provides an internal domain that can be used by application or client internal communication within the VPC. Internal domain typically looks like internal-<lbName>.lb.anypointdns.net.
Dedicated load balancer provides a public domain that resolves to two or more IP addresses (depending on the number of workers allocated to dedicated load balancer), this can be used by an external client to access the application deployed within Anypoint VPC. Public domain typically looks like <lbName>.lb.anypointdns.net.
To learn more about dedicated load balancers, check out the documentation here.
Jitendra Bafna is one of our MuleSoft Ambassadors, you can find him on LinkedIn here.
