SafeKit: All-in-One SANless High Availability & Application Clustering Software

SafeKit provides the following features for Windows and Linux in a single software product:

• Load balancing
• Synchronous real-time file replication
• Automatic application failover
• Automatic failback after a server failure

No. SafeKit is simple to deploy—no advanced expertise required.

No. SafeKit runs on your existing servers, virtual machines, or in the cloud—no shared disks or SAN storage needed.

No. SafeKit works with standard Windows and Linux editions and does not need enterprise database licenses.

SafeKit solves:

• Hardware failures (20% of problems), including the complete failure of a computer room
• Software failures (40% of problems), including restart of critical processes
• Human errors (40% of problems) thanks to its ease of use

You can implement real-time replication and failover for:

• All types of applications, file directories, and services
• Databases
• Complete Hyper-V or KVM virtual machines
• Docker, Podman, and cloud applications

SafeKit eliminates the following requirements:

• Network load balancers or dedicated proxy servers
• Shared disks or replicated SAN storage
• Enterprise editions of operating systems and databases
• Specialized cluster maintenance skills

No. Data replication is simply the act of copying data from Server A to Server B. While critical, replication by itself does not provide availability. Without the other components of an HA stack, replication is just a "passive copy" that requires manual, time-consuming intervention to become useful:

• If Server A crashes, data replication software will not automatically point your users to Server B.
• It will not detect that the application has stopped.
• It will not restart the services.

Many vendors require you to "bolt together" several different products to achieve host-based replication, failover, and load balancing. This fragmented architecture is a dangerous strategy for mission-critical systems:

• Fragile Integration: When you use product A for replication and product B for clustering, you create a "house of cards." Every OS update or security patch risks breaking the fragile communication link between these separate engines.
• High Cognitive Load & Human Error: Managing multiple interfaces increases the risk of mistakes. During a high-pressure system failure, jumping between different GUIs or using different CLI syntaxes to diagnose a problem leads to confusion and extended downtime.
• Vendor Finger-Pointing: If a failover fails, the replication vendor may blame the clustering tool, leaving you stuck in the middle with no clear path to resolution. An all-in-one solution provides a single point of accountability.
• Complex Maintenance: Fragmented systems require specialized skills for each separate component, making the solution harder to maintain and significantly more expensive over time.

To automate recovery and eliminate downtime, an all-in-one product must manage several technical moving parts simultaneously:

• Host-Based Replication: real-time, synchronous replication of critical application data between servers without relying on shared storage (SAN). This ensures zero data loss (RPO=0) and eliminates expensive hardware dependencies.
• Virtual IP Address (VIP): This provides a single entry point for users. When a failure occurs, the software moves the VIP from the failed node to the healthy one, so users don't have to change their configuration.
• Hardware and Software Error Detectors: The system must constantly "heartbeat" both the physical server and the specific software processes to identify a hang or a crash immediately.
• Customizable Restart Scripts: Not every application starts the same way. An all-in-one tool allows for custom scripts to ensure complex services start in the correct order.
• Automatic Failover: The intelligence to orchestrate the entire move from one server to another without human input.

If your failover manager and your data replication are two different products, they may not be "in sync."

The Danger: If a failover occurs but the replication hasn't finished sending the latest bits, Server B will start the application with outdated or corrupted data.

An all-in-one SANless HA solution ensures that the failover mechanism is aware of the replication state. It will only allow the application to start on the backup node if the data is guaranteed to be up-to-date, preventing conflicting active nodes and data loss.

Often ignored in technical guides and poorly executed by traditional HA solutions, automatic failback remains the most critical requirement for true resilience. A true all-in-one product handles the "Return to Normal" as elegantly as the failure. When the failed server comes back online, it is behind in data. The HA software must:

1. Resynchronize data in the background from the active node to the recovered node.
2. Maintain Uptime: This resynchronization must happen without interrupting the application currently running on the active node.
3. Restore Redundancy: Once the data is mirrored again, the cluster automatically returns to a protected state, ready for the next event.

The technical method used for host-based replication significantly impacts how much you have to change your existing application setup.

• The Challenge of Block-Level Replication: Most SANless solutions replicate at the disk/block level. This is not transparent for the application. It requires you to reconfigure the application entirely to move its data onto a specific, newly created "replicated disk" volume. This often involves complex migration and potential changes to application logic.
• The SafeKit File-Level Advantage: SafeKit performs host-based replication at the file level, which is completely transparent for the application. You do not need to move data to a special disk; you simply configure SafeKit to replicate the existing application folders. These folders can even remain on the system disk, allowing you to protect an application exactly where it is already installed.

Resynchronization time after a failure (step 3)

• 1 Gb/s network ≈ 3 Hours for 1 Tera-bytes.
• 10 Gb/s network ≈ 1 Hour for 1 Tera-bytes or less depending on disk write performances.

Alternative

• For a large volume of data, use external shared storage.
• More expensive, more complex.

• Resynchronization time performance after a failure (step 3).
• Time to check each file between both nodes.

Alternative

• Put the many files to replicate in a virtual hard disk / virtual machine.
• Only the files representing the virtual hard disk / virtual machine will be replicated and resynchronized in this case.

• Each VM runs in an independent mirror module.
• Maximum of 32 mirror modules running on the same cluster.

Alternative

• Use an external shared storage and another VM clustering solution.
• More expensive, more complex.

• Automatic failover of the virtual IP address with 2 nodes in the same subnet.
• Good bandwidth for resynchronization (step 3) and good latency for synchronous replication (typically a round-trip of less than 2ms).

Alternative

• Use a load balancer for the virtual IP address if the 2 nodes are in 2 subnets (supported by SafeKit, especially in the cloud).
• Use backup solutions with asynchronous replication for high latency network.

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

• Application Failover (Macros Tab): Define the specific application services to be automatically restarted in the event of a failure.
• Heartbeat network(s): Dedicated communication path(s) used by cluster nodes to continuously monitor each other's health and availability and synchronize failover decisions.
• Virtual IP Management: Set up the Virtual IP (VIP) for transparent client reconnection after a failover.
• Real-Time Replication: Select the critical directories for host-based, synchronous byte-level replication.
• Checkers: Monitor the application's health and trigger automatic recovery if a process failure is detected.

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. Learn more about heartbeat, failover and quorum in a cluster.

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 mirror 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.

The SafeKit cluster in farm mode is designed for high availability and scalability of services. The configuration focuses on distributing incoming traffic across both nodes simultaneously:

• Load Balanced Services (Macros tab): Define the specific application services (e.g., Apache, IIS, Nginx) to be kept active on all nodes.
• Heartbeat network(s): Communication path(s) used to detect if a node has left the farm, triggering an immediate redistribution of the load.
• Virtual IP (Farm VIP): Unlike a mirror cluster, the Farm VIP is shared between nodes using kernel filtering algorithm to distribute network traffic.
• Load Balancing Rules: Define the traffic distribution policy based on the source IP address or port.
• Checkers: Monitor the application's health and trigger automatic restart if a process failure is detected.

Monitoring a cluster in farm mode provides visibility into the Active-Active nature of the infrastructure, where all nodes contribute to the application's performance (showing 2 nodes in this example):

• UP State (50% on 2 nodes): In a healthy farm, both nodes are in the "UP" (50%) state, meaning they are both actively receiving and processing client requests via the shared Virtual IP.
• Automatic Re-balancing: If one node fails, the console visually shows the remaining node taking 100% of the traffic. There is no "failover" delay, as the surviving node is already active (aside from a detection time of a few seconds).
• Node Insertion: When a repaired node is restarted, it transitions from "STOP" to "UP" and automatically starts receiving its portion of the load without administrator intervention.
• No Data Sync: Note that in a farm-mode cluster, there is no "Orange" resynchronization state, as nodes are expected to be stateless or share a backend database (which can be protected separately in a mirror cluster).

Beyond simple status icons, the interface provides one-click node management, allowing you to manually stop or start a node for planned maintenance while the shared Virtual IP automatically redistributes traffic without interrupting user activity.