High availability · Hosted in Germany
High Availability Cluster
Hardware fails, networks have outages, software has bugs – the question is not if, but when. A high availability cluster is built so that your application never notices.
Context
What high availability means in numbers.
Availability is measured in nines – and the differences are bigger than they sound: 99% means more than three full days of downtime per year. 99.9% is still almost nine hours; only 99.99% pushes it below one hour. Which level your application needs is a business question: what does one hour of downtime cost you?
That is exactly why we define the availability target together before the architecture is designed – and then build precisely as much redundancy as that target requires. Committed targets go into the operations contract, not just on the website.
Architecture principle
No single point of failure.
High availability does not come from better hardware, but from architecture: every component whose failure would stop your application exists more than once.
- Redundant nodes in an N+1 design: the failure of a Proxmox node is a normal event, not an emergency.
- Automatic failover without manual intervention, typically within seconds.
- Redundant load balancers with a floating IP: the distribution layer itself is not a single point of failure either.
- Replicated storage: Ceph or ZFS replication – a disk failure costs no data.
- Redundant network paths: bonding, dual uplinks, separate networks for storage and management.
- Regular failover tests with a written record: we pull the plug before chance does.
Decision logic
Quorum, fencing, and the split-brain problem.
The most delicate moment for a cluster is not the failure itself, but the decision that follows: who takes over? For the automation to decide correctly, it needs clear rules. Quorum ensures that only a majority of nodes can act – which is why our clusters consist of at least three nodes.
Fencing complements the quorum: a node identified as faulty is cleanly isolated from the cluster before it can cause damage. This is how we prevent split-brain situations, in which two halves of a cluster write at the same time and data drifts apart beyond repair.
Reference
The failover, as it actually happens.
The complete failure scenario – from the Corosync heartbeat to alerting our on-call team – is described step by step on the home page and under Failover & high availability.
FAQ
Common questions about high availability.
Will my users notice a failover?
Usually not. The load balancer takes the failed node out of rotation within seconds; existing connections are re-established. How seamless this is in a specific case depends on the application – something we discuss honestly in the concept.
Is a two-node cluster enough?
Not for true high availability: with two nodes there is no majority in a failure scenario, and the cluster cannot decide safely. It is possible with an external quorum device – but for business-critical applications we recommend three nodes.
Does high availability replace backups?
No. Replication protects against hardware failure, but it also replicates mistakes: an accidental deletion is immediately on every copy. Separate, tested backups are therefore always part of the setup.
What availability is contractually committed?
We define the availability target together, matched to the application and the level of redundancy – and write it into the operations contract. We deliberately do not promise blanket nines without an architecture behind them.
Contact
What does one hour of downtime cost you?
Let's talk about your availability target. Initial assessment within one business day, free of charge and without obligation.
Request a project