iServFT
Traditional high-availability technologies require reallocation of resources and service restarts after anomalies occur, which may cause service interruptions and performance degradation. iServFT uses advanced fault-tolerant technology, allowing seamless service transfer immediately when an incident occurs, ensuring continuous operation and uninterrupted service. Through intelligent monitoring and automatic adjustment mechanisms, iServFT not only enhances computational efficiency but also effectively reduces risks, providing enterprises with a more stable, secure, and flexible operation.
# Non Stop
Fault Tolerance Technology
Breakthroughs with iServFT that enhance stability
Traditional high-availability technologies require reallocation of resources and service restarts after anomalies occur
- Connection interruptions and service restarts are risky and time-consuming
- Or services need to be redeveloped to utilize load balancing mechanisms
Main service host
Backup host
Restarting services on the backup host
Fault tolerance technology allows uninterrupted service transfer when an incident occurs
- Through real-time snapshots and replication of the entire VM, processor, memory, hard disk, and network card status can be transferred at any time
Main service host
Backup host
Uninterrupted transfer and continued service
Applicable scenarios
Automated devices or system services requiring higher availability
Services that are difficult to restart and recover for clients
Traditional/special applications with limited development or software update costs
# Non Stop
VM takeover process
System operating normally
The main service host sends device status, memory, and disk incremental backup data, keeping the backup host as a valid copy.
The client only receives a response when the copy is confirmed valid.
Main service host failure
The backup host detects timeout on both lines and cannot get a response from the main service host, immediately preparing to take over the service.
Backup host takes over service operation
The backup host sends an ARP broadcast to redirect network infrastructure client packets and continue providing services.
The backup host has the complete service execution status, so clients only experience slight delays.
# Modern
Redundancy modes for different scenarios
| Fault-Tolerant (FT) | Disaster Recovery (DR) | |
|---|---|---|
| Backup content | Entire VM | Entire VM / Hard disk only |
| No interruption to application (Transparent transfer) | Yes | No (Rollback to the last recovery point) |
| RPO (Recovery Point Objective) | 0 (No data loss) | Seconds to hours (depending on configuration) |
| Automatic fault detection and transfer | Supported | Supported |
Bandwidth per VM (Actual conditions depend on the protected application) | Uncompressed: 3-5 Gbps Compressed enabled: 300 Mbps - 1 Gbps (It is recommended to have a total available bandwidth of at least 10 Gbps to reduce latency) | 50 Mbps - 1 Gbps (Available bandwidth affects RPO achievement rate) |
| Application performance impact | Depends on the application | Almost no impact |
| Reduce traditional redundancy (hard disk data only) | No | Yes, single restore point |
# Modern
Comparison between iServFT and similar products in terms of deployment method and requirements
| iServFT (FT Mode) | VMware Fault Tolerance | Stratus everRun (fault tolerance) | |
|---|---|---|---|
| Deployment method | Standalone installation or Coexist with iServCloud / OpenStack | Requires vCenter | Standalone installation |
Base operating system (Host OS) | Ubuntu 20.04 or other Linux distributions supporting Docker (RHEL, CentOS, Debian) | VMware ESXi | Only CentOS 7 provided by Stratus is supported |
| Host network card and other hardware compatibility | Same as Host OS | Only VMware compatible hardware | Only CentOS 7 compatibility |
| Controller can still control FT after offline | Yes | Can only stop | Yes |
| Recommended bandwidth for FT data transmission | 1 Gbps or higher | 10 Gbps or higher (Fault Tolerance Logging) | 10 Gbps or higher (A-Link) |
| Guest OS restrictions | Common operating systems such as Win Server 2008R2-2022, Windows 11, Linux, FreeBSD, etc. (Supports virtio network drivers) | Common operating systems (Windows 11 requires vSphere 8.0 update 1 license) | Windows 10 / Server 2012-2022 / Linux |
| License restrictions | (Negotiable) | vSphere Standard (2 vCPUs) vSphere Enterprise Plus (8 vCPUs) (per VM; no host maximum) | everRun Enterprise |
# Modern
Comparison between iServFT and similar products in terms of deployment method and requirements
| iServFT (FT Mode) | VMware Fault Tolerance | Stratus everRun (fault tolerance) | |
|---|---|---|---|
Fault tolerance technology foundation (Note 1) | Continuous checkpoints | Continuous checkpoints (vSphere 6.0~8.0), vLockStep (vSphere 4.x) | Continuous checkpoints |
Redundant host synchronization method (Note 2) | Active-Passive | Active-Passive | Active-Passive |
| Virtualization technology | KVM | VMware ESXi | KVM |
| Supports UEFI + TPM | Yes | Yes | No |
Special operating system kernel version restrictions (Note 3) | None | (Custom operating system) | Yes (everRun customized) |
Note 1 :
Continuous checkpoints can be simply understood as taking incremental snapshots of the VM at the millisecond level as the basis for fault tolerance. vLockStep synchronizes the processor instructions on the redundant host, but does not support multi-core systems and is no longer supported by VMware (referred to as Legacy FT in VMware documentation).
Note 2 :
Active-Passive: In this mode, the backup machine is only in a warm-standby state and will not start the VM CPU; Active-Active redundancy involves both the primary and backup hosts running the VM CPU and executing the same VM, using packet comparison and control technology to reduce the required backup data transmission, as seen in products like Huawei FusionSphere / COLO (COarse-grained LOck-stepping Virtual Machines).
Note 3 :
Custom operating system kernels can improve fault tolerance system efficiency but may bind the operating system kernel version, causing delays or difficulty in receiving subsequent security updates and hardware support. It becomes hard to synchronize with upstream distributions (RHEL/Ubuntu/Debian, etc.) and difficult to integrate with other virtualization platforms. iServFT recommends using a generic Linux kernel, version 4.15 or higher, which is supported by most Linux distributions (Ubuntu 18.04/20.04/22.04, RHEL 8/9, Debian 10/11/12).