Load Balancer Management
Describes how to 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.
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:
A load balancer with pre-provisioned bandwidth.
A backend set with a health check policy. See Backend Sets for Load Balancers for more information.
Backend servers for your backend set. See Backend Servers for Load Balancers for more information.
One or more listeners . See Listeners for Load Balancers for more information.
Load balancer subnet security rules to allow the intended traffic. To learn more about these rules, see Security Rules.Note
To accommodate high-volume traffic, Oracle strongly recommends that you use stateless security rules for your load balancer subnets. See Stateful Versus Stateless Rules for more information.
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.
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 created in one public regional subnet consumes two private IPv4 addresses from the host subnet. The primary and secondary load balancers reside within the same subnet. Each load balancer requires a private IPv4 address from that subnet. The Load Balancer service assigns a floating public IPv4 address, which does not 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 created in two public AD-specific subnets consumes two private IP addresses, one from each host subnet. The primary and secondary load balancers reside within different subnets. Each load balancer requires one private IP address from its host subnet. The Load Balancer service assigns a floating public IPv4 address, which does not come from the host subnets. If the load balancer is enabled for IPv6, it is assigned an IPv6 address from the host subnet.
A private load balancer created in a single subnet consumes three private IP addresses from the host subnet. The primary and secondary load balancers reside within the same subnet. Each load balancer requires a private IP address from that subnet. The floating private IP address also comes from the host subnet. 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.
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.