[go: up one dir, main page]

CN1512363A - 提高商务机群可服务性的方法 - Google Patents

提高商务机群可服务性的方法 Download PDF

Info

Publication number
CN1512363A
CN1512363A CNA021594929A CN02159492A CN1512363A CN 1512363 A CN1512363 A CN 1512363A CN A021594929 A CNA021594929 A CN A021594929A CN 02159492 A CN02159492 A CN 02159492A CN 1512363 A CN1512363 A CN 1512363A
Authority
CN
China
Prior art keywords
node
service
serviceability
preposition
planes
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.)
Granted
Application number
CNA021594929A
Other languages
English (en)
Other versions
CN1251103C (zh
Inventor
李电森
冯锐
黄平
肖利民
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Lenovo Beijing Ltd
Original Assignee
Lenovo Beijing Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Lenovo Beijing Ltd filed Critical Lenovo Beijing Ltd
Priority to CN 02159492 priority Critical patent/CN1251103C/zh
Publication of CN1512363A publication Critical patent/CN1512363A/zh
Application granted granted Critical
Publication of CN1251103C publication Critical patent/CN1251103C/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)

Abstract

一种提高商务机群可服务性的方法,客户端与前置节点通信,向前置节点发送服务请求;各服务节点通过心跳环将本节点的负载信息传递给前置节点,前置节点根据配置信息和负载信息决定服务节点当前的处理能力,并依次对服务节点进行排序,在客户端请求到达时,按该排序分配负载。该服务节点还设有互相监控的模块,用于实现节点的高可靠运行。本发明为服务节点提供了双重保障,使服务节点具有进程级、应用级和系统级的自我恢复能力;用心跳环传递负载信息,实现了负载的动态均衡,并避免了单个(或部分)服务节点崩溃而导致的服务不可用情况;从而充分利用服务节点的处理能力,为用户提供高可用的服务。

Description

提高商务机群可服务性的方法
技术领域
本发明涉及一种提高商务机群可服务性的方法,尤其是一种在计算机集群系统中的服务节点上对系统状态进行监控,实现负载的动态均衡的系统及其方法;属于计算机网络技术领域。
背景技术
在计算机集群环境中,监控节点负责收集各个节点的资源、进程及服务的状态,并根据特定的指令执行启停进程或服务的操作。通常,监控节点只是简单地搜集各个节点在系统中进程的状态,并根据控制节点的指令来启动或停止相应的进程。
实际上,人们主要的目标是使用所有的服务节点提供高可用的服务。所谓服务的可用性是指:利用软/硬件资源为用户提供服务的能力;高可用的服务必须是可靠、稳定的,而且响应时间为用户所能接受。而进程状态不是系统服务可用性的唯一决定因素,运行正常的服务节点可能由于某种资源的匮乏而不能提供某种服务。为了避免这种资源匮乏的现象出现,需要对服务节点进行负载均衡。
由于各种因素的限制,现有的负载均衡策略都比较简单。例如:轮询法只是循环地把客户端的请求依次转发到各个服务节点上;最少连接数法优先把客户端请求发送到连接数最少的服务节点上;等等。实际上,这些方法并不能实现真正的负载均衡;其主要原因是: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)机制,重启并恢复系统。
最后应说明的是:以上实施例仅用以说明本发明而非限制,尽管参照较佳实施例对本发明进行了详细说明,本领域的普通技术人员应当理解,可以对本发明进行修改或者等同替换,而不脱离本发明的精神和范围,其均应涵盖在本发明的权利要求范围当中。

Claims (9)

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提高商务机群可服务性的方法,其特征在于:当出现故障的服务节点恢复之后,可重新申请加入心跳环。
CN 02159492 2002-12-31 2002-12-31 提高商务机群可服务性的方法 Expired - Fee Related CN1251103C (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN 02159492 CN1251103C (zh) 2002-12-31 2002-12-31 提高商务机群可服务性的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN 02159492 CN1251103C (zh) 2002-12-31 2002-12-31 提高商务机群可服务性的方法

Publications (2)

Publication Number Publication Date
CN1512363A true CN1512363A (zh) 2004-07-14
CN1251103C CN1251103C (zh) 2006-04-12

Family

ID=34237500

Family Applications (1)

Application Number Title Priority Date Filing Date
CN 02159492 Expired - Fee Related CN1251103C (zh) 2002-12-31 2002-12-31 提高商务机群可服务性的方法

Country Status (1)

Country Link
CN (1) CN1251103C (zh)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1889565B (zh) * 2005-08-16 2010-05-05 华为技术有限公司 会话建立方法
CN101957785A (zh) * 2010-09-20 2011-01-26 中兴通讯股份有限公司 处理故障信息的方法、受控终端和主控终端
CN102137133A (zh) * 2010-01-22 2011-07-27 华为技术有限公司 内容分发的方法、系统及调度服务器
CN102271147A (zh) * 2010-06-03 2011-12-07 北京神州绿盟信息安全科技股份有限公司 信息递送系统和方法
CN101098308B (zh) * 2007-06-26 2012-04-25 华为技术有限公司 网络中节点负载分担的方法及系统
CN102521339A (zh) * 2011-12-08 2012-06-27 北京京东世纪贸易有限公司 用于动态访问数据源的系统和方法
CN101685452B (zh) * 2008-09-26 2012-06-27 阿里巴巴集团控股有限公司 数据仓库调度方法及调度系统
CN102761448A (zh) * 2012-08-07 2012-10-31 中国石油大学(华东) 机群监控与预警方法
CN102779054A (zh) * 2012-06-15 2012-11-14 北京奇虎科技有限公司 应用程序的安装处理方法和装置、以及服务器
CN104182277A (zh) * 2013-05-21 2014-12-03 北大方正集团有限公司 基于多任务系统的分布式系统和方法
CN104410620A (zh) * 2014-11-24 2015-03-11 联想(北京)有限公司 一种信息处理方法及服务器
CN104572395A (zh) * 2014-12-30 2015-04-29 深圳市科漫达智能管理科技有限公司 基于适配器的进程监控方法及装置
CN105208133A (zh) * 2015-10-20 2015-12-30 上海斐讯数据通信技术有限公司 一种服务器、负载均衡器以及服务器负载均衡方法和系统
CN105490868A (zh) * 2015-11-17 2016-04-13 世纪龙信息网络有限责任公司 异地机房数据双向同步监控方法与系统
CN106598738A (zh) * 2016-12-13 2017-04-26 郑州云海信息技术有限公司 一种计算机集群系统及其并行计算方法
CN104301167B (zh) * 2013-07-19 2018-09-04 方正宽带网络服务股份有限公司 一种监测装置及方法
CN111031126A (zh) * 2019-12-10 2020-04-17 江苏满运软件科技有限公司 集群缓存共享方法、系统、设备及存储介质
CN111324464A (zh) * 2020-03-12 2020-06-23 北京首汽智行科技有限公司 一种基于微服务架构的负载分配方法

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1889565B (zh) * 2005-08-16 2010-05-05 华为技术有限公司 会话建立方法
CN101098308B (zh) * 2007-06-26 2012-04-25 华为技术有限公司 网络中节点负载分担的方法及系统
CN101685452B (zh) * 2008-09-26 2012-06-27 阿里巴巴集团控股有限公司 数据仓库调度方法及调度系统
US8443054B2 (en) 2010-01-22 2013-05-14 Huawei Technologies Co., Ltd. Method, system, and scheduling server for content delivery
CN102137133A (zh) * 2010-01-22 2011-07-27 华为技术有限公司 内容分发的方法、系统及调度服务器
WO2011088767A1 (zh) * 2010-01-22 2011-07-28 华为技术有限公司 内容分发的方法、系统及调度服务器
CN102137133B (zh) * 2010-01-22 2015-01-21 华为技术有限公司 内容分发的方法、系统及调度服务器
CN102271147A (zh) * 2010-06-03 2011-12-07 北京神州绿盟信息安全科技股份有限公司 信息递送系统和方法
CN102271147B (zh) * 2010-06-03 2013-12-25 北京神州绿盟信息安全科技股份有限公司 信息递送系统和方法
CN101957785A (zh) * 2010-09-20 2011-01-26 中兴通讯股份有限公司 处理故障信息的方法、受控终端和主控终端
CN102521339B (zh) * 2011-12-08 2014-11-19 北京京东世纪贸易有限公司 用于动态访问数据源的系统和方法
CN102521339A (zh) * 2011-12-08 2012-06-27 北京京东世纪贸易有限公司 用于动态访问数据源的系统和方法
CN102779054A (zh) * 2012-06-15 2012-11-14 北京奇虎科技有限公司 应用程序的安装处理方法和装置、以及服务器
CN102761448A (zh) * 2012-08-07 2012-10-31 中国石油大学(华东) 机群监控与预警方法
CN104182277A (zh) * 2013-05-21 2014-12-03 北大方正集团有限公司 基于多任务系统的分布式系统和方法
CN104301167B (zh) * 2013-07-19 2018-09-04 方正宽带网络服务股份有限公司 一种监测装置及方法
CN104410620A (zh) * 2014-11-24 2015-03-11 联想(北京)有限公司 一种信息处理方法及服务器
CN104572395A (zh) * 2014-12-30 2015-04-29 深圳市科漫达智能管理科技有限公司 基于适配器的进程监控方法及装置
CN104572395B (zh) * 2014-12-30 2019-05-10 深圳市科漫达智能管理科技有限公司 基于适配器的进程监控方法及装置
CN105208133A (zh) * 2015-10-20 2015-12-30 上海斐讯数据通信技术有限公司 一种服务器、负载均衡器以及服务器负载均衡方法和系统
CN105208133B (zh) * 2015-10-20 2018-05-25 上海斐讯数据通信技术有限公司 一种服务器、负载均衡器以及服务器负载均衡方法和系统
CN105490868A (zh) * 2015-11-17 2016-04-13 世纪龙信息网络有限责任公司 异地机房数据双向同步监控方法与系统
CN106598738A (zh) * 2016-12-13 2017-04-26 郑州云海信息技术有限公司 一种计算机集群系统及其并行计算方法
CN111031126A (zh) * 2019-12-10 2020-04-17 江苏满运软件科技有限公司 集群缓存共享方法、系统、设备及存储介质
CN111031126B (zh) * 2019-12-10 2022-08-12 江苏满运软件科技有限公司 集群缓存共享方法、系统、设备及存储介质
CN111324464A (zh) * 2020-03-12 2020-06-23 北京首汽智行科技有限公司 一种基于微服务架构的负载分配方法

Also Published As

Publication number Publication date
CN1251103C (zh) 2006-04-12

Similar Documents

Publication Publication Date Title
CN1251103C (zh) 提高商务机群可服务性的方法
CN1129857C (zh) 多处理器转换装置和主处理器转换方法
CN1595360A (zh) 用于在分布式计算体系结构中执行作业的系统和方法
CN106790565B (zh) 一种网络附属存储集群系统
CN102196039B (zh) 基于云计算的多机器人系统及其实现方法
CN102364448A (zh) 一种计算机故障管理系统的容错方法
CN108632057A (zh) 一种云计算服务器的故障恢复方法、装置及管理系统
CN1317658C (zh) 利用机群节点相互备份的容错方法
CN101996106A (zh) 一种对软件运行状态进行监控的方法
CN103019889A (zh) 分布式文件系统及其故障处理方法
CN1232131C (zh) 无线接入网中基站控制器的备份实现方法及装置
CN109977161A (zh) presto集群的监控系统
WO2009092322A1 (zh) 一种多处理器系统故障恢复的方法及装置
CN1638342A (zh) 用于管理集群系统中的协议网络故障的系统和方法
CN1754153A (zh) 对在os运行时期间发生的系统错误的基于策略的响应
CN101594254B (zh) 一种基于代理技术的网格计算容错系统及方法
CN1508689A (zh) 一种远程获取被监控计算机信息的系统和方法
CN118245269A (zh) Pci设备的故障处理方法及装置、故障处理系统
CN112737934B (zh) 一种集群式物联网边缘网关装置及方法
CN101557307B (zh) 调度自动化系统应用状态管理方法
CN1275476C (zh) 移动通讯系统中使用共享内存的群集系统及其实现方法
CN1512376A (zh) 大型机群系统的集中控制方法
CN1924810A (zh) 一种业务进程的分布式分优先级监控方法
CN100538647C (zh) 多核处理器的业务流处理方法及多核处理器
CN114598591A (zh) 嵌入式平台节点故障恢复系统及方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20060412

Termination date: 20201231

CF01 Termination of patent right due to non-payment of annual fee