WO2020108337A1

WO2020108337A1 - Cpu resource scheduling method and electronic equipment

Info

Publication number: WO2020108337A1
Application number: PCT/CN2019/119125
Authority: WO
Inventors: 姚军利
Original assignee: 中兴通讯股份有限公司
Priority date: 2018-11-29
Filing date: 2019-11-18
Publication date: 2020-06-04
Also published as: CN111240824A; CN111240824B

Abstract

The embodiment of the present disclosure relates to the technical field of networks. The embodiment of the present disclosure provides a CPU resource scheduling method. The method comprises: configuring all CPU cores on various nodes to be shared CPU cores; selecting nodes satisfying the required quantity of CPU cores for an application as deployment nodes and deploying the application onto the deployment nodes; when an application start event is processed, converting a part of the shared CPU cores with an amount equal to the required quantity of exclusive CPU cores for the application into exclusive CPU cores for use by the application; and when an application exit event is processed, converting the exclusive CPU cores allocated to the application into shared CPU cores.

Description

CPU resource scheduling method and electronic equipment

This disclosure claims the priority of the Chinese patent application CN201811442355.0 entitled "A CPU Resource Scheduling Method and Electronic Equipment" filed on November 29, 2018, the entire contents of which are incorporated herein by reference.

Technical field

Embodiments of the present disclosure relate to the field of network technology, and in particular, to a CPU resource scheduling method and electronic equipment.

Background technique

In the era of big data, social networks, online shopping, and the Internet of Things will generate a large number of real-time data streams. How to quickly analyze these real-time data has become a big challenge for big data processing technology. A distributed streaming data processing system is a system that converts real-time streaming data processing into multiple small jobs and executes them in parallel on multiple processing machines. The distributed stream data processing system based on small batch operations divides the real-time stream data into a series of small batch data at time intervals, and then processes these small batch data. In this way, this type of system can provide low Delayed, high-throughput real-time data processing services. With the development and popularization of cloud computing technology, it has become a trend to deploy such complex applications into cloud environment clusters.

In some cases, there are at least the following problems: In a cloud environment cluster, each node often needs to configure exclusive CPU cores and shared CPU cores in advance, and the configuration is more complicated; and the shared CPU cores and exclusive CPU cores need to be scheduled as two resources. The scheduling dimension is high; and because the threshold for exclusive use of CPU cores is high, one type of resources is often insufficient, and another type of resources is idle and wasted, resulting in inefficient utilization of CPU resources; at the same time, exclusive CPU cores are After the node operating system is started, it is determined. If the allocation ratio of shared CPU cores and exclusive CPU cores on the node is modified in order to improve the utilization efficiency of CPU resources, the node operating system must be restarted to take effect. In the cloud environment cluster, the restart of the node operating system means the migration or interruption of the services carried on the node, which cannot be executed at high frequency, which greatly affects the service effect of the node.

Summary of the invention

The purpose of the embodiments of the present disclosure is to provide a CPU resource scheduling method and an electronic device, so that the complexity of configuring nodes is reduced without affecting the service effect of nodes, and the scheduling dimension of CPU resources and the exclusive use of CPU resources are also reduced. The use threshold also realizes flexible scheduling of shared CPU and exclusive CPU resources, and improves the CPU resource utilization efficiency of nodes.

To solve the above technical problems, the embodiments of the present disclosure provide a CPU resource scheduling method, including: configuring all CPU cores on each node as shared CPU cores, and taking the number of shared CPU cores of each node as the node’s The number of available CPU cores; the number of CPU cores required to receive and parse the application. The number of CPU cores required includes the number of exclusive CPU cores and the number of shared CPU cores. Deploy the task of the application to the deployment node; monitor the application startup event and exit event of the deployment node, and when the application startup event of the deployment node is monitored, select a share equal to the number of exclusive CPU requirements from the shared CPU core of the deployment node CPU cores are converted into exclusive CPU cores, and the converted exclusive CPU cores are allocated to the application; when monitoring the application exit event of the deployment node, the exclusive CPU cores allocated to the application are converted into shared CPU cores.

An embodiment of the present disclosure also provides an electronic device including at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are at least one The processor executes to implement the above CPU resource scheduling method.

BRIEF DESCRIPTION

One or more embodiments are exemplarily illustrated by the pictures in the corresponding drawings. These exemplary descriptions do not constitute a limitation on the embodiments, and elements with the same reference numerals in the drawings represent similar elements. Unless otherwise stated, the figures in the drawings do not constitute a scale limitation.

1 is a schematic flowchart of a CPU resource scheduling method according to the first embodiment of the present disclosure;

2 is a schematic flowchart of a CPU resource scheduling method according to a second embodiment of the present disclosure;

3 is a schematic flowchart of a CPU resource scheduling method according to a third embodiment of the present disclosure;

4 is a schematic flow chart of dynamic conversion of shared CPU cores and exclusive CPU cores according to the third embodiment of the present disclosure;

5 is a schematic structural diagram of an electronic device according to a fourth embodiment of the present disclosure.

detailed description

To make the objectives, technical solutions, and advantages of the embodiments of the present disclosure clearer, the embodiments of the present disclosure will be described in detail below in conjunction with the accompanying drawings. However, those of ordinary skill in the art can understand that in various embodiments of the present disclosure, in order to make the reader better understand the present disclosure, many technical details are proposed. However, even without these technical details and various changes and modifications based on the following embodiments, the technical solutions claimed in the present disclosure can be realized.

The first embodiment of the present disclosure relates to a CPU resource scheduling method. The specific flow diagram is shown in FIG. 1 and specifically includes:

Step 101: All CPU cores on each node are configured as shared CPU cores, and the number of shared CPU cores of each node is used as the number of available CPU cores of the node.

In one embodiment, the existing cluster usually needs to plan exclusive CPU cores in advance, and in the embodiment of the present disclosure, all CPU cores on each node in the cluster are configured as shared CPU cores. When a node starts, all CPU cores on each node are shared CPU cores, and there is only one type of CPU resource in the cluster scheduler, that is, shared CPU resources. In the initial state, the number of available CPU cores of all nodes is equal to the number of shared CPU cores reported by the node, that is: the number of initially available CPU cores of the node = the number of shared CPU cores reported by the node. Therefore, in the initial state, the number of shared CPU cores of each node is the number of available CPU cores of the node. After the node is started, each node reports its own number of shared CPU cores to the cluster resource scheduler. In this embodiment, it is not necessary to plan exclusive CPU cores in advance, which reduces the complexity of nodes and lowers the threshold for exclusive CPU resources.

Step 102: Receive and analyze the number of CPU core requirements of the application.

In one embodiment, when there is an application task to be executed, the number of CPU core requirements of the application is received and analyzed, and the total number of CPU cores of the application = the number of exclusive CPU cores + the number of shared CPU cores. The cluster scheduler needs to analyze the application's CPU core requirements, determine the application's exclusive CPU core requirements and shared CPU core requirements, so as to subsequently deploy nodes for the application based on the application's exclusive CPU core requirements and shared CPU core requirements.

Step 103: Select a node whose available CPU core number is greater than or equal to the required number of CPU cores as a deployment node, and deploy the task of executing the application to the deployment node.

In one embodiment, each node in the cluster reports the number of its own shared CPU cores to the cluster resource scheduler, and the cluster resource scheduler learns the number of available CPU cores of each node in the cluster, and thus receives the CPU core demand of the application According to the number of CPU core requirements of an application, a node that meets the application requirements can be selected as a deployment node. The task of executing the application is deployed to a deployment node, and the deployment node executes the task of the application.

Step 104: Monitor the application startup event and exit event of the deployment node. If the startup event of the application is monitored, step 105 is entered; if the exit event is monitored, step 106 is entered.

Step 105: Select shared CPU cores equal to the number of exclusive CPU requirements from the shared CPU cores of the deployment node and convert them into exclusive CPU cores, and allocate the converted exclusive CPU cores to the application for use.

Step 106: When the application exit event of the deployment node is monitored, the exclusive CPU core allocated to the application is converted into a shared CPU core.

With respect to the above steps 104 to 106 in one embodiment, the cluster resource scheduler monitors the startup event and exit event of the application of the deployment node, and if the startup event of the application of the deployment node is monitored, it is selected from the shared CPU cores of the deployment node Shared CPU cores equal to the number of exclusive CPU cores required by the application are converted into exclusive CPU cores, and the converted exclusive CPU cores are allocated to the application for use. When the application exit event of the deployed node is monitored, the node's exclusive CPU core no longer needs to execute the application's task. At this time, the exclusive CPU core allocated to the application is converted into a shared CPU core. Dynamically convert the corresponding number of shared CPU cores to exclusive CPU cores, so that at the level of scheduling, there is no need to pay attention to whether the container needs shared CPU cores or exclusive CPU cores, and merge and schedule as ordinary CPU cores to avoid some situations. In the case of scheduling shared CPU cores and exclusive CPU cores as two types of resources, one type of resources is insufficient, and the other type of resources is idle and wasted, which greatly improves the utilization efficiency of CPU resources and the flexibility of scheduling. At the same time, in some cases, after the exclusive CPU cores are pre-configured, it is necessary to restart the node operating system to modify the distribution relationship between the shared CPU cores and the exclusive CPU cores on the node, avoiding the modification of the shared CPU cores on the node and the The exclusive distribution of the relationship between CPU cores leads to the migration or interruption of the services carried on the node, which improves the service effect of the node.

In one embodiment, after the task of executing the application is deployed to the deployment node, the method further includes: updating the number of available CPU cores of the deployment node. So that the cluster resource scheduler can obtain the real-time actual number of available CPU cores of each node after the application task is deployed, and it is convenient for the subsequent resource scheduler to deploy the application task for each node.

In one embodiment, after the task of executing the application is deployed to the deployment node, the method further includes: monitoring the task execution status of the deployment node, and updating the available CPU of the deployment node after the task execution of the deployment node is completed or the task execution is abnormally terminated The number of cores. So that the cluster resource scheduler can obtain the real-time actual number of available CPU cores of each node after the task execution of the deployment node is completed or the task execution is abnormally terminated, which is convenient for subsequent resource schedulers to deploy application tasks for each node.

After selecting a node whose available CPU quantity is greater than or equal to the CPU demand quantity as the deployment node, and deploying the task of executing the application to the deployment node, the method further includes the step of: updating the available CPU quantity of the deployment node. Specifically, the difference between the number of available CPUs before the deployment node is deployed and the number of CPU requirements is used as the updated number of available CPUs of the deployment node. Specifically, after the application is deployed for the deployment node, the number of available CPU cores of the deployment node is updated in time, so that the cluster resource scheduler can obtain the real-time actual number of available CPU cores of each node, which is convenient for subsequent resource schedulers to deploy for each node application.

In one embodiment, after converting the exclusive CPU allocated to the application to the shared CPU, the method further includes the step of: updating the number of available CPUs of the deployment node. Specifically, the sum of the number of available CPUs and the number of CPU requirements after the deployment node is deployed as the updated number of available CPUs of the deployment node. Specifically, when the application exit event of the deployment node is monitored, the exclusive CPU core of the node does not need to perform the task of the application. At this time, the number of available CPU cores of the deployment node is updated again to make the deployment node available after the application is deployed The sum of the number of CPU cores and the number of CPU core requirements is the updated number of available CPU cores of the deployment node, so that after the current task of the deployment node ends, the current number of available CPU cores is updated in time to facilitate subsequent resource schedulers for each Node deployment application.

The following uses typical cluster and application information as examples to illustrate the differences between this embodiment and some cases:

Typical cluster and application information is shown in Table 1 below:

Table 1

The following describes the execution flow of the two modes when scheduling tasks in a cluster application.

In some cases, the scheduling process of the cluster application under the static exclusive CPU solution is as follows:

Initialization process; MASTER establishes a connection with NODE1 and NODE2; 20 of the 32 CPUs on the NODE1 node are used as shared CPUs, and 12 are reported as exclusive CPUs to the MASTER node. Of the 48 CPUs on the NODE2 node, 30 are shared CPUs and 18 are reported to MASTER as exclusive CPUs. From the perspective of MASTER, there are 50 shared CPUs and 30 exclusive CPUs in the cluster. The initialization state table is shown in Table 2 below:

Table 2

(1) The scheduling process of common application containers is as follows:

Under the condition of no service in the cluster, deploy 15 CONTAINER1 containers. The scheduler will deploy 6 CONTAINER1 containers on NODE1 and 9 CONTAINER1 containers on NODE2 according to the proportion of shared CPUs available on the two nodes. The updated status table is shown in Table 3:

table 3

Continue to deploy 4 CONTAINER2 containers, the scheduler will deploy 1 CONTAINER2 container on NODE1, 2 CONTAINER2 containers on NODE2, and 1 CONTAINER2 container cannot be deployed due to insufficient resources. The updated status table is shown in Table 4:

Table 4

It can be seen from the above process that CONTAINER1 and CONTAINER2 have no exclusive CPU requirements, and all the pre-planned exclusive CPU resources in this cluster are idle.

(2) The scheduling process of high-performance application containers is as follows:

Under the condition of no service in the cluster, deploy 10 CONTAINER3 containers. The scheduler will deploy 4 CONTAINER3 containers on NODE1 and 6 CONTAINER3 containers on NODE2 according to the proportion of shared CPUs available on the two nodes. The updated status table is shown in Table 5:

table 5

Continue to deploy 3 CONTAINER4. The scheduler will deploy 1 CONTAINER4 container on NODE1 and 1 CONTAINER4 container on NODE2, and 1 CONTAINER4 container cannot be deployed due to insufficient resources. The updated status table is shown in Table 6:

Table 6

Through the above process, it can be seen that the number of deployments of CONTAINER3 and CONTAINER4 is ultimately limited by the exclusive CPU resources, resulting in a situation of tight exclusive resources and a large amount of shared resources in the cluster.

It can be obtained through the above two common application container and high-performance application container deployment processes. Since clusters often need to use shared CPU cores and exclusive CPU cores as two resources for scheduling, it is inevitable that in some scenarios will result in a resource Insufficient, and another kind of resources is a lot of idle waste occurs.

In the embodiment of the present disclosure, the scheduling process of the application container in the cluster under the dynamic exclusive CPU solution is as follows:

Initialization process; MASTER establishes a connection with NODE1 and NODE2; 32 of the 32 CPUs on the NODE1 node are reported to the MASTER node as shared CPUs, and 48 of the 48 CPUs on the NODE2 node are reported to the MASTER as shared CPUs From a perspective, the cluster has a total of 80 shared CPUs and 0 exclusive CPU cores. The state table in the initial state is shown in Table 7:

Table 7

(1) The scheduling process of common application containers is as follows:

Under the condition of no service in the cluster, deploy 15 CONTAINER1 containers. The scheduler will deploy 6 CONTAINER1 containers on NODE1 and 9 CONTAINER1 containers on NODE2 according to the proportion of shared CPUs available on the two nodes. The state table after updating the state is shown in Table 8:

Table 8

Continue to deploy 4 CONTAINER2 containers, the scheduler will deploy 2 CONTAINER2 containers on NODE1, 2 CONTAINER2 containers on NODE2, and enough resources to deploy 3 CONTAINER2 containers. The state table after updating the state is shown in Table 9:

Table 9

Through the above process, you can see that CONTAINER1 and CONTAINER2 do not have exclusive CPU requirements. All CPU resources in this cluster are used as shared CPUs, and there is no idle scenario.

Under the condition of no service in the cluster, deploy 10 CONTAINER3 containers. The scheduler will deploy 4 CONTAINER3 containers on NODE1 and 6 CONTAINER3 containers on NODE2 according to the proportion of shared CPUs available on the two nodes. The state table after updating the state is shown in Table 10:

Table 10

Continue to deploy 3 CONTAINER4, the scheduler will deploy 1 CONTAINER4 container on NODE1, 2 CONTAINER4 containers on NODE2, and enough resources to deploy 3 CONTAINER4. The updated state table is shown in Table 11:

Table 11

Through the above process, we can see that during the deployment of CONTAINER3 and CONTAINER4, the system will dynamically convert the corresponding number of shared CPUs on the nodes into exclusive CPUs based on the actual number of exclusive CPUs required by the container.

It can be obtained through the above two common application container and high-performance application container deployment processes. In this embodiment, the method of dynamically monopolizing the CPU core does not need to pay attention to whether the container needs to share the CPU or the exclusive CPU at the scheduling level. CPU needs to be scheduled, thereby improving the utilization efficiency of CPU resources in the cluster at the scheduling layer, circumventing the inevitable problem of idle CPU resources in the past, and improving the utilization efficiency of CPU resources.

Compared with some cases, this embodiment provides a CPU resource scheduling method, all CPU cores on each node are configured as shared CPU cores, and the number of shared CPU cores of each node is used as the available CPU core of the node Number, no need to configure exclusive CPU and shared CPU, reducing the complexity of configuring nodes; at the same time, CPU resources are only scheduled in the shared CPU dimension, and there is no need to schedule CPU resources in the shared CPU and exclusive CPU dimension, which reduces the scheduling dimension of CPU resources Then select the node with the number of available CPU cores greater than or equal to the number of application CPU cores as the deployment node, deploy the application to the deployment node to meet the application's CPU core demand, and select and apply from the shared CPU core of the deployment node when the application starts an event The number of shared CPU cores with the same number of exclusive CPU requirements is converted to exclusive CPU cores for use. When the application exits, the exclusive CPU cores allocated to the application are converted to shared CPU cores. According to the actual needs of the application, the exclusive CPU cores are Dynamic conversion of shared CPU cores, so that at the level of scheduling, it is not necessary to pay attention to whether the container needs shared CPU cores or exclusive CPU cores, but merged as ordinary CPU core requirements for scheduling, avoiding some cases of sharing CPU cores and exclusive CPU cores are scheduled as two kinds of resources, resulting in a situation where "one resource is insufficient, and the other resource is largely idle and wasted", which greatly improves the utilization efficiency of CPU resources and the flexibility of scheduling. On the shared CPU core and exclusive CPU core allocation ratio relationship, the node operating system needs to be restarted, which reduces the threshold for exclusive CPU resources, and avoids the migration or interruption of the bearer service on the node, which does not affect the service effect of the node.

The second embodiment of the present disclosure relates to a CPU resource scheduling method. The second embodiment is an improvement on the first embodiment. The main improvement is that: in this embodiment, a specific implementation manner for obtaining the number of CPU core requirements of an application is provided.

The specific flowchart of the CPU resource scheduling method in this embodiment is shown in FIG. 2 and specifically includes:

Step 201: All CPU cores on each node are configured as shared CPU cores, and the number of shared CPU cores of each node is used as the number of available CPU cores of the node.

The above step 201 is substantially the same as step 101 in the first embodiment, and will not be repeated here.

Step 202: Query the configuration information of the application.

Step 203: Determine the number of exclusive CPU requirements according to the configuration information.

For the

above steps

202 and 203, in one embodiment, after obtaining the number of available CPU cores of each node, the resource scheduler in the cluster queries the configuration information of the application before deploying the application, and the configuration information of the application includes the CPU of the application. According to the description of core requirements, the cluster resource scheduler can determine the number of exclusive CPU cores and the number of shared CPU cores of the application according to the description in the configuration information, which is convenient for the subsequent dynamic allocation of exclusive CPU cores for the application.

Step 204: Select a node whose available CPU core number is greater than or equal to the required number of CPU cores as the deployment node, and deploy the task of executing the application to the deployment node.

The above step 204 is substantially the same as step 103 in the first embodiment, and will not be repeated here.

Step 205: Hand over tasks that do not require exclusive CPU cores in the application to the operating system of the deployment node for scheduling.

In one embodiment, after the cluster resource scheduler deploys the task that executes the application to the deployment node according to the number of required CPU cores of the application, the resource retriever hands over the task that requires exclusive CPU cores in the application to the converted Exclusive CPU cores are used for processing, and tasks that do not require exclusive CPU cores in the application are directly scheduled by the operating system of the deployment node of the application for scheduling, and the operating system of the deployment node selects which shared CPU cores of the deployment node It does not need to monopolize the CPU core in the application, and realizes the flexible call to the shared CPU core in the deployment node.

Step 206: Monitor the application startup event and exit event of the deployment node. If the startup event of the application is monitored, step 207 is entered; if the exit event is monitored, step 208 is entered.

Step 207: When the application start event of the deployment node is monitored, select the shared CPU cores equal to the exclusive CPU demand from the shared CPU cores of the deployment node and convert to exclusive CPU cores, and assign the converted exclusive CPU cores to Application use.

Step 208: When the application exit event of the deployment node is monitored, convert the exclusive CPU core allocated to the application to a shared CPU core.

The above steps 206 to 208 are substantially the same as the steps 104 to 106 in the first embodiment, and will not be repeated here.

Compared with some cases, this embodiment provides a CPU resource scheduling method, and proposes a specific implementation method for obtaining the number of application CPU cores, and obtains the number of application CPU cores according to the configuration information of the application. And tasks that do not require exclusive CPU cores in the application are directly dispatched to the operating system of the deployment node of the application for scheduling, and the operating system of the deployment node selects which shared CPU cores of the deployment node to process the application without exclusive CPU cores The task of implementing the flexible call to the shared CPU core in the deployment node.

The third embodiment of the present disclosure relates to a CPU resource scheduling method. The third embodiment is an improvement on the first embodiment, and the main improvement lies in: a specific implementation manner for determining and converting an exclusive CPU core is proposed in this embodiment.

A specific process schematic diagram of a CPU resource scheduling method in this embodiment is shown in FIG. 3, and specifically includes:

Step 301: All CPU cores on each node are configured as shared CPU cores, and the number of shared CPU cores of each node is used as the number of available CPU cores of the node.

Step 302: Receive and analyze the number of CPU core requirements of the application.

Step 303: Select a node whose available CPU core number is greater than or equal to the required number of CPU cores as the deployment node, and deploy the task of executing the application to the deployment node.

The above steps 301 to 303 are substantially the same as

steps

101 and 103 in the first embodiment, and will not be repeated here.

Step 304: Monitor the application startup event and exit event of the deployment node. If the startup event of the application is monitored, step 305 is entered; if the exit event is monitored, step 309 is entered.

Step 305: Determine the ID of the CPU core of the deployment node that is equal to the number of exclusive CPU requirements and needs to be converted into the exclusive CPU core.

Step 306: According to the number of exclusive CPU requirements, determine the ID of the shared CPU core of the deployed node equal to the number of exclusive CPU requirements as the ID of the CPU core to be converted.

Step 307: Convert the shared CPU core corresponding to the CPU core ID to be converted on the deployment node into an exclusive CPU core.

Step 308: Assign the converted exclusive CPU core to the application.

With respect to the

above steps

305 and 308, in one embodiment, the processing for the application startup event in the cluster is as follows: (1) Query application configuration information, determine the number of exclusive CPU requirements of the application, and hand over tasks that do not require exclusive CPU to the operating system Perform scheduling; (2) Determine the number of CPU cores in the deployment node that need to be converted to exclusive CPUs, and the ID of the CPU cores of the deployment nodes that need to be converted to exclusive CPU cores; (3) Convert the CPU cores of specific IDs on the deployment nodes to exclusive CPU cores (the number is the number of exclusive CPUs required by the application on the deployment node); (4) Assign the converted exclusive CPU cores to the application.

In one embodiment, in step (2) above, the ID of the shared CPU core with the lightest load on the deployment node may be directly used as the ID of the CPU core to be converted. The shared CPU core with the fewest tasks and the lightest load directly handles the task of monopolizing the CPU core required by the application on the deployment node, providing a selection strategy for CPU conversion goals, which not only improves the speed of scheduling CPU cores, but also speeds up Task processing efficiency.

In one embodiment, after the shared CPU core corresponding to the CPU core ID to be converted on the deployment node is converted into an exclusive CPU core, the method further includes: migrating the load on the exclusive CPU core to other shared CPU cores. After step (3) above, you can also migrate the task process that was previously processed on the exclusive CPU core to another shared CPU core, which will be processed by the other shared CPU core. The migration was originally run on the "converted exclusive CPU" The above processes/tasks are prepared for the application to monopolize the CPU, and at the same time make the scheduling of CPU cores in the node more flexible.

In one embodiment, the converted exclusive CPU core information is passed to the application, and CONTROL GROUP is used to ensure that only the belonging application can use the converted exclusive CPU core, which specifically includes: binding the application to the application according to the application's exclusive CPU description Convert the exclusive CPU core. In one embodiment, the converted exclusive CPU core information is transferred to the application, and the converted exclusive CPU core information may be transferred to the application using the environment variable or configuration file of the exclusive CPU core. Use CONTROLGROUP (control group) to ensure that only the belonging application can use the converted exclusive CPU core. In one embodiment, the application is bound to the converted exclusive CPU, and a specific implementation solution that uses CONTROL GROUP to ensure CPU exclusive is provided, and this implementation depends on the binding strategy specified in the application information.

Step 309: Convert the exclusive CPU core allocated to the application to a shared CPU core.

Specifically, the processing of application exit events in the cluster is as follows: (1) Convert the exclusive CPU core assigned to the application container into a shared CPU; (2) The cluster scheduler monitors the task execution status sent to the node and sends it to the node After the task ends (including normal completion and abnormal termination), update the number of available CPUs of the corresponding nodes on the cluster. That is: the number of available CPU cores of the node = the number of currently available CPU cores of the node + the number of CPU cores required by the node to end the task.

The process of dynamically converting shared CPU cores and exclusive CPU cores on a node will be described in more detail with reference to FIG. 4 of the specification:

(1) When the node starts, all CPU cores are scheduled as shared CPU cores, and monitor specific files in the /PROC directory in the system. Initially, the exclusive CPU core ID list is empty, and the application's exclusive CPU core demand information is obtained;

(2) When the business on the node requires exclusive CPU cores, a list of IDs requiring exclusive CPU cores is described in a specific file in the system/PROC directory. Take a node as an example, specifically: configure PROC parameters according to the requirements of specific files in the system/PROC directory of the node, and convert it into CPUMASK (that is, the ID mask of the exclusive CPU core); after that, determine whether CPUMASK is legal, if it is legal , It is determined whether CPUMASK is empty, if it is empty, then clear the exclusive domain (exclusive collection of CPU cores), and then configure a new exclusive domain (exclusive collection of CPU cores), reconstruct the scheduling domain (shared collection of CPU cores). If it is not empty, configure a new exclusive domain (exclusive collection of CPU cores), and reconstruct the scheduling domain (collection of shared CPU cores);

(3) The system kernel finds the updated exclusive CPU core ID list, sets the CPU core corresponding to the ID in the list as the exclusive CPU core in the system, and can schedule the CPU core list after updating the operating system;

(4) Convert the CPU cores of the CPU core list with the lowest load to exclusive CPU cores. After updating the operating system, the CPU core list can be scheduled, and the operating system will not be able to continue scheduling processes to the exclusive CPU cores;

(5) Migrate the processes that have been set to run on the exclusive CPU core by the operating system to other shared CPU cores to ensure that the exclusive CPU cores are idle and wait for the application process to be bound to use

(6) Update the ID list information describing that it has been successfully set as the exclusive CPU core in the specific file under the /PROC directory.

The following example illustrates the exclusive CPU core conversion and isolation strategy on the node:

Assuming that NODE1 node contains 32 CPU resources, all CPU cores are initially configured as shared CPU cores. Assuming that the application requires exclusive CPU cores, the CPU core with the larger shared CPU core ID is preferentially converted to the exclusive CPU core.

Table 12

When CONTAINER1 is deployed on the initialization node NODE1, the CPU layout on NODE1 is adjusted to Table 13:

Table 13

The corresponding CPUSET configuration of CONTAINER1 on CGROUP is shown in Table 14:

Table 14

A	全局共享Global sharing	应用独占Application monopoly
CONTAINER1CONTAINER1	0～～～310～～～31	A

On this basis, CONTAINER2 is deployed on the NODE1 node, and the CPU layout on NODE1 is adjusted to Table 15:

Table 15

The corresponding CPUSET configuration of CGROUP on the NODE1 node is shown in Table 16:

Table 16

A	全局共享Global sharing	应用独占Application monopoly
CONTAINER1CONTAINER1	0～～～310～～～31	A
CONTAINER2CONTAINER2	0～～～310～～～31	A

On this basis, CONTAINER3 is deployed on the NODE1 node, then the CPU layout on NODE1 is adjusted to Table 17:

Table 17

The corresponding CPUSET configuration of CGROUP on the NODE1 node is shown in Table 18:

Table 18

A	全局共享Global sharing	应用独占Application monopoly
CONTAINER1CONTAINER1	0～～～300～～～30	A
CONTAINER2CONTAINER2	0～～～300～～～30	A
CONTAINER3CONTAINER3	0～～～300～～～30	3131

On this basis, CONTAINER4 is deployed on the NODE1 node, then the CPU layout on NODE1 is adjusted to Table 19:

Table 19

The corresponding application configuration on the NODE1 node is shown in Table 20:

Table 20

A	全局共享Global sharing	应用独占Application monopoly
CONTAINER1CONTAINER1	0～～～220～～～22	A
CONTAINER2CONTAINER2	0～～～220～～～22	A
CONTAINER3CONTAINER3	0～～～220～～～22	3131
CONTAINER4CONTAINER4	0～～～220～～～22	23～～～3023～～～30

As can be seen from the above allocation process, the CPU resources on the node are dynamically converted between the shared CPU and the exclusive CPU according to the actual needs of the application. After the CPU core is converted to the exclusive CPU core, the application ownership of the exclusive CPU core needs to be clearly defined, and through the configuration in the CONTROL GROUP, the exclusive CPU core can only be used by the belonging application.

Compared with some cases, this embodiment provides a specific implementation method for determining and converting an exclusive CPU core. The CPU core ID is used to determine the shared CPU core that needs to be converted to an exclusive CPU core, and the CPU core ID is used to Realize the conversion from shared CPU core to exclusive CPU core and allocate the converted exclusive CPU core to the application. At the same time, the shared CPU core with the fewest tasks and the lightest load directly handles the task of monopolizing the CPU core required by the application on the deployment node. And the task process converted to the exclusive processing on the exclusive CPU core is migrated to other shared CPU cores, and the processing is performed by the other shared CPU cores, making the scheduling of the CPU cores in the node more flexible.

The steps of the above methods are divided only for clarity, and can be combined into one step or split into some steps and decomposed into multiple steps when implemented, as long as they include the same logical relationship, they are all within the scope of protection of this patent ; Adding insignificant modifications to the algorithm or process or introducing insignificant designs, but not changing the core design of its algorithm and process are within the scope of protection of the patent.

The fourth embodiment of the present disclosure relates to an electronic device, as shown in FIG. 5, including: at least one processor 501; and a memory 502 communicatively connected to the at least one processor 501; The instructions executed by the processor 501 are executed by at least one processor 501, so that the at least one processor 501 can execute the medium CPU resource scheduling method in any of the foregoing embodiments.

Among them, the memory 502 and the processor 501 are connected by a bus. The bus may include any number of interconnected buses and bridges. The bus connects one or more processors 501 and various circuits of the memory 502 together. The bus can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, etc., which are well known in the art, and therefore, they will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on the transmission medium. The data processed by the processor 501 is transmitted on the wireless medium through the antenna. Further, the antenna also receives the data and transmits the data to the processor 501.

The processor 501 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. The memory 502 may be used to store data used by the processor 501 when performing operations.

The fifth embodiment of the present disclosure relates to a computer-readable storage medium storing a computer program. When the computer program is executed by the processor, the above method embodiments are implemented.

That is, those skilled in the art can understand that all or part of the steps in the method in the above embodiments can be completed by instructing relevant hardware through a program, which is stored in a storage medium and includes several instructions to make a device ( It may be a single chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods described in the embodiments of the present disclosure. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program code .

This embodiment provides a CPU resource scheduling method and electronic device, which reduces the complexity of configuring nodes without affecting the service effect of nodes, and reduces the scheduling dimension of CPU resources and the threshold for using exclusive CPU resources. It also realizes flexible scheduling of shared CPU and exclusive CPU resources, which improves the CPU resource utilization efficiency of nodes.

Compared with some cases, the embodiments of the present disclosure configure all CPU cores on each node as shared CPU cores, and use the number of shared CPU cores of each node as the number of available CPU cores of the node, without the need to configure an exclusive CPU and share CPU, reduces the complexity of configuring nodes; at the same time, only schedules CPU resources in the shared CPU dimension, and does not need to schedule CPU resources in the shared CPU and exclusive CPU dimensions at the same time, reducing the scheduling dimension of CPU resources; and then selects the number of available CPU cores greater than or A node equal to the number of application CPU cores is required as the deployment node, and the application is deployed to the deployment node to meet the application's CPU core requirements. When processing application startup events, the number of exclusive CPU requirements of the application is selected from the shared CPU cores of the deployment node Share CPU cores and convert them to exclusive CPU cores for use. When processing application exit events, convert the exclusive CPU cores assigned to the application to shared CPU cores, and realize the dynamic conversion of exclusive CPU cores and shared CPU cores according to the actual needs of the application. Therefore, at the level of scheduling, it is not necessary to pay attention to whether the container needs to share CPU cores or exclusive CPU cores, but it is combined as ordinary CPU cores for scheduling, which avoids the use of shared CPU cores and exclusive CPU cores as two resources in some cases. Scheduling results in a situation where "one resource is insufficient, while another resource is largely idle and wasted", which greatly improves the utilization efficiency of CPU resources and the flexibility of scheduling. It also does not need to share CPU cores and monopolize the nodes due to modification The distribution of CPU cores requires a restart of the node's operating system, which lowers the threshold for exclusive use of CPU resources. At the same time, it avoids the migration or interruption of bearer services on the node and does not affect the service effect of the node.

Those of ordinary skill in the art can understand that the above-mentioned embodiments are specific examples for realizing the present disclosure, and in practical applications, various changes can be made in form and detail without departing from the spirit and range.

Claims

A CPU resource scheduling method, including:

All CPU cores on each node are configured as shared CPU cores, and the number of shared CPU cores of each node is taken as the number of available CPU cores of the node;

Receiving and analyzing the number of CPU core requirements of the application, the number of CPU core requirements including the number of exclusive CPU requirements and the number of shared CPU core requirements;

Selecting a node with a number of available CPU cores greater than or equal to the required number of CPU cores as a deployment node, and deploying tasks that execute the application to the deployment node;

Monitoring the application startup event and the exit event of the deployment node, and when the application startup event of the deployment node is monitored, selecting a shared CPU core equal to the number of exclusive CPU requirements from the shared CPU core of the deployment node and Convert to an exclusive CPU core, and assign the converted exclusive CPU core to the application for use; when an application exit event of the deployment node is monitored, convert the exclusive CPU core allocated to the application to a shared CPU core .
The CPU resource scheduling method according to claim 1, wherein the receiving and analyzing the number of CPU core requirements of the application specifically includes:

Query the configuration information of the application;

The number of exclusive CPU requirements is determined according to the configuration information.
The CPU resource scheduling method according to claim 2, wherein after querying the configuration information of the application, the method further comprises:

Tasks that do not require exclusive CPU cores in the application are handed over to the operating system of the deployment node for scheduling.
The CPU resource scheduling method according to claim 1, wherein the shared CPU cores equal to the number of exclusive CPU requirements are selected from the shared CPU cores of the deployment node and converted into exclusive CPU cores The exclusive CPU core is allocated for use by the application, and specifically includes:

Determine the ID of the CPU core of the deployment node that is equal to the number of exclusive CPU requirements and needs to be converted into an exclusive CPU core;

According to the number of exclusive CPU requirements, determine the ID of the shared CPU core of the deployment node equal to the number of exclusive CPU requirements as the ID of the CPU core to be converted;

Converting the shared CPU core corresponding to the CPU core ID to be converted on the deployment node into an exclusive CPU core;

The converted exclusive CPU core is allocated to the application for use.
The CPU resource scheduling method according to claim 4, wherein, based on the number of exclusive CPU requirements, the ID of the shared CPU core of the deployment node equal to the number of exclusive CPU requirements is determined as the CPU core to be converted ID, including:

The ID of the shared CPU core with the lightest load on the deployment node is used as the ID of the CPU core to be converted.
The CPU resource scheduling method according to claim 4, wherein after converting the shared CPU core corresponding to the CPU core ID to be converted on the deployment node into an exclusive CPU core, further comprising:

The load on the exclusive CPU core is migrated to other shared CPU cores of the deployment node.
The CPU resource scheduling method according to claim 4, wherein the allocating the converted exclusive CPU core to the application for use specifically includes:

Pass the converted exclusive CPU core information to the application, use CONTROL GROUP to ensure that only the belonging application can use the converted exclusive CPU core, and the application decides how to use the converted exclusive CPU core resources .
The CPU resource scheduling method according to claim 1, wherein after the task of executing the application is deployed to the deployment node, further comprising: updating the number of available CPU cores of the deployment node.
The CPU resource scheduling method according to claim 8, wherein after the task of executing the application is deployed to the deployment node, the method further comprises:

Monitor the task execution status of the deployment node, and update the number of available CPU cores of the deployment node after the task execution of the deployment node is completed or the task execution is abnormally terminated.
An electronic device including at least one processor; and,

A memory in communication connection with the at least one processor;

Wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to implement the CPU resource scheduling method according to any one of claims 1 to 9 above .