The term "high availability" has become one of the most overused phrases in the cloud hosting industry. Nearly every VPS provider on the market claims to offer it, yet the vast majority deliver nothing more than a single virtual machine running on a single physical server with a single storage device. When that server fails -- and hardware always fails eventually -- your VPS goes down with it.
Understanding the difference between genuine high availability and marketing-grade "cloud" labeling is critical for anyone running production workloads. This article explains exactly what high availability means at the infrastructure level, how it is implemented, and what questions you should be asking your hosting provider.
Defining High Availability: The Numbers That Matter
High availability (HA) is measured in uptime percentages, often expressed as "nines." The differences between each level may seem small on paper, but the real-world impact is dramatic:
| Availability Level | Uptime % | Downtime Per Year |
|---|---|---|
| Two nines | 99% | 3.65 days |
| Three nines | 99.9% | 8.77 hours |
| Four nines | 99.99% | 52.6 minutes |
| Five nines | 99.999% | 5.26 minutes |
True high availability targets four nines (99.99%) or better. Achieving this requires eliminating every single point of failure in the stack -- from compute and storage to networking and power. A single server with RAID and a backup power supply does not meet this threshold, regardless of how it is marketed.
The Anatomy of a Standard VPS Setup
To understand why most "cloud" VPS offerings are not highly available, you need to understand how they are typically built. The standard architecture looks like this:
┌─────────────────────────────────────────┐
│ Single Physical Server │
│ ┌───────┐ ┌───────┐ ┌───────┐ │
│ │ VPS 1 │ │ VPS 2 │ │ VPS 3 │ ... │
│ └───────┘ └───────┘ └───────┘ │
│ │
│ ┌─────────────────────────────────┐ │
│ │ Local RAID Storage Array │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────────┘A hypervisor (typically KVM, Xen, or VMware) runs on a single physical server. Multiple VPS instances share the server's CPU, RAM, and local storage. A local RAID array provides some protection against individual disk failures, but if the RAID controller fails, the motherboard fails, or the server loses network connectivity, every VPS on that machine goes down simultaneously.
The recovery process in this scenario is manual. An engineer must diagnose the hardware fault, replace the failed component, rebuild the RAID if necessary, and restart all virtual machines. This typically takes anywhere from 30 minutes to several hours -- sometimes longer if the failure occurs outside business hours or if replacement parts are not immediately available.
Why Calling This "Cloud" Is Misleading
Many providers run exactly this architecture and label it "cloud VPS" simply because they use KVM virtualization. The use of a hypervisor does not make something a cloud. Cloud architecture, by definition, implies resource abstraction, redundancy, and the ability to survive hardware failures without service interruption. A single server with KVM is just a virtual private server -- not a cloud server.
What True High Availability Looks Like
Genuine HA infrastructure requires three independent layers of redundancy working together: clustered compute, distributed storage, and redundant networking. Here is how these layers are structured:
┌──────────────────────────────────────────────────────┐
│ Proxmox HA Cluster │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Node A │ │ Node B │ │ Node C │ ... │
│ │ (Compute)│ │ (Compute)│ │ (Compute)│ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ ┌────┴──────────────┴──────────────┴────────┐ │
│ │ Ceph Distributed Storage │ │
│ │ (Data replicated across all nodes) │ │
│ └───────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────┐ │
│ │ Redundant Network Fabric │ │
│ │ (Bonded NICs, dual switches, dual paths) │ │
│ └───────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘Layer 1: Clustered Compute with Proxmox VE
In a true HA setup, multiple physical servers (nodes) are joined into a cluster managed by a cluster resource manager. At MassiveGRID, we use Proxmox Virtual Environment (VE) with its built-in HA manager based on the Corosync cluster engine.
Every node in the cluster continuously communicates with every other node through a dedicated cluster network. This communication serves two critical purposes:
- Heartbeat monitoring: Each node sends periodic "I'm alive" messages. If a node stops responding, the cluster detects the failure within seconds.
- Fencing (STONITH): When a node fails, the cluster must ensure the failed node is truly offline before restarting its VMs elsewhere. This prevents "split-brain" scenarios where two copies of the same VM run simultaneously, which would cause data corruption. Proxmox uses IPMI/BMC-based fencing to power off the failed node before migration begins.
When the HA manager detects a node failure, it automatically restarts all affected VMs on healthy nodes in the cluster. The entire process -- detection, fencing, and restart -- typically completes in 60 to 120 seconds. No human intervention required. No support ticket. No waiting for an on-call engineer.
Layer 2: Distributed Storage with Ceph
Clustered compute alone is not enough. If VM data is stored on the local disks of the failed node, there is nothing to restart on another node. This is where distributed storage becomes essential.
Ceph is a distributed storage system that spreads data across all nodes in the cluster. When you write a block of data, Ceph replicates it to multiple OSDs (Object Storage Daemons) running on different physical servers. With a replication factor of 3 (the standard configuration), every piece of data exists on three separate physical machines.
This means that when a node fails, the VM's data is already present on the surviving nodes. The HA manager can restart the VM immediately because Ceph serves the VM's disk from the remaining replicas. There is no need to copy data, restore from backup, or wait for storage rebuilds.
We cover Ceph in much greater detail in our companion article: How Ceph Distributed Storage Protects Your Data.
Layer 3: Redundant Networking
The third pillar is network redundancy. A truly HA environment uses:
- Bonded network interfaces: Each server has multiple NICs bonded together (LACP/802.3ad). If one NIC or cable fails, traffic continues over the remaining links.
- Dual top-of-rack switches: Each server connects to two independent switches. A switch failure does not isolate any server from the network.
- Separate cluster network: Ceph replication traffic and Corosync heartbeat traffic run on a dedicated private network, isolated from public VM traffic. This prevents bandwidth contention and ensures cluster operations are never impacted by DDoS attacks or traffic spikes on the public network.
- Redundant upstream connectivity: Multiple transit providers and peering connections ensure that no single carrier failure disrupts connectivity.
The Five Questions to Ask Your VPS Provider
Before trusting a provider's HA claims, ask these questions. The answers will tell you everything you need to know:
- "If the physical server hosting my VPS fails at 3 AM, what happens?" -- The correct answer involves automatic detection and failover to another node. If the answer involves "our team will be notified" or "we'll migrate your VM," that is not HA.
- "Where is my VPS data stored?" -- If the answer is "local disks" or "local RAID," your data lives on a single machine. Distributed storage (Ceph, GlusterFS, or equivalent) means your data survives hardware failures.
- "How many physical nodes are in the cluster serving my VPS?" -- A minimum of three nodes is required for proper quorum in any HA cluster. Fewer than three means split-brain scenarios cannot be safely resolved.
- "What is your fencing mechanism?" -- If the provider does not know what fencing is, they do not run an HA cluster. Fencing (STONITH) is fundamental to any cluster that claims automatic failover.
- "What is the expected failover time for a hardware failure?" -- True HA failover completes in 1-2 minutes. If the answer is "typically under an hour" or involves manual steps, the provider is offering monitoring and manual recovery, not high availability.
Real-World Impact: Standard VPS vs. HA VPS
Consider a practical scenario. A power supply unit fails on the physical server hosting your VPS at 2:47 AM on a Saturday morning.
Standard VPS Provider
- Server goes offline. All VPS instances on the server stop immediately.
- Monitoring system detects the outage after 1-5 minutes.
- Alert is sent to the on-call engineer.
- Engineer acknowledges and begins diagnostics (15-45 minutes depending on response time).
- Failed PSU is identified. Replacement is sourced from spare parts inventory.
- Hardware is replaced and server is rebooted (30-60 minutes).
- VMs are started and verified (10-15 minutes).
- Total downtime: 1-3 hours, assuming spare parts are on-site.
MassiveGRID HA Infrastructure
- Server goes offline. Corosync detects missed heartbeat within 6 seconds.
- HA manager initiates fencing: IPMI confirms the node is powered off (10-15 seconds).
- HA manager restarts affected VMs on healthy cluster nodes (30-90 seconds).
- VMs resume operation with full access to their data via Ceph (already replicated to surviving nodes).
- Total downtime: 60-120 seconds, fully automatic, no human required.
The failed physical server is still down, but that is now a maintenance task -- not an emergency. An engineer replaces the hardware during the next business day while your services continue running without interruption on the remaining cluster nodes.
Why Most Providers Do Not Offer True HA
The reason is straightforward: it costs significantly more to build and operate. A genuine HA environment requires:
- More hardware: A minimum of three nodes per cluster, with enough headroom on each node to absorb the workloads of a failed node. This means running at 60-70% capacity instead of 90%+ capacity.
- Distributed storage overhead: Ceph with 3x replication means you need three times the raw storage capacity to deliver a given amount of usable space. NVMe drives are expensive; buying three times as many is a significant investment.
- Network infrastructure: Dual switches, bonded NICs, and a dedicated cluster network double the networking costs.
- Expertise: Managing Proxmox HA clusters and Ceph requires specialized knowledge. Most budget VPS providers do not employ engineers with this skill set.
This is why budget VPS plans at $2-5/month typically run on single servers with local storage. The economics of true HA simply do not work at those price points -- and any provider claiming HA at those prices is either subsidizing the cost or redefining the term.
How MassiveGRID Implements High Availability
At MassiveGRID, high availability is not a premium add-on. Our Managed Cloud Server and Managed Cloud Dedicated Server plans are built on Proxmox HA clusters with Ceph distributed storage from the ground up. Every VM is an HA-managed resource, every block of data is replicated across multiple nodes, and every cluster has the capacity to absorb node failures without degrading performance.
Our infrastructure spans four data center locations -- New York City, London, Frankfurt, and Singapore -- each built with the same HA architecture, redundant power (N+1 UPS and generator systems), and network connectivity with 12 Tbps DDoS protection.
For workloads where cost is the primary concern and some downtime is acceptable, our Cloud VPS plans starting at $1.99/month offer excellent performance on KVM with NVMe storage. But when your business depends on uptime, the managed HA platform is the right choice -- and the infrastructure behind it is what makes our 100% uptime SLA possible.
Conclusion
High availability is not a feature you can bolt on with a monitoring script or a clever RAID configuration. It is a fundamental architecture decision that permeates every layer of the infrastructure stack -- from how compute resources are clustered, to how data is stored and replicated, to how the network is designed for redundancy.
The next time you evaluate a cloud hosting provider, look past the marketing language. Ask about cluster sizes, storage architecture, fencing mechanisms, and failover times. The answers will tell you whether you are buying genuine high availability or just a VPS with a "cloud" label.
If you want to see how HA infrastructure works in practice, reach out to our engineering team. We are happy to walk you through the architecture and help you determine the right level of redundancy for your workloads.