High Availability Architectures and Best Practices

High Availability Architecture and Best Practices

This article compares high availability architectures and gives best practices: software vs hardware clustering, shared nothing vs shared disk cluster, application vs virtual machine high availability, synchronous vs asynchronous replication, file vs disk replication, quorum, network load balancing.

Comparison table on high availability architectures and best practices

High availability architectures comparison

(click on the feature for more information)

FeatureSafeKit clusterOther clusters
Software clustering vs hardware clustering A software cluster with SafeKit installed on two servers
A simple software cluster with the SafeKit package installed on two servers
Hardware clustering with external shared storage Network load balancers or dedicated proxy servers
Complex hardware clustering with external storage or network load balancers
Shared nothing vs a shared disk cluster SafeKit shared-nothing cluster: easy to deploy even in remote sites
SafeKit is a shared-nothing cluster: easy to deploy even in remote sites
Shared disk cluster: complex to deploy
A shared disk cluster is complex to deploy
Application High Availability vs Full Virtual Machine High Availability
SafeKit application HA supports hardware failure, software failure, human errors with quick recovery time
Virtual machines high availability supports only hardware failure with an unknown recovery time
Full virtual machines HA supports only hardware failure with a VM reboot and an unknown recovery time if the OS reboot does not work
Synchronous replication vs asynchronous replication
SafeKit implements real-time synchronous replication with no data loss in case of failure
Asynchronous replication with data loss on failure
With asynchronous replication, there is data loss on failure
Byte-level file replication vs block-level disk replication SafeKit cluster with byte-level file replication: simply replicates directories even in the system disk
SafeKit implements byte-level file replication and is simply configured with directories to replicate even in the system disk
Cluster with block-level disk replication: complex and require to put application data in a special disk
Block-level disk replication is complex to configure and requires to put application data in a special disk
Heartbeat, failover and quorum to avoid 2 master nodes Simple quorum in a SafeKit cluster with a split brain checker configured on a router
To avoid 2 masters, SafeKit proposes a simple split brain checker configured on a router
Complex quorum in other clusters: third machine, special quorum disk, remote hardware reset
To avoid 2 masters, other clusters require a complex configuration with a third machine, a special quorum disk, a special interconnect
Network load balancing No special network configuration in a SafeKit cluster
No special network configuration is required in a SafeKit cluster for network load balancing
Special network configuration in other clusters
Special network configuration is required in other clusters for network load balancing

FAQ on Evidian SafeKit

Best use cases [+]

Customers [+]

Mirror cluster: demonstration, advantages [+]

Farm cluster: demonstration, advantages [+]

Application high availability modules [+]

Cloud solutions [+]

SafeKit Webinar [+]

Pricing - Free trial [+]


Evidian SafeKit Pricing

White Papers


To receive Evidian news, please fill the following form.