Planned Failover Reducing RTO to 15 Seconds
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current data backup and recovery systems face challenges in achieving low Recovery Time Objective (RTO) during planned failover scenarios due to long VM boot times and the need to constantly run and monitor replica VMs, which increases overhead and downtime.
Innovation Solution
The solution involves delaying the stoppage and network disconnection of the source VM until slow recovery operations are completed, allowing IOs to continue and replicate to the replica VM, and booting the replica OS disk before disconnecting the source VM from the network, thereby minimizing downtime and RTO.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of time
If the replica VM is constantly run and monitored to reduce RTO, then the recovery time is improved, but the CPU overhead and operational complexity increase
Solution Approach 1:
The system performs preliminary actions by pre-configuring the replica VM with all necessary OS and application components in a suspended state. The replica VM is prepared in advance but not fully activated, allowing rapid deployment when failover is needed without requiring continuous monitoring or full resource allocation.
Solution Approach 2:
The patent extracts the OS and application loading steps from the failover process by pre-loading them into the replica VM's memory in a suspended state. This separation allows the replica to be ready for immediate activation without requiring continuous CPU execution or monitoring of full application stacks.
2Loss of time
If the replica VM is constantly run to eliminate OS and app load times, then the RTO is reduced, but the CPU overhead increases
Solution Approach 1:
The system uses a suspended replica VM instance that can be rapidly instantiated and discarded. Instead of maintaining a continuously running expensive VM, the system prepares a lightweight suspended image that can be quickly activated only when needed, reducing ongoing CPU overhead while maintaining rapid recovery capability.
Solution Approach 2:
The replica VM is pre-configured and staged in a suspended state with all necessary OS and application components loaded into memory, but not executed. This preliminary preparation eliminates load times during failover without requiring continuous CPU execution, as the pre-loaded state can be rapidly activated when needed.
3Stability of the object's composition
If traditional failover procedures are used with sequential operations, then system stability is maintained, but the downtime increases
Solution Approach 1:
The patent performs several actions in advance: the replica VM is pre-configured with OS and applications, data replication is ongoing before failover, and the replica is staged in a suspended state. When failover is triggered, these preliminary actions allow the system to switch rapidly without executing sequential boot and load procedures, reducing downtime while maintaining stability through controlled activation.
Solution Approach 2:
The failover process is segmented into distinct phases: data replication (ongoing), VM preparation (pre-configured suspended state), and activation (rapid switch). This segmentation allows different components to be prepared independently and activated in an optimized sequence, reducing overall downtime while maintaining system stability through controlled transitions.
Data Source
AI summary
One example method includes performing, as part a planned failover procedure, operations that include connecting a replica OS disk to a replica VM, powering up the replica VM, booting an OS of the replica VM, disconnecting a source VM from a network, and connecting replica data disks to the replica VM. IOs issued by an application at the source VM continue to be processed by the source VM while the replica OS disk is connected, the replica VM is powered up, and the OS of the replica VM is booted.