CN101202761B - 一种分布式资源调度系统及其方法 - Google Patents

Abstract

本发明提供了一种分布式资源调度方法，包括如下步骤：(a)服务节点将需要处理的任务打包生成格式统一的任务包，并将所述任务包发送至调度服务器；(b)所述调度服务器接收并管理所述服务节点发来的任务包，以预设规则将其分配至计算节点；(c)所述计算节点接收所述调度服务器发来的任务包，并对所述任务包进行处理，将处理的结果包发送至所述调度服务器。本发明可以使系统内计算机分工明确，便于管理，可以使得整个分布式系统的计算任务不受计算机语言、操作系统平台等限制。

Description

一种分布式资源调度系统及其方法

技术领域

本发明涉及资源调度技术，特别涉及一种分布式资源调度系统及其方法。

背景技术

现有的分布式计算(网格计算)技术有一些成熟的软件和产品，其中代表的有：

1、BOINC

BOINC是一个分布式计算平台，由美国加利福尼亚大学伯克利分校(University of California-Berkeley)于2003年开发，使得各种分布式计算项目能够使用一个平台软件来运行。

但是BOINC有几个困难的地方：

A、其服务器和任务的配置是全手工，而且非常复杂；

B、只能处理需要少量数据交互的运算；

C、要使用BOINC的提供开发包编程，支持的程序接口有限。

2、Globus

Globus由全球网格论坛(GGF)下属Globus项目组成员联合开发的GlobusToolkit标准工具包，可以建立网格系统和开发网格软件。

但是Globus也有几个困难的地方：

A、开发Globus程序，必须非常熟悉其API函数，并使用专用平台；

B、程序出错会影响全局，当计算节点死机时无法被控制；

C、当计算节点增多时，节点之间通信耗费资源太大，甚至抵消了计算能力的增长；

同时，以上这些分布式计算平台都有一些限制：

A、开发的分布式程序都是基于特定开发平台，非通用程序；

B、所有的环境构建和框架都是针对特定开发环境，非通用框架。

发明内容

本发明的目的在于提供一种分布式资源调度系统及其方法。

本发明解决其技术问题所采用的技术方案是：一种分布式资源调度方法，包括如下步骤：

(a)，服务节点将需要处理的任务打包生成格式统一的任务包，并将所述任务包发送至调度服务器；

(b)，所述调度服务器接收并管理所述服务节点发来的任务包，以预设规则将其分配至计算节点；

(c)，所述计算节点接收所述调度服务器发来的任务包，并对所述任务包进行处理，将处理的结果包发送至所述调度服务器。

本发明中，所述步骤(a)还包括：

(a1)，将需要处理的任务放置在预设目录下，并对该目录进行扫描，向所述调度服务器查询每个任务包的状态；

(a2)，根据返回的查询状态，作相应的处理，具体包括：任务正在计算中，不作处理；任务已经完成，则将相应的任务包移入相应的目录下并进行后续操作；任务错误，则选择重发该任务包或取消该任务包。

本发明中，所述步骤(a)还包括：

(a3)，扫描预设目录下的每个任务包时，每隔预设时间将其发送至所述调度服务器，发送完毕后，休眠预设时间。

本发明中，所述步骤(b)还包括：

(b1)，接收并登记所述服务节点发来的任务包，向所述服务节点提供任务包的状态查询；

(b2)，所述调度服务器以优先级为0～9的预设规则将任务包发送至计算节点。

本发明中，所述步骤(b)还包括：

(b3)，所述调度服务器响应所述服务节点的查询，如果发现该查询的任务包已经完成，则向所述服务节点返回结果包。

本发明中，所述步骤(c)还包括：

(c1)，计算节点向调度服务器提交本机所支持的运行环境，并从所述调度服务器中获取所述任务包列表；

(c2)，所述调度服务器从所述任务包列表中选择其中一个任务包，并将该任务包的连接地址返回给所述计算节点，同时记录该任务包的信息并封锁该任务包生存次数自减；

(c3)，所述计算节点根据所述任务包的连接地址下载任务包，解包，并运行主程序中指定的可执行程序进行处理。

本发明中，执行所述步骤(c3)之后还包括：

(c31)，所述调度服务器根据所述计算节点返回的结果处理任务包，并登记处理结束的时间，修改任务包状态，并将已处理的任务包移入已完成列表。

本发明还同时公开了一种分布式资源调度系统，包括服务节点、调度服务器以及多个计算节点，

服务节点，用于将需要处理的任务打包成格式统一的任务包，并将所述任务包发送至所述调度服务器和接收所述调度服务器返回的结果包；

调度服务器，用于接收并管理所述调度服务器发来的任务包，并以预设规则将其分配至所述计算节点，同时将所述计算节点返回的结果包返回至所述服务节点；

计算节点，接收所述调度服务器分配的任务包，并对所述任务包进行处理，并将处理的结果包返回至所述调度服务器。

本发明中，还包括用于管理和配置各个节点和服务器的参数的管理接口，所述管理接口包括管理各个节点模块、新闻处理系统管理模块、股票分析系统管理模块以及文件传输管理模块。

通过采用本发明技术方案，与现有的技术相比，本发明具有如下优点：

本发明的技术方案中，根据本发明，服务节点所需要处理的计算任务只需要提交调度系统，并在计算结束后取回即可，并不占用自身的CPU和内存。

调度服务器只负责任务包的接收，登记，分派，而不需要知道任务包的具体内容，从而使得整个系统的计算可以调度来自任意计算机语言、任意操作系统平台的任务。

计算节点的任务包是由调度服务器分派，故而它在整个系统中的计算任务来源是随机的，它可以计算任意服务节点的任务，并且它本身的运行状态失控不会给系统造成致命的打击，即使在规定时间内不返回结果，该计算任务则会被转而分派给另外的计算节点。

服务节点，计算节点，调度服务器三种角色的设定，可以使系统内计算机分工明确，便于管理，可以使得整个分布式系统的计算任务不受计算机语言、操作系统平台等限制。

附图说明

图1是本发明所述一种分布式资源调度系统的结构示意图。

具体实施方式

本发明涉及一种分布式资源调度系统及其方法，其中资源被打包成与平台无关的文件，该文件经由调度服务器分派到各计算节点，最终亦从计算节点返回结果文件的一种方案。

下面根据附图和具体实施例对本发明作进一步阐述。本发明的实施技术方案如下：

一、跨平台模块共享：

本发明中涉及一种跨平台模块共享实现分布式资源调度的方法，可以实现Windows、Linux/Unix中共享模块的统一调用，其中参数传递和算法与操作系统和编程语言无关。

该方法基于UIMP编程环境开发。UIMP(Unified Image ManipulationProgram)是一套用C++编写的高性能图像处理底层开发环境，内置了函数解析和脚本执行功能。UIMP的核心思想是描述和模块。任何一个函数只要通过描述清楚，则统一由函数引擎解析成内部命令，然后调用相关模块中算法来实现。

模块是可扩展的，只需要将相应的动态链接库(.dll/.so)拷贝到(common/module/open)目录下即可。编写模块也是非常方便的，通过调用UIMP提供的API函数和UIO类，在VC/MINGW32/Borland C++Builder/GCC等C++编译环境中都可以轻松编写。

UIMP软件已经由本专利申请人开发完成，并建有独立的维护和更新网站：http://sourceforge.net/projects/uimp/。

二、打包算法：

打包算法(pack)包括两个独立过程：

1、压缩

把整个目录中文件整和为单一个大文件(含子目录)。

2、解压

将压缩文件重新释放，可理解为解压到指定目录(含子目录)。

本打包程序算法是独创性、并有以下特点：

一、每一个打包文件有个变长的描述信息段，类似下面格式：

；in_type＝file；in_file＝main.ini；bin_len＝83；cmd_len＝4096；

这样可以记录任意多的信息和将来可能的信息段。不同于现有的打包或压缩算法，只是预留了固定长度的固定个数信息段存储空间，难以扩展和自由表达。

二、支持子目录和相对路径

所有的文件和目录都是分开保存的。在压缩时先处理目录，保持原有目录结构树。然后处理文件，保存文件和路径的关系。在解压时先建立目录，恢复原先目录结构树(可以采取相对路径恢复)，随后提取出原始文件。

三、支持可扩充的压缩算法

目前，对所需要压缩的文件，首先使用lz77算法进行压缩，对得到的结果再使用huffman编码的方法进行压缩。同时，因为压缩算法是个独立模块，所以，系统支持扩充或更换新的压缩算法。

四、操作系统独立性

文件压缩和恢复的算法都和操作系统无关。采用二进制流的方式保存文件(非文本方式)，这样保证了数据的完整性。压缩和解压算法会根据具体的操作系统环境(Windows或Unix/Linux)来自动调整目录符号和相对路径。

三、超级监护程序

超级监护程序sd(Super Daemon)兼具两个功能：

1、种子

通过sd可以下载软件包。

2、监管

通过sd可以管理软件包。

常见软件包，列举部分如下：

cnode            计算节点

snode            服务节点

dl_news          定期下载财经新闻

dl_stock         定期下载股票数据

uimp_mini        小型UIMP运行环境

shutdown         远程关机工具

本系统中，通过sd来启动和管理计算节点、服务节点和调度服务器。

下面以计算节点为例，说明sd的管理过程：

第一步，生成帐号密码

第一次运行sd实例(即在一台新节点上运行)。

若帐号不存在，则向调度服务器申请，需要发送本机mac号作为唯一标识，服务器返回自动生成的帐号和随机密码。

申请帐号成功后将相关参数写入本地配置。

第二步登陆服务器

若帐号和密码存在，则登录服务器要求验证；如果验证通过，服务器返回合法进程号。

获得合法的进程号session id(sid)，以后的操作(比如查询任务)皆发送sid表示这次连接。

第三步：设置开机启动项

sd获取任务后通过本地的配置文件(例如sd.ini)来设置开机自启动程序，比如cnode、d1_news等。通过文件传输机制，可以远程修改配置文件来控制启动项。

开机启动项为前述软件包，包括重启等程序均包含在内。sd通过“设置开机启动项”+“自动重启”来控制的运行的程序，并随时向服务器汇报运行状况。

四、分布式计算框架：

如图1所示，先仅仅描述一个最小化的网络结构，其中分为调度服务器、服务节点和计算节点。

1.调度服务器(Dispatch Server)

仅一台，基于linux。

负责整个系统的调度。

假定其IP为10.22.65.130，以下简称130。

2.服务节点(Server Node)

若干台，平台不限。

主要功能是发送和接受任务包。

假定其IP为10.22.65.131，以下简称131。

3.计算节点(Compute Node)

若干台，平台不限。

主要功能是计算分配到的任务包，并把结果返回调度服务器。

假定其IP为10.22.65.137，以下简称137。

4.管理接口(Manage interface)

一台或多台，平台不限。

主要功能是管理和配置各个节点和服务器的参数。

假定其IP为10.22.65.138，以下简称138。

以下对以上分布式资源调度系统的各个组成部分的工作流程进行详细说明。

以下简称：

(1)调度服务器Dispatch Server，主要服务于两方面：

第一，接收并登记服务节点送来的任务包，提供状态查询(例如排队中、运行中，已完成等状态)，将计算节点返回的结果包发送至服务节点。

第二，管理任务包，选择性地发送给计算节点，并接收计算节点返回的结果包。

注：这里的“发送”，“接收”皆为调度服务器的被动行为，实则是由计算节点或服务节点发起的请求。

关于任务包(pak)的管理，每个任务包具有唯一包编号(pak_id)，在服务节点发送过来，调度服务器登记入库时，确定唯一的字符串，由精确到秒的时间戳+6位随机字符串组成，[pak_id].inf保存着pak的属性、优先级等。

本发明优选实施例中将pak的优先级设为0～9，0最低，9最高，等级高表示越紧急。0最低，用来sleep，即空闲任务；9最高，用来升级模块，停止客户机，修改配置等，需要马上响应。1表示初级，用于金融分析，指标计算等用户请求；2表示中级，用于文字聚类，建立索引等系统工作；3表示高级，用于新闻抓取等实时操作；中间4～8可另行调整。

当调度服务器接收到任务请求时从9开始至0扫描，以确定优先级排序的pak列表。先分配从未被分配的任务，接着分配已分配但尚未有返回结果的任务。当一个任务被分配时，将任务相应记录中生存次数减一，如果发现减后小于等于0则表示已经超过最大尝试次数。生存次数默认为5。

调度服务器的功能还包括回应状态查询，包括响应来自服务节点的查询，如果发现此任务task已经完成，则返回结果包，并做相应的后续工作(登记结束时间、修改pak状态、移入已完成列表等)。

(2)计算节点Compute Node：本发明优选实施例中是以win32操作平台为主，接受win32操作平台计算任务，linux操作平台接受相应任务。流程如下：

步骤1：申请任务。计算节点定期主动访问调度服务器，并发送本机信息(包括os，cpp，matlab，python等环境是否支持)和接收数据(调度服务器根据计算节点的信息返回可用pak)。

请求的结果，可以有以下情况：

失败：指网络不可到达，调度服务器无响应等意外情况。

这时按照预设配置文件中规定的时间进行休眠(sleep)。

成功：指调度服务器正常回应请求，成功取得需处理的任务包。

若是没有获取到合适的任务包，或者任务包为空，则自动休息一下。

步骤2：计算节点解压pak，并分析包配置文件main.ini，确定主程序并进行处理。其执行处理的结果包括：

成功：是指pak运行正常，已输出done.ini，但不一定有输出文件。如果有的话，将在done.ini中指定。

失败：是指pak运行失败，并无done.ini输出。

计算节点会根据运行状态报告给调度服务器，并把计算结果打包为结果包提交给调度服务器。

步骤3：调度服务器根据计算节点返回的结果处理pak，并登记结束时间，修改pak状态，然后将其移入已完成列表，等待服务节点来查询并取回结果包。

(3)服务节点：

服务节点的工作流程如下：

本发明优选实施例中将服务节点的操作系统以win32操作平台为主，分以下几个状态：

in           尚未处理的任务包

run          正在计算的包

done         已完成的任务包

服务节点定时扫描输入目录，并依次查询每个pak状态，将状态为in的包发送至调度服务器，发送后将该包状态改为run，并将服务器返回的pak_id加入运行列表run_list。

服务节点定时查询所有run状态的包，返回状态包括：

第一，排队或计算中。表示任务正在计算中，不作处理。

第二，已完成。则服务节点从调度服务器上取回结果包。

第三，错误，错误情况又分为：

a，服务器上显示无此包。这时可以选择重发；

b，pak包有误，可能是程序出错或其它原因，从运行列表run_list中取消此包取消此包，并作记录。

(4)管理接口：

管理接口的主要功能是管理和配置各个节点和服务器的参数。

本发明优选实施例中将服务节点的操作系统以Linux操作平台为主，使用Apache+PHP实现网页方式管理界面，分以下几个模块：

websd        管理各个节点模块(通过超级监护程序)

webmsg       新闻处理系统管理模块

websmb       股票分析系统管理模块

webftp       文件传输管理模块

为了安全传递信息，管理平台支持ssl方式连接。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的权利要求范围之内。

Claims (3)

1.一种分布式资源调度方法，其特征在于，包括如下步骤：

(a)，服务节点将需要处理的任务打包生成格式统一的任务包，并将所述任务包发送至调度服务器；

(b)，所述调度服务器接收并管理所述服务节点发来的任务包，并按照合理的调度算法将其分配至计算节点；

(c)，所述计算节点提取所述调度服务器上的任务包，并对所述任务包进行处理，将处理的结果包发送回所述调度服务器；

其中所述服务器节点的数量至少为一台，所述调度服务器的数量为一台，所述计算节点的数量至少为一台；

所述步骤(a)还包括：

(a1)，将需要处理的程序或任务进行打包，封装为独立任务包文件；

(a2)，将需要处理的任务包放置在预设目录下，并对该目录进行扫描，向所述调度服务器查询每个任务包的状态；

(a3)，根据返回的查询状态，作相应的处理，具体包括：任务正在计算中，不作处理；任务已经完成，则将相应的任务包移入相应的目录下并进行后续操作；任务错误，则选择重发该任务包或取消该任务包；

所述步骤(a2)还包括：

(a4)，扫描预设目录下的每个任务包时，每隔预设时间将其发送至所述调度服务器，发送完毕后，休眠预设时间；

所述步骤(b)还包括：

(b1)，接收并登记所述服务节点发来的任务包，向所述服务节点提供任务包的状态查询；

(b2)，所述调度服务器以优先级为0～9的预设规则将任务包分配给计算节点；

所述步骤(b)还包括：

(b3)，所述调度服务器响应所述服务节点的查询，如果发现该查询的任务包已经完成，则向所述服务节点返回结果包；

所述步骤(c)还包括：

(c1)，计算节点向调度服务器提交本机所支持的运行环境，并从所述调度服务器中获取所述任务包列表；

(c2)，所述调度服务器从所述任务包列表中选择其中一个任务包，并将该任务包的连接地址返回给所述计算节点，同时记录该任务包的信息并使该任务包生存次数自减；

(c3)，所述计算节点根据所述任务包的连接地址下载任务包，解包，并运行主程序中指定的可执行程序进行处理；

执行所述步骤(c3)之后还包括：

(c31)，所述调度服务器根据所述计算节点返回的结果处理任务包，并登记处理结束的时间，修改任务包状态，并将已处理的任务包移入已完成列表。

2.一种分布式资源调度系统，其特征在于，包括服务节点、调度服务器以及多个计算节点，

服务节点，用于将需要处理的任务打包成格式统一的任务包，并将所述任务包发送至所述调度服务器和接收所述调度服务器返回的结果包；其中，将需要处理的程序或任务进行打包，封装为独立任务包文件；将需要处理的任务包放置在预设目录下，并对该目录进行扫描，向所述调度服务器查询每个任务包的状态；扫描预设目录下的每个任务包时，每隔预设时间将其发送至所述调度服务器，发送完毕后，休眠预设时间；根据返回的查询状态，作相应的处理，具体包括：任务正在计算中，不作处理；任务已经完成，则将相应的任务包移入相应的目录下并进行后续操作；任务错误，则选择重发该任务包或取消该任务包；

调度服务器，用于接收并管理所述调度服务器发来的任务包，并以预设规则将其分配至所述计算节点，同时将所述计算节点返回的结果包返回至所述服务节点；其中，接收并登记所述服务节点发来的任务包，向所述服务节点提供任务包的状态查询；所述调度服务器以优先级为0～9的预设规则将任务包分配给计算节点；所述调度服务器响应所述服务节点的查询，如果发现该查询的任务包已经完成，则向所述服务节点返回结果包；

计算节点，接收所述调度服务器分配的任务包，并对所述任务包进行处理，并将处理的结果包返回至所述调度服务器；其中，计算节点向调度服务器提交本机所支持的运行环境，并从所述调度服务器中获取所述任务包列表；所述调度服务器从所述任务包列表中选择其中一个任务包，并将该任务包的连接地址返回给所述计算节点，同时记录该任务包的信息并使该任务包生存次数自减；所述计算节点根据所述任务包的连接地址下载任务包，解包，并运行主程序中指定的可执行程序进行处理；所述调度服务器根据所述计算节点返回的结果处理任务包，并登记处理结束的时间，修改任务包状态，并将已处理的任务包移入已完成列表。。

3.根据权利要求2所述的一种分布式资源调度系统，其特征在于，还包括用于管理和配置各个节点和服务器的参数的管理接口，所述管理接口包括管理各个节点模块、新闻处理系统管理模块、股票分析系统管理模块以及文件传输管理模块。

Images