CN111240824A - 一种cpu资源调度方法及电子设备 - Google Patents

Abstract

本发明实施例涉及网络技术领域。本发明实施方式中提供了一种CPU资源调度方法，将各个节点上的全部CPU核均配置为共享CPU核，然后选取满足应用CPU核需求数量的节点作为部署节点，将应用部署到部署节点上，处理应用启动事件时，从部署节点的共享CPU核中将应用的独占CPU核需求数量相等的共享CPU核转换为独占CPU核，以供应用使用；处理应用退出事件时，将分配给应用使用的独占CPU核转换为共享CPU核。本实施方式提供的一种CPU资源调度方法及电子设备，使得在不影响节点服务效果的同时，降低了配置节点的复杂度，同时降低了CPU资源的调度维度以及对独占CPU资源的使用门槛，也实现了对共享CPU以及独占CPU资源的灵活调度，提高了节点的CPU资源利用效率。

Description

一种CPU资源调度方法及电子设备

技术领域

本发明实施例涉及网络技术领域，特别涉及一种CPU资源调度方法及电子设备。

背景技术

大数据时代下，社交网络、在线购物、物联网等会产生大量的实时数据流，如何快速分析这些实时数据成为大数据处理技术的一大挑战。分布式流数据处理系统是一类将实时流数据处理过程转换成多个小作业，在多个处理机器上并行执行的系统。基于小批次作业的分布式流数据处理系统将实时流数据按照时间间隔切分成一系列的小批次数据，然后对这些小批次数据进行处理，利用这种方式，该类型系统可以提供低延迟、高吞吐量的实时数据处理服务。随着云计算技术的发展和普及，将这类复杂的应用部署到云环境集群中成为趋势。

发明人发现现有技术中至少存在如下问题：在云环境集群中，各个节点往往需要预先配置独占CPU核和共享CPU核，配置较为复杂；且需将共享CPU核和独占CPU核作为两种资源进行调度，调度维度较高；且由于独占CPU核的使用门槛较高，往往会出现一种资源不足，而另一种资源大量闲置浪费的情况发生，导致CPU资源的利用效率不高；同时独占CPU核在节点操作系统启动以后就确定下来了，如果为了改善CPU资源的利用效率而修改节点上共享CPU核和独占CPU核的分配比例关系，则必须重新启动节点操作系统才可以生效。而在云环境集群中，节点操作系统的重启意味着节点上承载业务的迁移或者中断，不可能高频次执行，对节点的服务效果影响很大。

发明内容

本发明实施方式的目的在于提供一种CPU资源调度方法及电子设备，使得在不影响节点服务效果的同时，降低了配置节点的复杂度，同时降低了CPU资源的调度维度以及对独占CPU资源的使用门槛，也实现了对共享CPU以及独占CPU资源的灵活调度，提高了节点的CPU资源利用效率。

为解决上述技术问题，本发明的实施方式提供了一种CPU资源调度方法，包括：将各个节点上的全部CPU核均配置为共享CPU核，并将各个节点的共享CPU核数量作为该节点的可用CPU核数量；接收并解析应用的CPU核需求数量，CPU核需求数量包括独占CPU需求数量和共享CPU核需求数量；选取可用CPU核数量大于或等于CPU核需求数量的节点作为部署节点、将执行所述应用的任务部署到部署节点；监控部署节点的应用启动事件及退出事件，在监控到部署节点的应用启动事件时，从部署节点的共享CPU核中选取与独占CPU需求数量相等的共享CPU核并转换为独占CPU核、将转换的独占CPU核分配给应用使用；在监控到部署节点的应用退出事件时，将分配给应用使用的独占CPU核转换为共享CPU核。

本发明的实施方式还提供了一种电子设备，包括至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行以实现上述CPU资源调度方法。

本发明实施方式相对于现有技术而言，将各个节点上的全部CPU核均配置为共享CPU核、并将各个节点的共享CPU核数量作为该节点的可用CPU核数量，无需配置独占CPU和共享CPU，降低了配置节点的复杂度；同时仅在共享CPU维度调度CPU资源，无需同时在共享CPU和独占CPU维度上调度CPU资源，降低了CPU资源的调度维度；然后选取可用CPU核数量大于或等于应用CPU核需求数量的节点作为部署节点、将应用部署到部署节点以满足应用的CPU核需求，处理应用启动事件时，从部署节点的共享CPU核中选取与应用的独占CPU需求数量相等的共享CPU核、并转换为独占CPU核供应用使用，处理应用退出事件时，将分配给应用使用的独占CPU核转换为共享CPU核，根据应用实际需要实现独占CPU核与共享CPU核的动态转换，从而在调度的层面上不需要关注容器需要的是共享CPU核还是独占CPU核，而是合并作为普通CPU核需求进行调度，避免了现有技术中将共享CPU核和独占CPU核作为两种资源进行调度而导致“一种资源不足，而另一种资源大量闲置浪费”的情况发生，大大提高了CPU资源的利用效率以及调度的灵活性，同时也不需要因修改节点上共享CPU核和独占CPU核的分配比例关系而需重启节点操作系统，降低了独占CPU资源的使用门槛，同时避免导致节点上承载业务的迁移或中断，不影响节点的服务效果。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1是根据本发明第一实施方式中一种CPU资源调度方法的流程示意图；

图2是根据本发明第二实施方式中一种CPU资源调度方法的流程示意图；

图3是根据本发明第三实施方式中一种CPU资源调度方法的流程示意图；

图4是根据本发明第三实施方式中共享CPU核和独占CPU核动态转换的流程示意图；

图5是根据本发明第四实施方式中一种电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本发明而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本发明所要求保护的技术方案。

本发明的第一实施方式涉及一种CPU资源调度方法，其具体的流程示意图如图1所示，具体包括：

步骤101：将各个节点上的全部CPU核均配置为共享CPU核，并将各个节点的共享CPU核数量作为该节点的可用CPU核数量。

具体的说，现有的集群中通常需要预先规划独占CPU核，而本发明实施方式中将集群中各个节点上的全部CPU核均配置为共享CPU核。节点启动时，各个节点上全部CPU核均为共享CPU核，在集群调度器中只存在一种类型的CPU资源即共享CPU资源。初始状态下，所有节点的可用CPU核数量都等于节点上报的共享CPU核数量，即：节点初始可用CPU核数量＝节点上报共享CPU核数量。因此，在初始状态下各个节点的共享CPU核数量即为该节点的可用CPU核数量，在节点启动后，各个节点将自身的共享CPU核数量上报集群资源调度器。本实施方式中无需预先规划独占CPU核，降低了节点的复杂度并且降低了独占CPU资源的使用门槛。

步骤102：接收并解析应用的CPU核需求数量。

具体的说，在有待执行的应用任务时，接收并解析应用的CPU核需求数量，应用总计CPU核数量＝独占CPU核数量+共享CPU核数量。集群调度器需要解析应用的CPU核需求，确定应用的独占CPU核需求数量以及共享CPU核需求数量，以便后续根据应用的独占CPU核需求数量以及共享CPU核需求数量来为应用部署节点。

步骤103：选取可用CPU核数量大于或等于CPU核需求数量的节点作为部署节点、将执行所述应用的任务部署到部署节点。

具体的说，集群中各个节点将自身的共享CPU核数量上报给集群资源调度器，集群资源调度器得知集群中各个节点的可用CPU核数量，从而在接收到应用的CPU核需求数量时能够根据应用的CPU核需求数量选取满足该应用需求的节点来作为部署节点。将执行所述应用的任务部署到部署节点上，由该部署节点来执行应用的任务。

步骤104：监控部署节点的应用启动事件及退出事件。若监控到应用的启动事件时，进入步骤105；若监控到退出事件，则进入步骤106。

步骤105：从部署节点的共享CPU核中选取与独占CPU需求数量相等的共享CPU核并转换为独占CPU核、将转换的独占CPU核分配给应用使用。

步骤106：在监控到部署节点的应用退出事件时，将分配给应用使用的独占CPU核转换为共享CPU核。

针对上述步骤104至步骤106具体的说，集群资源调度器监控部署节点的应用的启动事件和退出事件，若监控到部署节点的应用的启动事件时，从部署节点的共享CPU核中选取与该应用的独占CPU核需求数量相等的共享CPU核并转换为独占CPU核，将转换后的独占CPU核分配给应用使用。当监控到部署节点的应用退出事件时，节点的独占CPU核无需再执行应用的任务，此时，将分配给应用使用的独占CPU核再转换为共享CPU核。动态地将对应数量的共享CPU核转换为独占CPU核，从而在调度的层面上就不需要关注容器需要的是共享CPU核还是独占CPU核，合并作为普通CPU核需求进行调度，避免了现有技术中将共享CPU核和独占CPU核作为两种资源进行调度而导致一种资源不足，而另一种资源大量闲置浪费的情况发生，大大提高了CPU资源的利用效率以及调度的灵活性。同时也不会出现现有技术中预先配置好独占CPU核后，修改节点上共享CPU核和独占CPU核的分配比例关系而需重启节点操作系统的情况发生，避免了由于修改节点上共享CPU核和独占CPU核的分配比例关系而导致节点上承载业务的迁移或中断，提高了节点的服务效果。

优选地，将执行应用的任务部署到部署节点之后，还包括：更新部署节点的可用CPU核数量。以便集群资源调度器能够在将应用的任务部署之后得到实时的各个节点的实际可用CPU核数量，方便后续资源调度器为各个节点部署应用的任务。

可选地，在将执行应用的任务部署到部署节点之后，还包括：监控部署节点的任务执行状态，并在部署节点的任务执行完成或任务执行异常终止之后，更新部署节点的可用CPU核数量。以便集群资源调度器能够在将部署节点的任务执行完成或任务执行异常终止之后得到实时的各个节点的实际可用CPU核数量，方便后续资源调度器为各个节点部署应用的任务。

在选取可用CPU数量大于或等于CPU需求数量的节点作为部署节点、将执行所述应用的任务部署到部署节点之后，还包括步骤：更新部署节点的可用CPU数量。具体包括：将部署节点被部署应用之前的可用CPU数量与CPU需求数量的差值作为更新后的、部署节点的可用CPU数量。具体地说，在为部署节点部署应用之后，及时更新该部署节点的可用CPU核数量，以便集群资源调度器能够得到实时的各个节点的实际可用CPU核数量，方便后续资源调度器为各个节点部署应用。

优选地，在将分配给应用使用的独占CPU转换为共享CPU之后，还包括步骤：更新部署节点的可用CPU数量。具体包括：将部署节点被部署应用之后的可用CPU数量与CPU需求数量的和作为更新后的、部署节点的可用CPU数量。具体地说，当监控到部署节点的应用退出事件时，节点的独占CPU核无需再执行应用的任务，此时，重新更新该部署节点的可用CPU核数量，将部署节点被部署应用之后的可用CPU核数量与CPU核需求数量的和作为更新后的、部署节点的可用CPU核数量，以便在该部署节点的当前任务结束后，及时更新当前可用的CPU核数量，方便后续资源调度器为各个节点部署应用。

下面以典型的集群和应用信息为例来说明本实施方式与现有技术的区别：

典型集群和应用信息如下表1所示：

表1

下面分别描述在集群应用任务调度时，两种模式的执行流程。

现有技术中静态独占CPU方案下集群应用调度流程如下：

初始化过程；Master和Node1、Node2建立连接；在Node1节点上全部32个CPU中20个作为共享CPU，12个作为独占CPU上报给Master节点。在Node2节点上全部48个CPU中30个作为共享CPU，18个作为独占CPU上报给Master。从Master角度看，集群中总计拥有50个共享CPU、30个独占CPU。初始化状态表如下表2所示：

表2

(1)普通应用容器的调度过程如下：

在集群无服务条件下，部署15个Container1容器，调度器会根据两个节点上可用共享CPU的比例关系在Node1上部署6个Container1容器，Node2上部署9个Container1容器。更新后的状态表如表3所示：

表3

继续部署4个Container2容器，调度器会在Node1部署1个Container2容器在Node2上各部署2个Container2容器，还有1个Container2容器因为资源不足无法部署。更新后的状态表如表4所示：

表4

通过以上流程可以看到，Container1和Container2没有独占CPU需求，本集群中预规划的独占CPU资源全部闲置。

(2)高性能应用容器的调度过程如下：

在集群无服务的条件下，部署10个Container3容器。调度器会根据两个节点上可用共享CPU的比例关系在Node1部署4个Container3容器，Node2上部署6个Container3容器。更新后的状态表如表5所示：

表5

继续部署3个Container4，调度器会在Node1部署1个Container4容器在Node2上各部署1个Container4容器，还有1个Container4容器因为资源不足无法部署。更新后的状态表如表6所示：

表6

通过以上流程可以看到，Container3和Container4的部署数量最终受到独占CPU资源的限制，导致集群中独占资源紧张和共享资源确大量闲置的情况。

通过以上两种普通应用容器和高性能应用容器的部署流程可以得到，由于集群中往往需要将共享CPU核和独占CPU核作为两种资源进行调度，不可避免的在一些场景下会导致一种资源不足，而另一种资源却大量闲置浪费的情况发生。

本发明实施方式中动态独占CPU方案下集群中应用容器调度流程如下：

初始化过程；Master和Node1、Node2建立连接；在Node1节点上全部32个CPU中32个作为共享CPU上报给Master节点，在Node2节点上全部48个CPU中48个作为共享CPU上报给Master，从Master角度看，集群中总计拥有80个共享CPU，0个独占CPU核。初始状态下的状态表如表7所示：

表7

(1)普通应用容器的调度过程如下：

在集群无服务条件下，部署15个Container1容器，调度器会根据两个节点上可用共享CPU的比例关系在Node1部署6个Container1容器，Node2上部署9个Container1容器。更新状态后的状态表如表8所示：

表8

继续部署4个Container2容器，调度器会在Node1部署2个Container2容器,在Node2上部署2个Container2容器，还有足够的资源部署3个Container2容器。更新状态后的状态表如表9所示：

表9

通过以上流程可以看到，Container1和Container2没有独占CPU需求，本集群中全部CPU资源都被作为共享CPU使用，不存在闲置的场景。

(2)高性能应用容器的调度过程如下：

在集群无服务的条件下，部署10个Container3容器。调度器会根据两个节点上可用共享CPU的比例关系在Node1部署4个Container3容器，Node2上部署6个Container3容器。更新状态后的状态表如表10所示：

表10

继续部署3个Container4，调度器会在Node1部署1个Container4容器，在Node2上部署2个Container4容器，还有足够资源可以部署3个Container4。更新状态后的状态表如表11所示：

表11

通过以上流程可以看到，Container3和Container4的部署过程中，系统会根据容器实际的独占CPU数量需求，动态将节点上对应数量的共享CPU转换为独占CPU。

通过以上两种普通应用容器和高性能应用容器的部署流程可以得到，本实施方式中动态独占CPU核的方法，在调度的层面上不需要关注容器需要的是共享CPU还是独占CPU，合并作为普通CPU需求进行调度，从而在调度层提高了集群中CPU资源的利用效率，规避了以前不可避免的CPU资源闲置问题，提高了CPU资源的利用效率。

与现有技术相比，本实施方式中提供了一种CPU资源调度方法，将各个节点上的全部CPU核均配置为共享CPU核、并将各个节点的共享CPU核数量作为该节点的可用CPU核数量，无需配置独占CPU和共享CPU，降低了配置节点的复杂度；同时仅在共享CPU维度调度CPU资源，无需同时在共享CPU和独占CPU维度上调度CPU资源，降低了CPU资源的调度维度；然后选取可用CPU核数量大于或等于应用CPU核需求数量的节点作为部署节点、将应用部署到部署节点以满足应用的CPU核需求，应用启动事件时，从部署节点的共享CPU核中选取与应用的独占CPU需求数量相等的共享CPU核、并转换为独占CPU核供应用使用，应用退出事件时，将分配给应用使用的独占CPU核转换为共享CPU核，根据应用实际需要实现独占CPU核与共享CPU核的动态转换，从而在调度的层面上不需要关注容器需要的是共享CPU核还是独占CPU核，而是合并作为普通CPU核需求进行调度，避免了现有技术中将共享CPU核和独占CPU核作为两种资源进行调度而导致“一种资源不足，而另一种资源大量闲置浪费”的情况发生，大大提高了CPU资源的利用效率以及调度的灵活性，同时也不需要因修改节点上共享CPU核和独占CPU核的分配比例关系而需重启节点操作系统，降低了独占CPU资源的使用门槛，同时避免了节点上承载业务的迁移或中断，不影响节点的服务效果。

本发明的第二实施方式涉及一种CPU资源调度方法。第二实施方式是对第一实施方式的改进，主要改进之处在于：在本实施方式中，提供了一种获取应用CPU核需求数量的具体实现方式。

本实施方式中的CPU资源调度方法的具体流程示意图如图2所示，具体包括：

步骤201：将各个节点上的全部CPU核均配置为共享CPU核，并将各个节点的共享CPU核数量作为该节点的可用CPU核数量。

上述步骤201与第一实施方式中的步骤101大致相同，在此不进行赘述。

步骤202：查询应用的配置信息。

步骤203：根据配置信息确定独占CPU需求数量。

针对上述步骤202和步骤203具体的说，集群中资源调度器在获取各个节点的可用CPU核数量之后，在部署应用之前，查询应用的配置信息，应用的配置信息中包含该应用对CPU核的需求描述，集群资源调度器便可根据配置信息中的描述来确定该应用的独占CPU核数目和共享CPU核数目，方便后续为该应用动态分配独占CPU核。

步骤204：选取可用CPU核数量大于或等于CPU核需求数量的节点作为部署节点、将执行所述应用的任务部署到部署节点。

上述步骤204与第一实施方式中的步骤103大致相同，在此不再进行赘述。

步骤205：将应用中无需独占CPU核的任务交给部署节点的操作系统进行调度。

具体的说，集群资源调度器在根据应用的所需CPU核数目将执行所述应用的任务部署到部署节点之后，资源调取器将应用中需要独占CPU核的任务交由转换后的独占CPU核来进行处理，而应用中无需独占CPU核的任务则直接交由该应用的部署节点的操作系统来进行调度，让部署节点的操作系统来选择由该部署节点的哪些共享CPU核来处理应用中无需独占CPU核的任务，实现了对该部署节点内共享CPU核的灵活调用。

步骤206：监控部署节点的应用启动事件及退出事件。若监控到应用的启动事件时，进入步骤207；若监控到退出事件，则进入步骤208。

步骤207：在监控到所述部署节点的应用启动事件时，从部署节点的共享CPU核中选取与独占CPU需求数量相等的共享CPU核并转换为独占CPU核、将转换的独占CPU核分配给应用使用。

步骤208：在监控到部署节点的应用退出事件时，将分配给应用使用的独占CPU核转换为共享CPU核。

上述步骤206至步骤208与第一实施方式中的步骤104至步骤106大致相同，在此不再进行赘述。

与现有技术相比，本实施方式中提供了一种CPU资源调度方法，提出了一种获取应用CPU核需求数量的具体实现方式，根据应用的配置信息来获取应用CPU核需求数量。且应用中无需独占CPU核的任务则直接交由该应用的部署节点的操作系统来进行调度，让部署节点的操作系统来选择由该部署节点的哪些共享CPU核来处理应用中无需独占CPU核的任务，实现了对该部署节点内共享CPU核的灵活调用。

本发明的第三实施方式涉及一种CPU资源调度方法。第三实施方式是对第一实施方式的改进，主要改进之处在于：本实施方式中提出来一种确定以及转换独占CPU核的具体实现方式。

本实施方式中的一种CPU资源调度方法的具体流程示意图如图3所示，具体包括：

步骤301：将各个节点上的全部CPU核均配置为共享CPU核，并将各个节点的共享CPU核数量作为该节点的可用CPU核数量。

步骤302：接收并解析应用的CPU核需求数量。

步骤303：选取可用CPU核数量大于或等于CPU核需求数量的节点作为部署节点、将执行所述应用的任务部署到部署节点。

上述步骤301至步骤303与第一实施方式中的步骤101及步骤103大致相同，在此不再进行赘述。

步骤304：监控部署节点的应用启动事件及退出事件。若监控到应用的启动事件时，进入步骤305；若监控到退出事件，则进入步骤309。

步骤305：确定与独占CPU需求数量相等的、需要转换为独占CPU核的部署节点的CPU核的ID。

步骤306：根据独占CPU需求数量，确定与独占CPU需求数量相等的、部署节点的共享CPU核的ID作为待转换CPU核的ID。

步骤307：将部署节点上、与待转换CPU核ID对应的共享CPU核转换为独占CPU核。

步骤308：将转换的独占CPU核分配给应用使用。

针对上述步骤305和步骤308具体的说，针对集群中应用启动事件的处理如下：(1)查询应用配置信息，确定应用的独占CPU需求数量，并将无需独占CPU的任务交给操作系统进行调度；(2)确定部署节点中需要转换为独占CPU的CPU核数量、需要转换为独占CPU核的部署节点的CPU核的ID；(3)将部署节点上特定ID的CPU核转换为独占CPU核(数量为该部署节点上应用所需求的独占CPU数量)；(4)将转换的独占CPU核分配给应用使用。

可选地，在上述第(2)步骤中，可以直接将部署节点上负载最轻的共享CPU核的ID作为待转换CPU核的ID。直接由任务最少，负载最轻的共享CPU核来处理该部署节点上应用所需要独占CPU核的任务，提供了CPU转换目标的一种选取策略，不仅提高了调度CPU核的速度，同时也加快了任务的处理效率。

进一步地，将部署节点上、与待转换CPU核ID对应的共享CPU核转换为独占CPU核之后，还包括：将独占CPU核上的负载迁移到其他共享CPU核上。在上述第(3)步骤后，还可以将转换为独占CPU核上之前处理的任务进程迁移到其他共享CPU核上，由其他共享CPU核来进行处理，迁移原本运行在“转换的独占CPU”上的进程/任务，为应用独占CPU做准备，同时使得节点内CPU核的调度更加具备灵活性。

可选地，将转换的独占CPU核信息传递给应用、使用control group确保只有归属的应用可使用转换的独占CPU核，具体包括：根据应用的独占CPU描述，将应用绑定到所述转换的独占CPU核上。具体的，将转换的独占CPU核信息传递给应用，可利用独占CPU核的环境变量或配置文件将转换的独占CPU核信息传递给应用。使用control group(控制组)来确保只有归属的应用可使用转换的独占CPU核。可选地，将应用绑定到转换的独占CPU上，提供了一种使用control group确保CPU独占的具体实现方案，该种实现方式依赖于应用信息中指明的绑定策略。

步骤309：将分配给应用使用的独占CPU核转换为共享CPU核。

具体地说，集群中应用退出事件的处理如下：(1)将分配给应用容器的独占CPU核转换为共享CPU；(2)集群调度器监控下发给节点的任务执行状态，在下发给节点的任务结束(包括正常完成和异常终止)以后，更新集群上对应节点的可用CPU数量。即：节点的可用CPU核数量＝节点当前可用CPU核数量+节点结束任务需求CPU核数量。

下面将结合说明书附图4较为详细的描述在节点上动态将共享CPU核和独占CPU核相互转换的流程：

(1)节点启动时，全部CPU核作为共享CPU核进行调度，并监控系统中/proc目录下特定文件，初始时独占CPU核ID列表为空，获取应用的独占CPU核需求信息；

(2)节点上业务需要独占CPU核时，在系统/proc目录下特定文件中描述需要独占CPU核的ID列表。以一个节点为例，具体的说：根据该节点系统/proc目录下特定文件的需求描述配置proc参数，转化为CPUmask(即独占CPU核的ID掩码)；之后，判断CPUmask是否合法，若合法，则判断CPUmask是否为空，如果为空，则清除排他域(独占CPU核的集合)，之后配置新的排他域(独占CPU核的集合)，重构调度域(共享CPU核的集合)。若不为空，则配置新的排他域(独占CPU核的集合)，重构调度域(共享CPU核的集合)；

(3)系统内核发现更新的独占CPU核ID列表，将列表中对应ID的CPU核在系统中设置为独占CPU核，更新操作系统后便可调度CPU核列表；

(4)将负载最低的CPU核列表的CPU核转换为独占CPU核，更新操作系统后可调度CPU核列表，操作系统将无法继续调度进程到独占CPU核上；

(5)将已经设置为独占CPU核上操作系统调度运行的进程迁移到其他共享CPU核上，以确保独占CPU核空闲，等待应用进程绑定使用；

(6)更新在/proc目录下特定文件中描述已经成功设置为独占CPU核的ID列表信息。

下面举例说明在节点上的独占CPU核转换和隔离策略：

假设Node1节点中包含32个CPU资源，初始阶段全部CPU核配置为共享CPU核。假设应用需要独占CPU核时，优先将共享CPU核ID较大的CPU核转换为独占CPU核。

表12

在初始化节点Node1上部署Container1，则Node1上的CPU布局调整为表13：

表13

对应的Container1在cgroup上的cpuset配置如表14：

表14

	全局共享	应用独占
			Container1	0～～～31

在此基础上在Node1节点上部署Container2，则Node1上的CPU布局调整为表15：表15

对应的在Node1节点上的应用的cgroup的cpuset配置为表16：

表16

	全局共享	应用独占
			Container1	0～～～31
Container2	0～～～31

在此基础上在Node1节点上部署Container3，则Node1上的CPU布局调整为表17：表17

对应的在Node1节点上的应用的cgroup的cpuset配置为表18：

表18

	全局共享	应用独占
			Container1	0～～～30
Container2	0～～～30
			Container3	0～～～30	31

在此基础上在Node1节点上部署Container4，则Node1上的CPU布局调整为表19：

表19

对应的在Node1节点上的应用的配置如表20：

表20

	全局共享	应用独占
			Container1	0～～～22
Container2	0～～～22
			Container3	0～～～22	31
Container4	0～～～22	23～～～30

从以上的分配流程可以看到，节点上的CPU资源根据应用的实际需求在共享CPU和独占CPU之间动态转换。在CPU核转换为独占CPU核以后，需要明确独占CPU核的应用归属，并且通过在control group中的配置，确保独占CPU核只能被归属的应用所使用。

与现有技术相比，本实施方式中提供了一种确定以及转换独占CPU核的具体实现方式，通过CPU核的ID来确定需要转换为独占CPU核的共享CPU核，并利用CPU核的ID来实现共享CPU核到独占CPU核转换以及将转换后的独占CPU核分配给应用使用。同时，直接由任务最少，负载最轻的共享CPU核来处理该部署节点上应用所需要独占CPU核的任务，不仅提高了调度CPU核的速度，同时也加快了任务的处理效率。并且将转换为独占CPU核上之前处理的任务进程迁移到其他共享CPU核上，由其他共享CPU核来进行处理，使得节点内CPU核的调度更加具备灵活性。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明第四实施方式涉及一种电子设备，如图5所示，包括：至少一个处理器501；以及，与至少一个处理器501通信连接的存储器502；其中，存储器502存储有可被至少一个处理器501执行的指令，指令被至少一个处理器501执行，以使至少一个处理器501能够执行上述任一实施方式中的中CPU资源调度方法。

其中，存储器502和处理器501采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器501和存储器502的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器501处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器501。

处理器501负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器502可以被用于存储处理器501在执行操作时所使用的数据。

本发明第五实施方式涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (10)

1.一种CPU资源调度方法，其特征在于，包括：

将各个节点上的全部CPU核均配置为共享CPU核，并将各个节点的共享CPU核数量作为该节点的可用CPU核数量；

接收并解析应用的CPU核需求数量，所述CPU核需求数量包括独占CPU需求数量和共享CPU核需求数量；

选取可用CPU核数量大于或等于所述CPU核需求数量的节点作为部署节点、将执行所述应用的任务部署到所述部署节点；

监控所述部署节点的应用启动事件及退出事件，在监控到所述部署节点的应用启动事件时，从所述部署节点的共享CPU核中选取与所述独占CPU需求数量相等的共享CPU核并转换为独占CPU核、将转换的所述独占CPU核分配给所述应用使用；在监控到所述部署节点的应用退出事件时，将分配给所述应用使用的独占CPU核转换为共享CPU核。

2.根据权利要求1所述的CPU资源调度方法，其特征在于，所述接收并解析应用的CPU核需求数量，具体包括：

查询所述应用的配置信息；

根据所述配置信息确定所述独占CPU需求数量。

3.根据权利要求2所述的CPU资源调度方法，其特征在于，所述查询所述应用的配置信息之后，还包括：

将所述应用中无需独占CPU核的任务交给所述部署节点的操作系统进行调度。

4.根据权利要求1所述的CPU资源调度方法，其特征在于，所述从所述部署节点的共享CPU核中选取与所述独占CPU需求数量相等的共享CPU核并转换为独占CPU核、将转换的所述独占CPU核分配给所述应用使用，具体包括：

确定与所述独占CPU需求数量相等的、需要转换为独占CPU核的所述部署节点的CPU核的ID；

根据所述独占CPU需求数量，确定与所述独占CPU需求数量相等的、所述部署节点的共享CPU核的ID作为待转换CPU核的ID；

将所述部署节点上、与所述待转换CPU核ID对应的共享CPU核转换为独占CPU核；

将转换的所述独占CPU核分配给所述应用使用。

5.根据权利要求4所述的CPU资源调度方法，其特征在于，所述根据所述独占CPU需求数量，确定与所述独占CPU需求数量相等的、所述部署节点的共享CPU核的ID作为待转换CPU核的ID，具体包括：

将所述部署节点上负载最轻的共享CPU核的ID作为所述待转换CPU核的ID。

6.根据权利要求4所述的CPU资源调度方法，其特征在于，所述将所述部署节点上、与所述待转换CPU核ID对应的共享CPU核转换为独占CPU核之后，还包括：

将独占CPU核上的负载迁移到所述部署节点的其他共享CPU核上。

7.根据权利要求4所述的CPU资源调度方法，其特征在于，所述将转换的所述独占CPU核分配给所述应用使用，具体包括：

将转换的独占CPU核信息传递给所述应用、使用control group确保只有归属的所述应用可使用所述转换的独占CPU核，由所述应用自主决定如何使用所述转换的独占CPU核的资源。

8.根据权利要求1所述的CPU资源调度方法，其特征在于，所述将执行所述应用的任务部署到所述部署节点之后，还包括：更新所述部署节点的可用CPU核数量。

9.根据权利要求8所述的CPU资源调度方法，其特征在于，所述将执行所述应用的任务部署到所述部署节点之后，还包括：

监控所述部署节点的任务执行状态，并在所述部署节点的任务执行完成或任务执行异常终止之后，更新所述部署节点的可用CPU核数量。

10.一种电子设备，包括至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；

其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行以实现如上述权利要求1至9中任一项所述的CPU资源调度方法。

Images