Load Balancer Management

Create and manage load balancers to provide automated traffic distribution from one entry point to multiple servers reachable from your virtual cloud network (VCN).

For the purposes of access control, you must specify the compartment where you want the load balancer to reside. Consult an administrator in your organization if you're not sure which compartment to use. For information about compartments and access control, see Managing Compartments.

You can perform the following load balancer management tasks:

When you create a load balancer within your VCN, you get a public or private IP address, and provisioned total bandwidth. If you need another IP address, you can create another load balancer.

A public load balancer in a region with multiple availability domains requires one public regional subnet or two public AD-specific subnets to host the primary load balancer and a standby. In the latter case, each AD-specific subnet must reside in a separate availability domain. A public load balancer in a region with only one availability domain requires a single public subnet to host the primary load balancer and a standby. For more information on VCNs and subnets, see Networking Overview. You can associate the public IPv4 address with a DNS name from any vendor. You can use the public IP address as a front end for incoming traffic. The load balancer can route data traffic to any backend server that's reachable from the VCN.
Note

To ensure reachability between the public load balancer and its public IP address based backends, configure a NAT Gateway. See NAT Gateway for more information.

A private load balancer requires only one subnet to host the primary load balancer and a standby. The private IP address is local to the subnet. The load balancer is accessible only from within the VCN that contains the associated subnet, or as further restricted by your security list rules. The load balancer can route data traffic to any backend server that is reachable from the VCN.

The essential components for load balancing include:

Optionally, you can associate your listeners with SSL server certificate bundles to manage how your system handles SSL traffic. See SSL Certificates for Load Balancers for more information.

For information about the number of load balancers you can have, see Service Limits.

Prerequisites

To implement a working load balancer, you need:

  • For a public load balancer in a region with multiple availability domains , you need a VCN with a public regional subnet or at least two public AD-specific subnets. In the latter case, each AD-specific subnet must reside in a separate availability domain. For more information on subnets, See VCNs and Subnets and Public IP Address Ranges.

    Note

    You cannot specify a private subnet for your public load balancer.

  • For a public load balancer in a region with only one availability domain, you need a VCN with at least one public subnet.

  • For a private load balancer in any region, you need a VCN with at least one private subnet.

  • Two or more backend servers (compute instances) running your applications. For more information about compute instances, see Creating an Instance.

Private IP Address Consumption

A public load balancer that's created in a public regional subnet consumes two private IPv4 addresses from that subnet. These private IPv4 addresses are used for communication from the load balancer to the backend servers. These private IPv4 addresses can change during the lifetime of the load balancer. The Load Balancer service assigns a floating public IPv4 address that doesn't come from the host subnet. If the load balancer is enabled for IPv6, it receives an IPv6 address from the host subnet.

A public load balancer that's created in two public AD-specific subnets consumes up to four private IP addresses, with up to two from each host subnet. These private IPv4 addresses are used for communication from the load balancer to the backend servers. These private IPv4 addresses can change during the lifetime of the load balancer. The Load Balancer service assigns a floating public IPv4 address that doesn't come from the host subnets. Public load balancers enabled for IPv6 can't be created in AD-specific subnets.

A private load balancer that's created in a single subnet consumes up to three private IPv4 addresses from the host subnet. One private IP address is used for client to load balancer communication. This IP address doesn't change. The remaining IP addresses are used for communication from the load balancer to the backend servers. These private IPv4 addresses can change during the lifetime of the load balancer. Internet communication with a load balancer enabled for IPv6 and created in a private subnet is prohibited. You can't create a globally-routable IPv6-enabled load balancer in a private subnet.

Note

You can't specify a particular private IP address to use when you create a load balancer. Instead, you're limited to the IP address the load balancer is assigned. After the IP address is assigned, it doesn't change. To use a different, randomly-generated IP address, create a new load balancer.

Configuration Changes and Service Disruption

For a running load balancer, some configuration changes lead to service disruptions. The following guidelines help you understand the effect of changes to your load balancer.

  • Operations that add, remove, or modify a backend server create no disruptions to the Load Balancer service.

  • Operations that edit an existing health check policy create no disruptions to the Load Balancer service.

  • Operations that trigger a load balancer reconfiguration can produce a brief service disruption with the possibility of some terminated connections.