CN111309491B - 一种作业协同处理方法及系统 - Google Patents
一种作业协同处理方法及系统 Download PDFInfo
- Publication number
- CN111309491B CN111309491B CN202010404798.1A CN202010404798A CN111309491B CN 111309491 B CN111309491 B CN 111309491B CN 202010404798 A CN202010404798 A CN 202010404798A CN 111309491 B CN111309491 B CN 111309491B
- Authority
- CN
- China
- Prior art keywords
- job
- computing center
- super computing
- super
- sub
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multi Processors (AREA)
Abstract
本发明公开了一种作业协同处理方法,适于在第一超级计算中心中执行,该超级计算中心包括多个资源节点,该方法包括步骤:获取提交到第一超级计算中心的作业信息;根据作业信息确定不同于第一超级计算中心的至少一个超级计算中心为第二超级计算中心,并获取第二超级计算中心的可用资源信息,其中,第二超级计算中心包括多个资源节点;根据可用资源信息将作业划分为多个子作业;根据子作业信息生成配置信息,使第二超级计算中心根据配置信息分配可用资源,以处理子作业;获取第二超级计算中心对子作业的处理结果,与第一超级计算中心的处理结果进行合并。本发明还公开了相应的作业协同处理系统。
Description
技术领域
本发明涉及信息处理技术领域,特别涉及一种作业协同处理方法及系统。
背景技术
高性能计算是使用大量高性能硬件资源进行并行计算的过程,执行高性能计算的资源通常称为超算集群,超算中心是提供公共高性能计算服务的机构,通常拥有一套或者多套集群。现有的高性能计算任务通常体现为一个或者若干个作业。现有的超级计算资源的调度方法,作业提交后,通过一个超算中心的调度服务器,在作业提交时在本超算中心的资源中,匹配一组合适的资源,并分配能够正好运行该作业的计算节点,运行客户端提交的作业,从而保证作业的正常执行。然而,随着高性能计算在各领域的普及,计算任务无论从规模还是从数量来看都呈现爆发性增长的趋势,单一超算中心提供的资源难以满足用户需要,多超算中心下的协同有强烈的实际需求。
目前高性能计算中对于任务之间的协同缺乏有效的范式和基础设施,在实际实现中通常使用简单方法实现,例如在共享存储上使用文件交换信息,这种方法的效率,可靠性都无法得到保障,而且无法支持跨地域通信与协同。而解决大量的基础设施层和实现跨地域协同的技术问题,往往需要对已有的程序进行修改或者编写额外代码实现作业的跨地域协同。
发明内容
为此,本发明提供了一种作业协同处理方法及系统,以力图解决或者至少缓解上面存在的至少一个问题。
根据本发明的一个方面,提供了一种作业协同处理方法,适于在第一超级计算中心中执行,该超级计算中心包括多个资源节点,该方法包括步骤:获取提交到第一超级计算中心的作业信息;根据作业信息确定不同于所述第一超级计算中心的至少一个超级计算中心为第二超级计算中心,并获取第二超级计算中心的可用资源信息,其中,第二超级计算中心包括多个资源节点;根据可用资源信息将作业划分为多个子作业,根据子作业信息生成配置信息,使第二超级计算中心根据所述配置信息分配可用资源,以处理子作业;获取第二超级计算中心对子作业的处理结果,与第一超级计算中心的处理结果进行合并。
可选地,在根据本发明的作业协同处理方法中,作业信息包括执行文件和属性信息,其中,执行文件用于在资源节点上执行以处理作业;属性信息包括作业内存需求、作业性能需求和作业所需节点数,用于判断资源节点是否可用
可选地,在根据本发明的作业协同处理方法中,根据作业信息确定至少一个超级计算中心为第二超算中心,包括步骤:根据作业的属性信息生成资源请求,发送资源请求给其他超级计算中心;接收其他超级计算中心的请求结果,请求结果包括至少一个第二超级计算中心的可用资源节点信息。
可选地,在根据本发明的作业协同处理方法中,请求结果还包括请求结果有效期,当请求结果超出有效期时,重新发送资源请求。
可选地,在根据本发明的作业协同处理方法中,根据可用资源信息将作业划分为多个子作业,包括步骤:获取预设的作业处理模式;当作业处理模式是最大本地化模式时,优先使用第一超级计算中心的资源。
可选地,在根据本发明的作业协同处理方法中,可用资源信息包括可用资源节点的性能参数,所述根据所述可用资源信息将作业划分为多个子作业,还包括步骤;当作业处理模式是最大性能化模式时,比较第一超级计算中心和第二超级计算中心的性能参数,优先使用性能更高的超级计算中心的资源。
可选地,在根据本发明的作业系协同处理方法中,可用资源信息包括可用资源节点的计费方式,根据可用资源信息将作业划分为多个子作业,还包括步骤:当作业处理模式是最大经济化模式时,比较第一超级计算中心和第二超级计算中心的资源性价比,优先使用性价比更高的超级计算中心。
可选地,在根据本发明的作业协同处理方法中,配置信息包括:第二超级计算中心的资源节点分配方式,以及资源最晚使用时间。
可选地,在根据本发明的作业协同处理方法中,多个子作业在进行处理时,通过消息机制进行协同通信。
可选地,在根据本发明的作业协同处理方法中,多个子作业在进行处理前,通过数据负载传输机制传输执行文件。
根据本发明的又一个方面,提供了一种作业协同处理方法,适于在第二超级计算中心中执行,该超级计算中心包括多个资源节点,该方法包括步骤:响应第一超级计算中心的资源请求,资源请求根据提交到第一超级计算中心的作业信息生成;根据资源请求获取可用资源信息,以向第一超级计算中心返回请求结果;接收第一超算中心的配置信息,其中,配置信息根据作业划分成的子作业信息生成,根据配置信息分配可用资源,以处理子作业;向第一超级计算中心传输子作业的处理结果,以便第一超级计算中心将处理结果进行合并。
可选地,在根据本发明的作业协同处理方法中,作业信息包括执行文件和属性信息,其中,执行文件用于在资源节点上执行以处理作业;属性信息包括作业内存需求、作业性能需求和作业所需节点数,用于判断资源节点是否可用。
可选地,在根据本发明的作业协同处理方法中,资源请求根据作业的属性信息生成,所述响应第一超级计算中心的资源请求之前,还包括步骤:判断是否存在满足所述资源请求的资源节点。
可选地,在根据本发明的作业协同处理方法中,请求结果还包括请求结果有效期。
可选地,在根据本发明的作业协同处理方法中,配置信息包括:第二超级计算中心的资源节点分配方式,以及资源最晚使用时间。
可选地,在根据本发明的作业协同处理方法中,多个子作业在进行处理时,通过消息机制进行协同通信。
可选地,在根据本发明的作业协同处理方法中,多个子作业在进行处理前,通过数据负载传输机制传输执行文件。
根据本发明的又一个方面,提供了一种作业协同处理方法,适于在作业协同处理系统中执行,该作业协同处理系统包括多个超级计算中心,该方法包括步骤:当作业提交到一个超级计算中心时,该超级计算中心适于执行如前所述第一方面的作业协同处理方法;其他超级计算中心适于执行如前所述第二方面的作业协同处理方法。
根据本发明的又一个方面,提供了一种第一超级计算中心,包括:
资源管理模块,适于获取提交到本地的作业信息,以及根据可用资源信息将作业划分为多个子作业,根据子作业信息生成配置信息,使第二超级计算中心根据所述配置信息分配可用资源,以处理子作业;
消息传输模块,适于根据作业信息确定至少一个超级计算中心为第二超算中心,并获取第二超级计算中心的可用资源信息;
数据传输模块,适于传输子作业的执行文件,以及获取第二超级计算中心对子作业的处理结果,以便与第一超级计算中心的处理结果进行合并;
协同管理模块,适于处理进行作业处理时第一超级计算中心和第二超级计算中心之间的请求;
资源节点,适于执行子作业的执行文件以处理作业。
根据本发明的又一个方面,提供了一种第二超级计算中心,包括:
资源管理模块,适于根据来自第一超级计算中心的资源请求,获取可用资源信息,以及根据配置信息分配可用资源,以处理子作业,其中,配置信息根据作业划分成的子作业信息生成;
消息传输模块,适于响应来自第一超级计算中心的资源请求,向第一超级计算中心返回请求结果,接收第一超级计算中心的配置信息;
数据传输模块,适于获取子作业的执行文件,向第一超级计算中心传输子作业的处理结果,以便第一超级计算中心将处理结果进行合并;
协同管理模块,适于处理进行作业处理时第一超级计算中心和第二超级计算中心之间的请求;
资源节点,适于执行子作业的执行文件以处理作业。
根据本发明的又一个方面,提供了一种作业协同处理系统,包括:如前所述的第一超级计算中心;和至少一个如前所述的第二超级计算中心;其中,第一超级计算中心和第二超级计算中心通信连接。
根据本发明的技术方案,超级计算中心包括资源管理模块、消息传输模块、数据传输模块、协同管理模块,用户在任意一个超级计算中心上提交作业,该超级计算中心都能根据所提交的作业信息,获取其他超级计算中心的可用资源信息,根据可用资源信息将用户提交的作业划分为多个子作业并生成配置信息,以使其他超级计算中心根据配置信息分配可用资源处理子作业,从而实现调用跨地域的超级计算资源。
多个子作业在进行处理时,消息传输模块通过消息机制进行协同通信,数据传输模块通过数据负载传输机制传输执行文件,占用的资源节点计算任务结束后立即释放,通过作业在若干个超算中心之间的资源发现,资源协商,任务分发,任务执行,子作业之间的通信与协同无需对已有的程序进行修改或者编写额外的代码,就能实现作业的跨地域协同。
附图说明
为了实现上述以及相关目的,本文结合下面的描述和附图来描述某些说明性方面,这些方面指示了可以实践本文所公开的原理的各种方式,并且所有方面及其等效方面旨在落入所要求保护的主题的范围内。通过结合附图阅读下面的详细描述,本公开的上述以及其它目的、特征和优势将变得更加明显。遍及本公开,相同的附图标记通常指代相同的部件或元素。
图1示出了根据本发明的一个实施例的作业协同处理系统100的示意图;
图2示出了根据本发明的一个实施例的作业协同处理方法200的流程图;
图3示出了根据本发明的又一个实施例的作业协同处理方法300的流程图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
图1示出了根据本发明一个实施例的作业协同处理系统100的示意图。如图1所示,该系统100包括多个超级计算中心110,每个超级计算中心之间通信连接。根据一种实现方式,每个超级计算中心110包含至少一个集群,每个集群又包括多个资源节点,超级计算中心110通过这些计算节点运行各种作业(或应用),完成计算任务,各超算中心在地理上是分布的。在根据本发明的实施例中,所提交的作业来自于物理、化学、生物、石油、电力、水利、科研、制造等领域或行业,不限于此。
每个超级计算中心都配置有资源管理模块112、消息传输模块114、数据传输模块116、协同管理模块118,这些模块被实现为部署在各超级计算中心的一个系统,以实现分配本超级计算中心所包含的节点,以及和其他跨地域的超级计算中心的协同管理。
具体来说,当作业在任意一个超级计算中心110的该系统上进行提交,该超级计算中心110即为第一超级计算中心,其资源管理模块112获取提交到本地的作业信息。根据本发明的一个实施例,作业信息包括执行文件和属性信息,其中,执行文件用于在资源节点上处理作业,属性信息包括作业内存需求、作业性能需求和作业所需节点数,用于判断资源节点是否可用。
如果第一超级计算中心资源不足,由其协同管理模块118根据作业的信息生成资源请求,消息传输模块114将资源请求通过点对点或者广播的方式发送给其他超级计算中心,若其他超级计算中心存在资源节点能满足作业的处理需求,则该超级计算中心即为第二超级计算中心。
相应地,第二超级计算中心响应第一超级计算中心的资源请求之前,其资源管理模块112会判断是否存在满足该资源请求的资源节点,若存在则获取可用资源信息,其协同管理模块118会根据可用资源信息生成报文,并通过消息传输模块114向第一超级计算中心返回请求结果。需要指出的是,第二超级计算中心可能存在多个。
获取到可用资源信息后,第一超级计算中心的资源管理模块112根据可用资源信息将作业划分为多个子作业,根据子作业信息生成配置信息,使第二超级计算中心根据配置信息分配可用资源,以处理子作业。同时根据数据传输模块116传输子作业的执行文件,以及获取第二超级计算中心对子作业的处理结果,以便与第一超级计算中心的处理结果进行合并。配置信息包括第二超级计算中心的资源节点分配方式,以及资源最晚使用时间,以实现子作业执行完成后节点的动态释放。
同理,第二超级计算中心的消息传输模块114接收第一超算中心的配置信息后,资源管理模块112根据配置信息分配可用资源,以处理子作业,其中,配置信息根据作业划分成的子作业信息生成。同时根据数据传输模块116获取子作业的执行文件,向第一超级计算中心传输子作业的处理结果。
需要指出的是,超级计算中心区别于现有的云计算服务,以及网格计算服务。云计算服务单一节点的运算任务相对较轻,一般很少用到单一物理节点的所有资源,为了提高节点的利用率,云服务通常使用虚拟化技术,将一个物理节点虚拟为多个虚拟节点,而高性能计算的运算任务往往要占据多个的物理节点才能满足需要。云计算服务运行的已分配虚拟机中长期运行的服务,一个虚拟机分配后,一般不会移动,当执行新任务时,需要重新分配虚拟机,各虚拟节点之间任务的协同依赖于一个集群中的物理节点,而一个高性能计算任务通常需要调用大量计算资源同时进行计算,有些任务对节点数的需求可以达到数千个甚至上万个节点,因此不适用于当前分布在不同地理区域的超级计算中心的不同集群。
而网格计算侧重于将网格中大量的计算机集中起来完成一个计算任务,然而受限于资源的多样性和单一节点的能力,能解决的问题有限,计算程序需要对网格计算能力进行专门适配,有额外开发成本。
根据本发明的技术方案,超级计算中心110包括资源管理模块112、消息传输模块114、数据传输模块116、协同管理模块118,用户在任意一个超级计算中心上提交作业,该超级计算中心都能根据所提交的作业信息,获取其他超级计算中心的可用资源信息,根据可用资源信息将用户提交的作业划分为多个子作业并生成配置信息,以使其他超级计算中心根据配置信息分配可用资源处理子作业,从而实现调用跨地域的超级计算资源。
为将网络波动对数据传输的影响降到小,在协同管理的过程中,对不同大小的消息进行分别传输。消息传输模块114主要负责传送控制消息,信令一般是小数据,对时效性要求高,采用浪费带宽换取高时效性和高可靠性:如通常采用TCP报文,且加入FEC(ForwardError Correction,前向纠错编码)和Extactly-Once(确保仅一次)传输策略。多个子作业在进行处理前,数据传输模块116通过数据负载传输机制传输执行文件。负载通常采取充分利用带宽而牺牲一定时效性与可靠性的方案,如采用UDP报文,使用应用协议级的纠错与重发机制,以获得带宽的充分利用。消息传输模块还增加了容错机制,请求结果包括请求结果有效期,当请求结果超出有效期时重新发送资源请求,配置信息包括资源最晚使用时间,加快了任务的分发及处理,占用的资源节点计算任务结束后立即释放。
通过作业在若干个超算中心110之间的资源发现,资源协商,任务分发,任务执行,子作业之间的通信与协同无需对已有的程序进行修改或者编写额外的代码,就能实现作业的跨地域协同。
图2示出了根据本发明的一个实施例的作业协同处理方法200的流程图。该方法适于在如上所述的超级计算中心110中执行,作业在该超级计算中心110的系统上进行提交,该超级计算中心110即为第一超级计算中心。高性能计算作业根据要解决的问题的算法特征,对于总规模相当的作业,可分为两类。
一类需要大量的计算节点在紧密的协同下进行计算,不能被分割为独立的子作业,或者只能分割为少量相对独立的子作业,每个子作业的规模依然很大。例如比如1万节点的规模,只能分成2-3个相对独立的子作业,每个的规模3000-5000节点。
另一类作业也需要大量计算节点计算,但是可以分割为大量相对独立的子作业,每个子作业可能占据一个或者几十个节点,独立的子作业之间关联很小。同样1万节点的规模,可以分成1000个10节点作业。就实际应用中的计算案例来看,第二类作业的数量要远多于第一类,本方案中的作业主要针对第二类作业。
如图2所示,方法200始于步骤S210。在步骤S210中,获取提交到第一超级计算中心的作业信息。提交的作业来自于物理、化学、生物、石油、电力、水利、科研、制造等领域或行业,不限于此。
在根据本发明的实施例中,作业信息包括执行文件和属性信息,其中,执行文件用于在资源节点上执行以处理作业;属性信息包括作业内存需求、作业性能需求和作业所需节点数,用于判断资源节点是否可用,具体来说,作业性能需求例如作业所需的硬件架构、操作系统版本范围等,作业所需节点数例如单个作业所需的CPU或者 GPU数目。根据本发明的一个实施例,作业信息所包括的执行文件以存储执行文件所在位置的形式存在,当需要调用执行文件时,根据所在路径打开执行文件即可,执行文件由数据传输模块114通过数据负载传输机制进行传输。如上所述的资源管理模块112存储有原本的队列情况,总共计算资源个数、空闲资源个数、内存大小、硬件架构剩余空间的存储情况等。执行作业的计算程序,如VASP、Fluent、LAMMPS等,不限于此。假如第一超算中心有500台12核64G内存的机器。
而以一个典型的基于第一性原理的材料性质筛选计算为例,使用的计算程序为VASP,支持硬件架构为x86,操作系统为Linux,内存需求单节点不小于64GB,核数不小于12核,内存/核数比大于等于2.6,执行文件为筛选范围为1000个可能的分子,标记为M1…M1000 每个分子的结构为一个数据文件,则第一超级计算中心的资源不足以处理该作业。
获取作业信息后,若出现第一超级计算中心资源不足的情况,则进入步骤S220,根据作业信息确定不同于第一超级计算中心的至少一个超级计算中心为第二超级计算中心,并获取第二超级计算中心的可用资源信息,其中,第二超级计算中心包括多个资源节点。
在根据本发明的实施例中,由其协同管理模块118根据作业的属性信息生成资源请求,消息传输模块114将资源请求通过点对点或者广播的方式发送给其他超级计算中心。接收其他超级计算中心110的请求结果,请求结果包括至少一个第二超级计算中心的可用资源节点信息,若其他超级计算中心存在资源节点能满足作业的处理需求,该超级计算中心即为第二超级计算中心。根据本发明的一个实施例,还增加了容错机制,请求结果包括请求结果有效期,当请求结果超出有效期时,重新发送资源请求。
假设第二超级计算中心只有一个,第一超级计算中心的资源信息和作业信息如上所述,步骤S220中第二超级计算中心的资源节点信息如下:
200台12核,96GB内存机器,为集群QB1;
200台48核,96GB内存机器,为集群QB2;
200台24核,128GB内存机器,为集群QB3;
200台12核,128GB内存机器,为集群QB4;
则子作业首先第二超级计算中心A上500台机器,每台机器一个子作业,
则作业A1…A500 为此作业的一部分,输入分别是M1…M500。
第二超级计算中心回复可用资源消息(QB2因为不满足内存/核数比大于等于2.6这一限制而未能匹配):
200台12核,96GB内存机器,为集群QB1;
200台24核,128GB内存机器,为集群QB3;
200台12核,128GB内存机器,为集群QB4;
有效时间24小时。
接着,在步骤S230中,根据所述可用资源信息将作业划分为多个子作业,根据子作业信息生成配置信息,使第二超级计算中心根据配置信息分配可用资源,以处理子作业。执行程序的输入是1000个可能分子,执行的计算程序为VASP,则每个分子为一个子任务的输入。具体地,配置信息包括第二超级计算中心的资源节点分配方式,以及资源最晚使用时间,以实现子作业执行完成后节点的动态释放。资源节点分配方式例如5台机器有120个CPU核,子任务需要110个CPU核,是采取22个核/机的平均分配,还是优先占满前4台机器。
根据本发明的一个实施例,资源管理模块根据可用资源信息将作业划分为多个子作业,包括步骤:获取预设的作业处理模式,当作业处理模式是最大本地化模式时,优先使用第一超级计算中心的资源,不够的部分再将子作业分流到其他超级计算中心。第一超级计算中心的资源信息、作业信息、第二超级计算中心的可用资源信息如上所述,则根据最大本地化模式进行作业处理的分配结果为:
此时第二超级计算中心可自主根据多种分配策略,假定此时第二超级计算中心尽量贴近发起方配置,避免作业失败风险的策略,则会按如下顺序使用:
QB1: 200台,因为和发起方配置完全一样;
QB4: 200台,CPU核数一样,内存更大;
QB3: 100台,CPU核数更多,内存/核数满足最低要求;
a) 会生成B1…B500 500个作业,对应输入分别为M501…M1000,需要说明的是,第二超级计算中心获取到需要其执行的作业后,分配策略不仅以上方式,可结合自身集群资源信息做出分配。
根据本发明的另一个实施例,可用资源信息包括可用资源节点的性能参数,当预设的作业处理模式为最大性能化模式时,比较第一超级计算中心和第二超级计算中心的性能参数,优先使用性能更高的超级计算中心的资源。例如比较计算资源的参数,如CPU型号,将较优的CPU上尽可能分配更多的资源,这由资源申请方根据用户设定的作业处理模式来决定。
根据本发明的又一个实施例,可用资源信息包括可用资源节点的计费方式,当作业处理模式是最大经济化模式时,比较第一超级计算中心和第二超级计算中心的资源性价比,优先使用性价比更高的超级计算中心。由于CPU及其他硬件性能差异,不同的集群,将会具有不同的费率。以用户所购买的核时单价(即,每个计算核每小时的运行价钱)作为标准费率,费率乘以用户所购买的核时单价,就可以得到各作业队列的核时价格(每个计算核每小时的运行价钱),再结合所提交作业所需要的计算资源的数量,就可以确定出各集群运行该子作业所需费用,以总费用最低的方案为性价比最高的方案,争取为用户节省费用。需要说明的时,实际使用的作业处理模式不限于以上三种,或者多种作业处理模式的混合。
实际上作业处理模式的运行是一个反复迭代的过程,例如,第一超级计算中心A向第二超算中心B提交500节点的请求报文,而B回复只能提供300节点,则A有两个选择:
一个是接受B提出的300节点的建议,将500节点任务,分割为200节点和300节点两组,然后将300节点的作业传输至超级计算中心B运行,然后将剩下的200节点任务向其它超级计算中心请求,直到所有作业都被分发,或者所有已知超级计算中心均不能提供更多资源为止。如果后一种情况发生,则最后剩余任务将在发起的超级计算中心排队等待。
另一个选择:A也可以选择不接受超级计算中心B的300节点建议,则可以向超级计算中心B发出拒绝报文,A将继续按前述逻辑向其它超级计算中心请求,直到所有作业都被分发,或者所有已知超级计算中心均不能提供更多资源为止。以上两个选择,如果还有剩余作业,则会定时迭代运行,直到所有作业被分发为止。
最后,在步骤S240中,获取第二超级计算中心对子作业的处理结果,与第一超级计算中心的处理结果进行合并。在广域互联网的复杂环境下,网络的波动对数据传输影响很大,所以要对不同大小的消息进行分别传输,在传输层面上也会采取不同的技术方案。
根据本发明的一个实施例,多个子作业在进行处理时,通过消息机制进行协同通信。协同通信主要负责传送控制消息,信令一般是小数据(1-10KB),对时效性要求高,采用浪费带宽换取高时效性和高可靠性:如通常采用TCP报文,且加入FEC(Forward ErrorCorrection,前向纠错编码)和Extactly-Once(确保仅一次)传输策略。
根据本发明的又一个实施例,多个子作业在进行处理前,通过数据负载传输机制传输执行文件。负载通常采取充分利用带宽而牺牲一定时效性与可靠性的方案,如采用UDP报文,使用应用协议级的纠错与重发机制,以获得带宽的充分利用。
根据本发明的技术方案,超级计算中心包括资源管理模块、消息传输模块、数据传输模块、协同管理模块,用户在任意一个超级计算中心上提交作业,该超级计算中心都能根据所提交的作业信息,获取其他超级计算中心的可用资源信息,根据可用资源信息将用户提交的作业划分为多个子作业并生成配置信息,以使其他超级计算中心根据配置信息分配可用资源处理子作业,从而实现调用跨地域的超级计算资源。
多个子作业在进行处理时,消息传输模块通过消息机制进行协同通信,数据传输模块通过数据负载传输机制传输执行文件,占用的资源节点计算任务结束后立即释放,通过作业在若干个超算中心之间的资源发现,资源协商,任务分发,任务执行,子作业之间的通信与协同无需对已有的程序进行修改或者编写额外的代码,就能实现作业的跨地域协同。
如果第一超级计算中心资源不足,由其协同管理模块118根据作业的信息生成资源请求,消息传输模块114将资源请求通过点对点或者广播的方式发送给其他超级计算中心,若其他超级计算中心存在资源节点能满足作业的处理需求,则该超级计算中心即为第二超级计算中心。图3示出了根据本发明的又一个实施例的作业协同处理方法300的流程图,该方法在如上所述的第二超级计算中心执行。
如图3所示,方法300始于步骤S310。在步骤S310中,响应第一超级计算中心的资源请求,该资源请求根据提交到第一超级计算中心的作业信息生成。提交的作业来自于物理、化学、生物、石油、电力、水利、科研、制造等领域或行业,不限于此。
在根据本发明的实施例中,作业信息包括执行文件和属性信息,其中,执行文件用于在资源节点上执行以处理作业;属性信息包括作业内存需求、作业性能需求和作业所需节点数,用于判断资源节点是否可用,具体来说,作业性能需求例如作业所需的硬件架构、操作系统版本范围等,作业所需节点数例如单个作业所需的CPU或者 GPU数目。根据本发明的一个实施例,作业信息所包括的执行文件以存储执行文件所在位置的形式存在,当需要调用执行文件时,根据所在路径打开执行文件即可。执行作业的计算程序,如VASP、Fluent、LAMMPS等,不限于此。具体地,资源请求根据作业的属性信息生成。
接着在步骤S320中,根据资源请求获取可用资源信息,以向第一超级计算中心返回请求结果。
具体来说,第二超级计算中心的资源管理模块112存储有原本的队列情况,总共计算资源个数、空闲资源个数、内存大小、硬件架构剩余空间的存储情况等。在响应第一超级计算中心的资源请求之前,还包括判断是否存在满足所述资源请求的资源节点的步骤。根据本发明的一个实施例,还增加了容错机制,请求结果包括请求结果有效期,当请求结果超出有效期时,重新发送资源请求。
接着,在步骤S330中,接收第一超算中心的配置信息,其中,配置信息根据作业划分成的子作业信息生成,根据配置信息分配可用资源,以处理子作业。执行程序的输入是1000个可能分子,执行的计算程序为VASP,则每个分子为一个子任务的输入。具体地,配置信息包括第二超级计算中心的资源节点分配方式,以及资源最晚使用时间,以实现子作业执行完成后节点的动态释放。
例如,第一超级计算中心A向第二超算中心B提交500节点的请求报文,而B回复只能提供300节点,则A有两个选择:
一个是接受B提出的300节点的建议,将500节点任务,分割为200节点和300节点两组,然后将300节点的作业传输至超级计算中心B运行,然后将剩下的200节点任务向其它超级计算中心请求,直到所有任务都被分发,或者所有已知超级计算中心均不能提供更多资源为止。如果后一种情况发生,则最后剩余任务将在发起的超级计算中心排队等待。
另一个选择:A也可以选择不接受超级计算中心B的300节点建议,则可以向超级计算中心B发出拒绝报文,A将继续按前述逻辑向其它超级计算中心请求,直到所有作业都被分发,或者所有已知超级计算中心均不能提供更多资源为止。以上两个选择,如果还有剩余作业,则会定时迭代运行,直到所有作业被分发为止。
按第一种方式选择后, 300节点的作业被传输至第二超级计算中心运行,执行文件由数据传输模块114通过数据负载传输机制进行传输,第二超级计算中心可自主根据多种分配策略,假定此时第二超级计算中心尽量贴近发起方配置,避免作业失败风险的策略。需要说明的是,第二超级计算中心获取到需要其执行的作业后,分配策略不仅以上方式,可结合自身集群资源信息做出分配。
随后,在步骤S340中,向第一超级计算中心传输子作业的处理结果,以便第一超级计算中心将处理结果进行合并。为将网络波动对数据传输的影响降到小,在资源发现、资源协商、任务分发、任务执行的过程中,对不同大小的消息进行分别传输。
根据本发明的一个实施例,多个子作业在进行处理时,通过消息机制进行协同通信。协同通信主要负责传送控制消息,信令一般是小数据(1-10KB),对时效性要求高,采用浪费带宽换取高时效性和高可靠性:如通常采用TCP报文,且加入FEC(Forward ErrorCorrection,前向纠错编码)和Extactly-Once(确保仅一次)传输策略。
根据本发明的又一个实施例,多个子作业在进行处理前,通过数据负载传输机制传输执行文件。负载通常采取充分利用带宽而牺牲一定时效性与可靠性的方案,如采用UDP报文,使用应用协议级的纠错与重发机制,以获得带宽的充分利用。
利用根据本发明的消息机制,消息传输模块114在第一超算中心与第二超算中心之间实现动态路由,以进行子作业协同管理的过程如下:子作业A1向本地消息传输模块发出消息报文M,与子作业B1通信;本地消息传输模块向A1所在的资源管理模块112发起查询,得到B1所在超级计算中心位置;消息传输模块根据实际位置信息,将M发送给B1所在超级计算中心的消息传输模块114;B1所在超级计算中心的消息传输模块114查询B本地资源管理模块112,得到B1在本地的实际位置,将消息发送给B1。
以上作业在运行过程中,通过本发明描述的资源管理模块和系统管理模块,可以自主的对同样支持协同的超级计算资源进行发现与调用,最终体现为在异地某个超算中心上运行的一个或者多个作业。通过各超级计算中心之间的协同计算关系,利用本发明描述的消息传输模块和数据传输模块来实现通信,计算程序无需改动,就能使用其它超级计算中心的计算资源,没有额外开发成本。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员应当理解在本文所公开的示例中的设备的模块或单元或组件可以布置在如该实施例中所描述的设备中,或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
此外,所述实施例中的一些在此被描述成可以由计算机系统的处理器或者由执行所述功能的其它装置实施的方法或方法元素的组合。因此,具有用于实施所述方法或方法元素的必要指令的处理器形成用于实施该方法或方法元素的装置。此外,装置实施例的在此所述的元素是如下装置的例子:该装置用于实施由为了实施该发明的目的的元素所执行的功能。
如在此所使用的那样,除非另行规定,使用序数词“第一”、“第二”、“第三”等等来描述普通对象仅仅表示涉及类似对象的不同实例,并且并不意图暗示这样被描述的对象必须具有时间上、空间上、排序方面或者以任意其它方式的给定顺序。
尽管根据有限数量的实施例描述了本发明,但是受益于上面的描述,本技术领域内的技术人员明白,在由此描述的本发明的范围内,可以设想其它实施例。此外,应当注意,本说明书中使用的语言主要是为了可读性和教导的目的而选择的,而不是为了解释或者限定本发明的主题而选择的。因此,在不偏离所附权利要求书的范围和精神的情况下,对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围,对本发明所做的公开是说明性的,而非限制性的,本发明的范围由所附权利要求书限定。
Claims (18)
1.一种作业协同处理方法,适于在多个超级计算中心的第一超级计算中心中执行,所述超级计算中心包括多个资源节点,所述方法包括步骤:
获取提交到所述第一超级计算中心的作业信息;
获取所述作业信息后,若第一超级计算中心资源不足,根据作业信息生成资源请求,发送资源请求给其他超级计算中心,接收其他超级计算中心的请求结果,所述请求结果包括至少一个第二超级计算中心的可用资源信息,其中,所述第二超级计算中心包括多个资源节点;获取预设的作业处理模式,根据所述作业处理模式和所述可用资源信息反复迭代将作业划分为多个子作业,根据所述子作业信息生成配置信息,使所述第二超级计算中心根据所述配置信息分配可用资源,以处理子作业,所述配置信息包括资源最晚使用时间,以实现子作业执行完成后节点的动态释放,其中,所述反复迭代是指:接收到第二超级计算中心返回的可用资源信息之后,若根据作业处理模式不接受所述可用资源信息的建议,则向第二超级计算中心发出拒绝报文,并继续按前述逻辑向其它超级计算中心请求,直到所有作业都被分发,或者所有已知超级计算中心均不能提供更多资源为止;
所述多个子作业在进行处理时,通过消息机制进行协同通信,获取第二超级计算中心对子作业的处理结果,与第一超级计算中心的处理结果进行合并;
其中,所述作业处理模式包括:最大本地化模式、最大性能化模式、最大经济化模式。
2.如权利要求1所述的方法,所述作业信息包括执行文件和属性信息,其中,
所述执行文件用于在资源节点上执行以处理作业;
所述属性信息包括作业内存需求、作业性能需求和作业所需节点数,用于判断资源节点是否可用。
3.如权利要求1所述的方法,所述请求结果还包括请求结果有效期,当请求结果超出有效期时,重新发送资源请求。
4.如权利要求1-3中任一项所述的方法,所述根据所述可用资源信息将作业划分为多个子作业,包括步骤:
获取预设的作业处理模式;
当作业处理模式是最大本地化模式时,优先使用第一超级计算中心的资源。
5.如权利要求1-3中任一项所述的方法,所述可用资源信息包括可用资源节点的性能参数,所述根据所述可用资源信息将作业划分为多个子作业,还包括步骤;
当所述作业处理模式是最大性能化模式时,比较第一超级计算中心和第二超级计算中心的性能参数,优先使用性能更高的超级计算中心的资源。
6.如权利要求1-3中任一项所述的方法,所述可用资源信息包括可用资源节点的计费方式,所述根据所述可用资源信息将作业划分为多个子作业,还包括步骤:
当所述作业处理模式是最大经济化模式时,比较第一超级计算中心和第二超级计算中心的资源性价比,优先使用性价比更高的超级计算中心。
7.如权利要求1-3中任一项所述的方法,所述配置信息包括:第二超级计算中心的资源节点分配方式,以及资源最晚使用时间。
8.如权利要求1-3中任一项所述的方法,所述多个子作业在进行处理前,通过数据负载传输机制传输执行文件。
9.一种作业协同处理方法,适于在多个超级计算中心的第二超级计算中心中执行,所述超级计算中心包括多个资源节点,所述方法包括步骤:
响应第一超级计算中心的资源请求,所述资源请求根据提交到第一超级计算中心的作业信息生成;
根据资源请求获取可用资源信息,以向第一超级计算中心返回请求结果,所述请求结果包括至少一个第二超级计算中心的可用资源信息;
接收第一超级计算中心的配置信息,其中,所述配置信息是第一超级计算中心根据预设的作业处理模式和所述可用资源信息反复迭代将作业划分成的多个子作业信息生成,根据所述配置信息分配可用资源,以处理子作业,所述配置信息包括资源最晚使用时间,以实现子作业执行完成后节点的动态释放,其中,所述反复迭代是指:第一超级计算中心接收到第二超级计算中心返回的可用资源信息之后,若根据作业处理模式不接受所述可用资源信息的建议,则向第二超级计算中心发出拒绝报文,并继续按前述逻辑向其它超级计算中心请求,直到所有作业都被分发,或者所有已知超级计算中心均不能提供更多资源为止;
所述多个子作业在进行处理时,通过消息机制进行协同通信,向第一超级计算中心传输子作业的处理结果,以便第一超级计算中心将处理结果进行合并;
其中,所述作业处理模式包括:最大本地化模式、最大性能化模式、最大经济化模式。
10.如权利要求9所述的方法,所述作业信息包括执行文件和属性信息,其中,
所述执行文件用于在资源节点上执行以处理作业;
所述属性信息包括作业内存需求、作业性能需求和作业所需节点数,用于判断资源节点是否可用。
11.如权利要求10所述的方法,所述资源请求根据作业的属性信息生成,所述响应第一超级计算中心的资源请求之前,还包括步骤:判断是否存在满足所述资源请求的资源节点。
12.如权利要求9-11中任一项所述的方法,所述请求结果还包括请求结果有效期。
13.如权利要求9-11中任一项所述的方法,所述配置信息包括:第二超级计算中心的资源节点分配方式,以及资源最晚使用时间。
14.如权利要求9-11中任一项所述的方法,所述多个子作业在进行处理前,通过数据负载传输机制传输执行文件。
15.一种作业协同处理方法,所述作业协同处理方法适于在作业协同处理系统中执行,所述作业协同处理系统包括多个超级计算中心,所述方法包括步骤:
当作业提交到一个超级计算中心时,所述超级计算中心适于执行如权利要求1-8中任一项所述的作业协同处理方法;
其他超级计算中心适于执行如权利要求9-14中任一项所述的作业协同处理方法。
16.一种第一超级计算中心,所述第一超级计算中心和多个超级计算中心通信连接,所述第一超级计算中心包括:
资源管理模块,适于获取提交到本地的作业信息,以及获取所述作业信息后,若第一超级计算中心资源不足,获取预设的作业处理模式,根据所述作业处理模式和可用资源信息反复迭代将作业划分为多个子作业,根据子作业信息生成配置信息,使第二超级计算中心根据所述配置信息分配可用资源,以处理子作业,所述配置信息包括资源最晚使用时间,以实现子作业执行完成后节点的动态释放,其中所述反复迭代是指:第一超级计算中心接收到第二超级计算中心返回的可用资源信息之后,若根据作业处理模式不接受所述可用资源信息的建议,则向第二超级计算中心发出拒绝报文,并继续按前述逻辑向其它超级计算中心请求,直到所有作业都被分发,或者所有已知超级计算中心均不能提供更多资源为止;所述作业处理模式包括:最大本地化模式、最大性能化模式、最大经济化模式;
消息传输模块,适于根据所述作业信息确定至少一个超级计算中心为第二超级计算中心,获取第二超级计算中心的可用资源信息,并通过消息机制使多个子作业在进行处理时进行协同通信;
数据传输模块,适于传输子作业的执行文件,以及获取第二超级计算中心对子作业的处理结果,以便与第一超级计算中心的处理结果进行合并;
协同管理模块,适于处理进行作业处理时第一超级计算中心和第二超级计算中心之间的请求;
资源节点,适于执行子作业的执行文件以处理作业。
17.一种第二超级计算中心,所述第二超级计算中心和多个超级计算中心连接,所述第二超级计算中心包括:
资源管理模块,适于根据来自第一超级计算中心的资源请求,获取可用资源信息,以及根据来自第一超级计算中心的配置信息分配可用资源,以处理子作业,其中,所述配置信息是第一超级计算中心根据预设的作业处理模式和所述可用资源信息反复迭代将作业划分成的多个子作业信息生成,所述配置信息包括资源最晚使用时间,以实现子作业执行完成后节点的动态释放,其中,所述反复迭代是指:第一超级计算中心接收到第二超级计算中心返回的可用资源信息之后,若根据作业处理模式不接受所述可用资源信息的建议,则向第二超级计算中心发出拒绝报文,并继续按前述逻辑向其它超级计算中心请求,直到所有作业都被分发,或者所有已知超级计算中心均不能提供更多资源为止;所述作业处理模式包括:最大本地化模式、最大性能化模式、最大经济化模式;
消息传输模块,适于响应来自第一超级计算中心的资源请求,向第一超级计算中心返回请求结果,所述请求结果包括至少一个第二超级计算中心的可用资源信息,接收第一超级计算中心的配置信息,并通过消息机制使多个子作业在进行处理时进行协同通信;
数据传输模块,适于获取子作业的执行文件,向第一超级计算中心传输子作业的处理结果,以便第一超级计算中心将处理结果进行合并;
协同管理模块,适于处理进行作业处理时第一超级计算中心和第二超级计算中心之间的请求;
资源节点,适于执行子作业的执行文件以处理作业。
18.一种作业协同处理系统,包括:
如权利要求16所述的第一超级计算中心;和
至少一个如权利要求17所述的第二超级计算中心;
其中,所述第一超级计算中心和第二超级计算中心通信连接。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010404798.1A CN111309491B (zh) | 2020-05-14 | 2020-05-14 | 一种作业协同处理方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010404798.1A CN111309491B (zh) | 2020-05-14 | 2020-05-14 | 一种作业协同处理方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111309491A CN111309491A (zh) | 2020-06-19 |
CN111309491B true CN111309491B (zh) | 2020-11-06 |
Family
ID=71150212
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010404798.1A Active CN111309491B (zh) | 2020-05-14 | 2020-05-14 | 一种作业协同处理方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111309491B (zh) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112580296B (zh) * | 2020-12-16 | 2024-05-31 | 全芯智造技术有限公司 | 用于处理电路版图的方法、设备和存储介质 |
CN112579286B (zh) * | 2020-12-16 | 2021-08-06 | 全芯智造技术有限公司 | 用于光源掩模优化的方法、设备和存储介质 |
CN112560392B (zh) * | 2020-12-16 | 2021-08-10 | 全芯智造技术有限公司 | 用于处理电路版图的方法、设备和存储介质 |
CN114764377A (zh) * | 2020-12-30 | 2022-07-19 | 花瓣云科技有限公司 | 一种数据备份方法、电子设备、数据备份系统及芯片系统 |
CN116909676B (zh) * | 2023-09-12 | 2024-02-23 | 中国科学技术大学 | 一种二分量第一性原理计算系统与服务方法 |
CN117390841B (zh) * | 2023-10-09 | 2024-06-11 | 中国航发商用航空发动机有限责任公司 | 一种基于超算云的异地协同仿真平台架构和设计方法 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104283943A (zh) * | 2014-09-22 | 2015-01-14 | 珠海许继芝电网自动化有限公司 | 一种集群服务器的通信优化方法 |
CN106790529A (zh) * | 2016-12-20 | 2017-05-31 | 北京并行科技股份有限公司 | 计算资源的调度方法、调度中心及调度系统 |
CN106844040A (zh) * | 2016-12-20 | 2017-06-13 | 北京并行科技股份有限公司 | 一种作业提交方法、系统及服务器 |
CN108694082A (zh) * | 2018-05-14 | 2018-10-23 | 有时数联科技(北京)有限公司 | 一种跨域作业流调度方法及系统 |
CN109951558A (zh) * | 2019-03-27 | 2019-06-28 | 北京并行科技股份有限公司 | 一种超算资源的云调度方法、云调度中心和系统 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102170474A (zh) * | 2011-04-22 | 2011-08-31 | 广州杰赛科技股份有限公司 | 一种云计算网络中虚拟资源动态调度方法及系统 |
US9602423B2 (en) * | 2013-06-28 | 2017-03-21 | Pepperdata, Inc. | Systems, methods, and devices for dynamic resource monitoring and allocation in a cluster system |
CN104461740B (zh) * | 2014-12-12 | 2018-03-20 | 国家电网公司 | 一种跨域集群计算资源聚合和分配的方法 |
CN110728363B (zh) * | 2018-06-29 | 2022-11-18 | 华为技术有限公司 | 任务处理方法和装置 |
CN110109752A (zh) * | 2019-04-12 | 2019-08-09 | 平安普惠企业管理有限公司 | 一种任务分配方法、装置、电子设备及存储介质 |
-
2020
- 2020-05-14 CN CN202010404798.1A patent/CN111309491B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104283943A (zh) * | 2014-09-22 | 2015-01-14 | 珠海许继芝电网自动化有限公司 | 一种集群服务器的通信优化方法 |
CN106790529A (zh) * | 2016-12-20 | 2017-05-31 | 北京并行科技股份有限公司 | 计算资源的调度方法、调度中心及调度系统 |
CN106844040A (zh) * | 2016-12-20 | 2017-06-13 | 北京并行科技股份有限公司 | 一种作业提交方法、系统及服务器 |
CN108694082A (zh) * | 2018-05-14 | 2018-10-23 | 有时数联科技(北京)有限公司 | 一种跨域作业流调度方法及系统 |
CN109951558A (zh) * | 2019-03-27 | 2019-06-28 | 北京并行科技股份有限公司 | 一种超算资源的云调度方法、云调度中心和系统 |
Also Published As
Publication number | Publication date |
---|---|
CN111309491A (zh) | 2020-06-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111309491B (zh) | 一种作业协同处理方法及系统 | |
US10262390B1 (en) | Managing access to a resource pool of graphics processing units under fine grain control | |
US8903981B2 (en) | Method and system for achieving better efficiency in a client grid using node resource usage and tracking | |
CN113157447B (zh) | 一种基于智能网卡的rpc负载均衡方法 | |
US20070180451A1 (en) | System and method for meta-scheduling | |
WO2006055027A1 (en) | On-demand instantiation in a high-performance computing (hpc) system | |
CN110990154B (zh) | 一种大数据应用优化方法、装置及存储介质 | |
EP3114589B1 (en) | System and method for massively parallel processing database | |
US8849905B2 (en) | Centralized computing | |
Garala et al. | A performance analysis of load Balancing algorithms in Cloud environment | |
US8458702B1 (en) | Method for implementing user space up-calls on java virtual machine before/after garbage collection | |
CN112153697B (zh) | 一种多基站、高并发场景下的cors解算方法、播发方法及系统、cors系统 | |
KR102119456B1 (ko) | 분산 클라우드 환경에서의 분산 브로커 코디네이터 시스템 및 방법 | |
KR20140118030A (ko) | 클라우드 컴퓨팅 환경의 계층형 부하분산 구조에서 자원 거래 관리 장치 및 방법 | |
CN111796932A (zh) | 一种gpu资源调度方法 | |
AU2014217773A1 (en) | Method, processing modules and system for executing an executable code | |
Shiekh et al. | A load-balanced hybrid heuristic for allocation of batch of tasks in cloud computing environment | |
CN104184685A (zh) | 数据中心资源分配方法、装置及系统 | |
Mishra et al. | A memory-aware dynamic job scheduling model in Grid computing | |
CN112346853A (zh) | 用于分布应用的方法和设备 | |
Jaikar et al. | Matrix-based data center selection algorithm for a federated cloud | |
CN111294383A (zh) | 物联网服务管理系统 | |
Sutagundar et al. | Development of fog based dynamic resource allocation and pricing model in IoT | |
CN111107135A (zh) | 一种容器镜像并行分发方法、调度器及存储介质 | |
Goswami et al. | Handling resource failure towards load balancing in computational grid environment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
PE01 | Entry into force of the registration of the contract for pledge of patent right |
Denomination of invention: A job collaborative processing method and system Effective date of registration: 20211201 Granted publication date: 20201106 Pledgee: Zhongguancun Beijing technology financing Company limited by guarantee Pledgor: BEIJING PARATERA TECHNOLOGY Co.,Ltd. Registration number: Y2021990001147 |
|
PE01 | Entry into force of the registration of the contract for pledge of patent right |