Load Balancer Types

Public Load Balancers

To accept traffic from the internet, you create a public load balancer. The service assigns it a public IP address that serves as the entry point for incoming traffic. You can associate the public IP address with a friendly DNS name through any DNS vendor.

A public load balancer is regional in scope. If your region includes multiple availability domains, a public load balancer requires either a regional subnet (recommended) or two availability domain-specific (AD-specific) subnets, each in a separate availability domain. With a regional subnet, the Load Balancer service creates a primary load balancer and a standby load balancer, each in a different availability domain, to ensure accessibility even during an availability domain outage. If you create a load balancer in two AD-specific subnets, one subnet hosts the primary load balancer and the other hosts a standby load balancer. If the primary load balancer fails, the public IP address switches to the secondary load balancer. The service treats the two load balancers as equivalent and you cannot specify which one is "primary."

Whether you use regional or AD-specific subnets, each load balancer requires one private IP address from its host subnet. The Load Balancer service supplies a floating public IP address to the primary load balancer. The floating public IP address does not come from your backend subnets.

If your region includes only one availability domain, the service requires just one subnet, either regional or AD-specific, to host both the primary and standby load balancers. The primary and standby load balancers each requires a private IP address from the host subnet, in addition to the assigned floating public IP address. If an availability domain outage occurs, the load balancer has no failover.

Private Load Balancers

To isolate your load balancer from the internet and simplify your security posture, you can create a private load balancer. The Load Balancer service assigns it a private IP address that serves as the entry point for incoming traffic.

When you create a private load balancer, the service requires only one subnet to host both the primary and standby load balancers. The load balancer can be regional or AD-specific, depending on the scope of the host subnet. The load balancer is accessible only from within the VCN that contains the host subnet, or as further restricted by your security rules.

The assigned floating private IP address is local to the host subnet. The primary and standby load balancers each requires an extra private IP address from the host subnet.

If an availability domain outage occurs, a private load balancer created in a regional subnet within a multi-AD region provides failover capability. A private load balancer created in an AD-specific subnet, or in a regional subnet within a single availability domain region, has no failover capability in response to an availability domain outage.

All Load Balancers

Your load balancer has a backend set to route incoming traffic to your compute instances. The backend set is a logical entity that includes:

• A list of backend servers.

• A load balancing policy.

• A health check policy.

• Optional SSL handling.

• Optional session persistence configuration.

The backend servers (compute instances) associated with a backend set can exist anywhere, as long as the associated network security groups (NSGs), security lists, and route tables allow the intended traffic flow.

If your VCN uses network security groups (NSGs), you can associate your load balancer with an NSG. An NSG has a set of security rules that controls allowed types of inbound and outbound traffic. The rules apply only to the resources in the group. Contrast NSGs with a security list, where the rules apply to all the resources in any subnet that uses the list. For more information about NSGs, see Network Security Groups.

If you prefer to use security lists for your VCN, the Load Balancer service can suggest appropriate security list rules. You also can configure them yourself through the Networking service. See Security Lists for more information.

See Security Rules for detailed information comparing NSGs and security lists.

Oracle recommends that you create your load balancer in a regional subnet.

Oracle recommends that you distribute your backend servers across all availability domains within the region.

To create a minimal system with a functioning load balancer, you must:

• For a public load balancer, create a VCN with an internet gateway and a public regional subnet.

  Note
  
  

  You can't specify a private subnet for your public load balancer.

• For a private load balancer, create a VCN with at least one private subnet.

• Create at least two compute instances, each in a separate availability domain.

• 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, with optional SSL handling.

• Update the load balancer subnet security rules so they allow the intended traffic.

Load Balancer Reachability

The load balancer does not directly respond to a client ICMP or TCP/UDP ping packet. Instead, the load balancer directs the packet to a backend server in accordance with the load balancing policy. The backend server then returns a response to the client. You can use any other tool, such as cURL, openssl or just opening the client in the browser, to test the load balancer connectivity.

Private IP Address Consumption

A public load balancer created in one public subnet consumes two private IP addresses from the host subnet.

A public load balancer created in two public subnets consumes two private IP addresses, one from each host subnet.

A private load balancer created in a single subnet consumes three private IP addresses from the host subnet.

See Getting Started with Load Balancing for step-by-step instructions to create a simple load balancing setup.

The following diagram provides a high-level view of a simple public load balancing system configuration. Far more sophisticated and complex configurations are common.