A hierarchical topology domain weight-aware task scheduling method and system

Abstract

The application discloses a kind of hierarchical topology domain weight-aware task scheduling method and system, the method includes: based on the network bandwidth difference between node performance and inter-node modeling, obtain the hierarchical cluster node performance topology domain model with weight, can reflect the network bandwidth difference between node performance and inter-node.Resource scheduling process, task specifies topology domain level, scheduler traverses all nodes of each topology domain under this level and carries out two stages of preselection and optimization, finally selects a best node, and the node is distributed to the node, and the scheduling result is recorded;If multiple topology domains meet the requirements, the node resources preferred by the Pod distributed in each topology domain are added, and the binding request is sent according to the highest score of the topology domain scheduling result, and the specific binding action is responsible by kubelet.The application considers the network bandwidth difference between node performance and inter-node, can schedule workload to the best performance domain, and improve the efficiency of large model training.

Description

Technical Field

[0001] This invention belongs to the field of cluster task scheduling technology, and relates to a hierarchical topology domain weight-aware task scheduling method and system. Background Technology

[0002] Currently, in large-scale AI model training scenarios, even nodes of the same specifications can exhibit performance differences or inter-node network transmission performance variations due to factors such as network topology and hardware drivers. This can slow down the overall training task due to poorly performing nodes, significantly impacting training efficiency. For example, distributed model training uses parallel methods such as model parallelism to split the entire model across multiple nodes. During training, a large amount of data is exchanged between nodes. The fewer switches between two nodes, the lower the communication latency and the higher the throughput. However, when assigned nodes cross switches, the inter-node network transmission performance is lower than when nodes are on the same switch, significantly affecting training efficiency. Therefore, users aim to schedule workloads to the optimal performance domain, minimizing cross-switch communication to accelerate data exchange and improve training efficiency.

[0003] Kubernetes, as the most popular container orchestration platform, provides various scheduling strategies, such as resource request-based scheduling, label-based scheduling, and affinity / anti-affinity-based scheduling. However, training large models requires a large number of nodes to collaborate and communicate, posing new scheduling requirements to existing systems. Current technologies use static scheduling methods, which can schedule Pods to specific node groups using label selectors, but cannot dynamically adjust scheduling strategies based on node performance or network bandwidth differences between nodes. The Pod is the most basic and smallest deployable and manageable computing unit in Kubernetes. Summary of the Invention

[0004] To address the problems existing in the implementation of the technology, this invention proposes a hierarchical topology domain weight-aware task scheduling method and system. Considering the performance of nodes and the differences in network bandwidth between nodes, the workload can be scheduled to the optimal performance domain, thereby improving the training efficiency of large models.

[0005] To achieve the above technical objectives, the present invention adopts the following technical solution: a hierarchical topology domain weight-aware task scheduling method, comprising:

[0006] Modeling node performance and network bandwidth differences between nodes yields a weighted hierarchical cluster node performance topology model.

[0007] Submit the task to the Kubernetes cluster and specify the task's topology hierarchy;

[0008] For all Pods created by the task in the Kubernetes cluster, traverse the topology domains at the specified topology domain level for each task, and pre-select and optimize all nodes in each topology domain.

[0009] In the resource pre-selection phase, identify node resources that meet resource requirements and affinity / anti-affinity requirements, and use them as pre-selected nodes;

[0010] During the resource optimization phase, the optimization score is calculated based on the node weight and hierarchical topology of the pre-selected nodes. The best node is selected, the Pod is assigned to the node, and the scheduling result is recorded.

[0011] The task is successfully scheduled in a topology domain when all Pods of the task can find an assignable node within that domain.

[0012] If multiple topologies meet the task scheduling requirements, the resource optimization scores of the allocated Pod nodes in each topology that meets the requirements are added together. Based on the scheduling result of the topology with the highest score, a binding request is sent to the corresponding node in that topology, and the kubelet component on the node is responsible for the specific binding action.

[0013] Furthermore, the modeling of node performance and network bandwidth differences between nodes includes: acquiring node network topology information and hardware performance labels; constructing an initial topology domain based on the network topology location and according to the switch hierarchy; performing performance analysis on each node in each underlying topology domain within the initial topology domain; constructing a topology domain based on the performance labels; and scoring nodes within the topology domain according to their performance labels and converting the scores into weights.

[0014] Furthermore, in the weighted hierarchical cluster node performance topology domain model, the hierarchical structure represents the network topology of the nodes, and the weight value of the topology domain serves as a parameter for quantitatively evaluating the performance of nodes within the topology domain. The magnitude of the weight value is positively correlated with the performance of the nodes.

[0015] Furthermore, among all the nodes to which all Pods of the task are assigned, the topology hierarchy of the lowest common ancestor between any two nodes does not exceed the topology hierarchy specified by the task.

[0016] Furthermore, the pre-selection adopts Kubernetes' default filtering algorithms, including resource request-based scheduling, label-based scheduling, and affinity / anti-affinity-based scheduling; specifically:

[0017] A. Filter out node resources whose ports required by the Pod are already in use;

[0018] B. Filter out node resources that do not meet the requirements of the Pod. The resources required by the Pod include CPU, Memory, and GPU.

[0019] C. Select node resources that meet the Pod affinity / anti-affinity requirements;

[0020] D. Filter out node resources that meet the NodeSelector attribute and HostName of the Pod.

[0021] Furthermore, the preferred method scores the pre-selected nodes based on their node weights and hierarchical topology domains. The final node score is the sum of the scores of all topology domains from the lowest topology domain to all its parent topology domains up to the highest level. When node weights are different and the final node scores are different, the node with the highest score is selected based on the scoring results, i.e., the node resource with the best node performance is selected first. When node weights are the same and the final node scores are the same, scheduling is performed according to the topology domain compact packaging strategy. When the first Pod is scheduled, a node is randomly selected. When the second Pod is scheduled, the node with the lowest nearest common ancestor level formed by the node where the already scheduled Pod is located is selected first.

[0022] To achieve the above objectives, the present invention also provides a hierarchical topology domain weight-aware task scheduling system, comprising:

[0023] The topology domain construction module is used to model node performance and network bandwidth differences between nodes, resulting in a weighted hierarchical cluster node performance topology domain model.

[0024] The pre-selection module is used to pre-select nodes in all topological domains at the specified topological domain level of the task, and find node resources that meet the resource requirements and affinity / anti-affinity requirements as pre-selected nodes;

[0025] The node selection module is used to select the best node based on the node weight and hierarchical topology of the pre-selected nodes, assign the Pod to the node, and record the scheduling results.

[0026] The topology domain optimization module, when multiple topology domains meet the task scheduling requirements, is used to sum up the node resource optimization scores of the allocated Pods in each topology domain that meets the requirements. Based on the scheduling result of the topology domain with the highest score, a binding request is sent to the corresponding node in that topology domain, and the kubelet component on the node is responsible for the specific binding action.

[0027] To achieve the above objectives, the present invention also provides a hierarchical topology domain weight-aware task scheduling apparatus, including one or more processors, for implementing the above-described hierarchical topology domain weight-aware task scheduling method.

[0028] To achieve the above objectives, the present invention also provides an electronic device, including a memory and a processor, wherein the memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the above-described hierarchical topology domain weight-aware task scheduling method.

[0029] To achieve the above objectives, the present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the above-described hierarchical topology domain weight-aware task scheduling method.

[0030] Compared with existing technologies, this invention has the following advantages: This invention models node performance based on the differences in network bandwidth between nodes, resulting in a weighted hierarchical cluster node performance topology model that reflects node performance and network bandwidth differences between nodes. During resource scheduling, the task specifies a topology hierarchy. The scheduler traverses all nodes in each topology hierarchy under that hierarchy, performing two phases: pre-selection and optimization. In the resource pre-selection phase, node resources that meet resource requirements, affinity / anti-affinity, etc., are identified. In the optimization phase, the pre-selected node resources are scored based on node weights and the hierarchical topology, ultimately selecting the best node and allocating the Pod to it, recording the scheduling result. If multiple topologies meet the requirements, the optimization scores of the node resources allocated to the Pod within each topology are added together. A binding request is sent based on the scheduling result of the topology with the highest score, and the kubelet is responsible for the specific binding action. This invention takes into account the differences in node performance and network bandwidth between nodes, and can schedule the workload to the optimal performance domain, ensuring balanced computing power of all working nodes, improving the effective throughput of training, while reducing the number and layers of switches that data packets need to pass through, significantly reducing the communication latency between nodes, optimizing cross-node communication performance, and improving the training efficiency of large models. Attached Figure Description

[0031] 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 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:

[0032] Figure 1 This is a flowchart of the task scheduling method based on hierarchical topology domain weight awareness according to the present invention;

[0033] Figure 2 This is a schematic diagram of a weighted hierarchical topology in this invention;

[0034] Figure 3 This is a schematic diagram of the working principle of the task scheduling system based on hierarchical topology domain weight awareness of the present invention;

[0035] Figure 4 This is a schematic diagram of the structure of the device of the present invention;

[0036] Figure 5 This is a schematic diagram of an electronic device according to the present invention. Detailed Implementation

[0037] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0038] The technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the description is only a part of this application, and not all of it. Based on the specific embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0039] like Figure 1 This is a flowchart of the task scheduling method based on hierarchical topology domain weight awareness according to the present invention. The method specifically includes the following steps:

[0040] Step 1: Model the performance of nodes and the differences in network bandwidth between nodes. A topology domain consists of a group of nodes with closely spaced network locations and consistent computing performance; for example, nodes interconnected through the same top-level switch and with consistent GPU models, memory capacities, and other computing performance characteristics. Node information is obtained by probing the nodes, such as through information provided by the data center or link-layer discovery protocols, to acquire information about the switches the nodes are connected to. Hardware information, such as node model and memory size, is read and converted into node tags. After obtaining all the necessary information, the topology domain is constructed. First, topology domains are constructed according to network topology location, and then according to the hierarchical structure of the switches. All nodes connected to the same switch constitute one topology domain. Then, within each lower-level topology domain in the initial topology domain, topology domains are constructed based on performance tags. Nodes with consistent computing performance are grouped into one topology domain, and scores are assigned based on different models and memory sizes. Higher computing performance and larger memory result in the highest scores, which are then converted into specific weights for the topology domains. This yields a weighted hierarchical cluster node performance topology domain model that reflects node performance and the differences in network bandwidth between nodes.

[0041] Figure 2This embodiment presents a weighted hierarchical cluster node performance topology model. The network topology is represented by hierarchical topology domain partitions. A network topology domain typically maps to a switch or a top-of-rack (Tor) switch. Multiple network topology domains are connected hierarchically to form a tree structure. The higher the level of the lowest common ancestor (LCA) of two node resources, the worse the communication performance between the two nodes. Figure 2 As can be seen, the leaf node topology domain 1 of level 1 contains 10 nodes, all under the same switch, and they do not need to communicate with each other across switches. Similarly, the 10 nodes in topologies 2, 3, and 4 do not need to communicate with each other across switches. The lowest common ancestor of any node in topology 1 and any node in topology 2 is topology 5 of level 2, requiring communication across switches. This communication performance is worse than communication between nodes in topologies 1 or 2. Topology domains use weight values ​​to represent the performance differences between nodes within the topology domain; a higher weight value indicates better resource performance for all nodes in the topology domain. Figure 2 As can be seen, topology 1 has a weight of 10, topology 2 has a weight of 1, and the performance of nodes within topology 1 is higher than that of topology 2; topology 5 has a weight of 1, topology 6 has a weight of 10, and the performance of nodes within topology 6 is higher than that of topology 5. At the same time, topology 6 is at a higher level than topology 1, and the performance of nodes within topology 6 will be higher than that of nodes within topology 5. Therefore, task scheduling should prioritize scheduling to nodes within topology 6. Figure 2 The weighted hierarchical cluster node performance topology shown can represent the node performance and the differences in network bandwidth between nodes. The hierarchical structure represents the network topology of the nodes, and the weight of the topology domain represents the quality of the node performance and the network bandwidth between nodes.

[0042] Step 2: Submit the task to the Kubernetes cluster and specify the topology level of the task.

[0043] This example sets the topology hierarchy of the submitted task to 2 and requires 8 Pods. It means that all 8 Pods of the task are scheduled to any one of the topology domains from topology 1 to topology 6, but not to topology 7. In other words, the maximum hierarchy of the lowest common ancestor topology domain of all nodes assigned to the task is 2.

[0044] Step 3: For all Pods created by the task in the Kubernetes cluster, first traverse the topology domains at the allowed topology domain level, and then perform two stages of pre-selection and optimization for all nodes in each topology domain to find suitable nodes to run the task.

[0045] In this example, the scheduler will first select 20 nodes in topology 5 to perform a task scheduling and record the scheduling result, and then select 20 nodes in topology 6 to perform a task scheduling and record the scheduling result.

[0046] Step 4: In the resource pre-selection stage, identify node resources that meet the requirements of resource needs, affinity / anti-affinity, etc., and use them as pre-selected nodes;

[0047] Kubernetes' traditional scheduling strategies include resource request-based scheduling, label-based scheduling, and affinity / anti-affinity-based scheduling. The scheduler filters out node resources where the ports required by a Pod are already occupied, and node resources that do not meet the Pod's resource requirements, including CPU, memory, and GPU. The scheduler then selects node resources that meet the Pod's affinity / anti-affinity requirements, as well as those matching the Pod's NodeSelector attribute and HostName. This example assumes all nodes meet these requirements and will not be filtered out; all nodes enter the selection phase.

[0048] Step 5: In the resource selection phase, the node weight and hierarchical topology domain are considered to score the pre-selected nodes, and finally the best node is selected. The Pod is assigned to the node and the scheduling result is recorded.

[0049] Scoring is based on the node weights and hierarchical topology of the pre-selected nodes. The scoring formula is as follows:

[0050]

[0051] Where h represents the level, The decay exponent is calculated based on the distance h from the highest level at that level. The distance decays exponentially. The weight of each node, For each layer, the amplification factor function, The score for each topology is calculated using the formula: the sum of the scores of all topologies from the lowest topology to all its parent topologies up to the highest level for each preselected node.

[0052] To amplify or mitigate the decay caused by level changes and adjust the score changes resulting from the decay caused by level changes, this invention selects an exponential function, and the final scoring formula is as follows:

[0053]

[0054] It can be decided by the user according to different scenarios. The ability to enhance the weights of higher-level topological domains. The larger the value, the higher the weight of the node will be amplified in the final score, ensuring the priority of the higher-level topology in the hierarchical structure of the scoring mechanism, and making the scoring results more consistent with the semantic hierarchy expressed by the tree structure. The decay rate of the weights in the lower-level topological domains. The larger the value of , the smaller the difference in influence between the weights of different levels of topological domains, and the stronger the influence of the weights of lower-level topological domains on the scoring results.

[0055] The two-parameter scoring formula can be adapted to the topology domain scheduling needs of different application scenarios. When the weights of all topology domains are between 1 and 10, the example is as follows:

[0056] Scenario 1: High-level dominant scenario, suitable for application scenarios that require strict representation of the semantic hierarchy of a tree structure.

[0057] In this scenario, This configuration can effectively suppress the influence of the weight of the lower-level topology on the scoring results, so that the scoring results are mainly determined by the weight of the higher-level nodes, while retaining the limited distinguishing ability of the lower-level topology.

[0058] Scenario 2: High-level priority is given and the lower-level weights are allowed to have a significant advantage in dominating the score.

[0059] In this scenario, This configuration, while ensuring that the weights of higher-level topology domains are prioritized overall, allows the weights of lower-level topology domains to correct the scoring results through path accumulation.

[0060] Scenario 3: Weak hierarchical constraint scenario.

[0061] In this scenario, Under this configuration, the influence of the topology weights at each level on the scoring is relatively balanced, and the scoring results mainly reflect the numerical accumulation of node weights.

[0062] This invention example adopts a high-level dominant scenario and sets... That is, the lower the level, the greater the weight decay, but changes in level do not affect the amplification factor. The scoring formula after variable substitution is:

[0063]

[0064] For the nodes within the first topological domain, topology 5, the scoring formula can be used to obtain:

[0065] All nodes in Topology 1 (Topo-1) are scored as 1.2, calculated as follows:

[0066]

[0067] All nodes in Topology 2 (Topo-2) are scored 1.11, calculated as follows:

[0068]

[0069] When node weights differ, resulting in different final node scores, the node with the highest score is selected based on the scoring results; that is, the node with the best performance is prioritized. For the 8 Pods that need to schedule tasks, all 8 Pods will be prioritized for scheduling within Topology 1, and the entire task will be scheduled within Topology 1 to meet the topology domain level requirements specified by the task.

[0070] For the nodes within the second topological domain, topology 6, the scoring formula can be used to obtain:

[0071] All nodes in Topology 3 (Topo-3) have a score of 2.01, calculated as follows:

[0072]

[0073] All nodes in Topology 4 (Topo-4) have a score of 2.01, calculated as follows:

[0074]

[0075] When nodes have consistent weights and ultimately the same score, scheduling is performed according to the topology binpacking strategy. The first Pod is scheduled randomly, while the second Pod prioritizes the node with the lowest lowest common ancestor (LCA) level formed by the nodes containing the already scheduled Pods. For the 8 Pods scheduling a task, if the first Pod chooses topology 3, all 8 Pods will be prioritized for scheduling within topology 3, and the entire task will be scheduled within topology 3. If the first Pod chooses topology 4, all 8 Pods will be prioritized for scheduling within topology 4, and the entire task will be scheduled within topology 4. Both cases satisfy the topology level requirements specified by the task.

[0076] Step 6: When all Pods of a task find a node that can be assigned within a topology domain, the task is successfully scheduled within that topology domain.

[0077] Following the scheduling process in step 6, tasks can be successfully scheduled for both topology domains, topology 5 and topology 6.

[0078] Step 7: If multiple topologies meet the task scheduling requirements, the resource optimization scores of the allocated Pod nodes in each topology that meets the requirements are added together. Based on the scheduling result of the topology with the highest score, a binding request is sent to the corresponding node in that topology. The kubelet component on the node is responsible for the specific binding action.

[0079] The total score of all nodes in the scheduling result within topology 5 is 9.6, calculated as follows:

[0080]

[0081] The total score of all nodes in the scheduling results within topology 6 is 16.08, calculated as follows:

[0082]

[0083] Based on the scheduling result of the highest-scoring topology domain, topology 6, a binding request is sent, and the task is scheduled into topology 6, while the workload is scheduled into the best performance domain.

[0084] This invention models node performance based on differences in network bandwidth between nodes, resulting in a weighted hierarchical cluster node performance topology model that reflects these differences. During resource scheduling, a task specifies a topology hierarchy. The scheduler traverses all nodes in each topology at that hierarchy, performing two phases: pre-selection and optimization. In the pre-selection phase, node resources meeting requirements such as resource needs, affinity / anti-affinity, etc., are identified. In the optimization phase, the pre-selected node resources are scored based on node weights and the hierarchical topology, ultimately selecting the optimal node. The Pod is then assigned to this node, and the scheduling result is recorded. If multiple topologies meet the requirements, the optimization scores of the node resources assigned to the Pod within each topology are summed. A binding request is sent based on the scheduling result of the topology with the highest score, with the kubelet handling the actual binding action. This invention considers node performance and differences in network bandwidth between nodes, allowing workloads to be scheduled to the optimal performance domain, improving the training efficiency of large models.

[0085] This application also provides a hierarchical topology domain weight-aware task scheduling system. Figure 3 This is a schematic diagram of the working principle. The entire system includes control nodes and working nodes.

[0086] The control node is an independent server in the cluster, responsible for cluster management and scheduling. The API-Server, ETCD, controller and scheduler are deployed on the control node.

[0087] API-Server is the entry point for the entire system requests. It provides operation interfaces for all resources within the cluster, including adding, deleting, modifying, and querying resources, and stores resource object information in ETCD.

[0088] ETCD is a distributed storage database used to store information about all resource objects within a cluster;

[0089] The controller is responsible for maintaining the state of resources within the cluster, monitoring resource changes, and taking corresponding actions based on those changes to ensure that the current state of resources matches the expected state. The controller includes the following modules:

[0090] The topology domain construction module is used to model node performance and network bandwidth differences between nodes, resulting in a weighted hierarchical cluster node performance topology domain model.

[0091] Other resource controllers are controllers for other resource objects in a Kubernetes cluster, including resource objects such as Nodes and Jobs.

[0092] The scheduler is responsible for finding a suitable node to run the Pod according to the scheduling policy. The scheduler includes the following modules:

[0093] The pre-selection module is used to pre-select nodes in all topological domains at the specified topological domain level of the task, and find node resources that meet the resource requirements and affinity / anti-affinity requirements as pre-selected nodes;

[0094] The node selection module is used to select the best node based on the node weight and hierarchical topology of the pre-selected nodes, assign the Pod to the node, and record the scheduling results.

[0095] The topology domain optimization module, when multiple topology domains meet the task scheduling requirements, is used to sum up the node resource optimization scores of the allocated Pods in each topology domain that meets the requirements. Based on the scheduling result of the topology domain with the highest score, a binding request is sent to the corresponding node in that topology domain, and the kubelet component on the node is responsible for the specific binding action.

[0096] It should be noted that, in a Kubernetes cluster, all nodes except the control node are worker nodes. Each node deploys a kubelet service to manage the Pod lifecycle, responsible for Pod creation, state maintenance, and deletion. Corresponding to the aforementioned embodiment of the hierarchical topology domain weight-aware task scheduling method, this invention also provides an embodiment of a hierarchical topology domain weight-aware task scheduling device.

[0097] See Figure 4 The hierarchical topology domain weight-aware task scheduling device provided in this embodiment of the invention includes one or more processors for implementing the hierarchical topology domain weight-aware task scheduling method in the above embodiment.

[0098] The embodiments of the hierarchical topology domain weight-aware task scheduling device of the present invention can be applied to any device with data processing capabilities, such as a computer. The device embodiments can be implemented in software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor of any data processing device loading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 4 The diagram shown is a hardware structure diagram of any data processing-capable device where the hierarchical topology domain weight-aware task scheduling device of the present invention is located, except... Figure 4 In addition to the processor, memory, network interface, and non-volatile memory shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

[0099] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0100] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the present invention according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0101] Corresponding to the aforementioned embodiments of the hierarchical topology domain weight-aware task scheduling method, this application also provides an electronic device, including: one or more processors; a memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the hierarchical topology domain weight-aware task scheduling method as described above. Figure 5 The diagram shown illustrates a hardware structure of any data processing-capable device for implementing the hierarchical topology domain weight-aware task scheduling method provided in this application embodiment, except... Figure 5 In addition to the processor, memory, DMA controller, disk, and non-volatile memory shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

[0102] Corresponding to the aforementioned embodiments of the hierarchical topology domain weight-aware task scheduling method, this embodiment of the invention also provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the hierarchical topology domain weight-aware task scheduling method described in the above embodiments.

[0103] The computer-readable storage medium can be an internal storage unit of any data processing device described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be any data processing device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units of any data processing device and external storage devices. The computer-readable storage medium is used to store the computer program and other programs and data required by the data processing device, and can also be used to temporarily store data that has been output or will be output.

[0104] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0105] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A hierarchical topology domain weight-aware task scheduling method, characterized in that, include: A weighted hierarchical cluster node performance topology model is obtained by modeling node performance and network bandwidth differences between nodes. This includes: acquiring node network topology information and hardware performance labels; constructing an initial topology domain based on network topology location and switch hierarchy; performing performance analysis on each node in each underlying topology domain within the initial topology domain; constructing a new topology domain based on performance labels; and scoring nodes within the topology domain according to their performance labels and converting the scores into weights. In the weighted hierarchical cluster node performance topology model, the hierarchical structure represents the network topology of the nodes, and the weight values ​​of the topology domains serve as parameters for quantitatively evaluating node performance within the topology domains. The magnitude of the weight values ​​is positively correlated with the quality of node performance. Submit the task to the Kubernetes cluster and specify the task's topology level; For all Pods created by the task in the Kubernetes cluster, traverse the topology domains at the specified topology domain level for each task, and pre-select and optimize all nodes in each topology domain. In the resource pre-selection phase, identify node resources that meet resource requirements and affinity / anti-affinity requirements, and use them as pre-selected nodes; During the resource optimization phase, the optimization score is calculated based on the node weight and hierarchical topology of the pre-selected nodes. The best node is selected, the Pod is assigned to the node, and the scheduling result is recorded. The task is successfully scheduled in a topology domain when all Pods of the task can find an assignable node within that domain. If multiple topologies meet the task scheduling requirements, the resource optimization scores of the allocated Pod nodes in each topology that meets the requirements are added together. Based on the scheduling result of the topology with the highest score, a binding request is sent to the corresponding node in that topology, and the kubelet component on the node is responsible for the specific binding action.

2. The hierarchical topology domain weight-aware task scheduling method according to claim 1, characterized in that, All Pods of a task are assigned to all nodes, and the topology level of the lowest common ancestor between any two nodes does not exceed the topology level specified by the task.

3. The hierarchical topology domain weight-aware task scheduling method according to claim 1, characterized in that, The pre-selection process uses Kubernetes' default filtering algorithms, including resource request-based scheduling, label-based scheduling, and affinity / anti-affinity-based scheduling; specifically: A. Filter out node resources whose ports required by the Pod are already in use; B. Filter out node resources that do not meet the requirements of the Pod. The resources required by the Pod include CPU, Memory, and GPU. C. Select node resources that meet the Pod affinity / anti-affinity requirements; D. Filter out node resources that meet the NodeSelector attribute and HostName of the Pod.

4. The hierarchical topology domain weight-aware task scheduling method according to claim 1, characterized in that, The preferred method scores the pre-selected nodes based on their node weights and hierarchical topology domains. The final node score is the sum of the scores of all topology domains from the lowest topology domain to all its parent topology domains up to the highest level. When node weights are different and the final node scores are different, the node with the highest score is selected based on the scoring results, i.e., the node with the best performance is selected first. When node weights are the same and the final node scores are the same, scheduling is performed according to the topology domain compact packaging strategy. When the first Pod is scheduled, a node is randomly selected. When the second Pod is scheduled, the node with the lowest nearest common ancestor level formed by the node where the already scheduled Pod is located is selected first.

5. A hierarchical topology domain weight-aware task scheduling system that implements the method as described in claim 1, characterized in that, include: The topology domain construction module is used to model node performance and network bandwidth differences between nodes, resulting in a weighted hierarchical cluster node performance topology domain model. The pre-selection module is used to pre-select nodes in all topological domains at the specified topological domain level of the task, and find node resources that meet the resource requirements and affinity / anti-affinity requirements as pre-selected nodes; The node selection module is used to select the best node based on the node weight and hierarchical topology of the pre-selected nodes, assign the Pod to the node, and record the scheduling results. The topology domain optimization module, when multiple topology domains meet the task scheduling requirements, is used to sum up the node resource optimization scores of the allocated Pods in each topology domain that meets the requirements. Based on the scheduling result of the topology domain with the highest score, a binding request is sent to the corresponding node in that topology domain, and the kubelet component on the node is responsible for the specific binding action.

6. A hierarchical topology domain weight-aware task scheduling device, characterized in that, It includes one or more processors for implementing the hierarchical topology domain weight-aware task scheduling method according to any one of claims 1-4.

7. An electronic device comprising a memory and a processor, characterized in that, The memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the hierarchical topology domain weight-aware task scheduling method according to any one of claims 1-4.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the hierarchical topology domain weight-aware task scheduling method as described in any one of claims 1-4.

Images