About the Components of Oracle Cloud Infrastructure Load Balancing Classic

When you create a load balancer using Oracle Cloud Infrastructure Load Balancing Classic, you define various attributes and characteristics of the load balancer.

Specifically, each load balancer consists of the following components. Some of these components are mandatory and some are optional, depending upon the specific topology you are implementing.

Topics

About Load Balancer Digital Certificates

You must obtain a digital certificate if you want to use a secure connection between the load balancer and the clients sending the request or between the load balancer and the origin servers in the server pool.

For example, in a production environment, you can use the HTTPS protocol to protect the HTTP requests that are sent to the load balancer from the Internet. The HTTPS protocol uses Secure Socket Layer (SSL) or Transport Layer Security (TLS) to secure the HTTP requests to the load balancer. SSL and TLS require a digital certificate.

Before you can use a digital certificate, you must obtain or create the certificate and then import the certificate so you can assign it to a load balancer.

Oracle Cloud Infrastructure Load Balancing Classic supports two types of digital certificates.

Server certificates, which are used to secure the connection between Internet clients and the load balancers. Server certificates secure the URL you are using to access the load balancer; for example:

https://mycompany.example.com

In this scenario, the load balancer is the server and the clients are the Web browsers sending requests to the load balancer. The clients request the certificate from load balancer to ensure they are connecting to a valid site.
Trusted certificates, which are used to secure the connection between the load balancer and the origin servers in the server pool.

In this scenario, the load balancer is the client, connecting to server software (such as an application server or Web server) that is running on the origin server. The application or Web servers have been configured to accept only secure HTTPS or SSL requests, and the clients must present a specific, trusted certificate to the server.

About Load Balancer Listeners

Before you use a load balancer, you must define at least one listener. A listener defines the virtual host, port, and protocol that the load balancer will use to listen for new requests.

For example, suppose you want the load balancer to listen for all requests to the following URL:

http://mycompany.example.com:80

For this example, you define a new listener called “myFirstListener.” The listener would include the following characteristics:

Name: myFirstListener
Port: 80
Virtual Hosts: mycompany.example.com

The load balancer listens for any requests to that specific URL and then routes those requests to the server pool defined for that listener.

About Load Balancer Server Pools

When you create a load balancer with Oracle Cloud Infrastructure Load Balancing Classic, you must define one or more servers (referred to as origin servers) to which the load balancer can distribute requests. A set of origin servers is called a server pool. When a request is received on one of the load balancer listeners, the load balancer routes that request to one of the servers in the server pool.

To define a server in the server pool, enter the IP address or DNS name of the compute instances, or you can select existing Compute instances available in your environment.

You can create a single server pool for each load balancer, or you can define individual server pools and assign them to specific listeners.

About Load Balancer Policies

Oracle Cloud Infrastructure Load Balancing Classic provides advanced features that you can configure by attaching specific policies to the load balancer.

The following table describes some of the policies you can set for a specific load balancer.

Policy	Description
Application Cookie Stickiness Policy	This policy enables session stickiness (session affinity) for any request based on a given cookie name specified in the policy. The cookie name is application specific. A session is defined by the presence of the same cookie value for that given cookie name in incoming requests. All requests belonging to the same session are routed to the same origin server.
CloudGate Policy	This policy provides attributes to protect resources/applications with the help of CloudGate module available in Load Balancer. The attributes in this policy are used to set CloudGate specific headers. These headers will enable CloudGate to lookup for the application and the policy present under the appropriate IDCS Tenant containing information for the protection mechanism to be enforced.
Load Balancer Cookie Stickiness Policy	This policy enables session stickiness (session affinity) for all requests for a given period of time specified in the policy. A unique cookie is generated by the load balancer with an expiration time for any new request that does not already carry the same cookie. Clients are expected to carry this cookie in subsequent requests to form a session. Until expiration time has reached, the load balancer will route all such requests to the same origin server. If expiration time specified in the policy is 0, the session will last indefinitely until the cookie is no longer present in the subsequent requests.
Load Balancing Mechanism Policy	This policy enables you to specify a load balancing mechanism for distributing client requests across multiple origin servers by using one of the following methods: Round Robin IP Hash Least Connections
Rate Limiting Request Policy	Limits the number of requests that can be processed per second by the load balancer. This feature enables administrators to optimize the utilization of the available bandwidth by limiting the rate of incoming requests from clients.
Redirect Policy	Redirects all requests to this load balancer to a specific URI.
Resource Access Control Policy	Controls what clients have access to the load balancer, based on the IP address or the Classless Inter-Domain Routing (CIDR) range of the incoming request.
Set Request Header Policy	Configures a load balancer listener so it inserts additional information into the standard HTTP headers of the requests it forwards to its server pool. You can identify the specific headers you want to modify and actions to perform if the header is already populated with specific values.
SSL Negotiation Policy	If you are securing connections between incoming client requests and the load balancer, you can use this policy to define specific SSL protocols, ciphers, and server order preference for the secure connection.
Trusted Certificate Policy	Identifies a trusted certificate, which the load balancer uses when making a secure connection to the compute instances in the server pool. Before you can reference the trusted certificate, you must import it, using the Digital Certificates tab in the Compute console. You can then can reference the certificate using the name (or URI) you provided when you imported the certificate. If you are configuring a secure connection (HTTPS or SSL) between the load balancer and the origin servers, you must add this policy to the load balancer. See About Load Balancer Digital Certificates.

About Load Balancer Properties

Each load balancer you create with Oracle Cloud Infrastructure Load Balancing Classic has a set of properties. You can set these properties when you create the load balancer or edit them later.

The load balancer properties are divided into these categories:

Information properties, which provide static information about the load balancer, such as the IP addresses assigned to the load balancer and the health state of the load balancer.
General properties, such as the load balancer name and description. You can also use this category to optionally set additional general properties, such the list of HTTP methods supported by the load balancer (GET, PUT, POST, and so on).