Set Up Load Balancers in Oracle Cloud Infrastructure

Load Balancing in Oracle Cloud Infrastructure Load Balancing Classic

Load balancing in an Oracle Cloud Infrastructure Compute Classic network is handled by the Oracle Cloud Infrastructure Load Balancing Classic service. Instances of Oracle Cloud Infrastructure Load Balancing Classic can be created from the Oracle Cloud Infrastructure Compute Classic console and used to balance requests against a pool of Oracle Cloud Infrastructure Compute Classic VMs.

For more information, see About Oracle Cloud Infrastructure Load Balancing Classic.

Oracle Cloud Infrastructure Load Balancers

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

For more information, see Overview of Load Balancing.

Features in Oracle Cloud Infrastructure Load Balancing Classic and Oracle Cloud Infrastructure Load Balancing

The following table compares load balancer features in Oracle Cloud Infrastructure Load Balancing Classic versus the Oracle Cloud Infrastructure Load Balancing service.

Feature	Oracle Cloud Infrastructure Load Balancing Classic	Oracle Cloud Infrastructure Load Balancing
Types of load balancers	Internet-facing or internal load balancer in a given IP network. When you create a load balancer in Oracle Cloud Infrastructure Load Balancing Classic, it allows you to select a scheme for the load balancer: Internet-facing - This scheme enables you to add a load balancer to your own IP Network, while assigning a internet addressable IP address to the load balancer. Internal - This scheme enables you to add a load balancer to your own IP network for the sole consumption of other clients inside the same network. See Creating a Load Balancer.	Public or private load balancer in a virtual cloud network (VCN). Public - A public load balancer has a public IP address that is accessible from the internet. To accept traffic from the internet, you create a public load balancer. Private - A private load balancer has an IP address from the hosting subnet, which is visible only within your VCN. To isolate your load balancer from the internet and simplify your security posture, you can create a private load balancer. Oracle Cloud Infrastructure load balancer is based on pre-provisioned bandwidth shape (100Mb, 400Mb and 8G). See How Load Balancing Works.
Origin servers/Backend servers	Origin servers A server or host computer to which the load balancer routes requests. In the context of the Oracle Cloud Infrastructure Load Balancing Classic, an origin server is an Oracle Cloud Infrastructure Compute Classic service instance.	Backend servers When you implement a load balancer, you must specify the backend servers (Compute instances) to include in each backend set. The load balancer routes incoming traffic to these backend servers based on the policies you specified for the backend set. The backend servers (Compute instances) associated with a backend set can exist anywhere, as long as the associated security lists and route tables allow the intended traffic flow.
Backend Set/Server Pool	Server pool When you create a load balancer with Oracle Cloud Infrastructure Load Balancing Classic, you must define one or more servers (referred to as origin servers) to which the load balancer can distribute requests. A set of origin servers is called a server pool. In Oracle Cloud Infrastructure Load Balancing Classic, there is no concept of a backend set (which is defined by a list of backend servers, a load balancing policy, and a health check policy). However, Oracle Cloud Infrastructure Compute Classic has server pools (a set of origin servers). In Oracle Cloud Infrastructure Compute Classic, after the creation of a load balancer, users must finish the configuration of the load balancer by adding a server pool (where you can also define health checks for the origin servers), a listener, and optional policies (such as Load Balancing Mechanism Policy).	Backend Set A logical entity defined by a list of backend servers, a load balancing policy, and a health check policy. SSL configuration is optional. The backend set determines how the load balancer directs traffic to the collection of backend servers.
Certificates	You must obtain a digital certificate if you want to use a secure connection between the load balancer and the clients sending the request or between the load balancer and the origin servers in the server pool. Oracle Cloud Infrastructure Load Balancing Classic supports two types of digital certificates: Server certificates Trusted certificates	If you use HTTPS or SSL for your listener, you must associate an SSL server certificate (X.509) with your load balancer. A certificate enables the load balancer to terminate the connection and decrypt incoming requests before passing them to the backend servers.
Health Check	The load balancer can perform regular health checks of the origin servers and route inbound traffic to the healthy origin servers. This feature is not enabled automatically when an origin server pool is created and must be enabled explicitly either during the origin server pool creation or update. Types of health check supported: TCP SSL HTTP	A test to confirm the availability of backend servers. A health check can be a request or a connection attempt. Based on a time interval you specify, the load balancer applies the health check policy to continuously monitor backend servers. If a server fails the health check, the load balancer takes the server temporarily out of rotation. If the server subsequently passes the health check, the load balancer returns it to the rotation. You configure your health check policy when you create a backend set. Types of health check supported: TCP-level HTTP-level
Health Status	N/A	The Load Balancing service provides health status indicators that use your health check policies to report on the general health of your load balancers and their components. You can see health status indicators for load balancers, backend sets, and backend servers.
Listeners	Before you use a load balancer, you must define at least one listener. A listener defines the virtual host, port, and protocol that the load balancer will use to listen for new requests. Supported protocols include: Balancer Protocol - The transport protocol that will be accepted for all incoming requests to the selected load balancer listener. HTTP - Use this protocol to listen for non-secure HTTP requests. HTTPS - Use this protocol to listen only for secure HTTP requests sent over SSL or TLS. Server Protocol - The protocol to be used for routing traffic to the origin servers in the server pool. HTTP - Use this protocol to route HTTP or HTTPS requests to the origin servers using the non-secure HTTP protocol. HTTPS - Use this protocol to route HTTP or HTTPS requests to the origin servers using the secure HTTPS protocol.	A logical entity that checks for incoming traffic on the load balancer's IP address. You configure a listener's protocol and port number, and the optional SSL settings. To handle TCP, HTTP, and HTTPS traffic, you must configure multiple listeners. Supported protocols include: TCP HTTP/1.0 HTTP/1.1 You can have one SSL certificate bundle per listener. You can configure two listeners, one each for ports 443 and 8443, and associate SSL certificate bundles with each listener.
Load Balancer Policies	Oracle Cloud Infrastructure Load Balancing Classic provides advanced features that you can configure by attaching specific policies to the load balancer. Supported policies include: Application Cookie Stickiness Policy CloudGate Policy Load Balancer Cookie Stickiness Policy Load Balancing Mechanism Policy This policy enables you to specify a load balancing mechanism for distributing client requests across multiple origin servers by using one of the following methods: Round Robin IP Hash Least Connections Rate Limiting Request Policy Redirect Policy Resource Access Control Policy Set Request Header Policy SSL Negotiation Policy Trusted Certificate Policy See About Load Balancer Policies and Creating Policies for a Load Balancer.	A load balancing policy tells the load balancer how to distribute incoming traffic to the backend servers. Supported policies include: Round robin Least connections IP hash See How Load Balancing Policies Work. Oracle Cloud Infrastructure load balancer supports HTTP cookie based Session Persistence. See Session Persistence. Oracle Cloud Infrastructure load balancer supports SSL termination and SSL tunneling policies.

Create a Load Balancer in Oracle Cloud Infrastructure

This topic provides information on creating a load balancer in Oracle Cloud Infrastructure.

Topics:

Considerations When Creating a Load Balancer as Part of Your Migration Project

Note that certain load balancer features which were available in Oracle Cloud Infrastructure Load Balancing Classic may not be available in Oracle Cloud Infrastructure Load Balancing service. See Features in Oracle Cloud Infrastructure Load Balancing Classic and Oracle Cloud Infrastructure Load Balancing.

Prerequisites

This procedure assumes:

you have already created a virtual cloud network (VCN) using the procedures described in Create a Virtual Cloud Network in Oracle Cloud Infrastructure.
you have already created the required Oracle Cloud Infrastructure virtual machines and you have migrated your workloads to the new VMs.
you have access to the URLs and endpoints where the load balancers will direct incoming network traffic.

Creating the Load Balancer

The following table describes the tasks involved in creating a load balancer in Oracle Cloud Infrastructure.

Task	Description	More Information
Add two subnets to your VCN to host your load balancer.	Your load balancer must reside in different subnets from your application instances. This configuration allows you to keep your application instances secured in subnets with stricter access rules, while allowing public internet traffic to the load balancer in the public subnets.	Add two subnets to your VCN to host your load balancer.
Create a load balancer.	When you create a public load balancer, you choose its shape (size) and you select two subnets, each in a different availability domain. This configuration ensures that the load balancer is highly available. It is active in only one subnet at a time. This load balancer comes with a public IP address and provisioned bandwidth corresponding to the shape you chose.	Create a load balancer.
Create a backend set with health check.	A backend set is a collection of backend servers to which your load balancer directs traffic. A list of backend servers, a load balancing policy, and a health check script define each backend set.	Create a backend set with health check.
Add backend servers to your backend set.	After the backend set is created, you can add compute instances (backend servers) to it. To add a backend server, you can enter the OCID for each instance and your application port. The OCID enables the Console to create the security list rules required to enable traffic between the load balancer subnets and the instance subnets. Tip	Add backend servers to your backend set.
Create a listener.	A listener is an entity that checks for connection requests. The load balancer listener listens for ingress client traffic using the port you specify within the listener and the load balancer's public IP.	Create a listener.
Update the load balancer subnet security list and allow internet traffic to the listener.	When you create a listener, you must also update your VCN's security list to allow traffic to that listener. The subnets where the load balancer resides must allow the listener to accept traffic. To enable the traffic to get to the listener, update the load balancer subnet's security list.	Update the load balancer subnet security list and allow internet traffic to the listener.
Verify your load balancer.	To test your load balancer's functionality, you can open a web browser and navigate to its public IP address (listed on the load balancer's detail page). If the load balancer is properly configured, you can see the name of one of the web server instances.	Verify your load balancer.
Update rules to protect your backend servers.	Update the default security list and the default route table to limit traffic to your backend servers.	Update rules to protect your backend servers.
Terminate your load balancer.	When your load balancer becomes available, you are billed for each hour that you keep it running. Once you no longer need a load balancer, you can delete it. When the load balancer is deleted, you stop incurring charges for it. Deleting a load balancer does not affect the backend servers or subnets used by the load balancer.	Terminate your load balancer.