Simple Linux KVM High Availability without Shared Storage

SafeKit brings high availability to KVM between two servers of any brand.

This article explains how to implement quickly a KVM cluster without shared storage on a SAN and without specific skills.

The principle of the solution is to put a critical application in a virtual machine under KVM. SafeKit implements real-time replication and automatic failover of the virtual machine.

Note that KVM is the free hypervisor included in all Linux versions.

Several applications can be put in several virtual machines replicated and restarted by SafeKit. You have the possibility to migrate each virtual machine between both servers with the SafeKit console and thus balance the load in an active-active cluster.

Should I choose high availability at the application level or the virtual machine (VM) level?

With SafeKit, you have the flexibility to choose the redundancy model that fits your needs.

VM-level redundancy (for KVM or Hyper-V) is the simplest to implement as it replicates the entire virtual machine, requiring no knowledge of the internal application.

Alternatively, application-level redundancy is more granular; it only replicates specific data folders and restarts the application services rather than the entire OS.

While VM-level HA is easier to set up, application-level HA is hypervisor-agnostic and can run across physical, virtual, or cloud environments.

What are the distinctive advantages of SafeKit for KVM high availability compared to competitors?

SafeKit differentiates itself from traditional KVM clustering solutions through its shared-nothing architecture and simplified management. While most competitors require complex distributed file systems (like Ceph) or a central SAN to manage VM failover, SafeKit provides:

• Integrated Real-Time Replication: Data synchronization is built directly into the solution, ensuring that KVM virtual machines are mirrored synchronously without the overhead of managing a separate storage layer.
• Simplified 2-Node Clustering: Unlike enterprise stacks that recommend a 3-node "witness" quorum, SafeKit delivers full high availability with just two redundant servers. Learn more about our heartbeat and quorum mechanism.
• Unified Management: Administrators can manage VM failover, replication, and load balancing through a single SafeKit console , making it accessible to teams without specialized clustering expertise.
• Custom Checkers: SafeKit goes beyond hardware monitoring; it utilizes custom checkers to detect if a VM has crashed, automatically triggering a local restart or a failover to the redundant node. The system is also highly extensible, allowing for the easy integration of new, user-defined custom checkers tailored to your specific environment.

How does SafeKit reduce the TCO (Total Cost of Ownership) compared to VMware-type solutions?

Unlike most high-availability solutions on the market, SafeKit is designed to operate with the absolute minimum hardware overhead, without compromising security or reliability. Key savings compared to VMware or complex open-source alternatives include:

• True 2-Node Efficiency: While most enterprise stacks or open-source solutions require a 3-node "witness" quorum to prevent split-brain, SafeKit delivers full high availability with just two redundant servers.
• Zero Storage Costs: SafeKit uses a shared-nothing architecture that works with local disks, removing the need for expensive SAN or vSAN hardware and specialized storage networking.
• No Forced Subscriptions: Unlike modern subscription-only models, SafeKit offers a perpetual license. You own your software, avoiding the "subscription trap" and unpredictable annual price hikes.
• Low Operational Expense (OPEX): As a plug-and-play solution, it requires no specialized training or expensive external consultancy for maintenance, unlike complex open-source clustering tools.
• CPU-Independent Pricing: Licensing is independent of the number of CPUs or cores. With just two licenses for two nodes, you can protect multiple KVM virtual machines.

Server 1 (PRIM) runs the VM (virtual machine). SafeKit replicates in real time the VM files (virtual hard disk, VM configuration). Only changes made in the files are replicated across the network.

The replication is synchronous with no data loss on failure contrary to asynchronous replication.

You just have to configure the VM directory name in SafeKit. There are no pre-requisites on disk organization. The directory may be located in the system disk.

When Server 1 fails, Server 2 takes over. SafeKit restarts the VM on Server 2. KVM finds the files replicated by SafeKit uptodate on Server 2.
The VM continues to run on Server 2 by locally modifying its files that are no longer replicated to Server 1.

The failover time is equal to the fault-detection time (set to 30 seconds by default) plus the VM reboot time.

Failback involves restarting Server 1 after fixing the problem that caused it to fail. SafeKit automatically resynchronizes the VM files.

Failback takes place without disturbing the VM, which can continue running on Server 2.

After reintegration, the VM files are once again in mirror mode, as in step 1. The system is back in high-availability mode, with the VM running on Server 2 and SafeKit replicating file updates to Server 1.

If the administrator wishes the VM to run on Server 1, this can be done manually through the web console at an appropriate time, or automatically through configuration.

The SafeKit web console provides an intuitive interface to configure high availability of your critical applications. In just a few steps, you can configure a SafeKit KVM cluster to ensure business continuity:

• Put in VM_PATH, the root path of the replicated directory (/var/lib/libvirt/images) where the KVM VM files reside.
• Enter in VM_NAME, the name of the virtual machine (vm1).

The SafeKit cluster includes a dedicated split-brain checker to resolve network isolation issues without the need for a third witness machine or an additional heartbeat network.

The SafeKit management console offers a unified view of your high availability infrastructure. It allows administrators to monitor the operational state of the cluster and track data synchronization in real-time.

For a 2-node KVM cluster, the console clearly displays the roles of each server:

• PRIM (Primary): The active node currently running the application and managing the Virtual IP. It performs writes to the local storage and real-time replication to the secondary node.
• SECOND (Secondary): The standby node receiving synchronous byte-level updates. It is ready to take over instantly if the Primary fails.
• ALONE State: Visually alerts you when the cluster is running on a single node (e.g., during maintenance or after a failure), indicating that redundancy is temporarily lost.
• Resynchronization Progress: When a failed node recovers, its status turns orange during background data reintegration, ensuring no downtime during the "return to normal" phase.

Beyond simple status icons, the interface provides one-click failover orchestration, allowing you to manually reassign the primary role for planned maintenance while ensuring continuous availability for user activity.

Note that if you deploy several VMs for replication and failover, you will have multiple PRIM/SECOND widgets. This allows independent failover for each VM and the ability to distribute the load across servers.