CN105592126A - 无代理自动化服务器系统 - Google Patents

Abstract

本发明涉及一种无代理自动化服务器系统，包含两个以上服务器，被配置成能够相互通信、并分别能够与多个客户端进行通信从而对多个客户端执行管理权以管理多个客户端中的作业的执行，其中，当系统中的一个服务器出现运行超载时，运行超载的一个服务器将对应于运行超载部分的作业的管理权移交给运行未超载的另一个服务器。

Description

无代理自动化服务器系统

技术领域

本发明涉及一种无代理自动化服务器系统。

背景技术

信息化程度较高的企业在运维业务中普遍采取了自动化运维的机制。运维人员根据业务内容编制作业，再根据业务流程把各作业集中排序编制成服务，由自动化服务器统一调度。

目前自动化服务器的管理方式有两种，一种是有代理方式，作业执行端安装代理软件，自动化服务器与代理软件通信，再由代理软件调度本机上的作业；另一种是无代理方式，执行端不额外安装任何软件，自动化服务器通过操作系统自带的协议执行端进行通信，调度执行端上的作业。

采用无代理的方式，所有服务都在服务器端统一调度并且进行监控。但其中有一个问题：每一个服务执行以及跟踪监控的系统资源开销比较大。所以为了能保障其他应用的正常运行，自动化服务器限制了同时能够执行的服务个数，比如10个，运行数量超过10个之后会将作业放入待执行队列，等系统空闲后再转入执行。这个时候就需要采取一种负荷分散机制以解决需要大规模执行服务的情况下自动化服务器并发执行数过少的问题。此外，即使并发数在合理范围之内也有可能导致系统资源耗尽，那么也需要一种机制在系统负荷过高，即，本发明中所称的运行超载，的情况下将负荷分散至空余服务器。

相关技术文献

专利文献

专利文献1：日本特開2004-5360

专利文献1提供了一种服务器负荷均衡化的方法。主要解决方法是将服务器的定义信息放置于ServerPool的定义部，同时将服务器的处理状况保存在ServerPool记忆部。分解来自于客户端的请求，将把请求分发给请求到来时负荷最小的服务器。

公知例中，服务器和客户端构成了一套信息系统，有着ServerPool保存服务器的定义信息以及处理状况，然后通过分发来自客户端的请求来达到负荷均衡的目标。但是，由服务器端完成请求的分发需要专门的处理模块，这会导致服务器端系统构成复杂化，增加额外成本。

本发明，并不通过专门的处理模块分发客户端请求，而是服务器本身将作业的管理权移交给其他服务器，以轻量级的开销达到服务器负荷分散的效果。

发明内容

本发明可以解决无代理自动化服务器上因服务执行的并发数限制导致作业进入等待队列或者因服务器负荷过高，即本发明中的运行超载导致作业运行不畅的问题，通过将负荷分散至其他空余的自动化服务器使得服务能够顺利地执行下去。

本发明提供了一种自动化服务器负荷分散的方法。当第1服务器(主处理服务器)负荷过载时自动地将作业管理权移交至第2服务器(空闲服务器)。在有第3、第4等空闲服务器的情况，可按同样机制再次进行负荷分散，最后将作业/服务执行结果同步至最初的主处理服务器。其实现过程主要包含以下四个方面：

1)服务器检测

服务器A每隔一段时间检测同一网域下其他服务器，并将检测到的信息记入本地数据库的服务器状态信息表。

2)负荷状况判断

服务器A进行自身负荷检测：CPU和/或内存使用率，以及作业等待队列。如果作业等待队列中有作业，则将该作业加入待移交作业队列，并将作业状态设为“保留”；如果CPU或内存使用率超过阈值，则将当前执行中的一个作业加入待移交作业队列，并将作业状态设为“中断”。

3)负荷分散

服务器A根据服务器状态信息表确定待移交对象服务器B，然后作成待移交作业的上下文信息。待移交作业队列中，如果作业状态是“保留”，则需获得其前任作业的输出参数；如果作业状态时“中断”，则仅需把后继所有作业作为作业上下文传送。

4)作业继续执行并同步结果

服务器B接收作业上下文信息后把该作业及后继作业存入作业管理DB，同时新起一个作业管理进程，建立与客户端的连接后控制作业的执行。如作业为“保留”，则取消该状态并将输出参数作为该作业的输入参数；如作业为“中断”，则取消该状态继续执行。作业及其后继作业的开始执行时间和结束执行时间以及执行结果同步给服务器A，操作人员便能够在服务器A上监控到负荷分散后作业的执行状况。

本发明涉及一种无代理自动化服务器系统，包含：两个以上服务器，被配置成能够相互通信、并分别能够与多个客户端进行通信从而对所述多个客户端执行管理权以管理所述多个客户端中的作业的执行，其中当所述系统中的一个服务器出现运行超载时，出现所述运行超载的所述一个服务器将对应于所述运行超载部分的作业的管理权移交给所述两个以上服务器中运行未超载的目标服务器。

本发明涉及一种无代理自动化服务器系统，所述运行超载取决于作业的个数超过预先设定的作业个数阈值。

本发明涉及一种无代理自动化服务器系统，所述运行超载取决于所述一个服务器的CPU和/或内存使用率超过预先设定的CPU和/或内存使用率阈值。

这种配置可以解决无代理自动化服务器上因服务执行的并发数限制导致作业进入等待队列或者因服务器运行超载导致作业运行不畅的问题，通过将负荷分散至其他空余的自动化服务器使得服务能够顺利地执行下去。

本发明涉及一种无代理自动化服务器系统，其中，两个以上服务器中的每一个服务器都具有各自的状态表，所述状态表包含所述每一个服务器的作业个数、以及CPU和/或内存使用率，所述每一个服务器的状态表可以被所述两个以上服务器中的其他服务器读取。

通过这种配置，可以使得系统中任意一个服务器都能够读取其他任一服务器的状态表，从而能够从中选出用于移交作业管理权的最合适的目标服务器。

本发明涉及一种无代理自动化服务器系统，当所述一个服务器出现所述运行超载时，所述一个服务器读取所述两个以上服务器中的其他服务器的状态表，其中，当所述其他服务器的状态表中的作业个数都超过作业个数阈值时，则所述一个服务器不对所述其他服务器移交对应于所述运行超载部分的作业的管理权；当所述其他服务器的状态表中的作业个数不都超过作业个数阈值时，若状态表中的作业个数最少的服务器只有一个，则所述一个服务器将对应于所述运行超载部分的作业的管理权移交给状态表中所述作业个数最少的服务器，若状态表中的作业个数最少的服务器有两个以上，则所述一个服务器将对应于所述运行超载部分的作业的管理权移交给空余处理能力最高的服务器。

本发明涉及一种无代理自动化服务器系统，所述空余处理能力是CPU处理能力。

本发明涉及一种无代理自动化服务器系统，所述空余处理能力是内存处理能力。

通过这种优选的负荷分散极制，能够以最分散的方式有效地将作业分配到各个服务器中，实现最大化地利用所有服务器，从而最有效地利用资源。

本发明涉及一种无代理自动化服务器系统，如果所述作业的个数超过预先设定的作业个数阈值，则所述对应于所述运行超载部分的作业的状态被设为保留。

本发明涉及一种无代理自动化服务器系统，如果所述作业的个数超过预先设定的作业个数阈值，则在所述运行超载的所述一个服务器将所述对应于所述运行超载部分的作业的管理权移交给所述目标服务器的同时，将所述对应于所述运行超载部分的作业、所述对应于所述运行超载部分的作业的前任作业的输出参数、以及所述对应于所述运行超载部分的作业的客户端信息移交给所述目标服务器。

本发明涉及一种无代理自动化服务器系统，如果所述一个服务器的CPU和/或内存使用率超过预先设定的CPU和/或内存使用率阈值，则所述对应于所述运行超载部分的作业的状态被设为中断。

本发明涉及一种无代理自动化服务器系统，如果所述一个服务器的CPU和/或内存使用率超过预先设定的CPU和/或内存使用率阈值，则在出现所述运行超载的所述一个服务器将所述对应于所述运行超载部分的作业的管理权移交给所述目标服务器的同时，将所述对应于所述运行超载部分的作业、以及所述对应于所述运行超载部分的作业的客户端信息移交给所述目标服务器。在完成至所述目标服务器的移交之后，被设为所述中断的所述对应于所述运行超载部分的作业被继续执行。

本发明涉及一种无代理自动化服务器系统，当所述运行超载的所述一个服务器将对应于所述运行超载部分的作业的管理权移交给运行未超载的所述目标服务器时，执行所述对应于所述运行超载部分的作业的客户端接收到服务器变更通知。

本发明涉及一种无代理自动化服务器系统，所述两个以上服务器包含一个主服务器和一个以上的副服务器，所述一个以上副服务器中的每一个服务器所管理的多个客户端中的作业的执行情况都被同步给主服务器。

本发明涉及一种无代理自动化服务器系统，操作人员能够在主服务器上监控所述两个以上服务器中的每一个服务器所管理的多个客户端中的作业的执行情况。

本发明涉及一种无代理自动化服务器系统，所述作业的执行情况包含作业开始执行时间、作业结束执行时间、以及作业执行结果。

通过这种配置，可以只在主服务器上连接显示器。由此，用户只需要通过观察连接在主服务器上的显示器就可以知道所有作业的执行情况，从而方便用户观察所有作业的执行情况，并且由于无需在所有副服务器上安装显示器，从而也进一步降低了成本。

本发明涉及一种无代理自动化服务器系统，先判断是否存在作业被设为所述保留，再判断是否存在作业被设为所述中断。

本发明涉及一种无代理自动化服务器系统，当所述目标服务器出现所述对应于运行超载部分的作业的运行超载时，所述目标服务器将所述对应于运行超载部分的作业的管理权优先移交回到所述一个服务器。

附图说明

图1是根据本发明的无代理自动化服务器系统构架图。

图2是根据本发明的检测同网域服务器的流程图。

图3是服务和作业管理模块管理在客户端上执行作业过程的示意图。

图4是根据本发明的判断本服务器负荷状况的流程图。

图5是根据本发明实施负荷分散的流程图。

图6是根据本发明的作业继续执行并同步结果的流程图。

图7是根据本发明的服务器A移交管理权的流程图。

图8是根据本发明的服务器A接收同步信息的流程图。

图9是根据本发明的第一实施例的服务器A-等待队列的示意图。

图10是根据本发明的第一实施例的服务器A-资源负载的示意图。

图11是根据本发明的第二实施例的服务器A执行状况-1的示意图。

图12是根据本发明的第二实施例的服务器A执行状况-2的示意图。

图13是根据本发明的第二实施例的服务器B执行状况的示意图。

图14是根据本发明的第二实施例的服务器C执行状况-1的示意图。

图15是根据本发明的第二实施例的服务器C执行状况-2的示意图。

具体实施方式

根据本发明的具体实施例的无代理自动化服务器系统，包含：两个以上服务器，被配置成能够相互通信、并分别能够与多个客户端进行通信从而对多个客户端执行管理权以管理多个客户端中的作业的执行，其中当系统中的一个服务器出现运行超载时，出现运行超载的一个服务器将对应于运行超载部分的作业的管理权移交给两个以上服务器中运行未超载的目标服务器。

并且，在本发明的实施例中，两个以上服务器中连接有显示器的服务器被作为主服务器，而其他服务器被称为副服务器，这样的话，两个以上服务器可以由一个主服务器和一个以上副服务器组成，其中，主服务器又称为第1服务器或者服务器A，副服务器又称为第2服务器或者服务器B、服务器C等等。应该注意，任意一个服务器均有可能发生或者最先发生超载，与是否为主服务器无关。一个以上副服务器中的每一个服务器所管理的多个客户端中的作业的执行情况都被同步给主服务器。而且，操作人员能够通过连接在主服务器上的显示器来监控两个以上服务器中的每一个服务器所管理的多个客户端中的作业的执行情况。作业的执行情况包含作业开始执行时间、作业结束执行时间、以及作业执行结果。

且本发明中所称的运行超载指的是，作业的并发执行个数超过所限个数，或者CPU使用率和内存使用率超过阈值，即负荷超载。在一个实施例中，如果作业并发执行个数超过所限，作业的状态会设为“保留”，如果CPU、内存的使用率超过阈值，则作业状态会设为“中断”。

运行超载取决于作业的个数超过预先设定的作业个数阈值，或者取决于一个服务器的CPU和/或内存使用率超过预先设定的CPU和/或内存使用率阈值。

在根据本发明的具体实施例的无代理自动化服务器系统中，两个以上服务器中的每一个服务器都具有各自的状态表，状态表包含每一个服务器的作业个数、以及CPU和/或内存使用率，每一个服务器的状态表可以被两个以上服务器中的其他服务器读取。

当一个服务器(例如，主服务器A)出现运行超载时，该一个服务器读取两个以上服务器中的其他服务器(例如，副服务器，如服务器B、C等)的状态表，其中，当其他服务器的状态表中的作业个数都超过作业个数阈值时，则主服务器不对其他服务器移交对应于运行超载部分的作业的管理权；当其他服务器的状态表中的作业个数不都超过作业个数阈值时，若状态表中的作业个数最少的服务器只有一个，则主服务器将对应于运行超载部分的作业的管理权移交给状态表中作业个数最少的服务器，若状态表中的作业个数最少的服务器有两个以上，则主服务器将对应于运行超载部分的作业的管理权移交给空余处理能力最高的服务器。

这里，空余处理能力是CPU处理能力，或者是内存处理能力。

以下根据运行超载的不同情况进行分别的说明。

在运行超载取决于作业的个数超过预先设定的作业个数阈值的情形中，在根据本发明的具体实施例的无代理自动化服务器系统中，如果作业的个数超过预先设定的作业个数阈值，则对应于运行超载部分的作业的状态被设为保留。

如果作业的个数超过预先设定的作业个数阈值，则在运行超载的主服务器将对应于运行超载部分的作业的管理权移交给目标服务器的同时，将对应于运行超载部分的作业、对应于运行超载部分的作业的前任作业的输出参数、以及对应于运行超载部分的作业的客户端信息移交给目标服务器。

在运行超载取决于服务器的CPU和/或内存使用率超过预先设定的使用率阈值的情形中，如果主服务器的CPU和/或内存使用率超过预先设定的CPU和/或内存使用率阈值，则对应于运行超载部分的作业的状态被设为中断。

如果主服务器的CPU和/或内存使用率超过预先设定的CPU和/或内存使用率阈值，则在出现运行超载的主服务器将对应于运行超载部分的作业的管理权移交给目标服务器的同时，将对应于运行超载部分的作业、以及对应于运行超载部分的作业的客户端信息移交给目标服务器。在完成至目标服务器的移交之后，被设为中断的对应于运行超载部分的作业在目标服务器的管理下在该作业对应的客户端被继续执行。

最后，当运行超载的主服务器将对应于运行超载部分的作业的管理权移交给运行未超载的目标服务器时，执行对应于运行超载部分的作业的客户端接收到服务器变更通知。

下面参考附图说明根据本发明的具体实施例的无代理自动化服务器系统的详细运转过程。

作为本发明的一个实施例，在如图1所示的系统中，有五台计算机(Computer)，其中两台为服务器(Server)，三台为客户端(Client)，服务器A(Server，1000)和服务器B(Server，1100)，上有服务和作业的管理模块(ManagerModule,1010)，检测其他服务器的检测模块(DetectionModule，1020)，与其他计算机通信的通信模块(Com-SModule，1030)。在管理模块中又有服务和作业管理DB(ManagerDB，1011)，作业调度模块(SchedulingModule，1012)，服务器A与服务器B的构造完全相同。三台客户端分别为以三种操作系统为平台的计算机，分别为Windows，Linux，Unix。以Windows平台的客户端为例(Client，1200)，其上有用户的业务系统(Businesssystem，1210)，运行的作业(Job，1220)，作业的形态可能是脚本或者命令的组合，与服务器通信的通讯模块(Com-CModule，1230)。其他操作系统平台的客户端，内部构造与之相同。

实施过程：

参考图2至图6，本发明的技术的一个优选的应用过程为：

检测同网域服务器(200)

执行服务和作业(图3)

判断本服务器负荷状况(400)

实施负荷分散(500)

作业继续执行并同步结果(600)

过程说明

1.检测同网域服务器(200)

参考图2，该模块设有开启与关闭开关，分别可由用户手动进行切换。参考如下表1，当开启服务器检测模块时，系统会自行收集同一个网域内其他服务器的信息，具体有

1)主机UUID(UUIDofhost)

2)主机CPU信息(CPUofhost)

3)主机内存信息(Memoryofhost)

4)主机IP地址(IPaddressofhost)

5)主机名(Nameofhost)

6)活动区分(ActiveFlag)

7)负荷信息1-CPU使用率(WorkloadofCPUUsage)

8)负荷信息2-内存使用率(WorkloadofMemUsage)

9)负荷信息3-等待队列(WorkloadofWaitingqueue)

10)负荷信息4-执行队列(WorkloadofRunningqueue)

11)更新时间(Updatetime)

主机UUID	UUID of host
		主机CPU信息	CPU of host
主机内存信息	Memory of host
		主机IP地址	IP address of host
主机名	Name of host
		活动区分	Active Flag
负荷信息1*CPU使用率	Workload*CPU usage
		负荷信息2*内存使用率	Workload2*Mem usage
负荷信息3*等待队列	Workload3*Waiting queue
		负荷信息4*执行队列	Workload4*Running queue
更新时间	Update time

表1.服务器状态信息表

下面参考图2对各个步骤进行说明：

1)检测本服务器状态信息(作为状态表的实例)(201)

检测本服务器的状态信息以便其他服务器读取。服务器的状态信息包括：服务器上的主机UUID，主机CPU，主机内存，主机IP地址，主机名，活动区分，负荷信息，更新时间。其中主机UUID是唯一区分主机的标识信息，活动区分固定设为2(0表示非活动，1表示活动)，负荷信息包括CPU使用率，内存使用率，等待队列，执行队列四个。等待队列的意思是该服务器上处于等待状态的作业队列，执行队列意思是该服务器上处于执行状态的作业队列。更新时间表示最近一次以上信息更新的时间。

检测本地服务器状态信息的命令：

主机IP地址：ifcon图(Linux)，ipcon图(Windows)

主机名：hostname(Linux/Windows)

CPU和/或内存使用率：top(Linux)，WMI接口函数(Windows)

等待队列和执行队列：管理模块所提供的接口

其中主机UUID第一次检测到信息(即建立一条记录)以后就不再做检测，同理主机CPU和主机内存也只做一次检测，因为该信息均为静态信息。主机IP地址和主机名以及活动区分每隔24小时检测更新一次，因为该信息相对静止。CPU和/或内存使用率每隔1分钟检测一次，每隔10分钟对记录更新一次，更新值为10分钟之内每次检测值的平均值，作业队列和执行队列每隔10分钟检测更新一次。

2)将获得的本服务器的状态信息存入本地数据库表(202)

在管理模块的服务与作业管理DB中建立一张服务器状态信息表，将上一步所取得的本服务器状态信息存入该表。每一次获得新的信息都会覆盖旧有信息。

3)检测同一局域网的其他服务器并读取其他服务器的状态信息(203)

检测同一网域，与其他服务器通过SSH或者WMI协议建立连接(SSH和WMI协议是Linux/Unix和Windows操作系统固有的组件)，通过远程连接读取其他服务器在服务器状态信息表里记录的本服务器状态信息(主机UUID，主机IP地址，主机名，活动区分，负荷信息，更新时间)。其中主机UUID是唯一区分主机的标识信息，活动区分意为该主机是否处于开启状态，负荷信息包括CPU使用率，内存使用率，等待队列，执行队列四个。更新时间表示最近一次以上信息更新的时间。

其中主机UUID第一次读取到信息(即建立一条记录)以后就不再做更新，同理主机CPU和主机内存也只做一次读取，因为该信息均为静态信息。主机IP地址和主机名以及活动区分每隔24小时读取更新一次，因为该信息相对静止。CPU和/或内存使用率以及作业队列执行队列则每隔10分钟读取更新一次。

4)将获得的其他服务器的状态信息存入本地数据库表(204)

将上一步所取得的其他服务器的状态信息存入步骤2)所建立的表。每一次获得新的信息都会覆盖旧有信息。

2.执行服务和作业(图3)

参考图3，该过程是服务和作业管理模块管理在客户端上执行作业过程。

管理模块(3100)中有服务和作业管理DB(3110)，脚本池(3120)，作业调度模块(3130)。服务由多个作业按照一定顺序关系串联或者并联构成，每个作业都有挂接的脚本或者命令，脚本或者命令的信息放置于脚本池。作业调度模块从服务和作业管理DB以及脚本池中获得作业执行所必要的信息，与客户端(3200)通过SSH或者WMI协议建立连接，并把脚本和命令信息(3210)通过连接下发客户端，客户端接收到来自作业调度模块的指令后立刻建立一个作业执行进程(3220)，执行下发过来的脚本和命令。客户端执行结束之后将结束信号发送给作业调度模块，获得作业调度模块的反馈后撤销作业执行进程，同时删除脚本，从而完成一个作业的执行。

3.判断本服务器负荷状况(400)

参考图4，该过程根据本服务器检测到的负荷信息来决定是否需要负荷分散，并且确定需要负荷分散的作业对象。

1)读取本服务器的负荷信息(401)

每隔10分钟读取一次服务器状态信息表中关于本服务器的负荷信息。

2)判断等待队列中是否有作业(402)

根据获得的负荷信息中的等待队列数，如果等待队列数不为零，则表明等待队列中有作业存在，需要将这些作业的管理权移交给别的服务器执行。反之则表明没有作业处于等待，返回至下一次读取服务器负荷信息(401)

3)将等待队列中的所有作业转入待移交作业队列并将作业状态设为“保留”(403)

如果等待队列中有作业存在，则将所有作业都转入待移交队列，同时把作业的状态设为“保留”。作业的“保留”状态意味着尚未被执行的作业即使到了执行时间也不会被执行，服务执行在该作业的这一步暂停。

4)判断CPU或者内存使用率超过阈值(404)

根据获得的负荷信息中的CPU和内存的使用率，如果CPU或者内存的使用率超过预设的阈值，则表明本服务器目前负荷过大，需要立刻将执行中的作业的管理权移交以保证当前作业的顺利执行。反之则表明目前服务器负荷正常，不需要负荷分散。

5)将执行中的一个作业转入待移交作业队列并将作业状态设为“中断”(405)

如果系统负荷过高，则需要将当前执行中的一个作业转入移交队列，同时把作业的状态设为“中断”。该作业为当前众多并行执行的作业中选取的一个最有“移交价值”的作业。选取的标准有两个：作业重要程度，后继作业的长度。作业的“中断”状态意味着执行途中的作业被暂停，等待状态的改变以继续执行。

作业的重要程度：

从作业的各种属性以及作业执行的时间段，频率来综合考量其重要程度，重要程度越高，“移交价值”也越高。

优先顺序：

客户端执行平台为Linux大于客户端执行平台为Windows

脚本step数大大于脚本step数小

作业执行时间为核心工作时间大于作业执行时间为非核心工作时间

作业执行频率，年执行大于月执行大于周执行大于日执行

后继作业的长度：

从该作业后面的作业队列数来判断，队列数越长，该作业的“移交价值”就越高。

4.实施负荷分散(500)

参考图5，该过程将待移交队列里的作业的管理权分散至其他服务器。

1)读取待移交队列里的作业(501)

读取(400)里所得到的待移交队列里的作业

2)查询服务器状态信息表以确定移交的目标服务器B(502)

查询本服务器上的服务器状态信息表，选择性能最为强大，负荷最小的服务器(记为服务器B)。选择标准有两个：性能，负荷值。

性能：CPU个数，核数，主频，物理内存总数

负荷：CPU和内存的使用率，等待队列，执行队列

比较方法：确认执行队列中的作业个数，选取执行中的作业个数小于最大数5且数字最小的服务器。当执行中作业个数一样时，则计算服务器的空余处理能力，公式为：

CPU处理能力：CPU个数*核数*主频*(1-CPU使用率)

内存处理能力：物理内存总数*(1-物理内存使用率)

鉴于无代理自动化服务器在客户端执行作业对内存要求较高，优先比较内存处理能力。

3)将需要移交的作业的上下文信息发送给服务器B(503)

参考如下表2，作业上下文信息包括

1)移交源信息1-IP地址(IPAddressoforiginalhost)

2)移交源信息2-主机名(Nameoforiginalhost)

3)待移交作业(Jobneedshift)

4)前任作业输出参数(Outputofpredecessor)

5)后继作业(Listofsuccessor)

6)控制信息1-客户端IP地址(IPAddressofimplementclient)

7)控制信息2-协议种类(Protocolofconnection)

8)控制信息3-访问的用户名/密码(Username/passwordofconnection)

移交源信息1*IP地址	IP Address of original host
		移交源信息2*主机名	Name of original host
待移交作业	Job need shift
		前任作业输出参数	Output of predecessor
后继作业	List of successor
		控制信息1*客户端IP地址	IP Address of implement client
控制信息2*协议种类	Protocol of connection
		控制信息3*访问的用户名/密码	Username/password of connection

表2.作业上下文信息

参考图7，该步骤的具体流程如子流程服务器A移交管理权(700)所示

1)读取待移交队列中的一个作业(701)，记为作业a

2)根据该作业的状态分为两条处理路线：作业状态为“保留”(702)，作业状态为“中断”(703)。

3)作业状态为“保留”时，从作业管理DB中获取该作业的前任作业(704)。作业管理DB记录着该服务器上所有服务与作业的信息和状态。

4)判断前任作业是否空(706)。

5)如果前任作业为空，获取服务的输入参数(708)。前任作业为空意味着作业a是该服务的第一个作业，作业a的输入参数就是服务的输入参数，则获取服务的输入参数作为作业a的输入参数。如果前任作业不为空(707)，则获取前任作业的输出参数，作为作业a的输入参数。因为作业a最初是来自于等待队列，其前任作业必然处于完成状态，因此前任作业已经产生了输出参数。

6)作业状态为“中断”时，将管理权的变更通知作业a的客户端(705)。因为作业在客户端执行途中被中断，管理权转变之后由服务器B恢复作业在客户端的执行，客户端需要知道这一转变才能够正确接收来自服务器B的指令。

7)从作业管理DB中获取所有后继作业的信息(709)。作业a及其所有后继作业的管理权都将移交，以切实减轻服务器A的负荷。

8)将上述上下文信息传递给目标服务器(710)，记为服务器B。移交源信息包含服务器A的IP地址和服务器A的主机名，这个信息需要告知服务器B以便服务器B恢复作业执行后与服务器A作信息同步。待移交作业，前任作业输出参数，后继作业保证了服务器B能够顺利执行作业a及其之后作业。控制信息包含客户端的IP地址，协议种类，以及连接用的用户名密码，服务器B接管作业管理权之后根据这些信息与客户端建立连接。

9)循环读取下一个待移交的作业(711)。

5.作业继续执行并同步结果(600)

参考图6，服务器B接收到来自服务器A的作业上下文信息，新起管理进程以恢复作业在客户端的执行，并且将作业执行结果和服务器A进行同步。

参考如下表3，同步的信息包含

1)作业名(Jobname)

2)作业开始执行时间(Workstarttime)

3)作业结束执行时间(Workendtime)

4)作业执行结果(Workimplementresult)

作业开始执行时间	Work start time
		作定结束执行时间	Work end time
作业执行结果	Work implement result

表3.服务器B与服务器A同步的信息

1)获取作业上下文信息。接收到来自服务器A的作业上下文信息，读入系统。(601)

2)将该作业以及后继作业存入作业管理DB。因为服务器B将要从作业a开始执行整个作业流程，所以将作业a及其后的作业流程存入服务器B的作业管理DB，以便管理执行。(602)

3)新建作业管理进程。服务器B创建作业管理的进程。(603)

4)与客户端建立连接。从作业上下文信息中获得客户端地址，连接协议，用户名密码，建立SSH/WMI协议的连接。(604)

5)将该作业的“保留”状态取消。(605)如果作业a的状态为“保留”，则取消该状态。

6)以输出参数作为该作业的输入参数执行该作业，并同步作业开始执行时间至服务器A。

(607)开始执行作业a，同时把管理DB中记录的作业a开始执行的时间发送给服务器A。

7)将该作业的“中断”状态取消，作业继续执行。(606)服务器B向客户端发送指令，指示作业a继续执行。

8)当该作业执行完毕后，同步作业执行结束时间和作业执行结果至服务器A。(608)作业a执行完毕后，服务器B把管理DB中记录的作业a执行结束的时间和作业a执行结果发送给服务器A。服务器A接收到来自服务器B关于作业执行的同步信息后，更新自身的管理DB。

参考图8，服务器A接收同步信息直到服务的最后一个作业执行完毕。(800)

1)服务器A从服务器B接收作业的执行结束时间和执行结果，更新自身的管理DB。(801)

2)判断当前接收到的作业是否为服务的最后一个作业，即判断后继作业是否为空。(802)

3)如果是服务的最后一个作业，则把该作业的执行结束时间作为服务的执行结束时间，并且把服务状态设为执行完毕。(803)如果不是服务的最后一个作业，则继续接收作业的同步信息。

设有三台服务器A和B和C，配置信息如下：

服务器A：1CPU，4Core/CPU，8GMem。主机名ServerA，IP地址：192.168.0.101

UUID：9ADAAB4DDAAB250

服务器B：2CPU，4Core/CPU，16GMem。主机名ServerB，IP地址：192.168.0.102

UUID：B2FCDCFBFCDCBAB5

服务器C：2CPU，4Core/CPU，8GMem。主机名ServerC，IP地址：192.168.0.103

UUID：0638C03038C02093

实施例1：A处于作业执行中，B和C处于无任何额外程序运行的空闲状态。之后服务器A由于负荷过高，采取负荷分散将作业管理权交给其他服务器。

1.服务器A开启检测，得到服务器状态信息表，如表4所示

主机UUID	9ADAAB4DDAAB250	B2FCDCFBFDCBAB5	0638C03038C02093
				主机名	ServerA	ServerB	ServerC
主机IP地址	192.168.0.101	192.168.0.102	192.168.0.103
				主机CPU信息	1*4	2*4	2*4
主机内存信息	8G	16G	8G
				活动区分	2	1	1
负荷信息1*CPU使用率	15％	12％1	2％
				负荷信息2*内存使用率	25％	30％	20％
负荷信息3*等待队列	0	0	0
				负荷信息4*执行队列	5	0	0
更新时间	2014-9-16 12:00	2014-9-16 12:00	2014-9-16 12:00

表4.服务器A的状态信息表

服务器B和C开启检测，同样得到如上的服务器状态信息表，只是记录顺序和活动区分略不同，其他字段一样。

2.负荷分散，分为两种情况：

1)服务器A产生等待队列

参考图9，举例来说，服务器A的最大同时执行作业数为5。然而，服务器A的最大同时执行作业数可以是任意数目，而并不局限于本实施例中具体列举的数目。如图9所示，服务1～5开始在t1时刻同时启动执行，首先执行a1～a5，为简化流程，在本实施例中，每个作业执行所需时间相同。然而，各个作业执行所需时间可以是不同的，且并不局限于本实施例。作业a1～a5在t2时刻执行结束，并开始执行b1～b5的作业。然而，服务4中b4开始执行的同时，因为作业的逻辑关系，d4也开始执行，此时由于最大同时执行数为5的限制，服务5中的b5不得不进入等待队列。因此服务器A在下一个检测时刻，服务器状态信息表中服务器A记录的负荷信息*等待队列由0变为了1。

服务器A读取本机的服务器状态信息表，发现等待队列中的作业b5，立刻将b5的状态设为“保留”，并转入待移交队列。

服务器A读取本机的服务器状态信息表，从备选服务器B和C中挑选移交对象。如表4所示，虽然服务器C的CPU使用率不高于服务器B的CPU使用率，但服务器B的内存可用数高于服务器C，则确定把服务器B作为移交对象。

服务器A作成作业b5的作业上下文信息，如表5所示。

移交源信息1*IP地址	192.168.0.101
		移交源信息2*主机名	ServerA
待移交作业	b5
		前任作业输出参数	a5*para1*para2
后继作业	c5
		控制信息1*客户端IP地址	192.168.0.201
控制信息2*协议种类	SSH
		控制信息3*访问的用户名/密码	admin/passAdmin

表5.作业b5的上下文信息

该表中，前任作业输出参数为para1和para2，后继作业为c5，执行作业b5的客户端B的IP地址为192.168.0.201，协议种类是SSH，连接的用户名密码是admin/passAdmin。

服务器B接收作业b5的上下文信息，把作业b5和作业c5存入服务器B的管理DB中，随后新建作业管理执行进程，与客户端B建立SSH连接，下发作业b5的脚本连同a5的输出参数para1和para2给客户端B，同时在管理DB中将b5的“保留”状态取消，b5开始执行。此时服务器B的管理DB中记录了b5开始执行的时刻，服务器B把这个更新信息发送给服务器A。待b5执行结束，服务器B的管理DB又会记录b5结束执行的时刻，服务器B又把这个更新信息连同b5执行完毕的结果发送给服务器A。服务器A接收到b5的同步信息，立刻更新自身的管理DB。

服务器B执行完作业b5后，继续执行作业c5(于客户端C)，同理同步信息给服务器A。待c5执行完毕后同样把结束信息同步给服务器A。服务器A收到后判断c5是服务5的最后一个作业，于是把c5执行结束时间设为服务5的执行结束时间，并且把服务5的状态设为执行完毕。

2)服务器A资源负载过高

参考图10，举例来说，服务器A的最大同时执行作业数为5。然而，服务器A的最大同时执行作业数可以是任意数目，而并不局限于本实施例中具体列举的数目。如图10所示，服务1～5开始在t1时刻同时启动执行，首先执行a1～a5，为简化流程，在本实施例中，每个作业执行所需时间相同。然而，各个作业执行所需时间可以是不同的，且并不局限于本实施例。作业a1～a5在t2时刻执行结束，并开始执行b1～b5的作业。然而，在b1～b5开始执行一段时间后的t21时刻，服务器A上新开始执行进程p，进程p为高耗资源进程，如启动一个虚拟机。故服务器A的CPU和内存的使用率上升至80％，超过用户所设阈值的75％，需要将服务1～5正在执行的作业b1～b5中选出一个作业，将其管理执行权移交给其他服务器。

对于作业b1～b5，在本实施例中，举例来说，均为相同作业(即执行平台，执行step数，执行时间相同)。然而，作业b1～b5可以是不同的作业，且并不局限于本实施例。但b5的后继作业长度为2(c5，d5)，所以确定b5为待移交作业，转入待移交队列。同时将b5的状态设为“中断”，此时服务器A会发送中断指令给客户端B，客户端B中断执行作业b5。

服务器A读取本机的服务器状态信息表，从备选服务器B和C中挑选移交对象。如表4所示，虽然服务器C的CPU使用率不高于服务器B的CPU使用率，但服务器B的内存可用数高于服务器C，则确定把服务器B作为移交对象。根据服务器状态信息表确定服务器B为移交对象。同时服务器A会把服务器B的认证信息(如IP地址)通知客户端B。

如表6所示为示例的服务器A作成作业b5的作业上下文信息。

移交源信息1*IP地址	192.168.0.101
		移交源信息2*主机名	ServerA
待移交作业	b5
		前任作业输出参数	(NULL)
后继作业	c5*d5
		控制信息1*客户端IP地址	192.168.0.201
控制信息2*协议种类	SSH
		控制信息3*访问的用户名/密码	admin/passAdmin

表6.作业b5的上下文信息

该表中，前任作业输出参数为空，因为作业b5已然在客户端B中执行，故不需要输出参数作为b5

的输入参数。后继作业为c5和d5，执行作业b5的客户端B的IP地址为192.168.0.201，协议种类是SSH，连接的用户名密码是admin/passAdmin。

服务器B接收作业b5的上下文信息，把作业b5和作业c5和作业d5存入服务器B的管理DB中，随后新建作业管理执行进程，与客户端B建立SSH连接。服务器B将b5的“中断”状态取消，同时发送恢复执行的指令给客户端B。因客户端B先前得到来自服务器A关于移交对象服务器B的信息，所以接受来自服务器B的恢复指令，作业b5继续执行。待b5执行结束，服务器B的管理DB又会记录b5结束执行的时刻，服务器B又把这个更新信息连同b5执行完毕的结果发送给服务器A。服务器A接收到b5的同步信息，立刻更新自身的管理DB。

服务器B执行完作业b5后，继续执行作业c5(于客户端C)，作业d5(于客户端D)，同理同步信息给服务器A。待d5执行完毕后同样把结束信息同步给服务器A。服务器A收到后判断d5是服务5的最后一个作业，于是把d5执行结束时间设为服务5的执行结束时间，并且把服务5的状态设为执行完毕。

实施例2：A和B和C均处于作业执行中。之后服务器A由于负荷过高，采取负荷分散将作业管理权交给服务器B。服务器B在执行剩余作业时又遇到自身负荷过高，继而把剩余作业再次转交给其他服务器。

1.服务器A开启检测，得到服务器状态信息表

主机UUID	9ADAAB4DDAAB250	B2FCDCFBFCDCBAB5	0638C03038C02093
				主机名	ServerA	ServerB	ServerC
主机IP地址	192.168.0.101	192.168.0.102	192.168.0.103
				主机CPU信息	1*4	2*4	2*4
主机内存信息	8G	16G	8G
				活动区分	2	1	1
负荷信息1*CPU使用率	45％	22％	18％
				负荷信息2*内存使用率	55％	35％	25％
负荷信息3*等待队列	0	0	0
				负荷信息4*执行队列	5	1	2
更新时间	2014-16 12:00	2014-9-16 12:00	2014-9-16 12:00

表7.服务器A的状态信息表

服务器B和C开启检测，同样得到如上的服务器状态信息表，只是记录顺序和活动区分略不同，其他字段一样

2.负荷分散，分为两种情况：

1)服务器B再次转交的对象为服务器A

参考图11、13和14，举例来说，服务器A、B和C的最大同时执行作业数为5。然而，服务器A、B和C的最大同时执行作业数可以是任意数目，而并不局限于本实施例中具体列举的数目。如图11所示，服务1～5开始在t1时刻同时启动执行，首先执行a1～a5，作业a1～a5在t2时刻执行结束，并开始执行b1～b5的作业。然而，服务4中b4开始执行的同时，因为作业的逻辑关系，d4也开始执行，此时由于最大同时执行数为5的限制，服务5中的b5不得不进入等待队列。因此服务器A在下一个检测时刻，服务器状态信息表中服务器A记录的负荷信息*等待队列由0变为了1。

服务器A读取本机的服务器状态信息表，发现等待队列中的作业b5，立刻将b5的状态设为“保留”，并转入待移交队列。

服务器A读取本机的服务器状态信息表，因服务器B的执行队列数比服务器C少，因此优先选择服务器B作为移交对象。

服务器A作成作业b5的作业上下文信息，如表5所示。

服务器B接收作业b5的上下文信息，把作业b5和作业c5存入服务器B的管理DB中，随后新建作业管理执行进程，与客户端B建立SSH连接，下发作业b5的脚本连同a5的输出参数para1和para2给客户端B，同时在管理DB中将b5的“保留”状态取消，b5开始执行。此时服务器B的管理DB中记录了b5开始执行的时刻，服务器B把这个更新信息发送给服务器A。

然而b5执行结束后的t3时刻，原本服务器B上执行中的服务6的作业b6也执行结束，作业b6的后继作业c6，d6，e6，f6，g6有五个，这样使得服务器B达到了作业最大同时执行数5，作业b5的后继c5不得不进入等待队列。

服务器B读取本机的服务器状态信息表，t3时刻服务器A的执行队列为4，服务器C的执行队列为2，但是根据b5的作业上下文信息中的移交源信息，c5移交对象优先选择服务器A。(即c5的管理权返回服务器A)

移交源信息1*IP地址	192.168.0.101
		移交源信息2*主机名	ServerA
待移交作业	c5
		前任作业输出参数	b5*para1*para2
后继作业	(Null)
		控制信息1*客户端IP地址	192.168.0.201
控制信息2*协议种类	SSH
		控制信息3*访问的用户名/密码	admin/passAdmin

表8.作业c5的上下文信息

服务器A获得返还的作业c5的管理权，根据服务器B传来的作业上下文信息，如表8所示，特别是作业b5的输出参数，t3时刻开始执行作业c5。因作业c5最初的管理者是服务器A，故c5的信息不必同步。

c5执行结束后服务5即执行完毕。

2)服务器B再次转交的对象为服务器C

参考图12、13和15，在本实施例中，服务器A、B和C的最大同时执行作业数均为5。然而，服务器A、B和C的最大同时执行作业数可以是任意数目，而并不局限于本实施例中具体列举的数目。如图12所示，服务1～5开始在t1时刻同时启动执行，首先执行a1～a5，作业a1～a5在t2时刻执行结束，并开始执行b1～b5的作业。然而，服务4中b4开始执行的同时，因为作业的逻辑关系，d4也开始执行，此时由于最大同时执行数为5的限制，服务5中的b5不得不进入等待队列。因此服务器A在下一个检测时刻，服务器状态信息表中服务器A记录的负荷信息*等待队列由0变为了1。

服务器A读取本机的服务器状态信息表，发现等待队列中的作业b5，立刻将b5的状态设为“保留”，并转入待移交队列。

服务器A读取本机的服务器状态信息表，因服务器B的执行队列数比服务器C少，因此优先选择服务器B作为移交对象。

服务器A作成作业b5的作业上下文信息，如表5所示。

服务器B接收作业b5的上下文信息，把作业b5和作业c5存入服务器B的管理DB中，随后新建作业管理执行进程，与客户端B建立SSH连接，下发作业b5的脚本连同a5的输出参数para1和para2给客户端B，同时在管理DB中将b5的“保留”状态取消，b5开始执行。此时服务器B的管理DB中记录了b5开始执行的时刻，服务器B把这个更新信息发送给服务器A。

然而b5执行结束后的t3时刻，原本服务器B上执行中的服务6的作业b6也执行结束，作业b6的后继作业c6，d6，e6，f6，g6有五个，这样使得服务器B达到了作业最大同时执行数5，作业b5的后继c5不得不进入等待队列。

服务器B读取本机的服务器状态信息表，t3时刻服务器A的执行队列为5，服务器C的执行队列为2，服务器A达到最大同时执行数，所以c5移交对象选择服务器C。

服务器C接收来自服务器B的作业c5的作业上下文信息，如表8所示，特别是作业b5的输出参数，t3时刻开始执行作业c5。服务器C开始执行c5时根据c5的移交源信息，把开始执行时间同步给服务器A，待c5执行完毕后又将执行结束时间和执行结果同步给服务器A。

服务器A接收到c5执行的同步信息，因c5是服务5最后一个作业，故c5执行结束即服务5执行完毕。

Claims (18)

1.一种无代理自动化服务器系统，其特征在于，包含：

两个以上服务器，被配置成能够相互通信、并分别能够与多个客户端进行通信从而对所述多个客户端执行管理权以管理所述多个客户端中的作业的执行，其中

当所述系统中的一个服务器出现运行超载时，出现运行超载的所述一个服务器将对应于运行超载部分的作业的管理权移交给所述两个以上服务器中运行未超载的目标服务器。

2.如权利要求1所述的无代理自动化服务器系统，其特征在于，

所述运行超载取决于作业的个数超过预先设定的作业个数阈值。

3.如权利要求1所述的无代理自动化服务器系统，其特征在于，

所述运行超载取决于所述一个服务器的CPU和/或内存使用率超过预先设定的CPU和/或内存使用率阈值。

4.如权利要求2或3所述的无代理自动化服务器系统，其特征在于，

两个以上服务器中的每一个服务器都具有各自的状态表，所述状态表包含所述每一个服务器的作业个数、以及CPU和/或内存使用率，所述每一个服务器的状态表可以被所述两个以上服务器中的其他服务器读取。

5.如权利要求4所述的无代理自动化服务器系统，其特征在于，

当所述一个服务器出现所述运行超载时，所述一个服务器读取所述两个以上服务器中的其他服务器的状态表，其中，

当所述其他服务器的状态表中的作业个数都超过作业个数阈值时，则所述一个服务器不对所述其他服务器移交对应于所述运行超载部分的作业的管理权；

当所述其他服务器的状态表中的作业个数不都超过作业个数阈值时，

若状态表中的作业个数最少的服务器只有一个，则所述一个服务器将对应于所述运行超载部分的作业的管理权移交给状态表中所述作业个数最少的服务器，

若状态表中的作业个数最少的服务器有两个以上，则所述一个服务器将对应于所述运行超载部分的作业的管理权移交给空余处理能力最高的服务器。

6.如权利要求5所述的无代理自动化服务器系统，其特征在于，

所述空余处理能力是CPU处理能力。

7.如权利要求5所述的无代理自动化服务器系统，其特征在于，

所述空余处理能力是内存处理能力。

8.如权利要求1、2、4-7中任一项所述的无代理自动化服务器系统，其特征在于，

如果所述作业的个数超过预先设定的作业个数阈值，则所述对应于所述运行超载部分的作业的状态被设为保留。

9.如权利要求8所述的无代理自动化服务器系统，其特征在于，

如果所述作业的个数超过预先设定的作业个数阈值，则在所述运行超载的所述一个服务器将所述对应于所述运行超载部分的作业的管理权移交给所述目标服务器的同时，将所述对应于所述运行超载部分的作业、所述对应于所述运行超载部分的作业的前任作业的输出参数、以及所述对应于所述运行超载部分的作业的客户端信息移交给所述目标服务器。

10.如权利要求1、3-7中任一项所述的无代理自动化服务器系统，其特征在于，

如果所述一个服务器的CPU和/或内存使用率超过预先设定的CPU和/或内存使用率阈值，则所述对应于所述运行超载部分的作业的状态被设为中断。

11.如权利要求10所述的无代理自动化服务器系统，其特征在于，

如果所述一个服务器的CPU和/或内存使用率超过预先设定的CPU和/或内存使用率阈值，则在出现所述运行超载的所述一个服务器将所述对应于所述运行超载部分的作业的管理权移交给所述目标服务器的同时，将所述对应于所述运行超载部分的作业、以及所述对应于所述运行超载部分的作业的客户端信息移交给所述目标服务器。

12.如权利要求11所述的无代理自动化服务器系统，其特征在于，

在完成至所述目标服务器的移交之后，被设为所述中断的所述对应于所述运行超载部分的作业被继续执行。

13.如权利要求1所述的无代理自动化服务器系统，其特征在于，

当所述运行超载的所述一个服务器将对应于所述运行超载部分的作业的管理权移交给运行未超载的所述目标服务器时，执行所述对应于所述运行超载部分的作业的客户端接收到服务器变更通知。

14.如权利要求1所述的无代理自动化服务器系统，其特征在于，

所述两个以上服务器包含一个主服务器和一个以上的副服务器，所述一个以上副服务器中的每一个服务器所管理的多个客户端中的作业的执行情况都被同步给主服务器。

15.如权利要求14所述的无代理自动化服务器系统，其特征在于，

操作人员能够在主服务器上监控所述两个以上服务器中的每一个服务器所管理的多个客户端中的作业的执行情况。

16.如权利要求14-15所述的无代理自动化服务器系统，其特征在于，

所述作业的执行情况包含作业开始执行时间、作业结束执行时间、以及作业执行结果。

17.如权利要求9或12所述的无代理自动化服务器系统，其特征在于，

先判断是否存在作业被设为所述保留，再判断是否存在作业被设为所述中断。

18.如权利要求1所述的无代理自动化服务器系统，其特征在于，

当所述目标服务器出现所述对应于运行超载部分的作业的运行超载时，所述目标服务器将所述对应于运行超载部分的作业的管理权优先移交回到所述一个服务器。