Oracle Cloud Infrastructure Documentation

Managing Backend Servers

This topic describes how to manage backend servers for use with a load balancer. For information about managing load balancers, see Managing a Load Balancer.

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.

Working with Backend Servers

When you implement a load balancer, you must specify the backend servers (Compute A bare metal or virtual machine (VM) compute host. The image used to launch the instance determines its operating system and other software. The shape specified during the launch process determines the number of CPUs and memory allocated to the instance.) to include in each A logical entity defined by a list of backend servers, a load balancing policy, and a health check policy.. The load balancer routes incoming traffic to these backend servers based on the policies you specified for the backend set. You can use the Console to add and remove backend servers in a backend set.

To route traffic to a backend server, Load Balancing requires the IP address of the compute instance and the relevant application port. If the backend server resides within the same VCN as the load balancer, Oracle recommends that you specify the compute instance's private IP address. If the backend server resides within a different VCN, you must specify the public IP address of the compute instance. You also must ensure that the VCN's Virtual firewall rules for your VCN. rules allow Internet traffic.

Warning

When you add backend servers to a backend set, you specify either the instance OCID or an IP address for the server to add. An instance with multiple VNICs attached can have multiple IP addresses pointing to it.

  • If you identify a backend server by OCID, Load Balancing uses the primary VNIC's primary private IP address.
  • If you identify the backend servers to add to a backend set by their IP addresses, it is possible to point to the same instance more than once.

To enable backend traffic, your backend server subnets must have appropriate ingress and egress rules in their security lists. When you add backend servers to a backend set, the Load Balancing service Console can suggest security list rules for you. If you do not allow the service to create security list rules, you must create your own rules using the Networking service. 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.

You can add and remove backend servers without disrupting traffic.

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.

Backend Server Health Summary

The Console list of a backend set's backend servers provides health status summaries that indicate the overall health of each backend server. The primary and standby load balancers both provide health check results that contribute to the health status. There are four levels of health status indicators. The meaning of each level is:

  • OK: The primary and standby load balancer health checks both return a status of OK.
  • WARNING: One health check returned a status of OK and one did not.
  • CRITICAL: Neither health check returned a status of OK.
  • UNKNOWN: One or both health checks returned a status of UNKNOWN or the system was unable to retrieve metrics.

To view the health status details for a specific backend server, click its IP Address.

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

Backend Server Health Details

The Details page for a backend set provides the same Overall Health status indicator found in the backend set's list of backend servers. It also reports the following data for the two health checks performed against each backend server:

ip address
The IP address of the health check status report provider, which is a Compute instance managed by the Load Balancing service. This identifier helps you differentiate same-subnet (private) load balancers that report health check status.
The Load Balancing service ensures high availability by providing one active and one standby load balancer. For a public load balancer, each load balancer instance resides in a different subnet. For a private load balancer, both load balancers reside in the same subnet. To diagnose a backend server issue, you must know the source of the health check report. For example, a misconfigured security list might cause a load balancer instance to report that a backend server is healthy. The other load balancer instance might return an unhealthy status. In this case, one of the two load balancer instances cannot communicate with the backend server. Reconfigure the security list to restore the backend server's health status.
status
The status returned by the health check. Possible values include:
  • OK

    The backend server's response satisfied the health check policy requirements.

  • INVALID_STATUS_CODE

    The HTTP response status code did not match the expected status code specified by the health policy.

  • TIMED_OUT

    The backend server did not respond within the timeout interval specified by the health policy.

  • REGEX_MISMATCH

    The backend server response did not satisfy the regular expression specified by the health policy.

  • CONNECT_FAILED

    The health check server could not connect to the backend server.

  • IO_ERROR

    An input or output communication error occurred while reading or writing a response or request to the backend server.

  • OFFLINE

    The backend server is set to offline, so health checks are not run.

  • UNKNOWN

    Health check status is not available.

last checked
The date and time of the most recent health check.

Health status is updated every three minutes. No finer granularity is available.

Using the Console

To add one or more servers to a backend set
To remove a server from a backend set

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.

The API enables you to mark a backend server in the following ways:

backup
The load balancer forwards ingress traffic to this backend server only when all other backend servers not marked as "backup" fail the health check policy. This configuration is useful for handling disaster recovery scenarios.
drain
The load balancer stops forwarding new TCP connections and new non-sticky HTTP requests to this backend server so an administrator can take the server out of rotation for maintenance purposes.
offline
The load balance forwards no ingress traffic to this backend server.

You also can use the API to specify a server's load balancing policy weight. For more information on load balancing policies, see How Load Balancing Policies Work.

Use these API operations to manage the backend servers in a backend set: