Disaster recovery control method and apparatus, and computer device and storage medium

Abstract

The present application relates to a disaster recovery control method and apparatus, and a computer device, a storage medium and a computer program product. The method comprises: when a cloud host operates in a user mode, acquiring disaster recovery control information of the cloud host from a control end, wherein the disaster recovery control information comprises a plurality of disaster recovery control conditions and disaster recovery control modes respectively corresponding to the disaster recovery control conditions; in response to an operation state switching event of the cloud host switching from the user mode to a kernel mode, acquiring system state information of the cloud host; and screening the disaster recovery control conditions to obtain a target control condition that matches the system state information, and determining, from among the disaster recovery control modes, a target control mode corresponding to the target control condition. By means of the method, when a cloud host is in the kernel mode, disaster recovery control is performed on the cloud host according to a target control mode, thereby implementing kernel-level rapid disaster recovery control, and improving the efficiency of disaster recovery control.

Description

Disaster recovery control methods, devices, computer equipment and storage media Cross-references

[0001] This application incorporates Chinese Patent Application No. 2024116280913, filed on November 14, 2024, entitled “Disaster Recovery Control Method, Apparatus, Computer Equipment and Storage Medium”, which is incorporated herein by reference in its entirety. Technical Field

[0002] This application relates to the field of cloud computing technology, and in particular to a disaster recovery control method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0003] In today's enterprise environment, maintaining the high availability and stability of IT systems is of paramount importance. When a system or service fails, it is necessary to switch the service to a backup system or component to ensure uninterrupted business operations and maintain system stability.

[0004] Traditional technologies rely on manual operation and fixed strategies for disaster recovery control. Due to the numerous steps involved, the manual disaster recovery control process is complex and time-consuming, making it difficult to respond quickly when a disaster occurs, and the problem of low efficiency in disaster recovery control still exists. Summary of the Invention

[0005] Therefore, it is necessary to provide a disaster recovery control method, device, computer equipment, computer-readable storage medium, and computer program product that can improve the efficiency of disaster recovery control in response to the above-mentioned technical problems.

[0006] In a first aspect, this application provides a disaster recovery control method applied to a cloud host. The method includes: obtaining disaster recovery control information of the cloud host from a control terminal when the cloud host is running in user mode; the disaster recovery control information includes multiple disaster recovery control conditions and a disaster recovery control mode corresponding to each of the disaster recovery control conditions; obtaining system status information of the cloud host in response to a running state switching event where the cloud host switches from user mode to kernel mode; filtering target control conditions that match the system status information from among the disaster recovery control conditions, and determining the target control mode corresponding to the target control conditions from among the disaster recovery control modes; and performing disaster recovery control on the cloud host according to the target control mode.

[0007] In one embodiment, the system status information includes parameter values ​​for multiple preset parameters; the step of filtering target control conditions that match the system status information from among the disaster recovery control conditions includes: for each disaster recovery control condition, determining a condition parameter to characterize the disaster recovery control condition; if the multiple preset parameters include a condition parameter corresponding to the disaster recovery control condition, then the disaster recovery control condition is determined as a candidate control condition; for each candidate control condition, if the parameter range of the condition parameter in the candidate control condition includes the parameter value of the preset parameter corresponding to the condition parameter, then the candidate control condition is determined as a target control condition that matches the system status information.

[0008] In one embodiment, there are multiple target control modes, and the step of performing disaster recovery control on the cloud host according to the target control modes includes: obtaining the expected recovery time of each of the target control modes; and performing disaster recovery control on the cloud host according to the target control mode with the shortest expected recovery time.

[0009] In one embodiment, the method further includes: loading the disaster recovery control information into the kernel-mode storage space when the cloud host is running in user mode; the method further includes: reading the disaster recovery control information from the storage space when the cloud host is running in kernel mode.

[0010] In one embodiment, obtaining the disaster recovery control information of the cloud host from the control terminal includes: obtaining multiple preset control information configured for the cloud host from the control terminal; performing control condition verification on each preset control information, and determining the preset control information that passes the control condition verification as the first control information; performing control mode verification on each preset control information, and determining the preset control information that passes the control mode verification as the second control information; and combining the first control information and the second control information to obtain the disaster recovery control information of the cloud host.

[0011] In one embodiment, the method further includes: when the cloud host is running in user mode, in response to a disaster recovery control update event, obtaining an updated disaster recovery control script and disaster recovery control information from the control terminal; obtaining the system status information of the cloud host includes: calling the disaster recovery control script to obtain the system status information of the cloud host; filtering target control conditions that match the system status information from among the various disaster recovery control conditions includes: filtering target control conditions that match the system status information from among the multiple disaster recovery control conditions included in the updated disaster recovery control information.

[0012] Secondly, this application also provides a disaster recovery control device. The device includes:

[0013] The control information acquisition module is used to acquire disaster recovery control information of the cloud host from the control terminal when the cloud host is running in user mode; the disaster recovery control information includes multiple disaster recovery control conditions and disaster recovery control modes corresponding to each disaster recovery control condition; the status information acquisition module is used to acquire system status information of the cloud host in response to the cloud host switching from user mode to kernel mode; the condition filtering module is used to filter target control conditions that match the system status information from the disaster recovery control conditions, and determine the target control mode corresponding to the target control conditions from the disaster recovery control modes; the disaster recovery control module is used to perform disaster recovery control on the cloud host according to the target control mode.

[0014] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0015] When the cloud host is running in user mode, disaster recovery control information of the cloud host is obtained from the control terminal. The disaster recovery control information includes multiple disaster recovery control conditions and a disaster recovery control mode corresponding to each disaster recovery control condition. In response to the cloud host switching from user mode to kernel mode, system status information of the cloud host is obtained. Among the disaster recovery control conditions, target control conditions that match the system status information are filtered, and the target control mode corresponding to the target control condition is determined from among the disaster recovery control modes. Disaster recovery control is performed on the cloud host according to the target control mode.

[0016] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0017] When the cloud host is running in user mode, disaster recovery control information of the cloud host is obtained from the control terminal. The disaster recovery control information includes multiple disaster recovery control conditions and a disaster recovery control mode corresponding to each disaster recovery control condition. In response to the cloud host switching from user mode to kernel mode, system status information of the cloud host is obtained. Among the disaster recovery control conditions, target control conditions that match the system status information are filtered, and the target control mode corresponding to the target control condition is determined from among the disaster recovery control modes. Disaster recovery control is performed on the cloud host according to the target control mode.

[0018] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0019] When the cloud host is running in user mode, disaster recovery control information of the cloud host is obtained from the control terminal. The disaster recovery control information includes multiple disaster recovery control conditions and a disaster recovery control mode corresponding to each disaster recovery control condition. In response to the cloud host switching from user mode to kernel mode, system status information of the cloud host is obtained. Among the disaster recovery control conditions, target control conditions that match the system status information are filtered, and the target control mode corresponding to the target control condition is determined from among the disaster recovery control modes. Disaster recovery control is performed on the cloud host according to the target control mode.

[0020] The aforementioned disaster recovery control methods, devices, computer equipment, storage media, and computer program products, when the cloud host is running in user mode, obtain disaster recovery control information from the control terminal. This information includes multiple disaster recovery control conditions and corresponding disaster recovery control modes for each condition, facilitating subsequent disaster recovery control of the cloud host in kernel mode and improving efficiency. In response to a cloud host switching from user mode to kernel mode, the system status information of the cloud host is obtained. Among the various disaster recovery control conditions, target control conditions matching the system status information are selected, and the target control mode corresponding to the target control condition is determined from among the various disaster recovery control modes. Using this method, when the cloud host is in kernel mode, disaster recovery control is performed according to the target control mode, achieving rapid kernel-level disaster recovery control and thus improving efficiency.

[0021] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0022] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the embodiments described below. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0023] Figure 1 is an application environment diagram of a disaster recovery control method in one embodiment;

[0024] Figure 2 is a flowchart illustrating a disaster recovery control method in one embodiment;

[0025] Figure 3 is a flowchart illustrating a method for determining target control conditions in one embodiment;

[0026] Figure 4 is a flowchart illustrating the disaster recovery control method in another embodiment;

[0027] Figure 5 is a flowchart illustrating a method for disaster recovery control of cloud hosts based on eBPF in one embodiment;

[0028] Figure 6 shows an example of an eBPF cloud host disaster recovery control system.

[0029] Figure 7 is a flowchart illustrating a disaster recovery switching method in one embodiment;

[0030] Figure 8 is a structural block diagram of a disaster recovery control device in one embodiment;

[0031] Figure 9 is an internal structure diagram of a computer device in one embodiment. Detailed Implementation

[0032] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0033] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0034] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0035] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0036] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0037] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0038] In the description of the embodiments of this application, the technical terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing the embodiments of this application and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the embodiments of this application.

[0039] In the description of the embodiments of this application, unless otherwise expressly specified and limited, the technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection, an electrical connection, or a communication connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. For those skilled in the art, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0040] The disaster recovery control method provided in this application embodiment can be applied to the application environment shown in Figure 1. The control terminal 102 communicates with the cloud host 104 via a network. The data storage system can store the data that the cloud host 104 needs to process. The data storage system can be integrated on the cloud host 104, or it can be placed in the cloud or on another network server.

[0041] When cloud host 104 is running in user mode, it obtains disaster recovery control information from control terminal 102. This information includes multiple disaster recovery control conditions and their corresponding disaster recovery control modes. In response to a runtime state switch event (from user mode to kernel mode), cloud host 104 obtains its system status information. From the various disaster recovery control conditions, cloud host 104 filters for target control conditions that match the system status information and determines the target control mode from the various disaster recovery control modes. Cloud host 104 then performs disaster recovery control according to the target control mode.

[0042] The control terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. The cloud host 104 can be implemented using a dedicated server or a server cluster consisting of multiple servers.

[0043] In one embodiment, as shown in Figure 2, a disaster recovery control method is provided. Taking the application of this method to cloud host 104 in Figure 1 as an example, the method includes:

[0044] S202: When the cloud host is running in user mode, obtain the disaster recovery control information of the cloud host from the control terminal.

[0045] A cloud server can be a cloud computing service based on virtualization technology. A cloud server can simulate multiple independent virtual hardware systems on a physical server using virtualization technology, each of which can run different guest operating systems. The resources of a cloud server include computing components such as CPU, memory, and disk; these components are virtualized and not real physical electronic components.

[0046] A cloud server can also be a type of physical hardware that a cloud computing server relies on. Specifically, cloud computing services can be services that depend on physical hardware such as servers, storage devices, and network devices.

[0047] User mode can represent a kernel state, and kernel states can include both user mode and kernel mode. For example, in an operating system, kernel mode and user mode are two different CPU operating modes, corresponding to different privilege levels and resource access capabilities. User mode is the state in which user programs run in the operating system. In this state, programs have restricted access to system resources and cannot directly use system resources or change the CPU's operating state. Kernel mode, on the other hand, is the state in which the operating system kernel runs, possessing full access rights and able to perform critical tasks such as memory management and hardware operations.

[0048] Specifically, when a cloud server is in user mode, programs have limited access to system resources and cannot directly use them or change the CPU's operating state. When a cloud server is in kernel mode, programs have full access to system resources, can perform critical tasks such as memory management and hardware operations, and run at a faster speed on the kernel-mode CPU.

[0049] A control terminal can refer to a terminal that communicates with a cloud host and is used to send disaster recovery control information to the cloud host. A control terminal can be a terminal that interacts with the computing services represented by the cloud host, a terminal that has a communication connection with a server on which the cloud host depends, or a terminal or server corresponding to the management platform of the server on which the cloud host depends.

[0050] Disaster recovery control information can include multiple disaster recovery control conditions and the corresponding disaster recovery control modes for each disaster recovery control condition.

[0051] Disaster recovery control conditions are specific conditions configured for disaster recovery information. These conditions may include preset network status of the cloud host, preset ports for the cloud host, or a CPU load rate greater than a preset value for the cloud host. Disaster recovery control modes can represent the specific control measures applied to the cloud host. For example, a disaster recovery control model could be traffic control, capacity expansion, or traffic migration.

[0052] Specifically, a cloud server can determine its own operating status. When the cloud server is in user mode, it can obtain its own disaster recovery control information from the control terminal. When the cloud server is in kernel mode, it does not obtain disaster recovery control information from the control terminal.

[0053] In one embodiment, the cloud host can directly obtain its disaster recovery control information from the control terminal. The cloud host can also obtain disaster recovery control information from other cloud hosts. For example, cloud host A can obtain its disaster recovery control information 'a' from the control terminal. Cloud host A can also obtain its disaster recovery control information 'a' from another cloud host B, which can effectively alleviate the communication pressure between the control terminal and the cloud hosts.

[0054] In one embodiment, the cloud host can also obtain updated disaster recovery control information from the control terminal in response to a disaster recovery control update event when the cloud host is running in user mode.

[0055] In one embodiment, the cloud host can also obtain multiple preset control information configured for the cloud host from the control terminal. The cloud host can verify each preset control information and determine the preset control information that passes the verification as disaster recovery control information.

[0056] S204 is used in response to a cloud host switching from user mode to kernel mode to obtain system status information of the cloud host.

[0057] Among them, runtime state transition events can represent the triggering events for state transitions of cloud hosts. Triggering events can be system call events, interrupt events, and exception events. For example, a system call event can represent an event where a user-mode process actively requests to switch to kernel mode. Through system calls, user programs can request services from the operating system, such as file operations and memory management. Interrupt and exception events can represent events corresponding to hardware device interrupts or program exceptions.

[0058] System status information can represent the status of the operating system in a cloud host. Specifically, status information can include process names, CPU load, memory load, network load, and port status, etc.

[0059] Taking Linux as an example, process names represent the names of programs running on a cloud server and can be used to monitor and manage system performance and resources. In Linux, various commands can be used to find process names, such as ps, top, htop, lsof, and pgrep. For example, the ps -A command can list all running processes.

[0060] CPU load represents the workload of a cloud server's central processing unit (CPU) when processing tasks. It's usually expressed as a percentage, reflecting the relative number of tasks the CPU is currently handling compared to the maximum number of tasks the system can process simultaneously. The `uptime` command can be used to view the system's average load. The `top` command can be used to monitor Linux system resource usage in real time.

[0061] Memory load represents the memory usage in a cloud server's system. The `top` command can be used to monitor Linux system processes and resource usage, including memory usage, in real time.

[0062] Network load represents a cloud server's ability to transmit and process data packets over a network, and is typically used to measure the busyness and performance of a network or system. Specific network load can be assessed by examining metrics such as network interface traffic and packet loss rate.

[0063] Port status indicates the current working state of a cloud server's network ports, such as listening, established, time-wait, and close-wait. In Linux systems, commands like netstat, lsof, and ss can be used to view port status. For example, netstat -ntlp can display the status of all TCP ports.

[0064] Specifically, a cloud host can respond to a runtime state switch event when it switches from user mode to kernel mode, thus determining that the cloud host is running in kernel mode. When the cloud host is running in kernel mode, it can obtain system status information.

[0065] Specifically, the cloud server can obtain a set of commands configured for acquiring system status information. Based on the commands in the command set, the cloud server obtains the status information corresponding to each command. The cloud server then combines all the status information to obtain the overall system status information.

[0066] In one embodiment, the cloud host can update the versions of each instruction in the instruction set to obtain new instructions for each instruction. If each new instruction passes the instruction compliance check, the cloud host can obtain the corresponding status information for each instruction. By combining all the status information, the cloud host can obtain the system status information.

[0067] S206. Among the various disaster recovery control conditions, select the target control conditions that match the system status information, and determine the target control mode corresponding to the target control conditions from among the various disaster recovery control modes.

[0068] Here, the target control condition can represent the disaster recovery control condition that matches the system state information. The target control mode represents the disaster recovery control mode corresponding to the target control mode. A target control condition can correspond to one or more target control modes.

[0069] Specifically, when the target control conditions correspond to one target control mode, the cloud host can perform disaster recovery control according to the target control mode. When the target control conditions correspond to multiple target control modes, the cloud host can filter through the target control modes to obtain the final control mode. The cloud host then performs disaster recovery control according to the final control mode.

[0070] Specifically, system status information can include the parameter values ​​of multiple preset parameters. For each disaster recovery control condition, the cloud host can determine the condition parameters characterizing that condition. If multiple preset parameters include the condition parameters corresponding to the disaster recovery control condition, the cloud host can determine that disaster recovery control condition as a candidate control condition. For each candidate control condition, if the parameter range of the condition parameters in the candidate control condition includes the parameter value of the preset parameter corresponding to the condition parameter, the cloud host can determine the candidate control condition as the target control condition matching the system status information.

[0071] Specifically, the cloud host can also respond to the control condition selection event, filter the target control condition that matches the system status information from among the various disaster recovery control conditions, and determine the target control mode corresponding to the target control condition from among the various disaster recovery control modes.

[0072] S208 performs disaster recovery control on cloud hosts according to the target control mode.

[0073] Among them, the target control mode can include at least traffic control, traffic migration, and capacity expansion.

[0074] Traffic forwarding refers to the process of forwarding a data flow in a network from one node to another. This is typically used to implement data exchange or routing functions between different nodes in a network. For example, in a cloud environment, traffic forwarding can be achieved by configuring public network routing rules to ensure that data packets correctly reach their destination host. Furthermore, traffic forwarding can also be implemented through port mapping, such as forwarding traffic from a public IP address's port to the corresponding port on an internal network host.

[0075] Traffic migration refers to transferring business traffic between different hosts or clusters to achieve load balancing or failover. For example, when scaling up a database, traffic can be redirected to the new database by switching the routing rules of the database sharding, thus achieving a smooth scaling process.

[0076] Scaling up can refer to increasing the hardware or software resources of a cloud server to meet the needs of applications. Scaling up can be divided into two types: one is overall scaling of a single machine, including adding CPU, memory, storage devices, etc.; the other is scaling up specific components, such as expanding memory, disk, or CPU. Scaling strategies can dynamically adjust resources according to business needs to address issues such as access latency and resource overload. For example, increasing bandwidth or adjusting bandwidth size to cope with traffic changes.

[0077] Specifically, the cloud host corresponding to each target control mode can obtain the expected recovery time for that target control mode. The cloud host can then perform disaster recovery control according to the target control mode with the shortest expected recovery time.

[0078] Specifically, the cloud server can also respond to a control mode selection event and determine the selected control mode from among various target control modes. The cloud server then performs disaster recovery control according to the selected control mode. Disaster recovery control can include traffic control, traffic migration, and capacity expansion.

[0079] For example, a cloud server can also respond to a control mode selection event to determine traffic control in traffic control, traffic migration, and scaling. The cloud server performs traffic control on itself according to the selected control mode.

[0080] In the aforementioned disaster recovery control method, when the cloud host is running in user mode, disaster recovery control information is obtained from the control terminal. This information includes multiple disaster recovery control conditions and their corresponding disaster recovery control modes. This facilitates subsequent disaster recovery control in kernel mode, improving efficiency. In response to the cloud host switching from user mode to kernel mode, system status information is obtained. Among the various disaster recovery control conditions, target control conditions matching the system status information are selected, and the target control mode corresponding to the target control condition is determined from the various disaster recovery control modes. Using this method, when the cloud host is in kernel mode, it performs disaster recovery control according to the target control mode, achieving rapid kernel-level disaster recovery control and thus improving efficiency.

[0081] In one embodiment, as shown in the flowchart of the method for determining target control conditions in FIG3, the system state information includes the parameter values ​​of multiple preset parameters, and S206 includes S302 to S306, wherein:

[0082] S302, for each disaster recovery control condition, determine the condition parameters used to characterize the disaster recovery control condition.

[0083] The preset parameters can be, for example, process name, CPU load, memory load, network load, and port status. The parameter values ​​can be specific values ​​of the preset parameters. For example, process name XX, CPU load 70%, etc.

[0084] Conditional parameters can be specific parameters that characterize disaster recovery control conditions. For example, specific parameters can be process name, CPU load, memory load, network load, and port status.

[0085] The parameters characterizing different disaster recovery control conditions can vary. For example, the parameters for disaster recovery control condition 1 are CPU load and memory load. Another example is the parameters for disaster recovery control condition 2, which are port number and process name.

[0086] S304 If multiple preset parameters include condition parameters corresponding to disaster recovery control conditions, then the disaster recovery control conditions will be determined as candidate control conditions.

[0087] Among them, the multiple preset parameters include the condition parameters corresponding to the disaster recovery control conditions, which can indicate that the disaster recovery control conditions are applicable to judging the parameter values ​​corresponding to the multiple preset parameters.

[0088] Candidate control conditions can represent disaster recovery control conditions whose condition parameters all correspond to preset parameters. For example, if multiple preset parameters include preset parameter a and preset parameter b, a disaster recovery control condition that contains only at least one of condition parameters a and b can be identified as a candidate control condition. If a disaster recovery control condition also includes condition parameter c, then that disaster recovery control condition is not a candidate control condition.

[0089] S306, for each candidate control condition, if the parameter range of the condition parameter in the candidate control condition includes the parameter value of the preset parameter corresponding to the condition parameter, then the candidate control condition is determined as the target control condition that matches the system state information.

[0090] The parameter range can represent the specific range of parameter values ​​configured for a conditional parameter. For example, if the conditional parameter is CPU load rate, the parameter range could be a CPU load rate greater than 70%. Similarly, if the conditional parameter is memory load rate, the parameter range could be a memory load rate greater than 80%.

[0091] The parameter range of the conditional parameter includes the parameter value of the preset parameter corresponding to the conditional parameter, which can represent a CPU load rate greater than 70% including a CPU load rate of 72%.

[0092] It should be noted that if the preset parameters are CPU load rate and memory load rate, a candidate control condition will only contain the parameter range corresponding to CPU load rate. If the parameter range includes the parameter value of CPU load rate, then the candidate control condition is the target control condition that matches the system status information.

[0093] In this embodiment, for each disaster recovery control condition, a condition parameter is determined to characterize the disaster recovery control condition. If multiple preset parameters include the condition parameter corresponding to the disaster recovery control condition, then the disaster recovery control condition is determined as a candidate control condition. For each candidate control condition, if the parameter range of the condition parameter in the candidate control condition includes the parameter value of the preset parameter corresponding to the condition parameter, then the candidate control condition is determined as the target control condition matching the system state information. First, each disaster recovery control condition is screened according to the preset parameters and condition parameters to obtain candidate control conditions. Then, each candidate control condition is screened according to the parameter range of the condition parameters and the parameter value of the preset parameters to obtain the target control condition matching the system state information. This reduces hardware resource consumption and improves the efficiency of subsequent disaster recovery control.

[0094] In one embodiment, there are multiple target control modes. Disaster recovery control of the cloud host is performed according to the target control modes, including: obtaining the expected recovery time for each target control mode; and performing disaster recovery control on the cloud host according to the target control mode with the shortest expected recovery time.

[0095] The preset recovery time represents the time required for a cloud server to eliminate disaster recovery risks. Specifically, it represents the time interval between the occurrence of a disaster recovery alarm on the cloud server and the time when the alarm is cleared. More specifically, the expected recovery time represents the control duration for disaster recovery control of the cloud server using the target control mode.

[0096] Specifically, the cloud server can obtain the recovery time target configured for the cloud server, as well as the expected recovery time for each target control mode. The cloud server can then filter for target recovery times shorter than the target recovery time from among the expected recovery times. If there are multiple target recovery times, the cloud server can randomly determine the target control mode corresponding to each target recovery time and perform disaster recovery control on the cloud server according to that target control mode.

[0097] In one embodiment, if the duration of each expected recovery time is longer than the recovery time target, the cloud host can be controlled for disaster recovery according to the target control mode with the shortest expected recovery time.

[0098] The Recovery Time Objective (RTO) can be represented as the maximum tolerable time required for a system to return to normal operation after a failure or disaster. For example, if the RTO is set to one hour, then the business can tolerate a certain degree of downtime within this timeframe; exceeding this period may lead to adverse consequences.

[0099] In one embodiment, the cloud host can predict the recovery time of each target control mode to obtain the expected recovery time of each target control mode. Specifically, for each target control mode, the cloud host can determine the average historical recovery time of the target control mode as the expected recovery time of the target control mode.

[0100] In this embodiment, there are multiple target control modes. The expected recovery time of each target control mode is obtained. The cloud host is controlled according to the target control mode with the shortest expected recovery time, so as to ensure that the time for disaster recovery control of the cloud host is minimized and improve the efficiency of disaster recovery control.

[0101] In one embodiment, the disaster recovery control method further includes: loading disaster recovery control information into kernel-mode storage space when the cloud host is running in user mode. The disaster recovery control method also includes: reading disaster recovery control information from storage space when the cloud host is running in kernel mode.

[0102] Kernel-mode memory can represent higher address spaces. For example, in a 64-bit system, the kernel-mode address space is located in the high address range. This is beneficial for improving the speed of resource access to that memory space.

[0103] Specifically, cloud hosts can use eBPF technology to load disaster recovery control information into the kernel-mode storage space.

[0104] eBPF (Extended Berkeley Packet Filter) is a user-space program that runs within the Linux kernel. It is compiled into eBPF bytecode using LLVM / Clang and the bytecode instructions are passed to the kernel via the bpf() system call. eBPF programs can execute when specific events are triggered, and data exchange between kernel space and user space can be achieved through eBPF maps.

[0105] In one embodiment, the cloud host runs a user-space program that uses the system call bpf() to pass bytecode instructions into the kernel's storage space, thereby loading disaster recovery control information into the kernel's storage space.

[0106] Specifically, when the cloud host is running in user mode, it can obtain disaster recovery control information from the control terminal. This information includes multiple disaster recovery control conditions and their corresponding disaster recovery control modes. The cloud host can load this information into the kernel-mode storage space. In response to a switch from user mode to kernel mode, the cloud host can obtain its system status information. When running in kernel mode, the cloud host can read the disaster recovery control information from the storage space. It can filter for target control conditions that match the system status information from among the various disaster recovery control conditions and determine the target control mode from among the various disaster recovery control modes. Finally, the cloud host can perform disaster recovery control according to the target control mode.

[0107] In this embodiment, when the cloud host is running in user mode, disaster recovery control information is loaded into the kernel-mode storage space. The kernel-mode storage space stores the disaster recovery control information. When the cloud host is running in kernel mode, the disaster recovery control information is read from the storage space. Since the kernel-mode storage space realizes data exchange between the kernel space and the user space through eBPF mapping (maps), the data exchange rate is improved, thereby improving the efficiency of disaster recovery control.

[0108] In one embodiment, obtaining disaster recovery control information of a cloud host from a control terminal includes: obtaining multiple preset control information configured for the cloud host from the control terminal; performing control condition verification on each preset control information; determining the preset control information that passes the control condition verification as the first control information; performing control mode verification on each preset control information; determining the preset control information that passes the control mode verification as the second control information; and combining the first control information and the second control information to obtain the disaster recovery control information of the cloud host.

[0109] The preset control information can represent control information for personalized configurations of cloud servers. Preset control information may include preset control conditions and preset control modes.

[0110] Preset control conditions can represent specific conditions configured for disaster recovery information, such as preset conditions for the network status of cloud hosts, preset ports for cloud hosts, and preset CPU load rates for cloud hosts.

[0111] Preset control modes can represent the specific control methods applied to cloud servers. For example, disaster recovery control models can include traffic control, capacity expansion, and traffic migration.

[0112] Control condition verification refers to verifying the preset control conditions against the preset control information. The first control information represents the preset control information that has passed the preset control conditions.

[0113] Control mode verification refers to verifying the preset control mode against preset control information. Second control information refers to the preset control information obtained through the preset control mode.

[0114] Specifically, the cloud host can perform integrity verification on the preset control conditions in the preset control information to obtain the control condition verification result. For example, the cloud host performs semantic analysis on the preset control conditions in the preset control information to obtain the semantic analysis result. If the semantic analysis result shows that the semantic completeness is greater than the preset completeness, the cloud host can determine the preset control information as the first control information. Similarly, the cloud host can also perform integrity verification on the preset control modes in the preset control information to obtain the second control information, which will not be elaborated upon here.

[0115] In one embodiment, after obtaining the first control information and the second control information, there are multiple ways to integrate the first control information and the second control information. The cloud host can determine the same control information in the first control information and the second control information as the cloud host's disaster recovery control information. The cloud host can also determine the first control information and the second control information simultaneously as the cloud host's disaster recovery control information. The cloud host can also respond to a selection event for disaster recovery control information and determine the cloud host's disaster recovery control information from the first control information and the second control information.

[0116] In this embodiment, multiple preset control information configured for the cloud host are obtained from the control terminal. The control conditions of each preset control information are verified, and the preset control information that passes the control condition verification is determined as the first control information. The control mode of each preset control information is verified, and the preset control information that passes the control mode verification is determined as the second control information. By combining the first control information and the second control information, the disaster recovery control information of the cloud host is obtained. The integrity of the control conditions and control modes can be verified, which improves the accuracy of the disaster recovery control information.

[0117] In one embodiment, referring to Figure 2 and Figure 4, the disaster recovery control method further includes:

[0118] S402, when the cloud host is running in user mode, responds to disaster recovery control update events and obtains updated disaster recovery control scripts and disaster recovery control information from the control terminal.

[0119] Among them, the disaster recovery control update event can represent the event triggered by the control terminal.

[0120] Updated disaster recovery control information can be newly configured control information. Updated disaster recovery control scripts can be newly issued scripts used to obtain disaster recovery control information. Scripts can be shell scripts. Shell scripts are scripting programming languages ​​used for automating tasks and batch processing, primarily running on Unix and Linux operating systems. They execute commands through an interpreter, can call system commands, programming statements, and tools, and can process files and data. Shell scripts typically have the .sh file extension, are simple and intuitive to write, and are suitable for automating tasks, batch processing, system administration, and configuration.

[0121] Specifically, the cloud server can respond to disaster recovery control update events while running in user space, and obtain updated disaster recovery control scripts and disaster recovery control information from the control terminal.

[0122] For example, a cloud host can, while running in user space, respond to a disaster recovery control update event and obtain the updated shell script and the updated disaster recovery control information from the control terminal.

[0123] S204 includes S404, which calls the disaster recovery control script to obtain the system status information of the cloud host.

[0124] The disaster recovery control script can be a shell script or other types of script.

[0125] Specifically, in response to the cloud host switching from user mode to kernel mode, the cloud host calls the disaster recovery control script to obtain the system status information of the cloud host.

[0126] S206 includes S406, which selects target control conditions that match the system status information from multiple disaster recovery control conditions contained in the updated disaster recovery control information.

[0127] Specifically, cloud servers can select target control conditions that match system status information from multiple disaster recovery control conditions included in the updated disaster recovery control information.

[0128] In one embodiment, the system status information includes parameter values ​​for multiple preset parameters. The cloud host can determine the multiple disaster recovery control conditions contained in the updated disaster recovery control information as new disaster recovery control conditions. For each new disaster recovery control condition, the cloud host can determine condition parameters to characterize it. If the multiple preset parameters include the condition parameters corresponding to the new disaster recovery control condition, the cloud host can determine the new disaster recovery control condition as a candidate control condition. For each candidate control condition, if the parameter range of the condition parameters in the candidate control condition includes the parameter value of the preset parameter corresponding to the condition parameter, the cloud host can determine the candidate control condition as the target control condition matching the system status information.

[0129] In this embodiment, when the cloud host is running in user mode, in response to the disaster recovery control update event, the updated disaster recovery control script and disaster recovery control information are obtained from the control terminal. The disaster recovery control script is called to obtain the system status information of the cloud host. From the multiple disaster recovery control conditions included in the updated disaster recovery control information, the target control conditions that match the system status information are selected. This allows each disaster recovery control information to be updated, which helps to keep the disaster recovery control information version in the latest version and improves the efficiency and accuracy of disaster recovery control.

[0130] In cloud computing environments, especially when facing large-scale host deployments, traditional disaster recovery monitoring, policy configuration, and response switching methods are inefficient. Therefore, in one embodiment, as shown in Figure 5, a method for disaster recovery control of cloud hosts based on eBPF is provided, including:

[0131] S502, when the cloud host is running in user mode, obtains multiple preset control information for the cloud host configuration from the control terminal.

[0132] For example, this method can be applied to the eBPF cloud host disaster recovery control system shown in Figure 6.

[0133] CFF-Manager can be a cloud-based web management platform used for eBPF program upgrades and management. Specifically, it's used for: 1. Distributing eBPF program code to cloud hosts, issuing commands to upgrade, compile, and load the eBPF code into the kernel; 2. Managing policies for different cloud hosts, distributing and updating policy configurations. CFF-Update can be an upgrade module, specifically a shell script, used to receive shell commands from the cloud management platform for program upgrades and policy configuration updates. CFF-Strategy can be a policy module, used to update policy configurations received from the cloud and simultaneously distribute these updates to the kernel module, storing them in the eBPF Map. CFF-Event can be an event matching module, used to perform policy matching based on collected data to determine if failover is necessary. CFF-Failover can be a disaster recovery control module, used to judge policies received from events; if policy matching is satisfied, failover operations are performed via eBPF, including traffic transfer and cloud host migration. The remaining kernel basic modules are used for: 1. Loading user-space eBPF code into kernel space for execution; 2. Monitoring system resources specified in the policy configuration, including (process name, port number, CPU load, memory load, network load); 3. Collecting data and pushing events to user space for specified resources.

[0134] As exemplified, Figure 7 illustrates the disaster recovery failover method, which includes: 1. A cloud management platform manages different cloud hosts; 2. The CFF-Update script module compiles and loads the code into the kernel module at the system level; simultaneously, it loads the policy configuration code issued by the cloud into the kernel; 3. The cloud management platform can issue different policy configurations based on different cloud host configurations and scenarios. For example, cloud host A needs to monitor whether an application with the process name "Java" exists; cloud host B needs to monitor whether port 22 is alive; cloud host C needs to monitor CPU and memory load, etc.; 4. The application loaded by the eBPF mechanism continuously monitors the data and status of the operating system in kernel mode. If the policy matching conditions are met, the matching result is transmitted through CFF-Event; 5. CFF-Failover will perform different disaster recovery failover operations based on different events; for example, it can transfer all network traffic of this machine to machine B; it can also notify the cloud host to migrate or expand to ensure resource availability.

[0135] This disaster recovery switching method features: 1. Kernel-level fast disaster recovery switching, reducing RTO time; 2. Cloud + kernel-level configuration, enabling personalized policy configuration for different cloud host models; 3. Kernel-based disaster recovery policies and switching, reducing system resource consumption and user impact.

[0136] S504, perform control condition verification on each preset control information, and determine the preset control information that passes the control condition verification as the first control information.

[0137] S506, perform control mode verification on each preset control information, and determine the preset control information that passes the control mode verification as the second control information.

[0138] S508 integrates the first and second control information to obtain the disaster recovery control information of the cloud host.

[0139] The disaster recovery control information includes multiple disaster recovery control conditions and the corresponding disaster recovery control modes for each disaster recovery control condition.

[0140] When the cloud host is running in user mode, the S510 responds to disaster recovery control update events and obtains updated disaster recovery control scripts and disaster recovery control information from the control terminal.

[0141] S512 loads disaster recovery control information into the kernel-mode storage space when the cloud host is running in user mode.

[0142] S514 responds to the cloud host's running state switch event from user mode to kernel mode and obtains the cloud host's system status information.

[0143] S516 calls the disaster recovery control script to obtain the system status information of the cloud host.

[0144] The S518 reads disaster recovery control information from storage space when the cloud host is running in kernel mode.

[0145] S520: For each disaster recovery control condition, determine the condition parameters used to characterize the disaster recovery control condition.

[0146] The system status information includes the parameter values ​​of several preset parameters.

[0147] S522, if multiple preset parameters include condition parameters corresponding to disaster recovery control conditions, then the disaster recovery control conditions will be determined as candidate control conditions.

[0148] S524, for each candidate control condition, if the parameter range of the condition parameter in the candidate control condition includes the parameter value of the preset parameter corresponding to the condition parameter, then the candidate control condition is determined as the target control condition that matches the system state information.

[0149] S526: From the multiple disaster recovery control conditions contained in the updated disaster recovery control information, select the target control conditions that match the system status information.

[0150] S528, determine the target control mode corresponding to the target control conditions from each disaster recovery control mode.

[0151] S530, obtain the expected recovery time for each target control mode.

[0152] S532 performs disaster recovery control on cloud servers according to the target control mode of the shortest expected recovery time.

[0153] When the cloud host is running in user mode, S534 responds to disaster recovery control update events and obtains updated disaster recovery control scripts and disaster recovery control information from the control terminal.

[0154] S536 calls the disaster recovery control script to obtain the system status information of the cloud host.

[0155] S538: From the multiple disaster recovery control conditions contained in the updated disaster recovery control information, select the target control conditions that match the system status information.

[0156] In this embodiment, firstly, when the cloud host is running in user mode, disaster recovery control information of the cloud host is obtained from the control terminal. This information includes multiple disaster recovery control conditions and corresponding disaster recovery control modes for each condition, facilitating subsequent disaster recovery control of the cloud host in kernel mode and improving efficiency. In response to a cloud host switching from user mode to kernel mode, system status information of the cloud host is obtained. Among the various disaster recovery control conditions, target control conditions matching the system status information are selected, and the target control mode corresponding to the target control condition is determined from the various disaster recovery control modes. Using this method, when the cloud host is in kernel mode, disaster recovery control is performed according to the target control mode, achieving rapid kernel-level disaster recovery control and thus improving efficiency.

[0157] Secondly, it combines a multi-level architecture design of cloud management + user space + kernel space to support the rapid disaster recovery switching capability of cloud hosts; personalized policy configuration based on eBPF kernel Map storage: supports different disaster recovery condition policies for different cloud hosts; and a rapid disaster recovery switching program flow developed based on eBPF: reduces system resource consumption, reduces the impact on user resources, and has the ability to achieve rapid RTO.

[0158] Thirdly, it allows for personalized kernel-level policy configuration on different host models. By performing data monitoring, policy judgment, and switchover execution at the kernel level, this embodiment ensures rapid response in the event of a disaster recovery incident, significantly reduces the recovery time objective (RTO), and thus improves the stability and reliability of the entire system.

[0159] Fourthly, 1. Real-time monitoring: Utilizing eBPF technology, system calls, network traffic, and key performance indicators are monitored and collected in real-time at the kernel level. This real-time data can quickly identify potential faults and performance bottlenecks, providing solid data support for disaster recovery switchover decisions. 2. Personalized and dynamically adjusted disaster recovery strategies: This method allows for the configuration and adjustment of personalized disaster recovery strategies for different cloud host models. This dynamic adjustment of strategies is based on real-time monitoring data, ensuring that the disaster recovery strategy always matches current business needs and system status. 3. Automated disaster recovery control: When the system detects a fault or reaches preset switchover conditions, the disaster recovery switchover operation can be automatically triggered in real-time and quickly through eBPF kernel operations, without manual intervention, thereby improving fault response efficiency and accuracy. 4. Fast response time: Through the efficient ability to perform fault switching in the kernel, this method significantly shortens the disaster recovery switchover response time, ensuring that the system can recover quickly when a fault occurs, guaranteeing business continuity, and significantly reducing the recovery time objective (RTO). 5. Reduced resource consumption and intrusiveness: This method runs in kernel mode, which has less impact on the security and resources of the operating system and reduces intrusiveness to the user environment. This allows the method to improve system monitoring and fault handling capabilities while minimizing the system load.

[0160] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0161] Based on the same inventive concept, this application also provides a disaster recovery control device for implementing the disaster recovery control method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more disaster recovery control device embodiments provided below can be found in the limitations of the disaster recovery control method described above, and will not be repeated here.

[0162] In one embodiment, as shown in FIG8, a disaster recovery control device is provided, including: a control information acquisition module 802, a status information acquisition module 804, a condition filtering module 806, and a disaster recovery control module 808, wherein:

[0163] The control information acquisition module 802 is used to acquire the disaster recovery control information of the cloud host from the control terminal when the cloud host is running in user mode. The disaster recovery control information includes multiple disaster recovery control conditions and the disaster recovery control mode corresponding to each disaster recovery control condition.

[0164] The status information acquisition module 804 is used to acquire the system status information of the cloud host in response to the cloud host switching from user mode to kernel mode running state switching event;

[0165] The condition filtering module 806 is used to filter target control conditions that match the system status information from various disaster recovery control conditions, and to determine the target control mode corresponding to the target control conditions from various disaster recovery control modes.

[0166] The disaster recovery control module 808 is used to perform disaster recovery control on cloud hosts according to the target control mode.

[0167] In one embodiment, the system status information includes the parameter values ​​of multiple preset parameters; the condition filtering module 806 is further configured to determine, for each disaster recovery control condition, a condition parameter characterizing the disaster recovery control condition; if the multiple preset parameters include the condition parameter corresponding to the disaster recovery control condition, then the disaster recovery control condition is determined as a candidate control condition; for each candidate control condition, if the parameter range of the condition parameter in the candidate control condition includes the parameter value of the preset parameter corresponding to the condition parameter, then the candidate control condition is determined as the target control condition matching the system status information.

[0168] In one embodiment, there are multiple target control modes; the disaster recovery control module 808 is also used to obtain the expected recovery time of each target control mode; and to perform disaster recovery control on the cloud host according to the target control mode with the shortest expected recovery time.

[0169] In one embodiment, the disaster recovery control device further includes: a loading module, used to load disaster recovery control information into the kernel-mode storage space when the cloud host is running in user mode; and a reading module, used to read disaster recovery control information from the storage space when the cloud host is running in kernel mode.

[0170] In one embodiment, the control information acquisition module 802 is further configured to acquire multiple preset control information configured for the cloud host from the control terminal; perform control condition verification on each preset control information, and determine the preset control information that passes the control condition verification as the first control information; perform control mode verification on each preset control information, and determine the preset control information that passes the control mode verification as the second control information; and combine the first control information and the second control information to obtain the disaster recovery control information of the cloud host.

[0171] In one embodiment, the disaster recovery control device further includes: an update module, configured to, in response to a disaster recovery control update event, obtain updated disaster recovery control scripts and disaster recovery control information from the control terminal when the cloud host is running in user mode; a status information acquisition module 804, further configured to call the disaster recovery control script to obtain system status information of the cloud host; and a condition filtering module 806, further configured to filter target control conditions that match the system status information from multiple disaster recovery control conditions included in the updated disaster recovery control information.

[0172] Each module in the aforementioned disaster recovery control device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0173] In one embodiment, a computer device, which may be a server, is provided, and its internal structure is shown in Figure 9. The computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores disaster recovery control information. The I / O interfaces are used for information exchange between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a disaster recovery control method.

[0174] Those skilled in the art will understand that the structure shown in Figure 9 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 to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or may combine certain components, or may have different component arrangements.

[0175] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method steps.

[0176] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described method steps.

[0177] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the above-described method steps.

[0178] Those skilled in the art will understand 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 can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0179] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0180] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

[0181] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of the claims and specification of this application. In particular, as long as there is no structural conflict, the various technical features mentioned in the embodiments can be combined in any way. This application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. A disaster control method, wherein, Applied to cloud servers, the method includes: When the cloud host is running in user mode, the disaster recovery control information of the cloud host is obtained from the control terminal; the disaster recovery control information includes multiple disaster recovery control conditions and the disaster recovery control mode corresponding to each of the disaster recovery control conditions. In response to the cloud host switching from user mode to kernel mode, obtain the system status information of the cloud host; Among the disaster recovery control conditions, target control conditions that match the system status information are selected, and the target control mode corresponding to the target control condition is determined from each of the disaster recovery control modes. Disaster recovery control is performed on the cloud host according to the target control mode.

2. The method of claim 1, wherein, The system status information includes the parameter values ​​of multiple preset parameters; The step of filtering target control conditions that match the system status information from among the disaster recovery control conditions includes: For each of the disaster recovery control conditions, determine the condition parameters used to characterize the disaster recovery control conditions; If the plurality of preset parameters include the condition parameter corresponding to the disaster recovery control condition, then the disaster recovery control condition is determined as a candidate control condition. For each candidate control condition, if the parameter range of the condition parameter in the candidate control condition includes the parameter value of the preset parameter corresponding to the condition parameter, then the candidate control condition is determined as the target control condition that matches the system state information.

3. The method of claim 1, wherein, The number of target control modes is multiple, and the disaster recovery control of the cloud host according to the target control modes includes: Obtain the expected recovery time for each of the target control modes; Disaster recovery control is performed on the cloud host according to the target control mode with the shortest expected recovery time.

4. The method of claim 1, wherein, The method further includes: When the cloud host is running in user mode, the disaster recovery control information is loaded into the kernel mode storage space; The method further includes: When the cloud host is running in kernel mode, the disaster recovery control information is read from the storage space.

5. The method of claim 1, wherein, The step of obtaining the disaster recovery control information of the cloud host from the control terminal includes: Obtain multiple preset control information configured for the cloud host from the control terminal; Each of the preset control information is verified for control conditions, and the preset control information that passes the control condition verification is determined as the first control information. Perform control mode verification on each of the preset control information, and determine the preset control information that passes the control mode verification as the second control information; By combining the first control information and the second control information, the disaster recovery control information of the cloud host is obtained.

6. The method of any one of claims 1 to 5, wherein, The method further includes: When the cloud host is running in user mode, in response to a disaster recovery control update event, it obtains the updated disaster recovery control script and disaster recovery control information from the control terminal. The process of obtaining the system status information of the cloud host includes: The disaster recovery control script is invoked to obtain the system status information of the cloud host; The step of filtering target control conditions that match the system status information from among the disaster recovery control conditions includes: From the multiple disaster recovery control conditions included in the updated disaster recovery control information, target control conditions that match the system status information are selected.

7. A disaster tolerance control apparatus, wherein, Applied to cloud servers, the device includes: The control information acquisition module is used to acquire the disaster recovery control information of the cloud host from the control terminal when the cloud host is running in user mode; the disaster recovery control information includes multiple disaster recovery control conditions and the disaster recovery control mode corresponding to each of the disaster recovery control conditions. The status information acquisition module is used to acquire the system status information of the cloud host in response to the running state switching event of the cloud host switching from the user mode to the kernel mode; The condition filtering module is used to filter target control conditions that match the system status information from each of the disaster recovery control conditions, and to determine the target control mode corresponding to the target control condition from each of the disaster recovery control modes. The disaster recovery control module is used to perform disaster recovery control on the cloud host according to the target control mode.

8. A computer device comprising a memory and a processor, the memory storing a computer program, wherein, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer readable storage medium having stored thereon a computer program, wherein, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program, wherein, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images