数据集群中的节点管理方法、装置及存储介质与流程

1.本技术涉及大数据技术领域，尤其涉及数据集群中的节点管理方法、装置及存储介质。


背景技术：

2.在大数据技术领域中，大数据集群的资源调度系统(hadoop yet another resource negotiator，hadoop yarn)负责系统的资源管理和调度工作，近年来已经成为大数据资源管理的事实上的标准，支持了并行计算编程模型(mapreduce)、大数据计算框架(spark)、流式计算框架(flink)、dag作业的分布式执行框架(tez)等诸多计算引擎。yarn中分为全局资源管理器(resouce manager，rm)和节点管理器(node manager，nm)角色，rm主要负责全局的分配和管理，nm负责单个节点的资源分配和管理。
3.随着集群规模的不断扩大，在集群资源管理中，节点异常事件总会发生，在目前相关技术中，对集群资源中出现的异常节点的管理主要通过nm自带的健康状态监测机制，默认提供磁盘损坏情况检测，同时也支持用户自定义监测脚本。
4.然而，现有的节点异常的检测方式对异常节点的识别不够准确，导致大数据集群的调度稳定性不高，因此，如何提高大数据集群的调度稳定性成为目前亟待解决的问题。


技术实现要素：

5.本技术提供数据集群中的节点管理方法、装置及存储介质，该节点管理方法可以提高识别大数据集群中异常节点的准确性，进而提升大数据集群的调度稳定性。
6.第一方面，本技术提供一种数据集群中的节点管理方法，应用于资源管理器，所述方法包括：获取至少一个应用程序管理器发送的至少一个异常节点信息和至少一个节点管理器发送的至少一个任务运行信息，所述至少一个异常节点信息指示的节点是与所述至少一个节点管理器连接的多个节点中的节点，所述至少一个任务运行信息包括在所述多个节点中的任意一个节点运行失败的目标任务的运行信息；根据所述至少一个异常节点信息和所述至少一个任务运行信息，从所述多个节点中确定目标异常节点；对所述多个节点中的正常节点进行任务调度，所述正常节点为所述多个节点中除去所述目标异常节点中的部分或全部异常节点外的节点。
7.在本技术实施例中，资源管理器获取来自应用程序管理器的异常节点信息和来自节点管理器的任务运行信息，综合确定目标异常节点，进而对除去目标异常节点中的部分或全部异常节点外的节点进行任务调度，这种综合应用程序管理器、节点管理器和资源管理器三个组件来参与确定目标异常节点的方法，可以提高识别大数据集群中异常节点的准确性，进而提升大数据集群的调度稳定性。
8.第二方面，本技术提供一种数据集群中的节点管理方法，应用于节点管理器，所述方法包括：获取至少一个任务运行信息，所述至少一个任务运行信息包括在与所述节点管理器连接的多个节点中的任意一个节点运行失败的目标任务的运行信息；向资源管理器发
送所述至少一个任务运行信息。
9.第三方面，本技术提供一种数据集群中的节点管理装置，应用于资源管理器，所述装置包括：获取模块，用于获取至少一个应用程序管理器发送的至少一个异常节点信息和至少一个节点管理器发送的至少一个任务运行信息，所述至少一个异常节点信息指示的节点是与所述至少一个节点管理器连接的多个节点中的节点，所述至少一个任务运行信息包括在所述多个节点中的任意一个节点运行失败的目标任务的运行信息；确定模块，用于根据所述至少一个异常节点信息和所述至少一个任务运行信息，从所述多个节点中确定目标异常节点；调度模块，用于对所述多个节点中的正常节点进行任务调度，所述正常节点为所述多个节点中除去所述目标异常节点中的部分或全部异常节点外的节点。
10.第四方面，本技术提供一种数据集群中的节点管理装置，应用于节点管理器，所述装置包括：获取模块，用于获取至少一个任务运行信息，所述至少一个任务运行信息包括在与所述节点管理器连接的多个节点中的任意一个节点运行失败的目标任务的运行信息；发送模块，用于向资源管理器发送所述至少一个任务运行信息。
11.第五方面，本技术提供一种数据集群中的节点管理装置，包括处理器和存储器，所述存储器用于存储代码指令；所述处理器用于运行所述代码指令，以实现上述第一方面或第二方面或其中任一种可能实现方式中的方法。
12.第六方面，本技术提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序(也可以称为代码，或指令)当其在计算机上运行时，使得计算机执行上述第一方面或第二方面或其中任一种可能实现方式中的方法。
13.第七方面，本技术提供一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当计算机程序被运行时，使得计算机执行上述第一方面或第二方面或其中任一种可能实现方式中的方法。
附图说明
14.图1是本技术一个实施例提供的yarn调度系统的结构示意图；
15.图2为本技术一个实施例提供的数据集群中的节点管理方法的流程图；
16.图3为本技术另一个实施例提供的数据集群中的节点管理方法的流程图；
17.图4为本技术一个实施例提供的由应用程序黑名单确定集群全局黑名单的示意图；
18.图5为本技术又一个实施例提供的数据集群中的节点管理方法的流程图；
19.图6为本技术一个实施例提供的数据集群中的节点管理装置的结构示意图；
20.图7为本技术另一个实施例提供的数据集群中的节点管理装置的结构示意图；
21.图8为本技术另一个实施例提供的装置的结构性示意图。
具体实施方式
22.下面将结合附图，对本技术中的技术方案进行描述。
23.为了便于清楚描述本技术实施例的技术方案，在本技术的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一指令和第二指令是为了区分不同的用户指令，并不对其先后顺序进行限定。本领域技术人员可以
理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
24.需要说明的是，本技术中，“示例性地”或者“例如”等词用于表示作例子、例证或说明。本技术中被描述为“示例性地”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性地”或者“例如”等词旨在以具体方式呈现相关概念。
25.此外，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b的情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a、b和c中的至少一项(个)，可以表示：a，或b，或c，或a和b，或a和c，或b和c，或a、b和c，其中a，b，c可以是单个，也可以是多个。
26.图1为本技术一个实施例提供的yarn调度系统的结构示意图。如图1所示，该yarn调度系统100包括资源管理器(resource manager，rm)101和节点管理器(node manager，nm)102。其中，rm 101和nm 102之间可以进行交互。例如，rm 101可以监控nm 102，并对nm 102上的资源进行统一管理和调度，nm 102会定期向rm 101上报其上运行的任务的状态(例如磁盘、内存、cpu等使用信息)。
27.可以理解，图1中示出的nm 102的数量为一个仅是一种示例，一般情况下，yarn调度系统100可以包括一个rm 101和多个nm 102，本技术对nm 102的数量不进行限制。
28.示例性地，rm 101为yarn调度系统100的中心资源管理器，负责整个系统的资源管理和分配，包括处理客户端请求、启动/监控应用程序管理器(application master，am)、监控nm 102、资源的分配与调度等。例如，当用户提交一个应用程序时，rm 101需要提供一个用以跟踪和管理这个程序的am，该am负责向rm 101申请资源，并要求nm102启动可以占用一定资源的任务(container)。由于不同的am被分布到不同的节点上，因此它们之间不会相互影响。
29.nm 102可以看做是每个节点上的资源和任务管理器，负责各个节点的资源使用情况以及各个container的运行状态，并与rm 101进行交互，即向rm 101上报节点的状态(磁盘，内存，cpu等使用信息)；nm 102同时处理am上附加的各种实际请求，例如container的启动、停止等。其中，container是yarn中分配资源的一个单位，包括内存、cpu等资源，也可以看做是yarn在多维度资源的封装，container的具体封装是根据应用程序的需求动态生成的。
30.作为一种示例，在yarn调度系统中，当用户提交作业到rm 101上时，rm 101会将该作业对应的am调度到一台nm 102节点上，am进程启动后，开始注册到rm 101上，并根据作业执行计划向rm 101申请资源，进而rm 101将container调度到各个nm 102节点上，container定期向am汇报执行的状态，yarn中的所有nm 102也会定期向rm 101汇报资源和进程状态。
31.近年来，在大数据计算领域内，hadoop yarn已经成为大数据资源管理的事实上的标准，支持了mapreduce、spark、flink、tez等诸多计算引擎。但是，随着集群规模的不断扩大，在集群资源管理中，节点异常这种小概率事件总会发生，因此在调度的时候必须考虑异
常节点的容错。
32.在目前相关技术中，对集群资源中出现的异常节点的管理主要通过nm自带的健康状态监测机制。例如，yarn调度系统中包括一个rm和多个nm，每个nm可以包括多个磁盘，每个nm通过其中的“localdirshandlerservice”服务周期性监测磁盘的健康状态，若某块磁盘的空间占用超过了管理员设定的阈值，则该磁盘会被标记为非正常状态，如果节点上非正常状态的磁盘数量超过了预设比例，则对应的整个节点会被标记为非健康状态(unhealthy)，也即异常节点，进一步地，相应的nm通过心跳(heartbeat)将该异常节点上报给rm，rm会清理掉该异常节点上正在运行的container，且后续调度也不再为其分配container。
33.然而，现有的异常节点的检测方式强依赖于nm，且检测的策略只能局限在节点本身的物理环境，对异常节点的识别不够准确，导致大数据集群的调度稳定性不高，因此，如何提高大数据集群的调度稳定性成为目前亟待解决的问题。
34.有鉴于此，本技术实施例提供了一种数据集群中的节点管理方法及装置，可以提高识别大数据集群中异常节点的准确性，进而提升大数据集群的调度稳定性。
35.下面结合附图对本技术实施例提供的数据集群中的节点管理方法进行详细说明。
36.请参考图2，为本技术一个实施例提供的数据集群中的节点管理方法的流程图。该方法可以应用于上述图1所示的yarn调度系统，除此之外还可以应用于其他场景，本技术实施例对此不做限定。为方便说明，下文中以该方法应用在如图1所示的yarn调度系统中为例，相应地，下文中的资源管理器为图1所示的rm 101，下文中的节点管理器为图1所示的nm 102。下面详细说明图2所示的方法中的各个步骤，该流程图包括：
37.s201，应用程序管理器向资源管理器发送至少一个异常节点信息，相应的，资源管理器接收该至少一个异常节点信息。
38.其中，至少一个异常节点信息指示的节点是与至少一个节点管理器连接的多个节点中的节点。
39.应理解，在yarn调度系统运行的过程中，资源管理器根据作业需要启动了相应的应用程序管理器，应用程序管理器会根据执行过程中失败的任务情况得到对应的异常节点信息，并将该异常节点信息发送至资源管理器。
40.作为一种示例，应用程序管理器(如app1)在节点n1、节点n2和节点n3上均运行失败，则异常节点信息中包括节点n1、节点n2和节点n3。
41.s202，节点管理器获取至少一个任务运行信息，至少一个任务运行信息包括在与节点管理器连接的多个节点中的任意一个节点运行失败的目标任务的运行信息。
42.应理解，在yarn调度系统运行的过程中，节点管理器会获取其上运行的任务的运行信息，例如所有任务(正在运行的任务和已经运行结束的任务)的状态码，其中部分状态码可以有效反映其对应的节点是否异常。或者，该运行信息可以用来指示任务的运行时长，若某个任务的运行时长超过预设时长阈值，则可以认为该任务为异常任务。当然，该运行信息也可以包括其他内容，在此不作限制。
43.s203，节点管理器向资源管理器发送至少一个任务运行信息，相应的，资源管理器接收该至少一个任务运行信息。
44.其中，所述至少一个任务运行信息包括在所述多个节点中的任意一个节点运行失
败的目标任务的运行信息。
45.理解性地，节点管理器会定期通过心跳向资源管理器发送该至少一个任务运行信息，告知资源管理器相应的节点的情况。例如将所有任务(正在运行的任务和已经运行结束的任务)的状态码发送至资源管理器，相应的，资源管理器接收该状态码。
46.s204，资源管理器根据至少一个异常节点信息和至少一个任务运行信息，从多个节点中确定目标异常节点。
47.应理解，资源管理器根据上述步骤中收到的至少一个异常节点信息和至少一个任务运行信息，确定存在异常的节点均为目标异常节点；或者，根据至少一个异常节点信息和至少一个任务运行信息，确定异常比较严重的节点为目标异常节点，其中，异常比较严重的节点可以通过异常节点信息和任务运行信息这两个信息中是否有多次重合来判断，重合的次数超过预设阈值，说明异常比较严重，且重合的次数越多说明异常越严重。
48.s205，资源管理器对多个节点中的正常节点进行任务调度。
49.其中，正常节点为多个节点中除去目标异常节点中的部分或全部异常节点外的节点。
50.应理解，资源管理器发现了目标异常节点后，则不在该目标异常节点上进行任务调度，在除目标异常节点中的部分或全部异常节点外的节点上进行任务调度。
51.示例性地，某些节点只会在运行特定任务的时候产生异常，这种情况下，正常节点为除去目标异常节点中的部分异常节点外的节点，不用全部排除，例如，资源管理器只在运行特定任务时，不对这些指定的异常节点进行调度，其他情况下，可以继续调度。若某些节点在不管运行什么任务时均被确定为异常节点，则正常节点为除去目标异常节点中全部异常节点外的节点。
52.可选地，资源管理器对正常节点进行任务调度的方法可以参照现有技术中的任务调度方法，本技术对此不做限制。
53.在上述实施例中，资源管理器通过获取来自应用程序管理器的异常节点信息和来自节点管理器的任务运行信息，综合确定目标异常节点，该方式得到的目标异常节点比较准确，例如，可以识别到诸如节点用户组缺失、配置文件错误导致运行异常、磁盘目录权限异常和依赖包缺失等多种环境异常的节点，大大减少任务的重试。
54.进一步地，基于确定好的目标异常节点，进而对除去目标异常节点中的部分或全部异常节点外的节点进行任务调度，这种综合应用程序管理器、节点管理器和资源管理器三个组件来参与确定目标异常节点的方法，充分利用了任务运行期间的状态参照信息并采用投票的思想来选举异常节点，挖掘出物理监控无法覆盖的各类环境异常问题，形成调度系统的内部自治，可以提高识别大数据集群中异常节点的准确性，进而提升大数据集群的调度稳定性。
55.基于上述实施例，图3为本技术另一个实施例提供的数据集群中的节点管理方法的流程图。在图3所示的实施例中，以具体怎么根据异常节点信息和任务运行信息确定目标异常节点为例，下面详细说明图3所示的方法中的各个步骤，该流程图包括：
56.s301，应用程序管理器向资源管理器发送至少一个异常节点信息，相应的，资源管理器接收该至少一个异常节点信息。
57.其中，至少一个异常节点信息指示的节点是与至少一个节点管理器连接的多个节
点中的节点。
58.该步骤和图2所示的实施例中的步骤s201相似，在此不再赘述。
59.s302，节点管理器获取至少一个任务运行信息，至少一个任务运行信息包括在与节点管理器连接的多个节点中的任意一个节点运行失败的目标任务的运行信息。
60.该步骤和图2所示的实施例中的步骤s202相似，在此不再赘述。
61.s303，节点管理器向资源管理器发送至少一个任务运行信息，相应的，资源管理器接收该至少一个任务运行信息。
62.其中，所述至少一个任务运行信息包括在所述多个节点中的任意一个节点运行失败的目标任务的运行信息。
63.该步骤和图2所示的实施例中的步骤s203相似，在此不再赘述。
64.s304，资源管理器根据至少一个异常节点信息，从多个节点中确定全局异常节点以及与至少一个应用程序分别对应的至少一个应用程序异常节点。
65.其中，资源管理器不在全局异常节点上进行任何任务调度，资源管理器不在目标应用程序异常节点上调度与目标应用程序对应的任务，目标应用程序异常节点与目标应用程序对应，目标应用程序异常节点为至少一个应用程序异常节点中的其中一个。
66.应理解，应用程序管理器根据执行过程中失败的任务情况得到对应的异常节点信息，并将该异常节点信息对应的节点标记为应用程序异常节点，然后发送至资源管理器，请求资源管理器为其更换一个其他节点。
67.例如，应用程序管理器在某个节点上运行任务时失败了，则应用程序管理器将该节点标记为应用程序异常节点，然后通过心跳将该应用程序异常节点发送至资源管理器，告知资源管理器这个节点有问题，请求为其更换一个其他节点。
68.可选地，应用程序异常节点的集合也可以叫做节点的应用程序黑名单(appblacklist)。
69.进一步地，资源管理器对接收到的应用程序管理器发送的应用程序黑名单进行处理，统计这些应用程序黑名单中对应的异常节点出现的频率，大于或等于预设阈值则被认定为全局异常节点，也即写入集群全局黑名单(global blacklist)。
70.例如，如图4所示，应用程序管理器app1的应用程序黑名单包括节点n1、节点n2和节点n3，应用程序管理器app2的应用程序黑名单包括节点n2、节点n4和节点n6，应用程序管理器app3的应用程序黑名单包括节点n2、节点n6和节点n7，应用程序管理器app4的应用程序黑名单包括节点n2、节点n6和节点n8，假设预设阈值为3，则节点n2出现了4次，节点n6出现了3次，即节点n2和节点n6的出现频率超过了预设阈值，则节点n2和节点n6被认定为集群全局黑名单。
71.应理解，集群全局黑名单中的节点禁止调度任何任务，应用程序黑名单中的节点只禁止往对应的应用程序上调度任务。
72.该步骤中，根据异常节点信息确定全局异常节点以及应用程序异常节点的方法比较准确，方便于后续的任务调度。
73.s305，资源管理器根据至少一个任务运行信息，从多个节点中确定至少一个应用程序异常任务节点。
74.其中，目标应用程序异常任务节点分别与目标应用程序中的目标任务对应，资源
管理器不在目标应用程序异常任务节点上调度目标任务，目标应用程序异常任务节点为至少一个应用程序异常任务节点中的其中一个。
75.可选地，资源管理器接收到的至少一个任务运行信息中的每个任务运行信息中包括运行失败的任务信息，该任务信息用于指示运行失败的任务的失败原因。
76.示例性地，运行失败的任务信息可以是对应的节点管理器上运行失败的目标应用程序中的目标任务(am container)的退出码。也就是说，该目标应用程序中的目标任务已经调度在节点上，但是运行失败了，该运行失败的任务的退出码中包括运行失败的原因，例如是目标任务启动过程中失败的、目标任务运行过程中失败的或者是节点的配置环境出现异常导致失败的等。
77.进一步地，资源管理器从至少一个任务运行信息中，去除目标失败任务，获得至少一个更新后的任务运行信息，该目标失败任务为失败原因指示为非节点的物理资源引起的运行失败的任务。根据至少一个更新后的任务运行信息，确定至少一个应用程序异常任务节点。
78.应理解，非节点的物理资源引起的运行失败的任务也即发送了退出码的目标任务，该目标任务已经调度在节点上，但是运行失败了。
79.示例性地，至少一个更新后的任务运行信息可以包括应用程序管理器启动器(am launcher)在启动目标应用程序管理器时直接在资源管理器内部发生异常，也即目标任务并未到达节点管理器，或者资源管理器和节点管理器之间单向网络不通等情况。
80.可选地，应用程序管理器发生异常的节点的集合也可以叫做应用程序管理器黑名单(amcontainer blacklist)，应用程序管理器黑名单中的节点只限制调度对应的应用程序管理器。
81.可选地，资源管理器中包括异常节点管理器，上述获取应用程序管理器发送的异常节点信息和节点管理器发送的任务运行信息，以及确定目标异常节点的步骤可以由异常节点管理器来执行。
82.该步骤中，根据任务运行信息确定应用程序异常任务节点的方法，考虑到了任务运行中产生异常以及任务还没开始运行时产生异常的可能，得到的目标异常节点比较准确，方便于后续的任务调度。
83.s306，资源管理器对多个节点中的正常节点进行任务调度。
84.其中，正常节点为多个节点中除去目标异常节点中的部分或全部异常节点外的节点。
85.应理解，资源管理器中的异常节点管理器在运行过程中会实时更新上述集群全局黑名单以及应用程序异常任务黑名单中的节点信息，并将信息传递给资源管理器中的调度模块(scheduler)，作为调度的黑名单过滤器(blacklist filter)，以达到规避调度的目的。
86.也就是说，资源管理器中的调度模块在进行任务调度时，会首先过滤掉集群全局黑名单以及应用程序异常任务黑名单中相关节点，然后对除去目标异常节点中的部分或全部异常节点外的正常节点进行任务调度。
87.在上述实施例中，资源管理器通过获取来自应用程序管理器的异常节点信息和来自节点管理器的任务运行信息，根据异常节点信息，从多个节点中确定全局异常节点以及
应用程序异常节点，根据任务运行信息，从多个节点中确定应用程序异常任务节点的方法，得到的目标异常节点比较准确，例如，可以识别到诸如节点用户组缺失、配置文件错误导致运行异常、磁盘目录权限异常和依赖包缺失等多种环境异常的节点，大大减少任务的重试。
88.进一步地，基于确定好的全局异常节点、应用程序异常节点以及应用程序异常任务节点，对除去目标异常节点中的部分或全部异常节点外的节点进行任务调度，可以提升大数据集群的调度稳定性。
89.在上述实施例的基础上，图5为本技术又一个实施例提供的数据集群中的节点管理方法的流程图。在图5所示的实施例中，以根据节点健康分，对多个节点中的正常节点进行任务调度为例，下面详细说明图5所示的方法中的各个步骤，该流程图包括：
90.s501，应用程序管理器向资源管理器发送至少一个异常节点信息，相应的，资源管理器接收该至少一个异常节点信息。
91.其中，至少一个异常节点信息指示的节点是与至少一个节点管理器连接的多个节点中的节点。
92.该步骤和图2所示的实施例中的步骤s201相似，在此不再赘述。
93.s502，节点管理器获取至少一个任务运行信息，至少一个任务运行信息包括在与节点管理器连接的多个节点中的任意一个节点运行失败的目标任务的运行信息。
94.该步骤和图2所示的实施例中的步骤s202相似，在此不再赘述。
95.s503，节点管理器向资源管理器发送至少一个任务运行信息，相应的，资源管理器接收该至少一个任务运行信息。
96.其中，所述至少一个任务运行信息包括在所述多个节点中的任意一个节点运行失败的目标任务的运行信息。
97.该步骤和图2所示的实施例中的步骤s203相似，在此不再赘述。
98.s504，资源管理器根据至少一个异常节点信息和至少一个任务运行信息，从多个节点中确定目标异常节点。
99.该步骤和图2所示的实施例中的步骤s204相似，在此不再赘述。
100.s505，节点管理器根据预设健康监测指标对与节点管理器连接的每个正常节点在执行任务时资源使用情况进行计算，得到的与每个正常节点对应的节点健康分。
101.其中，预设健康监测指标包括中央处理器使用情况、磁盘占用情况、内存占用情况和网络情况。
102.应理解，节点管理器对每个正常节点在执行任务时的资源使用情况，如中央处理器使用情况、磁盘占用情况、内存占用情况和网络情况进行检测，将得到的多维度的健康监测值通过加权平均的方式进行计算，得到统一的指标，即节点健康分。
103.可选地，不同负载类型的集群可以调整不同维度的权重。
104.示例性地，中央处理器(central processing unit，cpu)使用情况使用“systemloadavg”和“availableprocessors”作为参考指标；磁盘占用情况采用“iostat”来监控“util”指标，并对挂载的多块硬盘设备的“util”进行排序，选取使用率较高的前1/3的均值作为磁盘压力；内存占用情况选取自“/proc/meminfo”内核接口文件来计算系统内存空闲率；网络情况则根据“/proc/net/dev”来计算网络带宽使用率。然后将上述几类监控数据值均归一化到0至1之间，并通过加权平均来计算总的节点健康分(loadscore)数值，具体
算法如下：
[0105][0106]
其中，loadscore为每个节点对应的节点健康分，cpuscore和cpuweight为中央处理器使用情况对应的参考指标的平均分，diskscore和diskweight为磁盘占用情况对应的参考指标的平均分，netscore和netweight为网络情况对应的参考指标的平均分，memscore和memweight为内存占用情况对应的参考指标的平均分。当然，上述计算过程只是一种示例，本领域技术人员可以采用其他参数以及计算方式，获得节点健康分，在此不作限制。
[0107]
s506，节点管理器向资源管理器发送至少一个节点健康分，相应的，资源管理器接收该至少一个节点健康分。
[0108]
可选地，由于节点健康分变化较快，为避免抖动，可以对得到的节点健康分进行离散化(例如10，20，30，
…
，100)，只有当节点健康分的离散区间发生变化，才会将数值上报给资源管理器。
[0109]
可选地，计算节点健康分的过程可以由节点管理器执行，计算完成后发送至资源管理器，也可以由资源管理器对节点管理器监控时直接执行，本技术对此不做限制。
[0110]
s507，资源管理器根据节点健康分，对多个节点中的正常节点进行任务调度。
[0111]
应理解，针对每个节点，若节点健康分大于或等于第一预设阈值，则对运行在所述节点上的预设任务进行释放；若节点健康分大于或等于第二预设阈值，且小于第一预设阈值时，则停止继续调度新的任务至所述节点，第一预设阈值大于第二预设阈值；若节点健康分小于第二预设阈值，则维持所述节点的调度方式。
[0112]
示例性地，资源管理器将节点健康分为三类：节点健康分大于或等于第一预设阈值的为第一类(serious)、节点健康分大于或等于第二预设阈值，且小于第一预设阈值的为第二类(high)，节点健康分小于第二预设阈值的为第三类(low)。对于第一类(serious)节点，表示节点已经无法正常运行任务，此时会触发调度器进行任务的驱逐，选择部分任务进行释放，以使节点的负载(load)降低下来；对于第二类(high)节点，表示当前节点的负载已经较高，但当前正在运行的任务还可以继续运行，但是不适合再调度更多的任务，这类节点的状态会被标记为“autoreadonly”；对于第三类(low)节点，表示该节点运行正常，可以维持原有的调度方式。
[0113]
可选地，上述三类节点的状态在运行过程中可以互相转换，并及时将状态更新至调度器中进行相应的调度干预。
[0114]
应理解，任务运行在节点健康分较高的节点上时，会受到严重干扰，通过调度规避节点健康分高的节点可以有效减少任务的长尾现象。
[0115]
可选地，对于上述三类节点的缓存均采用优先队列的方式维护，例如，根据节点健康分，将正常节点缓存至第一预设队列中，其中，第一预设队列中的节点按照节点对应的节点健康分由低到高排序。若第一预设队列所占用的缓存空间大于或等于第一预设缓存阈值，例如，第一预设队列存满的时候，则按照节点对应的节点健康分的高低，顺序移除节点健康分低的节点。
[0116]
可选地，由于节点对应的节点健康分是实时更新的，所以无需写入“checkpoint”，在资源管理器重启后，可以重新根据节点管理器上报的节点健康分数据来重建。
[0117]
可选地，由于在spark、mapreduce类型的集群负载下，部分任务的“shuffle”过程很容易引起大量磁盘输入/输出(input/output，io)数据，并且在yarn节点管理器和“hdfs datanode”混部的节点上，这种io异常除了对其他任务造成干扰，也严重干扰了datanode的服务。因此，本技术对已经运行在节点上的任务采用动态的io限制模式，默认不做io限制，而是对每个任务在运行时进行io监控，并通过cgroup的blkio子系统来增加对io的限制，以减少对其他任务以及其他服务的干扰，最终使得节点环境自动恢复到正常水平。具体算法如下：
[0118]
监控至少一个节点管理器中每个节点管理器对应的所有任务的输入/输出io资源的使用信息，若所有任务中的io资源的使用信息中第一任务的io资源的使用值大于或等于预设使用阈值，则对第一任务使用的io资源进行抑制处理。
[0119]
示例性地，遍历节点管理器的进程树，对所有任务的io进行排序，如果超过单个进程io的预设使用阈值，则开始写入cgroup blk资源配置来限制任务的io使用，也即引入iops/bps限制的方式，来限制资源组使用上限。相应地，当任务结束时，清理相应的cgroup blk配置。
[0120]
应理解，通过对io异常的任务进行动态控制，可以大大减少异常io占用的节点。以磁盘读写率为例，指标采集自“/sys/block/$device/stat”，用预设时间窗口内的变化值表示磁盘io的使用压力。下表1统计了集群所有节点在某个时间段磁盘读写率，此处按照磁盘读写率从小到大排序，并统计不同分位数所对应的磁盘读写率。其中99％分位的磁盘写入率大幅下降，充分反映了这部分异常io的节点得到有效控制。
[0121]
表1
[0122]
分位值下降幅度99％91％90％18.9％80％18％
[0123]
可选地，由于io异常所导致的datanode掉线的比例也降低了90％以上。
[0124]
可选地，节点管理器除了对任务进行运行时监控和限制，自带的shuffle服务也可以建立监控，部分场景下shuffle服务也会带来异常的io消耗。
[0125]
该实施例中，在通过获取来自应用程序管理器的异常节点信息和来自节点管理器的任务运行信息，综合确定目标异常节点的基础上，对除去目标异常节点中的部分或全部异常节点外的节点计算节点的节点健康分，并针对节点健康分建立了分级的处理策略，以达到自愈代价最小化，从调度源头减少了任务异常的发生；且采用任务运行时动态io限制，在默认放开io限制的情况下充分发挥机器性能，同时又可以显著减少异常io场景的发生，有效提升了大数据集群的调度稳定性。
[0126]
可选地，基于上述三个实施例中的任意一个实施例，从多个节点中确定了目标异常节点之后，对目标异常节点的存储可以采用优先队列和超时控制机制，即将目标异常节点依次缓存至第二预设队列中；若第二预设队列所占用的缓存空间大于或等于第二预设缓存阈值，则按照进入队列的时间先后顺序移除第二预设队列中在先存入的目标异常节点；和/或，移除存储时间大于或等于预设存储周期对应的异常节点。
[0127]
示例性地，将目标异常节点按照入队时间进行排序，每当一个节点被认定为目标
异常节点就进入队列，并记录入队时间，同时控制队列的缓存(buffer)大小，当buffer满的时候，自动移除队首的节点，并定期将超时的节点移除。
[0128]
应理解，该存储方式可以有效地控制目标异常节点的数量，以避免异常节点数量过多导致计算资源严重不可用。
[0129]
可选地，节点重启会被认为是一次有效的运维操作，也会自动将该节点从目标异常节点移除。目标异常节点也会被写入容错恢复机制(checkpoint)，以保证资源管理器重启后不会丢失。
[0130]
可选地，本技术中还可以增加“yarn rmadmin”运维命令，以支持人为干预(增加或移除)目标异常节点列表。
[0131]
在上述实施例的基础上，图6为本技术一个实施例提供的数据集群中的节点管理装置600的结构性示意图，该装600包括：获取模块601、确定模块602和调度模块603。
[0132]
其中，获取模块601，用于获取至少一个应用程序管理器发送的至少一个异常节点信息和至少一个节点管理器发送的至少一个任务运行信息，至少一个异常节点信息指示的节点是与至少一个节点管理器连接的多个节点中的节点，至少一个任务运行信息包括在多个节点中的任意一个节点运行失败的目标任务的运行信息；确定模块602，用于根据至少一个异常节点信息和至少一个任务运行信息，从多个节点中确定目标异常节点；调度模块603用于对多个节点中的正常节点进行任务调度，正常节点为多个节点中除去目标异常节点中的部分或全部异常节点外的节点。
[0133]
在一些实施例中，确定模块602，具体用于根据所述至少一个异常节点信息，从所述多个节点中确定全局异常节点以及与至少一个应用程序分别对应的至少一个应用程序异常节点，其中，所述资源管理器不在所述全局异常节点上进行任何任务调度，所述资源管理器不在目标应用程序异常节点上调度与所述目标应用程序对应的任务，所述目标应用程序异常节点与所述目标应用程序对应，所述目标应用程序异常节点为所述至少一个应用程序异常节点中的其中一个；根据所述至少一个任务运行信息，从所述多个节点中确定至少一个应用程序异常任务节点，其中，目标应用程序异常任务节点分别与目标应用程序中的目标任务对应，所述资源管理器不在所述目标应用程序异常任务节点上调度所述目标任务，所述目标应用程序异常任务节点为所述至少一个应用程序异常任务节点中的其中一个。
[0134]
在一些实施例中，每个任务运行信息中包括运行失败的任务信息，所述任务信息用于指示所述运行失败的任务的失败原因，确定模块602，还用于从所述至少一个任务运行信息中，去除目标失败任务，获得至少一个更新后的任务运行信息，所述目标失败任务为所述失败原因指示为非节点的物理资源引起的运行失败的任务；根据所述至少一个更新后的任务运行信息，确定所述至少一个应用程序异常任务节点。
[0135]
在一些实施例中，获取模块601，还用于获取每个节点管理器发送的至少一个节点健康分，每个节点健康分是所述节点管理器根据预设健康监测指标对与所述节点管理器连接的每个正常节点在执行任务时资源使用情况进行计算得到的，所述预设健康监测指标包括中央处理器使用情况、磁盘占用情况、内存占用情况和网络情况。
[0136]
在一些实施例中，调度模块603，具体用于根据所述节点健康分，对所述多个节点中的正常节点进行任务调度。
[0137]
在一些实施例中，调度模块603，具体还用于针对每个节点，若所述节点健康分大于或等于第一预设阈值，则对运行在所述节点上的预设任务进行释放；若所述节点健康分大于或等于第二预设阈值，且小于所述第一预设阈值时，则停止继续调度新的任务至所述节点，所述第一预设阈值大于所述第二预设阈值；若所述节点健康分小于所述第二预设阈值，则维持所述节点的调度方式。
[0138]
在一些实施例中，所述装置还包括：缓存模块，用于根据所述节点健康分，将所述正常节点缓存至第一预设队列中，其中，所述第一预设队列中的正常节点按照所述正常节点对应的节点健康分由低到高排序；移除模块，用于若所述第一预设队列所占用的缓存空间大于或等于第一预设缓存阈值，则按照所述正常节点对应的节点健康分的高低，顺序移除节点健康分低的节点。
[0139]
在一些实施例中，所述装置还包括：监控模块，用于监控所述至少一个节点管理器中每个节点管理器对应的所有任务的输入/输出io资源的使用信息；处理模块，用于若所述所有任务中的io资源的使用信息中第一任务的io资源的使用值大于或等于预设使用阈值，则对所述第一任务使用的io资源进行抑制处理。
[0140]
在一些实施例中，缓存模块，还用于将所述目标异常节点依次缓存至第二预设队列中；所述移除模块还用于若所述第二预设队列所占用的缓存空间大于或等于第二预设缓存阈值，则按照进入队列的时间先后顺序移除所述第二预设队列中在先存入的目标异常节点；和/或，移除存储时间大于或等于预设存储周期对应的异常节点。
[0141]
应理解，这里的装置600以功能模块的形式体现。这里的术语“模块”可以指应用特有集成电路(application specific integrated circuit，asic)、电子电路、用于执行一个或多个软件或固件程序的处理器(例如共享处理器、专有处理器或组处理器等)和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。在一个可选例子中，本领域技术人员可以理解，装置600可以具体为上述实施例中的资源管理器，或者，上述实施例中资源管理器的功能可以集成在装置600中，装置600可以用于执行上述方法实施例中与资源管理器对应的各个流程和/或步骤，为避免重复，在此不再赘述。
[0142]
上述装置600具有实现上述方法中资源管理器执行的相应步骤的功能；上述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
[0143]
图7为本技术另一个实施例提供的数据集群中的节点管理装置700的结构性示意图，该装置700包括：获取模块701和发送模块702。
[0144]
其中，获取模块701，用于获取至少一个任务运行信息，至少一个任务运行信息包括在与节点管理器连接的多个节点中的任意一个节点运行失败的目标任务的运行信息；发送模块702，用于向资源管理器发送至少一个任务运行信息。
[0145]
在一些实施例中，所述装置还包括：计算模块，用于根据预设健康监测指标对与所述节点管理器连接的每个正常节点在执行任务时资源使用情况进行计算，得到的与每个正常节点对应的节点健康分，所述预设健康监测指标包括中央处理器使用情况、磁盘占用情况、内存占用情况和网络情况；发送模块702，还用于向所述资源管理器发送所述每个正常节点对应的节点健康分。
[0146]
在一些实施例中，所述装置还包括：监控模块，用于监控所述节点管理器对应的所
有任务的输入/输出io资源的使用信息；处理模块，用于若所述所有任务中的io资源的使用信息中第一任务的io资源的使用值大于或等于预设使用阈值，则对所述第一任务使用的io资源进行抑制处理。
[0147]
在一些实施例中，每个任务运行信息中包括运行失败的任务信息，所述任务信息用于指示所述运行失败的任务的失败原因。
[0148]
应理解，这里的装置700以功能模块的形式体现。这里的术语“模块”可以指应用特有集成电路(application specific integrated circuit，asic)、电子电路、用于执行一个或多个软件或固件程序的处理器(例如共享处理器、专有处理器或组处理器等)和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。在一个可选例子中，本领域技术人员可以理解，装置700可以具体为上述实施例中的节点管理器，或者，上述实施例中节点管理器的功能可以集成在装置700中，装置700可以用于执行上述方法实施例中与节点管理器对应的各个流程和/或步骤，为避免重复，在此不再赘述。
[0149]
上述装置700具有实现上述方法中节点管理器执行的相应步骤的功能；上述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
[0150]
图8为本技术另一个实施例提供的装置的结构性示意图。图8所示的装置可以用于执行前述任意一个实施例的方法。
[0151]
如图8所示，本实施例的装置800包括：存储器801、处理器802、通信接口803以及总线804。其中，存储器801、处理器802、通信接口803通过总线804实现彼此之间的通信连接。
[0152]
存储器801可以是只读存储器(read only memory，rom)，静态存储设备，动态存储设备或者随机存取存储器(random access memory，ram)。存储器801可以存储程序，当存储器801中存储的程序被处理器802执行时，处理器802用于执行上述实施例中所示的方法中资源管理器或节点管理器对应的各个步骤。
[0153]
处理器802可以采用通用的中央处理器(central processing unit，cpu)，微处理器，应用专用集成电路(application specific integrated circuit，asic)，或者一个或多个集成电路，用于执行相关程序，以实现本技术实施例中所示的各个方法。
[0154]
处理器802还可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，本技术实施例的方法的各个步骤可以通过处理器802中的硬件的集成逻辑电路或者软件形式的指令完成。
[0155]
上述处理器802还可以是通用处理器、数字信号处理器(digital signal processing，dsp)、asic、现成可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
[0156]
结合本技术实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器801，处理器802读取存储器801中的信息，结合其硬件完成本技术装置包括的单元所需执行的功能。
[0157]
通信接口803可以使用但不限于收发器一类的收发装置，来实现装置800与其他设备或通信网络之间的通信。
[0158]
总线804可以包括在装置800各个部件(例如，存储器801、处理器802、通信接口803)之间传送信息的通路。
[0159]
应理解，本技术实施例所示的装置800可以是电子设备，或者，也可以是配置于电子设备中的芯片。
[0160]
应理解，在本技术的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
[0161]
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
[0162]
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0163]
在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0164]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0165]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0166]
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
[0167]
以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。