A cluster resource planning method, equipment and apparatus

Abstract

This invention discloses a cluster resource planning method, device, and apparatus applied to a public cloud platform. The method includes: for each instance of a module in a list of instances to be scheduled obtained according to a first preset priority, a second preset priority, and preset resource requirements; selecting a host node from a host node list according to a first preset rule to obtain a pre-selected host node list; selecting the optimal host node from the pre-selected host node list according to a second preset rule to obtain a binding relationship between the host node and the instance; adjusting the binding relationship between the host node and the instance; and after confirming that the adjusted binding relationship meets preset conditions, deploying the instance corresponding to the host node in the adjusted binding relationship to the host node. This invention achieves automated resource allocation, improves the efficiency of resource planning, and automatically optimizes and reduces the number of nodes used in the cluster, balances the cluster resource load, and improves resource utilization.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a cluster resource planning method, device, and apparatus. Background Technology

[0002] With the advent of the cloud computing era, various big data components have been widely used with the help of public cloud platforms, especially for deploying multiple components in a cluster.

[0003] Currently, when deploying multiple components on a cluster based on a public cloud platform, the involvement of relevant experts is required. Experts' experience is used to determine the compatibility and mutual exclusion of different components on cluster nodes. In addition, it is necessary to confirm the resource requirements of component instances and pre-allocate different component instances on multiple host nodes as evenly as possible.

[0004] However, the above-mentioned cluster resource planning methods require expert intervention and rely on experts to manually process work orders, resulting in low processing efficiency. In addition, the above methods may also lead to the waste of host nodes and uneven resource allocation. Summary of the Invention

[0005] This invention provides a cluster resource planning method, device, and apparatus to solve the problems of low cluster resource allocation efficiency, waste of host nodes, and uneven resource allocation in the prior art.

[0006] In a first aspect, embodiments of the present invention provide a cluster resource planning method applied to a public cloud platform, comprising:

[0007] After obtaining the host node list and the first component list to be deployed, the first component list is sorted according to the first preset priority, the second preset priority and the preset resource requirements to obtain the list of instances to be scheduled.

[0008] For each instance in each module of the list of instances to be scheduled, a host node is selected from the host node list according to the first preset rule to obtain a pre-selected host node list corresponding to the current instance;

[0009] According to the second preset rule, after selecting the optimal host node from the list of pre-selected host nodes, the optimal host node is bound to the current instance to obtain the binding relationship between the host node and the instance;

[0010] The binding relationship between the host node and the instance is adjusted. After confirming that the adjusted binding relationship meets the preset conditions, the instance corresponding to the host node in the adjusted binding relationship is deployed to the host node.

[0011] This invention provides a cluster resource planning method. A first component list is obtained and sorted according to a first preset priority, a second preset priority, and preset resource requirements to obtain a list of instances to be scheduled. For each instance in each module of the list of instances to be scheduled, a pre-selected host node list is determined according to a first preset rule, and the optimal host node to be bound to the current instance is selected from the pre-selected host node list according to a second preset rule, thus obtaining the binding relationship between the host node and the instance. The binding relationship is adjusted, and after confirming that the adjusted binding relationship meets preset conditions, the instance corresponding to the host node is deployed according to the adjusted binding relationship. This cluster resource planning method can automate deployment, thereby improving deployment efficiency. Furthermore, by readjusting the obtained binding relationship between host nodes and instances, the cluster resource allocation result is rebalanced. While ensuring the availability of component services, it automatically optimizes and reduces the number of nodes used in the cluster, balances the cluster resource load, and improves resource utilization.

[0012] In one optional implementation, the preset conditions include:

[0013] The number of host nodes used in the adjusted binding relationship is less than the number of host nodes used in the unadjusted binding relationship; or

[0014] The number of host nodes used in the adjusted binding relationship is equal to the number of host nodes used in the unadjusted binding relationship, and the variance of the average resource utilization of the host nodes after the adjustment is less than the variance of the average resource utilization of the host nodes before the adjustment.

[0015] The above method adjusts the binding relationship between host nodes and instances. Based on preset conditions, it determines whether the adjusted binding relationship should be retained. If the adjusted binding relationship meets the preset conditions, it is retained, and instances are deployed according to the adjusted binding relationship. If the adjusted binding relationship does not meet the preset conditions, the binding relationship between host nodes and instances is adjusted again. That is, if the number of host nodes used in the adjusted binding relationship is less than the number of host nodes used in the original binding relationship, or if the number of host nodes used in the adjusted binding relationship is equal to the number of host nodes used in the original binding relationship, and the variance of the average resource utilization rate of the host nodes in the adjusted binding relationship is less than the variance of the average resource utilization rate of the host nodes in the original binding relationship, then this is considered a positive optimization process, and the adjusted binding relationship is retained and executed; otherwise, it is not retained. By judging the rationality of the adjusted binding relationship through preset conditions, the retained adjusted binding relationships are those that have undergone positive optimization, thereby automatically optimizing and reducing the number of nodes used in the cluster, balancing the cluster resource load, improving resource utilization, and obtaining better resource allocation results.

[0016] In one optional implementation, adjusting the binding relationship between the host node and the instance includes:

[0017] In the binding relationship between the host nodes and instances, any one host node is designated as the source host node, and the other host nodes are designated as the target host nodes.

[0018] For any instance among the instances corresponding to the source host node, traverse the target host nodes and select a first target host node that satisfies the deployment of the instance;

[0019] Add the instance to the instance corresponding to the first target host node in the binding relationship.

[0020] The above method employs a random optimization approach. It selects any one host node in the binding relationship as the source host node and the other host nodes as target host nodes. For any instance corresponding to the source host node, it selects a first target host node that meets the deployment requirements of that instance and adds that instance to the instances corresponding to the first target host node. By randomly selecting the source host node, the target host node, and instances from the instances corresponding to the source host node, the binding relationship between host nodes and instances is randomly optimized to balance the resource allocation of the cluster.

[0021] In one optional implementation, sorting the first component list according to a first preset priority, a second preset priority, and preset resource requirements to obtain a list of instances to be scheduled includes:

[0022] The components in the first component list are sorted in descending order according to the first preset priority to obtain the second component list;

[0023] The modules corresponding to each component in the second component list are sorted in descending order according to the second preset priority to obtain the component module list corresponding to the current component.

[0024] For each module in the component module list, an instance is created for the module based on the attribute information of the number of instances corresponding to the module, thus obtaining a component module instance list;

[0025] For each instance in the component module instance list, the component module instance list is sorted in descending order according to the preset resource requirements of the instance to obtain the list of instances to be scheduled.

[0026] The above method sorts the components in the first component list in descending order according to a first preset priority, sorts the modules corresponding to each component in descending order according to a second preset priority, creates instances for each module based on the number of instances corresponding to that module, and sorts the instances in descending order according to preset resource requirements, thus obtaining a list of instances to be scheduled. Therefore, by sorting each component and each module corresponding to a component by priority, and sorting the instances corresponding to each module by preset resource requirements, the method ensures that the affinity dependency strategy of the deployed instances is correctly resolved, thereby improving the quality of the allocation results.

[0027] In one optional implementation, the first preset rule includes:

[0028] The current host node satisfies the strong affinity rule;

[0029] Furthermore, the current host node satisfies the strong anti-affinity rule;

[0030] Furthermore, the available resources of the current host node meet the deployment requirements of the current instance.

[0031] The above method selects host nodes from the host node list according to a first preset rule. Specifically, it determines whether the current host node satisfies the strong affinity rule, the strong anti-affinity rule, and the available resources of the current host node. If the current node simultaneously meets all three conditions, it is designated as a pre-selected host node and added to the pre-selected host node list corresponding to the current instance. If the current node does not meet any of the three conditions, the next host node is selected. This pre-screening method initially identifies the available pre-selected host nodes for the current instance, narrowing the selection range and improving the efficiency of node allocation.

[0032] In one optional implementation, selecting the optimal host node from the pre-selected host node list according to the pre-selected host node list and the second preset rule includes:

[0033] For each host node corresponding to each instance, the score of the host node corresponding to the instance is determined according to the preset correspondence between host nodes, instances and scores.

[0034] The scores of each host node corresponding to each instance are compared, and the host node with the highest score is selected as the optimal host node.

[0035] The method described above determines the score of the host node corresponding to an instance based on a pre-defined correspondence between host nodes, instances, and scores. It then compares the scores of each host node to select the host node with the highest score as the optimal host node. This method offers flexible scoring rules for host nodes corresponding to instances, allowing for broad adaptation to different types of host nodes and improving its versatility.

[0036] In an optional implementation, if the host nodes with the highest scores include at least two, the method further includes:

[0037] The remaining resources of the host nodes with the highest scores after deploying the current module are compared, and the host node with the fewest remaining resources is selected as the optimal host node.

[0038] In the above method, if there are at least two host nodes with the highest scores, the remaining resources after deploying the current module on these two host nodes are compared, and the host node with the fewest remaining resources is selected as the optimal host node. Therefore, by using a double-optimization rule that selects the host node with the highest score and the fewest remaining resources after deploying the current module, the superiority of resource allocation results is ensured, while also improving the resource utilization rate of the nodes.

[0039] In an optional implementation, if the list of pre-selected host nodes corresponding to any instance is empty, the method further includes:

[0040] Obtain other host nodes outside the host node list and add them to the host node list;

[0041] Deploy the instance to the host node.

[0042] The above method, if the pre-selected host node list for any instance is empty, retrieves other host nodes outside the host node list, adds them to the pre-selected host node list, and deploys the current instance to that host node. By retrieving other host nodes from outside the host node list, the possibility of instance allocation failure is reduced, thereby improving the reliability of cluster resource allocation results.

[0043] Secondly, embodiments of the present invention provide a cluster resource planning device applied to a public cloud platform, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the cluster resource planning method described in any of the above embodiments.

[0044] Thirdly, embodiments of the present invention provide a cluster resource planning device applied to a public cloud platform, comprising:

[0045] The priority sorting module is used to sort the first component list according to the first preset priority, the second preset priority and the preset resource requirements after obtaining the host node list and the first component list to be deployed, so as to obtain the list of instances to be scheduled.

[0046] The rule verification module is used to select a host node from the host node list according to a first preset rule for each instance in each module of the list of instances to be scheduled, so as to obtain a pre-selected host node list corresponding to the current instance.

[0047] The resource optimization module is used to select the optimal host node from the list of pre-selected host nodes according to the second preset rule, and then bind the optimal host node to the current instance to obtain the binding relationship between the host node and the instance.

[0048] The resource rebalancing module is used to adjust the binding relationship between host nodes and instances. After determining that the adjusted binding relationship meets the preset conditions, the instance corresponding to the host node in the adjusted binding relationship is deployed to the host node.

[0049] Fourthly, embodiments of the present invention provide a computer storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the steps of the cluster resource planning method described in any of the above embodiments.

[0050] For the technical effects that the cluster resource planning equipment disclosed in the second aspect, the cluster resource planning device disclosed in the third aspect, and the computer storage medium disclosed in the fourth aspect may achieve, please refer to the above description of the technical effects that can be achieved for the first aspect or the various possible solutions in the first aspect, and will not be repeated here. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 This is a flowchart illustrating a cluster resource planning method provided in an embodiment of the present invention.

[0053] Figure 2 This is a flowchart illustrating another cluster resource planning method provided in an embodiment of the present invention;

[0054] Figure 3 A flowchart illustrating an affinity rule verification method provided in an embodiment of the present invention;

[0055] Figure 4 A flowchart illustrating a method for determining the available resources of a host node according to an embodiment of the present invention;

[0056] Figure 5 A flowchart illustrating a resource planning and optimization method provided in an embodiment of the present invention;

[0057] Figure 6 A flowchart illustrating a resource rebalancing optimization method provided in an embodiment of the present invention;

[0058] Figure 7 This is a schematic diagram of the structure of a cluster resource planning device provided in an embodiment of the present invention;

[0059] Figure 8 This is a schematic diagram of the module structure of a cluster resource planning device provided in an embodiment of the present invention;

[0060] Figure 9 This is a schematic diagram of a program product for a cluster resource planning method provided in an embodiment of the present invention. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0062] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0063] Currently, when deploying multiple components to a customer cluster on a public cloud platform, the involvement of relevant experts is required. Experts use their experience to determine the compatibility and mutual exclusion of different components on cluster nodes, confirm the resource requirements of component instances, and pre-allocate different component instances on multiple host nodes as evenly as possible. However, since the above method requires experts to manually process work orders, it cannot automate the processing of work orders. As business volume increases, the creation of public cloud clusters will be limited by the efficiency of expert processing. In addition, the above method also has the problems of wasting host nodes and uneven distribution of cluster resources.

[0064] To address the aforementioned problems, embodiments of the present invention provide a cluster resource planning method, device, and apparatus, which improve the efficiency of cluster resource planning, reduce the number of nodes used in the cluster, balance the allocation of cluster resources, and increase resource utilization.

[0065] Example 1

[0066] The following specific embodiments illustrate a cluster resource planning method provided by the present invention. This method is applied to a public cloud platform, such as... Figure 1 As shown, it includes:

[0067] Step 101: After obtaining the host node list and the first component list to be deployed, sort the first component list according to the first preset priority, the second preset priority and the preset resource requirements to obtain the list of instances to be scheduled.

[0068] Step 102: For each instance in each module in the list of instances to be scheduled, select a host node from the host node list according to the first preset rule to obtain a pre-selected host node list corresponding to the current instance;

[0069] Step 103: According to the second preset rule, after selecting the optimal host node from the list of pre-selected host nodes, bind the optimal host node to the current instance to obtain the binding relationship between the host node and the instance;

[0070] Step 104: Adjust the binding relationship between the host node and the instance. After confirming that the adjusted binding relationship meets the preset conditions, deploy the instance corresponding to the host node in the adjusted binding relationship to the host node.

[0071] It should be noted that the cluster resource planning method provided by this invention can be applied to cloud hosts, network-side devices, GPU (Graphics Processing Unit) computing devices, and terminals. Here, no specific limitation is made to the application scenarios of this cluster resource planning method.

[0072] In this embodiment of the invention, after sorting the obtained first component list according to a first preset priority, a second preset priority, and preset resource requirements, a list of instances to be scheduled is obtained. For each instance in each module of the list of instances to be scheduled, a list of pre-selected host nodes is determined according to a first preset rule, and the optimal host node to be bound to the current instance is selected from the list of pre-selected host nodes according to a second preset rule, thus obtaining the binding relationship between the host node and the instance. The above binding relationship is adjusted, and after confirming that the adjusted binding relationship meets preset conditions, the instance corresponding to the host node is deployed according to the adjusted binding relationship. This cluster resource planning method can achieve automation, thereby improving deployment efficiency. In addition, by readjusting the obtained binding relationship between host nodes and instances, the result of cluster resource allocation is rebalanced. While ensuring the availability of component services, it automatically optimizes and reduces the number of nodes used in the cluster, balances the cluster resource load, and improves resource utilization.

[0073] In addition, this method can be widely adapted to various resource allocation scenarios and has good versatility.

[0074] In one embodiment, the first component list is sorted according to a first preset priority, a second preset priority, and preset resource requirements to obtain a list of instances to be scheduled. First, each component in the first component list is sorted in descending order according to the first preset priority to obtain a second component list. Then, the modules corresponding to each component in the second component list are sorted in descending order according to the second preset priority to obtain a list of component modules corresponding to the current component. Next, for each module in the component module list, instances are created for the module based on the number of instances corresponding to the module, resulting in a list of component module instances. Finally, for each instance in the component module instance list, the component module instance list is sorted in descending order according to the preset resource requirements of the instance to obtain a list of instances to be scheduled.

[0075] In specific implementation, such as Figure 2 The diagram shown is an overall flowchart of a cluster resource planning method provided by the present invention. (See also...) Figure 2 21 in the text refers to the specific process of sorting the first component list according to the first preset priority, the second preset priority, and the preset resource requirements to obtain the list of instances to be scheduled. This process includes the following steps:

[0076] Step 201: Obtain the host node list Hosts and the first component list Components1 to be deployed;

[0077] Specifically, the Hosts list includes all host nodes owned by the cluster.

[0078] Step 202: Sort the first component list according to the first preset priority to obtain the second component list Components2;

[0079] Specifically, the first component list Components1 is iterated through, and each component in Components1 is sorted in ascending order of priority value. The priority value of a component is the pre-configured `priority` attribute, where `priority` is a positive integer value; the smaller the `priority` value, the higher the priority of the corresponding component. In other words, after obtaining the first component list Components1 to be deployed, the first component list Components1 is iterated through, and each component in Components1 is sorted in ascending order of priority value, resulting in the second component list Components2. The components in the second component list Components2 are arranged in descending order of priority.

[0080] Step 203: Traverse the second component list and sort the modules corresponding to each component according to the second preset priority;

[0081] Specifically, the modules corresponding to each component in the second component list Components2 are sorted in descending order according to the second preset priority to obtain the component module list corresponding to the current component. The second preset priority is the preset priority of the module, which is defined by the internal structure of the corresponding component and the order of the modules contained in the component is not adjusted.

[0082] Step 204: Determine whether the current module is a dynamic module. If so, set the dynamic flag to true for the current module; otherwise, proceed to step 205.

[0083] Specifically, modules can be divided into dynamic modules and static modules according to their type. The attribute information of the module is set in advance by the replica value. If the replica value of the current module is a magic number, it indicates that the current module is a dynamic module. For example, the replica value of the current module is 999999 or 999998. If the replica value of the current module is not a magic number, it indicates that the current module is a static module. For example, the replica value of the current module is 3.

[0084] Step 205: Create a corresponding instance for each module based on the attribute information of the number of instances corresponding to the module.

[0085] For example, if the current module is a static module and the number of instances of the module is 3, then create three instances a1, a2, and a3 and add them to the list of instances to be scheduled; if the current module is a dynamic module, then create the corresponding instances according to the number of host nodes and add them to the list of instances to be scheduled.

[0086] Specifically, for each module in the component module list, instances are created for the module based on the attribute information of the number of instances corresponding to the module, thus obtaining the component module instance list. That is, the number of instances generated for the module is equal to the number of replicas corresponding to the module's replica value. If the current module's replica value is a magic number, it indicates that the current module is a dynamic module. Instances are created based on the given number of host nodes, and the created instances are added to the list of instances to be scheduled. For example, if the current module's replica value is 999999, it means the module is deployed on all host nodes; if the current module's replica value is 999998, it means the module is deployed on two-thirds of the host nodes. If the current module's replica value is not a magic number, it indicates that the current module is a static module. Instances are created based on the current module's replica value. For example, if the current module's replica value is 3, it means the current module contains 3 instances, so 3 instances are created, and the created instances are added to the list of instances to be scheduled.

[0087] Step 206: Sort the instances from largest to smallest according to their preset resource requirements;

[0088] Specifically, instances are sorted in descending order according to their preset resource requirements to obtain a list of instances to be scheduled. For example, preset resource requirements can include the number of CPU cores, memory (GB), and disk (GB) required for instance deployment.

[0089] For example, suppose the cluster has 5 host nodes and needs to be allocated 3 different big data components. Let the 5 host nodes be A1, A2, ..., A5, and the 3 components be B1, B2, and B3. Component B1 contains 3 modules: B11, B12, and B13; component B2 contains 2 modules: B21 and B22; and component B3 contains 4 modules: B31, B32, B33, and B34. Modules B12 and B33 are dynamic modules, while the remaining modules are static modules, and each static module contains 2 instances. The list of the first component, the second component, the component module list, and the list of instances to be scheduled are shown in Table 1.

[0090]

[0091] Table 1

[0092] In this embodiment of the invention, components in the first component list are sorted in descending order according to a first preset priority, and modules corresponding to each component are sorted in descending order according to a second preset priority. Instances are created for each module based on the number of instances corresponding to it, and the instances are sorted in descending order according to preset resource requirements, thereby obtaining a list of instances to be scheduled. Therefore, by sorting each component and each module corresponding to a component according to priority, and sorting the instances corresponding to each module according to preset resource requirements, the affinity dependency strategy of the deployed instances is correctly resolved, thereby improving the quality of the allocation results.

[0093] In one embodiment, the first preset rule includes: the current host node satisfies the strong affinity rule; and the current host node satisfies the strong anti-affinity rule; and the available resources of the current host node meet the deployment requirements of the current instance.

[0094] It should be noted that, assuming a host node A1, component B1, and component B2, if instance C11 of component B1 is deployed to host node A1, then host node A1 must also deploy instance C21 of component B2. In this case, instances C11 and C21 conform to the strong affinity rule, meaning they are bound together when deployed on host node A1. Conversely, if instance C11 of component B1 is deployed to host node A1, then host node A1 cannot deploy instance C21 of component B2. In this case, instances C11 and C21 conform to the strong anti-affinity rule, meaning they are mutually exclusive when deployed on host node A1. These strong affinity and strong anti-affinity rules are predefined and can be specifically represented by an affinity rule list.

[0095] For specific implementation, see Figure 2 22 in the diagram describes the specific process of selecting host nodes from the host node list according to the first preset rule to obtain a pre-selected host node list corresponding to the current instance, which includes the following steps:

[0096] Step 207: Traverse the list of instances to be scheduled and initialize the list of pre-selected host nodes PreChooseHosts corresponding to the current instance;

[0097] Specifically, for each instance in the list of instances to be scheduled, a list of pre-selected host nodes corresponding to the current instance needs to be initialized to ensure the accuracy of the pre-selected host list obtained according to the first preset rule.

[0098] Step 208: Traverse the host node list Hosts, ensuring compliance with affinity rules and hard constraints on CPU performance, memory, and disk performance;

[0099] Step 209: Determine whether the current host node satisfies the strong affinity rule. If yes, proceed to step 210; otherwise, return to step 208.

[0100] Specifically, we can first select an instance that is allowed to be deployed corresponding to the current host node from the list of instances to be scheduled. Then, for each instance that is allowed to be deployed, if the current instance has a binding relationship with the instance that is allowed to be deployed, that is, if the strong affinity rule is satisfied, then the current instance can be deployed to the current host node. If the current instance does not satisfy the strong affinity rule, then we can proceed. Then we can iterate through the next host node in the list of host nodes.

[0101] Step 210: Determine whether the current host node satisfies the strong anti-affinity rule. If yes, proceed to step 211; otherwise, return to step 208.

[0102] Specifically, firstly, select the allowed deployment instance corresponding to the current host node from the list of instances to be scheduled. Then, for each allowed deployment instance, if the current instance and the allowed deployment instance meet the non-mutual exclusion principle, that is, do not satisfy the strong anti-affinity rule, then the current instance has the possibility of being deployed to the current host node. If the current instance satisfies the strong anti-affinity rule, then the current instance cannot be deployed to the current host node. Then, traverse the next host node in the host node list.

[0103] Specifically, such as Figure 3 The flowchart shown is for affinity rule validation, which includes the following steps:

[0104] Step 301: Input the affinity rule list AffinityList and obtain the current host node list Hosts;

[0105] Specifically, the expression of the rule to be validated in the affinity rule list AffinityList includes strong affinity rules and strong anti-affinity rules.

[0106] Step 302: Traverse the affinity rule list AffinityList to obtain the current rule expression to be verified;

[0107] Here, we determine whether the rule to be verified is a strong affinity rule or a strong anti-affinity rule.

[0108] Step 303: Based on the node attribute key specified by the current rule expression to be verified, obtain the attribute value X corresponding to the node;

[0109] Specifically, if the current rule to be verified is a strong anti-affinity rule, based on the node attribute specified by the strong anti-affinity rule as a module, the attribute value X1 of the current host node is obtained, where X1 is a list of all instances allowed to be deployed on the current node. If the current rule to be verified is a strong affinity rule, based on the node attribute specified by the strong affinity rule as a module, the attribute value X2 of the current host node is obtained, where X2 is a list of all instances allowed to be deployed on the current node.

[0110] Step 304: Invoke different operation logic according to the operation type operator specified by the current rule expression to be verified;

[0111] Specifically, if the current rule to be verified is a strong anti-affinity rule, based on the node attribute specified by the strong anti-affinity rule as a module, the attribute value X1 of the current host node is obtained, and the IN operation logic is called, then step 305 is executed. If the current rule to be verified is a strong affinity rule, based on the node attribute specified by the strong affinity rule as a module, the attribute value X2 of the current host node is obtained, and the EXIST operation logic is called, then step 307 is executed.

[0112] Step 305: Determine which operation logic is called. If the IN operation logic is called, proceed to step 306. If the NOTIN operation logic is called, proceed to step 307. If the EXIST operation logic is called, proceed to step 308. If the NOTEXIST operation logic is called, proceed to step 309.

[0113] It should be noted that the four operation logics IN, NOTIN, EXIST, and NOTEXIST are unrelated to which affinity rule is selected; they only indicate whether the currently scheduled rule has been triggered. That is, each affinity rule can call any of the four operation logics.

[0114] Step 306: Iterate through X, iterate through the values ​​specified by the current rule expression to be validated. If there is a match, return true; otherwise, return false.

[0115] For example, if the current rule to be verified is a strong anti-affinity rule, let X be the list of instances allowed to be deployed on host node A1 corresponding to instance C35, where the value of X is C31, C35, C39, C16, and C23, and the value of the set values ​​is C16 and C33. This means that C35 and C16 satisfy the strong anti-affinity rule, and the two instances cannot be deployed on the same host node at the same time. C35 and C33 also satisfy the strong anti-affinity rule, and the two instances cannot be deployed on the same host node at the same time. Since there is a match between X and values, i.e., both have C16, the return value is true, triggering the strong anti-affinity rule.

[0116] Step 307: Iterate through X, iterate through the values ​​specified by the current rule expression to be validated. If there is no match, return true; otherwise, return false.

[0117] For example, if the current rule to be verified is a strong affinity rule, let X be the list of instances allowed to be deployed on host node A1 corresponding to instance C35, where the value of X is C31, C35, C39, C16, and C23, and the value of the set values ​​is C14 and C33. This means that C35 and C14 satisfy the strong affinity rule, and the two instances must be deployed on the same host node. C35 and C33 also satisfy the strong affinity rule, and the two instances must be deployed on the same host node. Since there is no match between X and values, i.e., there are no identical instances, the return value is true, and the strong affinity rule is not triggered.

[0118] Step 308: Iterate through X. If it is not empty, return true; otherwise, return false.

[0119] For example, if the current rule to be verified is a strong anti-affinity rule, let X be the list of instances that can be deployed on host node A1 corresponding to instance C35, where the value of X is C31, C35, C39, C16, C23. Iterate through X, and since X is not empty, return true.

[0120] Step 309: Iterate through X. If it is empty, return true; otherwise, return false.

[0121] For example, if the current rule to be verified is a strong anti-affinity rule, let X be the list of instances that host node A1 corresponding to instance C35 is allowed to deploy, where the value of X is an empty set. Traverse X, and since X is empty, return the value true.

[0122] Step 211: Determine whether the available resources of the current host node are sufficient. If yes, proceed to step 212; otherwise, return to step 208.

[0123] Specifically, select an instance that is allowed to be deployed from the list of instances to be scheduled and that corresponds to the current host node; for each instance that is allowed to be deployed, if the available resources of the current host node meet the deployment requirements of the current instance, then the current instance is allowed to be deployed to the current host node; if the available resources of the current host node do not meet the deployment requirements of the current instance, then the current instance cannot be deployed to the current host node, and then iterate through the next host node in the list of host nodes.

[0124] Specifically, to determine whether the available resources of the current host node meet the deployment requirements of the current instance, we can assess the availability of resources in three dimensions: CPU, memory, and disk. If all three dimensions of the available resources of the current host node meet the deployment requirements of the current instance, the current host node is added to the pre-selected host node list. If any one of the three dimensions of the available resources of the current host node does not meet the deployment requirements of the current instance, we then select the next host node from the host node list.

[0125] like Figure 4 The diagram shown illustrates the specific flowchart for determining whether the available resources of the current host node are sufficient, including the following steps:

[0126] Step 401: Obtain the available resources of the current host node and the preset resource requirements of the current instance;

[0127] Step 402: Determine whether the available CPU of the current host node is greater than the CPU required by the current instance. If yes, proceed to step 403; otherwise, proceed to step 406.

[0128] Step 403: Determine whether the available memory of the current host node is greater than the memory required by the current instance. If yes, proceed to step 404; otherwise, proceed to step 406.

[0129] Step 404: Determine whether the available disk space of the current host node is greater than the disk space required by the current instance. If yes, proceed to step 405; otherwise, proceed to step 406.

[0130] Step 405: The current host node has sufficient available resources, so add it to the pre-selected host node list PreChooseHosts;

[0131] Step 406: The current host node does not have enough available resources and cannot be added to the PreChooseHosts list.

[0132] It's important to note that the weighting of CPU, memory, and disk differs across cluster types. For example, in compute-intensive clusters, the weighting of CPU and memory can be increased during the host node selection process, meaning host nodes with higher CPU and / or larger memory will be preferred. Conversely, in storage-intensive clusters, the weighting of disk can be increased, meaning host nodes with larger disk sizes will be preferred. By configuring different weightings for different cluster types, superior host nodes can be selected.

[0133] Specifically, firstly, select the allowed deployment instance corresponding to the current host node from the list of instances to be scheduled. Then, for each allowed deployment instance, if the instance is bound to the allowed deployment instance and meets the non-exclusivity principle, and the available resources of the current host node meet the deployment requirements of the current instance, then the current host node meets the first preset rule and is added to the pre-selected host node list PreChooseHosts. If the current host node does not meet any of the above first preset rules, then traverse the next host node in the host node list.

[0134] Step 212: Add the current host node to the pre-selected host node list PreChooseHosts;

[0135] Specifically, if the PreChooseHosts list corresponding to any instance is empty, other host nodes outside the list can be retrieved and added to the list; the instance is then deployed to those host nodes. This method reduces the probability of instance allocation failure by retrieving other host nodes from outside the list, thereby improving the reliability of cluster resource allocation results.

[0136] In this embodiment of the invention, a host node is selected from the host node list according to a first preset rule. Specifically, it is determined whether the current host node satisfies the strong affinity rule, the strong anti-affinity rule, and whether the available resources of the current host node are sufficient. If the current node simultaneously meets all three conditions, it is designated as a pre-selected host node and added to the pre-selected host node list corresponding to the current instance. If the current node does not meet any of the three conditions, the next host node is selected. This pre-screening method initially identifies the available pre-selected host nodes for the current instance, narrowing the selection range and improving the efficiency of node allocation.

[0137] In one embodiment, the optimal host node is selected from the pre-selected host node list according to the second preset rule. First, for each host node corresponding to each instance, the score of the host node corresponding to the instance is determined according to the preset correspondence between host nodes, instances and scores. Then, the scores of each host node corresponding to each instance are compared, and the host node with the highest score is selected as the optimal host node.

[0138] It should be noted that, assuming a host node A1, component B1, and component B2, if instance C11 of component B1 is deployed on host node A1, it is recommended to also deploy instance C21 of component B2 on host node A1 to improve system performance. However, if instance C21 of component B2 does not exist, deploying only instance C11 of component B1 on host node A1 will still achieve system functionality. Here, the relationship between instances C11 and C21 follows the weak affinity rule. That is, deploying both instance C11 of component B1 and instance C21 of component B2 on host node A1 results in superior system performance. Deploying either instance C11 of component B1 or instance C21 of component B2 on host node A1 will also improve system performance. System performance can also be achieved. If instance C11 in component B1 is deployed to host node A1, it is not recommended to deploy instance C21 in component B2 to host node A1 as well. However, if there are unforeseen circumstances that necessitate deploying both instance C11 in component B1 and instance C21 in component B2 to host node A1, system functionality can still be achieved, but system performance will be reduced. Here, instances C11 and C21 satisfy the weak affinity rule, meaning that deploying either instance C11 in component B1 or instance C21 in component B2 on host node A1 results in superior system performance. Deploying both instance C11 in component B1 and instance C21 in component B2 on host node A1 also achieves the desired system performance. The aforementioned weak affinity and weak anti-affinity rules are predefined and can be represented in the form of an affinity rule list.

[0139] Specifically, the weak affinity rules and weak anti-affinity rules specified in the affinity rule list pre-define a score (weight) for each host node. The scores defined in the weak affinity rules are positive integers, while the scores defined in the weak anti-affinity rules are negative integers. For each node in the pre-selected host nodes corresponding to the current instance, the rule to be verified for the current host node is determined according to the affinity rule list. If the rule to be verified for the current host node is a weak affinity rule, then based on the score defined in the weak affinity rule, the score for the current host node allowed to deploy the current instance can be obtained, where the obtained score is a positive integer. If the rule to be verified for the current host node is a weak anti-affinity rule, then based on the score defined in the weak anti-affinity rule, the score for the current host node allowed to deploy the current instance can be obtained, where the obtained score is a negative integer.

[0140] In practical implementation, if the current host node A1 can deploy n instances, C1, C2, ..., Cn, assume that the score of the current host node A1 for instance C1 is Y1; the score of the current host node A1 for instance C2 is Y2; ..., the score of the current host node A1 for instance Cn is Yn; the summation of the above scores Y1, Y2, ..., Yn can be obtained to obtain the total score Y of the current host node, and then the host node with the highest score is selected as the optimal host node.

[0141] In this embodiment of the invention, based on a preset correspondence between host nodes, instances, and scores, the score of the host node corresponding to an instance is determined, and the scores of each host node are compared to select the host node with the highest score as the optimal host node. This method offers flexible scoring rules for the host nodes corresponding to instances, allowing for broad adaptation to different types of host nodes and improving its versatility.

[0142] Specifically, if there are at least two host nodes with the highest scores, the remaining resources of the two host nodes with the highest scores after deploying the current module can be compared, and the host node with the fewest remaining resources can be selected as the optimal host node.

[0143] For specific implementation, see Figure 2 Section 23 includes a flowchart detailing the process of selecting the optimal host node from the pre-selected host node list and binding the optimal host node to the current instance, thus establishing the binding relationship between the host node and the instance. This flowchart includes the following steps:

[0144] Step 213: Iterate through the list of pre-selected host nodes PreChooseHosts, score each host node, and select the optimal host node.

[0145] Step 214: Determine whether the weak affinity rule score of the current host node is greater than the highest score of the host node. If it is greater, proceed to step 216; if it is equal, proceed to step 215; if it is less, return to step 213.

[0146] Step 215: Based on the heuristic algorithm, select the host node with the best resource matching as the optimal host node;

[0147] Specifically, such as Figure 5 The diagram shows the workflow of a heuristic algorithm for optimizing resource planning results, including the following steps:

[0148] Step 501: Enter the list of instances to be scheduled and the list of pre-selected host nodes (PreChooseHosts);

[0149] Step 502: For each instance in the list of instances to be scheduled, iterate through its corresponding list of pre-selected host nodes, PreChooseHosts.

[0150] Step 503: Select the current host node and calculate the remaining resources t1 of the current host node after deploying the current instance;

[0151] Step 504: Determine whether the remaining resource t1 of the current host node is the minimum remaining resource t_best. If yes, proceed to step 505; otherwise, return to step 503.

[0152] Step 505: Record the current host node as the optimal host node.

[0153] Step 216: Bind the current instance to the optimal host node to obtain the binding relationship between the host node and the instance;

[0154] In this embodiment of the invention, if there are at least two host nodes with the highest scores, the remaining resources of these two host nodes after deploying the current module are compared. The host node with the fewest remaining resources is selected as the optimal host node, thereby improving the resource utilization of the host nodes. Furthermore, by employing a dual-optimization rule that selects the host node with the highest score and the fewest remaining resources after deploying the current module, the superiority of the resource allocation result is ensured while also improving the resource utilization of the nodes.

[0155] In one embodiment, the binding relationship between host nodes and instances can be adjusted by first designating any one host node as the source host node and the other host nodes as target host nodes. Then, for any instance corresponding to the source host node, the target host nodes are traversed to select a first target host node that satisfies the deployment of the instance. Finally, the instance is added to the instance corresponding to the first target host node in the binding relationship.

[0156] In this embodiment of the invention, a random optimization approach is adopted. Any host node in the binding relationship is selected as the source host node, and the other host nodes are selected as target host nodes. For any instance corresponding to the source host node, a first target host node that meets the deployment requirements of that instance is selected, and that instance is added to the instances corresponding to the first target host node. By randomly selecting the source host node, randomly selecting the target host node, and randomly selecting instances from the instances corresponding to the source host node, the binding relationship between host nodes and instances is randomly optimized to balance the resource allocation of the cluster.

[0157] In one embodiment, the preset conditions include: the number of host nodes used in the adjusted binding relationship is less than the number of host nodes used in the binding relationship before adjustment; or the number of host nodes used in the adjusted binding relationship is equal to the number of host nodes used in the binding relationship before adjustment, and the variance of the average resource utilization rate of the host nodes after adjustment is less than the variance of the average resource utilization rate of the host nodes before adjustment.

[0158] Specifically, referring to Figure 2 23 in

[0159] Step 217, determine whether a host node has been deployed for each instance. If so, execute step 218; otherwise, execute step 220.

[0160] Step 218, adjust the binding relationship between the host nodes and the instances. After determining that the adjusted binding relationship meets the preset conditions, update the binding relationship between the host nodes and the instances.

[0161] Specifically, as Figure 6 shown, it is a flowchart of the host node resource rebalancing method, including the following steps:

[0162] Step 601, obtain the binding relationship between the host nodes and the instances, and set the number of attempted optimizations T.

[0163] Step 602, select any one host node as the source host node, and other host nodes as the target host nodes.

[0164] Step 603, calculate the variance aavg of the average resource utilization rate of the target host nodes in the binding relationship before adjustment and the number of host nodes used C.

[0165] Step 604, select any one instance corresponding to the source host node and traverse the target host nodes.

[0166] Step 605, determine whether the current instance can be deployed to the target node. If so, execute step 606; otherwise, return to step 604.

[0167] Step 606, the current optimization count is t = t + 1, and calculate the variance aavg' of the average resource utilization rate of the current host node in the adjusted binding relationship and the number of host nodes used C'.

[0168] Step 607, determine whether the condition C' < C or (C' = C and aavg' < aavg) is satisfied. If so, execute step 608; otherwise, return to step 604.

[0169] Specifically, the above conditions are preset conditions, that is, the number of host nodes used in the adjusted binding relationship is less than the number of host nodes used in the binding relationship before adjustment; or the number of host nodes used in the adjusted binding relationship is equal to the number of host nodes used in the binding relationship before adjustment, and the variance of the average resource utilization rate of the host nodes after adjustment is less than the variance of the average resource utilization rate of the host nodes before adjustment.

[0170] Step 608, adjust the binding relationship between the host node and the instance, and update the number of host nodes used C = C', and the variance of the average resource utilization rate aavg = aavg'.

[0171] Step 609, determine whether the condition t < T is satisfied. If so, return to Step 604; otherwise, end.

[0172] Specifically, if the current number of optimization times is equal to the preset number of optimization times, it means that the optimization has been completed. Then, end the optimization process of resource rebalancing and output the adjusted binding relationship between the host node and the instance.

[0173] Step 219, output the adjusted binding relationship between the host node and the component module instance;

[0174] Step 220, output the reason for allocation failure and the list of allocated host nodes.

[0175] In the embodiment of the present invention, the binding relationship between the host node and the instance is adjusted, and it is judged whether the adjusted binding relationship needs to be retained according to the preset conditions. If the adjusted binding relationship meets the preset conditions, the adjusted binding relationship is retained, and the instance is deployed according to the adjusted binding relationship; if the adjusted binding relationship does not meet the preset conditions, the binding relationship between the host node and the instance is adjusted again. That is to say, if the number of host nodes used in the adjusted binding relationship is less than the number of host nodes used in the binding relationship before adjustment, or the number of host nodes used in the adjusted binding relationship is equal to the number of host nodes used in the binding relationship before adjustment, and the variance of the average resource utilization rate of the host nodes after adjustment is less than the variance of the average resource utilization rate of the host nodes before adjustment, it is determined that this is a positive optimization process, and the adjusted binding relationship is retained and executed; otherwise, it is not retained. By judging the rationality of the adjusted binding relationship through the preset conditions, the retained adjusted binding relationship is a binding relationship that has been positively optimized, so that the nodes used by the cluster can be automatically optimized and reduced, the resource load of the cluster can be balanced, the utilization rate of resources can be improved, and a more excellent resource allocation result can be obtained.

[0176] In one embodiment, the method can also quantify expert experience into a set of JSON template files, including a list of affinity rules, a first preset priority, a second preset priority, available resources of the host node, and preset weights.

[0177] If there is no template file based on expert experience, it is necessary to pre-define the relationships between the modules in the component, the affinity rule list, the first preset priority, the second preset priority, the preset weight, and the available resources of the host node.

[0178] By solidifying expert experience and generating template files, cluster resource planning methods can be automated efficiently. The template files define component affinity rules, which can accurately express the dependencies and mutual exclusion relationships between components. Furthermore, the template files can be used to consider the resource requirements of components in layers, taking into account the requirements of different layers separately. In addition, different template combinations can be introduced as needed, and their priority relationships can be adjusted according to requirements to ensure the rationality and excellence of resource allocation.

[0179] Example 2

[0180] Based on the same concept, this embodiment of the invention also provides a cluster resource planning device for use on a public cloud platform. Since this cluster resource planning device is the same as the cluster resource planning device in the method of this embodiment of the invention, and the principle of solving the problem by this cluster resource planning device is similar to that of this method, the implementation of this cluster resource planning device can refer to the implementation of the method, and the repeated parts will not be described again.

[0181] The following reference Figure 7 To describe a cluster resource planning device 70 according to this embodiment of the invention. Figure 7 The cluster resource planning device 70 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0182] like Figure 7 As shown, the cluster resource planning device 70 can be represented as a general-purpose computing device, such as a terminal device. The components of the cluster resource planning device 70 may include, but are not limited to: at least one processor 71, at least one memory 72 for executing instructions by the processor 71, and a bus 73 connecting different system components (including memory 72 and processor 71), wherein the processor 71 is a processor of an intelligent device.

[0183] Processor 71 performs the following steps by executing executable instructions:

[0184] After obtaining the list of host nodes and the list of first components to be deployed, the list of first components is sorted according to the first preset priority, the second preset priority and the preset resource requirements to obtain the list of instances to be scheduled.

[0185] For each instance in each module of the list of instances to be scheduled, a host node is selected from the host node list according to the first preset rule to obtain a pre-selected host node list corresponding to the current instance;

[0186] According to the second preset rule, after selecting the optimal host node from the list of pre-selected host nodes, the optimal host node is bound to the current instance to obtain the binding relationship between the host node and the instance.

[0187] Adjust the binding relationship between the host node and the instance. After confirming that the adjusted binding relationship meets the preset conditions, deploy the instance corresponding to the host node in the adjusted binding relationship to the host node.

[0188] In one embodiment, the preset conditions include:

[0189] The number of host nodes used in the adjusted binding relationship is less than the number of host nodes used in the unadjusted binding relationship; or

[0190] The number of host nodes used in the adjusted binding relationship is equal to the number of host nodes used in the unadjusted binding relationship, and the variance of the average resource utilization of the host nodes after the adjustment is less than the variance of the average resource utilization of the host nodes before the adjustment.

[0191] In one embodiment, processor 71 is specifically used for:

[0192] In the binding relationship between host nodes and instances, any one host node is used as the source host node, and the other host nodes are used as the target host nodes;

[0193] For any instance among the instances corresponding to the source host node, traverse the target host nodes and select a first target host node that satisfies the deployment instance;

[0194] Add the instance to the instance corresponding to the first target host node in the binding relationship.

[0195] In one embodiment, processor 71 is specifically used for:

[0196] The components in the first component list are sorted in descending order according to the first preset priority to obtain the second component list;

[0197] Based on the second preset priority, the modules corresponding to each component in the second component list are sorted in descending order to obtain the component module list corresponding to the current component.

[0198] For each module in the component module list, create an instance for the module based on the attribute information of the number of instances corresponding to the module, and obtain the component module instance list;

[0199] For each instance in the component module instance list, the component module instance list is sorted in descending order according to the instance's preset resource requirements to obtain a list of instances to be scheduled.

[0200] In one embodiment, the first preset rule includes:

[0201] The current host node satisfies the strong affinity rule;

[0202] Furthermore, the current host node satisfies the strong anti-affinity rule;

[0203] Furthermore, the amount of available resources on the current host node meets the deployment requirements of the current instance.

[0204] In one embodiment, processor 71 is specifically used for:

[0205] For each host node corresponding to each instance, the score of the host node corresponding to the instance is determined according to the preset correspondence between host nodes, instances and scores.

[0206] The scores of each host node corresponding to each instance are compared, and the host node with the highest score is selected as the optimal host node.

[0207] In one embodiment, if the host nodes with the highest scores include at least two, the processor 71 is further configured to:

[0208] Compare the remaining resources of at least two host nodes with the highest scores after deploying the current module, and select the host node with the fewest remaining resources as the optimal host node.

[0209] In one embodiment, if the list of pre-selected host nodes corresponding to any instance is empty, the processor 71 is further configured to:

[0210] Retrieve other host nodes not listed in the host node list and add them to the host node list;

[0211] Deploy the instance to the host node.

[0212] Bus 73 represents one or more of several bus structures, including a memory bus or memory controller, peripheral bus, processor, or a local bus using any of the various bus structures.

[0213] The memory 72 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 721 and / or cache memory 722, and may further include read-only memory (ROM) 723.

[0214] The memory 72 may also include a program / utility 725 having a set (at least one) of program modules 724, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0215] The cluster resource planning device 70 can also communicate with one or more external devices 74 (e.g., keyboard, pointing device, etc.), one or more devices that enable users to interact with the cluster resource planning device 70, and / or any device that enables the cluster resource planning device 70 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 75. Furthermore, the cluster resource planning device 70 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 76. As shown, network adapter 76 communicates with other modules of the electronic device 70 via bus 73. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the cluster resource planning device 70, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0216] Example 3

[0217] Based on the same concept, this embodiment of the invention also provides a cluster resource planning device applied to a public cloud platform. Since this device is the same as the device in the method of this embodiment of the invention, and the principle of the device in solving the problem is similar to that of the method, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0218] like Figure 8 As shown, the above-mentioned device includes the following modules:

[0219] The priority sorting module 801 is used to sort the first component list according to the first preset priority, the second preset priority and the preset resource requirements after obtaining the host node list and the first component list to be deployed, so as to obtain the list of instances to be scheduled.

[0220] The rule verification module 802 is used to select a host node from the host node list according to the first preset rule for each instance in each module of the instance to be scheduled, so as to obtain a pre-selected host node list corresponding to the current instance.

[0221] The resource selection module 803 is used to select the optimal host node from the list of pre-selected host nodes according to the second preset rule, and then bind the optimal host node to the current instance to obtain the binding relationship between the host node and the instance.

[0222] The resource rebalancing module 804 is used to adjust the binding relationship between host nodes and instances. After confirming that the adjusted binding relationship meets the preset conditions, it deploys the instance corresponding to the host node in the adjusted binding relationship to the host node.

[0223] In one embodiment, the preset conditions include:

[0224] The number of host nodes used in the adjusted binding relationship is less than the number of host nodes used in the unadjusted binding relationship; or, the number of host nodes used in the adjusted binding relationship is equal to the number of host nodes used in the unadjusted binding relationship, and the variance of the average resource utilization of the host nodes after the adjustment is less than the variance of the average resource utilization of the host nodes before the adjustment.

[0225] In one embodiment, the resource rebalancing module 804 is specifically used for:

[0226] In the binding relationship between host nodes and instances, any one host node is designated as the source host node, and the other host nodes are designated as target host nodes. For any instance among the instances corresponding to the source host node, iterate through the target host nodes and select a first target host node that satisfies the deployment of the instance. Add the instance to the instance corresponding to the first target host node in the binding relationship.

[0227] In one embodiment, the priority sorting module 801 is specifically used for:

[0228] The components in the first component list are sorted in descending order according to the first preset priority to obtain the second component list; the modules corresponding to each component in the second component list are sorted in descending order according to the second preset priority to obtain the component module list corresponding to the current component; for each module in the component module list, an instance is created for the module according to the attribute information of the number of instances corresponding to the module to obtain the component module instance list; for each instance in the component module instance list, the component module instance list is sorted in descending order according to the preset resource requirements of the instance to obtain the list of instances to be scheduled.

[0229] In one embodiment, the first preset rule includes:

[0230] The current host node satisfies the strong affinity rule; and the current host node satisfies the strong anti-affinity rule; and the available resources of the current host node meet the deployment requirements of the current instance.

[0231] In one embodiment, the resource selection module 803 is specifically used for:

[0232] For each host node corresponding to each instance, the score of the host node corresponding to the instance is determined according to the preset correspondence between host nodes, instances and scores; the scores of each host node corresponding to each instance are compared, and the host node with the highest score is selected as the optimal host node.

[0233] In one embodiment, if the host nodes with the highest scores include at least two, the resource selection module 803 is further configured to:

[0234] Compare the remaining resources of at least two host nodes with the highest scores after deploying the current module, and select the host node with the fewest remaining resources as the optimal host node.

[0235] In one embodiment, if the list of pre-selected host nodes corresponding to any instance is empty, the resource selection module 803 is further configured to:

[0236] Retrieve other host nodes outside the host node list and add them to the host node list; deploy the instance to the host node.

[0237] Example 4

[0238] In some possible implementations, various aspects of the present invention can also be implemented as a program product, including program code. When the program product is run on a terminal device, the program code is used to cause the terminal device to execute the steps of each module in the cluster resource planning apparatus according to various exemplary embodiments of the present disclosure as described in the "Exemplary Methods" section of this specification. For example, the network-side device can obtain a list of host nodes and a list of first components to be deployed, and then sort the list of first components according to a first preset priority, a second preset priority, and preset resource requirements to obtain a list of instances to be scheduled. For each instance in each module in the list of instances to be scheduled, a host node is selected from the host node list according to a first preset rule to obtain a list of pre-selected host nodes corresponding to the current instance. After selecting the optimal host node from the list of pre-selected host nodes according to a second preset rule, the optimal host node is bound to the current instance to obtain a binding relationship between the host node and the instance. The binding relationship between the host node and the instance is adjusted, and after determining that the adjusted binding relationship meets preset conditions, the instance corresponding to the host node in the adjusted binding relationship is deployed to the host node.

[0239] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0240] like Figure 9 As shown, a program product 90 for cluster resource planning according to an embodiment of the present invention is described. This product may employ a portable compact disk read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0241] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take many forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0242] The program code contained on the readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wired, optical fiber, RF, or any suitable combination thereof.

[0243] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0244] It should be noted that although several modules or sub-modules of the system have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more modules described above can be embodied in one module. Conversely, the features and functions of one module described above can be further divided and embodied by multiple modules.

[0245] The present application has been described above with reference to block diagrams and / or flowcharts illustrating methods, apparatus (systems), and / or computer program products according to embodiments of the present application. It should be understood that a block of a block diagram and / or flowchart, as well as combinations of blocks of block diagrams and / or flowcharts, 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, and / or other programmable data processing means to produce a machine, such that the instructions, executable via the computer processor and / or other programmable data processing means, create methods for implementing the functions / actions specified in the blocks of the block diagrams and / or flowcharts.

[0246] Accordingly, this application can also be implemented using hardware and / or software (including firmware, resident software, microcode, etc.). Furthermore, this application can take the form of a computer program product on a computer-usable or computer-readable storage medium, having computer-usable or computer-readable program code implemented in the medium for use by or in conjunction with an instruction execution system. In the context of this application, a computer-usable or computer-readable medium can be any medium that can contain, store, communicate, transmit, or deliver a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0247] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A cluster resource planning method, characterized in that, Applied to public cloud platforms, including: After obtaining the host node list and the first component list to be deployed, each component in the first component list is sorted in descending order according to the first preset priority to obtain the second component list. The modules corresponding to each component in the second component list are sorted in descending order according to the second preset priority to obtain the component module list corresponding to the current component. For each module in the component module list, an instance is created for the module based on the attribute information of the number of instances corresponding to the module, resulting in a component module instance list. If the module is a dynamic module, a corresponding instance is created based on the number of host nodes. For each instance in the component module instance list, the component module instance list is sorted in descending order according to the preset resource requirements of the instance to obtain a list of instances to be scheduled. For each instance in each module of the list of instances to be scheduled, a host node is selected from the host node list according to the first preset rule to obtain a pre-selected host node list corresponding to the current instance; According to the second preset rule, after selecting the optimal host node from the list of pre-selected host nodes, the optimal host node is bound to the current instance to obtain the binding relationship between the host node and the instance; The binding relationship between the host node and the instance is adjusted. After confirming that the adjusted binding relationship meets the preset conditions, the instance corresponding to the host node in the adjusted binding relationship is deployed to the host node.

2. The method as described in claim 1, characterized in that, The preset conditions include: The number of host nodes used in the adjusted binding relationship is less than the number of host nodes used in the unadjusted binding relationship; or The number of host nodes used in the adjusted binding relationship is equal to the number of host nodes used in the unadjusted binding relationship, and the variance of the average resource utilization of the host nodes after the adjustment is less than the variance of the average resource utilization of the host nodes before the adjustment.

3. The method as described in claim 2, characterized in that, The adjustment of the binding relationship between the host node and the instance includes: In the binding relationship between the host nodes and instances, any one host node is designated as the source host node, and the other host nodes are designated as the target host nodes. For any instance among the instances corresponding to the source host node, traverse the target host nodes and select a first target host node that satisfies the deployment of the instance; Add the instance to the instance corresponding to the first target host node in the binding relationship.

4. The method as described in claim 1, characterized in that, The first preset rule includes: The current host node satisfies the strong affinity rule; Furthermore, the current host node satisfies the strong anti-affinity rule; Furthermore, the available resources of the current host node meet the deployment requirements of the current instance.

5. The method as described in claim 1, characterized in that, The step of selecting the optimal host node from the pre-selected host node list according to the pre-selected host node list and the second preset rule includes: For each host node corresponding to each instance, the score of the host node corresponding to the instance is determined according to the preset correspondence between host nodes, instances and scores. The scores of each host node corresponding to each instance are compared, and the host node with the highest score is selected as the optimal host node.

6. The method as described in claim 5, characterized in that, If the host nodes with the highest scores include at least two, the method further includes: The remaining resources of the host nodes with the highest scores after deploying the current module are compared, and the host node with the fewest remaining resources is selected as the optimal host node.

7. The method according to any one of claims 1 to 6, characterized in that, If the list of pre-selected host nodes corresponding to any instance is empty, the method also includes: Obtain other host nodes outside the host node list and add them to the host node list; Deploy the instance to the host node.

8. A cluster resource planning device, characterized in that, The method is applied to a public cloud platform and includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the cluster resource planning method according to any one of claims 1 to 7.

9. A cluster resource planning device, characterized in that, Applied to public cloud platforms, including: The priority sorting module is used to obtain the host node list and the first component list to be deployed, and then sort each component in the first component list in descending order according to a first preset priority to obtain a second component list; sort the modules corresponding to each component in the second component list in descending order according to a second preset priority to obtain a component module list corresponding to the current component; for each module in the component module list, create an instance for the module according to the attribute information of the number of instances corresponding to the module to obtain a component module instance list, wherein if the module is a dynamic module, the corresponding instance is created according to the number of host nodes; for each instance in the component module instance list, sort the component module instance list in descending order according to the preset resource requirements of the instance to obtain a list of instances to be scheduled. The rule verification module is used to select a host node from the host node list according to a first preset rule for each instance in each module of the list of instances to be scheduled, so as to obtain a pre-selected host node list corresponding to the current instance. The resource optimization module is used to select the optimal host node from the pre-selected host node list according to the pre-selected host node list and the second preset rule, and bind the optimal host node to the current instance to obtain a first binding relationship list; The resource rebalancing module is used to adjust the binding relationship between host nodes and instances in the first binding relationship list according to the first binding relationship list and the third preset rule to obtain a second binding relationship list, so as to plan and allocate cluster resources according to the second binding relationship list.

Images