Oracle Cloud Infrastructure―OCI Load Balancing Service Basics

A load balancer (LB) sits between the clients and the backends (e.g., web servers) performs tasks such as:

• Service Discovery
• What backends are available in the system?  
• How should the load balancer talk to them?
• Health Check
• What backends are currently healthy and available to accept requests?
• Load Balancing
• What algorithm should be used to balance individual requests across the healthy backends?

OCI Load Balancing Service is an LB implemented as a service in Oracle Cloud Infrastructure.  In this article, we will cover the basics of  OCI Load Balancing Service.

OCI Load Balancer Level 100 (Part 1 - 3)

OCI Load Balancer Level 200 (Part 1 -2 )

Benefits of Load Balancer

• Fault tolerance and HA
• Using health check and LB algorithms, an LB can effectively route around a bad or overloaded backend
• Scaling
• LB maximizes throughput, minimizes response time, and avoids overload of any single resource
• Naming abstraction
• Name resolution can be delegated to the LB; backends don't need public IP addresses

A simple Public Load Balancing System Configuration

Features of OCI Load Balancing Service

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).   It supports the following capabilities:

• Various Protocols
• TCP, HTTP/1.0, HTTP/1.1, HTTP/2, WebSocket
• SSL offloading
• SSL termination
• SSL terminates at LB
• SSL Tunneling
• SSL is implemented between LB and backend servers
• End-to-End SSL
• LB can accept SSL encrypted traffic from clients and encrypt traffic to the backend servers
• Backend Set 
• The backend set is a logical entity that includes:
• A list of backend servers (e.g., Application servers)
• Each backend server is assigned a weight 
• A load balancing policy.
• A health check policy.
• Optional SSL handling.
• Optional session persistence configuration.
• The backend servers 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.
• Work Request
• The Load Balancing service handles requests asynchronously. Each request returns a work request ID (OCID) as the response.
• Health Check Policy
• TCP level or HTTP level
• 4 Health Status
• OK, Warning, Critical, Unknown
• Is associated with a backend set
• Load Balancing Policy
• Round-robin (default), IP hash,^[2] Least connection^[3]
• Decisions applied differently to TCP load balancer, sticky HTTP requests (cookie-based session persistent HTTP requests), and non-sticky HTTP requests:
• TCP load balancer / non-sticky HTTP request
• Considers policy and weight criteria
• Sticky HTTP requests
• Forwards requests using cookie's session information
• Is associated with a backend set
• Advanced features 
• Session persistence and content based routing
• Session persistence
• LB must be in HTTP mode
• Not enabled if clients do not accept cookies
• If session persistence is stopped by the server, subsequent requests received by LB will follow the load balancing mechanism configured
• Can be configured on a backend set with two parameters
• Cookie name (a single name or a match-all pattern)
• Session persistence will be activated if 
• A server sends a Set-Cookie response header with the cookie name matching the one in the Cookie name parameter, 
• The server sends any cookie (match-all pattern) 
• After activation, LB will create a new cookie that is sent to the client.  This is used in the future requests to correctly route the request to the session persisted backend server
• Fallback 
• True
• LB will pick a different server from the backend set, and redirect the session to it
• False
• LB will fail the request with an HTTP code 502 (Bad Gateway)

The key differentiators of OCI Load Balancing Service include:

• Supports two visibility options (Private or Public)
• Supports different provisioned bandwidth
• Single load balancer for TCP (layer4) and HTTP (layer 7) traffic

Public Load Balancer

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.

• Is regional in scope
• Requires 2 subnets (each in a separate AD) for HA (in case for AD outage): 
• One subnet hosts the primary load balancer and the other hosts a standby load balancer to ensure HA
• Each load balancer requires one private IP address from its host subnet. 
• The Load Balancing service attaches a floating public IP address to one of the specified subnets. (The floating public IP address does not come from your backend subnets.) 
• If there is a failure in that subnet's availability domain, the load balancer and public IP address switch to the other subnet. 
• The service treats the two load balancer subnets as equivalent and you cannot denote one as "primary".

Private Load Balancing System Configuration

Private Load Balancer

To isolate your load balancer from the internet and simplify your security posture, you can create a private load balancer.  It can be deployed in a multi-tier environment (e.g., frontend, application server, database server) and in between components (e.g., between frontend and application server or between application server and DB server).

The Load Balancing service assigns it a private IP address that serves as the entry point for incoming traffic.

• Requires only one subnet to host both the primary and standby load balancers. 
• The primary and standby load balancers each require a private IP address from that subnet, in addition to the assigned floating private IP address.
• If there is an availability domain outage, the load balancer has no failover.
• The assigned floating private IP address is local to the specified 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.
• Is local to the availability domain that contains the hosting subnet

How to Configure

To create a minimal system with a functioning load balancer, you must:

• Public load balancer:
• Create a VCN with an internet gateway and at least two public subnets. 
• Each subnet must reside in a separate availability domain.
• Private load balancer:
• Create a VCN with at least one 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.
• Accepts x.509 type certificates in PEM format only
• Update the load balancer subnet security list so it allows the intended traffic.

Highlights of important configuration considerations:

• Subnet
• Every subnet within your VCN has security lists  and a route table
• Security lists
• Determine whether a subnet can accept data traffic from the internet or from another subnet
• To accommodate high-volume traffic, stateless security list rules is strongly recommended for your load balancer subnets
• Rules to be added to both LB's and backend subnet's security list to allow communication between them
• Route table
• Backend Set
• Backend servers are recommended to be distributed across all availability domains within the region
• Load balancer
• Each has the following configuration limits:
• One IP address
• 16 listeners
• 16 backend sets
• 512 backend servers per backend set
• 1024 backend servers total
• Shape
• A template that determines the load balancer's total pre-provisioned maximum capacity (bandwidth) for ingress plus egress traffic. 
• Available shapes include 100 Mbps, 400 Mbps, and 8000 Mbps.
• Request Routing (for HTTP / HTTPS listeners only)
• Virtual hostname
• The following considerations apply to virtual hostnames:
• You cannot use regular expressions.
• To apply virtual hostnames to a listener, you first create one or more virtual hostnames associated with a load balancer.
• Virtual hostname selection priority is not related to the listener's configuration order.
• You can apply a maximum of 16 virtual hostnames to a listener.
• You can associate a maximum of 16 virtual hostnames with a load balancer.
• Path Routing
• A path route is a string that the LB matches against an incoming URI to determine the appropriate destination backend set
• You can specify up to 20 path route rules per path route set
• You can have one path route set per listener

Finally, you can watch above Level 100 (lab demo starts at 28:28) and Level 200 videos on OCI Load Balancer for more details.

References

1. OCI Level 100 - Load Balancing
2. IP Hash (OCI Load Balancing Policy)
• Uses an incoming requests's source IP as a hashing key to route non-sticky traffic to the same backend server
3. Least Connection (OCI Load Balancing Policy)
• Routes incoming non-sticky request traffic to the backend server with the fewest active connections
4. Getting Started with OCI  Load Balancing
5. Overview of Load Balancing (OCI)
6. Virtual Cloud Network Overview and Deployment Guide
7. Oracle Cloud Infrastructure Documentation (Official Documentation)
8. IaaS - Enterprise Cloud - Oracle Cloud Infrastructure (YouTube playlist)
9. OCI Level 100 Training (YouTube playlist)
10. OCI Level 200 Training (YouTube playlist)
11. Oracle Cloud Infrastructure (redthunder.blog) 
12. More articles on OCI (XML and More)