专利名称：提高商务机群可服务性的方法
技术领域：
本发明涉及一种提高商务机群可服务性的方法，尤其是一种在计算机集群系统中的服务节点上对系统状态进行监控，实现负载的动态均衡的系统及其方法；属于计算机网络技术领域。
背景技术：
在计算机集群环境中，监控节点负责收集各个节点的资源、进程及服务的状态，并根据特定的指令执行启停进程或服务的操作。通常，监控节点只是简单地搜集各个节点在系统中进程的状态，并根据控制节点的指令来启动或停止相应的进程。
实际上，人们主要的目标是使用所有的服务节点提供高可用的服务。所谓服务的可用性是指利用软/硬件资源为用户提供服务的能力；高可用的服务必须是可靠、稳定的，而且响应时间为用户所能接受。而进程状态不是系统服务可用性的唯一决定因素，运行正常的服务节点可能由于某种资源的匮乏而不能提供某种服务。为了避免这种资源匮乏的现象出现，需要对服务节点进行负载均衡。
由于各种因素的限制，现有的负载均衡策略都比较简单。例如轮询法只是循环地把客户端的请求依次转发到各个服务节点上；最少连接数法优先把客户端请求发送到连接数最少的服务节点上；等等。实际上，这些方法并不能实现真正的负载均衡；其主要原因是1)每个服务的连接请求各不相同，有些可能需要消耗大量的资源，连接数目并不能真实地反应服务节点的负载情况；2)服务节点的配置各不相同，由于集群良好的可扩展性，后来扩充的服务节点的资源配备可能比原来的服务节点要好得多；3)每个服务节点中运行的任务各不相同，有些节点可能会提供多个服务，或者运行了大量的进程，资源消耗情况千差万别，而且会随时变换。因此，如果想要实现真正的负载均衡，就必须实时地监控服务节点的状态，根据服务节点的现有处理能力决定如何分发负载；另外，一个服务往往是由一组相关进程共同提供的，这些进程之间通常都存在一定的依赖关系，一旦某个进程出现问题，整个服务将都会受到影响。
在某些环境中，各个服务节点上进程、服务和资源的监控由一个中心控制节点实现，这样处理的优点是控制集中；但是，由于发生故障的服务节点往往不仅仅是一个进程出现问题，而相应的资源往往也会出现匮乏的情况，很可能不能正确处理中心控制节点的命令，最终导致该节点的故障一直得不到恢复。
发明内容
本发明的主要目的在于提供一种提高商务机群可服务性的方法，保障算机集群系统运行稳定可靠、服务高可用，并且具有故障自我恢复能力。
本发明的又一目的在于提供一种提高商务机群可服务性的方法，在所有节点之间实现负载均衡。
本发明的再一目的在于提供一种提高商务机群可服务性的方法，对系统资源进行监控，在资源负荷达到指定的水位线时预警并及时处理，从而最小化系统崩溃的风险。
本发明的目的是这样实现的一种提高商务机群可服务性的方法，客户端与前置节点通信，向前置节点发送其服务请求；各服务节点通过心跳环将本节点的负载信息传递给前置节点，前置节点根据配置信息和收到的负载信息决定出这些服务节点的当前处理能力，并依次对服务节点的优先级进行排序，在客户端请求到达时，按照该排序分配负载。
所述的各服务节点中设有代理模块，用于搜集本节点的负载信息，并将该负载信息通过心跳环发送给前置节点。
所述的服务节点和前置节点中均设有节点服务监控器(LifeGuard)模块，用于监控系统的进程、服务以及资源的状态，具体包括步骤A获取配置信息，启动相关进程和服务；步骤B监控资源、进程、服务状态；步骤C判断系统资源是否达到水位线，如果没有达到则执行步骤E；步骤D向前置节点发送预警信息；执行步骤B；步骤E判断进程、服务是否异常，不异常执行步骤B；步骤F重启进程、服务；步骤G判断重启是否成功，若成功执行步骤B；步骤H向前置节点发送故障信息，重启系统；结束。
上述的服务节点还设有命令执行器(Executor)模块，用于和LifeGuard模块互相监控，实现节点的高可靠运行。
所述的LifeGuard模块监控服务节点中Executor模块的流程如下步骤10系统初始化，启动包括Executor在内的相关进程；步骤11进行节点的正常事务处理；步骤12监控Executor的状态，如果正常则继续执行步骤12；步骤13重新启动该Executor；步骤14进行节点的其他事务处理。
所述的Executor模块监控服务节点中LifeGuard模块的流程如下
步骤20系统初始化，启动包括LifeGuard在内的相关进程；步骤21进行节点的正常事务处理；步骤22监控LifeGuard的状态，如果正常则继续执行步骤12；步骤23重新启动该LifeGuard；步骤24进行节点的其他事务处理。
所述的前置节点定期接收整个心跳环的负载信息，并根据该负载信息控制客户端请求的分发和心跳环的重构。
如果前置节点在规定的时间内未能采集到发生故障节点的心跳信息，则重构整个心跳环，并把故障节点排除在新的心跳环之外，不向该节点分发客户端的服务请求。当出现故障的服务节点恢复之后，可重新申请加入心跳环。
本发明使用LifeGuard和Executor为服务节点提供双重保障，使服务节点具有进程级、应用级以及系统级三种自我恢复能力；使用心跳环传递负载信息，真正实现了负载的动态均衡，并可以避免单个(或部分)服务节点崩溃而导致的服务不可用情况；从而充分利用服务节点的处理能力，为用户提供高可用的服务。
图1为本发明的计算机集群系统构成示意图；图2为本发明中LifeGuard模块监控系统并自动恢复系统的处理流程图；图3为本发明LifeGuard模块对Executor模块的监控流程图；图4为本发明Executor模块对LifeGuard模块的监控流程图；图5为本发明一具体实施例中LifeGuard模块对系统进程、服务及资源监控流程图。
具体实施例方式以下通过具体实施例和附图对本发明进行详细说明。
采用双重监控的计算机集群系统结构如图1，该系统由客户端A、前置节点B、多个服务节点组成。客户端A与前置节点B通信，客户端A的请求都被发送到前置节点B上；采用心跳线将服务节点1、服务节点2......和前置节点B构成一个心跳环，并在每个服务节点上设置一些代理程序，负责搜集本节点的负载信息，并将其通过心跳环传递给前置节点B。前置节点B根据配置信息和搜集到的负载信息决定出这些服务节点的当前处理能力，依次对服务节点的优先级进行排序，在下次客户端请求到达时就按照这个优先级的高低顺序来分配负载，这样，就达到资源的动态平衡，而且可以充分发挥服务节点硬件的处理能力。
采用心跳环机制，除了能传递服务节点的负载信息之外，还有一个功能就是可以实时地发现服务节点的故障。如果一个(或多个)服务节点发生故障，心跳环就会在故障节点处中断。故障节点的下游节点在一定的周期内如果没有接收到上游节点的心跳环负载信息，就向前置节点汇报自己的上游节点出现故障；前置节点接收到汇报之后，会通知故障节点的上、下游节点，分别修改自己的下、上游节点，从而重构整个心跳环，把故障节点排除在新的心跳环之外，而且不向该节点分发服务请求。如果前置节点超时未接收到整个心跳环的负载信息，则按照所有节点新加入心跳环的方式重新构造并初始化整个心跳环。当故障节点恢复之后，可以重新申请加入心跳环。采用这种机制，前置节点就能及时地掌握所有服务节点的负载，动态地实现负载均衡，同时可以避免由于服务节点故障而导致服务不可用的情况出现。
在每个服务节点上设置两个模块LifeGuard模块和Executor模块。LifeGuard模块也部署在前置节点上，负责监控系统的进程、服务以及资源的状态。
不同类型的服务对资源的要求也不同，例如有些应用需要的计算量相当大，这种应用最关心的资源是CPU，而有些应用则对I/O、内存或网络的要求非常苛刻。但是每个服务节点所实际拥有的物理硬件总是有限的，硬件的具体配置情况也不可能适用于所有的应用。极端的情况下，服务节点的大部分资源可能都空闲，但由于另外一种关键资源已经耗光，而导致不能提供服务。因此需要对系统的资源进行监控，并对关键资源设置一个水位线，当系统中该资源的利用率超过水位线之后，就向前置节点报警，前置节点对转发策略进行调整，不再向该服务节点转发这种请求，从而避免耗光该系统的所有资源。
服务的高可用性归根结底来自于服务节点的可用性，而每个服务都是由一系列相关进程提供的，因此保证服务节点上应用服务所依赖的相关进程的可用性是提供高可用性服务的基础。
共同提供服务的进程之间往往存在一定的依赖关系，在启动服务时需要按照特定的次序，先启动依赖进程，再启动本进程，过程如图2所示步骤A获取配置信息，启动相关进程和服务；步骤B监控资源、进程、服务状态；步骤C判断系统资源是否达到水位线，如果没有达到则执行步骤E；步骤D向前置节点发送预警信息；执行步骤B；步骤E判断进程、服务是否异常，不异常执行步骤B；步骤F重启进程、服务；步骤G判断重启是否成功，若成功执行步骤B；步骤H向前置节点发送故障信息，重启系统；结束。
LifeGuard已经成为服务节点可用性的保障，如果LifeGuard一旦发生故障，整个服务节点的自我恢复能力将不复存在。因此本发明采用另外一个模块Executor和Lifeguard互相进行监控，一旦对方出现故障，即可将其主动恢复，其监控的具体实现如图3、图4所示。
LifeGuard模块监控服务节点中Executor模块的流程如下步骤10系统初始化，启动包括Executor在内的相关进程；步骤11进行节点的正常事务处理；步骤12监控Executor的状态，如果正常则继续执行步骤12；步骤13重新启动该Executor；步骤14进行节点的其他事务处理。
Executor模块监控服务节点中LifeGuard模块的流程如下步骤20系统初始化，启动包括LifeGuard在内的相关进程；步骤21进行节点的正常事务处理；步骤22监控LifeGuard的状态，如果正常则继续执行步骤12；步骤23重新启动该LifeGuard；步骤24进行节点的其他事务处理。
本发明LifeGuard模块监控系统并自动恢复系统的流程如图5所示步骤101系统如果收到信号，则执行步骤120，否则按照顺序从步骤102开始执行；步骤102读取节点上运行的服务；步骤103读取需该服务监控的资源；步骤104判断是否有需要监控的资源，若没有执行步骤130；步骤105检查该资源；步骤106资源评价是否正常，若正常，执行步骤111；
步骤107判断该资源是否达到警戒线，若没有达到，执行步骤110；步骤108警戒线处理，调节该资源在所有资源中所占的权重；步骤109通知主节点资源到达警戒线；步骤110读取下一个要监控的资源，执行步骤104；步骤111记录错误，执行步骤110；步骤120判断是否为SIGKILL，如果是则结束；步骤121判断是否为SIGHUP信号，若不是，执行步骤102；步骤122重新读取资源水位设置；执行步骤102；步骤130读取需监控的过程队列；步骤131判断是否有需要监控的进程，若没有，执行步骤136；步骤132检查该进程；步骤133该进程是否异常，若异常，执行步骤135；步骤134恢复该进程；步骤135取下一个需监控的进程，执行步骤131；步骤136判断服务进程是否异常，若无异常，执得步骤138；步骤137向前置节点报告服务故障；步骤138取本节点的下一个服务；步骤139判断是否还有监控的服务；若有，执行步骤103；步骤140休眠等待后执行步骤101。
从以上的流程可以看出LifeGuard模块可以实现三个层次上的自我恢复能力进程级，LifeGuard可以监控所有进程的状态，而与服务有关的进程都是既定的，一旦这些进程出现故障，就可以按照事先预定的策略重新启动进程。
应用级，服务程序通常以服务程序或守护进程的形式出现，有时即使这些服务程序依赖的所有进程都正常，也会有服务不可用的情况发生，例如套接字(socket)端口释放后必须经过一定的延时之后才可用。LifeGuard对应用级程序的处理策略是启用本地客户端或测试程序对应用程序进行测试，如果确定已经不能提供服务，则通知前置节点暂停分发任务，同时重启服务器程序。
系统级在遇到严重错误时，很多程序变得不可用，此时必须重新启动系统才能正常恢复。LifeGuard的策略是使用软件狗(softdog)机制，重启并恢复系统。
最后应说明的是以上实施例仅用以说明本发明而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明进行修改或者等同替换，而不脱离本发明的精神和范围，其均应涵盖在本发明的权利要求范围当中。
权利要求
1.一种提高商务机群可服务性的方法，其特征在于客户端与前置节点通信，向前置节点发送其服务请求；各服务节点通过心跳环将本节点的负载信息传递给前置节点，前置节点根据配置信息和收到的负载信息决定出这些服务节点的当前处理能力，并依次对服务节点的优先级进行排序，在客户端请求到达时，按照该排序分配负载。
2.根据权利要求1所述的提高商务机群可服务性的方法，其特征在于所述的各服务节点中设有代理模块，用于搜集本节点的负载信息，并将该负载信息通过心跳环发送给前置节点。
3.根据权利要求1或2所述的提高商务机群可服务性的方法，其特征在于所述的服务节点和前置节点中均设有LifeGuard模块，用于监控系统的进程、服务以及资源的状态，具体包括步骤A获取配置信息，启动相关进程和服务；步骤B监控资源、进程、服务状态；步骤C判断系统资源是否达到水位线，如果没有达到则执行步骤E；步骤D向前置节点发送预警信息；执行步骤B；步骤E判断进程、服务是否异常，不异常执行步骤B；步骤F重启进程、服务；步骤G判断重启是否成功，若成功执行步骤B；步骤H向前置节点发送故障信息，重启系统；结束。
4.根据权利要求1或2所述的提高商务机群可服务性的方法，其特征在于所述的服务节点还设有Executor模块，用于和LifeGua rd模块互相监控，实现节点的高可靠运行。
5.根据权利要求4所述的提高商务机群可服务性的方法，其特征在于所述的LifeGuard模块监控服务节点中Executor模块的流程如下步骤10系统初始化，启动包括Executor在内的相关进程；步骤11进行节点的正常事务处理；步骤12监控Executor的状态，如果正常则继续执行步骤12；步骤13重新启动该Executor；步骤14进行节点的其他事务处理。
6.根据权利要求4所述的提高商务机群可服务性的方法，其特征在于所述的Executor模块监控服务节点中LifeGuard模块的流程如下步骤20系统初始化，启动包括LifeGuard在内的相关进程；步骤21进行节点的正常事务处理；步骤22监控LifeGuard的状态，如果正常则继续执行步骤12；步骤23重新启动该LifeGuard；步骤24进行节点的其他事务处理。
7.根据权利要求1或2所述的提高商务机群可服务性的方法，其特征在于所述的前置节点定期接收整个心跳环的负载信息，并根据该负载信息控制客户端请求的分发和心跳环的重构。
8.根据权利要求7提高商务机群可服务性的方法，其特征在于如果前置节点在规定的时间内未能采集到发生故障节点的心跳信息，则重构整个心跳环，并把故障节点排除在新的心跳环之外，不向该节点分发客户端的服务请求。
9.根据权利要求7提高商务机群可服务性的方法，其特征在于当出现故障的服务节点恢复之后，可重新申请加入心跳环。
全文摘要
一种提高商务机群可服务性的方法，客户端与前置节点通信，向前置节点发送服务请求；各服务节点通过心跳环将本节点的负载信息传递给前置节点，前置节点根据配置信息和负载信息决定服务节点当前的处理能力，并依次对服务节点进行排序，在客户端请求到达时，按该排序分配负载。该服务节点还设有互相监控的模块，用于实现节点的高可靠运行。本发明为服务节点提供了双重保障，使服务节点具有进程级、应用级和系统级的自我恢复能力；用心跳环传递负载信息，实现了负载的动态均衡，并避免了单个(或部分)服务节点崩溃而导致的服务不可用情况；从而充分利用服务节点的处理能力，为用户提供高可用的服务。
文档编号G06F13/18GK1512363SQ0215949
公开日2004年7月14日 申请日期2002年12月31日 优先权日2002年12月31日
发明者李电森, 冯锐, 黄平, 肖利民 申请人:联想(北京)有限公司