Host machine fault disaster recovery method and device, electronic equipment and storage medium

Abstract

The invention provides a host machine fault disaster recovery method and device, electronic equipment and a storage medium, and the method comprises the steps: determining whether each host machine has a fault risk or not according to the condition of receiving network communication information sent by each host machine; if the host machine with the fault risk exists, stopping receiving the network communication information sent by the host machine with the fault risk, and isolating storage resources of the host machine with the fault risk; and selecting a host machine from the host machines without the fault risk, and reconstructing a virtual machine running on the host machine with the fault risk on the selected host machine. Therefore, on one hand, potential faults of the host machine can be found as soon as possible; on the other hand, the site is reserved through isolation, subsequent detection of software and hardware problems of the host machine with the fault risk is facilitated, and a virtual machine on the host machine with the fault risk is reconstructed on other healthy host machines, so that the service interruption time of the host machine is shortened.

Description

Technical Field

[0001] One or more embodiments of the present disclosure relate to the field of cloud computing technology, and in particular to a method, apparatus, electronic device, and storage medium for host machine fault disaster recovery. Background Art

[0002] Existing cloud computing systems typically include a large number of host machines, each of which provides the necessary hardware and software infrastructure and supporting environment for virtual machines to run, thereby supporting the efficient execution of large-scale computing tasks. However, in actual operation, the current host machine failure recovery mechanism has certain limitations.

[0003] On the one hand, the corresponding recovery process will only be triggered when there is an obvious failure in the host machine's management network or storage network, or even when the host machine completely crashes. This mechanism makes it difficult to timely detect and handle potential failures or non-fatal anomalies in the host machine, which can easily cause problems to accumulate and expand.

[0004] On the other hand, the current host recovery process requires powering off the host to further detect the fault type. However, when the host is powered off, the software environment, including the operating system and service processes, is also shut down, making it impossible to diagnose software-level issues while the host is actually running. Therefore, this method is only suitable for diagnosing certain hardware faults. It lacks effective detection methods for software-level issues, such as operating system anomalies and service process crashes, resulting in some critical faults being unable to be identified and addressed in a timely manner. Summary of the Invention

[0005] In order to address the timeliness and applicability limitations of existing host machine fault disaster recovery mechanisms, the present disclosure provides a host machine fault disaster recovery method, the method comprising: Determine whether each host machine has a failure risk based on the network communication information received from each host machine; If there is a host machine with a risk of failure, stop receiving network communication information sent by the host machine with a risk of failure, and isolate the storage resources of the host machine with a risk of failure; A host machine is selected from the host machines without failure risk, and the virtual machine running on the host machine with failure risk is rebuilt on the selected host machine.

[0006] Optionally, determining whether each host machine has a failure risk based on the received network communication information sent by each host machine includes: If the network communication information sent by the target host machine among the host machines indicates that the target host machine has a failure risk, it is determined that the target host machine has a failure risk.

[0007] Optionally, the method further includes: If no network communication information sent by the target host machine exists among the host machines, indicating that the target host machine has a failure risk, detecting whether there is a host machine among the host machines that has not sent network communication information within a preset time period; If there is a host machine among the host machines that has not sent network communication information within a preset period of time, it is determined that the host machine that has not sent network communication information within the preset period of time has a failure risk.

[0008] Optionally, the method further includes: Based on the network communication information received from each host machine, a virtual machine routing information table is generated; Receive a request from any host machine for obtaining a routing information table of its associated virtual machines, the request carrying virtual private cloud identifiers of all virtual machines on the current host machine; According to the virtual private cloud identifier, the associated virtual machine routing information table of any host machine is searched in the virtual machine routing information table, and the searched associated virtual machine routing information table is returned to the any host machine.

[0009] Optionally, each host machine mounts the same storage resource pool, and stopping receiving network communication information sent by the host machine with a failure risk and isolating the storage resources of the host machine with a failure risk includes: Stop receiving network communication information sent from the host machine with the failure risk, and no longer query the virtual machine routing information table associated with the host machine with the failure risk; The storage resource pool is notified to disconnect the storage connection with the host machine with the failure risk, and the storage access status of the host machine with the failure risk is marked as abnormal.

[0010] Optionally, before determining whether each host machine has a failure risk based on the received network communication information sent by each host machine, the method further includes: Receive a virtual machine configuration file of a virtual machine to be created, wherein the virtual machine configuration file includes a network identifier, a storage identifier, and resource specification attributes of the virtual machine to be created; According to the virtual machine configuration file, a host machine is selected from each host machine to newly create the virtual machine to be created.

[0011] Optionally, selecting a host machine from host machines without failure risk, and rebuilding the virtual machine running on the host machine with failure risk on the selected host machine includes: Determining, based on the virtual machine configuration file, a network identifier, a storage resource identifier, and resource specification attributes of the virtual machine running on the host machine with the failure risk; A host machine is selected from the host machines without failure risk, and the virtual machine running on the host machine with failure risk is rebuilt on the selected host machine according to the virtual machine configuration file.

[0012] The present disclosure also provides a host machine fault disaster recovery device, the device comprising: a determination unit, configured to determine whether each host machine has a failure risk based on the network communication information received from each host machine; an isolation unit, configured to, if a host machine with a risk of failure exists, isolate the network resources and storage resources of the host machine with the risk of failure, and stop receiving network communication information sent by the host machine with the risk of failure; The reconstruction unit is configured to select a host machine from the host machines without failure risks, and to rebuild the virtual machine running on the host machine with failure risks on the host machine.

[0013] The present disclosure further provides an electronic device, comprising a communication interface, a processor, a memory, and a bus, wherein the communication interface, the processor, and the memory are interconnected via the bus; The memory stores machine-readable instructions, and the processor executes the above method by calling the machine-readable instructions.

[0014] The present disclosure also provides a machine-readable storage medium, wherein the machine-readable storage medium stores machine-readable instructions, and when the machine-readable instructions are called and executed by a processor, the above method is implemented.

[0015] Through the embodiments of the present disclosure, first, based on the situation of receiving network communication information sent by each host machine, it is determined whether each host machine contains a failure risk; further, if there is a host machine containing a failure risk, the network communication information sent by the host machine containing the failure risk is stopped from being received, and the storage resources of the host machine containing the failure risk are isolated; finally, a host machine is selected from the host machines that do not contain a failure risk, and the virtual machine running on the host machine containing the failure risk is rebuilt on the selected host machine.

[0016] Through the above method, the technical solution disclosed in the present invention can, on the one hand, realize active detection of whether each host machine contains fault risks, so as to avoid knowing the fault risks of the host machine only when the host machine crashes or the host machine's network fails, thereby discovering the potential faults of the host machine as soon as possible; on the other hand, after detecting that the host machine contains fault risks, there is no need to power off the host machine, but instead stop receiving network communication information sent by the host machine with fault risks, and isolate the storage resources of the host machine with fault risks, so as to retain the first scene, facilitate subsequent detection of software and hardware problems of the host machine with fault risks, and finally rebuild the virtual machine on the host machine with fault risks on other healthy host machines, thereby reducing the host machine service interruption time. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0018] Figure 1 This is a flowchart of a host machine fault disaster recovery method shown in an exemplary embodiment; Figure 2 This is a flowchart of a host machine failure risk detection method shown in an exemplary embodiment; Figure 3 This is a schematic diagram of a host machine failure disaster recovery method according to an exemplary embodiment; Figure 4 is a hardware structure diagram of an electronic device shown in an exemplary embodiment; Figure 5 The block diagram of a host machine fault disaster recovery device is shown in an exemplary embodiment. DETAILED DESCRIPTION

[0019] In order to enable those skilled in the art to better understand the technical solutions of the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present disclosure.

[0020] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this disclosure. In some other embodiments, the method may include more or fewer steps than those described in this disclosure. In addition, a single step described in this disclosure may be broken down into multiple steps for description in other embodiments; and multiple steps described in this disclosure may be combined into a single step for description in other embodiments.

[0021] Existing cloud computing systems typically include a large number of host machines, each of which provides the necessary hardware and software infrastructure and supporting environment for virtual machines to run, thereby supporting the efficient execution of large-scale computing tasks. However, in actual operation, the current host machine failure recovery mechanism has certain limitations.

[0022] On the one hand, the corresponding recovery process will only be triggered when there is an obvious failure in the host machine's management network or storage network, or even when the host machine completely crashes. This mechanism makes it difficult to timely detect and handle potential failures or non-fatal anomalies in the host machine, which can easily cause problems to accumulate and expand.

[0023] On the other hand, the current host recovery process requires powering off the host to further detect the fault type. However, when the host is powered off, the software environment, including the operating system and service processes, is also shut down, making it impossible to diagnose software-level issues while the host is actually running. Therefore, this method is only suitable for diagnosing certain hardware faults. It lacks effective detection methods for software-level issues, such as operating system anomalies and service process crashes, resulting in some critical faults being unable to be identified and addressed in a timely manner.

[0024] In view of this, the present disclosure aims to propose a technical solution for timely detecting potential faults of a host machine and preserving the scene to facilitate subsequent comprehensive troubleshooting of the host machine faults in terms of software and hardware.

[0025] This technical solution first determines whether each host machine has a failure risk based on the situation of receiving network communication information sent by each host machine; further, if there is a host machine with a failure risk, it stops receiving network communication information sent by the host machine with the failure risk and isolates the storage resources of the host machine with the failure risk; finally, it selects a host machine from the host machines without failure risk and rebuilds the virtual machine running on the host machine with failure risk on the selected host machine.

[0026] For example, Aggregator S receives health status information from the health check modules of hosts H1 and H2. Hosts H1 and H2 each have their own health check modules deployed. These modules regularly perform comprehensive system self-checks, including key metrics such as hardware sensor status, operating system logs, and management and service network connectivity. These modules periodically transmit this health status information to Aggregator S. Aggregator S analyzes and processes the received information. If it detects anomalies in the health status information repeatedly transmitted by host H1, such as hardware alarms or network link failures, Aggregator S determines that host H1 is at risk of failure. If host H2 continues to transmit normal operating status, it is confirmed that it is not at risk of failure. To prevent the potential problem from spreading and affecting the stability of the entire cloud computing platform, Aggregator S immediately implements isolation measures, stopping receiving health status information and any other data interaction from host H1's health check module. Aggregator S then notifies the distributed storage module to suspend all storage services for host H1, thereby cutting off host H1's access to storage resources. Finally, to ensure service continuity, after completing the above isolation operation, the aggregator S will select a host machine that is identified as healthy (such as host machine H2) to rebuild the virtual machine VM1 originally running on host machine H1, and obtain VM1' running on host machine H2.

[0027] Through the above method, the technical solution disclosed in the present invention can, on the one hand, realize active detection of whether each host machine contains fault risks, so as to avoid knowing the fault risks of the host machine only when the host machine crashes or the host machine's network fails, thereby discovering the potential faults of the host machine as soon as possible; on the other hand, after detecting that the host machine contains fault risks, there is no need to power off the host machine, but instead stop receiving network communication information sent by the host machine with fault risks, and isolate the storage resources of the host machine with fault risks, so as to retain the first scene, facilitate subsequent detection of software and hardware problems of the host machine with fault risks, and finally rebuild the virtual machine on the host machine with fault risks on other healthy host machines, thereby reducing the host machine service interruption time.

[0028] The present disclosure is described below through specific embodiments in combination with specific application scenarios.

[0029] See Figure 1 , Figure 1 This is a flowchart of a host machine fault disaster recovery method according to an exemplary embodiment. The method may perform the following steps: Step 102: Determine whether each host machine has a failure risk based on the network communication information received from each host machine.

[0030] For example, aggregator S receives health status information from the health check modules of host machines H1 and H2. Host machines H1 and H2 each have their own health check modules deployed. These modules regularly perform comprehensive system self-checks, including key indicators such as hardware sensor status, operating system logs, and management network and business network connectivity, and periodically send this health status information to aggregator S. Aggregator S analyzes and processes the received information and discovers anomalies in the health status information sent repeatedly by host machine H1, such as hardware alarms or network link failures. Aggregator S then determines that host machine H1 is at risk of failure. If host machine H2 continues to send normal operating status, it is confirmed that it does not have a failure risk.

[0031] The aggregator S is a management node in the cloud computing platform, responsible for monitoring and managing the health status and resource allocation of host machines. It assesses the health of host machines based on network communication information received from them and triggers appropriate disaster recovery mechanisms when a failure is detected. A host machine is a physical server that runs virtual machines and provides them with the necessary computing, storage, and network resources. A virtual machine is a virtualized instance running on a host machine, with an independent operating system and application environment.

[0032] The health check module is a software component deployed on each host machine, responsible for regularly sending health status information to the aggregator. The health check module determines whether there are hardware alarms based on the hardware sensor data read from the baseboard management controller chip of each host machine, determines whether there are software alarms by scanning the incremental information of the operating system log of the current host machine, and determines whether there are network link status alarms by checking the link connectivity between the current host machine and the network edge node to which it is connected. When the aggregator S receives health status information, it will first verify whether the information comes from a legitimate host machine. This process may involve checking the host machine's identity identifier. If the current host machine is not within the normal management range or the current host machine is isolated by the system, the verification fails, otherwise the verification is successful.

[0033] In one embodiment shown, determining whether each host machine contains a failure risk based on the situation of receiving network communication information sent by each host machine includes: if there is network communication information sent by a target host machine among the host machines, indicating that the target host machine contains a failure risk, then determining that the target host machine contains a failure risk.

[0034] For example, consider two hosts, H1 and H2, on a cloud computing platform. Each host has a health check module, X, deployed on it. The health check module regularly performs comprehensive system self-checks, including key metrics such as hardware sensor status, operating system logs, and network connectivity. It periodically sends this health status information to an aggregator, S. During one check, host H1 reported a hardware sensor temperature that was too high, while host H2 reported normal operation. After receiving this information, aggregator S analyzed and processed it, confirming that host H1 was at risk of failure, while host H2 was not.

[0035] The host machine deploys not only the health check module X but also other related network communication components (such as the network forwarding module Y). The host machine also interacts with the aggregator S through the network forwarding module Y to transmit network communication information such as virtual machine network traffic information and virtual machine routing table update requests. The aggregator can also determine whether the host machine is at risk of failure based on whether the network communication information sent by the host machine's network forwarding module is normal.

[0036] In one embodiment shown, the method also includes: if there is no network communication information sent by the target host machine among the host machines, indicating that the target host machine has a failure risk, then detecting whether there is a host machine among the host machines that has not sent network communication information within a preset time period; if there is a host machine among the host machines that has not sent network communication information within a preset time period, then determining that the host machine that has not sent network communication information within the preset time period has a failure risk.

[0037] For example, see Figure 2 , Figure 2 FIG. 1 is a flow chart showing a method for detecting host failure risk according to an exemplary embodiment. Figure 2As shown, host machine H1 periodically performs self-checks and reports its health status information to aggregator S. Based on the health status information regularly reported by host machine H1, aggregator S determines whether host machine H1 is at risk of failure. If the health status information regularly reported by host machine H1 indicates that host machine H1 is at risk of failure, aggregator S stops receiving network communication information from host machine H1, isolates host machine H1's storage resources, and then rebuilds the virtual machine running on the host machine at risk of failure on a host machine without risk of failure. If the health status information regularly reported by host machine H1 is not received, aggregator S determines whether the information has timed out (also known as a heartbeat timeout) to verify whether host machine H1 is actually operating properly. If not, aggregator S determines that host machine H1 is not at risk of failure. Otherwise, aggregator S determines that host machine H1 is at risk of failure and stops receiving network communication information from host machine H1, isolates host machine H1's storage resources, and then rebuilds the virtual machine running on the host machine at risk of failure on a host machine without risk of failure.

[0038] The host machine's health status information is sent to aggregator S by the built-in health check module. In addition to detecting whether the health check module X of hosts H1 and H2 sends health status information within a preset duration (e.g., 30 seconds), aggregator S can also detect whether other network communication components of hosts H1 and H2 (such as network forwarding module Y) have interacted with aggregator S within the preset duration. If no network communication information is received from other network communication components of hosts H1 and H2 interacting with aggregator S within the preset duration, hosts H1 and H2 can be considered to have a fault risk. This disclosure does not limit the content of the health status information or the type of network communication information.

[0039] Step 104: If there is a host machine with a risk of failure, stop receiving network communication information sent by the host machine with a risk of failure, and isolate the storage resources of the host machine with a risk of failure.

[0040] For example, in order to prevent potential problems from spreading and affecting the stability of the entire cloud computing platform, the aggregator S immediately takes isolation measures and stops receiving health status information and any other forms of data interaction sent by the health check module of the host machine H1. Then, the aggregator S will notify the distributed storage module to suspend providing any storage services to the host machine H1 to cut off the host machine H1's access to storage resources.

[0041] Among them, when the aggregator S detects that the host machine H1 has a failure risk, the first task is to prevent the failure from affecting the entire cloud computing platform. Because if the host machine H1 has a failure risk (such as hardware failure or software crash), continuing to allow it to access storage resources and network resources may cause data corruption, service interruption or other unforeseen problems. Therefore, first cutting off access rights to these resources can minimize potential risks. In addition, if the host machine H1 has a failure risk, the network communication information it sends may no longer be reliable or even erroneous. Continuing to receive this information may mislead the aggregator S and lead to incorrect decisions. In addition, stopping all data interactions with the host machine with a failure risk can reduce the burden on the aggregator and avoid wasting resources due to processing invalid or erroneous information. The distributed storage pool is a shared storage resource pool provided by multiple physical servers for use by all host machines. In this embodiment, in addition to using distributed storage, other storage methods can also be adopted. The present disclosure does not limit the specific storage type.

[0042] Step 106: Select a host machine from the host machines without failure risk, and rebuild the virtual machine running on the host machine with failure risk on the selected host machine.

[0043] For example, to ensure that service continuity is not affected, after isolating the network resources and storage resources of the host machine with failure risks and stopping receiving network communication information sent by the host machine with failure risks, the aggregator S will select a host machine that is identified as healthy (such as host machine H2) to rebuild the virtual machine VM1 originally running on host machine H1, and obtain VM1' running on host machine H2.

[0044] When selecting a host, the aggregator S can consider a single health factor or multiple factors, including the host's current load and resource utilization. Specifically, the aggregator S can evaluate the utilization of the host's CPU, memory, and storage resources, and select healthy hosts with sufficient resources and low load. Furthermore, the aggregator S can select hosts based on predefined priority rules, for example, prioritizing hosts in the same data center or rack as the faulty host to reduce network latency.

[0045] When rebuilding a VM, the aggregator S uses its pre-stored VM configuration file, which contains all the VM's attributes, such as network identifiers, storage resource identifiers, and resource specifications. This information enables the aggregator S to accurately rebuild the VM on the new host, ensuring that its network and storage configurations are consistent with the original VM.

[0046] In one embodiment shown, the method also includes: generating a virtual machine routing information table based on the network communication information received from each host machine; receiving an acquisition request for its own associated virtual machine routing information table sent by any host machine, the acquisition request carrying the virtual private cloud identifier of all virtual machines on the current host machine; based on the virtual private cloud identifier, querying the associated virtual machine routing information table of any host machine in the virtual machine routing information table, and returning the queried associated virtual machine routing information table to any host machine.

[0047] For example, there are two hosts H1 and H2 on a cloud computing platform. Host H1 runs virtual machine VM1, and host H2 runs virtual machine VM2. Aggregator S receives health status information and virtual machine routing information from hosts H1 and H2, retains only the virtual machine routing information for hosts in good health, and aggregates the information to generate a global virtual machine routing information table. For example, the global virtual machine routing information table records the network identifier of VM1 as 192.168.1.1 and the network identifier of VM2 as 192.168.1.2. Packets sent to 192.168.1.1 are forwarded to host H1, and packets sent to 192.168.1.2 are forwarded to host H2. If host H2 needs to update its locally cached virtual machine routing information to ensure it can correctly forward network traffic between virtual machines, it sends a request to aggregator S. This request contains the virtual private cloud identifiers of all virtual machines on host H2. After receiving the request, aggregator S searches the virtual machine routing table for the virtual machine routing information related to host H2 based on the virtual private cloud identifier carried in the request, and returns the query result to host H2. In this way, host H2 can forward network traffic based on the latest virtual machine routing information.

[0048] A virtual private cloud (VPC) refers to a logically isolated virtual network space created for users within a public or private cloud environment. Each VPC has independent subnets, routing tables, security policies, and other configurations. Network isolation is implemented between different VPCs by default. A VPC identifier is a string or number that uniquely identifies a VPC and is typically automatically generated and assigned to each VPC by the system. In a virtualized network environment, multiple tenants may deploy independent VPCs. When a host initiates a request to obtain a virtual machine routing information table, it must include the VPC identifier. This limits the query scope to only retrieve virtual machine routing information related to the VPC in which it resides, avoiding unnecessary data transmission and potential network conflicts. In this embodiment, the aggregator also stores the virtual machine routing information table and other related configuration information for the virtual machines running on the host. Based on the virtual machine routing information sent by the host and the determined host health information, the aggregator aggregates and generates a virtual machine routing information table. Upon receiving a request to obtain virtual machine routing information from the host, the aggregator returns the associated virtual machine routing information table to the host based on the aggregated virtual machine routing information table. This process does not require the linkage of third-party components to detect the scope of host disaster recovery and refresh the virtual machine routing information. The aggregator itself can generate a virtual machine routing information table based on the virtual machine routing information sent by the host and the determined host health information, thereby efficiently achieving rapid convergence of the network topology and enhancing the robustness of the cloud computing platform.

[0049] In one embodiment shown, each host machine mounts the same storage resource pool, and stopping receiving network communication information sent by the host machine with failure risk and isolating the storage resources of the host machine with failure risk includes: stopping receiving network communication information sent from the host machine with failure risk and no longer querying the virtual machine routing information table associated with the host machine with failure risk; notifying the storage resource pool to disconnect the storage connection with the host machine with failure risk, and marking the storage access status of the host machine with failure risk as abnormal.

[0050] For example, there are two host machines H1 and H2 in the cloud computing platform, both of which are mounted with the same distributed storage resource pool. The health check modules on the hosts H1 and H2 regularly perform comprehensive system self-checks and periodically report health status information to the aggregator S. If the aggregator S detects that the host H1 has a failure risk (such as a hardware alarm or network link failure), in order to prevent the potential problem from spreading and affecting the stability of the entire cloud computing platform, the aggregator S immediately takes isolation measures and stops receiving all network communication information from the host H1, including health status information and any other form of data interaction, and the aggregator S no longer provides any virtual machine routing information query service for the host H1. Then, the aggregator S notifies the distributed storage resource pool to disconnect all storage connections with the host H1 to prevent it from continuing to access or modify storage resources, and marks the storage access status of the host H1 as abnormal in the storage resource pool so that other system components can identify and avoid using the relevant resources of the host.

[0051] Among them, when the aggregator detects that a host machine has a failure risk, it can prohibit the host machine from accessing the storage resources by updating the access control list of the storage resource pool. This can be achieved through API calls or command line tools. A status table can be maintained inside the storage resource pool to record the storage access status of each host machine. Once a host machine is found to have a failure risk, its status is immediately marked as abnormal to alert other system components. In this embodiment, in addition to distributed storage, other storage methods can also be adopted. The present disclosure does not limit the specific storage type. Through the above-mentioned isolation measures, problems of hosts with failure risks can be effectively prevented from spreading to the entire cloud computing platform, ensuring the normal operation of other hosts and virtual machines.

[0052] In one embodiment shown, if there is a host machine with a failure risk, the network resources and storage resources of the host machine with the failure risk are isolated, and before receiving the network communication information sent by the host machine with the failure risk is stopped, the method also includes: receiving a virtual machine configuration file of the virtual machine to be created, the virtual machine configuration file including the network identifier, storage identifier and resource specification attributes of the virtual machine to be created; and selecting a host machine from each host machine to create the virtual machine to be created according to the virtual machine configuration file.

[0053] For example, there are two hosts, H1 and H2, in a cloud computing platform. A user requests the creation of a new virtual machine, VM2, and provides a virtual machine configuration file. This configuration file contains VM2's network identifier (e.g., IP address 192.168.1.2), storage identifier (e.g., vol-0123abcd), and resource specifications (e.g., 2 CPU cores, 4 GB memory). To ensure that the new virtual machine, VM2, can run in a healthy environment, the aggregator S selects host H2, which has more abundant resources, as the creation target based on the resource usage and health status of hosts H1 and H2. On host H2, the aggregator assigns VM2 a network identifier (192.168.1.2), storage identifier (vol-0123abcd), and resource specifications (2 CPU cores, 4 GB memory) based on the virtual machine configuration file. It then starts VM2 and ensures that it can operate normally and access the required network and storage resources.

[0054] Among them, after the virtual machine is created, the host machine supporting the virtual machine may subsequently face health risks again, so the aggregator needs to monitor its health status based on the network communication information sent by the host machine, and after determining that the host machine contains failure risks, transfer the virtual machines supported by the host machine to other hosts.

[0055] In one embodiment shown, the method of selecting a host machine from among host machines that do not have a failure risk and rebuilding the virtual machine running on the host machine with a failure risk on the selected host machine includes: determining the network identifier, storage resource identifier, and resource specification attributes of the virtual machine running on the host machine with a failure risk based on the virtual machine configuration file; selecting a host machine from among host machines that do not have a failure risk and rebuilding the virtual machine running on the host machine with a failure risk based on the virtual machine configuration file on the selected host machine.

[0056] For example, see Figure 3 , Figure 3 FIG. 1 is a schematic diagram showing a host machine failure disaster recovery process according to an exemplary embodiment. Figure 3 As shown in the figure, the cloud computing platform includes an aggregator S, two host machines H1 and H2, and a distributed storage pool V. Virtual machine VM1 is running on host machine H1, and virtual machine VM2 is running on host machine H2. Aggregator S pre-stores the virtual machine configuration files of virtual machines VM1 and VM2. Based on the virtual machine configuration files, the network identifier, storage resource identifier, and resource specification attributes of the virtual machines can be known.

[0057] Aggregator S includes a health aggregation module A, a host isolation module B, a virtual machine daemon module C, a virtual machine configuration list L0, a host state list L1, and a virtual machine routing information table L2. After creating a new virtual machine, the host sends its virtual machine configuration list and health status information to Aggregator S. Aggregator S receives and maintains virtual machine configuration list L0 and host state list L1, and generates and maintains virtual machine routing information table L2 based on virtual machine configuration list L0 and host state list L1. Health aggregation module A on Aggregator S determines whether the host has a failure risk based on the health status information reported by the host's health check module X. If the host is determined to be at risk of failure, host isolation module B on Aggregator S isolates the host H1. After scanning the VM configuration list L0 and the VM routing table L2 to identify hosts at risk of failure, the VM daemon C on aggregator S selects a non-failure-risk host H2 from the host status list L1. On H2, the affected VM VM1' is rebuilt from the original host H1 using VM1's configuration file. Network resources (IP address 192.168.1.1), storage resources (VM1-disk), and compute resources (2 CPU cores, 4GB of memory) are allocated to the rebuilt VM VM1'. VM VM1' is then started, ensuring normal operation and access to required network and storage resources. Finally, the VM routing table L2 is updated based on the VM routing information and health status information sent by H2.

[0058] The virtual machine configuration file is a document that describes the resources and attributes required for a virtual machine to run. It includes network identifiers (such as IP addresses and virtual private cloud identifiers), storage resource identifiers (such as disk image IDs), and resource specification attributes (such as the number of CPU cores and memory size). It guides the creation and management of virtual machines on the host. When a user requests to create or migrate a virtual machine, the aggregator receives the virtual machine configuration file from the cloud computing platform and parses it, extracting the various parameters of the virtual machine. This information is used to determine the virtual machine's location on the network, the required storage space, and the computing resource requirements.

[0059] Corresponding to the above-mentioned embodiment of the host machine fault disaster recovery method, the present disclosure also provides an embodiment of a host machine fault disaster recovery device.

[0060] See Figure 4 , Figure 4This is a hardware structure diagram of an electronic device shown in an exemplary embodiment. At the hardware level, the device includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a non-volatile memory 410, and of course may also include other required hardware. One or more embodiments of the present disclosure can be implemented based on software, such as the processor 402 reading the corresponding computer program from the non-volatile memory 410 into the memory 408 and then running it. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0061] See Figure 5 , Figure 5 This is a block diagram of a host machine fault disaster recovery device shown in an exemplary embodiment. The host machine fault disaster recovery device 500 can be applied to Figure 4 The electronic device shown in the figure is used to implement the technical solution of the present disclosure. The device includes: A determination unit 502 is configured to determine whether each host machine has a failure risk based on the network communication information received from each host machine; The isolation unit 504 is configured to, if a host machine with a risk of failure exists, stop receiving network communication information sent by the host machine with a risk of failure, and isolate the storage resources of the host machine with a risk of failure; The reconstruction unit 506 is configured to select a host machine from the host machines without failure risks, and to rebuild the virtual machine running on the host machine with failure risks on the host machine.

[0062] In some embodiments, determining whether each host machine has a failure risk based on the network communication information received from each host machine includes: If the network communication information sent by the target host machine among the host machines indicates that the target host machine has a failure risk, it is determined that the target host machine has a failure risk.

[0063] In some embodiments, the apparatus further comprises: a detection unit configured to detect whether there is a host machine among the host machines that has not sent network communication information within a preset period of time if no network communication information sent by the target host machine among the host machines indicates that the target host machine has a failure risk; The second determining unit is configured to determine that a host machine that has not sent network communication information within a preset time period has a failure risk if there is a host machine among the host machines that has not sent network communication information within a preset time period.

[0064] In some embodiments, the apparatus further comprises: The aggregation unit is used to generate a virtual machine routing information table based on the network communication information received from each host machine; A first receiving unit is configured to receive a request from any host machine for obtaining a routing information table of a virtual machine associated with the host machine, wherein the request carries virtual private cloud identifiers of all virtual machines on the current host machine; The query unit is configured to query the virtual machine routing information table for the associated virtual machine routing information table of any host machine according to the virtual private cloud identifier, and return the queried associated virtual machine routing information table to the any host machine.

[0065] In some embodiments, each host machine is mounted on the same storage resource pool, and stopping receiving network communication information sent by the host machine with a failure risk and isolating the storage resources of the host machine with a failure risk includes: Stop receiving network communication information sent from the host machine with the failure risk, and no longer query the virtual machine routing information table associated with the host machine with the failure risk; The storage resource pool is notified to disconnect the storage connection with the host machine with the failure risk, and the storage access status of the host machine with the failure risk is marked as abnormal.

[0066] In some embodiments, the apparatus further comprises: A second receiving unit is configured to receive a virtual machine configuration file of a virtual machine to be created, wherein the virtual machine configuration file includes a network identifier, a storage identifier, and resource specification attributes of the virtual machine to be created; The new creation unit is configured to select a host machine from among the host machines to create the virtual machine to be created according to the virtual machine configuration file.

[0067] In some embodiments, selecting a host machine from host machines without failure risk and rebuilding the virtual machine running on the host machine with failure risk on the selected host machine includes: Determining, based on the virtual machine configuration file, a network identifier, a storage resource identifier, and resource specification attributes of the virtual machine running on the host machine with the failure risk; A host machine is selected from the host machines without failure risk, and the virtual machine running on the host machine with failure risk is rebuilt on the selected host machine according to the virtual machine configuration file.

[0068] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0069] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the disclosed solution. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0070] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

[0071] In a typical configuration, a computer includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0072] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0073] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can be implemented using any method or technology to store information. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0074] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation entrances shall be provided for users to choose to authorize or refuse.

[0075] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0076] The foregoing description describes specific embodiments of the present disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0077] The terms used in one or more embodiments of the present disclosure are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of the present disclosure. The singular forms "a," "the," and "the" used in one or more embodiments of the present disclosure and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0078] It should be understood that although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of the present disclosure, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of one or more embodiments of the present disclosure, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0079] The above description is merely a preferred embodiment of one or more embodiments of the present disclosure and is not intended to limit one or more embodiments of the present disclosure. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of the present disclosure shall be included in the scope of protection of one or more embodiments of the present disclosure.

Claims

1. A host machine fault disaster recovery method, characterized in that: The method comprises: Determine whether each host machine has a failure risk based on the network communication information received from each host machine; If there is a host machine with a risk of failure, stop receiving network communication information sent by the host machine with a risk of failure, and isolate the storage resources of the host machine with a risk of failure; A host machine is selected from the host machines without failure risk, and the virtual machine running on the host machine with failure risk is rebuilt on the selected host machine.

2. The method according to claim 1, characterized in that The step of determining whether each host machine has a failure risk based on the network communication information received from each host machine includes: If the network communication information sent by the target host machine among the host machines indicates that the target host machine has a failure risk, it is determined that the target host machine has a failure risk.

3. The method according to claim 2, characterized in that The method further comprises: If no network communication information sent by the target host machine exists among the host machines, indicating that the target host machine has a failure risk, detecting whether there is a host machine among the host machines that has not sent network communication information within a preset time period; If there is a host machine among the host machines that has not sent network communication information within a preset period of time, it is determined that the host machine that has not sent network communication information within the preset period of time has a failure risk.

4. The method according to claim 1, wherein The method further comprises: Based on the network communication information received from each host machine, a virtual machine routing information table is generated; Receive a request from any host machine for obtaining a routing information table of its associated virtual machines, the request carrying virtual private cloud identifiers of all virtual machines on the current host machine; According to the virtual private cloud identifier, the associated virtual machine routing information table of any host machine is searched in the virtual machine routing information table, and the searched associated virtual machine routing information table is returned to the any host machine.

5. The method according to claim 4, characterized in that Each host machine mounts the same storage resource pool, and stopping receiving network communication information sent by the host machine with a failure risk and isolating the storage resources of the host machine with a failure risk includes: Stop receiving network communication information sent from the host machine with the failure risk, and no longer query the virtual machine routing information table associated with the host machine with the failure risk; The storage resource pool is notified to disconnect the storage connection with the host machine with the failure risk, and the storage access status of the host machine with the failure risk is marked as abnormal.

6. The method according to claim 1, characterized in that Before determining whether each host machine has a failure risk based on the network communication information received from each host machine, the method further includes: Receive a virtual machine configuration file of a virtual machine to be created, wherein the virtual machine configuration file includes a network identifier, a storage identifier, and resource specification attributes of the virtual machine to be created; According to the virtual machine configuration file, a host machine is selected from each host machine to newly create the virtual machine to be created.

7. The method according to claim 6, characterized in that The step of selecting a host machine from host machines without failure risks and rebuilding the virtual machine running on the host machine with failure risks on the selected host machine includes: Determining, based on the virtual machine configuration file, a network identifier, a storage resource identifier, and resource specification attributes of the virtual machine running on the host machine with the failure risk; A host machine is selected from the host machines without failure risk, and the virtual machine running on the host machine with failure risk is rebuilt on the selected host machine according to the virtual machine configuration file.

8. A host machine fault disaster recovery device, characterized in that: The device comprises: a determination unit, configured to determine whether each host machine has a failure risk based on the network communication information received from each host machine; an isolation unit, configured to, if a host machine with a risk of failure exists, isolate the network resources and storage resources of the host machine with the risk of failure, and stop receiving network communication information sent by the host machine with the risk of failure; The reconstruction unit is configured to select a host machine from the host machines without failure risks, and to rebuild the virtual machine running on the host machine with failure risks on the host machine.

9. An electronic device, characterized in that: It includes a communication interface, a processor, a memory and a bus, wherein the communication interface, the processor and the memory are interconnected via the bus; The memory stores machine-readable instructions, and the processor executes the method according to any one of claims 1 to 7 by calling the machine-readable instructions.

10. A machine-readable storage medium, characterized in that The machine-readable storage medium stores machine-readable instructions, and when the machine-readable instructions are called and executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images