In recent years, the Oracle Cloud Infrastructure Load Balancing service has added an increasing number of capabilities that enable customers to manage their public and private workloads and achieve best scenario traffic balancing, high availability, SSL offload, and much more. It’s been quite a journey!
Recently, I heard about a requirement to configure a load balancer as a reverse proxy to direct the traffic of two different public websites, which translates to two distinct backend sets. Each backend set has at least two servers to achieve high availability.
To clarify this a bit, let's say you need to access cats.dummy.com and dogs.dummy.com. When you access cats.dummy.com, you go to the specific backend set that hosts that site, and when you access dogs.dummy.com, you go to another backend set. And all this needs to be achieved with a single load balancer in Oracle Cloud. The following diagram shows a sample deployment that has load-balanced HTTP servers and a database tier with fault tolerance.
Note: Oracle Cloud Infrastructure load balancers can be configured to listen to HTTP, HTTPS, and TCP traffic at configurable ports. Additionally, you have the option of using SSL for TCP traffic.
In brief, here are the steps required to achieve this kind of request routing:
Create a load balancer.
Create a backend set with a health check policy.
Add backend servers (Compute instances) to the backend set.
Create a listener, and add the hostnames and optional SSL handling.
For detailed steps, see Creating a Load Balancer Using Oracle Cloud Infrastructure Load Balancing.
The hostnames are a configurable resource on the load balancer details page in the Console.
When you create a load balancer, you need to select the best shape to handle your traffic estimation. The 10-Mbps shape is Always Free eligible, and you can easily and freely create your own cloud setup as a proof of concept. Other available shapes are 100 Mbps, 400 Mbps, and 8000 Mbps.
An important step is to configure your DNS service, or ask your service provider to point to the public IP address of your load balancer. DNS A records work just fine. In the previous example, both cats.dummy.com and dogs.dummy.com should point to the same load balancer public IP address.
An additional DNS use case is to reverse proxy the traffic for different hostnames at the top-level domain (TLD). Hosting companies can provide names and different available TLD offerings. An example would be dummy.com and dummy.org.
Another useful configuration is path route rules. If your applications have multiple endpoints or content types (for example, /data/ or /video/), you can use path route rules to route traffic to the correct backend set without using multiple listeners or load balancers.
After you create the load balancer, in the Console you click Path Route Sets under Resources and create your rules.
For more information about managing request routing, see the Load Balancing service documentation.