X

Break New Ground

Application load balancing on Oracle Cloud Infrastructure

Prasenjit Sarkar
Senior Principal Product Manager

Application load balancing on Oracle Cloud Infrastructure

The Oracle Cloud Infrastructure Load Balancing service distributes traffic from one entry point to multiple servers reachable from your virtual cloud network (VCN). The service provides a load balancer with your choice of a public or private IP address, and provisioned bandwidth.

A load balancer improves resource use, facilitates scaling, and helps to ensure high availability. You can configure multiple load balancing policies and application-specific health checks to ensure that the load balancer directs traffic only to healthy instances. The load balancer can reduce your maintenance window by draining traffic from an unhealthy application server before you remove it from service for maintenance.

 

How load balancing works

The Load Balancing service enables you to create a public or private load balancer within your VCN.

  • A public load balancer has a public IP address that is accessible from the internet.

  • A private load balancer has an IP address from the hosting subnet, which is visible only within your VCN.

You can configure multiple listeners for an IP address to balance transport layer 4 and layer 7 (TCP and HTTP) traffic. Both public and private load balancers can route data traffic to any backend server that is reachable from the VCN.

Let’s look a little closer at layer 4 load balancers (network load balancers), layer 7 load balancers (application load balancers), and the differences between them.

 

Network load balancer (layer 3 and 4)

A network load balancer distributes traffic based on IP address and destination ports. It handles only layer 4 (TCP) traffic; it’s not built to handle anything at layer 7, such as content type, cookie data, custom headers, user location, or application behavior. A network load balancer is a context-less load distribution. It handles only the network-layer information contained within the packets.

 

Application load balancer (layer 7)

An application load balancer distributes traffic based on multiple variables, from the network layer to the application layer. An application load balancer is a context-aware load distribution that directs requests based on any single variable as easily as requests based on a combination of variables. Applications are load balanced based on their behaviour.

An application load balancer works on layer 7, so it supports both HTTP and HTTPS. It can distribute HTTP and HTTPS traffic based on host-based or path-based rules. It also has a configurable range of health check status codes. The following diagram shows a logical representation of an application load balancer in Oracle Cloud Infrastructure (OCI).

Figure 1: Application load balancer on OCI

 

Difference between layer 4 and layer 7 load balancers

The basic difference between these two types of load balancer is the layer in which they work. The network load balancer performs request forwarding, whereas the application load balancer routes the request after examining the contents of the HTTP request header. In short, the application load balancer performs content-based routing.

Another major difference is that layer 7 load balancers ensure the availability of the application, whereas layer 4 load balancers do not; they act only on the TCP layer variables.

A layer 7 load balancer can determine availability based on not only a successful HTTP GET of a particular page but also on the verification that the content is as was expected based on the input parameters.

 

Routing incoming requests using layer 7 rules

The Load Balancing service lets you route incoming requests to various backend sets. You can perform the following actions:

  • Assign virtual hostnames to a listener
  • Create path route rules
  • Combine these techniques

 

Virtual hostnames

When used with A records that you create in your DNS system, you can assign virtual hostnames to any listener that you create for your load balancer. Each hostname can correspond to a backend set, and that backend set can route traffic to specific backends that host different applications. Here are some advantages of virtual hostnames:

  • A single associated IP address: Multiple hostnames, backed by DNS entries that you create in your nameservers, can point to the same load balancer IP address.
  • A single load balancer: You don’t need a separate load balancer for each application.
  • A single load balancer shape: Running multiple applications behind a single load balancer helps you manage aggregate bandwidth demands and optimize use.
  • Simpler backend set management: Managing a set of backend servers under a single resource simplifies network configuration and administration.

You can define exact virtual hostnames, such as app.example.com, or you can use wildcard names. Wildcard names include an asterisk (*) in place of the first or last part of the name. When searching for a virtual hostname, the service chooses the first matching variant in the following priority order:

  1. Exact name match (no asterisk), such as app.example.com
  2. Longest wildcard name that begins with an asterisk, such as *.example.com
  3. Longest wildcard name that ends with an asterisk, such as app.example.*

 

Path route rules

Some applications have multiple endpoints or content types, each distinguished by a unique URI path—for example, /admin/, /data/, /video/, or /``cgi``/. You can use path route rules to route traffic to the correct backend set without using multiple listeners or load balancers.

A path route is a string that the Load Balancing service matches against an incoming URI to determine the appropriate destination backend set. Path route strings have the following characteristics:

  • Asterisks aren’t allowed.
  • Regular expressions aren’t allowed.
  • Path route string matching is case-insensitive.

 

Deploy a highly available web service and load balance it with application parameters

Creating a highly available web service requires creating at least two instances in two availability domains and then using the Load Balancing service to balance the traffic between them. To do this, you perform the following high-level tasks:

  1. Create two OCI instances in two availability domains in one OCI region.
  2. Deploy the web service on these instances.
  3. Create a load balancer instance to load balance the web service traffic between these two instances.

To create the instances and an associated VCN, see the instructions in Setting Up a VCN in Oracle Cloud Infrastructure.

To deploy a web service that has two different routing paths and also accepts a cookie header, you can follow the instructions in GitHub. However, you can use any web server that accepts cookie-based session persistence.

To balance traffic between these two instances, let’s use a public load balancer. The following diagram provides a high-level view of a simple public load balancing system configuration. Far more sophisticated and complex configurations are common.

Figure 2: OCI public load balancer architecture

To create a load balancer, follow these steps. For detailed information about the Load Balancing service, see the documentation.

  1. From the main navigation menu in the Oracle Cloud Console, go to Networking and then click Load Balancers.
  2. Choose a compartment that you have permission to work in, and then click Create Load Balancer.
  3. Add these details:
    • Enter a name for the load balancer.
    • Choose the Public visibility type.
    • Choose the total bandwidth for the load balancer. The default is 100 Mbps.
    • Choose the VCN and subnet in which to create the load balancer.

Figure 3: Load balancer details

  1. Click Next.
  2. Specify a load balancing policy. The default is Weighted Round Robin.
  3. Click Add Backends.
  4. Select the instances to include in the load balancer’s backend set. In this example, these are the two instances on which you deployed your web service. Then, click Add Selected Backends.
  5. In the Specify Health Check Policy section, use the default values. Because we’re load balancing a web server, HTTP is our choice of protocol and 80 is our port.
  6. Click Show Advanced Options, and then click the Session Persistence tab.
  7. Select Enable Application Cookie Persistence, and then enter a name for the cookie. In this example, the cookie name is oci-lb-cookie.

Figure 4: Session persistence

  1. Click Next.
  2. On the Configure Listener page, choose HTTP as the type of traffic that your listener handles.
  3. Use the default port (80), and click Submit.

Figure 5: Load balancer listener

After the load balancer is created, you are redirected to the details page. There, you can get the public IP address of the load balancer, as shown in the following image.

Figure 6: Load balancer IP address

 

Copy the IP address, open a browser, and paste it in the address bar. You will see the first instance in availability domain 1. Refresh the page to see that you’re accessing the same instance again; the cookie is working.

This illustrates how you can use HTTP-cookie-based session persistence and how the Load Balancing service can handle application-parameter-based load balancing.

Conclusion

This blog post gave you an overview of layer 4 and layer 7 load balancing capabilities and how Oracle Cloud Infrastructure can load balance traffic by using IP parameters and application parameters. It described how you can create two instances in two different availability domains within a region and then load balance the application traffic using application layer parameters such as cookie-based persistence.

Resources

Every use case is different. The only way to know if Oracle Cloud Infrastructure is right for you is to try it. You can select either the Oracle Cloud Free Tier or a 30-day free trial, which includes US$300 in credit to get you started with a range of services, including compute, storage, and networking.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.