Application disaster recovery switching drilling method and device, computer equipment and storage medium

Abstract

The invention discloses an application disaster recovery switching drilling method and device, computer equipment and a storage medium. The method comprises the following steps: adding asset information, configuring a switching script on each asset, establishing a disaster recovery pair and arranging a switching link; an SDK script is called to execute asset inspection, if any inspection fails, error information is fed back, and after the inspection is completed, it is prompted that the inspection is completed before switching; in the actual switching process, a main-to-standby script and a standby-to-main script of the disaster recovery pair are sequentially executed through an SDK script executor, and when script execution fails or echoing does not conform to expectation, a switching task is automatically paused, and a user is prompted to process corresponding assets; and after the link switching is completed, calling the switched check API interface through the SDK script executor to execute a check script, feeding back a result to the user interface, prompting that the switched check is completed when all checks are successful, and performing service verification. By implementing the method provided by the invention, the production and disaster recovery service systems can be ensured to be quickly switched during the disaster recovery switching period.

Description

Technical Field

[0001] The present invention relates to a disaster recovery control management method, and more specifically to an application disaster recovery switching drill method, device, computer equipment and storage medium. Background Art

[0002] Business-level disaster recovery switching is a key response strategy that aims to ensure that information technology systems can be quickly restored and continue to operate when encountering catastrophic events such as natural disasters, equipment failures, or network outages. The core goal of this strategy is to verify the effectiveness of disaster recovery systems and emergency plans, and to improve the recovery capabilities of key businesses in emergency situations.

[0003] Modern IT environments usually contain multiple types of systems and services, which increases the complexity of disaster recovery switching. During the switching process, data consistency between the source system and the target system must be ensured to avoid data loss or errors. When a disaster occurs, the speed of business recovery is critical. The switching process needs to be as fast as possible to reduce business interruption time. After the switch, the business system must be able to continue to run seamlessly to ensure that user experience and services are not affected.

[0004] In the specific operation of disaster recovery switching, the enterprise's IT assets are of various types, including servers, network equipment, applications, etc. The switching operation of each asset may be different; multiple operation steps need to be followed during the switching process, and the execution of each step is crucial; the environmental differences between different servers may cause incompatibility issues during switching; the switching operation usually requires entering a series of complex commands, and human errors are prone to occur when engineers enter them one by one; during the manual switching process, 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 the production and disaster recovery business systems can be quickly switched during disaster recovery switching, avoid various errors caused by factors such as misoperation during manual switching, reduce RTO, and reduce business interruption time. At the same time, ensure that RPO meets the design requirements and ensure business continuity. Summary of the invention

[0006] The purpose of the present invention is to overcome the defects of the prior art and provide an application disaster recovery switching drill method, device, computer equipment and storage medium.

[0007] To achieve the above object, the present invention adopts the following technical solution: a disaster recovery switching drill method is applied, comprising: Add asset information, configure switching scripts on each asset, establish disaster recovery pairs, and orchestrate switching links; Call the SDK script to perform asset checks. If any check fails, an error message will be fed back. After the check is completed, a message will be displayed indicating that the pre-switching check is complete. During the actual switching process, the SDK script executor executes the primary-backup script and the backup-backup script of the disaster recovery pair in sequence. When the script execution fails or the echo does not meet expectations, the switching task is automatically suspended and the user is prompted to process the corresponding assets. After the link switching is completed, the SDK script executor calls the post-switching check API interface to execute the check script, feeds back the results to the user interface, and prompts that the post-switching check is completed when all checks are successful for business verification.

[0008] The further technical solution is: adding asset information, configuring a switching script on each asset, establishing a disaster recovery pair and arranging a switching link, including: Add asset information corresponding to various types of assets included in the business system; Configure a script for each asset, wherein the script includes a pre-switching and post-switching inspection script, a main-to-standby script, and a standby-to-main script; According to the disaster recovery relationship between the primary assets and the backup assets, the corresponding relationship between the assets in the production environment and the disaster recovery environment is established to obtain a disaster recovery pair; The switching link is arranged according to the disaster recovery pair, wherein a link node is a disaster recovery pair; and the connection relationship of the link nodes is the correlation between the disaster recovery pairs.

[0009] Its further technical solution is: the asset information includes the host's IP address, port number, authentication information and related ports of various services.

[0010] A further technical solution is: calling the SDK script to perform asset inspection, if any inspection fails, an error message is fed back, and after the inspection is completed, a prompt is given that the pre-switching inspection is completed, including: When the switchover starts, select the switchover link and start the switchover, obtain the list of disaster recovery pairs, and execute the pre-switchover check script; Call the SDK script executor's pre-switch check API and pass in the primary 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 and executes the check script through SSH or WinRM remote connection; The SDK script executor executes the inspection script to obtain the inspection result of each asset; The inspection result of each asset is displayed on the user interface.

[0011] Its further technical solution is: in the actual switching process, the SDK script executor sequentially executes the primary switching backup script and the backup switching primary script of the disaster recovery pair, wherein, when the script execution fails or the echo does not meet expectations, the switching task is automatically suspended and the user is prompted to process the corresponding assets, including: Obtain a list of disaster recovery pairs from the selected switching link; Execute the main switch script and the backup switch script in sequence according to the disaster recovery pair list, and execute each link node in the switch link serially and in parallel to obtain the execution result; The execution result is displayed.

[0012] A further technical solution is: the main switching backup script and the backup switching main script are executed in sequence according to the disaster recovery pair list, and each link node in the switching link is executed serially and in parallel to obtain an execution result, including: According to the disaster recovery pair list, the SDK script executor puts the primary-backup script into the task scheduling manager, and remotely connects to the host of the primary asset through SSH or WinRM to execute the primary-backup script. When the SDK script executor completes the execution of the active / standby switch script, it feeds back the active / standby switch execution result to the SDK script executor and displays the active / standby switch execution result; According to the disaster recovery pair list, the SDK script executor puts the backup and cutover main script into the task scheduling manager, and remotely connects to the host of the backup asset through SSH or WinRM to execute the backup and cutover main script; When the SDK script executor completes the execution of the backup master script, the backup master execution result is fed back to the SDK script executor and the backup master execution result is displayed.

[0013] Its further technical solution is: after the link switching is completed, the SDK script executor calls the post-switching check API interface to execute the check script, feeds back the result to the user interface, and prompts that the post-switching check is completed when all checks are successful, and performs business verification, including: After all link nodes in the switching link execute the corresponding switching script, the post-switching check API interface of the SDK script executor is called, and the primary and backup asset information and the post-switching check script are passed in; The SDK script executor submits the switched inspection script to the task scheduling manager, executes it remotely through SSH or WinRM, and feeds back the execution result. After the post-switching check scripts for all assets are executed, business verification is performed.

[0014] The present invention also provides an application disaster recovery switching drill device, comprising: Configuration unit, used to add asset information, configure switching scripts on each asset, establish disaster recovery pairs, and orchestrate switching links; The pre-switching check unit is used to call the SDK script to perform asset checks. If any check fails, an error message will be fed back. After the check is completed, a message will be displayed indicating that the pre-switching check is completed. The switching unit is used to execute the primary-to-backup script and the backup-to-primary script of the disaster recovery pair in sequence through the SDK script executor during the actual switching process. When the script execution fails or the echo does not meet expectations, the switching task is automatically suspended and the user is prompted to process the corresponding assets. The post-switching check unit is used to call the post-switching check API interface through the SDK script executor to execute the check script after the link switching is completed, feedback the results to the user interface, and prompt the post-switching check to be completed when all checks are successful, so as to perform business verification.

[0015] The present invention further provides a computer device, which includes a memory and a processor. The memory stores a computer program, and the processor implements the above method when executing the computer program.

[0016] The present invention also provides a storage medium, wherein the storage medium stores a computer program, and the computer program implements the above method when executed by a processor.

[0017] Compared with the prior art, the present invention has the following beneficial effects: after adding asset information to the system, the present invention configures a switching script for each asset, establishes a disaster recovery pair and arranges a switching link; calls the SDK script to perform asset inspection, and if there is an inspection failure, an error is fed back, and after the inspection is completed, a prompt is given that the pre-switching inspection is completed; in the actual switching process, the SDK script executor sequentially executes the main-to-backup and backup-to-main scripts, and if a failure occurs, the switching task is automatically paused and the user is prompted to process, and after the switching is completed, a post-switching inspection and business verification are performed; through the automated SDK script executor, it is ensured that the production and disaster recovery business systems can be quickly and safely switched during the disaster recovery switching, thereby reducing the risk caused by human operational errors, and reducing the recovery time and business interruption. At the same time, the disaster recovery process is designed to meet the recovery point target and ensure business continuity and reliability.

[0018] The present invention is further described below in conjunction with the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying any creative work.

[0020] Figure 1 A schematic diagram of a process flow of an application disaster recovery switching drill method provided by an embodiment of the present invention; Figure 2 A schematic diagram of a sub-process of an application disaster recovery switching drill method provided by an embodiment of the present invention; Figure 3 A schematic diagram of a sub-process of an application disaster recovery switching drill method provided by an embodiment of the present invention; Figure 4 A schematic diagram of a sub-process of an application disaster recovery switching drill method provided by an embodiment of the present invention; Figure 5 A schematic diagram of a sub-process of an application disaster recovery switching drill method provided by an embodiment of the present invention; Figure 6 A schematic diagram of a sub-process of an application disaster recovery switching drill method provided by an embodiment of the present invention; Figure 7 A schematic diagram of a disaster recovery pair provided in an embodiment of the present invention; Figure 8 A schematic diagram of a switching link provided by an embodiment of the present invention; Fig. 9 A schematic diagram of a link set during cyclic processing provided by an embodiment of the present invention; Fig.10 A schematic block diagram of an application disaster recovery switching drill device provided by an embodiment of the present invention; Fig.11 A schematic block diagram of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0021] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

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

[0023] It should also be understood that the terms used in this specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. As used in the specification of the present invention and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include plural forms.

[0024] It should be further understood that the term "and / or" used in the present description and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0025] See also Figure 1 , Figure 1 A flow chart of the application disaster recovery switching drill method provided for an embodiment of the present invention. The method mainly uses disaster recovery management software to perform corresponding processing. The disaster recovery management software consists of two main parts: WEB management service software and SDK script execution software, that is, SDK script executor. The WEB management service software provides a user interface and operating functions, while the SDK script execution software includes a task scheduling manager, a script executor, and a script library suitable for mainstream databases, networks, applications, and middleware. The script executor is responsible for passing the script execution instructions of the disaster recovery management host to the controlled host. Therefore, it is necessary to perform SSH (for Linux and Unix systems) or WinRM (for Windows systems) remote login on each asset node in advance to receive instructions from the disaster recovery management end. Due to the diversity of host environments and asset types, scripts such as "pre-switching check", "active switch to standby", and "standby switch to active" for each asset should be saved and fixed for future switching. Due to their professionalism and high relevance to the environment, these scripts need to be managed and maintained by professionals and should not be integrated into the disaster recovery system. The disaster recovery system only needs to support the uploading and adding of external scripts to improve the flexibility and scalability of the system. In the disaster recovery management software, you can add active and standby assets and configure scripts such as "pre-switching check", "active switch to standby", and "standby switch to active" for them. Through the script executor, the system can use SSH remote login (applicable to Linux and Unix) or WinRM remote login (applicable to Windows) to send script execution instructions to the controlled host without installing an agent program on the controlled host, thereby saving resource overhead. .

[0026] Figure 1 FIG. 1 is a flow chart of an application disaster recovery switching drill method provided by an embodiment of the present invention. Figure 1 As shown, the method includes the following steps S110 to S140.

[0027] S110, adding asset information, configuring a switching script on each asset, establishing a disaster recovery pair, and arranging a switching link.

[0028] In this embodiment, the asset information includes the host's IP address, port number, authentication information, and related ports of various services. The scripts include pre-switching and post-switching inspection scripts, primary-to-standby scripts, and standby-to-primary scripts.

[0029] In one embodiment, see Figure 2 , the above-mentioned step S110 may include steps S111~S114.

[0030] S111. Add asset information corresponding to each type of asset included in the business system.

[0031] In this embodiment, various assets included in the business system are added to the WEB management service software, such as databases, applications, network devices, and file storage (NAS). Asset information usually includes the host's IP address, port number (such as SSH or WinRM), authentication information (such as user name and password or SSH public key), and related ports of various services (such as database and middleware ports).

[0032] Specifically, by centrally adding and managing information on all assets in the business system (such as databases, applications, network devices, and file storage), the comprehensiveness of assets is ensured. This integrated approach enables managers to quickly obtain relevant information on various types of assets, improving management efficiency.

[0033] Asset information includes authentication information (such as user name, password, and SSH public key), which can effectively control access rights, improve system security, and prevent unauthorized access.

[0034] When asset information is complete, in the event of a system failure or anomaly, managers can quickly locate the problem and reduce the time required to recover from the failure.

[0035] S112. Configure a script for each asset, wherein the script includes a pre-switching and post-switching inspection script, a main-to-standby script, and a standby-to-main script.

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

[0037] By configuring pre-switching and post-switching inspection scripts, primary-to-backup scripts, and backup-to-primary scripts for each asset, automated operation and maintenance of the switching process can be achieved, reducing errors and delays caused by manual operations.

[0038] Pre- and post-cutover check scripts ensure that the health of assets is verified during the cutover process, avoiding business interruptions due to undetected problems.

[0039] Flexible configuration of scripts can adjust switching strategies according to different business needs, improving the adaptability and flexibility of the system.

[0040] S113. According to the disaster recovery relationship between the primary asset and the backup asset, a corresponding relationship between each asset in the production environment and the disaster recovery environment is established to obtain a disaster recovery pair.

[0041] In this embodiment, the disaster recovery pair can ensure that each pair of assets corresponds to each other, so as to facilitate the switching management. The disaster recovery pair finally formed is as follows: Figure 7 shown.

[0042] Specifically, by establishing a disaster recovery relationship between primary assets and backup assets, it is ensured that each asset has a clear backup, reducing the switching risk caused by asset inequality.

[0043] Clear disaster recovery pairs allow managers to see at a glance when switching, improve decision-making efficiency, and simplify operational processes.

[0044] Clear disaster recovery relationships ensure that when a failure occurs, you can quickly switch to backup assets, improving overall disaster recovery capabilities.

[0045] S114. Arrange a switching link according to the disaster recovery pair, wherein a link node is a disaster recovery pair; and a connection relationship between link nodes is a correlation between disaster recovery pairs.

[0046] In this embodiment, a switching link is designed on the WEB management service software according to the actual needs of the business system, where the link node is a disaster recovery pair. According to the correlation between the disaster recovery pairs, the related disaster recovery pairs can be arranged in sequence, while the unrelated disaster recovery pairs can be arranged in parallel. After the arrangement is completed, save and name the switching link for subsequent use, such as Figure 8 shown.

[0047] Specifically, by arranging the switching links, related disaster recovery pairs can be processed in sequence, and unrelated disaster recovery pairs can be processed in parallel, so as to fully utilize system resources and improve the switching efficiency.

[0048] Reasonable link orchestration can avoid resource conflicts and ensure that all related assets can transition smoothly during the switching process, reducing system load and latency.

[0049] After saving and naming the switching link, subsequent management and maintenance will be more efficient. At the same time, it can be easily expanded and modified according to changes in business needs.

[0050] S120, calling the SDK script to perform asset inspection, if any inspection fails, an error message is fed back, after the inspection is completed, a message indicating that the inspection before switching is completed is displayed.

[0051] In one embodiment, see Figure 3 , the above-mentioned step S120 may include steps S121~S125.

[0052] S121. When the switch starts, select a switch link and start the switch, obtain a disaster recovery pair list, and execute a pre-switch check script.

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

[0054] The graphical interface simplifies user operations and reduces the risk of operational errors. Clearly select the link to be switched to facilitate subsequent operations.

[0055] When the user clicks the "Start Switching" button, the system will automatically obtain the relevant disaster recovery pair list from the configuration, including the primary and backup asset information.

[0056] Automatically obtain disaster recovery information, reduce manual intervention, and improve efficiency. Ensure that the assets targeted by the switch operation are the latest and meet current business needs.

[0057] The SDK script execution software executes the pre-written pre-switching check script for each host in the disaster recovery pair to check the readiness of each asset. Through scripted checks, it can ensure that the status of all assets before switching meets the requirements, reducing the possibility of failure after switching. It can improve the safety of switching and ensure that all conditions have been met.

[0058] During the entire inspection process, the user can choose to manually stop the switching operation at any time. This improves the user's control and allows the user to decide whether to continue switching at any time based on actual conditions, thus reducing potential risks.

[0059] Depending on the configured option "Do actual switchover immediately after switchover check": If configured as "Yes", the system automatically performs the switch.

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

[0061] If the check script has errors but is fixed by the user, the user can also manually approve to proceed with the switch.

[0062] Flexible configuration options allow users to make decisions based on specific circumstances when performing switching, increasing operational flexibility. This improves the system's fault tolerance, so that even if problems occur during the inspection process, users can still make adjustments based on actual conditions.

[0063] S122: Call the pre-switching check API of the SDK script executor, and input the primary asset information and backup asset information of the disaster recovery pair and the check script.

[0064] In this embodiment, the WEB management service software passes in the information of the primary and standby assets and the pre-switching check script through the "pre-switching check API" interface of the SDK script execution software.

[0065] Standardized API calls make the interaction between systems more efficient and reliable, improve the automation of pre-switching checks, and reduce manual intervention.

[0066] The content of the pre-cutover check script is written by professionals according to the asset type, such as database, network, etc. Database scripts check role matching and data consistency. Network scripts check connectivity and resource status.

[0067] Scripts written by professionals can ensure the comprehensiveness and accuracy of inspections and reduce potential risks. Inspections of various types of assets are highly targeted and can quickly identify potential problems.

[0068] S123, the SDK script executor puts the inspection script into the task scheduling manager, and executes the inspection script through the SSH or WinRM remote connection; S124, the SDK script executor executes the inspection script to obtain the inspection result of each asset; S125. Display each asset inspection result on the user interface.

[0069] In this embodiment, the SDK script execution software puts the pre-switching check script of each asset into the task scheduling manager, remotely connects to the asset to execute the script, and returns the check result.

[0070] Remote execution reduces the need for direct access to assets and improves security. Results are fed back to users in a timely manner, allowing them to quickly understand the overall status of the pre-switching check.

[0071] If the pre-switch check script of a certain asset fails to execute, the SDK script execution software will return an error message, but it will not affect the check execution of other assets. It will not affect the overall switching process, and avoid a single asset problem delaying the entire switch. It provides timely feedback on problems, which helps users quickly locate and solve problems.

[0072] When all pre-switching check scripts for assets are executed, the WEB management service software will prompt the user with the check completion status.

[0073] Clearly inform users of the overall results of the pre-switching check, making it easier for them to make subsequent decisions. This enhances users' understanding of the system's operating status and improves the transparency of operations.

[0074] Through this series of steps, the system realizes the automation and security of the switching process. Users can not only grasp the status of each asset in real time, but also flexibly respond to various situations during the switching, thereby reducing risks and improving business continuity.

[0075] S130. During the actual switching process, the SDK script executor executes the primary-backup script and the backup-primary script of the disaster recovery pair in sequence. When the script execution fails or the echo does not meet expectations, the switching task is automatically suspended and the user is prompted to process the corresponding assets.

[0076] In one embodiment, see Figure 4 , the above-mentioned step S130 may include steps S131~S133.

[0077] S131. Obtain a disaster recovery pair list from the selected switching link.

[0078] In this embodiment, the disaster recovery pair list is obtained from the selected switching link. This process mainly relies on the existing asset management system or service interface.

[0079] Through centralized management, all disaster recovery pairs that need to be switched can be quickly obtained to ensure the accuracy of the operation. When obtaining the disaster recovery pair list, it can be ensured that the information of the primary and backup assets is included to avoid switching failures due to incomplete information.

[0080] S132: Execute the primary-backup script and the backup-primary script in sequence according to the disaster recovery pair list, and execute each link node in the switching link in series and in parallel to obtain an execution result.

[0081] In this embodiment, the execution result refers to the result obtained after the switching is executed.

[0082] For each disaster recovery pair, the SDK script execution software executes the primary-backup script and the backup-backup master script in sequence. The primary-backup script is executed on the primary side, and the backup-backup master script is executed on the backup side.

[0083] Automatic script execution can reduce human operation errors and improve switching efficiency. Combining serial and parallel operations can be flexibly processed according to the actual situation of the link nodes, improving the speed and efficiency of the overall switching. The WEB management service software loops through the disaster recovery pair list, calls the "Switch API" interface of the SDK script execution software, and sequentially passes in the primary and standby asset information and the switching script; modular design is carried out through the API interface to facilitate subsequent maintenance and expansion. Through the API, the execution and status of each switching operation can be easily monitored. Fig. 9 As shown in the figure, the ordered set is represented by "[]" and the unordered set is represented by "{}". The ordered set is executed sequentially, and the unordered set is executed concurrently. The main switch script and the backup switch script are written by professionals according to the asset type. These scripts perform corresponding switching operations, such as SQL statement execution or virtual IP switching. Scripts written by professionals in the field can ensure the accuracy and reliability of switching. Specific switching scripts can be written for different asset types to enhance the adaptability of the system.

[0084] In one embodiment, see Figure 5 , the above-mentioned step S132 may include steps S1321~S1324.

[0085] S1321. The SDK script executor puts the primary-backup script into the task scheduling manager according to the disaster recovery pair list, and remotely connects to the host of the primary asset through SSH or WinRM to execute the primary-backup script.

[0086] In this embodiment, in this link, the SDK script executor puts the primary-to-backup script into the task scheduling manager according to the obtained disaster recovery pair list. This process involves remotely connecting to the host of the primary asset through SSH (Secure Shell) or WinRM (Windows Remote Management) to execute the corresponding primary-to-backup script.

[0087] Specifically, the disaster recovery pair list: contains detailed information about a pair of primary and backup assets to ensure the accuracy of the switchover operation. SDK script executor: responsible for handling the execution and scheduling of scripts, and sending the switchover task to the task scheduling manager. Task scheduling manager: receives script tasks and arranges the execution order to ensure that the operation is executed according to the predetermined process. Remote connection: uses SSH or WinRM for remote connection to ensure that no manual intervention is required when executing the script.

[0088] By automatically placing scripts into task scheduling, human errors are reduced and efficiency is improved; remote execution is supported to facilitate the management of assets in different locations.

[0089] S1322. After the SDK script executor completes the execution of the active / standby switching script, the active / standby switching execution result is fed back to the SDK script executor, and the active / standby switching execution result is displayed.

[0090] In this embodiment, after the active / standby switching script is executed, the SDK script executor feeds back the received active / standby switching execution result to itself and displays the execution result on the user interface.

[0091] Specifically, the SDK script executor receives the execution results from the master, including success or failure, execution logs, error information, etc. The results are fed back to the user through the user interface to ensure that the user can clearly understand the current operation status.

[0092] Users can quickly learn about the switching status, which helps with subsequent decision-making. The display of execution results makes the switching process more transparent and enhances user trust.

[0093] S1323. The SDK script executor puts the backup and cutover main script into the task scheduling manager according to the disaster recovery pair list, and remotely connects to the host of the backup asset through SSH or WinRM to execute the backup and cutover main script.

[0094] In this embodiment, after the primary-to-backup script is executed and the result is fed back, the SDK script executor again puts the backup-to-backup main script into the task scheduling manager according to the disaster recovery pair list, and remotely connects to the host of the backup asset through SSH or WinRM to execute the backup-to-backup main script.

[0095] Specifically, the backup-to-failure main script corresponds to the main-to-failure script and is a script specifically used to be executed on the backup-side assets.

[0096] Scheduling Manager: Receives and schedules the execution of the backup script to ensure that the backup script is started immediately after the main script is completed.

[0097] Remote connection: Similar to the steps in S1321, use SSH or WinRM to remotely connect to the backup asset.

[0098] By sequentially executing the active-standby switching and the standby-active-active switching, the consistency and safety of the entire switching process are ensured; automated management is also achieved to reduce manual operations.

[0099] S1324. After the SDK script executor completes the execution of the backup master script, the backup master execution result is fed back to the SDK script executor, and the backup master execution result is displayed.

[0100] After the master-switch script is executed, the SDK script executor feeds back the received backup-switch-master execution result to itself and displays the execution result on the user interface.

[0101] Specifically, the SDK script executor receives the execution results from the standby end, including success or failure, execution logs, error information, etc. The standby-to-master execution results are fed back to the user through the user interface to ensure that the user can understand the switching status of the standby end in real time.

[0102] Similar to step S1322, the two-way feedback mechanism ensures that the user has a comprehensive understanding of the switching process. If a problem occurs, the user can obtain information and handle it in a timely manner to reduce potential risks.

[0103] S133: Display the execution result.

[0104] The execution results are displayed through a clear user interface, including success, failure information and related logs. Users can obtain complete feedback on the switching process, which helps to evaluate the success rate of the entire operation. The detailed display of execution results provides a basis for subsequent decision-making, such as whether recovery operations are needed or disaster recovery strategies are adjusted.

[0105] In addition, if the switching script execution of an asset fails, the SDK script execution software returns a prompt, requiring the user to check and process the asset, and automatically suspends the switching task.

[0106] Through timely feedback and automatic pause switching, potential system risks can be effectively avoided. Users can participate in handling errors and ensure that the system runs in a stable state.

[0107] After handling the error, the user can choose to end the switch or skip the error and continue the switch. The user can flexibly choose the operation according to the actual situation, which helps to improve the availability and disaster recovery capabilities of the system. This design enhances the user's sense of control and participation and increases the transparency of the operation.

[0108] Through the above steps, the entire disaster recovery switching process can achieve efficient, automated and safe operation. Each step is designed with risk control and user experience in mind, so that when faced with emergencies, the system can recover quickly and minimize the risk of business interruption and data loss. This systematic switching solution is an indispensable part of the modern IT environment, especially in areas with high requirements for business continuity and data security.

[0109] S140. After the link switching is completed, the post-switching check API interface is called by the SDK script executor to execute the check script, the result is fed back to the user interface, and when all checks are successful, the post-switching check is completed to perform business verification.

[0110] In one embodiment, see Figure 6 , the above-mentioned step S140 may include steps S141~S143.

[0111] S141. After all link nodes in the switching link execute the corresponding switching script, the post-switching check API interface of the SDK script executor is called, and the primary and standby asset information and the post-switching check script are passed in.

[0112] S142, the SDK script executor submits the switched inspection script to the task scheduling manager, executes it remotely through SSH or WinRM, and feeds back the result of the execution; S143. After the post-switching check scripts of all assets are executed, business verification is performed.

[0113] Specifically, after all nodes in the link have executed the switching script, the WEB management service software interface displays the completion status of the link switching, and calls the SDK script execution software to initiate the post-switching inspection task, and concurrently executes the post-switching inspection script for all assets in the link.

[0114] Specifically, the WEB management service software updates the interface in real time to display the status of link switching completion; calls the SDK script to execute relevant functions of the software and starts post-switching inspection of all assets.

[0115] Users can intuitively see the switching status, which enhances the transparency of operations; Concurrent execution: Concurrent inspection of all assets improves efficiency and shortens inspection time.

[0116] The post-switching check is performed by the WEB management service software calling the "post-switching check API" interface of the SDK script execution software, and inputting the information of the primary and backup assets of the disaster recovery pair and the post-switching check script.

[0117] Specifically, the WEB management service software passes the information of the primary and backup assets and related scripts to the SDK script execution software through the API, ensuring that all necessary information is accurate and convenient for subsequent inspection.

[0118] Through API calls, the post-switching inspection process is standardized to reduce human errors; asset information is centrally managed to facilitate subsequent inspection and processing.

[0119] The content of the post-switch check script is related to the asset type and is written by professionals to ensure that it meets the characteristics of different assets. For example, the post-switch check script of the database will execute SQL statements to check the switching of the master and slave roles.

[0120] Specifically, professionals write corresponding post-switching inspection scripts based on different asset types. For example, database assets check whether the original master database has become a backup database, and virtual IP assets check whether the master end is offline and the backup end is online.

[0121] Scripts written by professionals ensure the accuracy and effectiveness of the inspection. The inspection content is targeted at specific asset types, which enhances the pertinence and effectiveness of the detection.

[0122] The SDK script execution software puts the post-switching check script of each asset into the task scheduling manager, which then remotely logs into the asset host through SSH or WinRM to execute the script.

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

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

[0125] If the post-switch check script execution of a certain asset fails or returns unexpected results, the SDK script execution software will prompt the user with an error message, but it will not affect the check execution of other assets.

[0126] Specifically, the SDK script execution software will feed back error information to the WEB management service software, and users can see relevant prompts; even if problems occur with individual assets, checks on other assets will continue to be executed.

[0127] Identify problem assets in a timely manner to facilitate subsequent processing; ensure the smooth progress of the overall inspection process and improve the robustness of the system.

[0128] After the post-switching check scripts for all assets are executed, the WEB management service software will prompt the user that the post-switching check has been completed.

[0129] 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 completed.

[0130] Users do not need to check the status of each asset one by one, the system automatically summarizes the feedback. Users can confirm the completion of the entire switching process through prompts, which enhances their trust in the system.

[0131] Finally, business validation is performed to ensure that all services and applications are functioning properly.

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

[0133] Through business verification, ensure that all services and applications can be used normally after switching; discover potential problems in a timely manner, reduce business operation risks, and enhance the reliability of the overall system.

[0134] The above steps constitute a comprehensive and systematic post-switching inspection process. Through clear steps, professional script writing and automated execution, the efficiency and accuracy of the switching process are ensured. At the same time, users can get feedback in real time, which enhances the transparency and trust of the operation. The design of each link guarantees the availability of the final business and the stability of the system, reducing potential risks.

[0135] The above-mentioned application disaster recovery switching drill method configures a switching script for each asset after adding asset information in the system, establishes a disaster recovery pair and arranges the switching link; calls the SDK script to perform asset inspection, and if there is an inspection failure, it will feedback an error. After the inspection is completed, it will prompt that the pre-switch inspection is completed; in the actual switching process, the SDK script executor will execute the main-to-backup and backup-to-main scripts in sequence. If it fails, the switching task will be automatically suspended and the user will be prompted to handle it. After the switching is completed, the post-switch inspection and business verification will be performed; through the automated SDK script executor, it is ensured that the production and disaster recovery business systems can be switched quickly and safely during the disaster recovery switching, thereby reducing the risks caused by human operation errors, reducing the recovery time (RTO) and business interruption. At the same time, the disaster recovery process is designed to meet the recovery point objective (RPO) to ensure business continuity and reliability.

[0136] Fig.10 FIG. 3 is a schematic block diagram of an application disaster recovery switching training device 300 provided in an embodiment of the present invention. Fig.10 As shown, corresponding to the above application disaster recovery switching drill method, the present invention also provides an application disaster recovery switching drill device 300. The application disaster recovery switching drill device 300 includes a unit for executing the above application disaster recovery switching drill method, and the device can be configured in a server. Fig.10 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.

[0137] The configuration unit 301 is used to add asset information, configure switching scripts on each asset, establish disaster recovery pairs, and arrange switching links; the pre-switching check unit 302 is used to call the SDK script to perform asset checks. If any check fails, an error message is fed back. After the check is completed, a prompt is given that the pre-switching check is completed; the switching unit 303 is used to execute the main-backup script and the backup-main script of the disaster recovery pair in sequence through the SDK script executor during the actual switching process. When the script execution fails or the echo does not meet expectations, the switching task is automatically paused and the user is prompted to process the corresponding assets; the post-switching check unit 304 is used to call the post-switching check API interface through the SDK script executor to execute the check script after the link switching is completed, feed back the results to the user interface, and prompt the post-switching check to be completed when all checks are successful, and perform business verification.

[0138] In one embodiment, the configuration unit 301 includes: An adding subunit is used to add asset information corresponding to various types of assets included in the business system; a script configuration subunit is used to configure a script for each asset, wherein the script includes a pre-switching and post-switching inspection script, a primary-to-backup script, and a backup-to-primary script; a disaster recovery pair building subunit is used to establish a corresponding relationship between each asset in the production environment and the disaster recovery environment based on the disaster recovery relationship between the primary asset and the backup asset to obtain a disaster recovery pair; a link arrangement subunit is used to arrange a switching link according to the disaster recovery pair, wherein a link node is a disaster recovery pair; and the connection relationship between the link nodes is the correlation between the disaster recovery pairs.

[0139] In one embodiment, the pre-switching checking unit 302 includes: The selection subunit is used to select the switching link and start the switching at the beginning of the switching, obtain the list of disaster recovery pairs and execute the pre-switching check script; the first input subunit is used to call the pre-switching check API of the SDK script executor, and input the primary asset information 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 scheduling manager and execute the check script through SSH or WinRM remote connection; the first execution subunit is used for the SDK script executor to execute the check script to obtain the check result of each asset; the first display subunit is used to display each asset check result on the user interface.

[0140] In one embodiment, the switching unit 303 includes: A list acquisition subunit is used to obtain a disaster recovery pair list from the selected switching link; a second execution subunit is used to execute the main-to-backup script and the backup-to-main 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 an execution result; a second display subunit is used to display the execution result.

[0141] In one embodiment, the second execution subunit includes: The first insertion module is used for the SDK script executor to put the main-to-backup script into the task scheduling manager according to the disaster recovery pair list, and remotely connect to the host of the primary asset through SSH or WinRM to execute the main-to-backup script; the first switching module is used for, after the SDK script executor completes the execution of the main-to-backup script, the main-to-backup execution result is fed back to the SDK script executor, and the main-to-backup execution result is displayed; the second insertion module is used for the SDK script executor to put the backup main script into the task scheduling manager according to the disaster recovery pair list, and remotely connect to the host of the backup asset through SSH or WinRM to execute the backup main script; the second switching module is used for, after the SDK script executor completes the execution of the backup main script, the backup main execution result is fed back to the SDK script executor, and the backup main execution result is displayed.

[0142] In one embodiment, the post-switching checking unit 304 includes The second input subunit is used to call the post-switching check API interface of the SDK script executor and input the primary and standby asset information and the post-switching check script after all link nodes in the switching link have executed the corresponding switching script. The third execution subunit is used for the SDK script executor to submit the post-switching check script to the task scheduling manager, remotely execute it through SSH or WinRM, and feedback the results of the execution; the verification subunit is used to perform business verification after the post-switching check script of all assets has been executed.

[0143] It should be noted that technicians in the relevant field can clearly understand that the specific implementation process of the above-mentioned application disaster recovery switching drill device 300 and each unit can refer to the corresponding description in the aforementioned method embodiment, and for the convenience and brevity of description, it will not be repeated here.

[0144] The application disaster recovery switching drill device 300 can be implemented in the form of a computer program. The computer program can be used in Fig.11 Runs on the computer device shown.

[0145] See also Fig.11 , Fig.11 5 is a schematic block diagram of a computer device provided in an embodiment of the present application. The computer device 500 may be a terminal.

[0146] See also Fig.11 The computer device 500 includes a processor 502 , a memory and a network interface 505 connected via a system bus 501 , wherein the memory may include a non-volatile storage medium 503 and an internal memory 504 .

[0147] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions, and when the program instructions are executed, the processor 502 can execute an application disaster recovery switching drill method.

[0148] The processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500 .

[0149] The internal memory 504 provides an environment for the operation 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 drill method.

[0150] The network interface 505 is used to communicate with other devices over the network. Fig.11The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present application, and does not constitute a limitation on the computer device 500 to which the solution of 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 a different arrangement of components.

[0151] The processor 502 is used to run the computer program 5032 stored in the memory to implement the following steps: Add asset information, configure switching scripts on each asset, establish disaster recovery pairs, and orchestrate switching links; call the SDK script to perform asset checks. If any check fails, an error message will be fed back. After the check is completed, a prompt will be displayed saying that the pre-switch check is completed. During the actual switching process, the SDK script executor will execute the primary-backup script and the backup-primary script of the disaster recovery pair in sequence. When the script execution fails or the echo does not meet expectations, the switching task will be automatically paused and the user will be prompted to process the corresponding assets. After the link switching is completed, the SDK script executor will call the post-switch check API interface to execute the check script, feed back the results to the user interface, and when all checks are successful, a prompt will be displayed saying that the post-switch check is completed for business verification.

[0152] In one embodiment, the processor 502 implements the following steps when implementing the steps of adding asset information, configuring a switching script on each asset, establishing a disaster recovery pair, and arranging a switching link: Add asset information corresponding to each type of asset included in the business system; configure scripts for each asset, wherein the scripts include pre-switching and post-switching inspection scripts, primary-to-backup scripts, and backup-to-primary scripts; establish a corresponding relationship between each asset in the production environment and the disaster recovery environment based on the disaster recovery relationship between the primary asset and the backup asset to obtain a disaster recovery pair; arrange switching links based on the disaster recovery pair, wherein a link node is a disaster recovery pair; and the connection relationship between the link nodes is the correlation between the disaster recovery pairs.

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

[0154] In one embodiment, the processor 502 implements the following steps when implementing the calling of the SDK script to perform asset inspection and feeding back an error message if any inspection fails and prompting the pre-switching inspection completion step after the inspection is completed: At the beginning of the switch, select the switch link and start the switch, obtain the disaster recovery pair list and execute the pre-switch check script; call the SDK script executor's pre-switch check API, 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 scheduling manager and executes the check script through SSH or WinRM remote connection; the SDK script executor executes the check script to obtain the check result of each asset; and displays each asset check result on the user interface.

[0155] In one embodiment, the processor 502 executes the primary-to-backup script and the backup-to-primary script of the disaster recovery pair in sequence through the SDK script executor during the actual switching process. When the script execution fails or the echo does not meet expectations, the switching task is automatically suspended and the user is prompted to process the corresponding asset steps. Specifically, the following steps are implemented: Obtain a disaster recovery pair list from the selected switching link; execute the main switching backup script and the backup switching main script in sequence according to the disaster recovery pair list, and execute each link node in the switching link in series and in parallel to obtain an execution result; and display the execution result.

[0156] In one embodiment, when the processor 502 implements the step of sequentially executing the primary-standby script and the standby-standby primary script according to the disaster recovery pair list, and executing each link node in the switching link in series and in parallel to obtain the execution result, the processor 502 specifically implements the following steps: According to the disaster recovery pair list, the SDK script executor puts the primary-to-backup script into the task scheduling manager, and remotely connects to the host of the primary asset through SSH or WinRM to execute the primary-to-backup script; when the SDK script executor completes the execution of the primary-to-backup script, it feeds back the primary-to-backup execution result to the SDK script executor, and displays the primary-to-backup execution result; according to the disaster recovery pair list, the SDK script executor puts the backup-to-backup main script into the task scheduling manager, and remotely connects to the host of the backup asset through SSH or WinRM to execute the backup-to-backup main script; when the SDK script executor completes the execution of the backup-to-backup main script, it feeds back the backup-to-backup execution result to the SDK script executor, and displays the backup-to-backup execution result.

[0157] In one embodiment, when the processor 502 implements the following steps, after the link switching is completed, the SDK script executor calls the post-switching check API interface to execute the check script, feeds back the result to the user interface, and prompts that the post-switching check is completed when all checks are successful. When performing the service verification step, the following steps are specifically implemented: After all link nodes in the switching link have executed the corresponding switching script, the post-switching check API interface of the SDK script executor is called, and the primary and standby asset information and the post-switching check script are passed in; the SDK script executor submits the post-switching check script to the task scheduling manager, executes it remotely through SSH or WinRM, and feeds back the execution results; when the post-switching check scripts of all assets are executed, business verification is performed.

[0158] It should be understood that in the embodiment of the present application, the processor 502 may be a central processing unit (CPU), and the processor 502 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0159] It can be understood by those skilled in the art that all or part of the processes in the method for implementing the above embodiment can be completed by instructing the relevant hardware through a computer program. The computer program includes program instructions, and the computer program 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 embodiment of the above method.

[0160] Therefore, the present invention also provides a storage medium. The storage medium may be a computer-readable storage medium. The storage medium stores a computer program, wherein when the computer program is executed by a processor, the processor executes the following steps: Add asset information, configure switching scripts on each asset, establish disaster recovery pairs, and orchestrate switching links; call the SDK script to perform asset checks. If any check fails, an error message will be fed back. After the check is completed, a prompt will be displayed saying that the pre-switch check is completed. During the actual switching process, the SDK script executor will execute the primary-backup script and the backup-primary script of the disaster recovery pair in sequence. When the script execution fails or the echo does not meet expectations, the switching task will be automatically paused and the user will be prompted to process the corresponding assets. After the link switching is completed, the SDK script executor will call the post-switch check API interface to execute the check script, feed back the results to the user interface, and when all checks are successful, a prompt will be displayed saying that the post-switch check is completed for business verification.

[0161] In one embodiment, when the processor executes the computer program to implement the steps of adding asset information, configuring a switching script on each asset, establishing a disaster recovery pair, and arranging a switching link, the processor specifically implements the following steps: Add asset information corresponding to each type of asset included in the business system; configure scripts for each asset, wherein the scripts include pre-switching and post-switching inspection scripts, primary-to-backup scripts, and backup-to-primary scripts; establish a corresponding relationship between each asset in the production environment and the disaster recovery environment based on the disaster recovery relationship between the primary asset and the backup asset to obtain a disaster recovery pair; arrange switching links based on the disaster recovery pair, wherein a link node is a disaster recovery pair; and the connection relationship between the link nodes is the correlation between the disaster recovery pairs.

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

[0163] In one embodiment, the processor implements the calling of the SDK script to perform asset inspection when executing the computer program, and if any inspection fails, an error message is fed back, and after the inspection is completed, a prompt is given to complete the pre-switching inspection step, and the following steps are specifically implemented: At the beginning of the switch, select the switch link and start the switch, obtain the disaster recovery pair list and execute the pre-switch check script; call the SDK script executor's pre-switch check API, 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 scheduling manager and executes the check script through SSH or WinRM remote connection; the SDK script executor executes the check script to obtain the check result of each asset; and displays each asset check result on the user interface.

[0164] In one embodiment, the processor executes the computer program to implement the following steps: in the actual switching process, the SDK script executor sequentially executes the primary switching script and the backup switching script of the disaster recovery pair, wherein when the script execution fails or the echo does not meet expectations, the switching task is automatically suspended and the user is prompted to process the corresponding asset steps, and the following steps are specifically implemented: Obtain a disaster recovery pair list from the selected switching link; execute the main switching backup script and the backup switching main script in sequence according to the disaster recovery pair list, and execute each link node in the switching link in series and in parallel to obtain an execution result; and display the execution result.

[0165] In one embodiment, when the processor executes the computer program to implement the step of sequentially executing the primary-standby script and the standby-standby primary script according to the disaster recovery pair list, and executing each link node in the switching link serially and in parallel to obtain the execution result, the processor specifically implements the following steps: According to the disaster recovery pair list, the SDK script executor puts the primary-to-backup script into the task scheduling manager, and remotely connects to the host of the primary asset through SSH or WinRM to execute the primary-to-backup script; when the SDK script executor completes the execution of the primary-to-backup script, it feeds back the primary-to-backup execution result to the SDK script executor, and displays the primary-to-backup execution result; according to the disaster recovery pair list, the SDK script executor puts the backup-to-backup main script into the task scheduling manager, and remotely connects to the host of the backup asset through SSH or WinRM to execute the backup-to-backup main script; when the SDK script executor completes the execution of the backup-to-backup main script, it feeds back the backup-to-backup execution result to the SDK script executor, and displays the backup-to-backup execution result.

[0166] In one embodiment, the processor executes the computer program to implement the following steps: after the link switching is completed, the SDK script executor calls the post-switching check API interface to execute the check script, feeds back the result to the user interface, and prompts that the post-switching check is completed when all checks are successful. When performing the service verification step, the processor specifically implements the following steps: After all link nodes in the switching link have executed the corresponding switching script, the post-switching check API interface of the SDK script executor is called, and the primary and standby asset information and the post-switching check script are passed in; the SDK script executor submits the post-switching check script to the task scheduling manager, executes it remotely through SSH or WinRM, and feeds back the execution results; when the post-switching check scripts of all assets are executed, business verification is performed.

[0167] The storage medium may be a USB flash drive, a mobile hard disk, a read-only memory (ROM), a magnetic disk, or an optical disk, etc., which are computer-readable storage media that can store program codes.

[0168] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

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

[0170] The steps in the method of the embodiment of the present invention can be adjusted in order, combined and deleted according to actual needs. The units in the device of the embodiment of the present invention can be combined, divided and deleted according to actual needs. In addition, the functional units in the various embodiments of the present 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.

[0171] If the integrated unit is implemented in the form of 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 is essentially 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. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, terminal, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention.

[0172] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. The application disaster recovery switching drill method is characterized by: include: Add asset information, configure switching scripts on each asset, establish disaster recovery pairs, and orchestrate switching links; Call the SDK script to perform asset checks. If any check fails, an error message will be fed back. After the check is completed, a message will be displayed indicating that the pre-switching check is complete. During the actual switching process, the SDK script executor executes the primary-backup script and the backup-backup primary script of the disaster recovery pair in sequence. If the script execution fails or the echo does not meet expectations, the switching task is automatically suspended and the user is prompted to process the corresponding assets. After the link switching is completed, the SDK script executor calls the post-switching check API interface to execute the check script, feeds back the results to the user interface, and prompts that the post-switching check is completed when all checks are successful for business verification.

2. The application disaster recovery switching drill method according to claim 1, characterized in that: Adding asset information, configuring switching scripts on each asset, establishing disaster recovery pairs, and arranging switching links include: Add asset information corresponding to various types of assets included in the business system; Configure a script for each asset, wherein the script includes a pre-switching and post-switching inspection script, a main-to-standby script, and a standby-to-main script; According to the disaster recovery relationship between the primary assets and the backup assets, the corresponding relationship between the assets in the production environment and the disaster recovery environment is established to obtain a disaster recovery pair; The switching link is arranged according to the disaster recovery pair, wherein a link node is a disaster recovery pair; and the connection relationship of the link nodes is the correlation between the disaster recovery pairs.

3. The application disaster recovery switching drill method according to claim 2, characterized in that: The asset information includes the host's IP address, port number, authentication information, and related ports for various services.

4. The application disaster recovery switching drill method according to claim 3 is characterized in that: The SDK script is called to perform asset checks. If any check fails, an error message is fed back. After the check is completed, a message prompting that the pre-switching check is completed is displayed, including: When the switchover starts, select the switchover link and start the switchover, obtain the list of disaster recovery pairs, and execute the pre-switchover check script; Call the SDK script executor's pre-switch check API and pass in the primary 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 and executes the check script through SSH or WinRM remote connection; The SDK script executor executes the inspection script to obtain the inspection result of each asset; The inspection result of each asset is displayed on the user interface.

5. The application disaster recovery switching drill method according to claim 3, characterized in that: In the actual switching process, the SDK script executor sequentially executes the primary switching script and the backup switching script of the disaster recovery pair. When the script execution fails or the echo does not meet expectations, the switching task is automatically suspended and the user is prompted to process the corresponding assets, including: Obtain a list of disaster recovery pairs from the selected switching link; Execute the main switch script and the backup switch script in sequence according to the disaster recovery pair list, and execute each link node in the switch link serially and in parallel to obtain the execution result; The execution result is displayed.

6. The application disaster recovery switching drill method according to claim 5, characterized in that: The main switching script and the backup switching script are executed in sequence according to the disaster recovery pair list, and each link node in the switching link is executed serially and in parallel to obtain an execution result, including: According to the disaster recovery pair list, the SDK script executor puts the primary-backup script into the task scheduling manager, and remotely connects to the host of the primary asset through SSH or WinRM to execute the primary-backup script. When the SDK script executor completes the execution of the active / standby switch script, it feeds back the active / standby switch execution result to the SDK script executor and displays the active / standby switch execution result; According to the disaster recovery pair list, the SDK script executor puts the backup and cutover main script into the task scheduling manager, and remotely connects to the host of the backup asset through SSH or WinRM to execute the backup and cutover main script; When the SDK script executor completes the execution of the backup master script, the backup master execution result is fed back to the SDK script executor and the backup master execution result is displayed.

7. The application disaster recovery switching drill method according to claim 3, characterized in that: After the link switching is completed, the SDK script executor calls the post-switching check API interface to execute the check script, feeds back the results to the user interface, and prompts that the post-switching check is completed when all checks are successful, and performs business verification, including: After all link nodes in the switching link execute the corresponding switching script, the post-switching check API interface of the SDK script executor is called, and the primary and backup asset information and the post-switching check script are passed in; The SDK script executor submits the switched inspection script to the task scheduling manager, executes it remotely through SSH or WinRM, and feeds back the execution result. After the post-switching check scripts for all assets are executed, business verification is performed.

8. The application disaster recovery switching drill device is characterized in that: include: Configuration unit, used to add asset information, configure switching scripts on each asset, establish disaster recovery pairs, and orchestrate switching links; The pre-switching check unit is used to call the SDK script to perform asset checks. If any check fails, an error message will be fed back. After the check is completed, a message will be displayed indicating that the pre-switching check is completed. The switching unit is used to execute the primary-to-backup script and the backup-to-primary script of the disaster recovery pair in sequence through the SDK script executor during the actual switching process. When the script execution fails or the echo does not meet expectations, the switching task is automatically suspended and the user is prompted to process the corresponding assets. The post-switching check unit is used to call the post-switching check API interface through the SDK script executor to execute the check script after the link switching is completed, feedback the results to the user interface, and prompt the post-switching check to be completed when all checks are successful, so as to perform business verification.

9. A computer device, characterized in that: The computer device comprises a memory and a processor, the memory stores a computer program, and the processor implements the method according to any one of claims 1 to 7 when executing the computer program.

10. A storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images