在集群中调度作业的方法、装置、设备及存储介质与流程

文档序号:16467342发布日期:2019-01-02 22:51阅读:181来源:国知局
本发明涉及作业调度领域,具体涉及在集群中调度作业的方法、装置、设备及存储介质。
背景技术
::利用多台物理机组成集群,在其上部署服务是互联网企业实现项目的常用手段,因此,如何对集群上服务的各类作业进行合理调度一直是技术人员不断研究的问题。以深度学习项目为例,技术人员往往希望同一基础架构平台上运行项目的所有部分,而深度学习的样本数据往往来自于业务线的产品,即需要在同一集群中共同调度多类型的作业。然而,现有的调度框架并不能很好地实现这一点。技术实现要素:有鉴于此,本发明提供了在集群中调度作业的方法、装置、设备及存储介质,以解决在同一集群中调度不同应用或服务的作业的问题。具体技术方案如下:一种在集群中调度作业的方法,包括:获取与作业对应的容器荚pod数据;根据所述pod数据中的节点调度条件与所述集群中各节点的节点状态,从所述集群中选出一个或多个目标节点;在各目标节点上根据所述pod数据分别部署pod,在部署的pod中运行所述作业的作业进程。可选地,所述节点调度条件包括硬性调度条件和/或软性调度条件;所述根据所述pod数据中的节点调度属性与所述集群中各节点的节点状态,从所述集群中选出一个或多个目标节点包括:若一个节点的节点状态满足所述硬性调度条件,则属于目标节点;和/或,根据各节点的节点状态和所述软性调度条件进行调度评分,根据评分结果选出一个或多个目标节点。可选地,所述硬性调度条件包括节点的硬件信息和/或节点的区域信息。可选地,所述根据所述pod数据中的节点调度条件与所述集群中各节点的节点状态,从所述集群中选出一个或多个目标节点包括:选出位于同一个可用区上的多个节点作为目标节点;所述在各目标节点上根据所述pod数据分别部署pod包括:在各目标节点上根据所述pod数据分别部署一个pod,以形成所述作业的多个实例。可选地,所述节点调度条件还包括实例数量下限和实例数量上限;所述选出位于同一个可用区上的多个节点作为目标节点还包括:当选出的节点数量大于或等于所述实例数量下限时,根据所述选出的节点数量和所述实例数量上限确定二者中一个较小的值作为目标节点的数量;当选出的节点数量小于所述实例数量下限时,终止本次作业调度。可选地,所述软性调度条件包括作业亲和条件,所述节点状态包括在本节点上部署的各pod对应的作业。可选地,所述作业对应于如下的一种或多种应用和/或服务:深度学习系统,web服务,日志采集器,分布式队列服务,日志连接器。可选地,所述作业是深度学习训练作业,所述在部署的pod中运行所述作业的作业进程包括:在部署的pod中运行一个参数服务器进程和一个训练器进程,由所述训练器进程从深度学习的元信息管理节点获取深度学习任务,根据本地的深度学习训练模型训练得到梯度后发送给所述参数服务器进程,以及从所述参数服务器进程获取更新后的参数;所述参数服务器进程按预定间隔在分布式存储中保存训练快照,以在pod或pod中的进程重新启动根据所述训练快照恢复训练;所述参数服务器进程和/或所述训练器进程将深度学习训练模型存储至分布式存储。可选地,所述节点调度条件包括与各计算资源分别对应的资源请求下限和资源请求上限;所述根据所述pod数据中的节点调度条件与所述集群中各节点的节点状态,从所述集群中选出一个或多个目标节点包括:根据各节点中已部署的pod计算各计算资源的可调度资源上限和可调度资源下限;当所述节点调度条件中的各计算资源的资源请求下限均小于或等于相应计算资源的可调度资源下限时,从所述集群中选出一个或多个目标节点。可选地,所述节点调度条件还包括作业优先级;所述根据所述pod数据中的节点调度条件与所述集群中各节点的节点状态,从所述集群中选出一个或多个目标节点还包括:当所述节点调度条件中的资源请求下限大于所述可调度资源下限时,按照作业优先级杀掉或阻塞已部署的pod,或者,终止本次作业调度。可选地,所述杀掉或阻塞pod包括:当所述节点调度条件对应的是可压缩资源时,阻塞pod;当所述节点调度条件对应的是不可压缩资源时,杀掉pod。可选地,该方法还包括:按节点调度条件为各节点上已部署的pod分配计算资源;其中,若一个节点中已部署的各pod的可压缩资源的资源请求上限之和小于该节点可压缩资源的上限,则将未被分配的可压缩资源按比例分配给该节点上已部署的各pod。可选地,该方法还包括:计算各作业进程的内存占用分,在计算得到的内存占用分达到与该作业进程对应的预设值时杀死该作业进程。可选地,该方法还包括:获取基于同一pod数据部署的各pod的cpu利用率,根据cpu利用率的算术平均值与所述pod数据中的节点调度条件计算调整后的pod数量。可选地,该方法还包括:监听所述集群中是否有未被成功调度的pod,是则进一步判断是否有可扩容的节点;是则启动至少部分可扩容的节点,将未被成功调度的pod调度至新启动的节点上。可选地,该方法还包括:根据各节点的节点状态判断节点是否满足缩容条件,是则关闭相应的节点,在相应的节点上已部署了pod时将已部署的pod调度至集群中的其他节点。可选地,所述缩容条件包括如下的一种或多种:节点的计算资源利用率小于预设值;节点中部署的pod均可被调度至集群中的其他节点;节点中部署的pod均依照poddisruptionbudget控制器被确定为可被漂移;节点没有本地存储。可选地,依据如下的一种或多种策略进行集群的扩容和/或缩容:随机选择节点;根据已部署的pod数量选择节点;根据计算资源利用率选择节点;根据物理机的使用价格选择节点;在集群中有预设数量和/或预设比例的节点发生异常时,暂停扩容和/或缩容。一种在集群中调度作业的装置,其特征在于,该装置包括:pod数据获取单元,用于获取与作业对应的容器荚pod数据;调度单元,用于根据所述pod数据中的节点调度条件与所述集群中各节点的节点状态,从所述集群中选出一个或多个目标节点;pod部署单元,用于在各目标节点上根据所述pod数据分别部署pod,在部署的pod中运行所述作业的作业进程。可选地,所述节点调度条件包括硬性调度条件和/或软性调度条件;所述调度单元,用于若一个节点的节点状态满足所述硬性调度条件,则属于目标节点;和/或,根据各节点的节点状态和所述软性调度条件进行调度评分,根据评分结果选出一个或多个目标节点。可选地,所述硬性调度条件包括节点的硬件信息和/或节点的区域信息。可选地,所述调度单元,用于选出位于同一个可用区上的多个节点作为目标节点;所述pod部署单元,用于在各目标节点上根据所述pod数据分别部署一个pod,以形成所述作业的多个实例。可选地,所述节点调度条件还包括实例数量下限和实例数量上限;所述调度单元,用于当选出的节点数量大于或等于所述实例数量下限时,根据所述选出的节点数量和所述实例数量上限确定二者中一个较小的值作为目标节点的数量;当选出的节点数量小于所述实例数量下限时,终止本次作业调度。可选地,所述软性调度条件包括作业亲和条件,所述节点状态包括在本节点上部署的各pod对应的作业。可选地,所述作业对应于如下的一种或多种应用和/或服务:深度学习系统,web服务,日志采集器,分布式队列服务,日志连接器。可选地,所述作业是深度学习训练作业;所述部署单元,用于在部署的pod中运行一个参数服务器进程和一个训练器进程,由所述训练器进程从深度学习的元信息管理节点获取深度学习任务,根据本地的深度学习训练模型训练得到梯度后发送给所述参数服务器进程,以及从所述参数服务器进程获取更新后的参数;所述参数服务器进程按预定间隔在分布式存储中保存训练快照,以在pod或pod中的进程重新启动根据所述训练快照恢复训练;所述参数服务器进程和/或所述训练器进程将深度学习训练模型存储至分布式存储。可选地,所述节点调度条件包括与各计算资源分别对应的资源请求下限和资源请求上限;所述调度单元,用于根据各节点中已部署的pod计算各计算资源的可调度资源上限和可调度资源下限;当所述节点调度条件中的各计算资源的资源请求下限均小于或等于相应计算资源的可调度资源下限时,从所述集群中选出一个或多个目标节点。可选地,所述节点调度条件还包括作业优先级;所述调度单元,用于当所述节点调度条件中的资源请求下限大于所述可调度资源下限时,按照作业优先级杀掉或阻塞已部署的pod,或者,终止本次作业调度。可选地,所述调度单元,用于当所述节点调度条件对应的是可压缩资源时,阻塞pod;当所述节点调度条件对应的是不可压缩资源时,杀掉pod。可选地,所述调度单元,还用于按节点调度条件为各节点上已部署的pod分配计算资源;其中,若一个节点中已部署的各pod的可压缩资源的资源请求上限之和小于该节点可压缩资源的上限,则将未被分配的可压缩资源按比例分配给该节点上已部署的各pod。可选地,所述调度单元,还用于计算各作业进程的内存占用分,在计算得到的内存占用分达到与该作业进程对应的预设值时杀死该作业进程。可选地,所述调度单元,用于获取基于同一pod数据部署的各pod的cpu利用率,根据cpu利用率的算术平均值与所述pod数据中的节点调度条件计算调整后的pod数量。可选地,所述调度单元,还用于监听所述集群中是否有未被成功调度的pod,是则进一步判断是否有可扩容的节点;是则启动至少部分可扩容的节点,将未被成功调度的pod调度至新启动的节点上。可选地,所述调度单元,用于根据各节点的节点状态判断节点是否满足缩容条件,是则关闭相应的节点,在相应的节点上已部署了pod时将已部署的pod调度至集群中的其他节点。可选地,所述缩容条件包括如下的一种或多种:节点的计算资源利用率小于预设值;节点中部署的pod均可被调度至集群中的其他节点;节点中部署的pod均依照poddisruptionbudget控制器被确定为可被漂移;节点没有本地存储。可选地,所述调度单元,用于依据如下的一种或多种策略进行集群的扩容和/或缩容:随机选择节点;根据已部署的pod数量选择节点;根据计算资源利用率选择节点;根据物理机的使用价格选择节点;在集群中有预设数量和/或预设比例的节点发生异常时,暂停扩容和/或缩容。一种计算机设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述处理器执行所述程序时实现如以上所述的方法。一种计算机可读存储介质,其上存储有计算机程序,所述程序被处理器执行时实现如以上所述的方法。基于上述介绍可以看出,采用本发明所述方案,在获取到与作业对应的容器荚pod数据后,根据其中的节点调度条件和集群中各节点的节点状态,从集群中选出若干个目标节点,并进一步在各目标节点上根据pod数据分别部署pod,在部署的pod中运行所述作业的作业进程。该技术方案采用容器化的方式部署作业进程,使得不同作业可以部署在各个独立的容器中,从而使得集群上各应用的作业可以互不影响,又能够在需要交互的场景进行通信,实现了集群资源的有效利用,对于深度学习等需要多应用管道化协作的项目能够实现稳定的作业调度。【附图说明】图1示出了根据本发明一个实施例的一种在集群中调度作业的方法的流程示意图。图2示出了根据本发明一个实施例的一种在集群中调度作业的装置的结构示意图。图3示出了根据本发明一个实施例的一种深度学习系统架构示意图。图4示出了适于用来实现本发明实施方式的示例性计算机系统/服务器12的框图。【具体实施方式】为了使本发明的技术方案更加清楚、明白,以下参照附图并举实施例,对本发明所述方案进行进一步说明。显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域技术人员在没有作出创造性劳动前提下所获得的所有其它实施例,都属于本发明保护的范围。图1示出了根据本发明一个实施例的一种在集群中调度作业的方法的流程示意图。如图1所示,该方法包括:步骤s110,获取与作业对应的容器荚pod数据。容器(container)可以提供独立的运行环境,这一点和虚拟机相类似。然而在本发明的实施例中采用了容器化的思路部署作业进程,而非采用虚拟机,这是因为容器更为轻量,效率和利用率都远远高于虚拟机。容器荚pod是一个或多个容器的集合,一般而言包括一个根容器,以及运行作业进程的各容器。在本发明的实施例中,一个pod可以对应于作业的一个或多个实例,但一般而言不会利用pod实现多个实例。pod数据可以保存在etcd上,etcd是一个键值存储仓库,用于配置共享和服务发现。新作业的pod数据和被杀死的pod的pod数据都可以保存在etcd上,在调度相应的作业时进行获取。具体来说,可以根据用户提交的作业请求生成pod数据。步骤s120,根据pod数据中的节点调度条件与集群中各节点的节点状态,从集群中选出一个或多个目标节点。这里,节点调度条件可以有很多,具体的描述形式可以是标签(label),同样,节点状态也可以以label形式描述。lablel是一个key-value的键值对,其中key与value由用户自己指定。可以附加到各种资源对象上,一个资源对象可以定义任意数量的label,可以通过labelselector(标签选择器)查询和筛选资源对象。步骤s130,在各目标节点上根据pod数据分别部署pod,在部署的pod中运行作业的作业进程。可见,图1所示的方法,在获取到与作业对应的容器荚pod数据后,根据其中的节点调度条件和集群中各节点的节点状态,从集群中选出若干个目标节点,并进一步在各目标节点上根据pod数据分别部署pod,在部署的pod中运行作业的作业进程。该技术方案采用容器化的方式部署作业进程,使得不同作业可以部署在各个独立的容器中,从而使得集群上各应用的作业可以互不影响,又能够在需要交互的场景进行通信,实现了集群资源的有效利用,对于深度学习等需要多应用管道化协作的项目能够实现稳定的作业调度。在本发明的一个实施例中,上述方法中,节点调度条件包括硬性调度条件和/或软性调度条件;根据pod数据中的节点调度属性与集群中各节点的节点状态,从集群中选出一个或多个目标节点包括:若一个节点的节点状态满足硬性调度条件,则属于目标节点;和/或,根据各节点的节点状态和软性调度条件进行调度评分,根据评分结果选出一个或多个目标节点。可以看出,硬性调度条件是较为严格的要求。举例而言,在本发明的一个实施例中,上述方法中,硬性调度条件包括节点的硬件信息和/或节点的区域信息。在一个示例中,用户希望某作业仅部署在cpu型号为intel的节点上,显然,这是一个节点的硬件信息。在另一个示例中,用户希望某作业部署在区域a的节点上,则这是一个节点的区域信息。总结地说,当一个作业的硬性调度条件中各项的集合是一个节点的节点状态中各项的集合的子集时,那么这个节点就是选出的目标节点。具体地也可以以标签形式标注硬性调度条件和节点状态,则可以采用nodeselector(节点选择器)的方式实现。硬性调度条件可以帮助快速筛选出可用的节点,然而这样也容易造成无节点可用的情况。因此对于那些需求不那么苛刻的作业,还可以设置软性调度条件,级根据各节点的节点状态和软性调度条件进行调度评分,根据评分结果选出一个或多个目标节点。这样,由于不再是严格匹配,则可以优先选出与作业亲和度最高而不是完美亲和的节点。在本发明的一个实施例中,上述方法中,根据pod数据中的节点调度条件与集群中各节点的节点状态,从集群中选出一个或多个目标节点包括:选出位于同一个可用区上的多个节点作为目标节点;在各目标节点上根据pod数据分别部署pod包括:在各目标节点上根据pod数据分别部署一个pod,以形成作业的多个实例。在本实施例中提供了一种作业调度思路,即在az(availabilityzone,可用区)中部署作业(这里的作业意味着应用或是服务,例如日志采集器)的多个实例(即pod),即单应用在az级别各实例亲和。可用区是指电力、网络等基础设施相互隔离的一个或多个数据中心。一个区域包含一个或多个可用区,当一个可用区出现故障后,不会影响其他可用区的使用。而在az中的各目标节点上则是分别部署一个实例,也就意味着一个节点不会部署两个实例,这样当一个节点故障时,也仅会影响一个实例。一种思路是在机框(机柜)级别做反亲和,因为有可能一个机框都会故障。但本质上它们都是节点上的一个标签,调度时只需要按这个特殊的标签进行动态分组,处理亲和与反亲和的关系即可。在本发明的一个实施例中,上述方法中,节点调度条件还包括实例数量下限和实例数量上限;选出位于同一个可用区上的多个节点作为目标节点还包括:当选出的节点数量大于或等于实例数量下限时,根据选出的节点数量和实例数量上限确定二者中一个较小的值作为目标节点的数量;当选出的节点数量小于实例数量下限时,终止本次作业调度。这是许多调度框架如slurm无法解决的问题。在这里简单介绍一下:slurm任务调度工具(前身为极简linux资源管理工具,英文:simplelinuxutilityforresourcemanagement,取首字母,简写为slurm),或slurm,是一个用于linux和unix内核系统的免费、开源的任务调度工具,被世界范围内的超级计算机和计算机群广泛采用。它提供了三个关键功能。第一,为用户分配一定时间的专享或非专享的资源(计算机节点),以供用户执行工作。第二,它提供了一个框架,用于启动、执行、监测在节点上运行着的任务(通常是并行的任务,例如mpi),第三,为任务队列合理地分配资源。大约60%的500强超级计算机上都运行着slurm,包括2016年前世界上最快的计算机天河-2。slurm使用基于hilbert曲线调度或肥胖网络拓扑结构的最适算法,以便优化并行计算机中的任务分配。mpi是一个跨语言的通讯协议,用于编写并行计算机。支持点对点和广播。mpi是一个信息传递应用程序接口,包括协议和和语义说明,他们指明其如何在各种实现中发挥其特性。mpi的目标是高性能,大规模性,和可移植性。mpi在今天仍为高性能计算的主要模型。主要的mpi-1模型不包括共享内存概念,mpi-2只有有限的分布共享内存概念。但是mpi程序经常在共享内存的机器上运行。在mpi模型周边设计程序比在numa架构下设计要好因为mpi鼓励内存本地化。尽管mpi属于osi参考模型的第五层或者更高,他的实现可能通过传输层的sockets和transmissioncontrolprotocol(tcp)覆盖大部分的层。大部分的mpi实现由一些指定惯例集(api)组成,可由c,c++,fortran,或者有此类库的语言比如c#,javaorpython直接调用。mpi优于老式信息传递库是因为他的可移植性和速度。然而,使用slrum或mpi框架时,在有99个可用节点和需要100个提交作业的例子中,作业必须等待而不使用任何可用节点。或者如果集群中出现错误,则整个任务会被标记成失败,从而浪费大量集群资源。显然根据本实施例则不会出现这样的问题,由于设置了实例数量下限和实例数量上限(也可以称为副本数,因为是根据同一个pod数据实现的),那么如果设置提交作业的副本数在80~100,则实例数量下限为80,那么99个可用节点显然是满足需求的。那么作业可以被调度到这99个可用节点上。在本发明的一个实施例中,上述方法中,软性调度条件包括作业亲和条件,节点状态包括在本节点上部署的各pod对应的作业。本实施例给出了一种软性调度条件的示例,即作业亲和条件,也可以称为应用亲和条件。例如,业务与监控日志处理和本地数据对应的作业亲和度较高,如果他们所在的pod距离较远,那么访问的网络开销就会造成效率低下的问题。因此在本实施例中实际上是提供了亲和应用的就近部署,例如部署在同一节点中,自然就减少了网络开销。亲和是一个相互的行为,因此,每个与其他作业可能亲和的作业都需要以作业亲和条件(也可以是标签)标注自己亲和/反亲和哪些作业,在pod部署时就会进行检查,实现对称性。另外一个常见的问题是被亲和的应用发生迁移的情况。需要说明的有两点,一是在算法设计上做了对称性的考虑,不管是先部署还是后部署,即便这个应用挂了,它在重建并被调度时,依然会检查当前系统里亲和哪些pod或者被哪些pod亲和,优先跟他们部到一起去。另外,目前rc/rs(副本集无状态应用)只有节点挂掉的时候才会发生重建pod的情况,节点没有挂,异常退出是在原地自己重启的。这个从两个层面上,能够保证亲和的应用部在一起、反亲和的应用分开这种需求。在本发明的一个实施例中,上述方法中,作业对应于如下的一种或多种应用和/或服务:深度学习系统,web服务,日志采集器,分布式队列服务,日志连接器。这样的深度学习项目可以用于人工智能(ai)的研究,满足工业需求。工业用户倾向于将深度学习作业作为完整数据管道的子集阶段,包括web服务器和日志采集器。这种通用集群需要基于优先级的弹性调度。这使得在web服务器作业中运行更多的进程成为可能,而在网络流量较高的时间段内深度学习则更少,然后在网络流量较低时优先进行深度学习。在这点上slurm或者mpi无法满足灵活调度的诉求。深度学习训练框架本身需要被设计成支持分布式训练。深度学习集群中有三个角色:参数服务器(parameterserver)和训练器(trainer)以及元信息管理节点(master)。每个参数服务器进程都维护全局模型(globalmodel)的分片(shard)。每个训练器都有其本地模型(localmodel)副本,并使用其本地数据更新模型。在培训过程中,训练器将模型更新发送给参数服务器,参数服务器负责汇总这些更新,以便训练器可以将其本地副本与全局模型同步。集群训练包含以下几个模块:单个元信息管理节点,负责分发任务(task),将数据集(dataset)分成任务分发到各个训练器中,通过使用任务队列(taskqueue)来保持训练任务的可追溯性;多个训练器,负责通过sgd(随机梯度下降)训练模型,即接受master的任务、处理任务,计算并上传梯度(gradient)到参数服务器,同时下载最新的梯度(也可以称为参数、模型)到自己的本地模型;多个参数服务器,负责存储更新训练模型,具体来说,从训练器处获得梯度,更新参数,返回给训练器最新的参数;定期将参数存储到分布式文件系统或etcd,覆盖原有参数。具体的训练架构可以参见图3。图3中深度学习模型被分割成两个分片,分别由两台参数服务器管理。master启动时,拿一个master锁,查看要创建的taskqueue是否已经存在,如果已经存在,就恢复该taskqueue,如果不存在,则创建。监听/trainer/目录,去寻找存在的trainer,分发task给存在的trainer,并且与此同时更新taskqueue。master故障恢复时,自动重启master,并从etcd中恢复对应的数据。trainer启动时,监听parameterserver相关的目录/ps/,等待parameterserver到达指定的数量。生成一个唯一id,写在etcd下,/trainer/,由于有lease的原因,master可以知道trainer在线上还是在线下,等待task被分配过来。trainer故障恢复时,会自动重启trainer,并从todoqueue(待处理队列)中拉取task,并继续训练。parameterserver启动时,读取parameterserver目标总数,搜索etcdkey是/ps/的,index(索引)小于目标总数,看看有哪一个不存在的key,如果有,就补充进去。parameterserver可以读取存储在该路径下的数据,并存储到内存中,然后开始对外提供服务。在本发明的一个实施例中,上述方法中,作业是深度学习训练作业,在部署的pod中运行作业的作业进程包括:在部署的pod中运行一个参数服务器进程和一个训练器进程,由训练器进程从深度学习的元信息管理节点获取深度学习任务,根据本地的深度学习训练模型训练得到梯度后发送给参数服务器进程,以及从参数服务器进程获取更新后的参数;参数服务器进程按预定间隔在分布式存储中保存训练快照,以在pod或pod中的进程重新启动根据训练快照恢复训练;参数服务器进程和/或训练器进程将深度学习训练模型存储至分布式存储。模型数据检查点的实现,可以有效的避免参数服务器的单点或多点同时故障。模型参数检查点通过定期向磁盘上保存一份存储在参数服务器内存中的模型数据的完整镜像,来保证训练过程可以从中间状态重新启动。在一个不可中断并缺少备份的训练任务中,可以通过阶段性的保存每个参数服务器的数据快照(snapshot)到分布式存储服务达到容灾的目的,比如每隔10分钟最新的快照,并删除更早的快照。在出现单点故障时,只需要恢复这台节点,或者将这台节点迁移到另一个节点并启动即可恢复训练任务。例如,利用锁(lock)机制实现,每10分钟,参数服务器会去申请读锁(readlock),保存检查点。而在同时,该参数服务器会停止写操作,等待保存检查点完成。之后参数服务器在分布式存储中写入当前快照,并删除原有的其他快照,操作完成后,释放readlock,写操作可以继续进行。快照读取时,从etcd中读取检查点文件标识uuid,从磁盘中加载检查点快照文件,并加载其中参数。如果加载不成功,则使用原始数据初始化参数。具体实现可以采用公有云bosfs文件系统实现数据的共享存储,也可以采用公有云最新的nfs存储系统。数据会统一转换成recordio接口,提供标准化转换接口。模型的存储有两种选择,即参数服务器进程和/或训练器进程将深度学习训练模型存储至分布式存储。由于目前参数服务器中的数据是分片的,而训练器中模型是是稠密更新的,所以其拥有整个模型,故而在易用性方面可以优选训练器来存储模型。具体地,训练器通过etcd来做选举,来选出其中一个节点作为模型的存储输出。在本发明的一个实施例中,上述方法中,节点调度条件包括与各计算资源分别对应的资源请求下限和资源请求上限;根据pod数据中的节点调度条件与集群中各节点的节点状态,从集群中选出一个或多个目标节点包括:根据各节点中已部署的pod计算各计算资源的可调度资源上限和可调度资源下限;当节点调度条件中的各计算资源的资源请求下限均小于或等于相应计算资源的可调度资源下限时,从集群中选出一个或多个目标节点。本实施例提供了一种基于资源的调度方式,即pod可以针对cpu、内存设置请求条件,具体包括一个资源请求上限和一个资源请求下限。对于每一种资源,0<=资源请求下限<=资源请求上限<=无穷。如果容器被成功调度至节点,容器的资源请求是能够保证的。那么,整个集群可以维护并计算出各计算资源的可调度资源上限和可调度资源下限,如果节点调度条件中的各计算资源的资源请求下限均小于或等于相应计算资源的可调度资源下限时,显然资源是足够的。例如,pod要求1024mb的内存下限,也就是如果不被提供1024mb的内存,则作业无法进行,而如果此时节点可以提供2048mb的内存作为可调度资源下限,显然该作业可以被调度到该节点上。在本发明的一个实施例中,上述方法中,节点调度条件还包括作业优先级;根据pod数据中的节点调度条件与集群中各节点的节点状态,从集群中选出一个或多个目标节点还包括:当节点调度条件中的资源请求下限大于可调度资源下限时,按照作业优先级杀掉或阻塞已部署的pod,或者,终止本次作业调度。可以分为按服务质量管理(qos)分为三个优先级:best-effort(最佳适应级别),即节点调度条件中不写明资源请求下限和资源请求上限,这样资源充足时可以利用最多的资源(例如深度学习训练作业可以被设置为这一优先级,在夜晚业务流量小的情况下占用尽可能多的资源进行训练),但是资源紧张时也会被最先被杀死(例如白天业务流量较大时需要优先保证业务的稳定);burstable(不稳定级别),对应的pod中只要有一个容器的资源请求下限、资源请求上限对其他容器设置的不一致,那么这个pod的qos就是burstable级别。guaranteed(保障级别),所有容器都必须统一设置了资源请求下限、资源请求上限,并且设置参数都一致。在本发明的一个实施例中,上述方法中,杀掉或阻塞pod包括:当节点调度条件对应的是可压缩资源时,阻塞pod;当节点调度条件对应的是不可压缩资源时,杀掉pod。这里根据计算资源的性质,由于内存被占用需要被释放,因此属于不可压缩资源,而cpu则可以动态调整使用情况,属于可压缩资源。因此相应的处理也不同。在本发明的一个实施例中,上述方法还包括:按节点调度条件为各节点上已部署的pod分配计算资源;其中,若一个节点中已部署的各pod的可压缩资源的资源请求上限之和小于该节点可压缩资源的上限,则将未被分配的可压缩资源按比例分配给该节点上已部署的各pod。最小的cpu资源限制为10m。这是linux内核限制决定的。容器能够获得要求的cpu量,能否获得额外的cpu时间取决于其它运行的任务。除了请求的cpu数量,额外的cpu资源是共享的。比如说,假定a容器指定需要cpu的60%,b容器请求cpu的30%,假设两个容器都尽可能多地使用cpu资源,那额外的10%的cpu资源将按照2:1的比例分别分配给容器a与容器b。容器资源使用超过资源限制就会被阻塞,如果没有指定资源限制,当有cpu资源可以使用时,容器就可以使用额外的cpu。容器可以获得请求的内存资源量,如果超出内存资源请求,容器会被杀掉(当其它容器需要内存时),但是如果容器消耗的资源小于资源请求下限的资源量,将不会被杀掉(除非系统任务或者守护进程需要更多的内存)。在容器内存使用量超过内存资源请求上限时,容器会被杀掉。在本发明的一个实施例中,上述方法还包括:计算各作业进程的内存占用分,在计算得到的内存占用分达到与该作业进程对应的预设值时杀死该作业进程。在本实施例中内存占用分也称为oom(outofmemory)得分。进程的oom得分是进程消耗的内存的百分比的10倍,由oom_score_adj(预设值)调整,杀死具有较高oom分数的进程。基本oom分数在0和1000之间,进程的最终oom得分也在0和1000之间。下面给出了三个优先级的oom_score_adj设置示例:best-effort-设置oom_score_adj:1000-容器中的进程的oom_score将为1000;guaranteed-设置oom_score_adj:-998-容器中的进程的oom_score为0或1;burstable-将oom_score_adj设置为1000-10*(资源请求下限的内存的所占整个节点内存的百分比),这确保burstable副本的oom_score>1。如果内存请求为0,oom_score_adj被设置为999。在本发明的一个实施例中,上述方法还包括:获取基于同一pod数据部署的各pod的cpu利用率,根据cpu利用率的算术平均值与pod数据中的节点调度条件计算调整后的pod数量。这也称为实例或是副本的水平自动伸缩(实际也是pod)。自动调节器(autoscaler)具体实现为控制回路,定期通过查询节点状态收集pod的副本的cpu利用率。然后,它将副本的cpu利用率的算术平均值与节点调度条件中定义的目标进行比较,并根据需要调整规模的副本数量以匹配目标。保留条件:minreplicas(实例数量下限)<=replicas(实例数)<=maxreplicas(实例数量上限)。自动调节器的周期由控制器管理器的—horizontal-pod-autoscaler-sync-period标志控制。默认值为30秒。cpu利用率是一个副本的最近cpu使用率(最后1分钟的平均值)除以该pod请求的cpu。目标数量的pod由以下公式计算:targetnumofpods=ceil(sum(currentpodscpuutilization)/target),ceil()为取整操作,表示取大于或等于某数的最近一个整数;sum为算术求和操作;currentpodscpuutilization为最近一分钟内某个pod的cpu使用率/量的平均值;target为cpu的资源请求上限。启动和停止窗口期内可能会对度量带来噪音(例如,启动可能会临时增加cpu)。因此,在每个动作之后,自动调节器应该等待一段时间以获得可靠的数据。只有在过去3分钟内没有重新缩放时,才能进行放大。缩小将从上次重新缩放到等待5分钟。此外,只有当副本的cpu利用率的算术平均值与资源请求下限的比值下降到低于0.9或增加到高于1.1(10%容差)时,才进行任何缩放。这种方法有两个好处:一方面,自动调节器以保守的方式工作。如果出现新用户负载,对我们来说重要的是快速增加pod的数量,以便不会拒绝用户请求,而降低pod的数量不是那么紧急。另一方面,自动调节器需要避免抖动:如果负载不稳定,阻止快速执行冲突决策。在本发明的一个实施例中,上述方法还包括:监听集群中是否有未被成功调度的pod,是则进一步判断是否有可扩容的节点;是则启动至少部分可扩容的节点,将未被成功调度的pod调度至新启动的节点上。该实施例为未被成功调度的pod提供了一种解决思路,即通过对集群中节点的扩容来满足需求,因为集群中的节点并不一定都处于启动状态。例如,采用扩容组件来实现,扩容组件创建一个对所有pod的监听,它每隔10秒会检查是否有无法被调度的pod,pod一般由于没有能调度的节点而会陷入无法被调度的状态。无法被调度的pod会被监听到他们的podcondition(状态)为unscheduled(未被调度的)。如果有这个情况出现,扩容组件会为其找一个新的节点来调度。也会确保该pod所在的副本集中所有的pod处于同一个节点组中,这样新建的机器类型可以和该节点组中的其他机器保持一致。从另一方面进行考虑,在本发明的一个实施例中,上述方法还包括:根据各节点的节点状态判断节点是否满足缩容条件,是则关闭相应的节点,在相应的节点上已部署了pod时将已部署的pod调度至集群中的其他节点。也就是避免了资源的浪费。例如,采用缩容组件来实现,每10秒缩容组件会查看是否有合适的节点能被删除。在本发明的一个实施例中,上述方法中,缩容条件包括如下的一种或多种:节点的计算资源利用率小于预设值;节点中部署的pod均可被调度至集群中的其他节点;节点中部署的pod均依照poddisruptionbudget控制器被确定为可被漂移;节点没有本地存储。在本发明的一个实施例中,上述方法中,依据如下的一种或多种策略进行集群的扩容和/或缩容:随机选择节点;根据已部署的pod数量选择节点;根据计算资源利用率选择节点;根据物理机的使用价格选择节点;在集群中有预设数量和/或预设比例的节点发生异常时,暂停扩容和/或缩容。例如为了防止出现网络或其他问题而导致的大规模节点不可用导致pod无法部署,从而创建更多不可用节点的雪崩情况,可以制定一定的规则。例如设置在30%的节点,或最大3个节点发生异常时,暂停扩缩容功能,直到集群节点整体恢复。图2示出了根据本发明一个实施例的一种在集群中调度作业的装置的结构示意图。如图2所示,在集群中调度作业的装置200包括:pod数据获取单元210,用于获取与作业对应的容器荚pod数据。调度单元220,用于根据pod数据中的节点调度条件与集群中各节点的节点状态,从集群中选出一个或多个目标节点。pod部署单元230,用于在各目标节点上根据pod数据分别部署pod,在部署的pod中运行作业的作业进程。可见,图2所示的装置,在获取到与作业对应的容器荚pod数据后,根据其中的节点调度条件和集群中各节点的节点状态,从集群中选出若干个目标节点,并进一步在各目标节点上根据pod数据分别部署pod,在部署的pod中运行作业的作业进程。该技术方案采用容器化的方式部署作业进程,使得不同作业可以部署在各个独立的容器中,从而使得集群上各应用的作业可以互不影响,又能够在需要交互的场景进行通信,实现了集群资源的有效利用,对于深度学习等需要多应用管道化协作的项目能够实现稳定的作业调度。在本发明的一个实施例中,上述装置中,节点调度条件包括硬性调度条件和/或软性调度条件;调度单元220,用于若一个节点的节点状态满足硬性调度条件,则属于目标节点;和/或,根据各节点的节点状态和软性调度条件进行调度评分,根据评分结果选出一个或多个目标节点。在本发明的一个实施例中,上述装置中,硬性调度条件包括节点的硬件信息和/或节点的区域信息。在本发明的一个实施例中,上述装置中,调度单元220,用于选出位于同一个可用区上的多个节点作为目标节点;pod部署单元230,用于在各目标节点上根据pod数据分别部署一个pod,以形成作业的多个实例。在本发明的一个实施例中,上述装置中,节点调度条件还包括实例数量下限和实例数量上限;调度单元220,用于当选出的节点数量大于或等于实例数量下限时,根据选出的节点数量和实例数量上限确定二者中一个较小的值作为目标节点的数量;当选出的节点数量小于实例数量下限时,终止本次作业调度。在本发明的一个实施例中,上述装置中,软性调度条件包括作业亲和条件,节点状态包括在本节点上部署的各pod对应的作业。在本发明的一个实施例中,上述装置中,作业对应于如下的一种或多种应用和/或服务:深度学习系统,web服务,日志采集器,分布式队列服务,日志连接器。在本发明的一个实施例中,上述装置中,作业是深度学习训练作业;部署单元,用于在部署的pod中运行一个参数服务器进程和一个训练器进程,由训练器进程从深度学习的元信息管理节点获取深度学习任务,根据本地的深度学习训练模型训练得到梯度后发送给参数服务器进程,以及从参数服务器进程获取更新后的参数;参数服务器进程按预定间隔在分布式存储中保存训练快照,以在pod或pod中的进程重新启动根据训练快照恢复训练;参数服务器进程和/或训练器进程将深度学习训练模型存储至分布式存储。在本发明的一个实施例中,上述装置中,节点调度条件包括与各计算资源分别对应的资源请求下限和资源请求上限;调度单元220,用于根据各节点中已部署的pod计算各计算资源的可调度资源上限和可调度资源下限;当节点调度条件中的各计算资源的资源请求下限均小于或等于相应计算资源的可调度资源下限时,从集群中选出一个或多个目标节点。在本发明的一个实施例中,上述装置中,节点调度条件还包括作业优先级;调度单元220,用于当节点调度条件中的资源请求下限大于可调度资源下限时,按照作业优先级杀掉或阻塞已部署的pod,或者,终止本次作业调度。在本发明的一个实施例中,上述装置中,调度单元220,用于当节点调度条件对应的是可压缩资源时,阻塞pod;当节点调度条件对应的是不可压缩资源时,杀掉pod。在本发明的一个实施例中,上述装置中,调度单元220,还用于按节点调度条件为各节点上已部署的pod分配计算资源;其中,若一个节点中已部署的各pod的可压缩资源的资源请求上限之和小于该节点可压缩资源的上限,则将未被分配的可压缩资源按比例分配给该节点上已部署的各pod。在本发明的一个实施例中,上述装置中,调度单元220,还用于计算各作业进程的内存占用分,在计算得到的内存占用分达到与该作业进程对应的预设值时杀死该作业进程。在本发明的一个实施例中,上述装置中,调度单元220,用于获取基于同一pod数据部署的各pod的cpu利用率,根据cpu利用率的算术平均值与pod数据中的节点调度条件计算调整后的pod数量。在本发明的一个实施例中,上述装置中,调度单元220,还用于监听集群中是否有未被成功调度的pod,是则进一步判断是否有可扩容的节点;是则启动至少部分可扩容的节点,将未被成功调度的pod调度至新启动的节点上。在本发明的一个实施例中,上述装置中,调度单元220,用于根据各节点的节点状态判断节点是否满足缩容条件,是则关闭相应的节点,在相应的节点上已部署了pod时将已部署的pod调度至集群中的其他节点。在本发明的一个实施例中,上述装置中,缩容条件包括如下的一种或多种:节点的计算资源利用率小于预设值;节点中部署的pod均可被调度至集群中的其他节点;节点中部署的pod均依照poddisruptionbudget控制器被确定为可被漂移;节点没有本地存储。在本发明的一个实施例中,上述装置中,调度单元220,用于依据如下的一种或多种策略进行集群的扩容和/或缩容:随机选择节点;根据已部署的pod数量选择节点;根据计算资源利用率选择节点;根据物理机的使用价格选择节点;在集群中有预设数量和/或预设比例的节点发生异常时,暂停扩容和/或缩容。上述装置实施例的具体实施方式可以参照前述方法实施例的具体实施方式来实现,在此不在赘述。需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其它顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其它实施例的相关描述。图4示出了适于用来实现本发明实施方式的示例性计算机系统/服务器12的框图。图4显示的计算机系统/服务器12仅仅是一个示例,不应对本发明实施例的功能和使用范围带来任何限制。如图4所示,计算机系统/服务器12以通用计算设备的形式表现。计算机系统/服务器12的组件可以包括但不限于:一个或者多个处理器(处理单元)16,存储器28,连接不同系统组件(包括存储器28和处理器16)的总线18。总线18表示几类总线结构中的一种或多种,包括存储器总线或者存储器控制器,外围总线,图形加速端口,处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说,这些体系结构包括但不限于工业标准体系结构(isa)总线,微通道体系结构(mac)总线,增强型isa总线、视频电子标准协会(vesa)局域总线以及外围组件互连(pci)总线。计算机系统/服务器12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被计算机系统/服务器12访问的可用介质,包括易失性和非易失性介质,可移动的和不可移动的介质。存储器28可以包括易失性存储器形式的计算机系统可读介质,例如随机存取存储器(ram)30和/或高速缓存存储器32。计算机系统/服务器12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例,存储系统34可以用于读写不可移动的、非易失性磁介质(图4未显示,通常称为“硬盘驱动器”)。尽管图4中未示出,可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器,以及对可移动非易失性光盘(例如cd-rom,dvd-rom或者其它光介质)读写的光盘驱动器。在这些情况下,每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产品,该程序产品具有一组(例如至少一个)程序模块,这些程序模块被配置以执行本发明各实施例的功能。具有一组(至少一个)程序模块42的程序/实用工具40,可以存储在例如存储器28中,这样的程序模块42包括——但不限于——操作系统、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本发明所描述的实施例中的功能和/或方法。计算机系统/服务器12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信,还可与一个或者多个使得用户能与该计算机系统/服务器12交互的设备通信,和/或与使得该计算机系统/服务器12能与一个或多个其它计算设备进行通信的任何设备(例如网卡,调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口22进行。并且,计算机系统/服务器12还可以通过网络适配器20与一个或者多个网络(例如局域网(lan),广域网(wan)和/或公共网络,例如因特网)通信。如图4所示,网络适配器20通过总线18与计算机系统/服务器12的其它模块通信。应当明白,尽管图中未示出,可以结合计算机系统/服务器12使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。处理器16通过运行存储在存储器28中的程序,从而执行各种功能应用以及数据处理,例如实现图1所示实施例中的方法,即本发明同时公开了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时将实现如图1所示实施例中的方法。可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括——但不限于——电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括——但不限于——无线、电线、光缆、rf等等,或者上述的任意合适的组合。可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码,所述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c++,还包括常规的过程式程序设计语言—诸如”c”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在本发明所提供的几个实施例中,应该理解到,所揭露的装置和方法等,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(rom,read-onlymemory)、随机存取存储器(ram,randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。当前第1页12当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1