Web and application clusters
HAProxy or Nginx in front, keepalived for the shared address, several application servers behind. Sessions and caches set up so any server can answer any request.
High availability and cloud
Clusters, failover and cloud setups
Two load balancers sharing one address. Databases that copy themselves to a second machine and switch over on their own. Container platforms, virtualisation clusters and a second site for when the first one burns down. On dedicated hardware, in the cloud, or a mix.
When it's worth it
Redundancy costs money twice: once for the extra hardware and again for the extra complexity. It pays off when an hour of downtime costs more than a year of the second server. For an internal tool used during office hours it usually doesn't. We'll tell you which side of that line you're on before we draw anything.
What's included
What we do
Database replication
MySQL or MariaDB replication, Galera, or PostgreSQL with Patroni. Automatic failover, and point-in-time recovery for when someone deletes the wrong table.
Kubernetes
When it's justified. On your own servers or as a managed service, with ingress, storage, secrets and deployments from Git.
Proxmox clusters
Virtual machines that move to another host when one fails. Storage on Ceph or replicated disks.
Cloud
Designs on AWS, Azure, Google Cloud or European providers, moving one workload at a time, and a look at the monthly bill while we're there.
Everything as code
Terraform or OpenTofu and Ansible, in a repository you own. If a whole environment disappears, it can be rebuilt.
Disaster recovery
A copy at a second site, written recovery steps, and a practice run so we know how long it really takes.
What you have at the end
- A design with agreed availability targets
- The infrastructure code, in your repository
- Failover and recovery runbooks
- A report from the failover test, with times
What we don't do
- Kubernetes for a single website
- Promising 99.99% on one server
A typical setup
Any one part can fail
This is a common shape for a web platform. Two load balancers share one address, so if one stops the other answers. Three application servers sit behind them. The database copies itself to a standby that takes over on its own. Backups allow a restore to any point in time, and a second site holds another copy for the day a whole data centre goes dark.
We size each part for the target you actually need, which is often less than people expect.
Availability
What 99.9% means in hours
How much unplanned downtime each target allows. Each extra nine divides the allowed downtime by ten. Past 99.9% there's no time left for a person to wake up and log in, so recovery has to happen by itself.
| Target | Per year | Per month | What it takes |
|---|---|---|---|
| 99.5% | 1 d 19 h 49 min | 3 h 39 min | One good server and good backups |
| 99.9% | 8 h 46 min | 43 min | Spare components in one location |
| 99.95% | 4 h 23 min | 22 min | Automatic failover, tested |
| 99.99% | 53 min | 4 min | Two locations and no manual steps |
Prices
What it costs
Assessment and design
from €2,400
A workshop, availability targets, a design document and a price for building it.
Failover test
€890
Per platform. We fail it over on purpose, time the recovery, check for data loss and write it up.
Prices are without VAT. Anything else is quoted, or charged at €96.80 an hour. All prices.
Software
What we use for this
- HAProxy
- keepalived
- Kubernetes
- k3s
- Proxmox VE
- Ceph
- Patroni
- Galera
- Terraform
- OpenTofu
- Ansible
- Argo CD
- AWS
- Azure
- Hetzner
Questions
Things people ask
- Do we need Kubernetes?
- Probably not, unless you run lots of services or several teams deploy every day. Two load balancers and a replicated database cover a lot of ground with much less to look after.
- Cloud or our own hardware?
- Steady workloads are usually cheaper on dedicated servers. Spiky ones suit the cloud. Plenty of setups end up using both.
- How do we know failover works?
- We switch it over on purpose, at a time we agree, and measure how long it takes and whether anything was lost.
Articles
If you want the detail
High availability & cloud
What 99.9% actually means, and what more nines cost
An availability target turns into minutes of downtime, gets worse with every dependency, and can be undone by one failure that hits every redundant copy at once. How to pick a target your setup can really meet.
Security & continuity
Your backup job says OK. That doesn't mean you can restore
A backup job that finishes without errors tells you something was copied. Whether you can get a working system back, and how long it takes, you only find out by restoring it. Here's how we do that, and what we write down each time.
Got something that needs looking after?
Tell us what you have and what's bothering you. You'll hear back within one working day, usually with a few questions before any price.