Overview of Load Balancing
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.
A load balancer improves resource utilization, facilitates scaling, and helps 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.
Load Balancer Types
Learn about the types of load balancers you can create within your VCN.
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 load 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.
The Load Balancing service does not support multiple listeners on same IP and port combination. You can use a single listener for multiple hostnames when combined with a Route Policy.
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 Balancing 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 Balancing 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.
You cannot specify a private subnet for your public load balancer.
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 Balancing 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 Balancing 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 cannot 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.
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.
Load Balancing Concepts
Learn about Load Balancer concepts to better understand and use the feature.
The following concepts are essential to working with Load Balancing.
- BACKEND SERVER
- An application server responsible for generating content in reply to the incoming TCP or HTTP traffic. You typically identify application servers with a unique combination of overlay (private) IPv4 address and port, for example, 10.10.10.1:8080 and 10.10.10.2:8080.
- See Backend Server Management for more information.
- 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.
- See Backend Set Management for more information.
- 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.
- See SSL Certificate Management for more information.
- health check
A health check is 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. You can configure TCP-level or HTTP-level health checks for your backend servers.
TCP-level health checks attempt to make a TCP connection with the backend servers and validate the response based on the connection status.
HTTP-level health checks send requests to the backend servers at a specific URI and validate the response based on the status code or entity data (body) returned.
The service provides application-specific health check capabilities to help you increase availability and reduce your application maintenance window.
- See Health Check Management for more information.
- HEALTH STATUS
- An indicator that reports the general health of your load balancers and their components.
- See Health Check Management for more information.
- A virtual server name applied to a listener to enhance request routing.
- See Hostname Management for more information.
- 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:
- See Listener Management for more information.
- LOAD BALANCING POLICY
- A load balancing policy tells the load balancer how to distribute incoming traffic to the backend servers. Common load balancer policies include:
- See Load Balancing Policies for more information.
- PATH ROUTE SET
- A set of path route rules to route traffic to the correct backend set without using multiple listeners or load balancers.
- See Request Routing Management for more information.
- REGIONS AND availability domains
- The Load Balancing service manages application traffic across availability domains within a region . A region is a localized geographic area, and an availability domain is one or more data centers located within a region. A region is composed of several availability domains.
- See Regions and Availability Domains for more information.
- SESSION PERSISTENCE
- A method to direct all requests originating from a single logical client to a single backend web server.
- See Session Persistence for more information.
- A template that determines the load balancer's total pre-provisioned maximum capacity (bandwidth) for ingress plus egress traffic. Available shapes include 10 Mbps, 100 Mbps, 400 Mbps, and 8000 Mbps.
- The 10 Mbps shape is Always Free eligible. For more information about Always Free resources, including other capabilities and limitations, see Oracle Cloud Infrastructure Free Tier.
Pre-provisioned maximum capacity applies to aggregated connections, not to a single client attempting to use the full bandwidth.
- Secure Sockets Layer (SSL) is a security technology for establishing an encrypted link between a client and a server. You can apply the following SSL configurations to your load balancer:
- SSL TERMINATION
- The load balancer handles incoming SSL traffic and passes the unencrypted request to a backend server.
- POINT-TO-POINT SSL
- The load balancer terminates the SSL connection with an incoming traffic client, and then initiates an SSL connection to a backend server.
- SSL TUNNELING
- If you configure the load balancer's listener for TCP traffic, the load balancer tunnels incoming SSL connections to your application servers.
- Load Balancing supports the TLS 1.2 protocol with a default setting of strong cipher strength. The default supported ciphers include:
- See SSL Certificate Management for more information.
- A subdivision you define in a virtual cloud network (VCN), such as 10.0.0.0/24 and 10.0.1.0/24. A subnet can span a region or exist within in a single availability domain. A subnet consists of a contiguous range of IP addresses that do not overlap with other subnets in the VCN. For each subnet, you specify the routing and security rules that apply to it.
- See VCNs and Subnets and Public IP Address Ranges for more information on subnets.
You can apply tags to your resources to help you organize them according to your business needs. You can apply tags at the time you create a resource, or you can update the resource later with the wanted tags. For general information about applying tags, see Resource Tags.
- VIRTUAL CLOUD NETWORK (VCN)
- A private network that you set up in the Oracle data centers, with firewall rules and specific types of communication gateways that you can choose to use. A VCN covers a single, contiguous IPv4 CIDR block of your choice in the allowed IP address ranges.
- You need at least one virtual cloud network before you launch a load balancer.
- For information about setting up virtual cloud networks, see Networking Overview.
- Specifies whether your load balancer is public or private.
- A public load balancer has a public IP address that clients can access from the internet.
- A private load balancer has a private IP address from a VCN local subnet. Clients can access the private load balancer using methods and technology that can provide access to a private IP, such as:
Cross-VCN (through LPG peering)
From another region (through RPC)
From on-prem (through FC private peering)
- For more information, see Load Balancer Management.
- WORK REQUEST
- An object that reports on the current state of a Load Balancing request.
- The Load Balancing service handles requests asynchronously. Each request returns a work request ID (OCID) as the response. You can view the work request item to see the status of the request.
- For more information, see Work Request Management.
Learn about how Load Balancer resources use resource identifiers.
Most types of Oracle Cloud Infrastructure resources have a unique, Oracle-assigned identifier called an Oracle Cloud ID (OCID). For information about the OCID format and other ways to identify your resources, see Resource Identifiers.
Ways to Access Oracle Cloud Infrastructure
Learn the different ways you can access Oracle Cloud Infrastructure.
You can access Oracle Cloud Infrastructure using the Console (a browser-based interface) or the REST API. Instructions for the Console and API are included in topics throughout this guide. For a list of available SDKs, see Software Development Kits and Command Line Interface.
To access the Console, you must use a supported browser. To go to the Console sign-in page, open the navigation menu at the top of this page and click Infrastructure Console. You prompted to enter your cloud tenant, your user name, and your password.
For general information about using the API, see REST APIs.
Learn how to monitor the health, capacity, and performance of your Oracle Cloud Infrastructure resources by using metrics, alarms, and notifications.
You can monitor the health, capacity, and performance of your Oracle Cloud Infrastructure resources by using metrics, alarms, and notifications. For more information, see Monitoring and Notifications.
For information about monitoring the traffic passing through your load balancer, see Load Balancing Metrics.
Authentication and Authorization
Learn how the Load Balancing service uses authentication and authorization to manage access to its features and functionality.
Each service in Oracle Cloud Infrastructure integrates with IAM for authentication and authorization, for all interfaces (the Console, SDK or CLI, and REST API).
An administrator in your organization needs to set up groups , compartments , and policies that control which users can access which services, which resources, and the type of access. For example, the policies control who can create new users, create and manage the cloud network, launch instances, create buckets, download objects, etc. For more information, see Getting Started with Policies. For specific details about writing policies for each of the different services, see Policy Reference.
If you’re a regular user (not an administrator) who needs to use the Oracle Cloud Infrastructure resources that your company owns, contact your administrator to set up a user ID for you. The administrator can confirm which compartment or compartments you should be using.
Limits on Load Balancing Resources
Learn about the limits on Load Balancer resources.
Other limits include:
You cannot convert an AD-specific load balancer to a regional load balancer or the reverse.
The Load Balancing service supports IPv6 addresses for load balancers in the US Government Cloud only. IPv6 support is only for the load balancer itself, and not the backend.
The maximum number of concurrent connections is limited when you use stateful security rules for your load balancer subnets. In contrast, no theoretical limit on concurrent connections exists if you use stateless security rules. The practical limitations depend on various factors. The larger your load balancer shape, the greater the connection capacity. Other considerations include system memory, TCP timeout periods, TCP connection state, and so forth.Tip
To accommodate high-volume traffic, Oracle strongly recommends that you use stateless security rules for your load balancer subnets.
Each load balancer has the following configuration limits:
One IP address
16 backend sets
512 backend servers per backend set
512 backend servers total
Required IAM Policies
Learn about Identify and Access Management policies and how they apply to theLoad Balancing service.
To use Oracle Cloud Infrastructure, you must be granted security access in a policy by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment to work in.
For administrators: For a typical policy that gives access to load balancers and their components, see Let network admins manage load balancers.
Also, be aware that a policy statement with
inspect load-balancers gives the specified group the ability to see all information about the load balancers. For more information, see Details for Load Balancing.
Load Balancing Policies
Learn how you can apply Load Balancer resource policies to control traffic distribution to your backend servers.
After you create a load balancer, you can apply policies to control traffic distribution to your backend servers. The Load Balancing service supports three primary policy types:
When processing load or capacity varies among backend servers, you can refine each of these policy types with backend server weighting. Weighting affects the proportion of requests directed to each server. For example, a server weighted '3' receives three times the number of connections as a server weighted '1.' You assign weights based on criteria of your choosing, such as each server's traffic-handling capacity.
Load balancer policy decisions apply differently to TCP load balancers, cookie-based session persistent HTTP requests (sticky requests), and non-sticky HTTP requests.
A TCP load balancer considers policy and weight criteria to direct an initial incoming request to a backend server. All subsequent packets on this connection go to the same endpoint.
An HTTP load balancer configured to handle cookie-based session persistence forwards requests to the backend server specified by the cookie's session information.
For non-sticky HTTP requests, the load balancer applies policy and weight criteria to every incoming request and determines an appropriate backend server. Multiple requests from the same client could be directed to different servers.
If you want to create a load Balancer with a reserve IP, add this policy:
Allow group group_name to manage floating-ips in tenancy
See Managing Policies for general information on policies.
Round Robin is the default load balancer policy. This policy distributes incoming traffic sequentially to each server in a backend set list. After each server has received a connection, the load balancer repeats the list in the same order.
Round Robin is a simple load balancing algorithm. It works best when all the backend servers have similar capacity and the processing load required by each request does not vary significantly.
The Least Connections policy routes incoming non-sticky request traffic to the backend server with the fewest active connections. This policy helps you maintain an equal distribution of active connections with backend servers. As with the round robin policy, you can assign a weight to each backend server and further control traffic distribution.
In TCP use cases, a connection can be active but have no current traffic. Such connections do not serve as a good load metric.
The IP Hash policy uses an incoming request's source IP address as a hashing key to route non-sticky traffic to the same backend server. The load balancer routes requests from the same client to the same backend server as long as that server is available. This policy honors server weight settings when establishing the initial connection.
IP Hash ensures that requests from a particular client are always directed to the same backend server, as long as the backend server is available.
You cannot add a backend server marked as Backup to a backend set that uses the IP Hash policy.
Multiple clients that connect to the load balancer through a proxy or NAT router appear to have the same IP address. If you apply the IP Hash policy to your backend set, the load balancer routes traffic based on the incoming IP address and sends these proxied client requests to the same backend server. If the proxied client pool is large, the requests could flood a backend server.
HTTP "X-" Headers and Host Header
Learn about using HTTP "X" headers in a Load Balancer resource.
HTTP requests and responses often include header fields that provide contextual
information about the message. RFC 2616 defines a standard set of HTTP header fields. Some non-standard
header fields, which begin with
X-, are common. The Load Balancing service adds or modifies the Host header and the
X- headers when it passes requests to your servers. Because
these headers are automatically added, they cannot be removed or modified using a rule
Provides a list of connection IP addresses.
The load balancer appends the last remote peer address to the
X-Forwarded-For field from the incoming request. A comma and space
precede the appended address. If the client request header does not include an
X-Forwarded-For field, this value is equal to the
X-Real-IP value. The original requesting client is the first
(left-most) IP address in the list, assuming that the incoming field content is
trustworthy. The last address is the last (most recent) peer, that is, the machine from
which the load balancer received the request. The format is:
X-Forwarded-For: original_client, proxy1, proxy2
Example incoming field:
Example field with appended proxy IP address:
X-Forwarded-For: 18.104.22.168, 192.168.0.10
Identifies the original host and port requested by the client in the
Host HTTP request header. This header helps you determine the
original host, since the hostname or port of the reverse proxy (load balancer) might
differ from the original server handling the request.
Identifies the listener port number that the client used to connect to the load balancer. For example:
Identifies the protocol that the client used to connect to the load balancer, either
https. For example:
Identifies the client's IP address. For the Load Balancing service, the "client" is the last remote peer.
Your load balancer intercepts traffic between the client
and your server. Your server's access logs, therefore, include only the load
balancer's IP address. The
X-Real-IP header provides the client's
IP address. For example:
Identifies the original host and optionally the port requested by the client in the Host HTTP request header. For example: