High Availability Calculator
Model redundant nodes, active-active or active-passive service modes, quorum requirements, shared dependencies, serial reliability, and expected yearly downtime.
⚙HA Architecture Presets
🖥Cluster Inputs
Physical or virtual nodes that can host the service.
Use quorum size, minimum replicas, or the active node count.
🗺HA Topology Grid
📊Component Spec Grid
📋Architecture Reference
| Architecture | Typical minimum | Strength | Watch point |
|---|---|---|---|
| Single server baseline | 1 of 1 node | Simple recovery model | No node redundancy |
| Active-passive pair | 1 of 2 nodes | Clear ownership and standby capacity | Failover detection and promotion time |
| Active-active web pair | 1 of 2 nodes | Parallel serving path for stateless apps | Load balancer becomes a critical dependency |
| Three-node quorum cluster | 2 of 3 nodes | Majority vote and one node failure tolerance | Shared storage or witness availability |
| Five-node compute cluster | 3 of 5 nodes | Two node failures tolerated with majority | Capacity headroom must match failure policy |
🔢Quorum and Fault Tolerance
| Total nodes | Majority quorum | Node failures tolerated | Common home lab fit |
|---|---|---|---|
| 2 nodes | 2 votes, or 1 plus witness | 0 without witness, 1 for simple service failover | Small NAS or firewall pair |
| 3 nodes | 2 votes | 1 node | Proxmox, Kubernetes, database quorum |
| 4 nodes | 3 votes | 1 node | Works better with an added witness |
| 5 nodes | 3 votes | 2 nodes | Compute cluster with maintenance room |
🔗Serial and Parallel Reliability
| Model | Formula used | Meaning | Example dependency |
|---|---|---|---|
| Serial path | A system = A1 × A2 × A3 | Every listed part must be available | Node pool, switch path, storage, VIP |
| Parallel pair | A pair = 1 - (1 - A)² | Either redundant part can carry the service | Dual switches or mirrored storage heads |
| k-of-n node pool | Sum of probability for k through n online | At least the required node count must be up | Quorum cluster or active-active pool |
| Failover penalty | Events × (detect + promote) | Short transitions still add yearly downtime | VIP move, VM restart, database promotion |
⏱Downtime Target Table
| Availability target | Downtime per year | Downtime per month | HA interpretation |
|---|---|---|---|
| 99% | 87.6 hours | 7.3 hours | Recoverable service, not usually HA |
| 99.9% | 8.76 hours | 43.8 minutes | Basic redundancy with tested restores |
| 99.99% | 52.6 minutes | 4.38 minutes | Strong HA with low failover delay |
| 99.999% | 5.26 minutes | 26.3 seconds | Requires very careful dependency removal |
💡HA Planning Tips
High availability is achieved when a service can remain online even in the face of component failure. High availability is often of concern when the failure of a single drive or switch can take the entire service offline. A calculator is available on this page that can convert the availability of a service to specific number.
These numbers can help you to plan for failures instead of remaining in the dark about whether your cluster will remain operational. To use the availability calculator, you must enter the total number of node in your cluster and the minimum number of nodes that are required to provide the service. The number of nodes that are required to provide the service is the most important of the numbers entered into the calculator.
Use the availability calculator to check cluster uptime
A three-node cluster that requires that all three nodes be healthy to provide the service will offer very little protection from failures. The availability calculator can calculate the likelihood that the required number of nodes will be healthy and operational. The results of the availability calculator will tell you whether your redundancy provide a real level of protection or only a theoretical one.
Beyond the nodes that provide the service, there are a number of other paths, storage layer, and components that must remain available to maintain the availability of the service. Each of these component has there own availability percentages. These components often limit the availability calculations for your cluster.
If you multiply the availability percentages of each component together, the total availability of the cluster are determined. The availability calculator allows you to choose which model best describes your hardware and wiring. This will provide you with an understanding of how the serial or parallel arrangement of your systems can impact availability.
Many clusters are limited by availability of a single switch or storage shelf. Failover time is another component that must be considered when designing for availability. Failures occur within the redundant cluster, and during this period of failure, the service is not provided to the client.
The availability calculator will ask you to enter the number of failovers that will occur each year and the length of each individual failover. Each second of failover each year can result in several hours of downtime each year. Despite the seemingly excellent availability that is calculated for a cluster, there may be significant downtime resulting from these failover time.
You can use this information to decide whether to add another node to the cluster or to purchase hardware that will reduce the failover time for the cluster. Another component of the availability tables on this page are the reference tables. These tables include common designs and availability calculations.
The reference tables can show you the reasons that two-node clusters require an external witness for quorum calculations, or why five-node clusters can lose more nodes simultaneously than three-node clusters. These tables do not replace your cluster availability calculations and measurements, but they do help to provide context to those numbers. There are a few realities of high availability calculations that this availability calculator cannot capture.
For instance, high availability calculations can disregard the impact of firmware updates, power events, and human error on availability. Failures can cascade into other failures within the cluster. To account for these failings, many cluster builders include a margin of safety into their availability calculations.
Another factor that can have an impact on availability is the quorum rule for the cluster. Availability percentages calculations often miss quorum calculations. Quorum calculations require an odd number of server to avoid split-brain scenarios.
Split-brain scenarios can result in data corruption within the cluster. Availability calculators will often fail to calculate if a quorum is low enough to be safe. Additionally, it is up to the cluster administrator to calculate if a marginal quorum can be accepted by the specific workload being provided by the cluster.
The goal for using an availability calculator is not to have a specific availability percentage for the cluster. The goal is to understand where the cluster defeats its risk budget. Based off this understanding, you can decide whether to improve that specific component of the cluster.
Or, you can decide whether the current availability is sufficient based upon the importance of the service that the cluster provides. The availability calculator makes this a concrete number instead of feeling and an estimation.
