High availability overview
This page is for IT architects and continuity planners in public bodies whose sites must stay reachable when one machine fails, for example because they carry emergency information or statutory publications. It answers what a single Exponential server gives you, what has to be in place before several servers can serve one site, and how to decide how far to go. The details are on the hosting pages Several web nodes and Clustering and shared storage.
Contents
- Start with the duty, not the technology
- What one server gives you
- What several web servers require
- The single points of failure that remain
- A step-by-step path
- Checklist
Start with the duty, not the technology
Ask first what the organization must deliver: how long the site may be unavailable, at what times, and how much recent content may be lost after a failure. These are organizational decisions, described on Availability targets and service levels and RPO and RTO as decisions. The project publishes no service level and no availability figure for the software itself; the numbers you promise come from your own design and tests.
What one server gives you
"A single machine with enough CPU and memory is the simpler choice for most sites" (Several web nodes). On one machine Exponential offers:
| Feature | Helps with | Page |
|---|---|---|
| Velocity's watchdog | restarts the engine after a crash or an out-of-memory kill | Velocity for public-sector teams |
| Response cache and HTTP cache | anonymous pages answered even under load spikes | Velocity response cache and HTTP cache |
| Maintenance mode | a clear 503 page with Retry-After during planned work | Maintenance mode and planned downtime |
| Fast restore | a tested backup brings the site back on another machine | Restore testing |
What one server does not give you: survival of a hardware, disk, data center or network failure. A cold standby machine with tested restores is often enough for a public body whose duty allows some hours of downtime.
What several web servers require
From Several web nodes:
| Part | Requirement | Page |
|---|---|---|
| Database | a database server every node reaches; not SQLite | Database high availability |
| Uploaded files | shared through the DFS cluster file handler and an NFS mount | Shared storage and the DFS cluster |
| Sessions | in the database, or the balancer keeps each user on one node | Sessions across servers |
| Load balancer | trusted by Exponential for the visitor's address and HTTPS | Several web servers behind a load balancer |
| Cron | on one node only | Several web servers behind a load balancer |
| Deploys, cache clears, maintenance | on every node | same page |
The single points of failure that remain
Several web servers remove the web server as a single point of failure, but not everything:
- The database server. Every node depends on it. Its own replication or clustering is needed to remove it; see Database high availability.
- The shared file storage. "If the NFS mount goes away, every server fails to read files" (Clustering and shared storage).
- The cluster metadata database, which is on the path of every file read.
- The load balancer, unless it is redundant itself.
- The data center, unless nodes and data are in more than one.
Write these into your continuity plan with an owner and a recovery procedure each.
A step-by-step path
| Step | What you add | You gain |
|---|---|---|
| 1 | one server, tested backups off site, a documented restore | recovery in the time your restore test measured |
| 2 | Velocity watchdog and external monitoring | automatic restart and fast alerting |
| 3 | a standby machine kept ready for restores | shorter recovery |
| 4 | a database server with its own replication | the database survives a machine failure |
| 5 | several web nodes, shared storage, a load balancer | the web tier survives a node failure |
Each step is a change of its own, with a test. Moving from SQLite to a database server is the documented way when a second web server is needed (Changing the database engine).
Checklist
- To do: Availability and recovery targets are decided by the organization and written down.
- To do: The design is chosen to meet them, and its remaining single points of failure are listed.
- To do: A restore has been tested and its time recorded.
- To do: For several nodes: database server, shared storage, sessions, one cron and trusted proxies are in place.
- To do: The continuity plan names an owner for each remaining single point of failure.
Related pages
- Availability index of this folder
- Disaster recovery plan
- SLA options for a provider's view of availability commitments
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.