Cloud resource instance scheduling method, device and equipment

Abstract

The invention relates to a cloud resource instance scheduling method, apparatus and device. The method comprises the steps of obtaining a to-be-scheduled cloud resource instance; for each cloud resource instance, determining at least one candidate fault domain from each fault domain based on a target instance type of the cloud resource instance; the target instance type is determined based on the service attribute of the cloud resource instance, each fault domain comprises at least one host machine, and the fault domains of different levels have an overlapping relationship; for each candidate host machine in the candidate fault domain, determining a scheduling weight value corresponding to the candidate host machine based on the resource quantity of the candidate host machine and the grading information of the fault domain; for each cloud resource instance, based on the respective scheduling weight value of each candidate host machine corresponding to the cloud resource instance, the target host machine is selected from the candidate host machines, and the cloud resource instance is scheduled to the target host machine, so that the efficiency and reliability of cloud resource scheduling are improved.

Description

Technical Field

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

[0002] Data centers usually have strict high availability mechanisms in place to ensure service availability in scenarios such as power outages in the computer room and cabinet failures. However, the implementation of this high availability mechanism requires the participation of multiple departments and systems, and the formulation of fault plans for various types of failures. When a failure occurs, it is also necessary to reschedule cloud resource instances in combination with manual judgment.

[0003] With the development of technology, the modularity and integration of data centers are continuously improving, and their physical and software topologies are becoming more and more complex. At the same time, since the physical and software topologies of data centers are usually in dynamic change during the business execution process, the corresponding fault impact range, that is, the fault domain, is also in a dynamic state, resulting in the increasing complexity of cloud resource instance scheduling.

[0004] In the related technology, the resource scheduling method based on pre-specified fault plans combined with manual judgment can realize the corresponding cloud resource instance scheduling when the topology structure changes. However, since the fault plan is usually formulated based on the original topology structure, its scheduling effect cannot be guaranteed after the data center topology structure changes. At the same time, the manual judgment method also has problems such as low scheduling efficiency. Summary of the invention

[0005] The present invention provides a cloud resource instance scheduling method, device and equipment, which are used to solve the problem of low efficiency and unguaranteed effect of cloud resource instance scheduling in related technologies.

[0006] In a first aspect, an embodiment of the present application provides a cloud resource instance scheduling method, the method comprising:

[0007] Get the cloud resource instance to be scheduled;

[0008] For each cloud resource instance, based on the target instance type of the cloud resource instance, at least one candidate fault domain is determined from each fault domain; the target instance type is determined based on the business attribute of the cloud resource instance corresponding to the target instance type, each fault domain includes at least one host machine, and there is an overlapping relationship between fault domains of different levels;

[0009] For each candidate host in the candidate fault domain, determine a scheduling weight value corresponding to the candidate host based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located;

[0010] For each cloud resource instance, based on the respective scheduling weight values ​​of the candidate hosts corresponding to the cloud resource instance, a target host is selected from the candidate hosts, and the cloud resource instance is scheduled to the target host.

[0011] The above method realizes adaptive scheduling after dynamic adjustment of cloud resource instances when cloud resource instances or physical topology changes, based on the resource quantity of the host machine and the fault classification information, thereby improving the efficiency of scheduling. When the network topology changes, the fault domain corresponding to the host machine will change accordingly. When selecting a host machine, in addition to referring to the resource quantity of the host machine, the fault domain where the host machine is currently located is also referred to, which can improve the accuracy of each scheduling. By adopting multi-level fault domains, fault domains of different levels can overlap, and a host machine can be located in multiple fault domains at the same time, which is closer to the real scene.

[0012] In a possible implementation, the determining of at least one candidate fault domain from each fault domain based on the target instance type of the cloud resource instance includes:

[0013] For any fault domain, determine the number of reference hosts included in the fault domain, wherein the reference hosts are hosts of cloud resource instances including the target instance type;

[0014] At least one candidate fault domain is determined from each fault domain based on the number of reference hosts included in each fault domain.

[0015] The above method selects candidate fault domains from each fault domain based on the distribution of cloud resource instances of the target instance type in each fault domain, which can avoid cloud resource instances of the same instance type being distributed in the same fault domain as much as possible, thereby ensuring load balancing of resource allocation.

[0016] In a possible implementation, if an anti-affinity set corresponding to the cloud resource instance is pre-configured, and the anti-affinity set includes instance types of each cloud resource instance having an anti-affinity relationship with the cloud resource instance to be scheduled; then after determining at least one candidate fault domain from each fault domain, and before determining the scheduling weight value corresponding to the candidate host, the method further includes:

[0017] Based on the instance types of the cloud resource instances included in the candidate hosts in each candidate fault domain, each candidate fault domain is screened to obtain a screened candidate fault domain; in the above screened candidate fault domain, the instance types of the cloud resource instances included in the candidate hosts are not located in the above anti-affinity set;

[0018] For each candidate host in the candidate fault domain, determining the scheduling weight value corresponding to the candidate host based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located includes:

[0019] For each candidate host in the screened candidate fault domain, a scheduling weight value corresponding to the candidate host is determined based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located.

[0020] In the above method, since there is a scenario where anti-affinity exists between cloud resource instances due to business attributes and other reasons, in this regard, an anti-affinity set corresponding to the cloud resource instance is set in the embodiment of the present application, and the instance type of the cloud resource instance that is not allowed to be set in the same fault domain as the cloud resource instance is stored in the anti-affinity set. After determining at least one candidate fault domain, each candidate fault domain is screened for the second time to eliminate the candidate fault domains where the cloud resource instance that has an anti-affinity relationship with the current cloud resource instance is located, thereby ensuring the normal operation of the business after subsequent scheduling.

[0021] In a possible implementation, if there is any candidate host machine located in multiple fault domains, determining a scheduling weight value corresponding to the candidate host machine based on the resource amount of the candidate host machine and the classification information of the fault domain in which the candidate host machine is located includes:

[0022] Based on the resource amount of any of the candidate host machines, a first weight value corresponding to any of the candidate host machines is generated; the resource amount is used to characterize the available resources of the corresponding candidate host machine;

[0023] Based on the grading information corresponding to each of the candidate fault domains in the multiple fault domains where the above-mentioned any candidate host is located, generating a second weight value corresponding to the above-mentioned any candidate host; the above-mentioned grading information is determined based on the topological structure of the above-mentioned any candidate fault domain;

[0024] Based on the first weight value and the second weight value, a scheduling weight value corresponding to any of the candidate host machines is determined.

[0025] The above method determines the scheduling weight value of the candidate fault domain based on the available resources of the candidate host and the hierarchical information of each candidate fault domain, which can accurately evaluate the scheduling effect of the candidate host corresponding to the cloud resource instance and improve the accuracy of cloud resource instance scheduling.

[0026] In a possible implementation manner, the grading information is a regional weight of a corresponding candidate fault domain. Before generating a second weight value corresponding to any of the candidate host machines based on the grading information corresponding to each of the candidate fault domains in the multiple fault domains in which any of the candidate host machines is located, the method further includes:

[0027] Obtain the coverage corresponding to each fault domain;

[0028] Based on the preset correspondence between coverage and regional weight, determine the regional weight corresponding to each fault domain; wherein, the larger the coverage, the larger the corresponding regional weight;

[0029] The generating of the second weight value corresponding to any of the candidate host machines based on the classification information corresponding to each of the candidate fault domains in the multiple fault domains in which any of the candidate host machines is located includes:

[0030] The regional weights corresponding to the above-mentioned candidate fault domains are summed up to generate a second weight value corresponding to any of the above-mentioned candidate host machines.

[0031] The above method determines the regional weight of the fault domain based on the coverage range, and sums the regional weights of each candidate fault domain where the candidate host is located to determine the second weight value of the candidate host. It comprehensively considers the information of multiple fault domains where the host is located, ensures the accuracy of the second weight value, and thus improves the accuracy of cloud resource instance scheduling.

[0032] In a possible implementation, the step of obtaining the cloud resource instance to be scheduled includes:

[0033] When a change is detected in a cloud resource instance in a resource scheduling group corresponding to any business, each cloud resource instance included in the resource scheduling group is used as the cloud resource instance to be scheduled; or,

[0034] When a change in a host machine in any fault domain is detected, each cloud resource instance currently configured on the host machine is used as the cloud resource instance to be scheduled.

[0035] The above method triggers the process of obtaining the cloud resource instance to be scheduled for scheduling when the cloud resource instance changes or the host machine changes, which can ensure timely scheduling of the cloud resource instance and improve scheduling efficiency.

[0036] In a possible implementation, the determining of at least one candidate fault domain from each fault domain based on the target instance type of the cloud resource instance includes:

[0037] Obtain the scheduling scope corresponding to the above cloud resource instance;

[0038] Based on the target instance type of the cloud resource instance, at least one candidate fault domain is determined from the fault domains within the scheduling range.

[0039] The above method can ensure that the selected candidate fault domain is within the specified range by setting the scheduling range of the cloud resource instance and selecting the candidate fault domain from each fault domain within the scheduling range.

[0040] In a second aspect, an embodiment of the present application provides a cloud resource instance scheduling device, the device comprising:

[0041] An acquisition module is used to acquire cloud resource instances to be scheduled;

[0042] A fault domain determination module is used to determine, for each cloud resource instance, at least one candidate fault domain from each fault domain based on a target instance type of the cloud resource instance; the target instance type is determined based on a business attribute of the cloud resource instance corresponding to the target instance type, each fault domain includes at least one host machine, and there is an overlapping relationship between fault domains of different levels;

[0043] A weight value determination module is used to determine, for each candidate host in the candidate fault domain, a scheduling weight value corresponding to the candidate host based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located;

[0044] The scheduling module is used to select a target host from each candidate host for each cloud resource instance based on the scheduling weight values ​​of each candidate host corresponding to the cloud resource instance, and schedule the cloud resource instance to the target host.

[0045] In a possible implementation manner, the fault domain determination module is specifically configured to:

[0046] For any fault domain, determine the number of reference hosts included in the fault domain, wherein the reference hosts are hosts of cloud resource instances including the target instance type;

[0047] At least one candidate fault domain is determined from each fault domain based on the number of reference hosts included in each fault domain.

[0048] In a possible implementation, if an anti-affinity set corresponding to the cloud resource instance is pre-configured, and the anti-affinity set includes instance types of each cloud resource instance having an anti-affinity relationship with the cloud resource instance to be scheduled; then after determining at least one candidate fault domain from each fault domain, the fault domain determination module is further used to:

[0049] Based on the instance types of the cloud resource instances included in the candidate hosts in each candidate fault domain, each candidate fault domain is screened to obtain a screened candidate fault domain; in the above screened candidate fault domain, the instance types of the cloud resource instances included in the candidate hosts are not located in the above anti-affinity set;

[0050] The weight value determination module is specifically used for:

[0051] For each candidate host in the screened candidate fault domain, a scheduling weight value corresponding to the candidate host is determined based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located.

[0052] In a possible implementation, if there is any candidate host machine located in multiple fault domains, the weight value determination module is specifically used to:

[0053] Based on the resource amount of any of the candidate host machines, a first weight value corresponding to any of the candidate host machines is generated; the resource amount is used to characterize the available resources of the corresponding candidate host machine;

[0054] Based on the grading information corresponding to each of the candidate fault domains in the multiple fault domains where the above-mentioned any candidate host is located, generating a second weight value corresponding to the above-mentioned any candidate host; the above-mentioned grading information is determined based on the topological structure of the above-mentioned any candidate fault domain;

[0055] Based on the first weight value and the second weight value, a scheduling weight value corresponding to any of the candidate host machines is determined.

[0056] In a possible implementation manner, the classification information is a regional weight of a corresponding candidate fault domain, and the weight value determination module is specifically used to:

[0057] Obtain the coverage corresponding to each fault domain;

[0058] Based on the preset correspondence between coverage and regional weight, determine the regional weight corresponding to each fault domain; wherein, the larger the coverage, the larger the corresponding regional weight;

[0059] The generating of the second weight value corresponding to any of the candidate host machines based on the classification information corresponding to each of the candidate fault domains in the multiple fault domains in which any of the candidate host machines is located includes:

[0060] The regional weights corresponding to the above-mentioned candidate fault domains are summed up to generate a second weight value corresponding to any of the above-mentioned candidate host machines.

[0061] In a possible implementation manner, the acquisition module is specifically used to:

[0062] When a change is detected in a cloud resource instance in a resource scheduling group corresponding to any business, each cloud resource instance included in the resource scheduling group is used as the cloud resource instance to be scheduled; or,

[0063] When a change in a host machine in any fault domain is detected, each cloud resource instance currently configured on the host machine is used as the cloud resource instance to be scheduled.

[0064] In a possible implementation manner, the fault domain determination module is specifically configured to:

[0065] Obtain the scheduling scope corresponding to the above cloud resource instance;

[0066] Based on the target instance type of the cloud resource instance, at least one candidate fault domain is determined from the fault domains within the scheduling range.

[0067] In a third aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps in the cloud resource instance scheduling method when executing the computer program.

[0068] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the steps in the cloud resource instance scheduling method described above in the present application are implemented.

[0069] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which is stored in a computer-readable storage medium; when the processor of a memory access device reads the computer program from the computer-readable storage medium, the processor executes the computer program, so that the memory access device executes the steps in the above-mentioned cloud resource instance scheduling method of the present application.

[0070] For each of the above-mentioned second to fifth aspects and the technical effects that may be achieved by each of the above-mentioned aspects, please refer to the above-mentioned description of the technical effects that can be achieved by the first aspect or various possible schemes in the first aspect, and no further details will be given here. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] 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 invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0072] Figure 1 A schematic diagram of an application scenario provided in an embodiment of the present application;

[0073] Figure 2 A schematic diagram of a cloud resource scheduling group provided in an embodiment of the present application;

[0074] Figure 3 A flowchart of a cloud resource instance scheduling method provided in an embodiment of the present application;

[0075] Figure 4A schematic diagram of a scheduling strategy for a cloud resource instance provided in an embodiment of the present application;

[0076] Figure 5 A schematic diagram of a fault domain provided in an embodiment of the present application;

[0077] Figure 6 A schematic diagram of a cloud resource instance scheduling process provided in an embodiment of the present application;

[0078] Figure 7 A schematic diagram of a cloud resource instance scheduling device provided in an embodiment of the present application;

[0079] Figure 8 A schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0080] In order to make the purpose, technical solution and advantages of the present application more clear, the present application will be further described in detail below in conjunction with the accompanying drawings. The specific operation method in the method embodiment can also be applied to the device embodiment or the system embodiment.

[0081] In the description of this application, "multiple" is understood to be "at least two". "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent three situations: A exists alone, A and B exist at the same time, and B exists alone. A is connected to B, which can represent two situations: A is directly connected to B and A is connected to B through C. In addition, in the description of this application, words such as "first" and "second" are only used for the purpose of distinguishing descriptions, and cannot be understood as indicating or implying relative importance, nor can they be understood as indicating or implying order.

[0082] In order to facilitate those skilled in the art to better understand the technical solutions provided by the embodiments of the present application, the following is a brief description of the professional terms involved:

[0083] (1) Fault domain: The scope of impact when a system fails.

[0084] (2) Cloud resource instances: cloud resources such as virtual machines, containers, and database instances.

[0085] (3) Host group: A group of physical machines or resources used to host cloud resource instances.

[0086] (4) Auto-scaling group: A group of cloud resource instances that has properties such as the expected number of instances and the minimum number of instances set. The number of instances is automatically increased or decreased as the scaling conditions change.

[0087] (5) Cloud resource scheduling group: a resource grouping with certain characteristics that can describe the scheduling relationship between cloud resource instances and hosts.

[0088] (6) Affinity: A policy used to control instance scheduling, which defines the "preference relationship" between instances, that is, a specified instance should be scheduled to a specific node or placed together with a specific instance.

[0089] (7) Anti-Affinity: A policy used to control instance scheduling. It defines the preference relationship between instances and nodes or other instances that they should not be placed together with. That is, the specified instance should avoid being scheduled to a specific node or placed together with a specific instance.

[0090] Data centers usually have strict high availability mechanisms in place to ensure service availability in scenarios such as power outages in the computer room, cabinet failures, router overloads, abnormal load balancing service resolution, and partial failures of cloud resource instances. However, the implementation of this high availability mechanism requires the simultaneous participation of multiple departments and systems, and the formulation of fault plans for various types of failures. When a failure occurs, it is also necessary to combine manual judgment to reschedule cloud resource instances.

[0091] With the development of technology, the modularity and integration of data centers are continuously improving, and their physical and software topologies are becoming more and more complex. Taking the implementation of liquid-cooled servers as an example, a liquid-cooling group can deploy multiple cabinets, a cabinet can deploy multiple blade boxes, and a blade box can deploy multiple physical machine servers. The failure impact range of liquid-cooling groups, cabinets, and blade boxes is different. When deploying services, they need to be dispersed to different fault domains as much as possible. At the same time, fault domains are usually multi-level and dynamically changing. Service expansion or shutdown maintenance will affect the fault domain, which in turn leads to the increasing complexity of cloud resource instance scheduling.

[0092] In the related technology, when cloud resource scheduling is performed, the fault domain, cloud resource instance, host group, cloud resource scheduling group, etc. can be registered through the cloud platform or manually recorded. When the fault domain or cloud resource instance changes, the handler obtains parameters such as physical topology and business attributes and re-formulates the scheduling strategy, and manually schedules the cloud resource instances for re-division. However, this method has low scheduling efficiency and the scheduling effect cannot be guaranteed. For example, if cloud resource instances originally allocated to different racks are scheduled to the same rack during scheduling, it is likely to cause service downtime when the next rack fails.

[0093] In this regard, an embodiment of the present application provides a cloud resource instance scheduling method applied to this scenario. When the cloud resource instance or physical topology changes, the cloud resource instance is re-divided through automatic scheduling to achieve efficient and real-time resource scheduling.

[0094] Figure 1 A schematic diagram of an application scenario provided in an embodiment of the present application is shown in FIG. Figure 1As shown, the application scenario includes multiple fault domains, each fault domain includes multiple host machines, and the multiple fault domains are obtained based on physical topology or software topology. In this application, there may be overlapping relationships between multiple fault domains, such as Figure 1 Fault domain 1 and fault domain 3, as well as fault domain 2 and fault domain 3 are shown. Host machines in the same fault domain, and host machines in different fault domains can be connected through switches to communicate with each other.

[0095] Among them, in the embodiment of the present application, a data collector is also provided, which detects the changes in each fault domain in real time, such as cloud resource instance update detection, host group (i.e., a group of host machines located in the same fault domain) update detection, physical topology update detection, etc., and sends the information to the device (such as the device that executes the cloud resource instance scheduling method described in the present application) Figure 1 The scheduling engine shown).

[0096] The scheduling engine is used to determine that there are cloud resource instances to be scheduled (such as Figure 1 1), selects a suitable target host from the hosts in each fault domain (such as Figure 1 The host machine located in fault domain 2 as shown in the figure) and schedules the cloud resource instance to the target host machine.

[0097] It should be noted that the cloud resource instance scheduling method in the embodiment of the present application is not limited to being implemented through the scheduling engine. In specific implementations, it can also be implemented through other mechanisms (for example, by adding an intermediate layer through event triggering, event processing, etc.).

[0098] Figure 2 A schematic diagram of a cloud resource scheduling group provided in an embodiment of the present application; Figure 2 As shown, in some embodiments, the present application can be based on business attributes, such as user attributes corresponding to the business, business type, service type, function attributes, etc., to cloud resource instances (such as Figure 2 The VM shown in the figure is divided into multiple cloud resource scheduling groups (such as Figure 2 Group 1, Group 2 and Group 3 shown); wherein, the cloud resource instances between multiple cloud resource scheduling groups may overlap, such as Figure 2 shown.

[0099] After obtaining each cloud resource scheduling group, the cloud resource instances in the same cloud resource scheduling group can be determined as the same type. It should be noted that due to the overlapping relationship between cloud resource scheduling groups, the same cloud resource instance may correspond to multiple instance types. In some embodiments, the instance type includes but is not limited to: background data processing type, web page access type, big data processing type, etc.

[0100] In some embodiments, when performing cloud resource instance division, the present application may also include an elastic resource group, which is set with a minimum number of instances (i.e. Figure 2 resident instances in ) and the expected number of instances (i.e. Figure 2 The elastic resource group can be set to correspond to a certain business, and automatically increase or decrease the number of cloud resource instances it includes according to preset scaling conditions (such as changes in the business volume corresponding to the business, the number of hosts). Among them, the resident instances are cloud resource instances in the elastic resource group that do not change with the scaling conditions, and the elastic instances are cloud resource instances that increase or decrease with the scaling conditions.

[0101] It should be noted that the structure of the above application scenario is only an example, and the cloud resource scheduling method in the embodiment of the present application can also be applied to other scenarios.

[0102] The present application is further described in detail below in conjunction with the accompanying drawings. Figure 3 FIG. 1 is a flow chart of a cloud resource scheduling method provided in an embodiment of the present application. The specific implementation process of the method is as follows:

[0103] Step S301, obtaining a cloud resource instance to be scheduled;

[0104] In some embodiments, when a cloud resource instance changes (i.e., the software topology changes), or a fault domain structure changes (i.e., the physical topology changes), the cloud resource instance scheduling method described in this application is triggered to obtain a scheduled cloud resource instance.

[0105] In a possible implementation, the step of obtaining the cloud resource instance to be scheduled includes:

[0106] When a change is detected in a cloud resource instance in a resource scheduling group corresponding to any business, each cloud resource instance included in the resource scheduling group is used as a cloud resource instance to be scheduled; or,

[0107] When a change in a host in any fault domain is detected, each cloud resource instance currently configured on the host is used as the cloud resource instance to be scheduled.

[0108] In some embodiments, Figure 1 The data collector shown monitors events such as cloud resource instance updates, host group updates, and physical topology updates in real time. When any of these events is updated, the scheduling indication of the cloud resource instance is triggered based on the specific information of the corresponding event collected by the data collector, and the cloud resource instance to be scheduled is obtained to perform the subsequent steps shown in steps S302-S304.

[0109] In some embodiments, after the present application determines that a cloud resource instance is updated, it will adaptively and automatically adjust the host machine, cloud resource scheduling group, and elastic scaling group (optional) related to the fault domain where the cloud resource instance is located to achieve optimal resource utilization efficiency.

[0110] Specifically, the above-mentioned cloud resource instance update event is: any business changes, resulting in changes in the cloud resource instances in the cloud resource scheduling group (or affinity group) corresponding to the business, such as the addition, deletion or change of cloud resource instances, etc. At this time, each cloud resource instance in the cloud resource scheduling group can be used as a cloud resource instance to be scheduled.

[0111] like Figure 4 As shown, when a cloud resource instance update event occurs, the following processes need to be performed in sequence for the cloud resource instance to be scheduled: determine the instance type of the cloud resource instance, determine at least one candidate fault domain from each fault domain, determine the scheduling weight value corresponding to each candidate host machine, sort the candidate host machines based on the scheduling weight value, and select the target host machine.

[0112] The above-mentioned host machine update event is: a host machine in any fault domain changes, for example, a host machine is added, deleted or replaced, etc. At this time, the cloud resource instance currently configured on the changed host machine can be used as the cloud resource instance to be scheduled; in some embodiments, the host group in the present application can also set its corresponding quantity range, that is, the maximum number and the minimum number, and adjust the number of hosts within this quantity range according to the business volume of the corresponding business.

[0113] like Figure 4 As shown, if a host update event occurs, such as when a new host is added, before scheduling the cloud resource instance, it is necessary to perform the following steps in sequence: determine the host's characteristic information, select the fault domain where the host is located based on the cloud host's characteristic information, add the host to the selected fault domain, and run the cloud resource instance on the host to determine whether the host can operate normally. After determining that the host can operate normally, the scheduling process of the cloud resource instance is executed.

[0114] Optionally, if a new host machine is added and no cloud resource instance is configured in the host machine, the cloud resource instances to be scheduled can be further determined based on the total number of cloud resource instances configured in each host machine in the fault domain in which the host machine is located. For example, when the total number is greater than a preset value (the preset value can be set based on demand), the cloud resource instances configured in each host machine in the fault domain are used as the cloud resource instances to be scheduled; when the total number is not greater than the preset value and there are unused cloud resource instances, the unused cloud resource instances (a preset number of cloud resource instances can be randomly selected therefrom, and the preset number can be set based on demand) are used as the cloud resource instances to be scheduled.

[0115] The above-mentioned physical topology update event is: when a large-scale host machine structure change occurs in the fault domain, such as the number of changed hosts in each fault domain is greater than a preset value, or the number of changed fault domains is greater than a preset value, at this time, the cloud resource instances configured on the hosts of each fault domain, that is, all cloud resource instances in use, can be used as cloud resource instances to be scheduled, and the overall cloud resource instances can be re-planned through automatic scheduling to optimize the distribution of cloud resource instances.

[0116] In a possible implementation, the embodiment of the present application may also be configured to schedule all cloud resource instances in use as cloud resource instances to be scheduled, or to schedule a specified portion of cloud resource instances as cloud resource instances to be scheduled, at preset intervals, to ensure that the distribution of cloud resource instances is in an optimal state in real time.

[0117] like Figure 4 As shown, if a physical topology update event occurs, or the above-mentioned preset period is reached, the following processes are executed in sequence: traverse each cloud resource instance to calculate the scheduling weight value, determine the target host machine corresponding to each cloud resource instance, and schedule if the target host machine changes (that is, it is different from the current host machine).

[0118] In some embodiments, the present application may also set permission information corresponding to each cloud resource instance, and the permission information includes permission to schedule and non-permitted scheduling. When a cloud resource instance whose permission information is non-permitted scheduling is determined as a cloud resource instance to be scheduled, the steps described in the subsequent steps S302-S304 are not executed, but the user manually schedules it. When a cloud resource instance whose permission information is permission to schedule is determined as a cloud resource instance to be scheduled, the steps described in the subsequent steps S302-S304 are executed.

[0119] It should be noted that the above-mentioned permission information can be set based on needs. Usually, the permission information of cloud resource instances that are not recommended for migration (such as when the business performed by the cloud resource instance is more important, or the migration will affect other cloud resource instances or the host machine) is set to not allow scheduling and is manually scheduled by the user.

[0120] Step S302, for each cloud resource instance, based on the target instance type of the cloud resource instance, determining at least one candidate fault domain from each fault domain;

[0121] The target instance type is determined based on the business attributes of the cloud resource instance corresponding to the target instance type, each fault domain includes at least one host machine, and there is an overlapping relationship between fault domains of different levels;

[0122] In some embodiments, the present application divides multiple levels of fault domains based on the physical or software topology structure, and associates corresponding hosts with them, wherein there is an overlapping relationship between fault domains of different levels. In addition, when the physical or software topology structure changes, such as when a new host is added or a host is deleted, the corresponding fault domain will be automatically updated to ensure its real-time accuracy.

[0123] Taking the implementation of liquid-cooled servers as an example, a liquid cooling group can deploy multiple cabinets, a cabinet can deploy multiple blade boxes, and multiple physical machine servers can be deployed in a blade box. The fault domains of the liquid cooling group, cabinet, and blade box are all different. When dividing the fault domains, the embodiments of the present application can divide the fault domains corresponding to the liquid cooling family, cabinet, and blade box into three different levels. Since fault domains of different levels are allowed to overlap, the same physical machine server can be located in different fault domains, which is more in line with scenario requirements.

[0124] In a possible implementation, the determining of at least one candidate fault domain from each fault domain based on the target instance type of the cloud resource instance includes:

[0125] For any fault domain, determine the number of reference hosts included in the fault domain, where the reference host is a host that includes a cloud resource instance of the target instance type;

[0126] At least one candidate fault domain is determined from each fault domain based on the number of reference hosts included in each fault domain.

[0127] In some embodiments, in order to ensure load balancing during allocation, the present application avoids cloud resource instances of the same instance type being distributed in the same fault domain as much as possible when selecting candidate fault domains. In specific implementations, when selecting fault domains, first determine the distribution of cloud resource instances of the target instance type in each fault domain, that is, the number of reference hosts in each of the above fault domains, and then select candidate fault domains based on the distribution, wherein the specific selection rules can be set based on demand, and in one possible embodiment, a fault domain whose number of reference hosts is less than a preset threshold (which can be set based on demand, such as set to 1) can be used as a candidate fault domain; in another possible embodiment, a quantity threshold can be set (which can be set based on demand), and each fault domain is arranged in order from the number of reference hosts in ascending order, and the fault domain at the front of the quantity threshold is selected from the arranged fault domains as the candidate fault domain.

[0128] In a possible implementation, based on the target instance type of the cloud resource instance, determining at least one candidate fault domain from each fault domain includes:

[0129] Get the scheduling scope corresponding to the cloud resource instance;

[0130] Based on the target instance type of the cloud resource instance, at least one candidate fault domain is determined from each fault domain within the scheduling scope.

[0131] In some embodiments, the present application may determine the scheduling range corresponding to the cloud resource instance based on the scheduling policy. When scheduling the cloud resource instance, it is necessary to schedule within the scheduling range, that is, select the candidate fault domain from the fault domains within the scheduling range. It should be noted that the embodiments of the present application do not limit the scheduling range, which can be set based on business needs.

[0132] In a possible implementation, when determining the candidate domains, the determination may be performed in sequence based on the levels of the fault domains. For example, the candidate fault domains are first selected from the highest level fault domains, and then from the next level fault domains, and so on.

[0133] Step S303, for each candidate host in the candidate fault domain, based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located, determine the scheduling weight value corresponding to the candidate host;

[0134] In a possible implementation, if there is any candidate host machine located in multiple fault domains, determining a scheduling weight value corresponding to the candidate host machine based on the resource amount of the candidate host machine and the classification information of the fault domain in which the candidate host machine is located includes:

[0135] Based on the resource amount of any candidate host machine, generating a first weight value corresponding to any candidate host machine; the resource amount is used to characterize the available resources of the corresponding candidate host machine;

[0136] Based on the grading information corresponding to each of the multiple fault domains in which any candidate host is located, generating a second weight value corresponding to any candidate host; the grading information is determined based on the topological structure of any candidate fault domain;

[0137] Based on the first weight value and the second weight value, a scheduling weight value corresponding to any candidate host machine is determined.

[0138] In some embodiments, the conversion relationship between the resource amount of the above-mentioned candidate host machine and its corresponding first weight value can be set based on demand, but it is necessary to ensure that the larger the resource amount, the larger the corresponding first weight value; at the same time, based on the grading information corresponding to each candidate fault domain, a second weight value corresponding to any candidate host machine is generated. The grading information corresponding to each candidate fault domain can be first summarized, and then based on the conversion relationship between the summary result and the second weight value, the second weight value is generated. Specifically, the conversion relationship can also be set based on demand.

[0139] In some embodiments, after obtaining the first weight value and the second weight value, the first weight value and the second weight value can be directly summed to obtain the scheduling weight value corresponding to the candidate host machine; or weighted weights corresponding to the first weight value and the second weight value can be pre-set, and weighted summation can be performed based on the weighted weights to obtain the scheduling weight value corresponding to the candidate host machine.

[0140] In a possible implementation, when the grading information is a regional weight of a corresponding candidate fault domain, based on grading information corresponding to each candidate fault domain in a plurality of fault domains in which any candidate host is located, before generating a second weight value corresponding to any candidate host, the method further includes:

[0141] Obtain the coverage corresponding to each fault domain;

[0142] Based on the preset correspondence between coverage and regional weight, determine the regional weight corresponding to each fault domain; wherein, the larger the coverage, the larger the corresponding regional weight;

[0143] Based on the grading information corresponding to each of the candidate fault domains in the multiple fault domains where any candidate host is located, generating a second weight value corresponding to any candidate host, including:

[0144] The regional weights corresponding to each candidate fault domain are summed to generate a second weight value corresponding to any candidate host machine.

[0145] In some embodiments, Figure 5 As shown, the above-mentioned grading information can be set as the regional weight of the candidate fault domain. The regional weight is determined based on the coverage of the fault domain. The larger the coverage, the greater the weight. When calculating the second weight value, the regional weights of the candidate fault domains where the candidate host is located are summed, such as Figure 5 The host machine 1 shown in FIG. 1 is located in fault domain 4 and fault domain 8, so its corresponding second regional weight is the sum of the regional weights between fault domain 4 and fault domain 8, that is, 160; Figure 5 The host machine 2 shown is located in fault domain 5, fault domain 7 and fault domain 8, so its corresponding second regional weight is the sum of the regional weights between fault domain 5, fault domain 7 and fault domain 8, that is, 180.

[0146] In a possible implementation, if an anti-affinity set corresponding to a cloud resource instance is pre-configured, and the anti-affinity set includes instance types of each cloud resource instance having an anti-affinity relationship with the cloud resource instance to be scheduled; after determining at least one candidate fault domain from each fault domain, and before determining a scheduling weight value corresponding to the candidate host, the method further includes:

[0147] Based on the instance types of the cloud resource instances included in the candidate host machines in each candidate fault domain, each candidate fault domain is screened to obtain a screened candidate fault domain; in the screened candidate fault domain, the instance types of the cloud resource instances included in the candidate host machines are not located in the anti-affinity set;

[0148] The step of determining, for each candidate host in the candidate fault domain, a scheduling weight value corresponding to the candidate host based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located, includes:

[0149] For each candidate host in the screened candidate fault domain, a scheduling weight value corresponding to the candidate host is determined based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located.

[0150] In some embodiments, there are scenarios where anti-affinity exists between cloud resource instances due to business attributes and other reasons. In this regard, in an embodiment of the present application, an anti-affinity set corresponding to the cloud resource instance is set, and the instance types of cloud resource instances that are not allowed to be set in the same fault domain as the cloud resource instance are stored in the anti-affinity set. After determining at least one candidate fault domain, each candidate fault domain is screened for the second time to eliminate the candidate fault domains where the cloud resource instances that have an anti-affinity relationship with the current cloud resource instance are located, thereby ensuring the normal operation of the business after subsequent scheduling.

[0151] Step S304 , for each cloud resource instance, based on the scheduling weight values ​​of the candidate hosts corresponding to the cloud resource instance, a target host is selected from the candidate hosts, and the cloud resource instance is scheduled to the target host.

[0152] In some embodiments, for each cloud resource instance, a candidate host machine with the largest scheduling weight value among the corresponding candidate host machines may be used as the target host machine, and the instance may be scheduled to the target host machine.

[0153] It should be noted that if the candidate host machine with the smallest scheduling weight value is selected as the target host machine in the order of scheduling weight values ​​from small to large, then in the above step S306, the larger the coverage range, the smaller the corresponding regional weight, and the larger the amount of resources, the smaller the corresponding first weight value.

[0154] The above method realizes adaptive scheduling after dynamic adjustment of cloud resource instances when cloud resource instances or physical topology changes, based on the resource quantity of the host machine and the fault classification information, thereby improving the efficiency of scheduling. When the network topology changes, the fault domain corresponding to the host machine will change accordingly. When selecting a host machine, in addition to referring to the resource quantity of the host machine, the fault domain where the host machine is currently located is also referred to, which can improve the accuracy of each scheduling. By adopting multi-level fault domains, fault domains of different levels can overlap, and a host machine can be located in multiple fault domains at the same time, which is closer to the real scene.

[0155] In some embodiments, due to the restrictions of affinity and anti-affinity between cloud resource instances, when multiple affinity groups are applied simultaneously, it is very likely that some host machines have sufficient available resources but cannot effectively complete key operations such as cloud host creation or scheduling. In this case, in the process of scheduling cloud resource instances in the embodiments of the present application, it is also possible to adaptively adjust the cloud resource instances (i.e., existing cloud hosts) currently distributed on the host machines based on the current cloud resource instances without affecting the high availability of the business, or adjust the number of host machines in the fault domain, and dynamically adjust the distribution of host machines in the fault domain by migrating, removing or adding host machines, so as to achieve dynamic balancing of host resources, complete resource allocation as much as possible, and improve the allocation rate.

[0156] In a specific implementation, when the above situation occurs (i.e., there is no candidate fault domain corresponding to the cloud resource instance currently to be scheduled), the existing cloud hosts on the host machine in the current fault domain can be migrated and scheduled to the host machines in other fault domains, and then the cloud resource instance currently to be scheduled can be scheduled to the migrated host machine to achieve dynamic balancing of host machine resources.

[0157] The following combination Figure 6 The above cloud resource instance scheduling process is described in detail with a specific example. The process specifically includes:

[0158] Step S601, when a change in a cloud resource instance or a physical topology is detected, a cloud resource instance to be scheduled is obtained;

[0159] Step S602, based on the target instance type of the cloud resource instance to be scheduled, respectively determine the number of reference hosts included in each fault domain;

[0160] Wherein, the reference host is a host of a cloud resource instance including the target instance type;

[0161] Step S603, determining at least one candidate fault domain from each fault domain based on the number of reference host machines included in each fault domain;

[0162] Step S604, screening each candidate fault domain based on the instance type of the cloud resource instance included in the candidate host in each candidate fault domain, to obtain screened candidate fault domains;

[0163] Among them, in the filtered candidate fault domains, the instance types of the cloud resource instances included in the candidate host machines are not located in the anti-affinity set corresponding to the cloud resource instance to be scheduled, and the anti-affinity set includes the instance types of each cloud resource instance that has an anti-affinity relationship with the cloud resource instance to be scheduled;

[0164] Step S605, for each candidate host in the screened candidate fault domain, generating a first weight value corresponding to the candidate host based on the resource amount of the candidate host;

[0165] The resource amount is used to represent the available resources of the corresponding candidate host machine;

[0166] Step S606, summing the regional weights corresponding to each candidate fault domain where the candidate host is located, to generate a second weight value corresponding to the candidate host;

[0167] The regional weight is determined based on the coverage of the fault domain. The larger the coverage, the greater the corresponding regional weight.

[0168] Step S607, determining a scheduling weight value corresponding to the candidate host machine based on the first weight value and the second weight value;

[0169] Step S608 , based on the respective scheduling weight values ​​of the candidate host machines, a target host machine is selected from the candidate host machines, and the cloud resource instance to be scheduled is scheduled to the target host machine.

[0170] Based on the same inventive concept, the present application also provides a cloud resource instance scheduling device, see Figure 7 , the device comprises:

[0171] An acquisition module 701 is used to acquire a cloud resource instance to be scheduled;

[0172] A fault domain determination module 702 is used to determine, for each cloud resource instance, at least one candidate fault domain from each fault domain based on a target instance type of the cloud resource instance; the target instance type is determined based on a business attribute of the cloud resource instance corresponding to the target instance type, each fault domain includes at least one host machine, and there is an overlapping relationship between fault domains of different levels;

[0173] The weight value determination module 703 is used to determine, for each candidate host in the candidate fault domain, a scheduling weight value corresponding to the candidate host based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located;

[0174] The scheduling module 704 is used to select a target host from each candidate host corresponding to each cloud resource instance based on the scheduling weight value of each candidate host corresponding to the cloud resource instance, and schedule the cloud resource instance to the target host.

[0175] In a possible implementation manner, the fault domain determination module 702 is specifically configured to:

[0176] For any fault domain, determine the number of reference hosts included in the fault domain, wherein the reference hosts are hosts of cloud resource instances including the target instance type;

[0177] At least one candidate fault domain is determined from each fault domain based on the number of reference hosts included in each fault domain.

[0178] In a possible implementation, if an anti-affinity set corresponding to the cloud resource instance is pre-configured, and the anti-affinity set includes instance types of each cloud resource instance having an anti-affinity relationship with the cloud resource instance to be scheduled; then after determining at least one candidate fault domain from each fault domain, the fault domain determination module 702 is further used to:

[0179] Based on the instance types of the cloud resource instances included in the candidate hosts in each candidate fault domain, each candidate fault domain is screened to obtain a screened candidate fault domain; in the above screened candidate fault domain, the instance types of the cloud resource instances included in the candidate hosts are not located in the above anti-affinity set;

[0180] The weight value determination module 703 is specifically used for:

[0181] For each candidate host in the screened candidate fault domain, a scheduling weight value corresponding to the candidate host is determined based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located.

[0182] In a possible implementation, if there is any candidate host machine located in multiple fault domains, the weight value determination module 703 is specifically used to:

[0183] Based on the resource amount of any of the candidate host machines, a first weight value corresponding to any of the candidate host machines is generated; the resource amount is used to characterize the available resources of the corresponding candidate host machine;

[0184] Based on the grading information corresponding to each of the candidate fault domains in the multiple fault domains where the above-mentioned any candidate host is located, generating a second weight value corresponding to the above-mentioned any candidate host; the above-mentioned grading information is determined based on the topological structure of the above-mentioned any candidate fault domain;

[0185] Based on the first weight value and the second weight value, a scheduling weight value corresponding to any of the candidate host machines is determined.

[0186] In a possible implementation manner, the classification information is the regional weight of the corresponding candidate fault domain, and the weight value determination module 703 is specifically used to:

[0187] Obtain the coverage corresponding to each fault domain;

[0188] Based on the preset correspondence between coverage and regional weight, determine the regional weight corresponding to each fault domain; wherein, the larger the coverage, the larger the corresponding regional weight;

[0189] The regional weights corresponding to the above-mentioned candidate fault domains are summed up to generate a second weight value corresponding to any of the above-mentioned candidate host machines.

[0190] In a possible implementation manner, the acquisition module 701 is specifically configured to:

[0191] When a change is detected in a cloud resource instance in a resource scheduling group corresponding to any business, each cloud resource instance included in the resource scheduling group is used as the cloud resource instance to be scheduled; or,

[0192] When a change in a host machine in any fault domain is detected, each cloud resource instance currently configured on the host machine is used as the cloud resource instance to be scheduled.

[0193] In a possible implementation manner, the fault domain determination module 702 is specifically configured to:

[0194] Obtain the scheduling scope corresponding to the above cloud resource instance;

[0195] Based on the target instance type of the cloud resource instance, at least one candidate fault domain is determined from the fault domains within the scheduling range.

[0196] Based on the same inventive concept, an electronic device is also provided in an embodiment of the present application, and the electronic device can implement the functions of the aforementioned cloud resource instance scheduling device, referring to Figure 8 , the electronic device comprises:

[0197] At least one processor 801, and a memory 802 connected to the at least one processor 801. The specific connection medium between the processor 801 and the memory 802 is not limited in the embodiment of the present application. Figure 8 In the example, the processor 801 and the memory 802 are connected via a bus 800. Figure 8The connections between other components are shown in bold lines, and are not intended to be limiting. The bus 800 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, Figure 8 Only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. Alternatively, the processor 801 can also be called a controller, and there is no limitation on the name.

[0198] In the embodiment of the present application, the memory 802 stores instructions that can be executed by at least one processor 801. The at least one processor 801 can execute the cloud resource instance scheduling method discussed above by executing the instructions stored in the memory 802. The processor 801 can implement Figure 7 The functions of each module in the device shown.

[0199] Among them, the processor 801 is the control center of the device, and can use various interfaces and lines to connect the various parts of the entire control device. By running or executing instructions stored in the memory 802 and calling the data stored in the memory 802, the various functions of the device and process data, the device can be monitored as a whole.

[0200] In one possible design, the processor 801 may include one or more processing units, and the processor 801 may integrate an application processor and a modem processor, wherein the application processor mainly processes an operating system, a user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the modem processor may not be integrated into the processor 801. In some embodiments, the processor 801 and the memory 802 may be implemented on the same chip, and in some embodiments, they may also be implemented separately on separate chips.

[0201] Processor 801 can be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, and can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the cloud resource instance scheduling method disclosed in the embodiments of the present application can be directly embodied as a hardware processor execution, or can be executed by a combination of hardware and software modules in the processor.

[0202] The memory 802 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 802 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. The memory 802 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 802 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0203] By designing and programming the processor 801, the code corresponding to the application anomaly detection method described in the above embodiment can be fixed into the chip, so that the chip can execute the code when running. Figure 3 The steps of the cloud resource instance scheduling method of the embodiment shown are as follows: How to design and program the processor 801 is a technology well known to those skilled in the art and will not be described in detail here.

[0204] An embodiment of the present application also provides a computer-readable storage medium that stores computer-executable instructions required to execute the above-mentioned processor, which includes a program required to execute the above-mentioned processor.

[0205] In some possible implementations, various aspects of the cloud resource instance scheduling method provided in the present application may also be implemented in the form of a program product, which includes a program code. When the above-mentioned program product is run on an electronic device, the above-mentioned program code is used to enable the above-mentioned electronic device to execute the steps of the cloud resource instance scheduling method according to various exemplary implementations of the present application described above in this specification.

[0206] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, devices, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0207] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (apparatus), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0208] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0209] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0210] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

[0211] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A cloud resource instance scheduling method, characterized in that: The method comprises: Get the cloud resource instance to be scheduled; For each cloud resource instance, based on the target instance type of the cloud resource instance, at least one candidate fault domain is determined from each fault domain; the target instance type is determined based on the business attribute of the cloud resource instance corresponding to the target instance type, each fault domain includes at least one host machine, and there is an overlapping relationship between fault domains of different levels; For each candidate host in the candidate fault domain, determine a scheduling weight value corresponding to the candidate host based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located; For each cloud resource instance, based on the respective scheduling weight values ​​of the candidate host machines corresponding to the cloud resource instance, a target host machine is selected from the candidate host machines, and the cloud resource instance is scheduled to the target host machine.

2. The method according to claim 1, characterized in that The determining at least one candidate fault domain from each fault domain based on the target instance type of the cloud resource instance includes: For any fault domain, determine the number of reference hosts included in the fault domain, wherein the reference host is a host of a cloud resource instance including a target instance type; At least one candidate fault domain is determined from each fault domain based on the number of reference hosts included in each fault domain.

3. The method according to claim 1, characterized in that If an anti-affinity set corresponding to the cloud resource instance is pre-configured, and the anti-affinity set includes instance types of each cloud resource instance having an anti-affinity relationship with the cloud resource instance to be scheduled; then after determining at least one candidate fault domain from each fault domain and before determining the scheduling weight value corresponding to the candidate host, the method further includes: Based on the instance types of the cloud resource instances included in the candidate host machines in each candidate fault domain, each candidate fault domain is screened to obtain a screened candidate fault domain; in the screened candidate fault domain, the instance types of the cloud resource instances included in the candidate host machines are not located in the anti-affinity set; The step of determining, for each candidate host in the candidate fault domain, a scheduling weight value corresponding to the candidate host based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located, includes: For each candidate host in the screened candidate fault domain, a scheduling weight value corresponding to the candidate host is determined based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located.

4. The method according to claim 1, characterized in that: If there is any candidate host machine located in multiple fault domains, the scheduling weight value corresponding to the candidate host machine is determined based on the resource amount of the candidate host machine and the classification information of the fault domain in which the candidate host machine is located, including: Based on the resource amount of any candidate host machine, generating a first weight value corresponding to any candidate host machine; the resource amount is used to characterize the available resources of the corresponding candidate host machine; Based on the grading information corresponding to each of the candidate fault domains in the multiple fault domains where the any candidate host is located, generating a second weight value corresponding to the any candidate host; the grading information is determined based on the topological structure of the any candidate fault domain; Based on the first weight value and the second weight value, a scheduling weight value corresponding to any one of the candidate host machines is determined.

5. The method according to claim 4, characterized in that The grading information is a regional weight of a corresponding candidate fault domain. Before generating a second weight value corresponding to any candidate host based on the grading information corresponding to each candidate fault domain in a plurality of fault domains in which any candidate host is located, the method further includes: Obtain the coverage corresponding to each fault domain; Based on the preset correspondence between coverage and regional weight, determine the regional weights corresponding to each fault domain; wherein the larger the coverage, the larger the corresponding regional weight; The generating a second weight value corresponding to any candidate host machine based on the classification information corresponding to each candidate fault domain in the multiple fault domains where the any candidate host machine is located includes: The regional weights corresponding to the candidate fault domains are summed to generate a second weight value corresponding to any candidate host machine.

6. The method according to claim 1, characterized in that The obtaining of the cloud resource instance to be scheduled includes: When a change is detected in a cloud resource instance in a resource scheduling group corresponding to any service, each cloud resource instance included in the resource scheduling group is used as the cloud resource instance to be scheduled; or, When a change in a host machine in any fault domain is detected, each cloud resource instance currently configured on the host machine is used as the cloud resource instance to be scheduled.

7. The method according to any one of claims 1 to 6, characterized in that: The determining at least one candidate fault domain from each fault domain based on the target instance type of the cloud resource instance includes: Obtaining a scheduling scope corresponding to the cloud resource instance; At least one candidate fault domain is determined from the fault domains within the scheduling range based on the target instance type of the cloud resource instance.

8. A cloud resource instance scheduling device, characterized in that: The device comprises: An acquisition module is used to acquire cloud resource instances to be scheduled; A fault domain determination module is used to determine, for each cloud resource instance, at least one candidate fault domain from each fault domain based on a target instance type of the cloud resource instance; the target instance type is determined based on a business attribute of the cloud resource instance corresponding to the target instance type, each fault domain includes at least one host machine, and there is an overlapping relationship between fault domains of different levels; A weight value determination module is used to determine, for each candidate host in the candidate fault domain, a scheduling weight value corresponding to the candidate host based on the resource amount of the candidate host and the classification information of the fault domain in which the candidate host is located; The scheduling module is used to select a target host from each candidate host corresponding to each cloud resource instance based on the respective scheduling weight values ​​of the candidate host corresponding to the cloud resource instance, and schedule the cloud resource instance to the target host.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to implement the method according to any one of claims 1 to 7 when executing a computer program stored in the memory.

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

Images