CN111459642A - 一种分布式***中故障处理和任务处理方法及装置 - Google Patents
一种分布式***中故障处理和任务处理方法及装置 Download PDFInfo
- Publication number
- CN111459642A CN111459642A CN202010271224.1A CN202010271224A CN111459642A CN 111459642 A CN111459642 A CN 111459642A CN 202010271224 A CN202010271224 A CN 202010271224A CN 111459642 A CN111459642 A CN 111459642A
- Authority
- CN
- China
- Prior art keywords
- task
- task processing
- computing node
- failed
- node
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/178—Techniques for file synchronisation in file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5083—Techniques for rebalancing the load in a distributed system
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Computer Hardware Design (AREA)
- Hardware Redundancy (AREA)
Abstract
本申请涉及一种分布式***中故障处理和任务处理方法及装置,所述分布式***包括分布在不同机房中的管理节点和计算节点,其中,各机房具有用于进行数据同步的分布式文件***;所述计算节点包括任务处理模块;所述方法应用于管理节点中,包括:确定发生故障的目标计算节点的故障信息;确定发生故障的任务处理模块的数量;根据所述发生故障的任务处理模块的数量以及已收集的各计算节点的负载信息,确定替代计算节点;为所述替代计算节点分配并下发对接的、发生故障的任务处理模块的标识。本实施例可以实现多维度的故障检测和故障转移,提高跨机房的计算节点以及各机房的高可用性。
Description
技术领域
本申请涉及数据处理技术领域,尤其涉及一种分布式***中故障处理和任务处理方法及装置。
背景技术
随着计算技术的发展,有些任务的计算需要非常大的计算能力才能完成,如果采用集中式计算,需要耗费相当长的时间来完成计算;而采用分布式计算,则可以将该任务分解成许多小的子任务,然后分配给多台计算机进行处理,这样可以节约整体计算时间,大大提高计算效率。
对于分布式计算而言,任务调度是一个最基本且具有挑战性的问题,其中,任务调度问题是指:给定一组任务和若干个可并行执行这些任务的计算节点,寻找一个能够将这一组任务有效调度到各个计算节点进行计算的方法,以获得更好的任务完成时间、吞吐量和资源利用率等。在实际中,任务调度还包括故障发生时的任务转移,例如,机器的某些硬件损坏、机房的光纤被挖断、机房紧急维护等等。而当故障发生时,如何能做到快速转移,以减少对整体业务的影响,是业界一直在探索的话题。
发明内容
鉴于上述问题,提出了本申请以便提供一种克服上述问题或者至少部分地解决上述问题的一种分布式***中故障处理和任务处理方法及装置。
第一方面,本申请提供了一种分布式***中故障处理的方法,所述分布式***包括分布在不同机房中的管理节点和计算节点,其中,各机房具有用于进行数据同步的分布式文件***;所述计算节点包括任务处理模块;所述方法应用于管理节点中,包括:
确定发生故障的目标计算节点的故障信息,所述故障信息包括所述目标计算节点中发生故障的任务处理模块的标识;
确定发生故障的任务处理模块的数量;
根据所述发生故障的任务处理模块的数量以及已收集的各计算节点的负载信息,确定一个或多个替代计算节点;
为所述替代计算节点分配并下发对接的、发生故障的任务处理模块的标识,以由所述任务管理模块根据所述发生故障的任务处理模块的标识,从所处机房的分布式文件***中读取该发生故障的任务处理模块的标识对应的任务数据文件和程序文件,并根据所述程序文件创建任务处理模块对所述任务数据文件进行作业处理。
可选地,所述确定发生故障的目标计算节点的故障信息,包括:
接收目标计算节点上报的故障信息,所述故障信息为所述目标计算节点检测到与其创建的一个或多个任务处理模块的心跳超时时生成的信息。
可选地,所述确定发生故障的目标计算节点的故障信息,包括:
在与各目标计算节点的任务管理模块的心跳检测过程中,若存在心跳超时,则判定该心跳超时对应的目标计算节点发生故障;
获取所述心跳超时对应的目标计算节点中的任务处理模块的标识,生成故障信息。
可选地,所述根据所述发生故障的任务处理模块的数量以及已收集的各计算节点的负载信息,确定一个或多个替代计算节点,包括:
根据各计算节点的负载信息,确定该计算节点的指定空闲值;
若最大的指定空闲值能覆盖发生故障的任务处理模块的数量,则将该最大的指定空闲值对应的计算节点作为替代计算节点;
若最大的指定空闲值不能覆盖发生故障的任务处理模块的数量,则继续往下累积次大的指定空闲值,直到累积的指定空闲值能覆盖发生故障的任务处理模块的数量,则将累积的指定空闲值对应的计算节点作为替代计算节点。
可选地,所述为所述替代计算节点分配并下发对接的、发生故障的任务处理模块的标识,包括:
若所述替代计算节点为一个,则将所有发生故障的任务处理模块的标识分配给该替代计算节点;
若所述替代计算节点超过一个,则将发生故障的任务处理模块的标识按照所述替代计算节点的指定空闲值由大到小的顺序分配。
第二方面,本申请还提供了一种分布式***中的任务处理方法,所述分布式***包括分布在不同机房中的管理节点和计算节点,其中,各机房具有用于进行数据同步的分布式文件***;所述方法应用于计算节点中,包括:
接收管理节点发送的发生故障的任务处理模块的标识;
在所处机房的分布式文件***中查找该发生故障的任务处理模块的标识对应的任务数据文件和程序文件;
根据接收到的任务处理模块的标识,确定发生故障的任务处理模块的数量;
根据所述程序文件在当前计算节点中创建所述数量对应的任务处理模块,并将所述任务数据文件分配至各任务处理模块,以由所述任务处理模块对所述任务数据文件进行作业处理。
第三方面,本申请还提供了一种分布式***中故障处理的装置,所述分布式***包括分布在不同机房中的管理节点和计算节点,其中,各机房具有用于进行数据同步的分布式文件***;所述计算节点包括任务处理模块;所述装置应用于管理节点中,包括:
故障信息确定单元,用于确定发生故障的目标计算节点的故障信息,所述故障信息包括所述目标计算节点中发生故障的任务处理模块的标识;
数量确定单元,用于确定发生故障的任务处理模块的数量;
替代计算节点确定单元,用于根据所述发生故障的任务处理模块的数量以及已收集的各计算节点的负载信息,确定一个或多个替代计算节点;
分配单元,用于为所述替代计算节点分配并下发对接的、发生故障的任务处理模块的标识,以由所述任务管理模块根据所述发生故障的任务处理模块的标识,从所处机房的分布式文件***中读取该发生故障的任务处理模块的标识对应的任务数据文件和程序文件,并根据所述程序文件创建任务处理模块对所述任务数据文件进行作业处理。
第四方面,本申请还提供了一种分布式***中的任务处理装置,所述分布式***包括分布在不同机房中的管理节点和计算节点,其中,各机房具有用于进行数据同步的分布式文件***;所述装置应用于计算节点中,包括:
标识接收单元,用于接收管理节点发送的发生故障的任务处理模块的标识;
作业数据查找单元,用于在所处机房的分布式文件***中查找该发生故障的任务处理模块的标识对应的任务数据文件和程序文件;
数量确定单元,用于根据接收到的任务处理模块的标识,确定发生故障的任务处理模块的数量;
任务处理单元,用于根据所述程序文件在当前计算节点中创建所述数量对应的任务处理模块,并将所述任务数据文件分配至各任务处理模块,以由所述任务处理模块对所述任务数据文件进行作业处理。
第五方面,本申请提供了一种电子设备,包括:
处理器;
用于存储所述处理器可执行指令的存储器;
其中,所述处理器被配置为执行所述指令,以实现如上述的方法。
第六方面,本申请提供了一种存储介质,当所述存储介质中的指令由所述设备的处理器执行时,使得所述电子设备能够执行如上述的方法。
本申请提供的技术方案可以包括以下有益效果:
在本实施例中,在不同机房中通过分布式文件***进行数据同步,因此在计算节点发生故障时,管理节点只需要根据发生故障的目标计算节点的故障信息,确定发生故障的任务处理模块的数量,以及,确定用于进行故障转移的替代计算节点,并为替代计算节点的TaskManager分配并下发对接的、发生故障的Task的标识,以使得Task Manager根据发生故障的Task的标识,从所处机房的分布式文件***中读取该发生故障的任务处理模块的标识对应的任务数据文件和程序文件,并根据所述程序文件创建新的任务处理模块来对任务数据文件进行作业处理,以此实现多维度的故障检测和故障转移,提高跨机房的计算节点以及各机房的高可用性,适用于提供大量计算能力、并且要求整体架构高可用的场景。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性的,并不能限制本申请。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并于说明书一起用于解释本申请的原理。
图1为本申请提供的一种示例性的实施环境的示意图;
图2为本申请提供的一种服务器结构示意图;
图3为本申请的一种跨机房的任务调度方法实施例的步骤流程图;
图4为本申请的作业数据划分示意图;
图5为本申请的另一种跨机房的任务调度方法实施例的步骤流程图;
图6为本申请的一种任务处理方法实施例的步骤流程图;
图7为本申请的一种分布式***中故障处理的方法实施例的步骤流程图;
图7a为本申请的一种Task故障转移示例的示意图;
图7b为本申请的一种服务器故障转移示例的示意图;
图7c为本申请的一种机房故障转移示例的示意图;
图8为本申请的一种分布式***中的任务处理方法实施例的步骤流程图;
图9为本申请的一种分布式***中故障处理的装置实施例的结构框图;
图10为本申请的一种分布式***中的任务处理装置实施例的结构框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
本申请所涉及的实施环境包括分布于不同机房的服务器集群,该服务器集群中可以包括具有管理功能的服务器(即管理节点)以及具有任务处理功能的服务器(即计算节点)。其中,管理节点可以有一个或多个,每个管理节点可以管理一个或多个计算节点。在本实施例中,管理节点具有作业管理模块Job Manager,计算节点具有任务管理模块TaskManager,Job Manager与Task Manager之间保持心跳通讯。
在本实施例中,Job Manager还具有WEB管理页面,用户可以在该WEB管理页面上上传Task的程序文件(如程序代码、Jar包等)以及作业对象的数据文件等。Task Manager在需要时可以向Job Manager获取该Task的程序文件来创建Task。
另外,各机房还具有用于进行数据同步的分布式文件***(Distributed FileSystem),Job Manager可以将Task的程序文件以及作业的数据文件存储在分布式文件***中。任一机房的分布式文件***发生数据变化时,会自动把新增的文件信息同步到其他机房的文件***,从而实现数据的同步。
示例性地,分布式文件***可以包括但不限于:MooseFS、NFS(Network FileSystem,网络文件***)、GoogleFS、GlusterFS、Ceph、FastDFS等。
参照图1示出了本申请所涉及的一种示例性的实施环境的示意图。该实施环境包括:A机房、B机房和C机房。A机房的服务器作为管理节点,B机房的服务器1和服务器2,以及C机房的服务器1和服务器2作为计算节点。计算节点可以通过Task Manager与管理节点的Job Manager通信。A机房、B机房和C机房中均有分布式文件***,用于进行跨机房的文件(包括数据文件和程序文件)同步。例如在图1中,共有6个Task,分别是Task1~Task6,则各机房的分布式文件***中均存储有Task1~Task6的程序文件和数据文件。假设A机房中的分布式文件***的文件更新,其会自动把新增的文件信息同步到其他机房(即图1中的B机房和C机房)。由于所有机房的分布式文件***中,存储的文件是相同的,所以在故障发生时,能起到故障转移的操作,从而达到整个跨机房计算的高可用。
参见图2,是本申请实施例提供的一种服务器结构示意图。该服务器200可因配置或性能不同而产生比较大的差异,可以包括一个或一个以***处理器(centralprocessing units,CPU)222(例如,一个或一个以上处理器)和存储器232,一个或一个以上存储应用程序242或数据244的存储介质230(例如一个或一个以上海量存储设备)。其中,存储器232和存储介质230可以是短暂存储或持久存储。存储在存储介质230的程序可以包括一个或一个以上模块(图示未示出),每个模块可以包括对服务器200中的一系列指令操作。
更进一步地,中央处理器222可以设置为与存储介质230通信,在服务器200上执行存储介质230中的一系列指令操作。服务器200还可以包括一个或一个以上电源226,一个或一个以上有线或无线网络接口250,一个或一个以上输入输出接口258,和/或,一个或一个以上操作***241,例如Windows ServerTM,Mac OS XTM,UnixTM,LinuxTM,FreeBSDTM等等。
本领域普通技术人员可以理解实现下述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
参照图3,示出了本申请的一种跨机房的任务调度方法实施例的步骤流程图。本实施例可以应用于管理节点中,例如应用于管理节点的Job Manager,其中,该管理节点位于第一机房中,例如图1中的A机房。本实施例具体可以包括如下步骤:步骤301,在接收到作业对象以后,根据已收集的各计算节点的负载信息,确定若干目标计算节点。
在本实施例中,Job Manager可以定期(例如,每分钟)采集所管理的各计算节点的负载信息,在一种例子中,Job Manager可以主动向各计算节点的Task Manager请求计算节点的负载信息,在另一种例子中,Job Manager还可以接收Task Manager主动上报的负载信息,本实施例对此不作限制。
负载信息又可以称为服务器压力,可以用于表示服务器的资源使用情况。示例性地,负载信息可以包括CPU负载(可以用服务器平均负载(linux load average,指***的运行队列的平均利用率)表示)、内存负载、磁盘负载等,除此以外,负载信息还可以包括服务器的逻辑核数。
在实现时,Job Manager获得各Task Manager的负载信息以后,可以将负载信息以及服务器标识关联记录在负载信息表中。
在一种实施方式中,步骤301中关于根据已收集的各计算节点的负载信息,确定若干目标计算节点的步骤,进一步可以包括如下子步骤:
子步骤S11,根据各计算节点的负载信息,确定该计算节点的指定空闲值。
例如,假设负载信息为CPU负载,则指定空闲值可以为CPU空闲值。在实现时,CPU空闲值=逻辑核数-CPU负载值。例如,某计算节点的逻辑核数为24,CPU负载值为10,则CPU空闲值为24-10=14。
得到各计算节点的指定空闲值以后,也可以将指定空闲值记录负载信息表中该计算节点的条目下。
子步骤S12,将指定空闲值最大的前N个计算节点,作为目标计算节点。
Job Manager在接收到新的作业对象后,可以将负载信息表中各计算节点的指定空闲值进行排序,挑选出N个计算节点作为目标计算节点。在一种实现中,可以将指定空闲值最大的前N个计算节点作为目标计算节点。其中,N可以为经验值,或者可以根据作业对象的大小确定,本实施例对此不作限制。
其中,N个目标计算节点分布于一个或多个第二机房中,该第二机房可以与第一机房相同或者不同,例如,第二机房可以包括图1中的B机房和C机房。
步骤302,根据所述目标计算节点的负载信息,确定各目标计算节点的任务调度信息。
在确定目标计算节点以后,则可以根据目标计算节点的负载信息,对作业对象进行划分,以确定对应的任务调度信息,从而实现负载均衡。其中,作业对象中可以包括多条数据记录。
示例性地,任务调度信息可以包括:该目标计算节点需要创建的任务处理模块的数量、作业对象划分至该目标计算节点的第一数据记录信息、第一数据记录信息再分配至各任务处理模块的第二数据记录信息,等等。则在一种实施方式中,步骤302可以包括如下子步骤:
子步骤S21,将所述目标计算节点的指定空闲值作为该目标计算节点需要创建的任务处理模块的数量。
例如,某个目标计算节点的CPU空闲值为14,则该目标计算节点的Task Manager需要创建的任务处理模块Task的数量为14个。这样,CPU的空闲核数越多,则其并行处理能力越强。若作业对象是CPU密集型的,在一些情况下可能会出现一个任务处理模块Task需要占用一个逻辑核的情况,则这个逻辑核的使用率能达到100%。
子步骤S22,汇总所有目标计算节点的指定空闲值,并根据所述汇总的结果计算各目标计算节点的空闲比例。
例如,假设目标计算节点有三个,分别为节点1、节点2和节点3,对应的指定空闲值分别为16、14和12,则三者之和为(16+14+12=42),节点1的空闲比例=16/42=38.0952%,节点2的空闲比例=14/42=33.3333%,节点3的空闲比例=12/42=28.5714%。
在一种实现中,在计算空闲比例后,为了便于计算,可以保留小数点后两位,并且对小数点第二位进位,则上述的三个空闲比例保留小数点后两位并进位后变成38.10%,33.34%和28.58%。当然,本实施例并不限于上述对空闲比例的处理,保留的小数位数可以根据实际业务情况决定,位数越多,则为每台服务器分配的数据记录越精确。
子步骤S23,按照所述空闲比例,对所述作业对象的数据记录的数量进行划分,得到对应的第一数据记录信息。
在该步骤中,可以将空闲比例作为作业分配比例,使得越空闲的节点获得分配的作业越多,从而实现负载均衡。在上述例子中,节点1、节点2和节点3的作业分配比例分别是38.10%,33.34%和28.58%。
例如,假设作业对象中有10000条数据记录,数据记录的编号为0-9999,则分配至节点1的第一数据记录信息为10000×38.10%=3810条,包括第0条至第3809条;分配至节点2的第一数据记录信息为10000×33.34%=3340条,包括第3810条至第7149条;分配至节点3的第一数据记录信息为10000-3810-3340=2850条,包括第7150条至第9999条。此处为最后一台服务器分配数据记录时,采用剩余数据记录而不采用百分比的计算方式,可以避免为前面的服务器分配数据记录的作业大小时,因为百分比中的小数除不尽而导致丢失部分数据记录的情况,使得数据分配更加完整精确。
子步骤S24,根据所述第一数据记录信息以及所述需要创建的任务处理模块的数量,确定所述第一数据记录信息再分配至各任务处理模块的第二数据记录信息。
例如,针对上例,节点1需要创建的任务处理模块的数量为16,需要分配的第一数据记录信息为(3810条,从第0条开始至第3809条),在计算该节点1中各任务处理模块Task的第二数据记录信息时,可以先计算3810/16=238.125,然后将小数进位取整,最后一个Task处理剩余的数据记录,即,前15个Task的第二数据记录信息为239(如,第一个Task需要处理的数据记录的编号为0-238,第二个Task需要处理的数据记录的编号为239-477,以此类推),最后一个Task的第二数据记录信息为225(例如,需要处理的数据记录的编号为3584-3809)。
同理,对于节点2,需要创建的任务处理模块的数量为14,需要分配的第一数据记录信息为3340,则前13个Task的第二数据记录信息为239,最后一个Task的第二数据记录信息为233。对于节点3,需要创建的任务处理模块的数量为12,需要分配的第一数据记录信息为2850,则前11个Task的第二数据记录信息为238,最后一个Task的第二数据记录信息为232。
在实现中,上述得到的任务调度信息可以一并记录在负载信息表中,则上例中负载信息表的记录如下:
可以看出,上述3台目标计算节点中每个Task处理的数据记录是比较平均的,达到负载均衡的效果。
在其他实施例中,在确定任务调度信息以后,也可以将各目标计算节点的任务调度信息与目标计算节点的标识关联记载在一张作业执行表里。具体的,在作业执行表里,可以记录每个目标计算节点中每个Task需要处理的数据记录的标识。
步骤303,按照所述第一数据记录信息以及所述第二数据记录信息将所述作业对象进行划分,得到对应的作业数据。
例如,根据上述的负载信息表,可以将作业对象划分成数量分别为3810、3340以及2850的作业数据。对于每一份作业数据,还可以根据需要创建的Task的数量进一步为每个Task划分对应的作业数据。
又如,如图4所示,假设作业对象(即图4中的作业的数据文件)中有10条数据记录,包括记录1-记录10。目标计算节点包括服务器1、服务器2和服务器3,在第一次划分时为各目标计算节点分配第一数据记录信息,如图4中为服务器1分配数据记录1-3,为服务器2分配数据记录4-6,服务器3分配数据记录7-10。然后在第二次划分时为每个目标计算节点的Task分配第二数据记录信息,如图4中为服务器1的Task1分配记录1,Task2分配记录2,Task3分配记录3,等等。
在实际中,划分出的各第一数据记录信息、第二数据记录信息以及对应的作业数据(即数据文件)可以存储在预设的存储介质中。则任务调度信息还可以包括:作业数据的存储路径和Task的程序文件的存储路径。
步骤304,针对各目标计算节点,将该目标计算节点对应的任务调度信息以及作业数据发送至该目标计算节点中。
在一种实施例中,Job Manager可以通过推送的方式向目标计算节点的TaskManager发送任务调度信息以及对应的作业数据,同时,Job Manager还可以向目标计算节点的Task Manager发送Task的程序文件。
例如,针对目标计算节点1,可以Job Manager将任务调度信息、Task的程序文件以及3810条数据记录发送给节点1的Task Manager。针对目标计算节点2,可以将任务调度信息、Task的程序文件以及3340条数据记录发送给节点2的Task Manager。针对目标计算节点3,可以将任务调度信息、Task的程序文件以及2850条数据记录发送给节点3的TaskManager。
在另一种实施例中,Job Manager还可以只向目标计算节点的Task Manager发送任务调度信息,然后Task Manager再从任务调度信息中获取作业数据的存储路径和Task的程序文件的存储路径,并根据获取的存储路径从分布式文件***中获取作业数据以及Task的程序文件。
然后,Task Manager根据获得的Task的程序文件创建对应数量的Task,并按照任务调度信息中的第二数据记录信息,将作业数据划分至各Task中,并运行Task。
在一种实施方式中,在步骤304之后,如图5所示,本实施例还可以包括如下步骤:
步骤305,接收各目标计算节点上报的处理结果。
其中,Job Manager接收的处理结果为目标计算节点收集所创建的各任务处理模块的运行结果后汇总得到的结果。具体的,对于目标计算节点而言,当Task运行完成以后,Task把运行结果上报给Task Manager。Task Manager将所有Task的运行结果进行汇总,得到处理结果,并将处理结果上报给Job Manager。
步骤306,汇总所有的处理结果,生成所述作业对象的作业结果。
在该步骤中,Job Manager接收到所有Task Manager的处理结果后进行汇总,得到作业对象的作业结果,此时表示整个作业对象的计算周期结束。
在本实施例中,在作业对象开始处理之前,由管理节点根据已收集的各计算节点的负载信息来确定若干目标计算节点,以及完成对作业对象的切分,然后将切分得到的作业数据以及任务调度信息发送给目标计算节点中。由目标计算节点创建任务处理模块,并按照任务处理模块的数量将接收的作业数据划分至各任务处理模块中进行处理。整个过程中,管理节点与目标计算节点的跨机房交互次数较少,很好地降低了数据传输失败的风险,而且成本低,大大提高了计算效率。且本实施例以服务器为维度进行任务划分,而不需要关注该服务器所处的机房的情况,很好地突破了机房范畴的约束。
参考图6,示出了本申请的一种任务处理的方法实施例的步骤流程图。本实施例可以应用于计算节点中,例如应用于计算节点的Task Manager,其中,该计算节点所处的机房与管理节点所处的机房并不相同,例如,管理节点可以位于第一机房中,例如图1中的A机房;计算节点位于第二机房中,例如图1中的B机房。
在本实施例中,该计算节点是由管理节点根据当前计算节点上报的负载信息挑选出的目标计算节点。示例性地,该负载信息可以包括CPU负载(可以用服务器平均负载(linux load average)表示)、内存负载、磁盘负载等,除此以外,负载信息还可以包括服务器的逻辑核数。
对于计算节点而言,该计算节点的Task Manager会定时(例如,每分钟)采集当前计算节点的负载信息并上报给Job Manager,负载信息例如是Linux load average(例如1分钟、5分钟、15分钟的平均统计数值,具体使用哪一个值,可以根据业务决定)。在一种实现方式中,在Linux服务器上,Task Manager可以定时通过top或uptime命令,查到loadaverage每1分钟、5分钟或15分钟的平均负载值。另外,还可以通过“cat/proc/cpuinfo|grep"processor"|wc-l”命令得到该台服务器的逻辑核数。
本实施例具体可以包括如下步骤:
步骤601,接收管理节点发送的任务调度信息以及作业数据;
示例性地,任务调度信息可以包括:当前计算节点需要创建的任务处理模块的数量、作业数据对应的第一数据记录信息、第一数据记录信息再分配至各任务处理模块的第二数据记录信息、Task程序文件的存储路径、作业数据的存储路径,等等。
例如,当前计算节点需要创建的任务处理模块的数量为16,作业分配比例为38.10%,分配至当前计算节点的第一数据记录信息为3810条数据记录,第一数据记录信息再分配至各Task的第二数据记录信息为239个。
步骤602,根据所述需要创建的任务处理模块的数量,创建对应数量的任务处理模块。
在该步骤中,Task Manager可以根据Task程序文件的存储路径获取对应的Task程序文件,然后根据需要创建的任务处理模块Task的数量,采用Task程序文件创建对应数量的Task,例如,创建16个Task。
步骤603,将所述作业数据按照所述第二数据记录信息,划分至各任务处理模块中,并运行所述任务处理模块。
在该步骤中,在创建Task的过程中,Task Manager将接收的作业数据再分配到各Task中,例如,第二数据记录信息为239个,则Task Manager针对前15个Task分别分配239个数据记录,对于最后一个Task则分配剩余的数据记录,即225条。
对各Task部署完毕以后,Task Manager启动运行各Task。
在一种实施方式中,在步骤603后,本实施例还可以包括如下步骤:
获取各任务处理模块的运行结果;汇总所有的运行结果,得到处理结果,并将所述处理结果上报所述管理节点。
在该实施例中,Task运行完毕以后,可以把运行结果上报给Task Manager。TaskManager获得各Task上报的运行结果以后,对所有的运行结果汇总成处理结果,并把处理结果上报到Job Manager中,至此,Task的生命周期结束,可以由Task Manager关闭和删除Task的部署文件。
在本实施例中,计算节点只需要根据管理节点下发的任务调度信息来创建Task进行作业数据处理,节省了计算节点的处理流程和计算资源,提高了计算节点的处理效率。
参考图7,示出了本申请的一种分布式***中故障处理的方法实施例的步骤流程图。本实施例应用于管理节点在任务调度后的故障检测和故障转移的场景中,包括如下步骤:
步骤701,确定发生故障的目标计算节点的故障信息。
在该实施例中,目标计算节点为分配有作业需要处理的计算节点。
示例性地,计算节点发生故障的场景可以包括但不限于如下场景:
场景一:Task故障,指Task的进程非正常退出,例如,因机器内存不足使得Task被服务器杀掉(kill)等。
场景二:服务器故障,指服务器因硬件损坏而不可用,例如,电源损坏、磁盘损坏、内存条损坏、CPU损坏、网卡损坏等。
场景三:机房故障,指机房由于某些原因而不可用,例如光缆被意外挖断、总电源故障,或其他不可抵抗的自然灾害等。
在一种例子中,故障信息可以包括但不限于:目标计算节点中发生故障的Task的标识。其中,Task的标识可以包括目标计算节点的标识以及Task的编号。
在一种实施方式中,步骤701可以包括如下子步骤:
接收目标计算节点上报的故障信息,所述故障信息为所述目标计算节点检测到与其创建的一个或多个任务处理模块的心跳超时时生成的信息。
具体的,Task Manager与Task之间保持心跳通讯,因此Task Manager能感知Task当前的状态是正常还是故障。当Task Manager在预设时间段内没有接收到某个Task的心跳信息(即心跳超时),但能接收到其他Task的心跳信息,则可以判定该心跳超时对应的Task发生故障,此时可以获取该Task的标识,并将该Task的标识上报给Job Manager。
在其他实施例中,若Task Manager在预设时间段内没有接收到任一Task的心跳信息,此时可以判定所有Task故障,或者判定Task Manager故障,或Task Manager所在的服务器故障。
在另一种实施方式中,步骤701可以包括如下子步骤:
在与各目标计算节点的心跳检测过程中,若存在心跳超时,则判定该心跳超时对应的目标计算节点发生故障;获取所述心跳超时对应的目标计算节点中的任务处理模块的标识,生成故障信息。
在该实施例中,Job Manager与Task Manager之间保持心跳通讯,因此JobManager能感知Task Manager当前的状态是正常还是故障。当Job Manager在预设时间段内没有接收到某个Task Manager的心跳信息(即心跳超时),但能接收到其他Task Manager的心跳信息,则可以判定该心跳超时对应的Task Manager发生故障,即判定该Task Manager对应的服务器发生故障。此时,Job Manager可以获取该发生故障的计算节点中包含的所有Task的标识生成故障信息。
在其他实施例中,当Job Manager检测到发生故障的Task Manager有多个,且该多个发生故障的Task Manager均处于同一机房中,例如,发生故障的Task Manager为某个机房的全部Task Manager,即机房中的所有Task Manager均发生故障,则可以判定该机房发生故障。
步骤702,确定发生故障的任务处理模块的数量。
在实现时,Job Manager根据接收的发生故障的Task的标识,可以统计发生故障的Task的数量。
步骤703,根据所述发生故障的任务处理模块的数量以及已收集的各计算节点的负载信息,确定一个或多个替代计算节点。
在该步骤中,当检测到故障发生时,Job Manager可以根据已收集的各计算节点的负载信息以及发生故障的Task的数量,确定一个或多个替代计算节点,该替代计算节点为用于进行故障转移的计算节点。其中,故障转移即当活动的服务或应用意外终止时,快速启用冗余或备用的服务器、***、硬件或者网络接替它们工作。
在一种实施方式中,步骤602可以包括如下子步骤:
子步骤S31,根据各计算节点的负载信息,确定该计算节点的指定空闲值。
在该步骤中,各计算节点可以为除故障的计算节点以外的计算节点。可以从负载信息表中读取各计算节点的指定空闲值。
子步骤S32,若最大的指定空闲值能覆盖发生故障的任务处理模块的数量,则将该最大的指定空闲值对应的计算节点作为替代计算节点。
子步骤S33,若最大的指定空闲值不能覆盖发生故障的任务处理模块的数量,则继续往下累积次大的指定空闲值,直到累积的指定空闲值能覆盖发生故障的任务处理模块的数量,则将累积的指定空闲值对应的计算节点作为替代计算节点。
在该实施例中,选取的替代计算节点的数量与发生故障的Task的数量相关,使得替代计算节点能够完成发生故障的Task中的作业。
在实现时,可以将指定空闲值由大到小进行排序,首先选取指定空闲值最大的计算节点,判断该最大的指定空闲值是否大于或等于发生故障的Task的数量,如果是,则判定最大的指定空闲值能覆盖发生故障的任务处理模块的数量,此时可以将该最大的指定空闲值对应的计算节点作为替代计算节点。
如果该最大的指定空闲值小于发生故障的Task的数量,即最大的指定空闲值不能覆盖发生故障的任务处理模块的数量,则继续向下取,计算次大的指定空闲值与最大的指定空闲值之和是否大于或等于发生故障的Task的数量,如果是,则将该次大的指定空闲值对应的计算节点和最大的指定空闲值对应的计算节点作为替代计算节点;如果否,则继续往下取,以此类推,直到累积的指定空闲值能覆盖发生故障的Task的数量。例如,假设发生故障的Task的数量为18个,前四个计算节点的指定空闲值由大到小分别是10个、9个、8个、7个,则可以将前两个计算节点作为替代计算节点。
需要说明的是,在选取替代计算节点时,除了按照上述指定空闲值由大到小排序的方式选定以外,还可以采用其他方式,本实施例对此不作限制。例如,选取与发生故障的Task的数量相近的指定空闲值对应的计算节点作为替代计算节点,例如,发生故障的Task的数量为3,若有个计算节点的指定空闲值刚好为3,则可以选取该计算节点作为替代计算节点,实现对空闲资源的充分利用。
步骤704,为所述替代计算节点分配并下发对接的、发生故障的任务处理模块的标识。
在该步骤中,当确定替代计算节点以后,则Job Manager可以为替代计算节点的Task Manager分配并下发其需要对接的、发生故障的Task的标识。
在一种实施方式中,步骤604可以包括如下子步骤:
子步骤S41,若所述替代计算节点为一个,则将所有发生故障的任务处理模块的标识分配给该替代计算节点。
例如,若替代计算节点为一个,发生故障的Task的数量为3个,则可以将该3个发生故障的Task的标识发送给该替代节点。
子步骤S42,若所述替代计算节点超过一个,则将发生故障的任务处理模块的标识按照所述替代计算节点的指定空闲值由大到小的顺序分配。
例如,假设发生故障的Task的数量为18个,选取的替代计算节点为2个,对应的指定空闲值分别是10和9,则可以随机从18个发生故障的Task中选取10个Task的标识分配给第一个替代计算节点,然后将剩余的8个Task的标识分配给第二个替代计算节点。
针对替代计算节点而言,可以由其对应的Task Manager接收发生故障的Task的标识,然后Task Manager可以从所处机房的分布式文件***中读取该发生故障的Task的标识对应的任务数据文件和Task的程序文件,并根据该Task的程序文件在本计算节点中创建Task,由该创建的Task对任务数据文件进行作业处理。
为了使得本领域技术人员能够更好地理解本申请实施例,如下结合图1,通过示例性流程说明步骤701中三种场景的故障转移处理过程:
场景一:Task故障,参照图7a所示,
(1)B机房中的服务器1的负载过高,内存不足,Task 1被服务器1的***kill掉。
(2)Task Manager把该Task 1的故障状态上报给Job Manager。
(3)Job Manager从其他低负载的服务器列表中挑选出一台,例如图中C机房的服务器1,然后把故障的Task1的标识下发给该服务器中的Task Manager。
(4)C机房服务器1的Task Manager从Job Manager接收原故障Task 1的标识,从本机房的分布式文件***中,读取出原故障Task 1的作业的数据文件和Task的程序文件,然后在本服务器上采用该Task的程序文件创建一个新的Task 1,并重新运行该数据文件。
至此,原来B机房服务器1的故障节点Task 1就转移到了C机房服务器1中运行,即实现了Task维度的故障转移。
场景二:服务器故障,参照图7b所示,
(1)B机房的服务器1发生故障后,Task Manager与Job Manager心跳超时。
(2)Job Manager判断该服务器故障,然后从正常的、低负载的服务器列表中,挑选出N台服务器,例如B机房的服务器2和C机房的服务器1。然后把故障的服务器1的计算任务重新分配给这N台服务器,由这N台服务器的Task Manager从Job Manager接收原故障服务器的计算任务,然后在本机房的分布式文件***中,读取出原故障服务器中相应的Task的数据文件,并在本机器中创建新的Task并重新运行。
至此,原来B机房的故障服务器1中的所有Task节点就转移到了其他服务器中运行,即实现了服务器维度的故障转移。
场景三:机房故障,参照图7c所示,(1)当B机房发生故障时,该机房内所有的TaskManager与Job Manager的心跳超时。
(2)Job Manager判断B机房的所有服务器故障,然后Job Manager从其他机房的正常的、低负载的服务器列表中,挑选出N台服务器,例如图中C机房的服务器1和服务器2。然后把故障的B机房的计算任务重新分配给这N台服务器,由这N台服务器的Task Manager从Job Manager接收原故障B机房的计算任务,然后从本机房的分布式文件***中,读取出原故障机房B中相应Task的数据文件,并在本机器中创建新的Task并重新运行。
至此,原来故障的B机房中的所有Task节点就转移到了其机房的服务器中运行,即实现了机房维度的故障转移。
在本实施例中,在不同机房中通过分布式文件***进行数据同步,因此在计算节点发生故障时,管理节点只需要根据发生故障的目标计算节点的故障信息,确定发生故障的任务处理模块的数量,以及,确定用于进行故障转移的替代计算节点,并为替代计算节点的Task Manager分配并下发对接的、发生故障的Task的标识,以使得Task Manager根据发生故障的Task的标识,从所处机房的分布式文件***中读取该发生故障的任务处理模块的标识对应的任务数据文件和程序文件,并根据所述程序文件创建新的任务处理模块来对任务数据文件进行作业处理,以此实现多维度的故障检测和故障转移,提高跨机房的计算节点以及各机房的高可用性,适用于提供大量计算能力、并且要求整体架构高可用的场景。
参考图8,示出了本申请的一种分布式***中的任务处理方法实施例的步骤流程图。本实施例应用于计算节点中,包括如下步骤:
步骤801,接收管理节点发送的发生故障的任务处理模块的标识。
示例性地,任务处理模块的标识可以包括该任务处理模块所在的计算节点的标识以及任务处理模块的编号。各任务处理模块的标识都是全局唯一的标识。
步骤802,在所处机房的分布式文件***中查找该发生故障的任务处理模块的标识对应的任务数据文件和程序文件。
在一种实现中,分布式文件***中存储了各任务处理模块的标识及对应的任务数据文件和程序文件。当Task Manager接收到Job Manager发送的发生故障的Task的标识以后,可以根据该Task的标识查找分布式文件***,以获得该标识对应的任务数据文件和程序文件。
步骤803,根据接收到的任务处理模块的标识,确定发生故障的任务处理模块的数量。
在该步骤中,Task Manager可以统计接收到的发生故障的Task的标识,来得到该发生故障的Task的数量。
步骤804,根据所述程序文件在当前计算节点中创建所述数量对应的任务处理模块,并将所述任务数据文件分配至各任务处理模块,以由所述任务处理模块对所述任务数据文件进行作业处理。
在该步骤中,当Task Manager确定发生故障的Task的数量以后,可以根据获取的Task的程序文件创建该数量对应的新的Task,由该新的Task来对任务数据文件进行处理,并采集该新的Task的运行结果上报给Job Manager。
在本实施例中,在不同机房中通过分布式文件***进行数据同步,因此在计算节点发生故障时,Task Manager在接收到Job Manager发送的发生故障的Task的标识以后,可以根据该Task的标识查找分布式文件***,以获得该标识对应的任务数据文件和程序文件,并在本地创建对应数量的Task来对任务数据文件进行处理,从而实现故障转移。
参照图9,示出了本申请一种分布式***中故障处理的装置实施例的结构框图,所述分布式***包括分布在不同机房中的管理节点和计算节点,其中,各机房具有用于进行数据同步的分布式文件***;所述计算节点包括任务处理模块;所述装置应用于管理节点中,所述装置可以包括如下单元:
故障信息确定单元901,用于确定发生故障的目标计算节点的故障信息,所述故障信息包括所述目标计算节点中发生故障的任务处理模块的标识;
数量确定单元902,用于确定发生故障的任务处理模块的数量;
替代计算节点确定单元903,用于根据所述发生故障的任务处理模块的数量以及已收集的各计算节点的负载信息,确定一个或多个替代计算节点;
分配单元904,用于为所述替代计算节点分配并下发对接的、发生故障的任务处理模块的标识,以由所述任务管理模块根据所述发生故障的任务处理模块的标识,从所处机房的分布式文件***中读取该发生故障的任务处理模块的标识对应的任务数据文件和程序文件,并根据所述程序文件创建任务处理模块对所述任务数据文件进行作业处理。
在一种实施方式中,所述故障信息确定单元901具体用于:
接收目标计算节点上报的故障信息,所述故障信息为所述目标计算节点检测到与其创建的一个或多个任务处理模块的心跳超时时生成的信息。
在另一种实施方式中,所述故障信息确定单元901具体用于:
在与各目标计算节点的心跳检测过程中,若存在心跳超时,则判定该心跳超时对应的目标计算节点发生故障;
获取所述心跳超时对应的目标计算节点中的任务处理模块的标识,生成故障信息。
在一种实施方式中,所述替代计算节点确定单元903具体用于:
根据各计算节点的负载信息,确定该计算节点的指定空闲值;
若最大的指定空闲值能覆盖发生故障的任务处理模块的数量,则将该最大的指定空闲值对应的计算节点作为替代计算节点;
若最大的指定空闲值不能覆盖发生故障的任务处理模块的数量,则继续往下累积次大的指定空闲值,直到累积的指定空闲值能覆盖发生故障的任务处理模块的数量,则将累积的指定空闲值对应的计算节点作为替代计算节点。
在一种实施方式中,所述分配单元904具体用于:
若所述替代计算节点为一个,则将所有发生故障的任务处理模块的标识分配给该替代计算节点;
若所述替代计算节点超过一个,则将发生故障的任务处理模块的标识按照所述替代计算节点的指定空闲值由大到小的顺序分配。
参照图10,示出了本申请一种分布式***中的任务处理装置实施例的结构框图,所述分布式***包括分布在不同机房中的管理节点和计算节点,其中,各机房具有用于进行数据同步的分布式文件***;所述装置应用于计算节点中,所述装置可以包括如下单元:
标识接收单元1001,用于接收管理节点发送的发生故障的任务处理模块的标识;
作业数据查找单元1002,用于在所处机房的分布式文件***中查找该发生故障的任务处理模块的标识对应的任务数据文件和程序文件;
数量确定单元1003,用于根据接收到的任务处理模块的标识,确定发生故障的任务处理模块的数量;
任务处理单元1004,用于根据所述程序文件在当前计算节点中创建所述数量对应的任务处理模块,并将所述任务数据文件分配至各任务处理模块,以由所述任务处理模块对所述任务数据文件进行作业处理。
关于上述实施例中的装置,其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述,此处将不做详细阐述说明。
虽然本说明书包含许多具体实施细节,但是这些不应被解释为限制任何发明的范围或所要求保护的范围,而是主要用于描述特定发明的具体实施例的特征。本说明书内在多个实施例中描述的某些特征也可以在单个实施例中被组合实施。另一方面,在单个实施例中描述的各种特征也可以在多个实施例中分开实施或以任何合适的子组合来实施。此外,虽然特征可以如上所述在某些组合中起作用并且甚至最初如此要求保护,但是来自所要求保护的组合中的一个或多个特征在一些情况下可以从该组合中去除,并且所要求保护的组合可以指向子组合或子组合的变型。
类似地,虽然在附图中以特定顺序描绘了操作,但是这不应被理解为要求这些操作以所示的特定顺序执行或顺次执行、或者要求所有例示的操作被执行,以实现期望的结果。在某些情况下,多任务和并行处理可能是有利的。此外,上述实施例中的各种***模块和组件的分离不应被理解为在所有实施例中均需要这样的分离,并且应当理解,所描述的程序组件和***通常可以一起集成在单个软件产品中,或者封装成多个软件产品。
由此,主题的特定实施例已被描述。其他实施例在所附权利要求书的范围以内。在某些情况下,权利要求书中记载的动作可以以不同的顺序执行并且仍实现期望的结果。此外,附图中描绘的处理并非必需所示的特定顺序或顺次顺序,以实现期望的结果。在某些实现中,多任务和并行处理可能是有利的。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。
Claims (10)
1.一种分布式***中故障处理的方法,其特征在于,所述分布式***包括分布在不同机房中的管理节点和计算节点,其中,各机房具有用于进行数据同步的分布式文件***;所述计算节点包括任务处理模块;所述方法应用于管理节点中,包括:
确定发生故障的目标计算节点的故障信息,所述故障信息包括所述目标计算节点中发生故障的任务处理模块的标识;
确定发生故障的任务处理模块的数量;
根据所述发生故障的任务处理模块的数量以及已收集的各计算节点的负载信息,确定一个或多个替代计算节点;
为所述替代计算节点分配并下发对接的、发生故障的任务处理模块的标识,以由所述任务管理模块根据所述发生故障的任务处理模块的标识,从所处机房的分布式文件***中读取该发生故障的任务处理模块的标识对应的任务数据文件和程序文件,并根据所述程序文件创建任务处理模块对所述任务数据文件进行作业处理。
2.根据权利要求1所述的方法,其特征在于,所述确定发生故障的目标计算节点的故障信息,包括:
接收目标计算节点上报的故障信息,所述故障信息为所述目标计算节点检测到与其创建的一个或多个任务处理模块的心跳超时时生成的信息。
3.根据权利要求1所述的方法,其特征在于,所述确定发生故障的目标计算节点的故障信息,包括:
在与各目标计算节点的心跳检测过程中,若存在心跳超时,则判定该心跳超时对应的目标计算节点发生故障;
获取所述心跳超时对应的目标计算节点中的任务处理模块的标识,生成故障信息。
4.根据权利要求1-3任一项所述的方法,其特征在于,所述根据所述发生故障的任务处理模块的数量以及已收集的各计算节点的负载信息,确定一个或多个替代计算节点,包括:
根据各计算节点的负载信息,确定该计算节点的指定空闲值;
若最大的指定空闲值能覆盖发生故障的任务处理模块的数量,则将该最大的指定空闲值对应的计算节点作为替代计算节点;
若最大的指定空闲值不能覆盖发生故障的任务处理模块的数量,则继续往下累积次大的指定空闲值,直到累积的指定空闲值能覆盖发生故障的任务处理模块的数量,则将累积的指定空闲值对应的计算节点作为替代计算节点。
5.根据权利要求4所述的方法,其特征在于,所述为所述替代计算节点分配并下发对接的、发生故障的任务处理模块的标识,包括:
若所述替代计算节点为一个,则将所有发生故障的任务处理模块的标识分配给该替代计算节点;
若所述替代计算节点超过一个,则将发生故障的任务处理模块的标识按照所述替代计算节点的指定空闲值由大到小的顺序分配。
6.一种分布式***中的任务处理方法,其特征在于,所述分布式***包括分布在不同机房中的管理节点和计算节点,其中,各机房具有用于进行数据同步的分布式文件***;所述方法应用于计算节点中,包括:
接收管理节点发送的发生故障的任务处理模块的标识;
在所处机房的分布式文件***中查找该发生故障的任务处理模块的标识对应的任务数据文件和程序文件;
根据接收到的任务处理模块的标识,确定发生故障的任务处理模块的数量;
根据所述程序文件在当前计算节点中创建所述数量对应的任务处理模块,并将所述任务数据文件分配至各任务处理模块,以由所述任务处理模块对所述任务数据文件进行作业处理。
7.一种分布式***中故障处理的装置,其特征在于,所述分布式***包括分布在不同机房中的管理节点和计算节点,其中,各机房具有用于进行数据同步的分布式文件***;所述计算节点包括任务处理模块;所述装置应用于管理节点中,包括:
故障信息确定单元,用于确定发生故障的目标计算节点的故障信息,所述故障信息包括所述目标计算节点中发生故障的任务处理模块的标识;
数量确定单元,用于确定发生故障的任务处理模块的数量;
替代计算节点确定单元,用于根据所述发生故障的任务处理模块的数量以及已收集的各计算节点的负载信息,确定一个或多个替代计算节点;
分配单元,用于为所述替代计算节点分配并下发对接的、发生故障的任务处理模块的标识,以由所述任务管理模块根据所述发生故障的任务处理模块的标识,从所处机房的分布式文件***中读取该发生故障的任务处理模块的标识对应的任务数据文件和程序文件,并根据所述程序文件创建任务处理模块对所述任务数据文件进行作业处理。
8.一种分布式***中的任务处理装置,其特征在于,所述分布式***包括分布在不同机房中的管理节点和计算节点,其中,各机房具有用于进行数据同步的分布式文件***;所述装置应用于计算节点中,包括:
标识接收单元,用于接收管理节点发送的发生故障的任务处理模块的标识;
作业数据查找单元,用于在所处机房的分布式文件***中查找该发生故障的任务处理模块的标识对应的任务数据文件和程序文件;
数量确定单元,用于根据接收到的任务处理模块的标识,确定发生故障的任务处理模块的数量;
任务处理单元,用于根据所述程序文件在当前计算节点中创建所述数量对应的任务处理模块,并将所述任务数据文件分配至各任务处理模块,以由所述任务处理模块对所述任务数据文件进行作业处理。
9.一种电子设备,其特征在于,包括:
处理器;
用于存储所述处理器可执行指令的存储器;
其中,所述处理器被配置为执行所述指令,以实现如权利要求1-5任一项和/或6所述的方法。
10.一种存储介质,当所述存储介质中的指令由所述设备的处理器执行时,使得所述电子设备能够执行如权利要求1-5中任一项和/或6所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010271224.1A CN111459642B (zh) | 2020-04-08 | 2020-04-08 | 一种分布式***中故障处理和任务处理方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010271224.1A CN111459642B (zh) | 2020-04-08 | 2020-04-08 | 一种分布式***中故障处理和任务处理方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111459642A true CN111459642A (zh) | 2020-07-28 |
CN111459642B CN111459642B (zh) | 2023-04-28 |
Family
ID=71678926
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010271224.1A Active CN111459642B (zh) | 2020-04-08 | 2020-04-08 | 一种分布式***中故障处理和任务处理方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111459642B (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2022007552A1 (zh) * | 2020-07-08 | 2022-01-13 | 腾讯科技(深圳)有限公司 | 处理节点的管理方法、配置方法及相关装置 |
CN115499296A (zh) * | 2022-07-29 | 2022-12-20 | 天翼云科技有限公司 | 一种云桌面热备管理方法、装置及*** |
CN115933565A (zh) * | 2022-12-23 | 2023-04-07 | 广东职业技术学院 | 一种agv任务交换方法、装置、***和介质 |
CN116701043A (zh) * | 2023-08-04 | 2023-09-05 | 浪潮电子信息产业股份有限公司 | 面向异构计算***的故障节点切换方法、装置和设备 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060200494A1 (en) * | 2005-03-02 | 2006-09-07 | Jonathan Sparks | Automated discovery and inventory of nodes within an autonomic distributed computing system |
JP2010231295A (ja) * | 2009-03-26 | 2010-10-14 | Fuji Xerox Co Ltd | 解析システム |
US20110228668A1 (en) * | 2010-03-22 | 2011-09-22 | Infosys Technologies Limited | Method and system for automatic failover of distributed query processing using distributed shared memory |
CN103716182A (zh) * | 2013-12-12 | 2014-04-09 | 中国科学院信息工程研究所 | 一种面向实时云平台的故障检测与容错方法及*** |
US20140310258A1 (en) * | 2013-04-15 | 2014-10-16 | Vmware, Inc. | Fault Tolerant Distributed Query Processing Using Query Operator Motion |
US9672122B1 (en) * | 2014-09-29 | 2017-06-06 | Amazon Technologies, Inc. | Fault tolerant distributed tasks using distributed file systems |
CN110635936A (zh) * | 2018-06-22 | 2019-12-31 | 布尔有限公司 | 基于全局策略管理节点网络故障的程序 |
-
2020
- 2020-04-08 CN CN202010271224.1A patent/CN111459642B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060200494A1 (en) * | 2005-03-02 | 2006-09-07 | Jonathan Sparks | Automated discovery and inventory of nodes within an autonomic distributed computing system |
JP2010231295A (ja) * | 2009-03-26 | 2010-10-14 | Fuji Xerox Co Ltd | 解析システム |
US20110228668A1 (en) * | 2010-03-22 | 2011-09-22 | Infosys Technologies Limited | Method and system for automatic failover of distributed query processing using distributed shared memory |
US20140310258A1 (en) * | 2013-04-15 | 2014-10-16 | Vmware, Inc. | Fault Tolerant Distributed Query Processing Using Query Operator Motion |
CN103716182A (zh) * | 2013-12-12 | 2014-04-09 | 中国科学院信息工程研究所 | 一种面向实时云平台的故障检测与容错方法及*** |
US9672122B1 (en) * | 2014-09-29 | 2017-06-06 | Amazon Technologies, Inc. | Fault tolerant distributed tasks using distributed file systems |
US20170249215A1 (en) * | 2014-09-29 | 2017-08-31 | Amazon Technologies, Inc. | Fault tolerant distributed tasks using distributed file systems |
CN110635936A (zh) * | 2018-06-22 | 2019-12-31 | 布尔有限公司 | 基于全局策略管理节点网络故障的程序 |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2022007552A1 (zh) * | 2020-07-08 | 2022-01-13 | 腾讯科技(深圳)有限公司 | 处理节点的管理方法、配置方法及相关装置 |
CN115499296A (zh) * | 2022-07-29 | 2022-12-20 | 天翼云科技有限公司 | 一种云桌面热备管理方法、装置及*** |
CN115499296B (zh) * | 2022-07-29 | 2024-03-12 | 天翼云科技有限公司 | 一种云桌面热备管理方法、装置及*** |
CN115933565A (zh) * | 2022-12-23 | 2023-04-07 | 广东职业技术学院 | 一种agv任务交换方法、装置、***和介质 |
CN115933565B (zh) * | 2022-12-23 | 2023-10-20 | 广东职业技术学院 | 一种agv任务交换方法、装置、***和介质 |
CN116701043A (zh) * | 2023-08-04 | 2023-09-05 | 浪潮电子信息产业股份有限公司 | 面向异构计算***的故障节点切换方法、装置和设备 |
CN116701043B (zh) * | 2023-08-04 | 2024-01-12 | 浪潮电子信息产业股份有限公司 | 面向异构计算***的故障节点切换方法、装置和设备 |
Also Published As
Publication number | Publication date |
---|---|
CN111459642B (zh) | 2023-04-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111459642B (zh) | 一种分布式***中故障处理和任务处理方法及装置 | |
CN106126346B (zh) | 一种大规模分布式数据采集***及方法 | |
CN110308983B (zh) | 资源负载均衡方法及***、服务节点和客户端 | |
CN111459641B (zh) | 一种跨机房的任务调度和任务处理的方法及装置 | |
US8874811B2 (en) | System and method for providing a flexible buffer management interface in a distributed data grid | |
US9319281B2 (en) | Resource management method, resource management device, and program product | |
US20180091586A1 (en) | Self-healing a message brokering cluster | |
US10333859B2 (en) | Multi-tenant resource coordination method | |
CN107864211B (zh) | 集群资源调度方法及*** | |
CN104081354A (zh) | 在可缩放环境中管理分区 | |
CN116340005B (zh) | 容器集群的调度方法、装置、设备及存储介质 | |
CN111414241A (zh) | 批量数据处理方法、装置、***、计算机设备及计算机可读存储介质 | |
CN111045811A (zh) | 一种任务分配方法、装置、电子设备及存储介质 | |
CN112631764A (zh) | 任务调度方法、装置、计算机设备和计算机可读介质 | |
CN112463395A (zh) | 一种资源分配方法、装置、设备及可读存储介质 | |
CN112162839A (zh) | 任务调度方法、装置、计算机设备和存储介质 | |
CN110377664B (zh) | 数据同步方法、装置、服务器及存储介质 | |
CN114338670A (zh) | 一种边缘云平台和具有其的网联交通三级云控平台 | |
US11561824B2 (en) | Embedded persistent queue | |
US11824922B2 (en) | Operating cloud-managed remote edge sites at reduced disk capacity | |
US20230155958A1 (en) | Method for optimal resource selection based on available gpu resource analysis in large-scale container platform | |
US20230185631A1 (en) | Embedded capacity-computer module for microservice load balancing and distribution | |
CN114090201A (zh) | 资源调度方法、装置、设备及存储介质 | |
KR102231359B1 (ko) | 고성능 클라우드 서비스를 위한 단일 가상화 시스템 및 프로세스 스케줄링 방법 | |
JP6277069B2 (ja) | 仮想機器管理装置、仮想機器管理方法及び仮想機器管理プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |