High Availability with Proxmox VE: Configuring a Two-Node Cluster with Shared Storage

Let's be real. That random Tuesday 3 AM outage? It wasn't "fun" for anyone. Your phone blew up. The boss got a fancy report about lost revenue. Now suddenly, making your VM infrastructure bulletproof is priority number one. High Availability isn't just a buzzword. It's your ticket to sleeping through the night. Proxmox gives you the tools to build that peace of mind. But you have to put the pieces together. And it starts with understanding what can go wrong before it does.

The Two-Node Cluster: A Balancing Act

Here's the thing about clusters. You usually want three nodes. It's the golden rule for avoiding "split-brain" scenarios. But what if your budget or rack space only allows for two? Proxmox has a workaround. It relies on a third, external "witness" to break ties. This could be a tiny virtual machine elsewhere, or even a cheap Raspberry Pi. The point is, two nodes can work. They just need a referee. Without it, if the network link between them flakes out, both might think the other is dead. Chaos ensues.

The Shared Storage Shuffle: Ceph vs. ZFS

This is where the rubber meets the road. If your VM lives on one server's local disk, and that server dies, the VM is down even if another node is ready. Shared storage fixes this. The VM's disk is on a piece of storage *both* nodes can see. When Node A dies, Node B can just... pick up where it left off. Proxmox really pushes two methods. Ceph is amazing. It's software-defined storage that replicates data across all nodes, creating its own resilient network. But for two nodes? It's overkill and resource-heavy. For a simpler life, look at ZFS replication. It's not *live* shared storage. It's a scheduled sync. Good enough for a lot of us. Pick your poison based on your need for simplicity versus seamless failover.

Nuts, Bolts, and The Config That Actually Works

Forget the theory. Let's talk setup. First, get your network straight. Dedicated NICs for cluster communication (corosync) and storage traffic (Ceph or replication). This is non-negotiable. Second, prep your shared storage. For ZFS, you'll set up a storage pool on both servers with identical names, then schedule a sync. Third, create the cluster on the first node with `pvecm`. Then, join the second. Finally, configure HA for your VMs through the web interface. Point it at your shared storage target. Click enable. It feels too easy after all that prep. That's the point.

Testing the "Oh Crap" Moment

If you don't test your HA, you don't have HA. You have hope. And hope is not a strategy. Schedule a maintenance window. Pick a non-critical VM. Then, do the unthinkable. Pull the power on the node it's running on. Or yank the network cable. Watch your dashboard. Your heart will race. After about 30-90 seconds of panic, you should see the VM pop up on the other node. It works. That feeling? That's why you did all this. Now go test a storage failure. Document what happens. Because when it happens for real, you'll know. No sweat.