Fault processing method and device, electronic equipment and storage medium

Abstract

The application provides a fault processing method and device, electronic equipment and storage medium, relates to the technical field of cloud computing, and the method comprises the following steps: determining that a first host in a CKE cluster fails according to host alarm information and / or node alarm information from the CKE cluster; determining that a target node of a control type is deployed on the first host; if the target node is deployed on the first host, determining a second host from the hosts in the CKE cluster; and migrating the target node from the first host to the second host. Through the above method, when the first host of the cloud platform fails, the nodes deployed in the host can be migrated to the available nodes of other hosts without manual intervention, the efficiency of restoring the normal operation of the nodes is improved, the time for interrupting the business scenario caused by the host failure is reduced, and therefore the use experience of the user is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud computing, and particularly relates to a fault processing method and device, an electronic device and a storage medium. BACKGROUND

[0002] With the rapid development of cloud computing technology, more and more users choose to build a cloud platform to provide better services to the outside.

[0003] In order to improve the computing performance of the cloud platform, a container technology is usually used to deploy different business processes in different business scenarios in different nodes of different hosts of the cloud platform. For a cloud platform with high complexity, if a node of a host fails, multiple business scenarios will be in an invalid state, and manual intervention is required for fault processing, resulting in a long fault repair time and poor user experience. SUMMARY

[0004] In view of the problem that manual intervention is required in the current fault processing, resulting in a long fault repair time, the present application provides a fault processing method and device, an electronic device and a storage medium, which can improve the efficiency of fault repair.

[0005] In a first aspect, the present application provides a fault processing method applied to a cloud platform, wherein the cloud platform comprises a monitoring host and a plurality of CKE clusters, each CKE cluster comprising a plurality of hosts, and each host being deployed with at least one node of at least one type, the method being applied to the monitoring host, and the method comprising:

[0006] determining that a first host in the CKE cluster has failed according to host alarm information and / or node alarm information from the CKE cluster;

[0007] determining that the first host is deployed with a target node of a control type;

[0008] if the first host is deployed with the target node, determining a second host from the hosts of the CKE cluster;

[0009] migrating the target node from the first host to the second host.

[0010] Optionally, the determining that the first host has failed according to the node alarm information from the CKE cluster comprises:

[0011] parsing the node alarm information to obtain a host identifier to which the node belongs;

[0012] if the number of the first host identifiers obtained by parsing is greater than or equal to a preset value, it is determined that the first host has failed;

[0013] If the number of the first host identifiers obtained by the analysis is less than the preset value, a request message is output to request manual verification of whether the first host fails;

[0014] If a response message is received and the response message indicates that the first host fails, it is determined that the first host fails.

[0015] Optionally, before the second host is determined from the hosts of the CKE cluster, the method further comprises:

[0016] The failure recovery time of the first host is predicted.

[0017] If the failure recovery time is greater than a preset time, a second host is determined from the hosts of the CKE cluster.

[0018] Optionally, the predicted failure recovery time of the first host is obtained by:

[0019] According to the operating parameters of the first host, the failure cause of the first host is obtained.

[0020] According to the failure cause of the first host, the failure recovery time of the first host is predicted.

[0021] Optionally, the second host is determined from the hosts of the CKE cluster by:

[0022] According to the resources required for operating the target node and the available resources of the hosts other than the first host in the CKE cluster, the second host is determined from the other hosts.

[0023] Optionally, the target node is migrated from the first host to the second host by:

[0024] The migration information file of the target node is configured, and the data of the CKE cluster is backed up.

[0025] The target node is migrated to an idle node of the second host according to the migration information file; or a newly constructed node.

[0026] Optionally, after the target node is migrated from the first host to the second host, the method further comprises:

[0027] The operating state of the CKE cluster is obtained.

[0028] If the operating state of the node cluster is abnormal, a third host is determined from the hosts of the CKE cluster again.

[0029] migrate the target node from the first host to the third host.

[0030] In a second aspect, the present application provides a fault processing apparatus, applied to a cloud platform, the cloud platform comprising a monitoring host and a plurality of CKE clusters, each CKE cluster comprising a plurality of hosts, and each host deploying at least one node of at least one type, the apparatus being applied to the monitoring host, and the apparatus comprising:

[0031] a first determining module, configured to determine, according to host alarm information and / or node alarm information from the CKE cluster, that a first host in the CKE cluster has a fault;

[0032] a second determining module, configured to determine that the first host deploys a target node of a control type;

[0033] a processing module, configured to determine, if the first host deploys the target node, a second host from the hosts of the CKE cluster;

[0034] a migration module, configured to migrate the target node from the first host to the second host.

[0035] In a third aspect, the present application provides an electronic device, comprising a memory and a processor.

[0036] The memory is configured to store computer instructions, and the processor is configured to run the computer instructions stored in the memory to implement the method of any one of the first aspect.

[0037] In a fourth aspect, the present application provides a computer readable storage medium, having a computer program stored thereon, the computer program being executed by a processor to implement the method of any one of the first aspect.

[0038] In a fifth aspect, the present application provides a computer program product, comprising a computer program, the computer program being executed by a processor to implement the method of any one of the first aspect.

[0039] The fault handling method, apparatus, electronic device, and storage medium provided in this application determine that a first host in the CKE cluster has failed based on host alarm information and / or node alarm information from the CKE cluster; determine that a target node of a control type is deployed on the first host; if the target node is deployed on the first host, determine a second host from the hosts in the CKE cluster; and migrate the target node from the first host to the second host. Through this method, when a first host on the cloud platform fails, nodes deployed on that host can be migrated to available nodes on other hosts without manual intervention, improving the speed of restoring normal node operation, reducing the time of business interruption due to host failure, and thus improving the user experience. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of a scenario provided for an embodiment of this application;

[0041] Figure 2 Flowchart of the fault handling method provided in the embodiments of this application Figure 1 ;

[0042] Figure 3 Flowchart of the fault handling method provided in the embodiments of this application Figure 2 ;

[0043] Figure 4 This is a schematic diagram of the fault handling device provided in the embodiments of this application;

[0044] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0046] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect, without limiting their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0047] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0048] With the rapid advancement of cloud computing technology, more and more users are choosing to build cloud platforms to provide better services. This means that building a cloud platform not only requires meeting user needs technically, but also ensuring the reliable and stable operation of the cloud platform.

[0049] To improve the computing performance of cloud platforms, container technology is typically used to deploy different business processes across different nodes on different hosts of the cloud platform. One business scenario can correspond to one node cluster.

[0050] For highly complex cloud platforms, if a host fails, multiple business scenarios will become unusable, requiring manual troubleshooting, resulting in long repair times and a poor user experience.

[0051] In view of this, this application provides a fault handling method, apparatus, electronic device, and storage medium. By setting up a monitoring host in a cloud platform, the monitoring host collects alarm information from the cloud platform's hosts and / or alarm information from nodes deployed on the hosts. Based on the host alarm information and / or node alarm information, when a host failure is determined, the nodes deployed on that host can be migrated to available nodes on other hosts. Through this method, when a host failure occurs, no manual intervention is required to quickly restore the usability of each node, reducing the probability of business scenarios becoming unusable due to host failure, thereby improving the user experience.

[0052] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be implemented independently or in combination with each other. The same or similar concepts or processes may not be described again in some embodiments.

[0053] Figure 1 This is a schematic diagram illustrating an application scenario of an embodiment of this application, such as... Figure 1 As shown, the cloud platform includes a monitoring host and multiple hosts. Each host has multiple nodes deployed on it. The multiple nodes deployed on different hosts can form a Containership Kubernetes Engine (CKE) cluster.

[0054] For example, node 1 deployed on host 1, node 1 deployed on host 2, and node 2 deployed on host N together constitute CKE cluster 1. Node 2 deployed on host 1, node N deployed on host 1, and node 2 deployed on host 2 together constitute CKE cluster 2.

[0055] It should be understood that the number of nodes included in each CKE cluster can be set according to actual needs, and this application embodiment does not impose any restrictions on this.

[0056] It should be understood that the architecture of the cloud platform described above can also be described as the cloud platform including a monitoring host, multiple CKE clusters, each CKE cluster including multiple hosts, and each host having multiple nodes deployed.

[0057] In this embodiment of the application, the monitoring host can communicate with each host to obtain the status and information of each host. For example, it can receive host alarm information sent by the host, which can be used to indicate that the host has failed.

[0058] In some embodiments, the monitoring host may also obtain the status and information of each node included in each CKE cluster, for example, receive node alarm information sent by the host, which can be used to indicate that the node has failed.

[0059] The monitoring host can determine whether a corresponding host has failed based on host alarm information and / or node alarm information. If the host is determined to have failed, the monitoring host can migrate the nodes deployed on that host to available nodes on other hosts. This can quickly restore nodes that are unavailable due to host failure to an available state, reducing the impact on services using those nodes.

[0060] The application scenarios provided by the embodiments of this application have been described above. The following section describes applications in... Figure 1 Taking the monitoring host in the middle as an example, the fault handling method provided in this application will be described in detail.

[0061] Figure 2 Flowchart of the fault handling method provided in the embodiments of this application Figure 1 ,like Figure 2 As shown, it includes the following steps:

[0062] S201. Based on the host alarm information and / or node alarm information from the CKE cluster, determine that the first host in the CKE cluster has failed.

[0063] In this embodiment, the CKE cluster can be a Kubernetes cluster developed based on the distributed computing framework Mesos. The CKE cluster adopts a "container-on-container" technical architecture. The system services of the CKE cluster run in node containers started through Mesos, and the business nodes in the CKE cluster also run in node containers. The containers of all nodes in the entire CKE cluster run on the compute node host, and resource isolation is achieved through container cgroups.

[0064] In one possible implementation, the monitoring host can interact with each host in the CKE cluster to obtain host alarm information and / or node alarm information output by the host.

[0065] In one possible implementation, a monitoring program is deployed on the monitoring host. This program can collect monitoring metrics data and / or node status data of the host operation, analyze the monitoring metrics data to obtain host alarm information, and / or analyze the node status data to obtain node alarm information.

[0066] For example, the Prometheus monitoring program can be deployed on the monitoring host. Through Prometheus, the node_exporter monitoring indicator data of the host can be obtained and analyzed. If the monitoring indicator data indicates that the host has an anomaly, an alarm message will be output.

[0067] Optionally, the Prometheus monitoring program also includes a federated mode. This mode monitors the node status of the CKE cluster and outputs alarm information when the node status indicates an anomaly. The Prometheus federated mode can consist of a main program and multiple sub-monitoring programs. Each sub-monitoring program can monitor the node status of one CKE cluster node, and the main program can summarize and output the information collected by each sub-program.

[0068] In one possible implementation, when the monitoring host obtains host alarm information, it parses the host alarm information to determine the identifier of the first host corresponding to the alarm information, and determines that the first host has failed based on the identifier of the first host.

[0069] In one possible implementation, when the monitoring host obtains node alarm information, it can parse the node alarm information and determine whether the first host has malfunctioned based on the content included in the alarm information.

[0070] For example, if the identifier of the first host included in the node alarm information is greater than a preset value, it can be determined that the first host has failed. Alternatively, if the fault type of the first host in the node alarm information is a preset type, it can be determined that the first host has failed.

[0071] S202. Determine that a target node of the control type is deployed on the first host.

[0072] In this embodiment, when a fault is detected in the first host, the monitoring host can determine whether a control-type target node is deployed in the first host. Details of the nodes deployed in each host can be pre-stored in the monitoring host or other storage units of the cloud platform. The monitoring host can determine whether a control-type target node is deployed in the first host based on the node details.

[0073] In this embodiment, the nodes in the CKE cluster can be divided into control type nodes and compute type nodes. Control type nodes may include a master node and a console node, while compute type nodes include pods. A pod can migrate to an available node on another host when the first host fails.

[0074] If a control-type target node is deployed on the first host, the subsequent steps can be executed. If no control-type target node is deployed on the first host, the process ends, and / or an alarm message is pushed to the user's terminal.

[0075] S203. If the target node is deployed on the first host, then determine the second host from the hosts of the CKE cluster.

[0076] In this embodiment of the application, if the target node is deployed on the first host, the monitoring host needs to migrate the target node to ensure that the node can be used normally.

[0077] The monitoring host can obtain the resources required to deploy the target node, such as memory and CPU, and determine a second host in the cloud platform that can meet the resource requirements for migrating the target node. That is, the second host includes idle resources sufficient to support the operation of the target node.

[0078] S204. Migrate the target node from the first host to the second host.

[0079] In this embodiment of the application, when the monitoring host determines the second host, it can organize and merge the information and data related to the target node and move them to an available node of the second host.

[0080] The fault handling method provided in this application embodiment determines that a first host in the CKE cluster has failed based on host alarm information and / or node alarm information from the CKE cluster; determines that a target node of a control type is deployed on the first host; if the target node is deployed on the first host, then determines a second host from the hosts in the CKE cluster; and migrates the target node from the first host to the second host. Through this method, when a first host on the cloud platform fails, nodes deployed on that host can be migrated to available nodes on other hosts without manual intervention, improving the speed of restoring normal node operation, reducing the time of business interruption due to host failure, and thus improving the user experience.

[0081] Optionally, based on the above embodiments, the fault handling method provided in this application embodiment, in which the first host is determined to have failed based on the node alarm information from the CKE cluster, can also be determined in the following manner.

[0082] For example, the node alarm information is parsed to obtain the host identifier to which the node belongs; if the number of the first host identifiers obtained by parsing is greater than or equal to a preset value, it is determined that the first host has failed; if the number of the first host identifiers obtained by parsing is less than the preset value, a request message is output requesting manual verification of whether the first host has failed; if a response message to the request message is received, and the response message indicates that the first host has failed, it is determined that the first host has failed.

[0083] In this embodiment, when the monitoring host receives node alarm information, it can parse the node alarm information to obtain the host identifier of the host to which the node belongs, which is included in the node alarm information. The number of alarm nodes including the first host identifier is used to determine whether the first host has malfunctioned.

[0084] If the number of first host identifiers obtained by parsing is greater than or equal to a preset value, it can be confirmed that most of the nodes deployed in the first host are abnormal. In this case, it can be basically confirmed that the reason for the node alarm information is that the first host has failed.

[0085] If the number of first host identifiers obtained through parsing is less than the preset value, the reason for the node alarm information may be a problem with the node's own status or a failure of the first host. In this case, the monitoring host can push the node alarm information to the terminal device of the relevant maintenance personnel to request verification of whether the first host has failed. If a response message is received from the terminal device, the response message is parsed to determine the content represented by the response message. If the response message indicates that the first host has failed, then it is determined that the first host has failed.

[0086] Optionally, based on the above embodiments, the fault handling method provided in this application embodiment further includes checking the CKE cluster status after migrating the target node.

[0087] For example, the running status of the CKE cluster is obtained; if the running status of the node cluster is abnormal, a third host is determined from the hosts of the CKE cluster; the target node is migrated from the first host to the third host.

[0088] In this embodiment of the application, when migrating the target node to the second host, the monitoring host can also determine whether the migration is successful. If it is unsuccessful, the target node can be migrated to the third host to improve the success rate of the target node migration.

[0089] In one possible implementation, when re-migrating the target node, it can be migrated to a third host or the migration to a second host can be retried; this application embodiment does not impose any restrictions on this. When retriing the migration to a second host, a maximum number of retries can be set. If the migration fails after the maximum number of retries, the target node is then migrated to a third host.

[0090] The monitoring host can obtain the running status of the CKE cluster of the target node after migration to determine whether the migration was successful.

[0091] For example, the monitoring host can query the status of the CKE cluster after the migration of nodes is completed through the interface to see if it is normal.

[0092] The interface query methods can be as follows:

[0093] http: / / xxxx / service / {CKE-NAME} / k8s / v2 / clusters

[0094] If the interface returns a cluster status of "running," it indicates that the node migration is normal and the migration verification is complete. If the interface returns a cluster status of any other type, such as "Stop" or "error," it indicates that the target node migration has failed and needs to be performed again.

[0095] Figure 3 Flowchart of the fault handling method provided in the embodiments of this application Figure 2 ,exist Figure 2 Based on the illustrated embodiment, the fault handling method will be further described, such as... Figure 3 As shown, it includes:

[0096] S301. Based on the host alarm information and / or node alarm information from the CKE cluster, determine that the first host in the CKE cluster has failed.

[0097] S302. Determine that a target node of the control type is deployed on the first host.

[0098] In this embodiment of the application, the specific implementation methods of S301 and S302 are as follows: Figure 2 The specific implementations of S201 and S202 in the illustrated embodiments are similar and will not be described again here.

[0099] Optionally, if the monitoring host receives both host alarm information and node alarm information at the same time, and the host alarm information and node alarm information point to the same host, the host alarm information shall prevail; if they point to different hosts, they can be confirmed separately.

[0100] S303. Predict the fault recovery time of the first host.

[0101] In this embodiment of the application, when the monitoring host determines that the first host has failed, it can predict the recovery time of the first host. If the recovery time of the first host is less than the preset time, the monitoring host can wait for the first host to recover, thereby reducing the consumption of cloud platform computing resources due to the migration of the target node.

[0102] The predicted fault recovery time of the first host can be performed as follows:

[0103] For example, based on the operating parameters of the first host, the cause of the first host failure is obtained; based on the cause of the first host failure, the failure recovery time of the first host is predicted.

[0104] The operating parameters may include, but are not limited to, the CPU utilization rate, cache size, memory utilization rate, storage space utilization rate, stack usage status, and temperature of the core hardware of the first host.

[0105] If the cause of the first host's failure is determined to be due to the operating parameters, such as excessively high CPU utilization, excessively high memory utilization, or excessively high CPU temperature, then it can be determined that the recovery time of the first host is relatively short.

[0106] If it is determined from the operating parameters that the cause of the first host failure is not due to the operating parameters, then it can be determined that the recovery time of the first host is relatively long.

[0107] In one possible implementation, the monitoring host may also output a request message requesting manual verification of the recovery time of the first host, and predict the fault recovery time of the first host based on the response message received from the request message.

[0108] Optionally, in one possible implementation, the step of determining that a target node of a control type is deployed on the first host can be performed after the step of predicting the fault recovery time of the first host. This embodiment of the application does not restrict the execution order.

[0109] S304. Determine whether the fault recovery time is greater than the preset time. If yes, the steps shown in S305 can be executed. If no, the process ends.

[0110] S305. Determine the second host from the hosts of the CKE cluster.

[0111] In this embodiment of the application, the monitoring host determines that the target node is deployed in the first host, and when the first host is unrecoverable for a short period of time, a second host that can run the target node can be determined from the hosts of the CKE cluster.

[0112] For example, the second host is determined from the other hosts based on the resources required to run the target node and the available resources of the other hosts in the CKE cluster besides the first host.

[0113] When deploying each node, the monitoring host can record the resources required for each node to run and generate relevant record information. Based on the record information, the resources required to run the target node can be determined.

[0114] The monitoring host can obtain the available resources of other hosts besides the first host. If the available resources of a certain host are greater than or equal to the resources required by the target node, then that host can be used as the second host.

[0115] Optionally, if there are multiple second hosts, the monitoring platform can determine the resources consumed by migrating the target node to each second host, and select the host with the lowest resource consumption as the second host.

[0116] Determining the second host by the resources required to run the target node can reduce the probability of the target node migration failing due to insufficient available resources on the second host.

[0117] It should be understood that the second host can be any host in the cloud platform other than the first host, and is not limited by the CKE cluster.

[0118] S306. Migrate the target node from the first host to the second host.

[0119] For example, configure the migration information file of the target node and back up the data of the CKE cluster; migrate the target node to an idle node of the second host according to the migration information file; or, create a new node.

[0120] The migration information file may be a file used to ensure the normal operation of the target node, or a migration path information file, etc. The file used to ensure the normal operation of the target node includes, but is not limited to, environment information files, data information files, etc.

[0121] When the monitoring host migrates the target node according to the migration information file, it can determine whether the second host has an idle node that can support the operation of the target node. If so, the target node can be migrated to an idle node of the second host.

[0122] If it does not exist, the monitoring host can build a new node based on the resources required to run the target node in the second host, and migrate the target node to the newly built node.

[0123] Optionally, during the migration of the target node, the monitoring host can also back up the data of the CKE cluster to which the target node belongs, reducing the probability of data loss or corruption of the target node during the migration, thus reducing the likelihood of incomplete data in the CKE cluster due to migration failure.

[0124] S307. After obtaining the target node for migration, determine whether the status of each CKE cluster is normal.

[0125] In this embodiment, the implementation of step S307 can be found in the implementation of the above embodiments, and will not be repeated here.

[0126] The fault handling method provided in this application can migrate target nodes of faulty hosts in batches or individually, shortening the impact time on user services and ensuring service availability. During the migration process, no manual intervention is required, reducing the time spent obtaining information about the target nodes to be migrated, shortening the significant time consumed in the pre-migration preparation phase, and reducing unexpected situations such as human error. This improves the efficiency of successfully migrating target nodes.

[0127] This application also provides a fault handling device.

[0128] Figure 4 This is a schematic diagram of the structure of the fault handling device 400 provided in the embodiments of this application. The fault handling device is applied to a cloud platform, which includes a monitoring host and multiple CKE clusters. Each CKE cluster includes multiple hosts, and each host has at least one node of at least one type deployed on it. The device is applied to the monitoring host and includes:

[0129] The first determining module 401 is used to determine, based on host alarm information and / or node alarm information from the CKE cluster, that a first host in the CKE cluster has failed.

[0130] The second determining module 402 is used to determine that a target node of the control type is deployed on the first host.

[0131] The processing module 403 is used to determine the second host from the hosts of the CKE cluster if the target node is deployed on the first host.

[0132] Migration module 404 is used to migrate the target node from the first host to the second host.

[0133] Optionally, the first determining module 401 is further configured to parse the node alarm information and obtain the host identifier to which the node belongs; if the number of the first host identifiers obtained by parsing is greater than or equal to a preset value, then it is determined that the first host has failed; if the number of the first host identifiers obtained by parsing is less than the preset value, then a request message requesting manual verification of whether the first host has failed is output; if a response message to the request message is received, and the response message indicates that the first host has failed, then it is determined that the first host has failed.

[0134] Optionally, the first determining module 402 is further configured to predict the fault recovery time of the first host; if the fault recovery time is longer than a preset time, then a second host is determined from the hosts of the CKE cluster.

[0135] Optionally, the first determining module 402 is further configured to obtain the cause of the failure of the first host based on the operating parameters of the first host; and predict the failure recovery time of the first host based on the cause of the failure of the first host.

[0136] Optionally, the processing module 403 is further configured to determine the second host from the other hosts based on the resources required to run the target node and the available resources of the other hosts in the CKE cluster besides the first host.

[0137] Optionally, the migration module 404 is also used to configure the migration information file of the target node and back up the data of the CKE cluster; migrate the target node to an idle node of the second host according to the migration information file; or, a newly constructed node.

[0138] Optionally, the migration module 404 is further configured to obtain the running status of the CKE cluster; if the running status of the node cluster is abnormal, a third host is re-determined from the hosts of the CKE cluster; and the target node is migrated from the first host to the third host.

[0139] The fault handling device provided in this application embodiment can execute the technical solution of the fault handling method provided in any of the above embodiments. Its principle and technical effect are similar, and will not be repeated here.

[0140] Figure 5 This is a schematic diagram of an electronic device structure provided in this application. Figure 5 As shown, the electronic device 500 may include at least one processor 501, a memory 502, and a communication interface 503.

[0141] The memory 502 is used to store programs. Specifically, the program may include program code, which includes computer operation instructions.

[0142] The memory 502 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0143] The processor 501 is used to execute computer execution instructions stored in the memory 502 to implement the fault handling method described in the foregoing method embodiments. The processor 501 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0144] In practical implementation, if the communication interface 503, memory 502, and processor 501 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0145] Optionally, in a specific implementation, if the communication interface 503, memory 502, and processor 501 are integrated on a single chip, then the communication interface 503, memory 502, and processor 501 can communicate through an internal interface.

[0146] This application also provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the technical solution of the above-described fault handling method embodiment. Its implementation principle and technical effect are similar, and will not be repeated here.

[0147] In one possible implementation, a computer-readable medium may include random access memory (RAM), read-only memory (ROM), compact discread-only memory (CD-ROM) or other optical disc storage, disk storage or other magnetic storage devices, or any other medium targeted to carry or to store the required program code in the form of instructions or data structures, and accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disks and optical discs include optical discs, laser discs, optical discs, Digital Versatile Discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers. The above combinations should also be included within the scope of computer-readable media.

[0148] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the technical solution of the above-described fault handling method embodiment. Its implementation principle and technical effects are similar, and will not be repeated here.

[0149] In the specific implementation of the aforementioned terminal device or server, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0150] Those skilled in the art will understand that all or part of the steps in any of the above method embodiments can be implemented by hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium, and when the program is executed, all or part of the steps in the above method embodiments are performed.

[0151] If the technical solution of this application is implemented in software form and sold or used as a product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of this application can be embodied in the form of a software product, which is stored in a storage medium and includes a computer program or several instructions. This computer software product causes a computer device (which may be a personal computer, server, network device, or similar electronic device) to execute all or part of the steps of the method described in the embodiments of this application.

[0152] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended 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. Such 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.

Claims

1. A fault handling method, characterized in that, The method is applied to a cloud platform, which includes a monitoring host and multiple CKE clusters. Each CKE cluster includes multiple hosts, and each host has at least one node of at least one type deployed on it. The method is applied to the monitoring host and includes: Based on the host alarm information and node alarm information from the CKE cluster, it is determined that the first host in the CKE cluster has failed. It is determined that a target node of the control type is deployed on the first host; Based on the operating parameters of the first host, obtain the cause of the first host's failure; Based on the cause of the first host failure, predict the recovery time of the first host failure; If the fault recovery time is longer than the preset time, then a second host that meets the resource requirements for migrating the target node is determined from the hosts of the CKE cluster; The target node is migrated from the first host to the second host; The step of determining that the first host has failed based on node alarm information from the CKE cluster includes: Parse the node alarm information to obtain the host identifier to which the node belongs; If the number of the first host identifiers obtained by parsing is greater than or equal to a preset value, then it is determined that the first host has malfunctioned; If the number of first host identifiers obtained by parsing is less than the preset value, a request message is output requesting manual verification of whether the first host has malfunctioned. If a response message to the request message is received, and the response message indicates that the first host has failed, then it is determined that the first host has failed.

2. The method according to claim 1, characterized in that, Determining the second host from the hosts of the CKE cluster includes: The second host is determined from the other hosts based on the resources required to run the target node and the available resources of the other hosts in the CKE cluster besides the first host.

3. The method according to claim 1, characterized in that, The step of migrating the target node from the first host to the second host includes: Configure the migration information file for the target node and back up the data of the CKE cluster; The target node is migrated to an idle node of the second host according to the migration information file; or, a newly constructed node.

4. The method according to claim 1, characterized in that, After migrating the target node from the first host to the second host, the method further includes: Obtain the running status of the CKE cluster; If the node cluster is in an abnormal operating state, a third host will be determined from the hosts of the CKE cluster. The target node is migrated from the first host to the third host.

5. A fault handling device, characterized in that, The device is applied to a cloud platform, which includes a monitoring host and multiple CKE clusters. Each CKE cluster includes multiple hosts, and each host has at least one node of at least one type deployed on it. The device is applied to the monitoring host and includes: The first determining module is used to determine, based on host alarm information and / or node alarm information from the CKE cluster, that a first host in the CKE cluster has failed. The second determining module is used to determine that a target node of the control type is deployed on the first host; the first determining module is also used to obtain the cause of the failure of the first host based on the operating parameters of the first host; and to predict the failure recovery time of the first host based on the cause of the failure of the first host. The processing module is used to determine a second host from the hosts of the CKE cluster that meets the resources required to migrate the target node if the fault recovery time is longer than a preset time. A migration module is used to migrate the target node from the first host to the second host; When the first determining module determines that the first host in the CKE cluster has failed based on the node alarm information, it is specifically used to parse the node alarm information and obtain the host identifier to which the node belongs; if the number of the first host identifiers obtained by parsing is greater than or equal to a preset value, then the first host has failed; if the number of the first host identifiers obtained by parsing is less than the preset value, then a request message is output requesting manual verification of whether the first host has failed; if a response message to the request message is received, and the response message indicates that the first host has failed, then the first host has failed.

6. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the method of any one of claims 1-4.

7. A computer-readable storage medium, characterized in that, It stores a computer program, which is executed by a processor to implement the method of any one of claims 1-4.

8. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-4.

Images