Fault processing method and device, computer equipment and storage medium

Abstract

The invention discloses a fault processing method and device, computer equipment and a storage medium, and relates to the technical field of virtual machines. The method comprises the following steps: monitoring a running state of a server cluster corresponding to a virtual machine; if a fault occurs in operation of a first server, the fault type of the fault is determined based on operation parameters of the first server, and the first server is any server in the server cluster; and calling a fault processing strategy corresponding to the fault type, and performing scheduling processing on the virtual machine in the first server. Thus, richer fault processing strategies are provided, the fault processing strategies corresponding to the fault types are flexibly called for different fault types to schedule the virtual machines in the first server, the management efficiency of the virtual machine cluster is improved, the influence of faults on system operation is reduced, the self-healing capability of the system is enhanced, and the user experience is improved. And the stability and reliability of the whole server cluster are improved, so that the use experience of the virtual machine service of the user is improved.

Description

Technical Field

[0001] The present application relates to the field of virtual machine technology, and in particular to a fault handling method, apparatus, computer equipment and storage medium. Background Art

[0002] Cluster HA (High Availability) refers to providing customers with abnormal redundant processing capabilities through a combination of hardware and software, ensuring that the business can be quickly restored in the event of a failure, thereby providing uninterrupted services. Among them, the hardware mainly provides resources for virtual machines by forming multiple physical hosts into a cluster; the software refers to the HA cluster service provided by the manufacturer, which monitors the status of physical hosts. When a physical host fails (such as host downtime, component failure, etc.), the HA service actively switches the virtual machines on the failed host to other available hosts. The user is unaware of the entire switching process.

[0003] However, in the related technologies, the HA scenario handling mechanism is not perfect, and the virtual machine can only be switched to other nodes through failover, resulting in interruption of user services and greatly reducing the user experience of the virtual machine services. Summary of the invention

[0004] The present application proposes a fault handling method, apparatus, computer equipment and storage medium.

[0005] In a first aspect, an embodiment of the present application provides a fault handling method, the method comprising: monitoring the operating status of a server cluster corresponding to a virtual machine; if a first server fails to operate, determining the fault type of the fault based on the operating parameters of the first server, the first server being any server in the server cluster; calling a fault handling strategy corresponding to the fault type to schedule and process the virtual machines in the first server.

[0006] In the second aspect, the embodiment of the present application provides a fault handling device, which includes: an operation monitoring module, a fault type determination module and a fault handling module. The operation monitoring module is used to monitor the operation status of the server cluster corresponding to the virtual machine; the fault type determination module is used to determine the fault type of the fault based on the operation parameters of the first server if a fault occurs in the operation of the first server, and the first server is any server in the server cluster; the fault handling module, the user calls the fault handling strategy corresponding to the fault type to schedule the virtual machine in the first server.

[0007] In a third aspect, an embodiment of the present application provides a computer device, comprising: one or more processors; a memory; one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to execute the above-mentioned method.

[0008] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a program code is stored. The program code can be called by a processor to execute the above method.

[0009] In the solution provided by the present application, the operating status of the server cluster corresponding to the virtual machine is monitored; if the operation of the first server fails, the fault type of the fault is determined based on the operating parameters of the first server, and the first server is any server in the server cluster; the fault handling strategy corresponding to the fault type is called to schedule and process the virtual machine in the first server. In this way, a richer fault handling strategy is provided. For different fault types, the fault handling strategy corresponding to the fault type is flexibly called to schedule and process the virtual machine in the first server, thereby improving the management efficiency of the virtual machine cluster, reducing the impact of faults on system operation, enhancing the self-healing ability of the system, and improving the stability and reliability of the entire server cluster, thereby improving the user experience of the virtual machine business. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0011] Figure 1 A schematic diagram of the architecture of a fault handling system provided in an embodiment of the present application is shown.

[0012] Figure 2 A flowchart of a fault handling method provided in an embodiment of the present application is shown.

[0013] Figure 3 A cluster diagram of a server cluster provided in an embodiment of the present application is shown.

[0014] Figure 4 A schematic diagram of the architecture of a fault handling system provided in another embodiment of the present application is shown.

[0015] Figure 5 A scheduling flow chart of an intelligent scheduling engine provided in one embodiment of the present application is shown.

[0016] Figure 6 A flowchart of memory detection provided by an embodiment of the present application is shown.

[0017] Figure 7 A flow chart showing the principle of resource reservation provided in an embodiment of the present application is shown.

[0018] Figure 8 A flowchart of a fault proactive HA response provided by an embodiment of the present application is shown.

[0019] Fig. 9 A flowchart of a fault handling method provided in yet another embodiment of the present application is shown.

[0020] Fig.10 A flowchart of a fault-preventive HA response provided by an embodiment of the present application is shown.

[0021] Fig.11 A flowchart of a virtual machine relocation algorithm provided in one embodiment of the present application is shown.

[0022] Fig.12 A schematic diagram of a maneuvering algorithm provided in an embodiment of the present application is shown.

[0023] Fig.13 A schematic diagram of another maneuvering algorithm provided in an embodiment of the present application is shown.

[0024] Fig.14 A schematic diagram of another maneuvering algorithm provided in an embodiment of the present application is shown.

[0025] Fig.15 A cluster diagram of a server cluster provided in another embodiment of the present application is shown.

[0026] Fig.16 A flowchart of resource pre-arrangement provided by an embodiment of the present application is shown.

[0027] Fig.17 It is a block diagram of a fault handling device provided according to an embodiment of the present application.

[0028] Fig.18 It is a block diagram of a computer device according to an embodiment of the present application for executing a fault handling method according to an embodiment of the present application.

[0029] Fig.19 It is a storage unit of an embodiment of the present application for storing or carrying program codes for implementing the fault handling method according to an embodiment of the present application. DETAILED DESCRIPTION

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

[0031] It should be noted that in some processes described in the specification, claims and the above-mentioned drawings of the present application, multiple operations that appear in a specific order are included, and these operations may not be executed or executed in parallel in the order in which they appear in this article. The sequence numbers of operations such as S110, S120, etc. are only used to distinguish different operations, and the sequence numbers themselves do not represent any execution order. In addition, these processes may include more or less operations, and these operations may be executed in sequence or in parallel. And, the terms "first", "second", etc. in the specification, claims and the above-mentioned drawings of the present application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described here can be implemented in an order other than those illustrated or described here. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or server that includes a series of steps or sub-modules is not necessarily limited to those steps or sub-modules explicitly listed, but may include other steps or sub-modules that are not explicitly listed or that are inherent to these processes, methods, products, or devices.

[0032] The inventor proposes a fault handling method, device, computer equipment and storage medium. The fault handling method provided in the embodiment of the present application is described in detail below.

[0033] See also Figure 1 , Figure 1 A schematic diagram of an application scenario of a fault handling method provided in an embodiment of the present application, the application scenario includes a fault handling system 10. The fault handling system 10 includes a server cluster 110 and a virtual machine management platform 120. The server cluster 110 may include a server 111, a server 112, a server 113, and a server 114. Of course, a larger number of servers may also be included. Figure 1 Each server in the server cluster 110 may deploy one virtual machine (VM) or multiple virtual machines, which is not limited in this embodiment. A virtual machine refers to a complete computer system with complete hardware system functions simulated by software and running in a completely isolated environment.

[0034] The virtual machine management platform 120 is also deployed on the server. The virtual machine management platform 120 can uniformly manage all servers in the server cluster 110, that is, uniformly manage all physical resources and virtual machine resources in the server cluster 110, for example, virtual machine life cycle and server operation status detection, etc. The virtual machine life cycle includes the creation, startup, suspension, restart, shutdown and migration of the virtual machine.

[0035] In the present application, the virtual machine management platform 110 can monitor the operating status of the server cluster 110, and when it is detected that a failure occurs in the operation of the first server, determine the fault type of the fault based on the operating parameters of the first server, where the first server is any server in the server cluster 110; call the fault handling strategy corresponding to the fault type to schedule and process the virtual machines in the first server.

[0036] Please refer to Figure 2 , Figure 2 A flowchart of a fault handling method provided in an embodiment of the present application is shown below. Figure 2 The fault handling method provided in the embodiment of the present application is described in detail. The fault handling method may include the following steps:

[0037] Step S210: monitoring the operating status of the server cluster corresponding to the virtual machine.

[0038] In this embodiment, the virtual machine management platform can monitor the operating status of each server in the server cluster from multiple levels such as the hardware layer, platform layer and application layer. Among them, the monitoring of the operating status of the hardware layer includes but is not limited to the monitoring of the operating parameters of the hardware such as the central processing unit (CPU), memory, system disk, motherboard, graphics processing unit (GPU) graphics card and encryption card on each server.

[0039] Optionally, the monitoring of the operating status of the platform layer includes, but is not limited to, monitoring of the network parameters of the management network, storage network, business network, virtual extended local area network (Virtual Extensible Local Area Network, VXLAN) network and terminal communication network of each server. Among them, the management network can be understood as the network of the virtual machine management platform itself, including the communication between the management server, management control node and other management components. The virtual machine management platform usually configures, monitors and manages resources such as virtual machines and physical hosts based on the management network. The storage network is a network used to connect virtual machines and storage devices, which provides a channel for virtual machines to read and write storage resources. The business network is a network that provides external network connections for virtual machines. Virtual machines can communicate with external networks through business networks, such as accessing the Internet, communicating with other virtual machines or physical hosts, etc. The VXLAN network is a tunnel network based on virtualization technology, which is used to establish a logical layer 2 network connection between multiple physical hosts (i.e., servers). It provides the ability for virtual machines to communicate and migrate across servers. Therefore, the VXLAN network can also be understood as a data communication network, so that virtual machines can be seamlessly migrated between different physical hosts. The terminal communication network can be understood as an access network provided for the virtual desktop (Virtual Desktop Infrastructure, VDI).

[0040] Optionally, monitoring the running status of the application layer may include monitoring the status of the process of the virtual machine in each server and the parameters of the input / output (I / O) operation.

[0041] Step S220: If a failure occurs in the operation of the first server, a failure type of the failure is determined based on an operation parameter of the first server, where the first server is any server in the server cluster.

[0042] Based on this, it is possible to determine whether each server in the server cluster has a fault based on the operating parameters monitored at multiple levels such as the aforementioned hardware layer, platform layer, and application layer; if it is determined that the first server (i.e., any server) has a fault, the fault type of the fault can be further determined based on the operating parameters of the first server.

[0043] Step S230: calling a fault handling strategy corresponding to the fault type to schedule the virtual machine in the first server.

[0044] In some implementations, if the fault type is a hardware layer fault, a server that meets the first set condition is determined from the target cluster as the second server; the virtual machine in the first server is restarted and switched to the second server, and the target cluster includes other servers in the server cluster except the first server. In other words, the virtual machine in the server with the hardware layer fault is restarted and switched to a server in the target cluster that is operating normally (i.e., not faulted).

[0045] In this way, if the hardware layer failure is determined to be a CPU failure, memory failure, system disk failure or motherboard failure that causes the server downtime, the virtual machine in the first server can be actively restarted and switched to the second server. Optionally, if the hardware layer failure is determined to be an encryption card failure, the virtual machine associated with the encryption card can be actively restarted and switched to run on the second server with other normal encryption cards.

[0046] Optionally, if a GPU graphics card failure is detected on the first server, the virtual machine associated with the GPU graphics card is actively restarted to run on the second server where other GPU graphics cards are normal. It should be noted that if the first server supports multiple identical GPU graphics cards and only one of them fails, the GPU graphics card associated with the failed GPU can be restarted.

[0047] In other embodiments, if the fault type is a network offline fault, a server that meets the first set condition is determined from the target cluster as the second server, and the virtual machine in the first server is restarted and switched to the second server, or the virtual machine in the first server is hot migrated to the second server.

[0048] In this mode, if the fault type is a network offline fault, a server that meets the first set condition is determined from the target cluster as the second server. That is to say, a server that is operating normally (i.e., not faulty) is determined from the target cluster as the second server. Optionally, if the network offline fault is a storage network offline fault, the storage network offline will cause the virtual machine to fail to read and write storage resources, and hot migration cannot be performed when the network is offline. Therefore, the virtual machine in the first server can be restarted in time and switched to the second server for operation. In this way, in the event of a network offline fault, the server can be switched to another second server with a normal storage network and accessible by actively restarting.

[0049] Optionally, if the network offline fault is a service network offline fault or a data communication network offline fault, the virtual machine in the first server is restarted and switched to the second server for operation, or the virtual machine in the first server is hot migrated to the second server. Specifically, in the case of a service network offline fault or a data network offline fault, a first prompt message can be output to the client, and the first prompt message at least includes a restart switching mode and a hot migration mode, so as to prompt the user to select any mode to schedule and migrate the virtual machine service in the first server. Further, in response to the mode selection instruction input based on the first prompt message, the selected scheduling migration mode is called to migrate the virtual machine in the first server to the second server. In this way, the selection of scheduling migration mode is provided, so that the user can select the required scheduling migration mode according to whether there is a running business in the current virtual machine. For example, if there is no running business in the virtual machine, the user can select the restart switching mode to quickly realize the scheduling migration of the virtual machine; for another example, if there is a running business in the virtual machine, in order to avoid interruption of these businesses, the user can select the hot migration mode to realize the scheduling migration of the virtual machine without affecting the virtual machine business, which greatly improves the user experience.

[0050] Of course, in the case of a business network offline failure or a data network offline failure, the actual memory occupied by the virtual machine in the first server can be obtained. If the actual memory is greater than the first memory threshold, the virtual machine in the first server can be directly scheduled to migrate to the second server for operation by restarting and switching; if the actual memory is less than or equal to the first memory threshold, the virtual machine in the first server can be scheduled to migrate to the second server for operation by hot migration. In this way, it is possible to avoid problems such as the hot migration process taking too long due to the actual memory occupied by the virtual machine being too large, and other abnormal emergencies during the hot migration process causing hot migration failure.

[0051] Optionally, if the network offline failure is a terminal communication network offline failure, the virtual machine in the first server is hot migrated to the second server. Due to the problem of the terminal communication network being offline, the desktop virtual machine will be inaccessible, that is, the client cannot use the desktop virtual machine, which seriously affects the user experience of the client user. In addition, considering that the user may not save some data in the desktop virtual machine in time, the desktop virtual machine in the first server where the terminal communication network is offline can be hot migrated to other second servers where no failure has occurred. In this way, the unsaved data in the desktop virtual machine is avoided, and the loss of data is caused by restarting and switching servers, which effectively ensures the integrity of the data in the virtual machine.

[0052] Optionally, if the network offline failure is the management network offline failure of the server, then the virtual machine shutdown platform will lose the ability to manage the server, and the server cluster will be split into two clusters, the abnormal side cluster (a single host cluster composed of hosts with offline management networks) and the normal side cluster (a cluster composed of hosts with normal management networks). If the servers in the abnormal cluster do not have the aforementioned other types of network offline failures, and the hardware status of the servers is normal, then the virtual machine services in the abnormal cluster can actually run normally and will not be affected, and no HA response is required.

[0053] Of course, if any server in the abnormal test cluster has other types of network offline failures mentioned above, or a problem server with abnormal hardware status, the abnormal side cluster will actively shut down the problem server and switch to the server in the normal side cluster for operation.

[0054] In some other embodiments, if the fault type is an application layer fault, the virtual machine in the first server is restarted. That is, if it is detected that the virtual machine process in the first server is abnormally suspended or the virtual machine I / O is abnormally suspended, the process suspension and I / O abnormal suspension caused by a situation can be quickly recovered by restarting the virtual machine in the first server.

[0055] Optionally, if no server in the server cluster has any type of failure, step S210 is performed again after sleeping for a set time period.

[0056] That is to say, Figure 3 As shown, in a server cluster consisting of multiple servers, when any server fails and affects the business of the virtual machines running on the server, the cluster high availability (HA) service will promptly and proactively switch the virtual machines to other normal servers in the cluster.

[0057] In this embodiment, by covering multiple levels of monitoring including the hardware layer, the network offline fault layer and the application layer, and providing corresponding response methods for different faults, that is, when facing a virtual machine failure, a variety of flexible response methods can be provided. When a failure occurs, the HA switching of the virtual machine is actively completed, and the virtual machine is switched to a host in a normal state, thereby improving the management efficiency of the virtual machine cluster, reducing the impact of the failure on the system operation, enhancing the self-healing ability of the system, and comprehensively ensuring the continuity and stability of the client's virtual machine business, thereby improving the user experience of the virtual machine business.

[0058] Please refer to Figure 4 , Figure 4A flowchart of a fault handling method provided in another embodiment of the present application is shown below. Figure 4 The fault handling method provided in the embodiment of the present application is described in detail. The fault handling method may include the following steps:

[0059] Step S310: monitor the operating status of the server cluster corresponding to the virtual machine.

[0060] Step S320: If a failure occurs in the operation of the first server, a failure type of the failure is determined based on the operation parameters of the first server, where the first server is any server in the server cluster.

[0061] In this embodiment, the specific implementation of step S310 to step S320 can refer to the content of the above-mentioned embodiment, which will not be repeated here.

[0062] Step S330: If the fault type is a hardware layer fault, determine a server that meets the first set condition from the target cluster as the second server, restart the virtual machine in the first server and switch it to the second server. The target cluster includes other servers in the server cluster except the first server.

[0063] Specifically, combined Figure 5 The specific implementation method of step S330 is explained. When it is determined that the operation of the server fails, the intelligent scheduling engine determines that there is a scheduling request task; if it is determined that there is no server operation failure, it determines that there is no scheduling request task.

[0064] First, when it is necessary to execute the scheduling request task, the scheduling data is loaded, and then all other servers in the target cluster are traversed based on the scheduling data, and servers that do not meet the hard conditions are filtered out. Specifically, the scheduling data may include the virtual machine configuration memory and the remaining computing memory of the server, that is, the virtual machine configuration memory of the virtual machine in the first server can be obtained; from other servers in the target cluster where the failure has not occurred, the server whose remaining computing memory is greater than or equal to the virtual machine configuration memory is determined as the second server. Among them, the virtual machine configuration memory can be understood as the preset memory pre-configured for the virtual machine. For example, the virtual machine configuration memory is 10G, and 10G of memory will be allocated in the first server for the virtual machine to use. The remaining computing memory of the server can be understood as the theoretically remaining memory after the virtual machine in the server is configured. For example, the total memory allocated to all virtual machines in the server is 100G, and the configuration memory of each virtual machine is 10G. 8 virtual machines have been configured on the server. At this time, the remaining computing memory of the server is 20G. Obviously, the first setting condition first needs to filter out the second server whose remaining computing memory is sufficient for configuring the virtual machine in the first server from the target cluster.

[0065] Furthermore, based on the first set condition, a second filtering will be performed on the first servers whose remaining computing memory is sufficient for configuration. For example, when scheduling virtual machines that need to use a GPU, servers that are not configured with a GPU graphics card or servers with insufficient GPU graphics card resources will be filtered out.

[0066] Optionally, if the number of the first servers remaining after the second filtering is one, the one determined server may be directly used as the second server.

[0067] Optionally, if the number of the remaining first servers after the second filtering is 0, the scheduling is determined to have failed, and a prompt message of the scheduling failure is fed back to the client. In some embodiments, after the prompt message of the scheduling failure is fed back, the first server that failed is detected again after a first preset time interval to see whether it has recovered. If it has recovered, the server continues to be monitored for failure after a second preset time interval; if it has not recovered, the intelligent scheduling engine is triggered again, i.e., the server scheduling retry process is entered. Each retry will be separated by a certain time interval, and the interval time is increased in a step-by-step manner. As the number of retries increases, the time interval for waiting for the next retry will gradually increase, i.e., the HA response priority is reduced. On the one hand, it reduces the consumption of useless retries and resources, and on the other hand, it gives priority to ensuring that other abnormal virtual machines can be HA in time.

[0068] Optionally, if the number of servers whose remaining computing memory is greater than the configured memory of the virtual machine is determined to be multiple from other servers in the target cluster where the failure has not occurred is multiple, the multiple servers determined are used as multiple third servers. Then, a pre-trained scoring model is used, and based on the operating parameters of each of the third servers, each of the third servers is scored to obtain an operating score for each of the third servers. From the multiple third servers, the third server with the highest operating score is determined as the second server.

[0069] The operation parameter may be a load parameter. At this time, the operation score of each third server is negatively correlated with the parameter value of the load parameter, that is, the lower the parameter value of the load parameter of the third server, the smaller the complex pressure of the server is at this time, and naturally the higher the operation score of the server is. The operation score can also be regarded as a quantitative score of the performance of the third server. The higher the operation score of the third server, the better the performance of the third server is.

[0070] In some embodiments, the operating parameter may also be a network parameter, which may include a network transmission rate and a network packet loss rate, etc. Based on this, the network parameter of each third server is used as a model input of a pre-trained scoring model, and the output of the scoring model is a quantitative score of the network performance of each third server based on the network parameter, and the quantitative score output by the scoring model is used as the operating score of each third server. In this case, the higher the operating score of the third server, the better the network performance of the third server.

[0071] In other embodiments, the operating parameters may be multiple, for example, including load parameters and network parameters at the same time, and the scoring model may include a load scoring model and a network scoring model. Based on this, the network parameters of each third server are used as the model input of the network scoring model, and the output of the network scoring model is a quantitative score of the network performance of each third server based on the network parameters, and the quantitative score output by the network scoring model is used as the network operating score of each third server. And, the load parameters of each third server are used as the model input of the load scoring model, and the output of the load scoring model is a quantitative score of the load performance of each third server based on the load parameters, and the quantitative score output by the load scoring model is used as the load operating score of each third server. Finally, the network operating score and the load operating score are weighted and summed to obtain the final operating score of each third server. At this time, the higher the operating score of the third server, the better the network performance and load performance of the third server.

[0072] In this manner, there may be one scoring model, that is, the input of the scoring model is a plurality of operating parameters of the third server, and the scoring model may score the comprehensive performance of the third server based on the plurality of operating parameters, and the score output by the scoring model is used as an operating score for judging the comprehensive performance. The higher the operating score, the better the comprehensive performance of the third server.

[0073] It should be noted that after determining multiple third servers, secondary filtering can still be performed in the aforementioned manner, and then a pre-trained scoring model is used to score each third server based on multiple operating parameters of each filtered third server.

[0074] In one possible implementation, see Figure 6 If a server whose remaining computing memory is greater than or equal to the configured memory of the virtual machine is not determined from other servers in the target cluster where the failure has not occurred, the target memory actually required by the virtual machine in the first server can be predicted based on the historical memory usage of the virtual machine in the first server; specifically, an artificial intelligence (AI) algorithm is used, and based on the historical memory usage of the virtual machine in the first server, the target memory (i.e., RightSize memory) actually required and to be used by the virtual machine in the future is predicted.

[0075] Further, from other servers in the target cluster where the failure has not occurred, a server whose remaining computing memory is greater than or equal to the target memory and whose remaining configuration memory is greater than or equal to the virtual machine configuration memory is determined as the second server. The remaining configuration memory of the server can be understood as the actual remaining available memory in all the memories allocated to the virtual machines in the server. For example, the total memory allocated to all virtual machines in the server is 100G, the configuration memory of each virtual machine is 10G, and 8 virtual machines have been configured on the server. At this time, the remaining computing memory of the server is 20G; but each virtual machine actually uses only 8G of memory. At this time, the size of the remaining configuration memory of the server is 100G-8×8G=36G. In other words, if the remaining computing memory of the server is greater than or equal to the virtual machine configuration memory, it is considered that the memory resources in the server are sufficient; in this way, the waste of part of the memory that has been configured for the virtual machines in the server that is not actually used by the virtual machines can be reduced.

[0076] In this way, if there is no server in the target cluster whose remaining computing memory is greater than or equal to the target memory and whose remaining configuration memory is greater than or equal to the virtual machine configuration memory in other servers where the failure has not occurred, it can be determined that the scheduling has failed, and a scheduling failure prompt message can be fed back to the client.

[0077] It should be noted that in this embodiment, the virtual machine management platform provides an advanced resource (memory, CPU) reservation function. Users can customize the server resource reservation size according to the cluster virtual machine scale. This part of the resources will not be used by the system and virtual machine non-HA response. Figure 7 As shown, when a server fails and the virtual machine runs abnormally and needs HA response, if the remaining non-reserved resources are less than the virtual machine configuration resources, the reserved host resources can be used to immediately restore the virtual machine, reducing the risk of service failure recovery failure due to insufficient resources. In other words, the remaining computing memory and remaining configuration memory of the server mentioned in the above content are the remaining memory obtained under HA response, that is, they all include reserved resources.

[0078] Step S340: If the fault type is a network offline fault, determine a server that meets the first set condition from the target cluster as the second server, restart the virtual machine in the first server and switch it to the second server, or hot migrate the virtual machine in the first server to the second server.

[0079] Step S350: If the fault type is an application layer fault, restart the virtual machine in the first server.

[0080] In this embodiment, the specific implementation of step S340 to step S350 can refer to the content of the above-mentioned embodiment, which will not be repeated here.

[0081] In summary, please refer to Figure 8 In this application, when any type of failure occurs in the server, the corresponding fault handling strategy is called to schedule the server's virtual machine; if the server fails to run, the scheduling engine cannot successfully schedule the second server, then an alarm message will be output to indicate that the first server has a failure, and after a set period of sleep, the fault in the first server will be checked again to see if it has recovered. If not, the intelligent scheduling engine will be triggered again. In addition, in this embodiment, if the fault handling strategy fails to execute, the aforementioned alarm message will also be output. If it is executed successfully, the alarm of the first server will be marked as an automatic recovery indicator.

[0082] It should be noted that if the HA response fails, an alarm message will be output and the retry process will be entered. Each retry will be set at an interval, and the interval setting time is stepped up. As the number of retries increases, the time interval for waiting for the next retry will gradually increase. That is, in actual application, there may be a large number of abnormal virtual machines that need to be processed, and each abnormal virtual machine needs to be retried, which may consume a lot of resources and time. Therefore, the method of gradually increasing the retry time interval can reduce invalid retry operations and improve the utilization of system resources. At the same time, giving priority to other abnormal virtual machines can also make the entire system more stable and reliable.

[0083] In this embodiment, fault detection capabilities covering hardware, platform, and application levels are provided, and virtual machines are switched to servers in normal status, fully guaranteeing customer service continuity and stability. Secondly, multiple response methods are provided for users to flexibly configure. Finally, resource reservation and RightSize memory analysis capabilities are also provided to reduce the risk of HA response failure due to insufficient server resources.

[0084] Please refer to Fig. 9 , Fig. 9 A flowchart of a fault handling method provided in another embodiment of the present application is shown below. Fig. 9 The fault handling method provided in the embodiment of the present application is described in detail. The fault handling method may include the following steps:

[0085] Step S410: monitor the operating status of the server cluster corresponding to the virtual machine.

[0086] In this embodiment, the virtual machine management platform can detect whether the server in the server cluster is in a sub-healthy operating state based on a variety of server parameters. The various server parameters may include CPU microcode version identification, CPU temperature, Error Checking and Correcting (ECC) memory parameters, system disk life, server power status, server downtime times, and abnormal server hardware parameters.

[0087] Optionally, the virtual machine management platform can obtain the CPU microcode version identifier of each server, and determine whether the CPU microcode version identifier is lower than the preset microcode version identifier, that is, determine whether the CPU microcode version identifier has a problem of a lower version. If the CPU microcode version is too low, it will cause security vulnerabilities, performance risks and stability problems in the server. Therefore, the virtual machine management platform will determine that the server is in a sub-healthy operating state when it detects that the CPU microcode version of the server is too low. It should be noted that the CPU microcode version identifier can be a digital identifier, and the size of the digital identifier is positively correlated with the newness of the CPU microcode version, that is, the newer the CPU microcode version, the larger the digital identifier corresponding to the CPU microcode version; based on this, the aforementioned judgment of whether the CPU microcode version identifier is lower than the preset microcode version identifier can be to determine whether the CPU microcode version identifier is less than the preset microcode version identifier.

[0088] Optionally, the virtual machine management platform can also monitor the CPU temperature of the server in real time. If the CPU temperature is continuously high, it is easy to cause the server performance and reliability to decline, the system to be unstable, and the hardware to be damaged. Therefore, if it is monitored that the CPU temperature of the server is greater than the set temperature threshold within the first preset time, it is determined that the operation state of the server is a sub-healthy operation state.

[0089] Optionally, the virtual machine management platform can also monitor the ECC memory parameters of the server in real time, where ECC memory can be understood as a memory bar that uses error checking and correction technology (ECC), so as to determine the memory area with faults based on the ECC memory parameters. Specifically, it is determined whether the memory area is greater than the set memory threshold. If it is greater, it is determined that the area where the physical memory fault occurs in the ECC memory is large. At this time, the reliability and available memory resources of the server will be seriously reduced, and there is a greater risk of failure. Therefore, it can be determined that the server is in a sub-healthy operating state.

[0090] Optionally, the virtual machine management platform can also monitor the life span of the server's system disk in real time. If it is determined that the life span of the system disk is less than the second preset time, it is determined that the life span of the server's system disk is about to expire. At this time, the hardware performance will decline, affecting the platform performance, making it more likely that hardware damage will occur, and the reliability of the server will decline. Therefore, it is determined that the server is in a sub-healthy operating state. The detection of the life span of the server's system disk can be obtained by using a life prediction algorithm and combining relevant parameters of the system disk.

[0091] Optionally, the virtual machine management platform can also monitor the server power status of the server in real time. The server is generally in dual power mode, that is, there are two power modules supplying power to the server at the same time. If it is determined that only one power module of the server is currently in operation, it indicates that if the power module has an offline fault problem, it will cause the server to shut down, and there may also be insufficient power supply, and the reliability of the host is reduced. Therefore, if it is determined that only one power module of the server is currently in operation, the server is judged to be in a sub-healthy operation state.

[0092] Optionally, the virtual machine management platform can also count the number of server downtimes. If the number of server downtimes counted within a third preset time period is greater than a set threshold, it can be determined that the server may have repeatedly crashed due to reasons such as host quality and expiration of life. At this time, the server can also be determined to be in a sub-healthy operating state.

[0093] Optionally, the virtual machine management platform can also monitor abnormal hardware parameters of the server, including but not limited to CPU parameters, graphics card parameters, memory parameters, and hard disk parameters. Specifically, a pre-trained scoring model can be used, and the abnormal hardware parameters can be used as the input of the scoring model. Based on this, the scoring model will output a health score for the server. If the health score of the server is less than the set health score threshold, the server is determined to be in a sub-healthy operating state. It should be noted that the more abnormal hardware parameters there are, the lower the health score of the server, that is, the more abnormal hardware parameters there are on the server, the lower the reliability of the server, and therefore, the lower its health score.

[0094] It can be understood that when the CPU microcode version identifier of the server is not lower than the preset microcode version identifier, the CPU temperature of the server is not greater than the set temperature threshold within the first preset time period, the faulty memory area is less than or equal to the set memory threshold, the system disk life span is greater than or equal to the second preset time period, both power modules of the server are in operation, the number of server downtimes counted within the third preset time period is less than or equal to the set number threshold, and the server's health score is greater than or equal to the set health score threshold, then the server is determined to be in a healthy operating state.

[0095] Step S420: If the operating status of the first server is a sub-healthy operating status, determine a server that meets the second setting condition and is in a healthy operating status from the target cluster as the fourth server, and the target cluster includes other servers in the server cluster except the first server.

[0096] Step S430: hot migrating the virtual machine in the first server to the fourth server.

[0097] Specifically, combined Fig.10 It is explained that when it is determined that the running state of the first server is a sub-healthy running state, it is determined that there is a sub-healthy event on the first server, which will trigger the intelligent scheduling engine to schedule the server; that is, the intelligent scheduling engine schedules the server that meets the second setting condition and is in a healthy running state from the above-mentioned target cluster. If the server is successfully scheduled, the scheduled server is used as the fourth server, and the HA response phase is entered, that is, the virtual machine in the first server is hot migrated to the fourth server. If the hot migration is successful, a recovery prompt message is output, and the recovery prompt message is used to prompt that the virtual machine business in the server in the sub-healthy running state has been successfully hot migrated; if the hot migration is unsuccessful, an alarm prompt message is output, and the sleep setting time is set, and then the running state of the first server is further re-checked whether it is still in a sub-healthy running state. If it is not in a sub-healthy running state, the sleep setting time is set, and step S410 is executed again, that is, at regular intervals, the server will be monitored whether it is in a sub-healthy running state. If the re-checked first server is still in a sub-healthy state, the intelligent scheduling engine is triggered again to schedule the server for hot migration of the first server.

[0098] In some implementations, after determining the fourth server, it is further possible to determine whether the current time is within a set time period. If it is within the set time period, the virtual machine in the first server is hot migrated to the fourth server; if it is not within the set time period, the hot migration process is not performed, and the virtual machine in the first server is hot migrated to the fourth server after entering the set time period. The set time period can be a user's flexible setting of the hot migration response time period according to the actual virtual machine business characteristics, that is, hot migration within this time period can avoid affecting other businesses running on the virtual machine.

[0099] It should be noted that when a sub-health event occurs on the server, combined with the recommendation results of the intelligent scheduling engine, hot migration is used to switch the virtual machine from the sub-healthy server to the healthy server. During the whole process, the virtual machine business will not be interrupted and the user will not be aware of it. If the hot migration response fails, an alarm message will be output and the retry process will be entered. Each retry will be set at an interval, where the interval setting time is set in a step-by-step increment. As the number of retries increases, the time interval for waiting for the next retry will gradually increase. That is, in the actual application process, there may be a large number of abnormal virtual machines that need to be processed, and for each abnormal virtual machine, a retry is required, which may consume a lot of resources and time. Therefore, the method of gradually increasing the retry time interval can reduce invalid retry operations and improve the utilization of system resources. At the same time, giving priority to other abnormal virtual machines can also make the entire system more stable and reliable.

[0100] The specific implementation of the intelligent scheduling engine for scheduling the fourth server can be found in the aforementioned Figure 5 The scheduling flow chart shown will not be repeated here.

[0101] In some embodiments, see Fig.11 , Fig.11 The flowchart of the relocation algorithm used by the intelligent scheduling engine when scheduling servers is shown. Specifically, the intelligent scheduling engine performs the first intelligent scheduling without considering relocation of other virtual machines. If the scheduling destination server is successfully generated (i.e., a healthy server with sufficient remaining space for hot migration of the virtual machine of the first server is successfully found), the scheduling is successful; if the scheduling fails, the second intelligent scheduling is performed, combined with the relocation algorithm, to try to generate a feasible HA scheduling plan. For example, first try to migrate a virtual machine with less resource usage on healthy server 1 to healthy server 2, so that healthy server 1 can provide more operational resource space for the virtual machine business in the first server.

[0102] Optionally, the above-mentioned relocation algorithm can be an algorithm for relocating only one virtual machine, that is, relocating the virtual machine in the server with insufficient remaining resource space to another server with insufficient remaining resource space, so that the relocated server can provide sufficient resource space for the virtual machine in the first server to perform hot migration. In other words, by using the algorithm for relocating only one virtual machine, a relocation migration suggestion and an HA virtual machine migration suggestion can be generated. For example, please refer to Fig.12 , when server A is in a sub-healthy state, the memory space occupied by virtual machine VMA1 in server A is 64G, while the memory space occupied by virtual machine VMB1 in server B, which is in a healthy state, is 32G, and the memory space occupied by virtual machine VMB2 is 64G. The memory space occupied by virtual machine VMC1 in server C, which is in a healthy state, is 16G, and the memory space occupied by virtual machine VMC2 is 64G. Obviously, at this time, the remaining space of server B and server C is 32G and 48G respectively. If the virtual machine is not moved, server B and server C are not enough to accommodate the virtual machine VMA1 to be hot migrated, that is, the destination server cannot be successfully scheduled. At this time, the virtual machine VMB1 in server B can be moved to server C, so that there is enough resource space in server B for VMA1 to run, and then VMA1 in server A is hot migrated to the moved server B.

[0103] Optionally, the above migration algorithm can also be a chain migration of two virtual machines, that is, when the first server is in a sub-healthy operating state, it is necessary to hot migrate the virtual machines in the first server to other healthy servers, and it is necessary to chain the virtual machines on the two healthy servers to have enough resource space for the first server's virtual machine to run. In other words, two migration suggestions and one HA virtual machine migration suggestion are generated. For example, please refer to Fig.13 , when server A is in a sub-healthy state, the memory space occupied by virtual machine VMA1 in server A is 64G, while the memory space occupied by virtual machine VMB1 in server B which is in a healthy state is 32G, and the memory space occupied by virtual machine VMB2 is 64G. The memory space occupied by virtual machine VMC1 in server C which is in a healthy state is 16G, the memory space occupied by virtual machine VMC2 is 32G, and the memory space occupied by virtual machine VMC3 is 64G; the memory space occupied by virtual machine VMD1 in server D which is in a healthy state is 16G, the memory space occupied by virtual machine VMD2 is 32G, and the memory space occupied by virtual machine VMD3 is 64G. Obviously, at this time, the remaining space of server B, server C and server D is 32G, 16G and 16G respectively. If only one virtual machine is moved, server B, server C and server D are still not enough to accommodate virtual machine VMA1 to be hot migrated, that is, the destination server cannot be successfully scheduled. At this time, the virtual machine VMC1 in server C can be moved to server D, and the virtual machine VMB1 in server B can be moved to server C, so that there is enough remaining resource space in server B for VMA1 to run, and then VMA1 in server A can be hot migrated to the relocated server B.

[0104] Optionally, the above-mentioned relocation algorithm can also be a swapping relocation of two virtual machines, that is, when the first server is in a sub-healthy operating state, it is necessary to hot migrate the virtual machines in the first server to other healthy servers, and it is necessary to swap the virtual machines on the two healthy servers to have enough resource space for the first server's virtual machines to run; that is to say, the virtual machine with smaller resource usage on the server with smaller remaining resources is swapped with the virtual machine with larger resource usage on the server with larger remaining resource space. Finally, two relocation migration suggestions and one HA virtual machine migration suggestion are generated. For example, please refer to Fig.14, when server A is in a sub-healthy state, the memory space occupied by virtual machine VMA1 in server A is 64G, while the memory space occupied by virtual machine VMB1 in server B which is in a healthy state is 32G, and the memory space occupied by virtual machine VMB2 is 48G. The memory space occupied by virtual machine VMC1 in server C which is in a healthy state is 16G, and the memory space occupied by virtual machine VMC2 is 96G. Obviously, at this time, the remaining space of server B and server C is 48G and 16G respectively, and both server B and server C are not enough to accommodate virtual machine VMA1 to be hot migrated, that is, the destination server cannot be successfully scheduled. At this time, virtual machine VMC1 in server C can be moved to server B, and then virtual machine VMB1 in server B can be exchanged and moved to server C, so that there is enough remaining resource space in server B for VMA1 to run, and then VMA1 in server A can be hot migrated to server B after the move.

[0105] That is to say, Fig.15 As shown, in a server cluster composed of multiple servers, when the operating status of any server is in a sub-healthy state and is likely to have a significant impact on the business of the virtual machines running in the server, the cluster high availability (High Availability, HA) service will promptly and proactively hot migrate the virtual machines to other servers in the cluster that are in a healthy state.

[0106] In some embodiments, see Fig.16 , each server can be pre-arranged periodically, and the server abnormality (i.e., in a sub-healthy operating state) can be simulated to require HA response, and the feasible HA scheduling scheme for each virtual machine running on the server can be inferred through the intelligent scheduling engine. If the remaining resources of any server in the server cluster cannot meet the HA of all virtual machines on the host, an HA mechanism failure risk alarm will be output to prompt the user to reduce the risk of virtual machine HA failure failure in advance by adjusting the cluster virtual machine running location, host resource reservation, and capacity expansion.

[0107] Step S440: If a failure occurs in the operation of the first server, a failure type of the failure is determined based on the operation parameters of the first server, where the first server is any server in the server cluster.

[0108] Step S450: calling a fault handling strategy corresponding to the fault type to schedule the virtual machine in the first server.

[0109] It is understandable that if the first server is in a healthy operating state, there is no need to execute the aforementioned steps S420 to S430; of course, even if the first server is in a healthy operating state, its operation may still suddenly fail. Based on this, when the operation of the first server suddenly fails, steps S440 to S450 can be executed. The specific implementation of steps S440 to S450 can refer to the content of the aforementioned embodiment, which will not be repeated here. Optionally, after step S430, the fourth server may also suddenly fail. For the failed fourth server, it can also be scheduled and processed for the virtual machine in a manner similar to the HA response processing of the first server. The specific implementation can refer to the aforementioned content, which will not be repeated here.

[0110] In this embodiment, when a sub-healthy server is detected, the virtual machine on the sub-healthy server is hot migrated to a healthy server before the server is seriously affected, identifying risks in advance, greatly reducing the risk of virtual machine business interruption in the event of future failures, and ensuring customer business continuity. Secondly, it provides fragmented resource integration and resource pre-arrangement capabilities to reduce the risk of HA response failure due to insufficient server resources.

[0111] Please refer to Fig.17 , which shows a structural block diagram of a fault processing device 500 provided in an embodiment of the present application. The device 500 may include: an operation monitoring module 510, a fault type determination module 520 and a fault processing module 530.

[0112] The operation monitoring module 510 is used to monitor the operation status of the server cluster corresponding to the virtual machine.

[0113] The fault type determination module 520 is used to determine the fault type of the first server based on the operating parameters of the first server if a fault occurs during operation of the first server, where the first server is any server in the server cluster.

[0114] The fault processing module 530 user calls the fault processing strategy corresponding to the fault type to schedule the virtual machine in the first server.

[0115] In some embodiments, the fault handling module 530 may include: a first fault handling unit, a second fault handling unit, and a third fault handling unit. The first fault handling unit may be used to, if the fault type is a hardware layer fault, determine a server that meets the first set condition from the target cluster as the second server, restart the virtual machine in the first server and switch it to the second server, and the target cluster includes other servers in the server cluster except the first server. The second fault handling unit may be used to, if the fault type is a network offline fault, determine a server that meets the first set condition from the target cluster as the second server, restart the virtual machine in the first server and switch it to the second server, or hot migrate the virtual machine in the first server to the second server. The third fault handling unit may be used to, if the fault type is an application layer fault, restart the virtual machine in the first server.

[0116] In this manner, the second fault handling unit may include: a server determination subunit and a fault handling subunit. Among them, the server determination subunit may be used to determine a server that meets the first set condition from the target cluster as the second server if the fault type is a network offline fault. The fault handling subunit may be used to restart the virtual machine in the first server and switch it to the second server for operation if the network offline fault is a storage network offline fault; restart the virtual machine in the first server and switch it to the second server for operation if the network offline fault is a business network offline fault or a data communication network offline fault, or hot migrate the virtual machine in the first server to the second server; hot migrate the virtual machine in the first server to the second server if the network offline fault is a terminal communication network offline fault.

[0117] In some embodiments, the server determination subunit can be specifically used to obtain the virtual machine configuration memory of the virtual machine in the first server; and determine, from other servers in the target cluster where the failure has not occurred, a server whose remaining computing memory is greater than or equal to the virtual machine configuration memory as the second server.

[0118] In this manner, the server determination subunit can also be specifically used for: if it is determined that there are multiple servers whose remaining computing memory is greater than the configured memory of the virtual machine from other servers in the target cluster where the failure has not occurred, then the multiple determined servers are used as multiple third servers; using a pre-trained scoring model and based on multiple operating parameters of each of the third servers, scoring each of the third servers to obtain an operating score for each of the third servers; and determining the third server with the highest operating score from among the multiple third servers as the second server.

[0119] In other embodiments, the server determination subunit can also be specifically used for: if a server whose remaining computing memory is greater than or equal to the virtual machine configuration memory is not determined from other servers in the target cluster where the failure has not occurred, then based on the historical memory usage of the virtual machines in the first server, predicting the target memory actually required by the virtual machines in the first server; and determining a server whose remaining computing memory is greater than or equal to the target memory and whose remaining configuration memory is greater than or equal to the virtual machine configuration memory from other servers in the target cluster where the failure has not occurred as the second server.

[0120] In some embodiments, the fault handling device 500 may further include: a fault prevention processing module. The fault prevention processing module may be specifically used for, before determining the fault type of the fault based on the operating parameters of the first server, if the first server is in a sub-healthy operating state, determining a server that meets the second set condition and is in a healthy operating state from the target cluster as the fourth server, the target cluster including other servers in the server cluster except the first server; and hot migrating the virtual machine in the first server to the fourth server.

[0121] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here.

[0122] In several embodiments provided in the present application, the coupling between modules may be electrical, mechanical or other forms of coupling.

[0123] In addition, each functional module in each embodiment of the present application can be integrated into a processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The above integrated modules can be implemented in the form of hardware or software functional modules.

[0124] To sum up, firstly, when a server in sub-healthy operation is detected, the present application hot migrates the virtual machine on the sub-healthy server to a healthy server before the server is seriously affected, identifies risks in advance, greatly reduces the risk of virtual machine business interruption in the event of future failures, and ensures customer business continuity. Secondly, it provides fragmented resource integration and resource pre-orchestration capabilities to reduce the risk of HA response failure due to insufficient server resources. Secondly, the present application also provides fault detection capabilities covering the three levels of hardware, platform, and application, switches the virtual machine to a server in a normal state, and comprehensively guarantees customer business continuity and stability. Secondly, it provides a variety of response methods for users to flexibly configure. Finally, it also provides resource reservation and RightSize memory analysis capabilities to reduce the risk of HA response failure due to insufficient server resources.

[0125] The following will be combined Fig.18 A computer device provided by the present application is described.

[0126] Reference Fig.18 , Fig.18 The structural block diagram of a computer device 600 provided in an embodiment of the present application is shown, and the above method provided in an embodiment of the present application can be executed by the computer device 600. The computer device can be a server, and the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, network acceleration services (Content Delivery Network, CDN), and big data and artificial intelligence platforms.

[0127] The computer device 600 in the embodiment of the present application may include one or more of the following components: a processor 601, a memory 602, and one or more applications, wherein the one or more applications may be stored in the memory 602 and configured to be executed by one or more processors 601, and the one or more programs are configured to execute the method as described in the aforementioned method embodiment.

[0128] The processor 601 may include one or more processing cores. The processor 601 uses various interfaces and lines to connect the various parts of the entire computer device 600, and executes various functions and processes data of the computer device 600 by running or executing instructions, programs, code sets or instruction sets stored in the memory 602, and calling data stored in the memory 602. Optionally, the processor 601 can be implemented in at least one hardware form of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), and programmable logic array (Programmable Logic Array, PLA). The processor 701 can integrate one or a combination of a central processing unit (Central Processing Unit, CPU), a graphics processing unit (Graphics Processing Unit, GPU) and a modem. Among them, the CPU mainly processes the operating system, user interface and application programs; the GPU is responsible for rendering and drawing display content; and the modem is used to process wireless communications. It can be understood that the above-mentioned modem can also be integrated into the processor 601 and implemented separately through a communication chip.

[0129] The memory 602 may include a random access memory (RAM) or a read-only memory (ROM). The memory 602 may be used to store instructions, programs, codes, code sets or instruction sets. The memory 602 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the following various method embodiments, etc. The data storage area may also store data (such as the various corresponding relationships described above) created by the computer device 600 during use.

[0130] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here.

[0131] In several embodiments provided in the present application, the coupling or direct coupling or communication connection between the modules shown or discussed may be an indirect coupling or communication connection through some interfaces, devices or modules, which may be electrical, mechanical or other forms.

[0132] In addition, each functional module in each embodiment of the present application can be integrated into a processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The above integrated modules can be implemented in the form of hardware or software functional modules.

[0133] Please refer to Fig.19 , which shows a structural block diagram of a computer-readable storage medium provided in an embodiment of the present application. The computer-readable medium 700 stores program codes, which can be called by a processor to execute the method described in the above method embodiment.

[0134] The computer readable storage medium 700 may be an electronic memory such as a flash memory, an EEPROM (electrically erasable programmable read-only memory), an EPROM, a hard disk, or a ROM. Optionally, the computer readable storage medium 700 includes a non-transitory computer-readable storage medium. The computer readable storage medium 700 has storage space for program code 710 that performs any method step of the above method. These program codes can be read from or written to one or more computer program products. The program code 710 can be compressed, for example, in an appropriate form.

[0135] In some embodiments, a computer program product or computer program is provided, the computer program product or computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device performs the steps in the above-mentioned method embodiments.

[0136] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A fault handling method, characterized in that: The method comprises: Monitor the operating status of the server cluster corresponding to the virtual machine; If a failure occurs in the operation of the first server, determining the failure type of the failure based on the operation parameters of the first server, the first server being any server in the server cluster; A fault handling strategy corresponding to the fault type is called to schedule the virtual machine in the first server.

2. The method according to claim 1, characterized in that The calling of the fault handling strategy corresponding to the fault type to schedule the virtual machine service in the first server includes: If the fault type is a hardware layer fault, a server that meets the first set condition is determined from the target cluster as the second server, and the virtual machine in the first server is restarted and switched to the second server, and the target cluster includes other servers in the server cluster except the first server; If the fault type is a network offline fault, determining a server that meets the first set condition from the target cluster as the second server, restarting the virtual machine in the first server and switching it to the second server, or hot migrating the virtual machine in the first server to the second server; If the fault type is an application layer fault, restart the virtual machine in the first server.

3. The method according to claim 2, characterized in that If the fault type is a network offline fault, determining a server that meets the first set condition from the target cluster as the second server, restarting the virtual machine in the first server and switching it to the second server, or hot migrating the virtual machine in the first server to the second server, includes: If the fault type is a network offline fault, determining a server that meets the first set condition from the target cluster as the second server; If the network offline fault is a storage network offline fault, restarting the virtual machine in the first server and switching it to the second server for operation; If the network offline failure is a service network offline failure or a data communication network offline failure, restarting the virtual machine in the first server and switching it to the second server for operation, or hot migrating the virtual machine in the first server to the second server; If the network offline failure is a terminal communication network offline failure, hot migration of the virtual machine in the first server to the second server is performed.

4. The method according to claim 2, characterized in that: The step of determining, from the target cluster, a server that meets the first set condition as a second server includes: Obtaining a virtual machine configuration memory of the virtual machine in the first server; From other servers in the target cluster where the failure has not occurred, determine a server whose remaining computing memory is greater than or equal to the configured memory of the virtual machine as the second server.

5. The method according to claim 4, characterized in that The method further comprises: If no server whose remaining computing memory is greater than or equal to the configured memory of the virtual machine is determined from other servers in the target cluster where the failure has not occurred, predicting the target memory actually required by the virtual machine in the first server based on the historical memory usage of the virtual machine in the first server; From other servers in the target cluster where the failure has not occurred, determine a server whose remaining computing memory is greater than or equal to the target memory and whose remaining configuration memory is greater than or equal to the virtual machine configuration memory as the second server.

6. The method according to claim 2, characterized in that The step of determining, from other servers in the target cluster where the failure has not occurred, a server having a remaining computing memory greater than the configured memory of the virtual machine as the second server, includes: If it is determined that there are multiple servers whose remaining computing memory is greater than the configured memory of the virtual machine from other servers in the target cluster where the failure has not occurred, the multiple servers determined are used as multiple third servers; Using a pre-trained scoring model and based on the operating parameters of each of the third servers, scoring each of the third servers to obtain an operating score of each of the third servers; A third server with the highest operation score is determined from among the multiple third servers as the second server.

7. The method according to any one of claims 1 to 6, characterized in that: Before determining the fault type of the fault based on the operating parameters of the first server if the first server fails during operation, the method further includes: If the running state of the first server is a sub-healthy running state, determining a server that meets the second setting condition and is in a healthy running state from the target cluster as a fourth server, the target cluster including other servers in the server cluster except the first server; Hot migrate the virtual machine in the first server to the fourth server.

8. A fault handling device, characterized in that: The device comprises: An operation monitoring module is used to monitor the operation status of the server cluster corresponding to the virtual machine; a fault type determination module, configured to determine the fault type of a first server based on an operation parameter of the first server if a fault occurs during operation of the first server, wherein the first server is any server in the server cluster; The fault processing module is used to call a fault processing strategy corresponding to the fault type to schedule the virtual machine in the first server.

9. A computer device, characterized in that: The computer device comprises: one or more processors; Memory; One or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program code, which can be called by a processor to execute the method according to any one of claims 1 to 7.

Images