Article 10 – OCI Load Balancing: Traffic Distribution and DNS steering

The Global vs. Regional Proxy Trade-Off

In Google Cloud, Cloud Load Balancing is a global, software-defined service. When you deploy a Global External HTTP(S) Load Balancer, it utilizes Google’s global Edge network. Traffic from a client enters the closest Edge Point of Presence (PoP) and is immediately terminated, then routed over Google’s internal network to backends running in any GCP region.

While highly performant, this model is inherently global. If you require strict regional isolation (where data and traffic processing must remain entirely within a single geographic or regulatory boundary), configuration is complex.

Oracle Cloud Infrastructure (OCI) approaches traffic distribution through Regional Load Balancers. An OCI Load Balancer runs as an active-standby pair of redundant instances within a single region, automatically distributing traffic across multiple Availability Domains or Fault Domains in your VCN.

OCI Load Balancing Portfolio: Layer 7 vs. Layer 4

OCI provides two distinct load balancing services based on the OSI network layer:

1. OCI Load Balancer (Layer 7 / Proxy)

Operates at Layer 7 (HTTP/HTTPS) and Layer 4 (TCP), acting as a full reverse proxy. It terminates incoming client connections and establishes new connections to backend servers.
* Flexible Bandwidth: Unlike load balancers that bill on rigid, pre-defined tiers or complex consumption formulas, OCI Load Balancers are flexible. You define a minimum and maximum bandwidth limit (e.g., a minimum of 10 Mbps and a maximum of 400 Mbps). OCI guarantees the minimum bandwidth and dynamically scales up to the maximum based on real-time traffic spikes, optimizing costs.
* Features: Supports SSL/TLS termination, HTTP header manipulation, URL-based routing (path route sets), and cookie-based session persistence.
* GCP Equivalent: GCP Regional External Application Load Balancer.

2. Network Load Balancer (NLB – Layer 4 / Pass-Through)

A non-proxy, pass-through load balancer that operates at Layer 3 and Layer 4 (TCP/UDP/ICMP).
* Ultra-Low Latency: Because it does not terminate the connection, the NLB is capable of processing millions of requests per second with microsecond latency. It routes packets directly to backend servers while preserving the original source IP and port.
* High Availability: Like the Layer 7 Load Balancer, OCI NLB is regional and provisions redundant active-standby instances automatically.
* GCP Equivalent: GCP Regional External/Internal TCP/UDP Network Load Balancer.

Load Balancer Architecture Components

When configuring an OCI Load Balancer, you configure three primary components:

  • Listener: The logical entity that exposes the load balancer’s IP address and listens for incoming requests on a specific port. It is here that you associate SSL certificates for HTTPS traffic.
  • Backend Set: A logical group of backend servers (compute instances) that receive the load balancer’s traffic. (Equivalent to GCP Backend Service). You configure:
  • Load Balancing Policy: Round Robin, Least Connections, or IP Hash.
  • Health Check: Protocols (HTTP, TCP), port, path, and timeout parameters.
  • Session Persistence: Configure cookie-based affinity to keep a client routed to the same backend.
  • Backend: An individual compute instance (or IP address) associated with a Backend Set, defined by its target port and weight.

Here is the traffic distribution topology, showing DNS steering directing requests to public or private load balancers:

OCI Load Balancing and DNS Traffic Management Topology

Global Routing: DNS Traffic Management

To route traffic across multiple OCI regions or implement multi-cloud failover, you use OCI DNS Traffic Management Steering Policies. (Equivalent to GCP Cloud DNS Routing Policies).

You configure your public DNS zone in OCI and apply one of the following steering policies to direct queries:
1. Failover (Active-Passive): Routes all traffic to a primary endpoint (e.g., a load balancer in Ashburn). OCI monitors the endpoint’s health; if it fails, DNS queries are automatically answered with the IP of a standby endpoint (e.g., in London).
2. Load Balancer (Weighted Round-Robin): Distributes queries across multiple endpoints based on user-defined weights.
3. Geolocation Steering: Answers DNS queries based on the physical location of the client’s DNS resolver, routing European users to a London load balancer and North American users to an Ashburn load balancer.
4. Geoproximity Steering: Routes clients to the physically closest endpoint based on latitude/longitude coordinate calculations.

Declarative Provisioning via Terraform

Instead of running manual CLI commands, you configure OCI Load Balancers using Terraform. The following configuration defines a flexible public Load Balancer (10-100 Mbps), a Backend Set with health checks, a Backend instance, and an HTTP Listener:

# 1. Create a flexible regional public Load Balancer
resource "oci_load_balancer_load_balancer" "prod_app_lb" {
  compartment_id = "ocid1.compartment.oc1..aaaaaaaadevvv..."
  display_name   = "Prod-App-LB"
  shape          = "flexible"
  subnet_ids     = ["ocid1.subnet.oc1.iad.aaaaaaaasub1..."]

  # Set the flexible bandwidth boundaries (min and max)
  shape_details {
    minimum_bandwidth_in_mbps = 10
    maximum_bandwidth_in_mbps = 100
  }

  is_private     = false
}

# 2. Define the Backend Set inside the Load Balancer
resource "oci_load_balancer_backend_set" "app_backend_set" {
  load_balancer_id = oci_load_balancer_load_balancer.prod_app_lb.id
  name             = "App-Backend-Set"
  policy           = "ROUND_ROBIN"

  # Configure the load balancer health checker
  health_checker {
    protocol          = "HTTP"
    port              = 80
    url_path          = "/health"
    response_body_regex = ".*"
  }
}

# 3. Register a backend compute instance in the Backend Set
resource "oci_load_balancer_backend" "app_backend_1" {
  load_balancer_id = oci_load_balancer_load_balancer.prod_app_lb.id
  backend_set_name = oci_load_balancer_backend_set.app_backend_set.name
  ip_address       = "10.0.1.15"
  port             = 80
  weight           = 1
}

# 4. Create an HTTP Listener to accept port 80 traffic
resource "oci_load_balancer_listener" "http_listener" {
  load_balancer_id         = oci_load_balancer_load_balancer.prod_app_lb.id
  name                     = "HTTP-Listener"
  port                     = 80
  protocol                 = "HTTP"
  default_backend_set_name = oci_load_balancer_backend_set.app_backend_set.name
}

By leveraging OCI’s flexible reverse proxies and combining them with DNS-level steering policies managed via Terraform, you can build highly resilient, multi-region web architectures that scale automatically while keeping operational costs tightly controlled.

Related Posts