Oracle Cloud Infrastructure Documentation

Managing a Load Balancer

This topic describes how to create or delete a load balancer on your system.

Warning

Avoid entering confidential information when assigning descriptions, tags, or friendly names to your cloud resources through the Oracle Cloud Infrastructure Console, API, or CLI.

Prerequisites

To implement a working load balancer, you need:

  • For a public load balancer in a region with multiple One or more isolated, fault-tolerant Oracle data centers that host cloud resources such as instances, volumes, and subnets. A region contains one or more 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 vs. Private Subnets.

    Warning

    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 on Compute instances, see Creating an Instance.
Note

Private IP Address Consumption

A public load balancer created in one public regional subnet consumes two 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 Load Balancing service assigns a floating public IP address, which does not come 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 Balancing service assigns a floating public IP address, which does not come from the host subnets.

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.

Working with Load Balancers

For background information on Oracle Cloud Infrastructure Load Balancing, see Overview of Load Balancing.

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 Overview of Oracle Cloud Infrastructure Identity and Access Management.

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 Overview of Networking. 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 is reachable from the VCN.

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 A logical entity defined by a list of backend servers, a load balancing policy, and a health check policy. with a health check policy. See Managing Backend Sets.
  • Backend servers for your backend set. See Managing Backend Servers.
  • One or more An entity that checks for incoming traffic on the load balancer's public floating IP address.. See Managing Load Balancer Listeners.
  • Load balancer subnet security list rules to allow the intended traffic. To learn more about these rules, see Parts of a Security List Rule.

    Tip

    To accommodate high-volume traffic, Oracle strongly recommends that you use stateless security list rules for your load balancer subnets.

Optionally, you can associate your listeners with SSL server certificate bundles to manage how your system handles SSL traffic. See Managing SSL Certificates.

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

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 Balancing service.
  • Operations that edit an existing health check policy create no disruptions to the Load Balancing service.
  • Operations that trigger a load balancer reconfiguration can produce a brief service disruption with the possibility of some terminated connections.

Health Status

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 on the Console List and Details pages for load balancers, backend sets, and backend servers. You also can use the Load Balancing API to retrieve this information.

For general information about health status indicators, see Editing Health Check Policies.

Load Balancer Health Summary

The Console list of load balancers provides health status summaries that indicate the overall health of each load balancer. There are four levels of health status indicators. The meaning of each level is:

  • OK: All backend sets associated with the load balancer return a status of OK.
  • WARNING: All the following conditions are true:

    • At least one backend set associated with the load balancer returns a status of WARNING or UNKNOWN.
    • No backend sets return a status of CRITICAL.
    • The load balancer life cycle state is ACTIVE.
  • CRITICAL: At least one backend set associated with the load balancer returns a status of CRITICAL.
  • UNKNOWN: Any one of the following conditions is true:

    • The load balancer life cycle state is not ACTIVE.
    • No backend sets are defined for the load balancer.
    • All the following conditions are true:

      • More than half of the backend sets associated with the load balancer return a status of UNKNOWN.
      • None of the backend sets return a status of WARNING or CRITICAL.
      • The load balancer life cycle state is ACTIVE.
    • The system could not retrieve metrics for any reason.

For guidance on detecting and correcting common issues, see Using Health Status.

Load Balancer Health Details

The load balancer Details page provides the same Overall Health status indicator found in the list of load balancers. It also includes counters for the Backend Set Health status values reported by the load balancer's child backend sets.

The health status counter badges indicate the following:

  • The number of child entities reporting the indicated health status level.
  • If a counter corresponds to the overall health, the badge has a fill color.
  • If a counter has a zero value, the badge has a light gray outline and no fill color.

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be given the required type of access in a An IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization. you should 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.

If you're new to policies, see Getting Started with Policies and Common Policies.

Using the Console

To create a load balancer
To delete a load balancer

Managing Tags for a Load Balancer

You can apply tags to your resources, such as load balancers, to help you organize them according to your business needs. You can apply tags at the time you create a load balancer, or you can update the load balancer later with the desired tags. For general information about applying tags, see Resource Tags.

To manage tags for a load balancer

Monitoring Resources

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 Overview and Notifications Overview.

For information about monitoring the traffic passing through your load balancer, see Load Balancing Metrics.

Using the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Use these API operations to manage load balancers: