Nav

About Dedicated Load Balancer Architecture

A CloudHub Dedicated Load Balancer (DLB) lets you route external HTTP and HTTPS traffic to Mule applications deployed into CloudHub workers inside a particular Virtual Private Cloud (VPC). Each CloudHub Dedicated Load Balancer is assigned to a particular VPC, and that VPC runs within a particular service region. This means that the dedicated load balancer routes traffic, both external and internally to the VPC, to CloudHub workers deployed into that VPC.

The public CloudHub Load Balancer already routes HTTP requests to http://<myApp>.cloudhub.io to mule-worker-<myApp>.cloudhub.io:8081, and HTTPS traffic to https://<myApp>.cloudhub.io:443 to https://mule-worker-<myApp>.cloudhub.io:8082, where <myApp> is the name of the Mule application deployment to CloudHub.

Routing External Requests to the Dedicated Load Balancer

A CloudHub Dedicated Load Balancer provides an alternative domain name to route HTTP requests to Mule applications listening on port 8091, and HTTPS requests to Mule applications listening on port 8092. In addition, you can write mapping rules to rename requests to the CloudHub Dedicated Load Balancer to a different Mule application domain name.

For example, supose you define a create a load balancer named lb-name. Then the dedicated load Balancer exposes an external domain name that resolves to two public IP addresses which are accessible from outside your CloudHub VPC network.

 lb-name.lb.anypointdns.net

Renaming External Mule Application URLs Through a Dedicated Load Balancer

You can create a mapping rule to rename the Mule application, so it can be accessed through a different domain name.

For example, suppose you deploy a Mule application named <myApp>-myCompany-prod.cloudhub.io. Recall that CloudHub domain names must be globally unique among every other MuleSoft customer and Mule application. A dedicated load balancer helps you hide this naming complexity within your corporate DNS domain name.

You could then set a mapping rule in your dedicated load balancer so external clients can access the Mule application on http://<myApp>.lb-name.lb.anypointdns.net, or https://<myApp>.lb-name.lb.anypointdns.net:443.

In addition, you can set a CNAME record in your corporate DNS nameserver to mask the lb-name.lb.anypointdns.net domain to your companies "vanity" domain.

For example, suppose your company owns the DNS domain example.com. You can create a CNAME record to route requests to myapp.example.com to <myApp>.lb-name.lb.anypointdns.net. Now you have hidden the complexity of the CloudHub domain name in the cloudhub.io domain.

Routing Internal Requests to the Dedicated Load Balancer

Your CloudHub Dedicated Load Balancer also has an internal domain name that is used by applications and clients within the VPC. The naming convention used by the internal domain is:

internal-<lb-name>.lb.anypointdns.net

where <lb-name> is the name you gave the load balancer when you created it.

Each dedicated load balancer has a DNS A Record <lb-name>.lb.anypointdns.net that resolves to the two public IP addresses of the two instances. Through your DNS provider, you can add a CNAME record pointing to this record and use your own domain names to access.

If you want your load balancer to handle all connections to your application, but do not want your default domain name for your application publicly exposed, then each application needs to be listening on HTTP on port 8091 or 8092. Alternately, you can create a custom mapping policy to redirect outside requests from your load balancer to your specific application.

The following diagram shows how a load balancer interacts between a virtual private cloud and Anypoint Plaform.

Load Balancer

Your load balancer listens for outside requests over HTTPS and, by default, communicates internally with your worker over HTTP. If you configured your Mule application within the VPC to listen on HTTPS, you must set upstreamProtocol to HTTPS when creating the mapping list using the load-balancer mappings add command.

The Internal HTTP Mode lets you configure how HTTP requests are handled. They are either silently ignored, mapped HTTPS on the default SSL endpoint, or the URL is mapped straight through to the corresponding HTTPS URL.