Fault handling methods, devices and equipment

Abstract

The present application relates to the field of cloud computing technology, and discloses a fault handling method, device and equipment, including: obtaining the scheduling policy and affinity group corresponding to the host to be processed, the host to be processed is a virtual machine set in the faulty host, the faulty host is a physical host that fails in the host cluster, and the scheduling policy is an affinity policy or an anti-affinity policy; selecting a target physical host from the host cluster based on the scheduling policy and the affinity group; migrating the host to be processed to the target physical host. Since scheduling is performed according to the scheduling policy set when each virtual machine is created and the affinity group to which it belongs, and selecting a suitable physical host for evacuation and migration, it can be ensured that high-priority virtual machines are not in the same physical host as much as possible, and it can be ensured that when a single physical host fails, the impact on the business can be minimized as much as possible, thereby improving the high availability of the cloud computing platform.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a fault handling method, device and equipment. Background Art

[0002] A cloud computing platform is a platform that uses cloud computing software to form a resource pool with one or more hardware devices to provide computing, storage, and network resources. High availability is an important feature of the cloud computing platform. High availability means that when a physical host in the host cluster of the cloud computing platform fails and can no longer provide services, the virtual machines (also called cloud hosts) running on the physical host will be evacuated and migrated to other normal physical hosts to ensure the normal use of the virtual machines and unaffected business.

[0003] In the related high-availability technologies, when virtual machines are created, they are not scheduled according to priority, and multiple high-priority virtual machines may be scheduled to the same physical host. When the physical host fails, there are many high-priority core virtual machines, and their failure recovery time is also long, which has a greater impact on the business. In addition, during migration, the priority scheduling of each virtual machine is still not considered. During migration, high-priority core virtual machines may still be migrated to the same physical host. If the physical host fails again after migration, it will again have a greater impact on the business. Summary of the invention

[0004] The main purpose of this application is to provide a fault handling method, device and equipment, aiming to solve the technical problem that when the relevant technology creates and migrates virtual machines in the cloud computing platform, the priority of the virtual machine is not considered, which will cause a great impact on the business of the cloud computing platform when a fault occurs.

[0005] To achieve the above objectives, the present application proposes a fault handling method, which includes:

[0006] Obtaining a scheduling policy corresponding to a host to be processed and an affinity group to which it belongs, wherein the host to be processed is a virtual machine set in a faulty host, the faulty host is a physical host that fails in a host cluster, and the scheduling policy is an affinity policy or an anti-affinity policy;

[0007] Selecting a target physical host from a host cluster based on the scheduling policy and the affinity group to which it belongs;

[0008] Migrate the host to be processed to the target physical host.

[0009] In a possible implementation of the present application, at least one virtual machine is provided in the faulty host;

[0010] The step of obtaining the scheduling policy corresponding to the host to be processed and the affinity group to which it belongs includes:

[0011] Obtaining the host priority corresponding to each virtual machine in the faulty host, where the host priority is used to represent the importance of each virtual machine;

[0012] Sort the virtual machines in the failed host based on the host priority and generate a host processing sequence;

[0013] Extracting a host to be processed from the host processing sequence;

[0014] Obtain the scheduling policy corresponding to the host to be processed and the affinity group to which it belongs.

[0015] In a possible implementation of the present application, before obtaining the scheduling policy corresponding to the host to be processed and the affinity group to which it belongs, the process further includes:

[0016] Monitor the performance of each physical host in the host cluster;

[0017] When any physical host in the host cluster is detected to have abnormal performance, the physical host with abnormal performance is used as a host to be determined;

[0018] Get the historical abnormal count of the host to be judged;

[0019] Updating the historical exception count to obtain a current exception count;

[0020] If the current abnormality count is greater than the abnormality count threshold, the host to be judged is regarded as a faulty host;

[0021] A host to be processed is determined according to the virtual machines in the faulty host.

[0022] In a possible implementation of the present application, obtaining the scheduling policy corresponding to the host to be processed and the affinity group to which it belongs includes:

[0023] Obtaining a host priority and / or a policy identifier corresponding to a host to be processed, and obtaining host identification information of the host to be processed;

[0024] The scheduling policy corresponding to the host to be processed is determined according to the host priority and / or the policy identifier, and the affinity group corresponding to the host to be processed is searched based on the host identification information.

[0025] In a possible implementation of the present application, selecting a target physical host from a host cluster based on the scheduling policy and the affinity group to which the target physical host belongs includes:

[0026] If the scheduling strategy is an affinity strategy, searching for a candidate physical host in the host cluster that is provided with a virtual machine belonging to the affinity group, and selecting a target physical host from the candidate physical hosts;

[0027] or,

[0028] If the scheduling policy is an anti-affinity policy, a candidate physical host is searched in the host cluster for which no virtual machine belonging to the affinity group is configured, and a target physical host is selected from the candidate physical hosts.

[0029] In a possible implementation of the present application, after migrating the host to be processed to the target physical host, the method further includes:

[0030] When the migration fails, a low-priority host among normal physical hosts in the host cluster is obtained, where the normal physical host is a physical host with normal performance in the host cluster;

[0031] Building a host shelving queue according to the low-priority host, and shelving the low-priority host;

[0032] After the processing is completed, return to the step of selecting a target physical host in the host cluster based on the scheduling policy and the affinity group.

[0033] In a possible implementation of the present application, the step of putting the low-priority host on hold includes:

[0034] The device resources occupied by the low-priority host are released, and the host disk data of the low-priority host is saved.

[0035] In a possible implementation of the present application, after migrating the host to be processed to the target physical host, the method further includes:

[0036] Extracting a host to be restored from the host hold queue, and obtaining cluster resource information of the host cluster;

[0037] If the cluster resource information meets the recovery resource requirement of the host to be recovered, then performing an anti-holding process on the host to be recovered;

[0038] When the processing is completed, return to the step of extracting the host to be restored from the host holding queue and obtaining the cluster resource information of the host cluster.

[0039] In addition, to achieve the above purpose, the present application also proposes a fault handling device, the device comprising:

[0040] An acquisition module is used to acquire a scheduling policy corresponding to a host to be processed and an affinity group to which it belongs, wherein the host to be processed is a virtual machine set in a faulty host, the faulty host is a physical host that fails in a host cluster, and the scheduling policy is an affinity policy or an anti-affinity policy;

[0041] A selection module, used for selecting a target physical host from a host cluster based on the scheduling policy and the affinity group to which it belongs;

[0042] A migration module is used to migrate the host to be processed to the target physical host.

[0043] In addition, to achieve the above-mentioned purpose, the present application also proposes a fault handling device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the fault handling method as described above.

[0044] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the fault handling method described above are implemented.

[0045] In addition, to achieve the above-mentioned purpose, the present application also proposes a computer program product, wherein the computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the fault handling method described above are implemented.

[0046] One or more technical solutions proposed in this application have at least the following technical effects:

[0047] Since scheduling will be performed based on the scheduling policy set when each virtual machine is created and the affinity group to which it belongs, and the appropriate physical host will be selected for evacuation and migration, it can be ensured that high-priority virtual machines are not in the same physical host as much as possible, ensuring that when a single physical host fails, the impact on the business can be minimized, thereby improving the high availability of the cloud computing platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0049] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0050] Figure 1 A flowchart of the first embodiment of the troubleshooting method of the present application is provided;

[0051] Figure 2 This is a schematic diagram of the functional modules of a fault handling device according to an embodiment of the present application;

[0052] Figure 3 A schematic diagram of a cloud host creation process according to an embodiment of the present application;

[0053] Figure 4 A schematic diagram of creating a group for a host according to an embodiment of the present application;

[0054] Figure 5 A flowchart of the second embodiment of the fault handling method of the present application is provided;

[0055] Figure 6 This is a schematic diagram of the overall fault handling process of an embodiment of the present application;

[0056] Figure 7 A schematic diagram of a process of restoring a suspended host according to an embodiment of the present application;

[0057] Figure 8 This is a schematic diagram of the module structure of the fault handling device according to an embodiment of the present application;

[0058] Fig. 9 A schematic diagram of the device structure of the hardware operating environment involved in the fault handling method in the embodiment of the present application.

[0059] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0060] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0061] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0062] Based on this, the present application embodiment provides a fault handling method, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the fault handling method of the present application.

[0063] In this embodiment, the fault handling method includes steps S10 to S30:

[0064] Step S10: Obtain the scheduling policy corresponding to the host to be processed and the affinity group to which it belongs.

[0065] It should be noted that the executor of this embodiment can be a cloud computing platform, or a fault handling device set in the cloud computing platform, or a fault handling device independent of the cloud computing platform but capable of monitoring and controlling the cloud computing platform. The fault handling device can be an electronic device such as a personal computer or a server, or other devices that can achieve the same or similar functions. This embodiment does not impose any restrictions on this. In this embodiment and the following embodiments, the fault handling method of this application is described by taking a fault handling device as an example.

[0066] It should be noted that the host to be processed may be a virtual machine (also called a cloud host) set in the faulty host, the faulty host is a physical host that has a fault in the host cluster constituting the cloud computing platform, the scheduling policy is an affinity policy or an anti-affinity policy, and the affinity group corresponding to the host to be processed may be the affinity group to which the host to be processed is assigned.

[0067] Among them, the role of affinity groups varies depending on the scheduling policy. For example, if the scheduling policy is an affinity policy, the virtual machines assigned to the same affinity group will be set in the same physical host as much as possible; if the scheduling policy is an anti-affinity policy, the virtual machines assigned to the same affinity group will be assigned to different physical hosts as much as possible.

[0068] In a specific implementation, the affinity policy and the affinity group to which it belongs are set for a virtual machine when it is first created. For example, when a virtual machine is added to a cloud computing platform, the corresponding affinity policy and affinity group need to be set for the virtual machine when it is created.

[0069] In a possible implementation of this embodiment, the scheduling policy may be set based on the host priority and / or the policy identifier. In this case, step S10 of this embodiment may include:

[0070] Obtaining a host priority and / or a policy identifier corresponding to a host to be processed, and obtaining host identification information of the host to be processed;

[0071] The scheduling policy corresponding to the host to be processed is determined according to the host priority and / or the policy identifier, and the affinity group corresponding to the host to be processed is searched based on the host identification information.

[0072] It should be noted that a corresponding scheduling policy can be set for each virtual machine. In order to distinguish the scheduling policies of each virtual machine, a corresponding policy identifier can be set for each virtual machine. The scheduling policy corresponding to the virtual machine can be distinguished by the policy identifier. For example: if the policy identifier is 0, the scheduling policy is determined to be an affinity policy; if the policy identifier is 1, the scheduling policy is determined to be an anti-affinity policy.

[0073] In actual application, the more anti-affinity policies are applied, the more difficult it is to schedule virtual machines and determine the physical host on which the virtual machines should be set. Therefore, the scheduling policy of high-priority virtual machines can be set to an anti-affinity policy. For example, high-priority virtual machines will automatically join anti-affinity and set up anti-affinity groups for them to ensure that high-priority virtual machines are scheduled on different hosts as much as possible to reduce the impact of failures.

[0074] In this case, there is no need to use the policy identifier, but instead the scheduling policy for the host to be processed can be determined directly based on the host priority corresponding to the host to be processed. For example: if the host priority is greater than level s, the scheduling policy is determined to be an anti-affinity policy; if the host priority is less than or equal to level s, the scheduling policy is determined to be an affinity policy, where s is the preset priority threshold.

[0075] Of course, in some cases, some high-priority virtual machines may need to be in the same physical host as other high-priority virtual machines due to business needs. In order to ensure that this situation can be dealt with, the host priority can be combined with the policy identifier to determine the scheduling policy. For example: first determine whether the host priority is greater than level s. If it is less than or equal to level s, the scheduling policy is determined to be an affinity policy; if it is greater than level s, further detect the policy identifier. If the policy identifier is 0, the scheduling policy is determined to be an affinity policy; if the policy identifier is 1, the scheduling policy is determined to be an anti-affinity policy.

[0076] Step S20: Select a target physical host from the host cluster based on the scheduling policy and the affinity group to which it belongs.

[0077] It should be noted that the target physical host may be a migration target when migrating the host to be processed.

[0078] In actual use, based on the scheduling policy corresponding to the host to be processed and the affinity group to which it belongs, it can be determined which part of the virtual machines the host to be processed should be on the same physical host or which part of the virtual machines should be on different physical hosts. Based on this, the physical hosts in the host cluster that can currently be selected as migration targets can be determined and selected as the target physical hosts.

[0079] There may be multiple physical hosts that can be selected as the migration target of the host to be processed. In this case, a random selection method can be adopted to select one as the target physical host, or a physical host with the lowest current load can be selected as the target physical host.

[0080] In a possible implementation of the present application, in order to ensure reasonable selection of the target physical host, step S20 in this embodiment may include:

[0081] If the scheduling strategy is an affinity strategy, searching for a candidate physical host in the host cluster that is provided with a virtual machine belonging to the affinity group, and selecting a target physical host from the candidate physical hosts;

[0082] or,

[0083] If the scheduling policy is an anti-affinity policy, a candidate physical host is searched in the host cluster for which no virtual machine belonging to the affinity group is configured, and a target physical host is selected from the candidate physical hosts.

[0084] It should be noted that if the scheduling policy of the host to be processed is an affinity policy, it means that the virtual machine needs to be on the same physical host as the virtual machines in the affinity group as much as possible. At this time, you can search the host cluster for physical hosts that are equipped with virtual machines belonging to the affinity group, and use the found physical hosts as candidate physical hosts, and then select one of them as the target physical host.

[0085] Among them, when selecting, one can be randomly selected from the candidate physical hosts as the target physical host, or the candidate physical host with the largest number of virtual machines belonging to the affinity group can be selected as the target physical host. Of course, the candidate physical host with the lowest current load (such as the lowest CPU resource occupancy ratio, the lowest memory occupancy ratio, or the lowest combined CPU and memory occupancy ratio) can also be selected as the target physical host.

[0086] In actual use, if the scheduling policy of the host to be processed is an anti-affinity policy, it means that the virtual machine needs to be on a physical host that is as different from the virtual machines in the affinity group as possible. Therefore, a physical host in the host cluster that does not have any virtual machine belonging to the affinity group can be searched, and the found physical host can be used as the candidate physical host.

[0087] When selecting, random selection or selection of the candidate physical host with the lowest current load may be adopted as the target physical host.

[0088] In the specific implementation, in some cases, due to the limitation on the number of physical hosts in the host cluster corresponding to the cloud computing platform, all physical hosts may be set with candidate physical hosts for virtual machines belonging to their affinity groups. At this time, in order to ensure that the hosts to be processed can be migrated, the physical host with the least number of virtual machines belonging to their affinity groups can be used as the candidate physical host.

[0089] Step S30: Migrate the host to be processed to the target physical host.

[0090] It should be noted that after the target physical host is determined, the host to be processed can be migrated to the target physical host.

[0091] Among them, during the migration process, if the data in the failed physical host where the host to be processed was originally located can be read, the host data of the host to be processed (such as disk data, configuration data, etc.) can be read from it, and migration is performed according to the read host data; if the data in the failed physical host where the host to be processed was originally located cannot be read, the most recent backup data of the host to be processed can be obtained, and migration is performed according to the backup data.

[0092] In a possible implementation of this embodiment, in order to avoid misjudgment of a fault, before step S10 in this embodiment, the following steps may be further included:

[0093] Monitor the performance of each physical host in the host cluster;

[0094] When any physical host in the host cluster is detected to have abnormal performance, the physical host with abnormal performance is used as a host to be determined;

[0095] Get the historical abnormal count of the host to be judged;

[0096] Updating the historical exception count to obtain a current exception count;

[0097] If the current abnormality count is greater than the abnormality count threshold, the host to be judged is regarded as a faulty host;

[0098] A host to be processed is determined according to the virtual machines in the faulty host.

[0099] It should be noted that the judgment conditions for detecting abnormal performance of the physical host can be pre-set by the administrator of the fault handling device, for example: the network speed is lower than the preset threshold, the CPU occupancy rate is higher than the preset rate, the response time is longer than the preset time, etc.

[0100] In actual use, since the network may fluctuate and the equipment calculation may be occupied suddenly, this situation may also lead to the detection of physical host performance abnormalities. If a fault is determined after detection once, it may lead to misjudgment. In order to avoid this situation, each time an abnormality is detected, an abnormality count can be performed on the physical host. Therefore, when a performance abnormality is detected in any physical host in the host cluster, the physical host with the performance abnormality can be used as the host to be judged. After that, the historical abnormality count of the host to be judged is obtained, and then it is updated (such as adding 1. Of course, different values ​​can also be updated according to different detected abnormality categories, such as adding 1 for network abnormalities and adding 2 for response abnormalities). The current abnormality count is determined, that is, the total number of times the physical host is detected to have performance abnormalities at the current moment. If the current abnormality count is greater than the abnormality count threshold, it means that the performance abnormality of the host to be judged has been detected multiple times. Therefore, the host to be judged can be regarded as a faulty host.

[0101] The host to be processed is determined according to the virtual machine in the faulty host, which may be selected from the virtual machines set in the faulty host as the host to be processed.

[0102] For ease of understanding, now combined Figure 2 , 3 , 4 are used to illustrate but not to limit this solution. Figure 2 This is a schematic diagram of the functional modules of the fault handling device of this embodiment. Figure 3 This is a schematic diagram of the cloud host creation process of this embodiment. Figure 4 A schematic diagram of grouping created for the hosts in this embodiment.

[0103] like Figure 2 As shown, the fault handling device described in this embodiment may include four modules, and the four modules cooperate to perform fault handling. The four modules include: a host monitoring module, a fault handling module, a cloud host management module and a cloud host scheduling module.

[0104] The purpose of each module is as follows:

[0105] Host monitoring module: detects the physical host, including the physical network, CPU, memory, power status, operating system, etc., and supports setting the detection interval and number of times. In order to prevent network jitter, the physical host is considered to be faulty only when the number of consecutive failures is greater than N times;

[0106] Fault handling module: After detecting a physical host failure, it performs fault handling operations on the cloud host (i.e., virtual machine) on the physical host, including obtaining priority, sorting by priority, and initiating evacuation instructions;

[0107] Virtual machine management: perform specific cloud host management, including cloud host creation, priority setting, evacuation operation execution, etc.;

[0108] Virtual machine scheduling: schedule virtual machines, including the collection and update of total cluster resources, used resources, and remaining resources, and resource judgment during virtual machine creation, evacuation, and other operations.

[0109] And as Figure 3 As shown, the default creation of cloud hosts is scheduled according to normal resource scheduling. You must specify the affinity group to which it belongs and set the corresponding affinity policy or anti-affinity policy. The scheduling is performed according to the set scheduling policy. The creation process of the cloud host is: create a cloud host and set the priority of the cloud host, create a corresponding anti-affinity group according to the priority, add the high-priority cloud host to the corresponding anti-affinity group, and specify the anti-affinity group to create the cloud host. Among them, the anti-affinity policy can be used only for high-priority cloud hosts, and low-priority cloud hosts can be left untouched.

[0110] Based on this, the settings of the created cloud host are distributed as follows Figure 4 As shown in the figure, high-priority hosts belonging to the same anti-affinity group will be set in different physical hosts. As shown in the figure, cloud host 1, cloud host 2 and cloud host 3 all have a corresponding host priority of 10, and are assigned to the same anti-affinity group (that is, they belong to the same affinity group), and the scheduling policy is the anti-affinity policy. At this time, cloud host 1, cloud host 2 and cloud host 3 will be scheduled to different physical hosts, as shown in the figure. Figure 4 As shown, cloud host 1 is in physical host 1, cloud host 2 is in physical host 2, and cloud host 3 is in physical host 3.

[0111] This embodiment provides a fault handling method. Since each virtual machine is scheduled according to the scheduling policy set when it is created and the affinity group to which it belongs, and a suitable physical host is selected for evacuation and migration, it can ensure that high-priority virtual machines are not in the same physical host as much as possible, and ensure that when a single physical host fails, the impact on the business can be minimized, thereby improving the high availability of the cloud computing platform.

[0112] In a feasible implementation, step S10 may include steps S101 to S104:

[0113] Step S101: Obtaining the host priority corresponding to each virtual machine in the faulty host;

[0114] Step S102: Sort the virtual machines in the faulty host based on the host priority and generate a host processing sequence;

[0115] Step S103: extracting a host to be processed from the host processing sequence;

[0116] Step S104: Obtain the scheduling policy corresponding to the host to be processed and the affinity group to which it belongs.

[0117] It should be noted that the faulty host may have at least one virtual machine set up. In this case, in order to ensure that the high-priority virtual machine can be migrated first, the impact on the business can be minimized. The host priority is used to represent the importance of each virtual machine, that is, the impact on the business. The higher the impact of the virtual machine on the business, the higher its host priority. The host priority of each virtual machine can be pre-set by the administrator of the fault handling device according to actual business needs, such as setting it when the virtual machine is created, or even before the virtual machine is actually created, when there is a need to create it.

[0118] It is understandable that if there are multiple virtual machines set in the faulty host, in order to ensure that the high-priority virtual machines are migrated first, it is necessary to ensure that the virtual machines with higher host priorities are taken out of the sequence earlier. Therefore, the virtual machines in the faulty host can be sorted from high to low based on the host priority to generate a host processing sequence. Then, based on the sequence sorting in the host processing sequence, the virtual machines are sequentially extracted as the hosts to be processed. Then, the scheduling policy corresponding to the hosts to be processed and the affinity group to which they belong are obtained.

[0119] Correspondingly, after step S30 in this embodiment, it is also possible to detect whether there are elements in the host processing sequence that have not been extracted. If so, the process returns to step S103.

[0120] Based on this implementation mode, when multiple virtual machines are set in the faulty host, high-priority virtual machines can be migrated first to minimize the impact on the business.

[0121] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 5 After step S30, the fault handling method further includes steps S40 to S60:

[0122] Step S40: when the migration fails, obtain a low-priority host from among the normal physical hosts in the host cluster.

[0123] It should be noted that the normal physical host may be a physical host with normal current performance in the host cluster corresponding to the cloud computing platform, and the low-priority host may be a virtual machine whose corresponding host priority is lower than a preset low-priority threshold.

[0124] In actual use, after a physical host fails, the virtual machines on the failed physical host need to be evacuated and migrated to other normal physical hosts. The migration needs to ensure that there are sufficient resources on other normal physical hosts. Insufficient resources will cause the evacuation to fail, and the virtual machines cannot be restored normally, and will fail no matter how they are retried. At this time, in order to ensure that high-priority virtual machines can be restored first, you can try to put low-priority hosts among other normal physical hosts on hold to release resources, so that high-priority virtual machines can be restored first through migration.

[0125] It can be understood that, in order to ensure that high-priority virtual machines are restored first, step S40 and subsequent steps of this embodiment can be executed only when the migration of a high-priority virtual machine fails. For example: the host priority is divided into levels 1-10, and step S40 and subsequent steps can be executed only when the migration of a virtual machine with a host priority greater than or equal to level 8 fails.

[0126] Step S50: construct a host holding queue according to the low-priority host, and hold the low-priority host.

[0127] It should be noted that in order to ensure that high-priority virtual machines can be restored, sufficient resources need to be released. At this time, in order to ensure that the virtual machines that are currently on hold can be restored later, a host hold queue can be built based on low-priority hosts. The held virtual machines can be recorded through the host hold queue and the low-priority hosts can be put on hold.

[0128] In a specific implementation, in order to ensure that the suspended virtual machine can be restored normally later, the step of suspending the low-priority host in this embodiment may include:

[0129] The device resources occupied by the low-priority host are released, and the host disk data of the low-priority host is saved.

[0130] It should be noted that device resources may include CPU resources, memory resources or other types of device resources. In order to ensure that there are enough resources available for recovering high-priority virtual machines, the device resources occupied by low-priority hosts may be released. In order to ensure that the shelved virtual machines can be directly recovered later, it is necessary to avoid data loss. Therefore, the host disk data of the low-priority hosts may be saved.

[0131] Among them, when saving the host disk data of the low-priority host, it can be saved on the physical host where it is located to facilitate subsequent rapid recovery. Of course, since it is saved on the physical host, it may also occupy the storage resources of the physical host and cause the high-priority host to fail to recover. In order to avoid this situation, the host disk data of the low-priority host can also be sent to other devices or systems for storage, which is not limited in this embodiment.

[0132] Step S60: After the processing is completed, return to the step of selecting a target physical host in the host cluster based on the scheduling policy and the affinity group to which it belongs.

[0133] It is understandable that after the suspension process is completed, certain resources will be released in each normal physical host in the host cluster. At this time, it is possible to try to migrate and recover the host to be processed again, so it is possible to return to step S20.

[0134] In a possible implementation of this embodiment, in order to ensure that the suspended virtual machine can be normally restored later, after step S30 described in this embodiment, the following may also be included:

[0135] Extracting a host to be restored from the host hold queue, and obtaining cluster resource information of the host cluster;

[0136] If the cluster resource information meets the recovery resource requirement of the host to be recovered, then performing an anti-holding process on the host to be recovered;

[0137] When the processing is completed, return to the step of extracting the host to be restored from the host holding queue and obtaining the cluster resource information of the host cluster.

[0138] It should be noted that the cluster resource information may include resource information of each physical host in the host cluster, such as CPU resources, memory resources, storage resources, etc. The recovery resource requirements of the host to be recovered may be device resources required to restore the host to be recovered to normal operation.

[0139] It can be understood that if the cluster resource information meets the recovery resource requirements of the host to be recovered, it means that the host cluster has the ability to recover the host to be recovered at this time. Therefore, the host to be recovered can be de-suspended. After that, the host cluster continues to monitor whether it can recover the virtual machines in the host suspension queue. Therefore, it is possible to return to the step of extracting the host to be recovered from the host suspension queue and obtaining the cluster resource information of the host cluster.

[0140] The anti-hold processing may be a reverse operation of the hold processing, that is, creating a virtual machine according to the host disk data and allocating corresponding device resources thereto.

[0141] For ease of understanding, now combined Figure 6 and 7 This is for illustration only, but not for limitation. Figure 6 This is a schematic diagram of the overall fault handling process of this embodiment. Figure 7 A schematic diagram of the process of restoring a suspended host in this embodiment.

[0142] like Figure 6 As shown, the overall fault handling process is: create a cloud host in the host cluster and set the priority of the cloud host. Then, monitor the host cluster and detect the faulty host. Then, sort the cloud hosts on the faulty host according to the priority, and evacuate and migrate the cloud hosts on the faulty host to other normal physical hosts in sequence according to the priority queue. If the evacuation is successful, the process ends. If the evacuation fails, the low-priority cloud hosts on other normal nodes in the cluster can be put on hold, and an automatic put-aside queue (i.e., host put-aside queue) can be built. Then, the evacuation can be retried. When the number of retries exceeds the preset limit threshold, the process ends.

[0143] And then, if Figure 7As shown, the previously shelved host can be restored, that is, the automatically shelved virtual machine can be monitored regularly. When the cluster resources of the host cluster are sufficient (for example, the capacity is expanded, or other virtual machines are deleted to release resources), the automatically shelved virtual machine can be un-shelved to restore low-priority services.

[0144] This embodiment provides a fault handling method. When evacuation fails, some low-priority virtual machines can be put on hold to release some resources, and then the evacuation migration of the host to be processed can be tried again, so as to ensure that the abnormal virtual machine can be restored through migration and minimize the impact on the business.

[0145] This application also provides a fault handling device, please refer to Figure 8 , the fault handling device comprises:

[0146] The acquisition module 10 is used to acquire the scheduling policy corresponding to the host to be processed and the affinity group to which it belongs, wherein the host to be processed is a virtual machine set in the faulty host, the faulty host is a physical host that fails in the host cluster, and the scheduling policy is an affinity policy or an anti-affinity policy;

[0147] A selection module 20, configured to select a target physical host from a host cluster based on the scheduling policy and the affinity group to which it belongs;

[0148] The migration module 30 is used to migrate the host to be processed to the target physical host.

[0149] The fault handling device provided by the present application adopts the fault handling method in the above embodiment, which can solve the technical problem that the priority of the virtual machine is not considered when creating and migrating virtual machines in the cloud computing platform, which will cause a greater impact on the business of the cloud computing platform when a fault occurs. Compared with the prior art, the beneficial effects of the fault handling device provided by the present application are the same as the beneficial effects of the fault handling method provided by the above embodiment, and the other technical features of the fault handling device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0150] The present application provides a fault handling device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the fault handling method in the above-mentioned embodiment one.

[0151] Reference below Fig. 9, which shows a schematic diagram of the structure of a fault handling device suitable for implementing the embodiment of the present application. The fault handling device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Fig. 9 The fault handling device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0152] like Fig. 9 As shown, the fault handling device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the fault handling device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the fault handling device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a fault handling device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0153] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0154] The fault handling device provided by the present application adopts the fault handling method in the above embodiment, which can solve the technical problem that the priority of the virtual machine is not considered when creating and migrating virtual machines in the cloud computing platform, which will cause a greater impact on the business of the cloud computing platform when a fault occurs. Compared with the prior art, the beneficial effects of the fault handling device provided by the present application are the same as the beneficial effects of the fault handling method provided by the above embodiment, and the other technical features in the fault handling device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0155] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0156] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0157] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the fault handling method in the above-mentioned embodiment.

[0158] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, or infrared systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0159] The computer-readable storage medium may be included in the fault handling device; or may exist independently without being assembled into the fault handling device.

[0160] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the fault handling device, the fault handling device: obtains the scheduling policy and the affinity group corresponding to the host to be processed, the host to be processed is a virtual machine set in the faulty host, the faulty host is a physical host that fails in the host cluster, and the scheduling policy is an affinity policy or an anti-affinity policy; selects a target physical host from the host cluster based on the scheduling policy and the affinity group; and migrates the host to be processed to the target physical host.

[0161] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0162] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0163] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0164] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned fault handling method, and can solve the technical problem that the priority of virtual machines is not considered when creating and migrating virtual machines in the cloud computing platform, which will cause a greater impact on the business of the cloud computing platform when a fault occurs. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the fault handling method provided by the above-mentioned embodiment, and will not be repeated here.

[0165] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned fault handling method when executed by a processor.

[0166] The computer program product provided by the present application can solve the technical problem that the priority of the virtual machine is not considered when creating and migrating virtual machines in the cloud computing platform, which will cause a significant impact on the business of the cloud computing platform when a failure occurs. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as the beneficial effects of the fault handling method provided by the above embodiment, and will not be repeated here.

[0167] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A fault handling method, characterized in that: The method comprises: Obtaining a scheduling policy corresponding to a host to be processed and an affinity group to which it belongs, wherein the host to be processed is a virtual machine set in a faulty host, and the faulty host is a physical host that fails in a host cluster, and the scheduling policy is an affinity policy or an anti-affinity policy, and the anti-affinity policy is automatically set based on the host priority of the host to be processed; Selecting a target physical host from a host cluster based on the scheduling policy and the affinity group to which it belongs; Migrating the host to be processed to the target physical host; After migrating the host to be processed to the target physical host, the method further includes: When the migration fails, a low-priority host among normal physical hosts in the host cluster is obtained, wherein the normal physical host is a physical host with normal performance in the host cluster, and the low-priority host is a virtual machine whose corresponding host priority is lower than a preset low-priority threshold; Building a host shelving queue according to the low-priority host, and shelving the low-priority host; After the processing is completed, return to the step of selecting a target physical host in the host cluster based on the scheduling policy and the affinity group to which it belongs; The step of putting the low-priority host on hold includes: Release the device resources occupied by the low-priority host and save the host disk data of the low-priority host; After migrating the host to be processed to the target physical host, the method further includes: Extracting a host to be restored from the host hold queue, and obtaining cluster resource information of the host cluster; If the cluster resource information meets the recovery resource requirement of the host to be recovered, then performing an anti-holding process on the host to be recovered; When the processing is completed, return to the step of extracting the host to be restored from the host holding queue and obtaining cluster resource information of the host cluster; The step of obtaining the scheduling policy corresponding to the host to be processed and the affinity group to which it belongs includes: Obtaining a host priority and / or a policy identifier corresponding to a host to be processed, and obtaining host identification information of the host to be processed; Determine the scheduling policy corresponding to the host to be processed according to the host priority and / or the policy identifier, and search for the affinity group corresponding to the host to be processed based on the host identification information; Determining the scheduling policy corresponding to the host to be processed according to the host priority and / or the policy identifier includes: If the host priority is less than or equal to the preset priority threshold, determining that the scheduling policy corresponding to the host to be processed is an affinity policy; or, If the host priority is greater than a preset priority threshold, and the policy identifier is a first-class identifier, determining that the scheduling policy of the host to be processed is an affinity policy; or, If the host priority is greater than a preset priority threshold and the policy identifier is a second type identifier, it is determined that the scheduling policy of the host to be processed is an anti-affinity policy.

2. The fault handling method according to claim 1, characterized in that: At least one virtual machine is configured in the faulty host; The step of obtaining the scheduling policy corresponding to the host to be processed and the affinity group to which it belongs includes: Obtaining the host priority corresponding to each virtual machine in the faulty host, where the host priority is used to represent the importance of each virtual machine; Sort the virtual machines in the failed host based on the host priority and generate a host processing sequence; Extracting a host to be processed from the host processing sequence; Obtain the scheduling policy corresponding to the host to be processed and the affinity group to which it belongs.

3. The fault handling method according to claim 1, characterized in that: Before obtaining the scheduling policy corresponding to the host to be processed and the affinity group to which it belongs, the method further includes: Monitor the performance of each physical host in the host cluster; When any physical host in the host cluster is detected to have abnormal performance, the physical host with abnormal performance is used as a host to be determined; Get the historical abnormal count of the host to be judged; Updating the historical exception count to obtain a current exception count; If the current abnormality count is greater than the abnormality count threshold, the host to be judged is regarded as a faulty host; A host to be processed is determined according to the virtual machines in the faulty host.

4. The fault handling method according to claim 1, characterized in that: The selecting a target physical host from a host cluster based on the scheduling policy and the affinity group to which the host belongs includes: If the scheduling strategy is an affinity strategy, searching for a candidate physical host in the host cluster that is provided with a virtual machine belonging to the affinity group, and selecting a target physical host from the candidate physical hosts; or, If the scheduling policy is an anti-affinity policy, a candidate physical host is searched in the host cluster for which no virtual machine belonging to the affinity group is configured, and a target physical host is selected from the candidate physical hosts.

5. A fault handling device, characterized in that: The device comprises: An acquisition module is used to acquire a scheduling policy corresponding to a host to be processed and an affinity group to which it belongs, wherein the host to be processed is a virtual machine set in a faulty host, and the faulty host is a physical host that fails in a host cluster, and the scheduling policy is an affinity policy or an anti-affinity policy, and the anti-affinity policy is automatically set based on the host priority of the host to be processed; A selection module, used for selecting a target physical host from a host cluster based on the scheduling policy and the affinity group to which it belongs; A migration module, used for migrating the host to be processed to the target physical host; The migration module is further used to obtain a low-priority host among normal physical hosts in the host cluster when migration fails, wherein the normal physical host is a physical host with normal performance in the host cluster, and the low-priority host is a virtual machine whose corresponding host priority is lower than a preset low-priority threshold; construct a host shelving queue according to the low-priority host, and shelve the low-priority host; after the processing is completed, return to the step of selecting a target physical host in the host cluster based on the scheduling policy and the affinity group to which it belongs; The migration module is further used to release the device resources occupied by the low-priority host and save the host disk data of the low-priority host; The migration module is further configured to extract the host to be restored from the host shelving queue and obtain cluster resource information of the host cluster; if the cluster resource information meets the recovery resource requirements of the host to be restored, perform an anti-shelving process on the host to be restored; when the process is completed, return to the step of extracting the host to be restored from the host shelving queue and obtaining the cluster resource information of the host cluster; The acquisition module is further used to acquire the host priority and / or policy identifier corresponding to the host to be processed, and acquire the host identification information of the host to be processed; determine the scheduling policy corresponding to the host to be processed according to the host priority and / or policy identifier, and search for the affinity group corresponding to the host to be processed based on the host identification information; The acquisition module is further configured to determine that the scheduling policy corresponding to the host to be processed is an affinity policy if the host priority is less than or equal to a preset priority threshold; or, If the host priority is greater than a preset priority threshold, and the policy identifier is a first-class identifier, determining that the scheduling policy of the host to be processed is an affinity policy; or, If the host priority is greater than a preset priority threshold and the policy identifier is a second type identifier, it is determined that the scheduling policy of the host to be processed is an anti-affinity policy.

6. A fault handling device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the fault handling method according to any one of claims 1 to 4.

Images