2.1 Availability Domains, Fault Domains, Instance Pools & Load Balancers

Regional Architecture: Availability Domains and Fault Domains

Designing resilient cloud infrastructure begins with understanding the physical and logical boundaries of Oracle Cloud Infrastructure (OCI). An OCI Region is a localized geographic area containing one or more Availability Domains (ADs). Certain heritage regions (such as US East Ashburn, US West Phoenix, Germany Central Frankfurt, and UK South London) feature three Availability Domains connected by a private, high-speed, low-latency fiber network. Most newer expansion regions are single-AD regions, designed for rapid geographic footprint deployment while delivering enterprise-grade redundancy within a single metropolitan data center facility.

To ensure resilience within an individual Availability Domain, OCI partitions every AD into three Fault Domains (FDs): FAULT-DOMAIN-1, FAULT-DOMAIN-2, and FAULT-DOMAIN-3. A Fault Domain represents a logical grouping of physical hardware, including distinct physical server racks, redundant power distribution units (PDUs), uninterruptible power supplies (UPS), and dedicated top-of-rack (TOR) network switches. Fault Domains share no single point of hardware failure within the AD.

Fault Domains serve two critical architectural functions:

1. Hardware failure mitigation: If a physical server hypervisor crashes, a rack PDU trips, or a network switch fails, only compute and database nodes situated within that specific Fault Domain are impacted.
2. Maintenance isolation: A hardware failure or Compute hardware maintenance event that affects one Fault Domain does not affect instances placed in the other Fault Domains, so spreading replicas across all three keeps the service running during host maintenance.

---

Single-AD vs. Multi-AD High Availability Strategies

Architects must structure workloads differently depending on regional topology:

• Multi-AD Regions: High availability can be achieved across data centers. An active-active compute tier distributes web and application nodes across AD-1, AD-2, and AD-3. Database architectures can deploy an active primary database in AD-1 and a synchronous standby replica in AD-2 using Data Guard, eliminating data center facility loss as a catastrophic failure mode.
• Single-AD Regions: High availability is achieved by enforcing anti-affinity across FD-1, FD-2, and FD-3. Workloads must never place all application nodes or database replicas in the same Fault Domain. For instance, a two-node Oracle Real Application Clusters (RAC) system or primary-standby database pair allocates Node 1 to FD-1 and Node 2 to FD-2, achieving hardware and power separation within the same data center.

---

Instance Configurations and Instance Pools

To build self-healing, horizontally scalable compute clusters, enterprise architectures pair Instance Configurations with Instance Pools:

1. Instance Configuration: An immutable template defining compute parameters, including base OS image (custom or platform), compute shape (bare metal, standard VM, or flexible VM with defined OCPU and memory allocations), Virtual Network Interface Card (VNIC) attributes, subnet attachments, cloud-init initialization scripts, storage volume attachments, and tags.
2. Instance Pool: A group of instances created from one instance configuration and managed together (create, start, stop, terminate, and resize). Placement configurations spread the pool across availability domains and fault domains. When a load balancer or network load balancer is attached, every instance added to the pool is automatically added to the backend set and starts receiving traffic once it passes the health check.

---

Autoscaling Policies: Metric-Based vs. Schedule-Based

Instance pools integrate with Autoscaling Policies to respond dynamically to load demands without manual operator intervention:

• Metric-Based Autoscaling: Evaluates aggregated performance metrics emitted by the OCI Monitoring service. Typical trigger metrics include CPU utilization and memory utilization. The architect configures:
  • Scale-Out Rule: Metrics are aggregated into one-minute periods and averaged across all instances in the pool. When three consecutive one-minute averages meet the threshold (for example, average CPU above 75%), autoscaling adds a defined number of instances, up to the configured maximum pool size.
  • Scale-In Rule: When three consecutive one-minute averages fall below the scale-in threshold (for example, average CPU below 25%), autoscaling removes a defined number of instances, down to the configured minimum pool size.
  • Cooldown Period: The minimum time between metric-based scaling events. The minimum value is 300 seconds, which is also the default, and the cooldown starts when the pool returns to the Running state. A longer cooldown and a wide gap between the scale-out and scale-in thresholds prevent autoscaling thrashing (adding and then quickly removing instances).
• Schedule-Based Autoscaling: Uses Quartz cron expressions to set a target pool size, or to stop and start the pool's instances, at known times such as business-hour surges or nightly batch windows. One autoscaling configuration holds either a single metric-based policy or up to 50 schedule-based policies.

---

Regional Load Balancers and Health Check Probe Tuning

The OCI Load Balancer service is the usual single ingress point for highly available architectures. A load balancer is a regional resource built from a primary and a standby node placed in separate availability domains (multi-AD regions) or separate fault domains (single-AD regions). If the primary node fails, the standby takes over the same IP address, so clients do not need a DNS change.

Traffic is forwarded to backend sets populated by instance pool members. Ensuring traffic reaches only healthy instances requires precise health check probe tuning:

• Protocol: TCP-level checks (a TCP handshake) or HTTP-level checks (a request to a URI), optionally using SSL.
• Path: A dedicated lightweight health endpoint (such as /healthz or /status), decoupled from deep computational database queries to avoid false degradation during heavy load.
• Interval: Frequency of health checks (default 10,000 milliseconds).
• Timeout: Maximum wait for a backend response (default 3,000 milliseconds).
• Retries: The number of failed checks before a backend is taken out of rotation (default 3). A backend that later passes the health check is returned to rotation automatically.
• Response validation: HTTP checks validate the returned status code (for example, 200) and can match the response body with a regular expression.