Multi-cluster hybrid deployment system for heterogeneous models

Abstract

The invention provides a multi-cluster hybrid deployment system of a heterogeneous model. Relates to the technical field of computers, in particular to the technical fields of cluster management, heterogeneous resource management and the like. According to the specific implementation scheme, a plurality of clusters are constructed based on heterogeneous models; each cluster comprises a plurality of machine groups; each machine group corresponds to respective first target service; for each machine group, the machine group is obtained by grouping the requirements of the corresponding first target service for the hardware features; and dynamically performing resource adjustment among different machine groups in the same cluster according to the resource requirement of the second target service supported by the cluster.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of cluster management, heterogeneous resource management, etc. Background Art

[0002] In the field of computer technology, with the continuous expansion and diversification of services, the demand for computing resources has become increasingly complex. The multi-cluster architecture has emerged. By dividing different computing resources into multiple clusters and respectively undertaking corresponding workloads, classified management and efficient utilization of resources are realized. Summary of the Invention

[0003] This disclosure provides a multi-cluster hybrid deployment system for heterogeneous machine types to solve or alleviate one or more technical problems in the prior art.

[0004] In a first aspect, this disclosure provides a multi-cluster hybrid deployment system for heterogeneous machine types, including: Multiple clusters built based on heterogeneous machine types; Each cluster includes multiple machine groups; each machine group corresponds to its own first target service respectively; for each machine group, the machine group is obtained by grouping according to the requirements of the corresponding first target service for hardware characteristics; Within the same cluster, according to the resource requirements of the second target service supported by the cluster, resources are dynamically adjusted between different machine groups within the cluster.

[0005] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of this disclosure, nor is it used to limit the scope of this disclosure. Other features of this disclosure will become easily understood through the following description. Brief Description of the Drawings

[0006] In the drawings, unless otherwise specified, the same reference numerals throughout the multiple drawings denote the same or similar components or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings only depict some embodiments provided by this disclosure and should not be regarded as limiting the scope of this disclosure.

[0007] Figure 1 is an exemplary architecture diagram of a multi-cluster hybrid deployment system for heterogeneous machine types according to the first embodiment of this disclosure; Figure 2 is a schematic flowchart of dynamically adjusting resources between different machine groups within a cluster according to the second embodiment of this disclosure; Figure 3 is a schematic structural flowchart of machine resource adjustment between different machine groups according to the third embodiment of this disclosure; Figure 4It is a schematic flow chart of load balancing between clusters according to the fourth embodiment of the present disclosure; Figure 5 It is a schematic flow chart of configuring a cluster for a new service according to the fifth embodiment of the present disclosure; Figure 6 It is a schematic execution scheduling diagram of a multi-cluster hybrid deployment system with heterogeneous machine types according to the sixth embodiment of the present disclosure; Figure 7 It is a schematic structural diagram of an electronic device of a multi-cluster hybrid deployment system with heterogeneous machine types according to the seventh embodiment of the present disclosure. Detailed implementation manners

[0008] Hereinafter, the present disclosure will be described in further detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements having the same or similar functions. Although various aspects of the embodiments are shown in the drawings, the drawings do not have to be drawn to scale unless otherwise specified.

[0009] In addition, for better illustration of the present disclosure, numerous specific details are given in the following detailed implementation manners. Those skilled in the art should understand that the present disclosure can also be implemented without some of these specific details. In some instances, methods, means, elements, and circuits well known to those skilled in the art are not described in detail so as to highlight the gist of the present disclosure.

[0010] Furthermore, the terms "first" and "second" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the present disclosure, "a plurality of" means two or more unless otherwise specifically defined.

[0011] It should be noted that, unless it is clearly stated that there is a sequential execution order between different operations in the flow charts shown in the embodiments of the present disclosure, or there is a sequential execution order between different operations in terms of technical implementation, the execution order between multiple operations can be unordered, and multiple operations can also be executed simultaneously.

[0012] In the field of computer technology, cluster scheduling systems play a crucial role. However, existing cluster hybrid deployment solutions have many limitations: on the one hand, services in the cluster are difficult to fully utilize the advantageous resources of specific nodes; on the other hand, it is difficult to achieve the load balancing goal between online and offline hybrid deployment in a single cluster. These two aspects may lead to a reduction in the overall operating efficiency of the cluster.

[0013] In view of this, to solve at least one of the above problems, the embodiments of the present disclosure provide a multi-cluster hybrid deployment system for heterogeneous machine types. The system constructs a multi-dimensional resource model of cluster-machine group-machine-target service, effectively groups machines according to their own characteristics, and forms machine groups with differentiated capabilities. And based on the grouping results, load balancing scheduling between clusters and within a single cluster is achieved, thereby improving the overall utilization rate of machine resources in the cluster.

[0014] As Figure 1 shown, it is an exemplary architecture diagram of the multi-cluster hybrid deployment system for heterogeneous machine types provided by the present disclosure, including: Multiple clusters 101 built based on heterogeneous machine types. Among them, heterogeneous machine types refer to machines with characteristic differences at the hardware level such as operating system, graphics card type, disk type, network card type, etc. The multiple clusters built based on heterogeneous machine types are a collection of computing resources composed of multiple machines interconnected through a network. These machines work together to provide a unified service capability to the outside world.

[0015] Each cluster includes multiple machine groups 102. Each machine group corresponds to its own first target service respectively; for each machine group, the machine group is obtained by grouping according to the requirements of the corresponding first target service for hardware characteristics. Among them, each cluster contains multiple machine groups internally, and each machine group is formed by grouping according to the requirements of its corresponding first target service for machine hardware characteristics. Among them, the first target service can be understood as a specific function or application service. Different first target services may have different requirements for machine hardware characteristics.

[0016] During implementation, each machine can report its own characteristic information to the monitoring node of the cluster where it is located through its own agent (proxy). Each cluster can receive the characteristic information reported by each machine through its own monitoring node such as a resource manager. The monitoring center of the cluster divides the machines that meet the hardware characteristics required by the first target service into a machine group according to the requirements of the first target service for machine hardware characteristics. As Figure 1 shown, in cluster A, there are machine group A1 and machine group A2. The first target service corresponding to machine group A1 may be executed only under the conditions of a Linux (a computer system) system environment and high-performance graphics cards and high-read / write hard disks, so the machines with these characteristics are divided into machine group A1. Similarly, the first target service corresponding to machine group A2 may be executed only under the conditions of a Windows (a computer system) system environment and relatively high-performance graphics cards and faster-read / write hard disks, so the machines with these characteristics are divided into machine group A2.

[0017] In this system, within the same cluster, according to the resource requirements of the second target service supported by the cluster, resources are dynamically adjusted between different machine groups within the cluster.

[0018] The second target service is a service that needs to be coordinated and managed within the same cluster, and its resource requirements may change with factors such as time and business load. Within the same cluster, the services to be supported can also change dynamically. Therefore, according to the resource requirements of the second target service, resource adjustment can be performed between different machine groups in the same cluster to adjust the machines included in different machine groups, so as to ensure the efficient and stable operation of the entire cluster.

[0019] In the embodiments of the present disclosure, in a cluster architecture based on heterogeneous machine types, multiple clusters can be constructed, and each cluster can be targeted at different types of service requirements. When a certain service needs to be added, the system can quickly find suitable machine resources in the existing clusters and machine groups according to the resource requirements of the service for allocation, so as to support the flexible expansion of the service. Each cluster includes multiple machine groups. By grouping the machines that meet the first target service according to the requirements of the first target service for machine hardware characteristics, the system can ensure that the first target service can obtain a corresponding stable supply of machine resources, reducing the problems of waste of machine resources or insufficient performance caused by too high or too low hardware configuration. Moreover, the machine group can make full use of the advantageous resources of specific nodes. Within the same cluster, according to the resource requirements of the second target service supported by the cluster, dynamic resource adjustment is performed between different machine groups in the cluster, so that when the load is unbalanced between different machine groups, machine resources can be allocated in real time from the machine group with relatively abundant resources to the machine group in need, reducing the problem that the service performance of some machine groups in the same cluster decreases due to insufficient machine resources, and at the same time preventing the idle of machine resources in some machine groups, further optimizing the overall utilization efficiency of machine resources in the system.

[0020] In the embodiments of the present disclosure, online tasks and offline tasks are usually mixedly deployed in the same cluster to achieve the efficient utilization of machine resources in the cluster. Among them, online tasks have the characteristics of strong real-time performance. In emergency scenarios, there may be a situation where the existing configured machine resources are insufficient; while offline tasks have relatively loose requirements for the quality of machine resources and can run elastically when there are remaining machine resources.

[0021] Based on this, on the premise that the total amount of machine resources in the cluster is fixed, the allocation strategy can be dynamically adjusted according to the requirements of online tasks and offline tasks for machine resources. For example, when the load of online tasks surges, the idle machine resources of offline tasks can be temporarily called to ensure the normal operation of online tasks.

[0022] During implementation, to improve the security and stability of the machine resource migration process and reduce the problem of interfering with existing services running on the machine group caused by directly switching machines between machine groups, a more stable resource transition can be achieved by setting up an idle resource area, effectively avoiding the interruption or performance fluctuation of existing services in operation due to machines suddenly joining or leaving the machine group. Thus, dynamic resource adjustment can be realized between different machine groups within the cluster.

[0023] During implementation, in the multi-cluster hybrid deployment system of heterogeneous machine types in the embodiments of the present disclosure, monitoring nodes can be set in each cluster, and a general scheduling center can be set in the entire system. Among them, the monitoring nodes are used to manage the resource allocation problems within the cluster where they are located. The general scheduling center can manage the task allocation problems between clusters. It can be understood that the monitoring nodes can also be used as the medium for transmitting information within the corresponding cluster to transmit relevant information to the general scheduling center, and the general scheduling center manages the resource allocation within the cluster and the task allocation between clusters.

[0024] During implementation, within the same cluster, by maintaining an idle resource area, dynamic resource adjustment is carried out between different machine groups within the cluster. The specific implementation method can be as Figure 2 shown, which can be implemented by the monitoring nodes of the cluster, including: S201, maintain the idle resource area, and the idle resource area includes the idle machines released from the first target machine group.

[0025] The idle resource area refers to the area in the cluster specifically used for storing and managing idle machine resources. In the multi-cluster hybrid deployment system of heterogeneous machine types, it is used to manage the machine resources that are temporarily not in use in the cluster so that they can be quickly allocated to services that need the machine resources when needed.

[0026] During implementation, the implementation process of maintaining the idle resource area by using the idle machines released from the first target machine group can be as Figure 2 shown, including: S2011, based on a preset task eviction strategy, screen out the target tasks within the cluster.

[0027] In the embodiments of the present disclosure, the second target service is an online task with a resource demand growth rate exceeding the threshold, and the target task is an offline task. This threshold is used to represent the sudden occurrence of online tasks so that the cluster can cope with sudden situations. By deploying online tasks and offline tasks in the same cluster, the system can dynamically adjust the resource allocation strategy according to the real-time resource usage situation and business requirements, improving the efficiency and flexibility of cluster management.

[0028] The task eviction policy is a pre - set rule or method. According to this task eviction policy, the system will identify target tasks that meet the eviction conditions within the cluster. For example, it identifies target tasks with the least impact on the system for eviction.

[0029] When implemented, the pre - set task eviction policy can screen out target tasks by determining the eviction scores of each candidate task within the cluster and based on the eviction scores of each candidate task.

[0030] The eviction score is a quantitative metric used to evaluate whether each candidate task within the cluster is suitable for eviction. The eviction score can help the system quickly and objectively identify which candidate tasks can be suspended or terminated to release idle machines to the idle resource area.

[0031] Among them, the eviction score is determined based on at least one of the following parameters and has a positive correlation with each of the following parameters. These parameters include: the processor utilization rate of the candidate task, the storage resource utilization rate of the candidate task, and the execution duration of the candidate task.

[0032] Exemplarily, the eviction score can be described by formula (1): In formula (1), EvictStore represents the eviction score of each candidate task; CPU_util / 100 represents the processor utilization rate of each candidate task, that is, the CPU utilization rate of each candidate task in the corresponding machine group; Mem_util / 100 represents the storage resource utilization rate of each candidate task, which can include the memory utilization rate of each candidate task in the corresponding machine group; TaskAge / 24h represents the execution duration of each candidate task, in hours, with a maximum value of 24 hours, that is, the running time of the target task does not exceed 24 hours.

[0033] Sort each candidate task according to the eviction score, and select the candidate task with the smallest eviction score as the target task to perform the eviction operation. Among them, the smaller the score, the lower the processor utilization rate and storage resource utilization rate of the candidate task in the machine group, and the shorter the execution duration of the candidate task itself. At this time, evicting this task can efficiently release idle machine resources and have less impact on the task.

[0034] In the embodiments of the present disclosure, the eviction score is obtained by calculating at least one of the processor utilization rate, storage utilization rate, and task execution duration of each candidate task within the cluster. Deciding which candidate tasks to select as target tasks for eviction operations based on the eviction score can release machine resources at the lowest cost, avoid service interruptions caused by evicting high - load or critical tasks, achieve refined management of machine resource release on demand, and improve resource utilization and task scheduling efficiency in a heterogeneous cluster environment.

[0035] In S2012, evict the target task from the target machine running the target task in the first target machine group to release the resources of the target machine and obtain idle machines.

[0036] After screening out the target tasks based on the eviction scores of the candidate tasks, the system will evict the target tasks from the target machines running these target tasks. And set the status of the target machine from the busy state to the idle state, indicating that they are not running any tasks currently and can be used as idle resources for the system to allocate.

[0037] Among them, evicting the target task may involve pausing the execution of the task, migrating the task to other machines, or directly terminating the task, which depends on the specific policy and the nature of the task. The embodiments of the present disclosure do not limit this.

[0038] S2013, set the idle machines into the idle resource area.

[0039] That is, add the idle machines to the idle resource area. In this way, when other services or tasks in the same cluster in the system need to expand resources, they can quickly obtain available machine resources from this idle resource area.

[0040] In the embodiments of the present disclosure, through the preset task eviction policy, screen out the target tasks with less impact in the cluster, perform the eviction operation on the target machines running the tasks in the first target machine group to release the target machine resources and convert them into idle machines. At the same time, uniformly incorporate the idle machines into the idle resource area. When other services (such as the second target service) in the cluster need more resources, they can directly obtain these idle machines from the idle resource area, which not only avoids resource idleness but also improves the resource utilization efficiency of the entire cluster.

[0041] S202, for the second target service, perform dynamic resource adjustment among different machine groups through the idle resource area based on the resource expansion amount required by the second target service.

[0042] During implementation, the system will monitor the resource usage of the second target service in real time and evaluate its current resource requirements.

[0043] In the case that the second target machine group where the second target service is located needs to be expanded, based on the resource expansion amount required by the second target service, obtain idle machines that match the requirements of the second target service for hardware characteristics from the idle resource area; divide the idle machines into the second target machine group.

[0044] That is, the system will screen out eligible idle machines from the idle resource area according to the requirements of the second target service for machine hardware features, and assign them to the second target machine group that needs to be expanded. In this way, the machine resource capacity of the second target machine group is expanded, enabling it to more efficiently handle the increasing load requirements. At the same time, the system can continuously monitor the machine resource usage status of the second target machine group to further adjust the resource allocation strategy when necessary.

[0045] In the embodiments of the present disclosure, when the second target machine group where the second target service is located needs to be expanded, based on the required resource expansion amount of the second target service, idle machines that match the requirements of the second target service for hardware features are obtained from the idle resource area for expansion, which can effectively prevent problems such as system crashes or severe performance degradation caused by resource overload, and further ensure the continuity of the second target service. According to the actual load conditions of different machine groups, by dynamically expanding and allocating idle machines to machine groups with demands, on-demand allocation of machine resources can be achieved, improving the overall utilization rate of resources.

[0046] In the embodiments of the present disclosure, when the load of the second target service increases, the system (such as the monitoring node of the cluster) will calculate the required resource expansion amount. Calculating the required resource expansion amount of the second target service can be achieved based on the following steps: Step A1, when the second target service is an online task, determine the current idle resource amount in the total resources allocated to the offline task, and the online metric; the online metric is determined based on the resource quota allocated to the online task, and the online metric is less than the resource quota; Among them, the current idle resource amount in the total resources allocated to the offline task refers to the part of the resources allocated to the offline task that has not been used. The online metric is the amount of resources allocated to the online task to ensure the basic operation of the online task.

[0047] In implementation, the online metric can be planned and restricted through the quota (System Quota, a quota mechanism) mechanism, and the resource usage range of the online task can be restricted by setting the minimum quota and the maximum quota. Moreover, the quota usage situation can be supervised and adjusted when necessary to optimize resource allocation, so as to reasonably allocate and manage limited resources, prevent excessive resource consumption, and ensure the stable and efficient operation of the system.

[0048] The minimum quota refers to the minimum resource guarantee for the normal operation of the online task, to prevent the online task from being unable to work due to too little resources. When configuring the minimum quota of the online task, it must be ensured that the sum of the minimum quotas of each online task does not exceed the total physical resources actually owned by the cluster, so as to ensure the reasonable allocation of each service's minimum resource requirements without exceeding the overall bearing capacity of the cluster.

[0049] The maximum quota refers to the upper limit of resources that an online task can use, preventing the online task from overusing resources and affecting other services.

[0050] In the embodiments of the present disclosure, the online metric selects the maximum quota, and the maximum quota allows the online task to borrow more idle resources from the offline task. This allows the online task to apply for more resources in a short period of time, thus better coping with sudden high loads.

[0051] Step A2: Determine the resource expansion amount required for the second target service based on the current idle resource amount and the online metric.

[0052] During implementation, the resource expansion amount required for the second target service can be expressed by formula (2): Resource expansion amount = min(current idle resource amount, online metric × γ) (2) Among them, γ is the maximum borrowing ratio and can be set to 50%.

[0053] In the embodiments of the present disclosure, by determining the resource expansion amount required for the second target service, the system can determine the maximum value of the offline resources that the online task can borrow. This can ensure that the resources of the offline task are fully utilized without affecting the basic operation of the offline task, improving the resource utilization rate of the entire system.

[0054] In the embodiments of the present disclosure, to reduce the problem that the resources of the offline task cannot operate normally for a long time due to being borrowed for a long time, when the second target service is an online service and idle machines are obtained by evicting the offline service, the borrowing duration of the idle machines by the second target service can be set as the duration threshold; control the second target service to return a preset proportion of the idle machines borrowed from the offline task every specified period.

[0055] When the online task borrows machines from the offline task, the system will set a duration threshold for the borrowed machines, that is, the maximum preset time that the online service can borrow these idle machines. At the same time, the system will set a specified time period and require the online service to return the idle machines borrowed from the offline service at a preset proportion at the end of each period to ensure that the offline service can gradually resume resource usage. For example, if the borrowing period ≤ 2 hours, 20% of the borrowed resources need to be forcibly returned every hour.

[0056] In the embodiments of the present disclosure, when obtaining idle machines by evicting offline tasks, by setting the borrowing duration of the idle machines by the second target service to the duration threshold, and controlling the second target service to return a preset proportion of the idle machines borrowed from the offline tasks at intervals of a specified period, the resource requirements of online tasks and offline tasks within a single cluster can be balanced. By setting the borrowing duration and controlling the return period and proportion, the system can ensure that the online service obtains sufficient resources when needed, while avoiding long-term occupation of the resources of the offline service, thereby improving the resource utilization efficiency and flexibility of the entire system.

[0057] In summary, by maintaining the idle resource area, dynamic resource adjustment is performed between different machine groups within the cluster. For Figure 3 example, when the task load of machine group A surges, idle machine 1 resources that meet the task hardware characteristic requirements can be obtained from the idle resource area to ensure the normal operation of the tasks in machine group A.

[0058] During implementation, the tasks on machine 1 in machine group B can be evicted first through a preset task eviction policy, and the resources of machine 1 are released and incorporated into the idle resource area. Then, machine group A obtains machine 1 from the idle resource area to meet the demand for the surging task load.

[0059] In the embodiments of the present disclosure, by maintaining the idle resource area and using the idle resource area as a resource buffer pool, it is possible to quickly provide the required machine resources for the machine group that needs to be expanded, respond in a timely manner to the changes in the load of the second target service, and meet the sudden demands of the second target service. For the second target service, based on the resource expansion amount required by the second target service, dynamic resource adjustment is performed between different machine groups through the idle resource area to ensure that each machine group has sufficient machine resources to cope with the load changes, which can reduce the risk of interruption of the second target service caused by insufficient machine resources and improve the resource utilization efficiency.

[0060] In the embodiments of the present disclosure, in addition to the dynamic resource adjustment between each machine group in the same cluster described above. In the case of load imbalance between clusters, resource optimization scheduling can also be achieved through the following strategy, specifically as Figure 4 shown: S401, when it is determined that the difference between the load of the first cluster and the load of the second cluster meets the cross-cluster adjustment task condition, determine the task migration amount in the first cluster; the first cluster and the second cluster support the same task type.

[0061] During implementation, taking the first cluster as the high-load cluster and the second cluster as the low-load cluster as an example, the system (such as the general scheduling center) determines whether the load difference between the two clusters meets the cross-cluster adjustment task condition by setting a threshold. After determining that the cross-cluster adjustment task condition is met, it is necessary to calculate the task migration volume of the first cluster, that is, the number of tasks migrated from the high-load first cluster to the low-load second cluster.

[0062] In the embodiments of the present disclosure, determining the task migration volume in the first cluster can be achieved based on the following steps: Step A1, determining a first candidate migration volume based on the load of the first cluster; and determining a second candidate migration volume based on the load of the second cluster; Step A2, screening out the task migration volume from the first candidate migration volume and the second candidate migration volume.

[0063] During implementation, determining the first candidate migration volume based on the load of the first cluster can be obtained by subtracting the number of services that are crucial for business operation and not easily migrated in this cluster from the number of all services currently running in the first cluster; similarly, determining the second candidate migration volume based on the load of the second cluster can also be obtained by subtracting the number of services that are crucial for business operation and not easily migrated in this cluster from the number of all services currently running in the second cluster.

[0064] After that, the minimum value can be screened out from the first candidate migration volume and the second candidate migration volume as the task migration volume in the first cluster. Of course, a migration volume can be randomly selected from the range represented by the first candidate migration volume and the second candidate migration volume to obtain the task migration volume.

[0065] In the embodiments of the present disclosure, by calculating the candidate migration volumes of the first cluster and the second cluster and selecting the minimum value as the final task migration volume, the excess load in the first cluster is transferred to the second cluster, making the loads of the two clusters tend to be balanced, and at the same time avoiding overloading the second cluster due to migrating too many tasks.

[0066] It should be understood that the task migration between clusters also needs to ensure that the machine resource requirements of the tasks in the first cluster match the hardware characteristics of the machines in the second cluster.

[0067] S402, screening out the tasks to be migrated with the task migration volume from the first cluster.

[0068] Among them, the tasks to be migrated screened out are the tasks in the first cluster without the core task mark. By screening out the tasks without the core task mark for migration, it can be ensured that these core tasks continue to run stably in the first cluster without being interfered by the migration process. In this way, it is possible to avoid business interruption or performance degradation caused by migrating core tasks and ensure the continuity and reliability of the business.

[0069] S403. Migrate the task to be migrated to the machine group in the second cluster that supports the task to be migrated for execution.

[0070] In the embodiments of the present disclosure, by migrating the tasks in the first cluster to the second cluster with lighter load, the computing resources can be more evenly distributed, avoiding overloading of some clusters while leaving the resources of other clusters idle, thereby improving the overall resource utilization rate.

[0071] In the embodiments of the present disclosure, as the business scale expands and the complexity increases, the resource management strategy needs to be continuously optimized to meet diverse requirements. When facing new service deployment requirements, the deployment of new services can be achieved based on the strategy shown in FIG. 5. The specific operations are as follows and can be executed by the general scheduling center: S501. Determine the allocation weights of each machine based on the load conditions of each cluster.

[0072] The system will monitor the load conditions of each cluster in real time, including resource utilization rate, task execution status, etc. For example, a cluster may have multiple machine groups running various tasks. The system will count metrics such as the CPU utilization rate and memory occupancy rate of each cluster to determine its load condition.

[0073] Based on the load conditions of each cluster, determine the allocation weight of each cluster. A cluster with a lighter load may be assigned a higher weight, indicating that it can receive more tasks; while a cluster with a heavier load will be assigned a lower weight, indicating that task allocation needs to be reduced to avoid overloading.

[0074] During implementation, for each cluster, determine the allocation weight of the cluster based on at least one of the following parameters of the cluster: the amount of idle processor resources of the cluster, the amount of idle storage resources of the cluster, the amount of idle processor resources of all clusters, and the amount of idle storage resources of all clusters.

[0075] Among them, the allocation weight has a positive correlation with the amount of idle processor resources of the cluster and the amount of idle storage resources of the cluster respectively; The allocation weight has an inverse correlation with the amount of idle processor resources of all clusters and the amount of idle storage resources of all clusters respectively.

[0076] In the embodiments of the present disclosure, the determination of the allocation weight of the cluster can be expressed by formula (3): In formula (3), represents the allocation weight of cluster i; CPU_free represents the amount of idle processor resources of cluster i, is the weight coefficient of the amount of idle processor resources of cluster i; Mem_free represents the amount of idle storage resources of cluster i, is the weight coefficient of the idle storage resources of cluster i; is the sum of the idle processor resources of all clusters and the idle storage resources of all clusters.

[0077] Among them, the higher the weight ratio, when there is a new task to be assigned, the greater the probability that this cluster will be selected to be assigned a new instance, so as to obtain more resources to run the task.

[0078] In the embodiments of the present disclosure, by calculating the ratio of the idle processor resources of a cluster and the idle storage resources of the cluster to the idle processor resources of all clusters and the idle storage resources of all clusters, determining the allocation weight of the cluster can optimize resource matching, so that the allocation weight of the cluster can reflect the available status of multiple hardware resources at the same time, avoid scheduling deviation caused by a single dimension, and improve the resource utilization rate and service stability of the overall system.

[0079] S502. When adding a third target service, based on the allocation weight, screen the clusters that meet the requirements of the hardware characteristics of the third target service as the target clusters.

[0080] When adding a third target service, the system will first match the hardware characteristics of the machine required by the third target service, and then combine the allocation weights of each cluster to finally determine the target cluster that can carry the service. For example, in the scenario where the hardware resources required for adding a third target service are a Linux system + HDD (Hard Disk Drive) hard disk, select the cluster with the highest allocation weight as the target cluster to achieve reasonable allocation and efficient utilization of resources.

[0081] S503. Allocate the third target service to the target cluster and create a corresponding machine group for the third target service.

[0082] Deploy the third target service to the selected target cluster. In the target cluster, create a dedicated machine group for the third target service.

[0083] During implementation, based on the content described above, the machines in the cluster that meet the hardware characteristic requirements of the third target service can also be migrated to the idle resource area. Subsequently, obtain the required machine resources from the idle resource area and combine them to form the machine group corresponding to the third target service.

[0084] In the embodiments of the present disclosure, by determining the allocation weight of each machine based on the load conditions of each cluster, the weight can reflect the current resource idle degree or bearing capacity of the cluster. Screening the clusters that meet the hardware characteristic requirements as the target clusters based on the allocation weight can prevent the new service from being assigned to the clusters with high load, and avoid service performance degradation or failure caused by insufficient resources.

[0085] In summary, the overall scheduling process of the multi-cluster hybrid deployment system for heterogeneous machine types provided by the present disclosure is as follows Figure 6 as shown: During implementation, a general scheduling center can be set up in the multi-cluster hybrid deployment system for heterogeneous machine types. By monitoring the load conditions of each cluster in real time, the load balancing problem between clusters can be managed.

[0086] Monitoring nodes can also be set up in each cluster to receive the hardware feature conditions reported by each machine through its own agent (not shown in the figure). Then, according to the hardware feature requirements of each target service, the machines can be divided into different machine groups. In addition, the monitoring nodes in each cluster can monitor the load balancing between the machine groups in the cluster in real time to manage the load balancing problem between the machine groups in the cluster.

[0087] The monitoring nodes can also be used as a medium for transmitting information within the corresponding cluster to transmit relevant information to the general scheduling center, and the general scheduling center manages the resource allocation within the cluster and the task allocation between clusters.

[0088] It can be understood that in the multi-cluster hybrid deployment system for heterogeneous machine types, the general scheduling center and the monitoring nodes in each cluster can be flexibly deployed on any electronic device within the system.

[0089] Figure 7 It is a structural block diagram of an electronic device according to an embodiment of the present disclosure. As Figure 7 shown, the electronic device includes: a memory 710 and a processor 720. A computer program that can run on the processor 720 is stored in the memory 710. The number of the memory 710 and the processor 720 can be one or more. The memory 710 can store one or more computer programs. When the one or more computer programs are executed by the electronic device, the electronic device executes the method provided by the above method embodiment. The electronic device may further include: a communication interface 730 for communicating with external devices and performing data interaction and transmission.

[0090] If the memory 710, the processor 720, and the communication interface 730 are implemented independently, the memory 710, the processor 720, and the communication interface 730 can be interconnected via a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 only a thick line is shown in Figure 7 , but it does not mean that there is only one bus or one type of bus.

[0091] Optionally, in a specific implementation, if the memory 710, the processor 720, and the communication interface 730 are integrated on a single chip, the memory 710, the processor 720, and the communication interface 730 can communicate with each other via an internal interface.

[0092] It should be understood that the above-mentioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. It is worth noting that the processor can be a processor that supports the Advanced RISC Machines (ARM) architecture.

[0093] Further, optionally, the above-mentioned memory may include a read-only memory and a random access memory, and may also include a non-volatile random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchlink dynamic random access memory (SLDRAM), and direct rambus random access memory (DR RAM).

[0094] In the description of the embodiments of the present disclosure, the descriptions referring to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples", etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present disclosure. Moreover, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, without conflict, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples.

[0095] In the description of the embodiments of the present disclosure, unless otherwise specified, " / " means "or". For example, A / B may mean A or B. The "and / or" herein is merely a description of the association relationship of the associated objects, indicating that there may be three relationships. For example, A and / or B may mean: A exists alone, A and B exist simultaneously, and B exists alone, these three cases.

[0096] In the description of the embodiments of the present disclosure, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of the present disclosure, unless otherwise stated, the meaning of "a plurality of" is two or more.

[0097] The foregoing are only exemplary embodiments of the present disclosure and are not intended to limit the present disclosure. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present disclosure shall be included within the protection scope of the present disclosure.

Claims

1. A multi-cluster hybrid deployment system for heterogeneous machine types, comprising: Multiple clusters built based on heterogeneous machine types; Each cluster includes multiple machine groups; Each machine group corresponds to its own first target service respectively; For each machine group, the machine group is obtained by grouping based on the requirements of the corresponding first target service for hardware characteristics; Within the same cluster, according to the resource requirements of the second target service supported by the cluster, resources are dynamically adjusted among different machine groups within the cluster.

2. The system according to claim 1, wherein The dynamically adjusting resources among different machine groups within the cluster according to the resource requirements of the second target service supported by the cluster includes: Maintaining an idle resource area, which includes idle machines released from the first target machine group; For the second target service, based on the required resource expansion amount of the second target service, dynamic resource adjustment is performed among different machine groups through the idle resource area.

3. The system according to claim 2, wherein, The dynamically adjusting resources among different machine groups through the idle resource area includes: When the second target machine group where the second target service is located needs to be expanded, based on the required resource expansion amount of the second target service, obtain idle machines that match the requirements of the second target service for hardware characteristics from the idle resource area; Divide the idle machines into the second target machine group.

4. The system according to claim 2, wherein The maintaining the idle resource area includes: Based on a preset task eviction policy, screening out target tasks within the cluster; Evicting the target tasks from the target machines running the target tasks in the first target machine group to release the resources of the target machines to obtain the idle machines; Setting the idle machines into the idle resource area.

5. The system according to claim 4, wherein The screening out target tasks within the cluster based on a preset task eviction policy includes: Determining the eviction scores of each candidate task within the cluster; the eviction scores are determined based on at least one of the following parameters and have a positive correlation with each of the following parameters: the processor utilization rate of the candidate task, the storage resource utilization rate of the candidate task, and the execution duration of the candidate task; Based on the eviction scores of each candidate task, screening out the target tasks.

6. The system according to claim 4 or 5, wherein, The second target service is an online task with a resource demand growth exceeding a threshold, and the target task is an offline task.

7. The system according to claim 2, wherein, Determine the required resource expansion amount of the second target service based on the following method: When the second target service is an online task, determine the current idle resource amount and the online metric in the total resources allocated to the offline tasks; the online metric is determined based on the resource quota allocated to the online task, and the online metric is less than the resource quota; Based on the current idle resource amount and the online metric, determine the required resource expansion amount of the second target service.

8. The system according to claim 2, wherein It further includes: When the second target service is an online service and the idle machines are obtained by evicting the offline service, set the borrowing duration of the idle machines by the second target service to the duration threshold; Control the second target service to return a preset proportion of the idle machines borrowed from the offline tasks every specified period.

9. The system according to claim 1, further comprising: Determining the allocation weights of each machine based on the load conditions of each cluster; In the case of adding a third target service, screening, based on the allocation weights, a cluster that meets the requirements of the hardware characteristics adapted to the third target service as the target cluster; Allocating the third target service to the target cluster and creating a corresponding machine group for the third target service.

10. The system according to claim 9, wherein, The determining the allocation weights of each machine based on the load conditions of each cluster includes: For each cluster, determining the allocation weight of the cluster based on at least one of the following parameters of the cluster: the amount of idle processor resources of the cluster, the amount of idle storage resources of the cluster, the amount of idle processor resources of all clusters, and the amount of idle storage resources of all clusters; Wherein, the allocation weights are respectively positively correlated with the amount of idle processor resources of the cluster and the amount of idle storage resources of the cluster; The allocation weights are respectively inversely correlated with the amount of idle processor resources of all clusters and the amount of idle storage resources of all clusters.

11. The system according to claim 1, further comprising: When it is determined that the difference between the load of the first cluster and the load of the second cluster meets the cross-cluster adjustment task condition, determining the amount of tasks to be migrated in the first cluster; the first cluster and the second cluster support the same task type; Screening out the tasks to be migrated with the amount of tasks to be migrated from the first cluster; Migrating the tasks to be migrated to the machine group in the second cluster that supports the tasks to be migrated for execution.

12. The system according to claim 11, wherein, The determining the amount of tasks to be migrated in the first cluster includes: Determining a first candidate migration amount based on the load of the first cluster; and determining a second candidate migration amount based on the load of the second cluster; Screening out the amount of tasks to be migrated from the first candidate migration amount and the second candidate migration amount.

13. The system according to claim 11, wherein, The tasks to be migrated screened out are the tasks in the first cluster without the core task mark.

Images