- High availability in virtualized servers combines clusters, replication, and redundant storage to minimize downtime.
- RHEL, Hyper-V, HA-DAS and NAS solutions like QNAP offer different HA approaches depending on size, budget and needs.
- Replication for DR does not replace a real HA: automatic and almost seamless failover requires near real-time synchronization.
- Properly designing the architecture and respecting hardware, network, and software requirements is key to ensuring continuity of service.
High availability on virtualized servers has become a basic requirement for any organization that cannot afford service outages, even for just a few minutes. We're talking about ensuring that your virtual machines, applications, and data remain accessible even if a physical server, disk, network, or even an entire data center fails. It's not just about having backups, but about keeping the service running no matter what.
When we combine virtualization , clusters, storage, and disaster recovery , many technologies emerge (KVM, Xen, Hyper-V, RHEL HA, RHEV, CSV, NAS, JBOD, replicas, etc.), and it's not always clear which to choose or how to fit it all together. This article provides an in-depth review of the main options and approaches: from traditional clusters with shared storage to modern solutions based on real-time replication between nodes, including specific examples with Red Hat, Microsoft Hyper-V, QNAP, and HA-DAS architectures.
Basic concepts of high availability in virtualized environments
In a virtualized environment, high availability (HA) means that VMs remain accessible even if one or more system components (servers, disks, controllers, network, power supply, etc.) fail. This is not the same as disaster recovery (DR): HA aims for minimal or near-zero downtime, while DR typically accepts some downtime to restore services from a backup.
To achieve this behavior, several components are combined: hardware redundancy, cluster software, fault-tolerant storage , and monitoring and failover mechanisms . The goal is to avoid single points of failure: if one component breaks, another takes over without manual intervention (or with minimal intervention).
In the world of virtualization, this typically translates to having multiple physical hosts that share or replicate storage , and a system that monitors the status of the nodes and VMs. When one host fails, the virtual machines start up on another host, ideally without the user noticing or with a very brief interruption.
It's also important to differentiate between solutions designed for elastic "cloud-like" environments and classic HA platforms. Certain cluster products have a relatively static configuration and a relatively low maximum number of nodes, so they aren't suitable for setting up a massive cloud, although they are excellent for protecting a well-defined set of critical services.
In a cloud or hybrid environment, it is advisable to review specific migration and continuity strategies: for example, cloud migration can be part of the disaster recovery strategy, but it does not replace local HA.
High availability on Red Hat Enterprise Linux and KVM/Xen platforms
The Red Hat ecosystem offers several options for protecting virtual machines using clusters and high-availability add-ons . Versions like Red Hat Enterprise Linux 5 and 6 support various combinations of hypervisors and cluster add-ons.
RHEL 5 supports two virtualization platforms: Xen (from RHEL 5.0 onwards) and KVM (from RHEL 5.4 onwards) . The RHEL 5 Advanced Platform (AP) Cluster add-on allows you to manage both Xen and KVM VMs as cluster resources, so the host's high-availability infrastructure controls the startup, shutdown, and failover of virtual machines between nodes.
With RHEL 6, virtualization support is simplified: only KVM is supported as a hypervisor . However, the RHEL 6 High Availability plugin still allows KVM virtual machines to be treated as cluster resources managed by the host's HA infrastructure. The cluster resource manager (rgmanager in classic versions) is responsible for monitoring the nodes and moving guests between physical servers when a failure is detected.
This approach is often referred to as “ RHEL Cluster/HA running on physical hosts acting as a virtualization platform .” The RHEL cluster itself manages where each VM runs and takes over in the event of a node failure, ensuring that virtual machines configured as critical are restarted on a healthy host.
An interesting aspect is that, from the cluster's perspective, the VM's guest operating system is less important . Any Xen- or KVM-compatible guest operating system in RHEL can be treated as a highly available virtual machine: different versions of RHEL (3, 4, 5, etc.) and various editions of Microsoft Windows, as long as they are supported by the hypervisor. This provides considerable flexibility when securing mixed environments.
However, Red Hat itself recommends caution when choosing between using the RHEL High Availability Add-on or more comprehensive virtualization platforms like Red Hat Enterprise Virtualization (RHEV) to provide high availability for VMs. Both offer high availability functionality, but the use cases are different, and the size of the environment and the operating model must be considered.
When to use RHEL HA versus RHEV for high availability
When deciding whether to use RHEL HA Add-on or a platform like RHEV to protect virtual machines, one of the key criteria is the number of physical hosts and the type of use that will be given to the virtualized environment.
RHEL's high-availability add-on is designed for relatively small, statically configured clusters . Traditionally, these clusters have a maximum limit of about 16 physical nodes, which is sufficient for many corporate environments but doesn't fit well with cloud-like architectures with tens or hundreds of constantly changing hosts.
Therefore, Red Hat's own documentation indicates that using RHEL HA exclusively to build cloud-like infrastructures is not recommended , precisely because of its static nature and the node count limit. For cloud scenarios, it makes more sense to use platforms specifically designed for that model, with more elastic and scalable resource managers.
On the other hand, if the goal is to protect a moderate number of critical VMs on a well-defined set of hosts , RHEL's HA add-on is a robust solution: it integrates well with the operating system, relies on mature clustering technologies, and provides the necessary logic to monitor and move VMs in case of failure.
In any case, it is advisable to review the latest RHEL documentation on supported guest operating systems and hypervisor and cluster combinations , because support evolves with each release and it is important to stick to the official matrices.
High availability in Hyper-V: clusters, replicas, and live migration
In Microsoft environments, high availability is fundamentally based on the capabilities of Hyper-V combined with Windows Server Failover Clustering . The goal is to have consistent access to virtual machines even in the event of hardware failures, network problems, or software errors.
The core component is Hyper-V failover clusters . Such a cluster is a set of servers (nodes) that share storage and work in a coordinated manner: if one node fails, the VMs it was running are automatically restarted on another node in the cluster. This is all supported by shared disk technologies and specific internal communications.
For this to work, nodes typically share storage via a SAN (Storage Area Network) or a scale-out file server (SOFS) . Cluster Shared Volumes (CSVs) are then created on top of this layer , allowing all nodes to simultaneously access the same disks where the virtual machine files reside.
The nodes also communicate via a dedicated network known as the cluster heartbeat . This network is separate from the production data network and allows each server to report that it is alive. If the cluster stops receiving heartbeats from a node, it is considered to have failed, and failover procedures are initiated.
Another fundamental element is the quorum configuration . The quorum defines how many votes (nodes or external witnesses) must be active for the cluster to continue functioning. This prevents "split brain" scenarios, where isolated groups of nodes mistakenly believe they are the main cluster and cause data corruption. Choosing the right quorum model (nodes, disk witness, file share witness, etc.) is key to stability.
Based on this, Hyper-V leverages cluster capabilities to enable live migrations of virtual machines between nodes with minimal downtime . During maintenance or load balancing, a VM can be moved from one host to another without service interruption, transparently transferring memory, state, and active connections.
If, instead of planned maintenance, an actual hardware or software failure occurs on a node, the cluster performs an automatic failover . The virtual machines running there are brought up on another host with access to the same shared storage. The disruption is greater than in a live migration (the VMs need to be powered off and on), but service continuity is maintained with minimal human intervention.
In addition to the classic SAN cluster, Hyper-V incorporates other technologies focused on both high availability and disaster recovery, notably Hyper-V Replica and live migration without shared storage.
Hyper-V Replication is an asynchronous virtual machine replication feature that replicates virtual machines between a primary host and one or more replica hosts, typically located in a different site or data center. Changes are sent to the target VM at regular intervals, creating recovery points that allow the VM to be restored to a recent state if the primary site experiences a disaster.
This mechanism uses a Hyper-V replication agent that coordinates replication traffic, manages recovery points, and centralizes failover operations. It allows for both planned failovers (for example, to move production to another site) and unplanned failovers (when the primary site goes down unexpectedly).
Due to its asynchronous nature, replication is more oriented towards disaster recovery ( DR) than near-zero downtime high availability (HA) . After an incident, a failover must be initiated on the replica VM, and although the process is quite agile, it involves some downtime and the potential loss of the last few seconds or minutes of data, depending on the configured replication interval.
In parallel, Hyper-V offers Shared Nothing live migration , which allows you to move a VM between hosts that don't share storage. In this model, each host has its own local storage, but live migration transparently copies the virtual machine's disks to the destination while the VM remains online, and then switches execution to the new server.
This functionality is especially useful in environments without a SAN or shared storage infrastructure , reducing the upfront cost for SMEs or scenarios where maintaining a dedicated storage network is undesirable. It allows, for example, reorganizing hosts or migrating to new hardware with minimal impact, without needing to shut down existing machines.
The combination of these technologies (failover clusters, CSV, live migration with or without shared storage and Hyper-V replication) provides a wide range of options for designing business continuity and fault tolerance strategies tailored to different budgets and levels of demand.
High availability solutions with HA-DAS and Windows Server
Beyond environments with large SANs, there are architectures designed for high availability in storage systems directly attached to servers (HA-DAS) . These solutions leverage Windows Server (e.g., 2012) and advanced RAID/HBA controllers to deliver high-availability clusters without the need to set up a traditional iSCSI or FC SAN.
This approach uses two HA cluster nodes with shared JBOD storage (just a bunch of disks without any built-in intelligence). The JBOD connects to both servers via redundant Host RAID HBA controllers, so each node sees the same set of disks and can access the same RAID array simultaneously.
These solutions can achieve capacities of up to 180 TB in a shared chassis , working with hot-swap magnetic or SSD drives in different RAID levels. The RAID controllers typically incorporate 1 GB of cache each, with the cache mirrored across controllers to maintain consistency and improve performance, and cache protection based on supercapacitors instead of traditional batteries.
Communication between controllers is typically performed via SAS links , eliminating the need for heartbeat Ethernet links for disk state synchronization. This provides a direct and highly reliable communication path between the two storage nodes.
Another important feature is that these architectures typically operate in active/active mode on the same RAID array . This means both nodes provide service simultaneously and leverage the computing power of both servers, instead of leaving one "on standby" until the other fails. This avoids wasting 50% of the hardware investment that usually occurs in active/passive clusters.
By building on Windows Server 2012 (or later versions), administrators benefit from a familiar management environment: familiar tools, wizards, management console, and permissions model. Learning time is minimized, which also reduces operating costs and risks during implementation.
These HA-DAS solutions are geared towards various uses: Hyper-V server virtualization, Windows VDI, SAN/NAS storage, transactional databases (OLTP) , data warehousing, and high-availability web services . All of this is achieved by leveraging a single shared storage chassis, two redundant nodes, and Windows clustering logic.
High availability specifically for QNAP NAS arrays and Virtualization Station 4
In the NAS sector, manufacturers like QNAP have developed advanced features to achieve high availability for both storage and the virtual machines hosted on their devices . Specifically, they combine the QuTS hero operating system (based on ZFS) with Virtualization Station 4 to offer real-time replication and failover between two NAS devices.
On one hand, the QuTS hero system integrates high availability ( HA) technologies into the NAS itself , allowing two identical (or similar) devices to be configured as a high-availability pair. If one NAS fails, the second takes over, and services remain operational. This protects both the storage and the NAS's core services.
Building on that foundation, the new high availability functionality in Virtualization Station 4 (available in beta in recent versions) takes it a step further: it allows virtual machines running on the NAS to have advanced fault tolerance through real-time replication between two QNAP devices.
This feature is only available on QNAP NAS devices with x86 processors running QuTS hero and the appropriate version of Virtualization Station 4. The use of ZFS and SnapSync technology is essential, as it synchronizes VM data between the two NAS devices in real time, ensuring that the replicated VM is always up to date.
The operating scheme is based on two NAS devices backing each other up : NAS A and NAS B act as backup nodes for each other, bidirectionally. Each can have its own virtual machines, and for those marked as HA-protected, a replica is created on the other NAS. In case of failure of one of the devices, the other takes control and starts the affected VMs.
This enables seamless NAS server switching . High Availability (HA) protection can be activated only for specific critical VMs without affecting other NAS services (e.g., backups, file sharing, etc.). Each NAS can continue to perform its original function while simultaneously protecting the virtual machines designated for high availability.
SnapSync-based real-time synchronization ensures that, in the event of an incident, failover is virtually instantaneous and without data loss . Unlike traditional architectures that rely on a central shared storage area (SAN), this solution eliminates that single point of failure: each NAS maintains a complete and consistent copy of the VMs it protects.
Furthermore, QNAP defines multiple failure conditions that can trigger a failover : prolonged CPU overload (above a certain threshold, for example, 80% for a period of time), excessive system temperature, disk failure even in RAID configurations, loss of one of the redundant power supplies, among others. The system evaluates these conditions and, if the NAS is deemed unreliable, shifts the load to the other node.
The system also offers the option of manual migrations , which are very useful when the technical team wants to migrate virtual machines to another NAS in a controlled manner for maintenance tasks such as replacing disks, updating firmware, changing advanced settings, etc. The migration is very fast (on the order of less than a second), making the process virtually transparent to users.
Another interesting point is that there are no additional licensing costs : the high availability functionality in Virtualization Station 4 is part of the application itself and is included in the system, with no extra payments per node or per VM. This makes it especially attractive for SMEs and environments looking for high availability at a reasonable cost.
Requirements and limitations of high availability in QNAP
To successfully deploy this solution on QNAP, it's essential to meet certain software, hardware, and network requirements . They aren't extremely complex, but it's important to be very clear about them before designing the environment.
Regarding software, QuTS hero version h5.3 or higher and Virtualization Station 4.1 or later are required. Only these versions include SnapSync-based VM HA functionality. This feature is not available on NAS devices with "classic" QTS or earlier versions of Virtualization Station.
At the hardware level, the two NAS devices don't have to be exactly the same model, but they do need to use processors of the same architecture and brand (either both Intel or both AMD) . This simplifies compatibility and ensures that replicated VMs can run smoothly on either device.
Regarding the network, it is essential that both NAS devices are on the same network segment and that there is a direct connection between them using a dedicated physical network cable for virtual machine data synchronization. This dedicated link acts as an "out-of-band" channel for replication, preventing interference with normal user traffic.
In practice, the actual hardware requirement boils down to this: the same CPU family and a direct link between NAS devices . Everything else (disk capacity, RAM, etc.) is scaled based on the number of VMs to be protected and the expected performance. If these conditions are met, QNAP's HA setup is relatively straightforward and very robust.
Difference between high availability and simple replication/DR in VMs
Virtual machine replication solutions as a disaster recovery mechanism are often confused with true high availability with zero downtime (or minimal downtime). Both are important, but they solve different problems.
For example, in VMware vSphere environments, it's common to configure VM replication to a disaster recovery (DR) site , so that the primary server's disk image is copied to the disaster recovery node. This protects against the total loss of the primary site, but when it fails, a manual recovery is usually necessary: powering on the VMs at the DR site, reconfiguring networks, validating data integrity, and so on.
This process, while partially automatable, involves downtime that can range from minutes to hours, depending on the complexity of the environment and internal procedures. It's an excellent DR strategy, but it doesn't meet the near-continuous availability goal expected of a strict HA solution.
True high availability requires an automatic or near-automatic failover mechanism with very low downtime and no need for complex manual operations when a component fails. Furthermore, data synchronization between the active and backup nodes must be tight enough to prevent or minimize the loss of recent information.
Therefore, when designing a highly available VM environment, it's essential to properly combine clustering technologies, near-real-time replication, redundant storage, and proactive monitoring . Only in this way can users continue to access the website, database, or corporate application with minimal interruption, even if an entire server or NAS suddenly shuts down.
In practice, the most common approach is to complement local high availability (for example, a cluster within the same data center) with a disaster recovery strategy at a different site . This way, both everyday failures (disks, servers, power supplies, etc.) and more serious events (fires, prolonged power outages, natural disasters) are covered.
This wide range of solutions—RHEL and Hyper-V clusters, SAN-free HA-DAS architectures, dedicated high availability on QNAP NAS with Virtualization Station, and advanced VM replication—demonstrates that it is now possible to design highly fault-tolerant virtualized environments tailored to different company sizes and budgets . A thorough understanding of the differences between each approach, their limitations (such as the maximum number of nodes or the need for shared storage), and their technical requirements is key to choosing the right combination and keeping critical services running almost seamlessly.
