Disaster recovery switchover rehearsal method and device, computer device and storage medium

Abstract

The application discloses a disaster recovery switching rehearsal method and device, computer equipment and a storage medium. The method comprises the following steps: adding asset information, configuring switching scripts on each asset, establishing a disaster recovery pair and arranging a switching link; calling an SDK script to perform asset inspection, feeding back error information if any inspection fails, and prompting that the pre-switching inspection is completed after the inspection is completed; in the actual switching process, a master-back script and a back-master script of the disaster recovery pair are executed in sequence by an SDK script executor, wherein, when the script execution fails or the echo does not meet the expectation, the switching task is automatically paused and the user is prompted to handle the corresponding asset; after the link switching is completed, the switching post-inspection API interface is called by the SDK script executor to execute the inspection script, the feedback result is fed back to the user interface, and when all the inspections are successful, the switching post-inspection is prompted to be completed, and business verification is performed. By implementing the method of the application, the production and disaster recovery business system can be quickly switched during the disaster recovery switching.

Description

Technical Field

[0001] This invention relates to a disaster recovery control and management method, and more specifically to a disaster recovery switchover drill method, apparatus, computer equipment, and storage medium. Background Technology

[0002] Business-level disaster recovery switchover is a critical strategy designed to ensure that IT systems can quickly recover and continue operating in the event of catastrophic events such as natural disasters, equipment failures, or network outages. The core objective of this strategy is to validate the effectiveness of disaster recovery systems and contingency plans, and to enhance the resilience of critical business operations in emergency situations.

[0003] Modern IT environments typically contain multiple types of systems and services, which increases the complexity of disaster recovery switchovers. During the switchover process, it is crucial to ensure data consistency between the source and target systems to avoid data loss or errors. In the event of a disaster, the speed of business recovery is paramount. The switchover process needs to be as rapid as possible to minimize business downtime. After the switchover, business systems must be able to continue operating seamlessly, ensuring an unaffected user experience and service.

[0004] In the specific operation of disaster recovery switchover, enterprises have a wide variety of IT assets, including servers, network devices, and applications. The switchover operation for each asset may be different. The switchover process requires following multiple operation steps, and the execution of each step is crucial. Environmental differences between different servers may lead to incompatibility issues during the switchover. The switchover operation usually requires entering a series of complex commands, and engineers are prone to human error when entering them one by one. During manual switchover, entering commands one by one is not only time-consuming, but may also prolong the activation time of the disaster recovery business system.

[0005] Therefore, it is necessary to design a new method to ensure that production and disaster recovery business systems can be quickly switched during disaster recovery switching, avoiding various errors caused by misoperation and other factors during manual switching, reducing RTO, minimizing business downtime, and ensuring that RPO meets design requirements to guarantee business continuity. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the prior art and provide an application disaster recovery switching exercise method, apparatus, computer equipment and storage medium.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: applying a disaster recovery switching drill method, including:

[0008] Add asset information, and configure switchover scripts, establish disaster recovery pairs, and orchestrate switchover links on each asset;

[0009] Call the SDK script to perform asset checks. If any check fails, an error message will be returned. After the check is completed, a message will be displayed indicating that the pre-switch check is complete.

[0010] During the actual switchover process, the primary switchover script and the backup switchover primary script of the disaster recovery pair are executed sequentially through the SDK script executor. If the script execution fails or the output does not meet expectations, the switchover task is automatically paused and the user is prompted to handle the corresponding assets.

[0011] After the link switch is completed, the SDK script executor calls the post-switch check API interface to execute the check script, returns the results to the user interface, and prompts that the post-switch check is complete when all checks are successful, so as to perform business verification.

[0012] The further technical solution is as follows: adding asset information and configuring switching scripts, establishing disaster recovery pairs, and orchestrating switching links on each asset includes:

[0013] Add asset information corresponding to various assets included in the business system;

[0014] Configure a script for each asset, wherein the script includes a check script before and after the switchover, a primary switchover script for the backup, and a backup switchover script for the primary;

[0015] Based on the disaster recovery relationship between primary assets and backup assets, establish the corresponding relationship between each asset in the production environment and the disaster recovery environment to obtain disaster recovery pairs.

[0016] The disaster recovery pairs are used to orchestrate and switch links, where each link node is a disaster recovery pair; the connection relationship between the link nodes is the correlation between each disaster recovery pair.

[0017] The further technical solution is as follows: the asset information includes the host's IP address, port number, authentication information, and relevant ports for various services.

[0018] The further technical solution is as follows: the SDK script is called to perform asset checks. If any check fails, an error message is returned. After the check is completed, a message indicating that the pre-switch check is complete is displayed, including:

[0019] At the start of the handover, select the handover link and initiate the handover, obtain the list of disaster recovery pairs and execute the pre-handover check script;

[0020] Call the SDK script executor's pre-switch check API, passing in the primary and backup asset information of the disaster recovery pair and the check script;

[0021] The SDK script executor places the inspection script into the task scheduler and executes the inspection script via remote connection via SSH or WinRM.

[0022] The SDK script executor executes the inspection script to obtain the inspection results for each asset;

[0023] The results of each asset inspection are displayed on the user interface.

[0024] The further technical solution is as follows: During the actual switchover process, the primary switchover script and the backup switchover primary script of the disaster recovery pair are executed sequentially through the SDK script executor. If the script execution fails or the output does not meet expectations, the switchover task is automatically paused and the user is prompted to handle the corresponding assets, including:

[0025] Obtain the list of disaster recovery pairs from the selected switching links;

[0026] According to the disaster recovery pair list, the primary switch-backup script and the backup switch-primary script are executed sequentially, and the link nodes in the switching link are executed serially and in parallel to obtain the execution results;

[0027] The execution result is displayed.

[0028] Its further technical solution is as follows: The primary-to-backup script and the backup-to-primary script are executed sequentially according to the disaster recovery pair list, and each link node in the switching link is executed serially and in parallel to obtain the execution result, including:

[0029] According to the disaster recovery pair list, the SDK script executor puts the primary switchover script into the task scheduler manager, and executes the primary switchover script by remotely connecting to the host of the primary asset via SSH or WinRM.

[0030] After the SDK script executor completes the execution of the primary-to-standby script, it will send the execution results back to the SDK script executor and display the results.

[0031] According to the disaster recovery pair list, the SDK script executor puts the backup switch main script into the task scheduler manager, and executes the backup switch main script by remotely connecting to the host of the backup asset via SSH or WinRM.

[0032] After the SDK script executor completes the execution of the backup main script, it will send the backup main execution result back to the SDK script executor and display the backup main execution result.

[0033] The further technical solution is as follows: After the link switch is completed, the SDK script executor calls the post-switch check API interface to execute the check script, returns the results to the user interface, and prompts that the post-switch check is complete when all checks are successful, and performs business verification, including:

[0034] After all link nodes in the switching link have executed the corresponding switching script, the SDK script executor's post-switching check API interface is called, and the primary / backup asset information and the post-switching check script are passed in;

[0035] The SDK script executor submits the switched inspection script to the task scheduler manager, which executes it remotely via SSH or WinRM and returns the results.

[0036] After all assets have switched over and the check script has been executed, business verification will be performed.

[0037] This invention also provides an application disaster recovery switching drill device, comprising:

[0038] The configuration unit is used to add asset information and configure switchover scripts, establish disaster recovery pairs, and orchestrate switchover links on each asset.

[0039] The pre-switch check unit is used to call the SDK script to perform asset checks. If any check fails, an error message will be returned. After the check is completed, a message will be displayed indicating that the pre-switch check is complete.

[0040] The switching unit is used to execute the primary switching script and the backup switching primary script of the disaster recovery pair sequentially through the SDK script executor during the actual switching process. When the script execution fails or the output does not meet expectations, the switching task is automatically paused and the user is prompted to handle the corresponding assets.

[0041] The post-switch check unit is used to execute the check script by calling the post-switch check API interface through the SDK script executor after the link switch is completed, return the results to the user interface, and prompt that the post-switch check is complete when all checks are successful, so as to perform business verification.

[0042] The present invention also provides a computer device, the computer device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the above-described method.

[0043] The present invention also provides a storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0044] The advantages of this invention compared to existing technologies are as follows: After adding asset information to the system, this invention configures a switching script for each asset, establishes disaster recovery pairs, and orchestrates the switching links. It calls SDK scripts to perform asset checks; if a check fails, an error is reported, and upon completion, a notification indicates that the pre-switch check is complete. During the actual switching process, the SDK script executor sequentially executes the primary-to-standby and standby-to-primary scripts. If a failure occurs, the switching task is automatically paused, and the user is prompted for handling. After the switch is completed, a post-switch check and business verification are performed. Through the automated SDK script executor, it ensures that production and disaster recovery business systems can switch quickly and safely during disaster recovery switching, thereby reducing the risk caused by human error and minimizing recovery time and business interruption. Simultaneously, by designing a disaster recovery process to meet recovery point objectives, it ensures business continuity and reliability.

[0045] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0046] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 A flowchart illustrating the application disaster recovery switching drill method provided in this embodiment of the invention;

[0048] Figure 2 A schematic diagram of a sub-process of the application disaster recovery switching exercise method provided in an embodiment of the present invention;

[0049] Figure 3 A schematic diagram of a sub-process of the application disaster recovery switching exercise method provided in an embodiment of the present invention;

[0050] Figure 4 A schematic diagram of a sub-process of the application disaster recovery switching exercise method provided in an embodiment of the present invention;

[0051] Figure 5 A schematic diagram of a sub-process of the application disaster recovery switching exercise method provided in an embodiment of the present invention;

[0052] Figure 6 A schematic diagram of a disaster recovery pair provided in an embodiment of the present invention;

[0053] Figure 7 A schematic diagram of a switching link provided in an embodiment of the present invention;

[0054] Figure 8 This is a schematic diagram of the link set during loop processing provided in an embodiment of the present invention;

[0055] Figure 9 This is a schematic block diagram of an application disaster recovery switching drill device provided in an embodiment of the present invention;

[0056] Figure 10 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0057] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0058] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0059] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0060] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0061] Please see Figure 1 , Figure 1 This is a flowchart illustrating the application disaster recovery switchover drill method provided in this embodiment of the invention. The method primarily utilizes disaster recovery management software for processing. This software consists of two main parts: a web management service software and an SDK script execution software, also known as an SDK script executor. The web management service software provides the user interface and operational functions, while the SDK script execution software includes a task scheduler, a script executor, and script libraries applicable to mainstream databases, networks, applications, and middleware. The script executor is responsible for transmitting script execution instructions from the disaster recovery management host to the controlled host. Therefore, it is necessary to perform remote login via SSH (for Linux and Unix systems) or WinRM (for Windows systems) on each asset node beforehand to receive instructions from the disaster recovery management end.

[0062] Due to the diversity of host environments and asset types, scripts such as "pre-switchover checks," "primary-to-standby switchover," and "standby-to-primary switchover" for each asset should be permanently stored for future switching. These scripts, due to their specialized nature and high environment dependence, should be managed and maintained by professionals and should not be integrated within the disaster recovery system. The disaster recovery system only needs to support the uploading and addition of external scripts, thereby improving system flexibility and scalability. In the disaster recovery management software, primary and standby assets can be added and configured with scripts such as "pre-switchover checks," "primary-to-standby switchover," and "standby-to-primary switchover." Through a script executor, the system can send script execution commands to the controlled host via SSH remote login (for Linux and Unix) or WinRM remote login (for Windows) without installing an agent program on the controlled host, thus saving resource overhead.

[0063] Figure 1 This is a flowchart illustrating the application disaster recovery switching drill method provided in an embodiment of the present invention. Figure 1 As shown, the method includes the following steps S110 to S140.

[0064] S110. Add asset information, configure switching scripts on each asset, establish disaster recovery pairs, and orchestrate switching links.

[0065] In this embodiment, the asset information includes the host's IP address, port number, authentication information, and relevant ports for various services. The scripts include pre-switch and post-switch check scripts, primary-to-standby switch scripts, and standby-to-primary switch scripts.

[0066] In one embodiment, step S110 described above may include steps S111 to S114.

[0067] S111. Add asset information corresponding to various types of assets included in the business system.

[0068] In this embodiment, the web management service software adds various assets included in the business system, such as databases, applications, network devices, and file storage (NAS). Asset information typically includes the host's IP address, port number (such as SSH or WinRM), authentication information (such as username and password or SSH public key), and relevant ports for various services (such as the ports of databases and middleware).

[0069] Specifically, by centrally adding and managing information on all assets (such as databases, applications, network devices, and file storage) within the business system, comprehensive asset coverage is ensured. This integrated approach enables managers to quickly access relevant information on various assets, improving management efficiency.

[0070] Asset information, including authentication information (such as username, password, and SSH public key), can effectively control access permissions, improve system security, and prevent unauthorized access.

[0071] With complete asset information, in the event of system failure or anomaly, managers can quickly locate the problem and reduce the time required for fault recovery.

[0072] S112. Configure a script for each asset, wherein the script includes a check script before and after the switchover, a primary switchover script, and a backup switchover primary script.

[0073] In this embodiment, effective checks and management are ensured during the switching process.

[0074] By configuring pre-switch and post-switch inspection scripts, primary-to-standby scripts, and standby-to-primary scripts for each asset, automated operation and maintenance of the switchover process can be achieved, reducing errors and delays caused by human operation.

[0075] The pre- and post-switch check scripts ensure that the health status of assets is verified during the switchover process, avoiding business interruptions due to undetected issues.

[0076] The script's flexible configuration allows for adjustments to switching strategies based on different business needs, improving the system's adaptability and flexibility.

[0077] S113. Based on the disaster recovery relationship between the primary asset and the backup asset, establish the corresponding relationship between each asset in the production environment and the disaster recovery environment to obtain the disaster recovery pair.

[0078] In this embodiment, disaster recovery pairs ensure that each pair of assets corresponds one-to-one, facilitating switchover management. The resulting disaster recovery pairs are as follows: Figure 6 As shown.

[0079] Specifically, by establishing a disaster recovery relationship between primary and backup assets, it ensures that each asset has a clear backup, reducing the switching risk caused by asset asymmetry.

[0080] A clearly defined disaster recovery pair allows administrators to easily understand the process during a switchover, improving decision-making efficiency and simplifying operational procedures.

[0081] A clear disaster recovery framework ensures that in the event of a failure, a rapid switch to backup assets can be achieved, enhancing overall disaster recovery capabilities.

[0082] S114. Arrange and switch links according to the disaster recovery pairs, wherein a link node is a disaster recovery pair; the connection relationship of the link nodes is the correlation between each disaster recovery pair.

[0083] In this embodiment, a switchover link is designed on the web management service software according to the actual needs of the business system, where each link node is a disaster recovery pair. Based on the correlation between the disaster recovery pairs, related pairs can be orchestrated sequentially, while unrelated pairs can be orchestrated in parallel. After orchestration, the link is saved and named for future use, such as... Figure 7 As shown.

[0084] Specifically, by orchestrating the switching links, related disaster recovery pairs can be processed sequentially, while unrelated disaster recovery pairs can be processed in parallel, making full use of system resources and improving switching efficiency.

[0085] Proper link orchestration can avoid resource conflicts, ensure a smooth transition of all relevant assets during the switchover process, and reduce system load and latency.

[0086] Saving and naming the switched links will make subsequent management and maintenance more efficient. Furthermore, it allows for easy expansion and modification based on changing business needs.

[0087] S120. Call the SDK script to perform asset checks. If any check fails, an error message will be returned. After the check is completed, a message will be displayed indicating that the pre-switch check is complete.

[0088] In one embodiment, please refer to Figure 2 The above step S120 may include steps S121 to S125.

[0089] S121. At the start of the handover, select the handover link and initiate the handover, obtain the list of disaster recovery pairs and execute the pre-handover check script.

[0090] In this embodiment, the user starts the WEB management service software and selects the link name to be switched in the interface; this operation is usually performed in the daily operation and maintenance window to ensure that the correct business link is selected.

[0091] The graphical interface simplifies user operations and reduces the risk of errors. Clearly selecting the link to switch to facilitates subsequent operations.

[0092] When a user clicks the "Start Switchover" button, the system will automatically retrieve the relevant disaster recovery pair list from the configuration, which includes primary and backup asset information.

[0093] Automated acquisition of disaster recovery information reduces manual intervention and improves efficiency. It ensures that the assets targeted in the failover operation are up-to-date and meet current business needs.

[0094] The SDK script execution software executes pre-written pre-switch check scripts on each host of the disaster recovery pair to check the readiness of each asset. This scripted check ensures that all assets meet requirements before the switchover, reducing the likelihood of post-switch failures. It also improves switchover security by ensuring all conditions are met.

[0095] Throughout the inspection process, users can manually stop the switching operation at any time. This increases user control, allowing them to decide whether to continue the switching based on the actual situation at any time, thus reducing potential risks.

[0096] Depending on the configured option "Whether to perform the actual switch immediately after the switch check":

[0097] If configured as "Yes", the system will automatically switch.

[0098] If configured as "No", user approval is required before the actual switch can be performed.

[0099] If the script check finds errors but the user fixes them, the user can manually approve the switch to continue.

[0100] Flexible configuration options allow users to make decisions based on specific circumstances when switching, increasing operational flexibility. It also improves the system's fault tolerance; even if problems arise during the inspection process, users can still make adjustments according to the actual situation.

[0101] S122. Call the SDK script executor's pre-switch check API, passing in the primary asset information and backup asset information of the disaster recovery pair, as well as the check script.

[0102] In this embodiment, the WEB management service software uses the "Pre-Switchover Check API" interface of the SDK script execution software to pass in the information of the primary and backup assets and the pre-switchover check script.

[0103] Standardized API calls make interactions between systems more efficient and reliable. This increases the automation of pre-switch checks and reduces manual intervention.

[0104] The pre-switch check scripts are written by professionals based on the asset type, such as databases and networks. Database scripts check role matching and data consistency. Network scripts check connectivity and resource status.

[0105] Scripts written by professionals ensure comprehensiveness and accuracy of inspections, reducing potential risks. The inspections of various assets are highly targeted, enabling rapid identification of potential problems.

[0106] S123. The SDK script executor puts the inspection script into the task scheduler and executes the inspection script via SSH or WinRM remote connection.

[0107] S124. The SDK script executor executes the inspection script to obtain the inspection results for each asset;

[0108] S125. Display the results of each asset inspection on the user interface.

[0109] In this embodiment, the SDK script execution software puts the pre-switch check script for each asset into the task scheduler manager, remotely connects to the asset to execute the script, and returns the check results.

[0110] Remote execution reduces the need for direct access to assets and improves security. Results are promptly fed back to users, allowing them to quickly grasp the overall status of the pre-switch check.

[0111] If the pre-switch check script for a particular asset fails to execute, the SDK script execution software will return an error message, but this will not affect the execution of checks for other assets. This ensures the overall switchover process is not disrupted, preventing delays caused by a single asset issue. Timely feedback on problems is provided, helping users quickly locate and resolve issues.

[0112] Once all asset pre-switch check scripts have been executed, the web management service software will notify the user of the check completion status.

[0113] Clearly informing users of the overall results of the checks before the switch facilitates their subsequent decision-making. This enhances users' understanding of the system's operational status and increases operational transparency.

[0114] Through this series of steps, the system automates and ensures the security of the switchover process. Users can not only monitor the status of each asset in real time, but also flexibly respond to various situations during the switchover, thereby reducing risks and improving business continuity.

[0115] S130. During the actual switchover process, the primary switchover script and the backup switchover primary script of the disaster recovery pair are executed sequentially through the SDK script executor. If the script execution fails or the output does not meet expectations, the switchover task is automatically paused and the user is prompted to handle the corresponding assets.

[0116] In one embodiment, please refer to Figure 3 The above-mentioned step S130 may include steps S131 to S133.

[0117] S131. Obtain the list of disaster recovery pairs from the selected switching links.

[0118] In this embodiment, the process of obtaining the disaster recovery pair list from the selected switching links mainly relies on the existing asset management system or service interface.

[0119] Centralized management allows for the rapid acquisition of all disaster recovery pairs requiring failover, ensuring operational accuracy. When obtaining the list of disaster recovery pairs, it ensures that information on both primary and backup assets is included, preventing failover failures due to incomplete information.

[0120] S132. Execute the primary switchover script and the backup switchover primary script in sequence according to the disaster recovery pair list, and execute each link node in the switching link serially and in parallel to obtain the execution result.

[0121] In this embodiment, the execution result refers to the result obtained after switching execution.

[0122] For each disaster recovery pair, the SDK script execution software executes the primary-to-standby script and the standby-to-primary script sequentially. The primary-to-standby script is executed on the primary end, and the standby-to-primary script is executed on the standby end.

[0123] Automated script execution reduces human error and improves switchover efficiency. Combining serial and parallel processing allows for flexible handling based on the actual conditions of each link node, improving overall switchover speed and efficiency. The web management service software uses a cyclic disaster recovery pair list, calling the SDK script execution software's "Switchover API" interface, sequentially passing in primary / standby asset information and the switchover script. Modular design through the API interface facilitates subsequent maintenance and expansion. The API also allows for convenient monitoring of the execution status and progress of each switchover operation. Figure 8 As shown, ordered sets are represented by "[]", and unordered sets are represented by "{}". Ordered sets are executed sequentially, while unordered sets are executed concurrently. The primary switchover script and the backup switchover primary script are written by professionals based on the asset type. These scripts perform corresponding switchover operations, such as SQL statement execution or virtual IP switching. Having scripts written by professionals in the field ensures the accuracy and reliability of the switchover. Specific switchover scripts can be written for different asset types to enhance the system's adaptability.

[0124] In one embodiment, please refer to Figure 4 The above step S132 may include steps S1321 to S1324.

[0125] S1321. Based on the disaster recovery pair list, the SDK script executor puts the primary switchover script into the task scheduler and executes the primary switchover script by remotely connecting to the host of the primary asset via SSH or WinRM.

[0126] In this embodiment, during this step, the SDK script executor places the primary / standby script into the task scheduler manager based on the obtained disaster recovery pair list. This process involves remotely connecting to the host of the primary asset via SSH (Secure Shell) or WinRM (Windows Remote Management) to execute the corresponding primary / standby script.

[0127] Specifically, the disaster recovery pair list contains detailed information on a primary and backup asset pair, ensuring the accuracy of the failover operation. The SDK script executor handles script execution and scheduling, sending failover tasks to the task scheduler. The task scheduler receives script tasks and arranges their execution order, ensuring the operation follows the predetermined process. Remote connection uses SSH or WinRM for remote connection, ensuring no manual intervention is required when executing scripts.

[0128] By automatically adding scripts to the task scheduler, human error is reduced and efficiency is improved; remote execution is supported, making it easy to manage assets in different locations.

[0129] S1322. After the SDK script executor completes the execution of the primary-to-standby script, it will send the execution result back to the SDK script executor and display the execution result.

[0130] In this embodiment, after the primary-to-standby script is executed, the SDK script executor will send the received primary-to-standby execution result back to itself and display the execution result on the user interface.

[0131] Specifically, the SDK script executor receives execution results from the host, including success or failure, execution logs, and error messages. These results are then fed back to the user through the user interface, ensuring the user clearly understands the current operation status.

[0132] Users can quickly learn about the switching status, which helps with subsequent decision-making. Displaying the execution results makes the switching process more transparent, enhancing user trust.

[0133] S1323. Based on the disaster recovery pair list, the SDK script executor puts the backup master script into the task scheduler and executes the backup master script by remotely connecting to the host of the backup asset via SSH or WinRM.

[0134] In this embodiment, after the primary switchover script is executed and the result is returned, the SDK script executor again places the primary switchover script into the task scheduler manager according to the disaster recovery pair list, and executes the primary switchover script by remotely connecting to the host of the backup asset via SSH or WinRM.

[0135] Specifically, the standby switch master script is a script specifically designed to be executed on the standby asset, corresponding to the master switch standby script.

[0136] Scheduler Manager: Receives and schedules the execution tasks of the standby master script, ensuring that the standby master script starts immediately after the master script is completed.

[0137] Remote connection: Similar to step S1321, use SSH or WinRM to remotely connect to the backup asset.

[0138] By sequentially executing primary-to-standby and standby-to-primary switching, the consistency and security of the entire switching process are ensured; similarly, automated management is achieved, reducing manual operations.

[0139] S1324. After the SDK script executor completes the execution of the backup main script, it will send the execution result of the backup main script back to the SDK script executor and display the execution result of the backup main script.

[0140] After the primary switch script is executed, the SDK script executor will send the received primary switch execution result back to itself and display the result on the user interface.

[0141] Specifically, the SDK script executor receives execution results from the standby end, including success or failure, execution logs, and error messages. The user interface then feeds back the standby-to-master switchover results to the user, ensuring that the user can understand the standby end's switchover status in real time.

[0142] Similar to step S1322, the two-way feedback mechanism ensures that users have a full understanding of the handover process. If problems occur, users can obtain information and take action in a timely manner, reducing potential risks.

[0143] S133. Display the execution result.

[0144] The execution results are displayed through a clear user interface, including success and failure information, as well as relevant logs. Users receive complete feedback on the switchover process, which helps assess the overall success rate of the operation. Detailed results provide a basis for subsequent decisions, such as whether recovery operations are needed or disaster recovery strategies need to be adjusted.

[0145] In addition, if the switching script for an asset fails to execute, the SDK script execution software will return a prompt, requiring the user to check and handle the asset, and automatically pause the switching task.

[0146] Timely feedback and automatic pause / switchover can effectively prevent potential system risks. Allowing users to participate in error handling ensures the system operates in a stable state.

[0147] After handling the error, users can choose to end the switchover or skip the error and continue. Users can flexibly choose their actions based on the actual situation, which helps improve system availability and disaster recovery capabilities. This design enhances user control and engagement, and increases operational transparency.

[0148] Through the above steps, the entire disaster recovery switchover process achieves efficient, automated, and secure operation. Each step is designed with risk control and user experience in mind, enabling rapid system recovery in the face of unforeseen circumstances and minimizing the risk of business interruption and data loss. This systematic switchover solution is an indispensable part of modern IT environments, especially in areas with high requirements for business continuity and data security.

[0149] S140. After the link switch is completed, the SDK script executor calls the post-switch check API interface to execute the check script, returns the results to the user interface, and prompts that the post-switch check is complete when all checks are successful, and performs business verification.

[0150] In one embodiment, please refer to Figure 5 The above-mentioned step S140 may include steps S141 to S143.

[0151] S141. After all link nodes in the switching link have executed the corresponding switching script, call the SDK script executor's post-switching check API interface and pass in the primary and backup asset information and the post-switching check script.

[0152] S142. The SDK script executor submits the switched inspection script to the task scheduler manager, executes it remotely via SSH or WinRM, and returns the results after execution.

[0153] S143. After all assets have switched over and the script has finished executing, perform business verification.

[0154] Specifically, after all nodes in the link have completed the switching script, the WEB management service software interface displays the completion status of the link switching and calls the SDK script to execute the software to initiate the post-switching inspection task, concurrently executing the post-switching inspection script on all assets in the link.

[0155] Specifically, the web management service software updates its interface in real time, displaying the status that the link switch has been completed; it calls the SDK script to execute the relevant functions of the software and begins to check all assets after the switch.

[0156] Users can intuitively see the switching status, enhancing the transparency of operations; concurrent execution: concurrent checks on all assets improve efficiency and shorten check time.

[0157] The post-switchover check is performed by the WEB management service software calling the SDK script execution software's "Post-Switchover Check API" interface, passing in the primary and backup asset information of the disaster recovery pair and the post-switchover check script.

[0158] Specifically, the web management service software transmits primary and backup asset information and related scripts to the SDK script execution software via API. This ensures that all necessary information is accurate and facilitates subsequent checks.

[0159] By using API calls, the post-switch inspection process is standardized, reducing human error; centralized management of asset information facilitates subsequent inspections and processing.

[0160] The post-switch check scripts are tailored to the asset type and written by professionals to ensure they are appropriate for the characteristics of different assets. For example, a database post-switch check script might execute SQL statements to check for master-slave role switching.

[0161] Specifically, depending on the asset type, professionals write corresponding post-switch check scripts. For example, for database assets, they check whether the original primary database has become the standby database, and for virtual IP assets, they check whether the primary database has been taken offline and the standby database has been brought online.

[0162] Scripts written by professionals ensure the accuracy and effectiveness of the checks. The checks are tailored to specific asset types, enhancing the targeted nature and effectiveness of the detection.

[0163] The SDK script execution software places the post-switch check script for each asset into the task scheduler manager, which then executes the script by remotely logging into the asset host via SSH or WinRM.

[0164] Specifically, the inspection script is placed in the task scheduler for execution; the inspection script is executed by remotely connecting to the asset host via SSH or WinRM, and the execution results are collected.

[0165] Automatic scheduling and remote execution reduce manual intervention and improve efficiency; after each check script is executed, the SDK script executor returns the results, improving the timeliness of feedback.

[0166] If the script execution fails or returns unexpected results after a switchover of an asset, the SDK script execution software will prompt the user with an error message, but this will not affect the execution of checks on other assets.

[0167] Specifically, the SDK script execution software sends error messages to the web management service software, and users can see relevant prompts; even if individual assets have problems, the checks on other assets will continue to be performed.

[0168] Timely identification of problematic assets facilitates subsequent processing; ensures the smooth progress of the overall inspection process and improves the robustness of the system.

[0169] After all assets have switched over and the script has finished executing, the web management service software will notify the user that the switchover check is complete.

[0170] Specifically, the system automatically summarizes the inspection results of all assets; a prompt pops up on the web management service software to inform the user that the inspection is complete.

[0171] Users don't need to check the status of each asset individually; the system automatically aggregates and provides feedback. Users can confirm the completion of the entire switchover process through prompts, enhancing their trust in the system.

[0172] Finally, conduct business validation to ensure all services and applications are functioning correctly.

[0173] Specifically, perform necessary functional and performance verifications on business applications to ensure the stability and availability of the system after the switch. Record the results of the business verifications to provide a basis for subsequent optimization and adjustments.

[0174] Business verification ensures that all switched services and applications can be used normally; potential problems are identified in a timely manner, reducing business operation risks and enhancing the overall system reliability.

[0175] The above steps constitute a comprehensive and systematic post-switchover inspection process. Clear steps, professional scripting, and automated execution ensure the efficiency and accuracy of the switchover process. Simultaneously, users receive real-time feedback, enhancing transparency and trust. The design of each step guarantees the final availability of business operations and the stability of the system, reducing potential risks.

[0176] The aforementioned disaster recovery switchover drill method involves adding asset information to the system, configuring a switchover script for each asset, establishing disaster recovery pairs, and orchestrating the switchover chain. The SDK script is called to perform asset checks; if any checks fail, an error is reported, and upon completion, a message indicates that the pre-switch checks are complete. During the actual switchover, the SDK script executor sequentially executes the primary-to-standby and standby-to-primary scripts. If a failure occurs, the switchover task is automatically paused, and the user is prompted for further action. After the switchover is complete, post-switch checks and business verification are performed. This automated SDK script executor ensures that production and disaster recovery business systems can switch quickly and safely during the disaster recovery switchover, thereby reducing the risk of human error and minimizing recovery time (RTO) and business interruption. Simultaneously, the disaster recovery process is designed to meet recovery point objectives (RPO), ensuring business continuity and reliability.

[0177] Figure 9 This is a schematic block diagram of an application disaster recovery switching drill device 300 provided in an embodiment of the present invention. Figure 9As shown, corresponding to the above application disaster recovery switchover drill method, the present invention also provides an application disaster recovery switchover drill device 300. This application disaster recovery switchover drill device 300 includes a unit for executing the above application disaster recovery switchover drill method, and the device can be configured in a server. Specifically, please refer to... Figure 9 The application disaster recovery switching drill device 300 includes a configuration unit 301, a pre-switching inspection unit 302, a switching unit 303, and a post-switching inspection unit 304.

[0178] Configuration unit 301 is used to add asset information and configure switching scripts, establish disaster recovery pairs, and orchestrate switching links on each asset; pre-switching check unit 302 is used to call SDK scripts to perform asset checks. If any check fails, an error message is returned, and a message indicating that the pre-switching check is complete is displayed after the check is completed; switching unit 303 is used to execute the primary-to-standby script and the standby-to-primary script of the disaster recovery pair sequentially through the SDK script executor during the actual switching process. If the script execution fails or the feedback does not meet expectations, the switching task is automatically paused and the user is prompted to handle the corresponding asset; post-switching check unit 304 is used to call the post-switching check API interface to execute the check script after the link switching is completed through the SDK script executor, return the results to the user interface, and indicate that the post-switching check is complete when all checks are successful, and perform business verification.

[0179] In one embodiment, the configuration unit 301 includes:

[0180] The system includes several sub-units: an addition sub-unit for adding asset information corresponding to various assets included in the business system; a script configuration sub-unit for configuring scripts for each asset, including pre-switch and post-switch check scripts, primary-to-standby scripts, and standby-to-primary scripts; a disaster recovery pair setup sub-unit for establishing the correspondence between various assets in the production and disaster recovery environments based on the disaster recovery relationship between the primary and standby assets, thus obtaining disaster recovery pairs; and a link orchestration sub-unit for orchestrating switching links based on the disaster recovery pairs, where each link node is a disaster recovery pair; and the connection relationship between link nodes is the correlation between each disaster recovery pair.

[0181] In one embodiment, the pre-switching check unit 302 includes:

[0182] The selection subunit is used to select the switching link and initiate the switching at the start of the switchover, obtain the list of disaster recovery pairs, and execute the pre-switchover check script. The first input subunit is used to call the pre-switchover check API of the SDK script executor, passing in the primary and backup asset information of the disaster recovery pair and the check script. The first connection subunit is used for the SDK script executor to put the check script into the task scheduler manager and execute the check script remotely via SSH or WinRM. The first execution subunit is used for the SDK script executor to execute the check script to obtain the check results for each asset. The first display subunit is used to display the check results for each asset on the user interface.

[0183] In one embodiment, the switching unit 303 includes:

[0184] The first subunit is a list retrieval subunit, used to retrieve a list of disaster recovery pairs from the selected switching links; the second execution subunit is used to execute the primary switching standby script and the standby switching primary script sequentially according to the list of disaster recovery pairs, and to execute each link node in the switching links serially and in parallel to obtain the execution results; the second display subunit is used to display the execution results.

[0185] In one embodiment, the second execution subunit includes:

[0186] The first insertion module is used to insert the primary / standby script into the task scheduler based on the disaster recovery pair list using the SDK script executor, and execute the primary / standby script by remotely connecting to the host of the primary asset via SSH or WinRM. The first switching module is used to return the execution result of the primary / standby script to the SDK script executor after it has completed execution, and to display the execution result. The second insertion module is used to insert the standby / primary script into the task scheduler based on the disaster recovery pair list using the SDK script executor, and execute the standby / primary script by remotely connecting to the host of the standby asset via SSH or WinRM. The second switching module is used to return the execution result of the standby / primary script to the SDK script executor after it has completed execution, and to display the execution result.

[0187] In one embodiment, the post-switch inspection unit 304 includes

[0188] The second input subunit is used to call the SDK script executor's post-switch check API interface after all link nodes in the switching link have executed their corresponding switching scripts, and to input the primary / backup asset information and the post-switch check script. The third execution subunit is used by the SDK script executor to submit the post-switch check script to the task scheduler manager for remote execution via SSH or WinRM, and to provide feedback on the execution results; the verification subunit is used to perform business verification after all asset post-switch check scripts have been executed.

[0189] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned application disaster recovery switching drill device 300 and each unit can be referred to the corresponding description in the foregoing method embodiments. For the sake of convenience and brevity, it will not be repeated here.

[0190] The aforementioned disaster recovery switching drill device 300 can be implemented as a computer program, which can be used in situations such as... Figure 10 It runs on the computer device shown.

[0191] Please see Figure 10 , Figure 10 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 may be a terminal.

[0192] See Figure 10 The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0193] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions that, when executed, cause the processor 502 to perform an application disaster recovery switchover exercise method.

[0194] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0195] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute an application disaster recovery switching exercise method.

[0196] This network interface 505 is used for network communication with other devices. Those skilled in the art will understand that... Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0197] The processor 502 is used to run a computer program 5032 stored in the memory to perform the following steps:

[0198] Add asset information and configure switchover scripts, establish disaster recovery pairs, and orchestrate switchover links for each asset; call the SDK script to perform asset checks, and if any check fails, return an error message; after the check is completed, indicate that the pre-switch check is complete; during the actual switchover process, the SDK script executor executes the primary switchover backup script and the backup switchover primary script of the disaster recovery pair in sequence. If the script execution fails or the output does not meet expectations, the switchover task is automatically paused and the user is prompted to handle the corresponding asset; after the link switchover is completed, the SDK script executor calls the post-switchover check API interface to execute the check script, returns the results to the user interface, and indicates that the post-switchover check is complete when all checks are successful, thus performing business verification.

[0199] In one embodiment, when implementing the steps of adding asset information and configuring switchover scripts, establishing disaster recovery pairs, and orchestrating switchover links on each asset, the processor 502 specifically implements the following steps:

[0200] Add asset information corresponding to various assets included in the business system; configure scripts for each asset, wherein the scripts include pre-switch and post-switch check scripts, primary-to-standby switch scripts, and standby-to-primary switch scripts; establish the correspondence between each asset in the production environment and the disaster recovery environment based on the disaster recovery relationship between the primary asset and the standby asset to obtain disaster recovery pairs; orchestrate switchover links according to the disaster recovery pairs, wherein a link node is a disaster recovery pair; the connection relationship between link nodes is the correlation between each disaster recovery pair.

[0201] The asset information includes the host's IP address, port number, authentication information, and relevant ports for various services.

[0202] In one embodiment, when the processor 502 implements the step of calling the SDK script to perform asset checks, and if any check fails, it returns an error message and prompts that the pre-switch check is complete after the check is finished, the specific implementation steps are as follows:

[0203] At the start of the switchover, select the switchover link and initiate the switchover, obtain the list of disaster recovery pairs and execute the pre-switchover check script; call the pre-switchover check API of the SDK script executor, and pass in the primary asset information and backup asset information of the disaster recovery pair and the check script; the SDK script executor puts the check script into the task scheduler manager and executes the check script remotely via SSH or WinRM; the SDK script executor executes the check script to obtain the check results for each asset; and displays the check results for each asset on the user interface.

[0204] In one embodiment, during the actual handover process, the processor 502 sequentially executes the primary handover script and the backup handover script of the disaster recovery pair through the SDK script executor. Specifically, when the script execution fails or the output does not meet expectations, the handover task is automatically paused and the user is prompted to handle the corresponding asset steps. The specific implementation steps are as follows:

[0205] Obtain a list of disaster recovery pairs from the selected switching links; execute the primary switching standby script and the standby switching primary script in sequence according to the list of disaster recovery pairs, and execute each link node in the switching links serially and in parallel to obtain the execution results; display the execution results.

[0206] In one embodiment, when the processor 502 executes the primary-to-standby script and the standby-to-primary script sequentially according to the disaster recovery pair list, and executes each link node in the switching link serially and in parallel to obtain the execution result, the processor 502 specifically implements the following steps:

[0207] Based on the disaster recovery pair list, the SDK script executor places the primary / standby script into the task scheduler and executes it via SSH or WinRM remote connection to the host of the primary asset. After the SDK script executor completes the execution of the primary / standby script, the execution result is returned to the SDK script executor and displayed. Based on the disaster recovery pair list, the SDK script executor places the standby / primary script into the task scheduler and executes it via SSH or WinRM remote connection to the host of the standby asset. After the SDK script executor completes the execution of the standby / primary script, the execution result is returned to the SDK script executor and displayed.

[0208] In one embodiment, when the processor 502 executes the check script by calling the post-switch check API interface through the SDK script executor after the link switch is completed, returns the results to the user interface, and prompts that the post-switch check is complete when all checks are successful, and then proceeds to the service verification step, the specific implementation steps are as follows:

[0209] Once all link nodes in the switching process have executed their corresponding switching scripts, the SDK script executor's post-switching check API interface is invoked, and the primary / backup asset information and the post-switching check script are passed in. The SDK script executor then submits the post-switching check script to the task scheduler, which executes it remotely via SSH or WinRM and provides feedback on the execution results. After all asset post-switching check scripts have been executed, business verification is performed.

[0210] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0211] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0212] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein when executed by a processor, the computer program causes the processor to perform the following steps:

[0213] Add asset information and configure switchover scripts, establish disaster recovery pairs, and orchestrate switchover links for each asset; call the SDK script to perform asset checks, and if any check fails, return an error message; after the check is completed, indicate that the pre-switch check is complete; during the actual switchover process, the SDK script executor executes the primary switchover backup script and the backup switchover primary script of the disaster recovery pair in sequence. If the script execution fails or the output does not meet expectations, the switchover task is automatically paused and the user is prompted to handle the corresponding asset; after the link switchover is completed, the SDK script executor calls the post-switchover check API interface to execute the check script, returns the results to the user interface, and indicates that the post-switchover check is complete when all checks are successful, thus performing business verification.

[0214] In one embodiment, when the processor executes the computer program to implement the steps of adding asset information, configuring switchover scripts on each asset, establishing disaster recovery pairs, and orchestrating switchover links, it specifically implements the following steps:

[0215] Add asset information corresponding to various assets included in the business system; configure scripts for each asset, wherein the scripts include pre-switch and post-switch check scripts, primary-to-standby switch scripts, and standby-to-primary switch scripts; establish the correspondence between each asset in the production environment and the disaster recovery environment based on the disaster recovery relationship between the primary asset and the standby asset to obtain disaster recovery pairs; orchestrate switchover links according to the disaster recovery pairs, wherein a link node is a disaster recovery pair; the connection relationship between link nodes is the correlation between each disaster recovery pair.

[0216] The asset information includes the host's IP address, port number, authentication information, and relevant ports for various services.

[0217] In one embodiment, when the processor executes the computer program to perform asset checks by calling the SDK script, and if any check fails, it returns an error message. After the checks are completed, it prompts that the pre-switch check is finished. Specifically, the following steps are implemented:

[0218] At the start of the switchover, select the switchover link and initiate the switchover, obtain the list of disaster recovery pairs and execute the pre-switchover check script; call the pre-switchover check API of the SDK script executor, and pass in the primary asset information and backup asset information of the disaster recovery pair and the check script; the SDK script executor puts the check script into the task scheduler manager and executes the check script remotely via SSH or WinRM; the SDK script executor executes the check script to obtain the check results for each asset; and displays the check results for each asset on the user interface.

[0219] In one embodiment, the processor, while executing the computer program, implements the following steps during the actual handover process: sequentially executing the primary handover script and the backup handover script of the disaster recovery pair through the SDK script executor. Specifically, when a script fails to execute or the output does not meet expectations, the handover task is automatically paused and the user is prompted to handle the corresponding asset steps:

[0220] Obtain a list of disaster recovery pairs from the selected switching links; execute the primary switching standby script and the standby switching primary script in sequence according to the list of disaster recovery pairs, and execute each link node in the switching links serially and in parallel to obtain the execution results; display the execution results.

[0221] In one embodiment, when the processor executes the computer program to implement the step of sequentially executing the primary-to-standby script and the standby-to-primary script according to the disaster recovery pair list, and serially and in parallel executing each link node in the switching link to obtain the execution result, the specific implementation is as follows:

[0222] Based on the disaster recovery pair list, the SDK script executor places the primary / standby script into the task scheduler and executes it via SSH or WinRM remote connection to the host of the primary asset. After the SDK script executor completes the execution of the primary / standby script, the execution result is returned to the SDK script executor and displayed. Based on the disaster recovery pair list, the SDK script executor places the standby / primary script into the task scheduler and executes it via SSH or WinRM remote connection to the host of the standby asset. After the SDK script executor completes the execution of the standby / primary script, the execution result is returned to the SDK script executor and displayed.

[0223] In one embodiment, when the processor executes the computer program to implement the step of calling the post-switching check API interface to execute the check script through the SDK script executor after the link switch is completed, feeding back the results to the user interface, and prompting that the post-switching check is complete when all checks are successful, and performing the business verification step, the specific implementation is as follows:

[0224] Once all link nodes in the switching process have executed their corresponding switching scripts, the SDK script executor's post-switching check API interface is invoked, and the primary / backup asset information and the post-switching check script are passed in. The SDK script executor then submits the post-switching check script to the task scheduler, which executes it remotely via SSH or WinRM and provides feedback on the execution results. After all asset post-switching check scripts have been executed, business verification is performed.

[0225] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0226] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0227] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0228] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0229] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0230] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. The method of applying disaster recovery switching drills is characterized by, include: Add asset information, and configure switchover scripts, establish disaster recovery pairs, and orchestrate switchover links on each asset; Call the SDK script to perform asset checks. If any check fails, an error message will be returned. After the check is completed, a message will be displayed indicating that the pre-switch check is complete. During the actual switchover process, the primary switchover script and the backup switchover primary script of the disaster recovery pair are executed sequentially through the SDK script executor. If the script execution fails or the output does not meet expectations, the switchover task is automatically paused and the user is prompted to handle the corresponding assets. After the link switch is completed, the SDK script executor calls the post-switch check API interface to execute the check script, returns the results to the user interface, and prompts that the post-switch check is complete when all checks are successful, so as to perform business verification. The process of adding asset information and configuring switchover scripts, establishing disaster recovery pairs, and orchestrating switchover links on each asset includes: Add asset information corresponding to various assets included in the business system; Configure a script for each asset, wherein the script includes a check script before and after the switchover, a primary switchover script for the backup, and a backup switchover script for the primary; Based on the disaster recovery relationship between primary assets and backup assets, establish the corresponding relationship between each asset in the production environment and the disaster recovery environment to obtain disaster recovery pairs. The disaster recovery pairs are used to orchestrate and switch links, where each link node is a disaster recovery pair; the connection relationship between the link nodes is the correlation between each disaster recovery pair. The asset information includes the host's IP address, port number, authentication information, and the relevant ports for various services; The process of calling the SDK script to perform asset checks will return an error message if any check fails, and will indicate that the pre-switch check is complete upon completion of the checks. This includes: At the start of the handover, select the handover link and initiate the handover, obtain the list of disaster recovery pairs and execute the pre-handover check script; Call the SDK script executor's pre-switch check API, passing in the primary and backup asset information of the disaster recovery pair and the check script; The SDK script executor places the inspection script into the task scheduler and executes the inspection script via remote connection via SSH or WinRM. The SDK script executor executes the inspection script to obtain the inspection results for each asset; Display the results of each asset inspection on the user interface; During the actual switchover process, the SDK script executor sequentially executes the primary switchover script and the backup switchover primary script for the disaster recovery pair. If a script execution fails or the output does not meet expectations, the switchover task is automatically paused, and the user is prompted to handle the relevant assets, including: Obtain the list of disaster recovery pairs from the selected switching links; According to the disaster recovery pair list, the primary switch-backup script and the backup switch-primary script are executed sequentially, and the link nodes in the switching link are executed serially and in parallel to obtain the execution results; The execution result is displayed.

2. The application disaster recovery switching drill method according to claim 1, characterized in that, The process of sequentially executing the primary switchover script and the backup switchover primary script according to the disaster recovery pair list, and executing each link node in the switchover link serially and in parallel to obtain the execution result includes: According to the disaster recovery pair list, the SDK script executor puts the primary switchover script into the task scheduler manager, and executes the primary switchover script by remotely connecting to the host of the primary asset via SSH or WinRM. After the SDK script executor completes the execution of the primary-to-standby script, it will send the execution results back to the SDK script executor and display the results. According to the disaster recovery pair list, the SDK script executor puts the backup switch main script into the task scheduler manager, and executes the backup switch main script by remotely connecting to the host of the backup asset via SSH or WinRM. After the SDK script executor completes the execution of the backup main script, it will send the backup main execution result back to the SDK script executor and display the backup main execution result.

3. The application disaster recovery switching drill method according to claim 1, characterized in that, After the link switchover is completed, the SDK script executor calls the post-switchover check API interface to execute the check script, returns the results to the user interface, and prompts that the post-switchover check is complete when all checks are successful, thus performing business verification, including: After all link nodes in the switching link have executed the corresponding switching script, the SDK script executor's post-switching check API interface is called, and the primary / backup asset information and the post-switching check script are passed in; The SDK script executor submits the switched inspection script to the task scheduler manager, which executes it remotely via SSH or WinRM and returns the results. After all assets have switched over and the check script has been executed, business verification will be performed.

4. The application of a disaster recovery switching drill device is characterized in that, The device uses the application disaster recovery switching drill method as described in claim 1, including: The configuration unit is used to add asset information and configure switchover scripts, establish disaster recovery pairs, and orchestrate switchover links on each asset. The pre-switch check unit is used to call the SDK script to perform asset checks. If any check fails, an error message will be returned. After the check is completed, a message will be displayed indicating that the pre-switch check is complete. The switching unit is used to execute the primary switching script and the backup switching primary script of the disaster recovery pair sequentially through the SDK script executor during the actual switching process. When the script execution fails or the output does not meet expectations, the switching task is automatically paused and the user is prompted to handle the corresponding assets. The post-switch check unit is used to execute the check script by calling the post-switch check API interface through the SDK script executor after the link switch is completed, return the results to the user interface, and prompt that the post-switch check is completed when all checks are successful, so as to perform business verification. After the link switch is completed, the SDK script executor calls the post-switch check API interface to execute the check script, returns the results to the user interface, and prompts that the post-switch check is complete when all checks are successful, so as to perform business verification. The configuration unit includes: The system includes several sub-units: an addition sub-unit for adding asset information corresponding to various assets included in the business system; a script configuration sub-unit for configuring scripts for each asset, including pre-switch and post-switch check scripts, primary-to-standby scripts, and standby-to-primary scripts; a disaster recovery pair setup sub-unit for establishing the correspondence between various assets in the production and disaster recovery environments based on the disaster recovery relationship between the primary and standby assets, thus obtaining disaster recovery pairs; and a link orchestration sub-unit for orchestrating switching links based on the disaster recovery pairs, where each link node is a disaster recovery pair; and the connection relationship between link nodes is the correlation between each disaster recovery pair.

5. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1 to 3.

6. A storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 3.

Images