High Availability Hosting: Load Balancing and Clusters

Introduction

High availability hosting is designed to reduce downtime by removing single points of failure. Instead of relying on one server for everything, a high availability setup uses multiple components that can continue working if one part fails.

A typical high availability architecture may include a load balancer, multiple web servers, database replication, shared or replicated storage, health checks, failover rules, monitoring and backups. This can improve resilience, but it also increases complexity and cost.

Quick answer

What is high availability hosting?

High availability hosting means designing infrastructure so a service remains available even when part of the system fails.

A simple website may run on one server:

• web server
• database
• files
• email
• DNS configuration

If that server fails, the whole site may go down.

A high availability setup separates and duplicates important parts:

• load balancer
• multiple web servers
• replicated database
• shared or synchronized files
• health checks
• failover routing
• monitoring
• backups

Single points of failure

A single point of failure is any component that can take the whole service offline if it fails.

Common single points of failure:

• one web server
• one database server
• one storage volume
• one DNS provider
• one load balancer
• one network path
• one power source
• one data center
• one control panel server
• one backup location
• one SSL renewal process

Load balancers

A load balancer receives traffic and distributes it across multiple backend servers.

A load balancer can:

• send traffic to healthy servers
• remove failed servers from rotation
• distribute requests
• terminate SSL
• route by hostname or path
• improve scaling
• reduce direct exposure of web nodes
• help during maintenance

Common load balancing methods:

• round robin
• least connections
• weighted routing
• IP hash
• health-check-based routing

Web server clusters

A web cluster uses two or more web servers to run the same website or application.

web01
web02
web03

The load balancer sends visitors to available nodes.

Requirements:

• same application code on each node
• consistent configuration
• shared or synced uploads
• same PHP/runtime version
• same environment variables
• access to the same database
• health checks
• deployment process

Health checks and failover

Health checks allow a load balancer or monitoring system to decide whether a server is healthy.

Health checks may test:

• HTTP status code
• response time
• specific health endpoint
• database connectivity
• application readiness
• disk space
• service availability
• SSL status

Failover happens when traffic is moved away from a failed component.

Database high availability

Databases are often the hardest part of high availability hosting.

Common approaches:

• primary-replica replication
• managed database cluster
• automatic failover
• read replicas
• multi-node database cluster
• backup plus restore plan
• point-in-time recovery

Challenges:

• data consistency
• replication lag
• failover timing
• split-brain risk
• write conflicts
• backups
• application connection handling

Shared storage and uploads

In a cluster, website files and user uploads must be available to all web nodes.

Options:

• shared network storage
• object storage
• file synchronization
• deployment pipeline
• CDN for static files
• separating uploads from application code

Problems if storage is not planned:

• uploaded images appear on one server only
• user files disappear between requests
• plugin/theme changes are inconsistent
• cache files differ by node
• backups miss files from some nodes

DNS failover

DNS failover changes DNS records when a service becomes unavailable.

It can be useful for:

• simple failover between IPs
• regional failover
• backup hosting location
• disaster recovery
• emergency traffic switching

Limitations:

• DNS caching can delay changes
• not all users switch instantly
• low TTL helps but does not guarantee instant failover
• application data must already be available elsewhere
• email and other records may be separate

Active-active vs active-passive

Sessions and cache

Applications in a cluster must handle sessions and cache carefully.

Options:

• store sessions in database
• store sessions in Redis or Memcached
• use stateless authentication
• enable sticky sessions
• avoid local-only session files
• use shared cache where needed

Why this matters

HA hosting is not only about adding more servers. It requires correct architecture, monitoring, failover testing, backups, deployment process and operational discipline.

How to check high availability readiness

Use Website Status Checker, Domain Health Checker and infrastructure monitoring to review public availability and technical risks.

1. Website status — Confirm the site responds correctly.
2. DNS — Check current records and TTL values.
3. SSL — Confirm certificates work across all public endpoints.
4. Load balancer — Confirm health checks and backend rotation.
5. Web nodes — Confirm each node serves the same application version.
6. Database — Check replication, backups and failover plan.
7. Storage — Confirm uploads and shared files are available to all nodes.
8. Monitoring — Confirm alerts for nodes, database, SSL, disk, CPU and response time.

Common problems

How to plan high availability hosting

1. Step 1: Define uptime requirement

   Decide how much downtime is acceptable and what downtime costs.

2. Step 2: Identify single points of failure

   Review web server, database, storage, DNS, load balancer and backups.

3. Step 3: Add load balancing

   Route traffic to multiple healthy web nodes.

4. Step 4: Plan web node consistency

   Use deployment automation, shared storage or object storage.

5. Step 5: Plan database availability

   Use managed HA database, replication or reliable backup/restore plan.

6. Step 6: Handle sessions and cache

   Avoid local-only session storage in multi-node setups.

7. Step 7: Configure health checks

   Check real application readiness, not only server response.

8. Step 8: Monitor everything

   Monitor load balancer, nodes, database, storage, DNS, SSL and response time.

9. Step 9: Test failover

   Simulate failure before relying on the architecture.

10. Step 10: Document rollback

    Keep recovery procedures, DNS values and provider contacts ready.

Example high availability architecture

Visitor
  ↓
DNS
  ↓
Load balancer
  ↓
web01       web02
  ↓           ↓
Shared storage / object storage
  ↓
Database primary + replica
  ↓
Backups + monitoring + alerts

Purpose:
- load balancer routes traffic
- web nodes serve the app
- storage keeps files consistent
- database replication improves resilience
- monitoring detects failures

When high availability is worth it

HA hosting is usually worth considering when:

• website downtime directly loses revenue
• checkout or payments must stay online
• application has active users all day
• client contracts require uptime
• traffic spikes are common
• support cost from downtime is high
• business reputation depends on availability
• recovery from backup is too slow
• one server failure would be unacceptable

HA may be unnecessary when:

• site is small or low traffic
• downtime impact is low
• budget is limited
• application is not designed for clustering
• backups and quick restore are enough

High availability vs backups

You still need backups because HA does not protect against:

• accidental deletion
• bad deployments
• malware
• database corruption
• user mistakes
• ransomware
• application bugs
• compromised admin accounts

Useful availability checks

Check website status:
curl -I https://example.com

Follow redirects:
curl -IL http://example.com

Check DNS:
dig example.com A

Check TTL:
dig example.com A +noall +answer

Check SSL:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Check response time:
curl -o /dev/null -s -w "time_total: %{time_total}\n" https://example.com

Check load balancer backend manually:
curl -I http://web01.internal
curl -I http://web02.internal

Frequently asked questions