Sprint 4C · HA architecture
Proxmox High Availability Hardware Requirements
Proxmox high availability is not created by buying three identical mini PCs and ticking an HA box. Quorum, low-latency cluster communication, guest storage availability, redundant networking and power domains all have to survive the failure you expect the cluster to handle.
Quick answer
What hardware does Proxmox HA require?
A practical HA design normally starts with at least three voting nodes for straightforward majority quorum, reliable low-latency Corosync communication, guest storage that a surviving node can access, and enough spare compute capacity to restart workloads after a failure. Two-node designs need an explicit quorum device strategy.
Live Amazon hardware
Live HA infrastructure hardware
Current 10/25GbE NICs, switches and UPS systems are shown near the top because HA depends heavily on network and power paths. Product cards do not claim that buying a device by itself makes a cluster highly available.
Buying decision
Design around failure domains, not node count
Three nodes on one switch, one UPS and one storage shelf still share single points of failure. Decide which failures must be tolerated—host, NIC, switch, storage, power or site—and remove those common dependencies deliberately.
Interactive planner
Proxmox HA Hardware Planner
Screen node count, quorum, Corosync, storage, network paths and power diversity.
The planner flags obvious architecture gaps. It cannot validate switch configuration, fencing behavior, storage consistency or actual failover time.
Compatibility checkpoints
Check these constraints before buying hardware
Quorum
A cluster needs a majority to make safe decisions. Two-node designs require a deliberate quorum strategy such as a QDevice rather than wishful thinking.
Corosync quality
Cluster communication values low latency and reliability. A dedicated physical path is preferable when production traffic could congest the same links.
Guest storage
A surviving node can only recover a guest when its required storage is available there through shared or appropriately replicated storage.
Power and network diversity
Three compute nodes on one switch and one UPS still share major failure domains. High availability is an end-to-end architecture, not a node count.
Quorum prevents split decisions
In Proxmox High Availability Hardware, quorum prevents split decisions addresses majority voting after communication loss as a failure-domain question. A cluster that cannot establish a majority should not continue making conflicting state changes as if nothing happened. A cluster is only as available as the dependencies that survive with the remaining nodes, so quorum, storage, switching and power must be considered together. Document which single failures the design is expected to tolerate.
Test quorum prevents split decisions during planned maintenance while backups are current. Prefer an odd number of voting participants for straightforward designs, and understand exactly what a QDevice contributes in a two-node environment. Observe quorum, guest restart, storage reachability and network convergence rather than assuming the diagram behaves correctly. Any dependency that fails the exercise becomes a concrete infrastructure task before production HA is trusted.
Three nodes are a foundation, not a guarantee
In Proxmox High Availability Hardware, three nodes are a foundation, not a guarantee addresses compute capacity after one node disappears as a failure-domain question. If every node normally runs near full CPU or memory, the cluster may have nowhere to restart the failed node’s guests. A cluster is only as available as the dependencies that survive with the remaining nodes, so quorum, storage, switching and power must be considered together. Document which single failures the design is expected to tolerate.
Test three nodes are a foundation, not a guarantee during planned maintenance while backups are current. Reserve enough capacity on survivors for the protected workload or define which guests are lower priority during a failure. Observe quorum, guest restart, storage reachability and network convergence rather than assuming the diagram behaves correctly. Any dependency that fails the exercise becomes a concrete infrastructure task before production HA is trusted.
Corosync needs a dependable path
In Proxmox High Availability Hardware, corosync needs a dependable path addresses low latency and predictable packet delivery as a failure-domain question. Bulk migration, replication or storage traffic can create bursts that matter more to cluster communication than average bandwidth suggests. A cluster is only as available as the dependencies that survive with the remaining nodes, so quorum, storage, switching and power must be considered together. Document which single failures the design is expected to tolerate.
Test corosync needs a dependable path during planned maintenance while backups are current. Use a dedicated physical network as a best-practice direction where practical, or protect Corosync from congestion with deliberate network design. Observe quorum, guest restart, storage reachability and network convergence rather than assuming the diagram behaves correctly. Any dependency that fails the exercise becomes a concrete infrastructure task before production HA is trusted.
Shared storage simplifies restart access
In Proxmox High Availability Hardware, shared storage simplifies restart access addresses guest disks visible from another node as a failure-domain question. HA cannot restart a VM elsewhere if its disks exist only on the failed node with no replication or shared backend. A cluster is only as available as the dependencies that survive with the remaining nodes, so quorum, storage, switching and power must be considered together. Document which single failures the design is expected to tolerate.
Test shared storage simplifies restart access during planned maintenance while backups are current. Choose shared storage, replication or another recovery architecture before configuring HA groups and expecting automatic restart. Observe quorum, guest restart, storage reachability and network convergence rather than assuming the diagram behaves correctly. Any dependency that fails the exercise becomes a concrete infrastructure task before production HA is trusted.
Replication changes the recovery model
In Proxmox High Availability Hardware, replication changes the recovery model addresses copies that may lag the latest writes as a failure-domain question. Replicated local storage can reduce dependence on a central array, but it has scheduling and recovery-point implications. A cluster is only as available as the dependencies that survive with the remaining nodes, so quorum, storage, switching and power must be considered together. Document which single failures the design is expected to tolerate.
Test replication changes the recovery model during planned maintenance while backups are current. Document the expected data currency and failure behavior instead of describing all replicated storage as equivalent to synchronous shared storage. Observe quorum, guest restart, storage reachability and network convergence rather than assuming the diagram behaves correctly. Any dependency that fails the exercise becomes a concrete infrastructure task before production HA is trusted.
Network redundancy needs switch diversity
In Proxmox High Availability Hardware, network redundancy needs switch diversity addresses dual NICs connected to independent paths as a failure-domain question. Bonding two ports into one switch protects a cable or port but not the switch itself. A cluster is only as available as the dependencies that survive with the remaining nodes, so quorum, storage, switching and power must be considered together. Document which single failures the design is expected to tolerate.
Test network redundancy needs switch diversity during planned maintenance while backups are current. If switch failure is inside the availability objective, provide separate switching paths and test what happens when one disappears. Observe quorum, guest restart, storage reachability and network convergence rather than assuming the diagram behaves correctly. Any dependency that fails the exercise becomes a concrete infrastructure task before production HA is trusted.
Power redundancy has the same logic
In Proxmox High Availability Hardware, power redundancy has the same logic addresses separate UPS units and circuits where justified as a failure-domain question. Three servers connected to one overloaded UPS share a single power failure domain. A cluster is only as available as the dependencies that survive with the remaining nodes, so quorum, storage, switching and power must be considered together. Document which single failures the design is expected to tolerate.
Test power redundancy has the same logic during planned maintenance while backups are current. If the design must survive UPS failure, separate critical nodes and network/storage dependencies across genuinely independent protected feeds. Observe quorum, guest restart, storage reachability and network convergence rather than assuming the diagram behaves correctly. Any dependency that fails the exercise becomes a concrete infrastructure task before production HA is trusted.
Fencing and watchdog behavior matter
In Proxmox High Availability Hardware, fencing and watchdog behavior matter addresses preventing failed nodes from corrupting cluster state as a failure-domain question. High availability requires safe decisions about a node that stops responding, not only a script that starts a VM elsewhere. A cluster is only as available as the dependencies that survive with the remaining nodes, so quorum, storage, switching and power must be considered together. Document which single failures the design is expected to tolerate.
Test fencing and watchdog behavior matter during planned maintenance while backups are current. Use the supported Proxmox HA mechanisms and test failure scenarios instead of improvising external restart automation around the cluster. Observe quorum, guest restart, storage reachability and network convergence rather than assuming the diagram behaves correctly. Any dependency that fails the exercise becomes a concrete infrastructure task before production HA is trusted.
HA is not a backup
In Proxmox High Availability Hardware, ha is not a backup addresses rapid service recovery versus historical data recovery as a failure-domain question. A replicated deletion, guest corruption or ransomware event can reach every HA copy. A cluster is only as available as the dependencies that survive with the remaining nodes, so quorum, storage, switching and power must be considered together. Document which single failures the design is expected to tolerate.
Test ha is not a backup during planned maintenance while backups are current. Maintain independent PBS backups and retention even when the cluster can restart guests automatically after a host failure. Observe quorum, guest restart, storage reachability and network convergence rather than assuming the diagram behaves correctly. Any dependency that fails the exercise becomes a concrete infrastructure task before production HA is trusted.
Maintenance should resemble failure
In Proxmox High Availability Hardware, maintenance should resemble failure addresses live migration, node drain and controlled shutdown as a failure-domain question. Routine maintenance is a safe opportunity to test whether capacity and network paths really support moving workloads. A cluster is only as available as the dependencies that survive with the remaining nodes, so quorum, storage, switching and power must be considered together. Document which single failures the design is expected to tolerate.
Test maintenance should resemble failure during planned maintenance while backups are current. Record migration time and unexpected dependencies during planned work so the next unplanned event is less surprising. Observe quorum, guest restart, storage reachability and network convergence rather than assuming the diagram behaves correctly. Any dependency that fails the exercise becomes a concrete infrastructure task before production HA is trusted.
Two-node clusters require special care
In Proxmox High Availability Hardware, two-node clusters require special care addresses quorum when either compute node is lost as a failure-domain question. Without another vote, two nodes cannot simply outvote each other after a partition. A cluster is only as available as the dependencies that survive with the remaining nodes, so quorum, storage, switching and power must be considered together. Document which single failures the design is expected to tolerate.
Test two-node clusters require special care during planned maintenance while backups are current. A QDevice can help quorum design, but it does not provide guest compute, storage or power redundancy by itself. Observe quorum, guest restart, storage reachability and network convergence rather than assuming the diagram behaves correctly. Any dependency that fails the exercise becomes a concrete infrastructure task before production HA is trusted.
Define the service objective
In Proxmox High Availability Hardware, define the service objective addresses which workloads must restart and how quickly as a failure-domain question. Not every homelab VM deserves the complexity of HA, while a business-critical service may justify substantial redundancy. A cluster is only as available as the dependencies that survive with the remaining nodes, so quorum, storage, switching and power must be considered together. Document which single failures the design is expected to tolerate.
Test define the service objective during planned maintenance while backups are current. Assign recovery objectives per workload and use HA only where the saved downtime outweighs the added infrastructure and operational complexity. Observe quorum, guest restart, storage reachability and network convergence rather than assuming the diagram behaves correctly. Any dependency that fails the exercise becomes a concrete infrastructure task before production HA is trusted.
Questions people ask
Proxmox High Availability Hardware questions
How many nodes do I need for Proxmox HA?
Three voting nodes are the straightforward majority-quorum starting point. Two-node clusters require a deliberate quorum strategy such as a QDevice.
Can Proxmox HA work with local storage?
Only when the guest storage required for recovery is available on another node through a supported shared or replication strategy. A disk that exists only on the failed node cannot be restarted elsewhere.
Do I need a dedicated Corosync network?
Proxmox best practice favors a dedicated physical network because Corosync values reliable low latency. Small environments may share links if congestion is carefully controlled.
Is a two-node Proxmox cluster HA?
It can be designed for HA with an appropriate quorum device and storage/network architecture, but two nodes alone do not provide straightforward majority quorum.
Does HA replace Proxmox Backup Server?
No. HA addresses service availability after component failure; PBS provides historical recovery from deletion, corruption and other data-loss events.
Do I need two switches for HA?
If switch failure is a failure mode you intend to survive, yes, you need independent network paths rather than two cables into the same switch.
How much spare compute should HA nodes have?
Enough for the protected workloads to run after the planned failure scenario. A cluster at full capacity has little room for automatic recovery.
Can Corosync use 10GbE?
Yes. Link speed is less important than reliable low latency and avoiding congestion. A dedicated or protected path is the key design consideration.
Should all nodes be identical?
Identical hardware can simplify capacity planning and migrations, but it is not an absolute requirement. Ensure CPU compatibility, resource headroom and the features each protected guest needs.
What is the first HA test?
Perform a controlled node maintenance/failure exercise after backups are verified, and confirm quorum, guest restart, storage access and network reachability behave as documented.
Official references and methodology
Verify the current Proxmox and hardware requirements before deployment
HA guidance follows current Proxmox quorum, Corosync and HA-manager concepts. The calculator is a readiness screen, not a substitute for validating storage, fencing, switch configuration and recovery under real failure tests.
As an Amazon Associate, Cloudzat may earn from qualifying purchases. Prices, firmware, transceiver compatibility, link capabilities, switch features, UPS runtime, battery condition and seller terms can change. Verify the exact delivered model and your platform documentation before deployment.