CN113542001B - Osd故障心跳检测方法、装置、设备及存储介质 - Google Patents

Abstract

本公开提供了一种OSD故障心跳检测方法、装置、设备及存储介质，用于解决OSD故障无法被及时有效检测到的技术问题。本公开技术方案中，MON为每个OSD进程建立故障检测队列，基于故障检测队列中的OSD故障消息统计被报故障的目标OSD进程是否满足故障确认条件，当不重复的上报者OSD进程所在节点总数超过目标OSD进程所在节点的伙伴节点的总数的一半时，MON才将目标OSD标记为故障状态，从而OSD故障漏报问题。

Description

OSD故障心跳检测方法、装置、设备及存储介质

技术领域

本公开涉及计算及存储技术领域，尤其涉及一种OSD故障心跳检测方法、装置、设备及存储介质。

背景技术

Ceph是一种分布式存储系统。一个Ceph存储集群通常包括监视器(Monitor)，管理器和对象存储设备(Object Storage Device，OSD)，运行Ceph文件系统客户端时，还需要元数据服务(MetaData Server，MDS)。

监视器Monitor负责监视整个集群的运行状况，如各个节点之间的状态、集群配置信息等，监视器维护着集群状态的映射，包括监视器映射，管理器映射，OSD映射，MDS映射和CRUSH映射。这些映射是Ceph成员设备上的守护程序相互协调所需的关键群集信息。

管理器负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率，当前性能指标和系统负载。

对象存储设备OSD是由物理磁盘驱动器、在其之上的Linux文件系统以及Ceph OSD守护进程等几个部分组成，本公开中所称的节点在不引起歧义的情况下指承载OSD的物理节点设备。Ceph OSD将数据以对象的形式存储到集群中的每个节点的物理磁盘上，完成存储数据的工作绝大多数是由OSD守护进程(OSD daemon，简称OSD进程)实现的。一个OSD设备上至少会部署一个OSD守护进程。OSD守护进程用于存储数据，处理数据复制，恢复，重新平衡，并通过检查其他Ceph OSD守护进程的心跳来向Ceph监视器和管理器提供一些监视信息。

当存储集群中包含大量OSD时，保障对外业务不中断，及时和完善的OSD故障检测能力尤为重要。当前，监视器一共有3种机制检测OSD故障：

第一种机制是OSD自主上报。

第二种机制是OSD之间通过周期性的心跳检测，监控彼此之间的状态，若超过一定时间没有收到某个伙伴OSD的应答消息，则向监视器上报该OSD失联消息(即报该失联OSDDown)。监视器收到该报Down消息后，判断上报该失联的OSD Down的节点数是否超过半数，如果超过半数，则监视器将该失联OSD标记为Down。

第三种机制是看门狗机制，每个OSD需要周期性(默认为300s)地向监视器发送Beacon消息进行保活，如果监视器在一段时间内(默认为900s)没有收到过某个OSD的任何Beacon消息，则将该OSD标记为Down。

现有心跳检测机制中，当有半数节点都报某一个OSD失联时，监视器就会将该失联OSD标记为故障(Down)状态。但是集群规模较大时，OSD建立心跳的范围未必会覆盖到所有OSD节点，那么就有可能出现有OSD故障而无法被报Down的情况。另外，在单点故障上报信息未被及时清理的情况下，如果产生累积效应，那么后续再出现其它OSD节点单点故障时，可能会导致满足报Down的条件，从而使监视器MON将某些OSD误标为Down状态。

发明内容

有鉴于此，本公开提供一种OSD故障心跳检测方法、装置、设备及存储介质，用于解决OSD故障无法被及时有效检测到的技术问题。

图1为本公开提供的一种OSD故障心跳检测方法的步骤流程图，该方法应用于分布式存储集群中的监视器MON，该方法包括：

步骤101.监视器MON接收对象存储设备OSD进程基于心跳检测机制上报的OSD故障消息，所述OSD故障消息中携带上报者OSD进程所在节点的标识、目标OSD进程所在节点的标识；

步骤102.MON将接收到的OSD故障消息存入目标OSD进程的故障检测队列；

步骤103.统计目标OSD进程的故障检测队列中不重复的上报者OSD进程所在节点总数N；

步骤104.根据故障检测队列中的OSD故障消息，判断目标OSD进程是否满足故障确认条件；故障确认条件为：不重复的上报者OSD进程所在节点总数N超过目标OSD进程所在节点的伙伴节点的总数M的一半；所述伙伴节点是指节点上的OSD进程之间建立心跳检测机制的节点；

步骤105.当判定目标OSD进程满足故障确认条件时，MON标记所述目标OSD进程为故障状态。

进一步地，所述方法还包括：

所述OSD故障消息中还携带故障产生时间；

MON周期性扫描每个OSD进程的故障检测队列中的OSD故障消息，判断OSD故障消息中的故障产生时间是否超过预设的老化时间，若超过预设的老化时间，则从故障检测队列中删除该OSD故障消息。

进一步地，目标OSD进程所在节点的伙伴节点总数M由MON基于自身所维护的集群映射关系中获得，集群映射关系中包括OSD进程之间是否建立心跳检测机制的信息；所述MON接收目标OSD进程在与伙伴节点上的OSD进行建立心跳检测机制后上报的伙伴关系建立成功消息，记录所述目标OSD进程所在节点的伙伴节点信息。

进一步地，所述方法还包括：在标记目标OSD进程故障后，所述MON将所述目标OSD进程的故障检测队列中的OSD故障消息清空。

图2为本公开一实施例提供的一种OSD故障心跳检测装置结构示意图，该装置200中的各功能模块可以采用软件、硬件或软硬件相结合的方式实现。当多个硬件设备共同实施本公开的技术方案时，由于各硬件设备之间相互协作的目的是共同实现本发明目的，一方的动作和处理结果确定了另一方的动作执行的时机及可能获得的结果，因此，可视为各执行主体之间具有相互协作关系，各执行主体之间具有相互指挥和控制关系。该装置200应用于分布式存储集群中的监视器MON中，所述装置200包括：

消息接收模块201，用于接收对象存储设备OSD进程基于心跳检测机制上报的OSD故障消息，所述OSD故障消息中携带上报者OSD进程所在节点的标识、目标OSD进程所在节点的标识；

入队列模块202，用于将接收到的OSD故障消息存入目标OSD进程的故障检测队列；

统计模块203，用于统计目标OSD进程的故障检测队列中不重复的上报者OSD进程所在节点总数N；以及获取目标OSD进程所在节点的伙伴节点的总数M；

故障判断模块204，用于根据故障检测队列中的OSD故障消息，判断目标OSD进程是否满足故障确认条件；所述故障确认条件为：不重复的上报者OSD进程所在节点总数N超过目标OSD进程所在节点的伙伴节点的总数M的一半；所述伙伴节点是指节点上的OSD进程之间建立心跳检测机制的节点；

故障标记模块205，用于当判定目标OSD进程满足故障确认条件时，标记所述目标OSD进程为故障状态。

进一步地，所述OSD故障消息中还携带故障产生时间，所述装置200还包括：

消息老化模块，用于周期性扫描每个OSD进程的故障检测队列中的OSD故障消息，判断OSD故障消息中的故障产生时间是否超过预设的老化时间，若超过预设的老化时间，则从故障检测队列中删除该OSD故障消息。

进一步地，所述统计模块203从所述MON自身所维护的集群映射关系中获得目标OSD进程所在节点的伙伴节点总数M，所述集群映射关系中包括OSD进程之间是否建立心跳检测机制的信息；所述消息接收模块还用于接收目标OSD进程在与伙伴节点上的OSD进行建立心跳检测机制后上报的伙伴关系建立成功消息，记录所述目标OSD进程所在节点的伙伴节点信息。

进一步地，所述装置200还包括：

清理模块，用于在标记目标OSD进程故障后，将所述目标OSD进程的故障检测队列中的OSD故障消息清空。

本公开技术方案中，MON为每个OSD进程建立故障检测队列，基于故障检测队列中的OSD故障消息统计被报故障的目标OSD进程是否满足故障确认条件，当不重复的上报者OSD进程所在节点总数超过目标OSD进程所在节点的伙伴节点的总数的一半时，MON才将目标OSD标记为故障状态，从而OSD故障漏报问题。

附图说明

为了更加清楚地说明本公开实施例或者现有技术中的技术方案，下面将对本公开实施例或者现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据本公开实施例的这些附图获得其他的附图。

图1为本公开提供的一种OSD故障心跳检测方法的步骤流程图；

图2为本公开一实施例提供的一种装置结构示意图；

图3为本公开一实施例提供的OSD故障心跳检测方法的步骤流程图；

图4为本公开一实施例中OSD故障心跳检测场景示意图；

图5为本公开一实施例中OSD进程上报OSD故障消息的时序逻辑示意图；

图6为本公开一实施例提供的一种电子设备结构示意图。

具体实施方式

在本公开实施例使用的术语仅仅是出于描述特定实施例的目的，而非限制本公开实施例。本公开实施例中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其它含义。本公开中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，此外，所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

发明人经分析发现，在心跳报Down的机制下，监视器(Monitor，简称MON)标记某个OSD进程故障(包括设备硬软件故障、链路故障等情况，另可概括称为DOWN)的前提为：报该OSD进程故障的节点数量超过集群中节点总数的一半。当集群规模很大，节点数较多，OSD建立心跳范围可能不会覆盖到所有节点。比如：集群中有15个OSD节点，OSD.1只与其中7个节点上的OSD建立心跳连接，即使7个节点全部报OSD.1故障，也不会满足超过半数节点报故障的条件，那么就会出现OSD.1始终不会被心跳报Down。

另外，单点故障上报信息未被及时清理，产生累积效应，后续再出现其他节点单点故障时可能会导致满足报Down条件，从而使得监视器将对应的OSD误报Down。比如说，集群中有3个OSD节点，节点1出现网络震荡，节点1上的OSD.1和节点2上的OSD.2网络不通，节点1报OSD.2故障，此时由于报OSD.2故障节点数不足半数，OSD.2不会被标记为DOWN。后续节点1故障恢复，又出现了节点3网络震荡，此时节点3上的OSD.3与节点2上的OSD.2网络不通，OSD.3报OSD.2故障，那么此时就满足了报OSD.2故障的节点数超过半数节点的条件，将OSD.2标记为DOWN。

为解决上述问题，本公开提出了一种新的OSD故障心跳检测方法，该方法对OSD心跳报Down机制进行了改进，在统计报Down的节点数量时，将与故障的OSD具有伙伴关系的节点数量作为判断基础，当报Down的节点数量超过与故障OSD具有伙伴关系的节点总数的一半时，监视器才将故障OSD报Down，从而避免在大集群中漏报情况的发生。此外，通过增加定时清理线程，清理超时报Down信息，从而避免报Down信息累积出现误报的情况发生。

图3为本公开一实施例提供的OSD故障心跳检测方法的步骤流程图，该方法应用于分布式存储集群中的监视器MON，所述分布式存储集群包括监视器、多个部署OSD的物理节点设备(简称节点)。

本公开实施例中，建立心跳检测关系(简称为伙伴关系)的两个OSD守护进程之间会周期性发送心跳检测报文，当一方在预设时间范围内未检测到对方的应答或接收到对方的心跳检测报文，则OSD守护进程会向MON上报OSD故障消息，OSD故障消息中会携带上报故障的OSD守护进程所在节点的标识、被报故障的OSD守护进程所在节点的标识、故障产生时间等信息。

本公开实施例中，一个物理节点设备上可根据实际需要，部署一个OSD守护进程，也可以部署多个OSD守护进程，因此，位于同一节点的OSD守护进程所在节点的标识相同。

图4为本公开一实施例中OSD故障心跳检测场景示意图，该应用场景中，存储集群包括4个部署OSD守护进程的节点和一个监视器MON节点，4个部署OSD守护进程的节点分别为节点1、节点2、节点3和节点4。

节点1分别与节点2、节点3和节点4通过心跳检测机制建立有伙伴关系，节点1上部署有两个OSD守护进程，分别为OSD.11和OSD.12。节点1与节点2、节点3和节点4互为伙伴节点，本公开所述伙伴节点是指与目标OSD进程建立心跳检测机制具有伙伴关系的节点。

节点3分别与节点1、节点2和节点4通过心跳检测机制建立有伙伴关系；节点3上部署有一个OSD守护进程OSD.3。同理，节点3与节点1、节点2和节点4互为伙伴节点。

节点2分别与节点1和节点3通过心跳检测机制建立有伙伴关系；节点2上部署有一个OSD守护进程OSD.2。同理，节点2分别与节点1和节点3互为伙伴节点。

节点4分别与节点1和节点3通过心跳检测机制建立有伙伴关系。节点4上部署有一个OSD守护进程OSD.4。同理，节点4分别与节点1和节点3互为伙伴节点。

从图可知，该集群总共有4个部署OSD的节点，但节点2和节点4上的OSD守护进程只与节点1和节点3上的OSD守护进程通过心跳检测机制建立了伙伴关系。

MON与所有OSD守护进行连接，可接收到所有OSD守护进程发送的OSD故障消息。

基于图4的应用场景，图3示例了该场景下OSD故障心跳检测方法的步骤流程图，该方法包括：

步骤301.MON分别接收到OSD.11,OSD.12和OSD.3上报的OSD故障消息，OSD.11和OSD.12发送的OSD故障消息中携带节点1的标识；OSD.3发送的OSD故障消息中携带节点3的标识；

当节点2出现故障时，节点2将无法响应节点1与节点3向其发送的心跳检测报文，因此OSD.11,OSD.12和OSD.3作为上报者OSD进程会因节点2长时间未响应心跳报文向监视器MON上报OSD故障消息，由于OSD.11和OSD.12都位于节点1，因此OSD.11和OSD.12发送的OSD故障消息中都携带节点1的节点标识，OSD.3发送的OSD故障消息中携带节点3的标识。

OSD.11,OSD.12和OSD.3发送的OSD故障消息所指向的目标OSD进程为OSD.2，因此OSD故障消息中携带的目标OSD进程所在节点的标识为节点2的标识。

节点4上的OSD.4由于未与节点2上的OSD.2建立伙伴关系，因此OSD.4不会向MON上报有关OSD.2的OSD故障消息。

步骤302.MON将所有关于OSD.2的OSD故障消息都输入到OSD.2的故障检测队列中；

本公开中，MON为每个OSD进程建立一个独立的故障检测队列，用于存储以该OSD进程为目标OSD进程的OSD故障消息。

OSD故障消息中可包括上报者OSD进程标识和目标OSD进行标识，MON根据OSD故障消息中OSD进行标识将所接收到的OSD故障消息入相应的故障检测队列，由于OSD.11,OSD.12和OSD.3发送的OSD故障消息所针对的目标OSD进程都为OSD.2，因此将这些故障消息都压入到OSD.2的故障检测队列。

步骤303.统计OSD.2的故障检测队列中不重复的上报者OSD进程所在节点总数N；获取目标OSD进程所在节点的伙伴节点总数M；

在OSD.2的故障检测队列中仅包含OSD.11,OSD.12和OSD.3发送的OSD故障消息的情况下，由于OSD.11和OSD.12都位于节点1，OSD.3位于节点3，因此根据OSD.2的故障检测队列中OSD故障检测消息统计的上报者OSD进程所在节点总数N＝2。

本公开一实施例中，目标OSD进程所在节点的伙伴节点总数M由MON基于自身所维护的集群映射(MAP)关系获得。集群映射关系中包括OSD进程之间是否建立心跳检测机制的信息，即MON自身维护有OSD进程之间是否存在伙伴关系的信息。目标OSD进程在与伙伴节点上的OSD进行建立心跳检测机制后，向MON上报伙伴关系建立成功消息，MON记录所述目标OSD进程所在节点的伙伴节点信息，在需要获取目标OSD进程所在节点的伙伴节点总数M时，直接以目标OSD进程标识为条件检索统计其伙伴节点个数即可得到M。

基于图4的应用场景，由于节点1、节点2和节点3互为伙伴节点，因此可得到OSD.2所在节点2的伙伴节点总数为2，即M＝2。注意，由于节点4与OSD.2所在节点2未建立心跳检测机制，因此不包括在内。图4应用场景中，集群OSD节点总数S＝4，因此M不等于S。

步骤304.判断OSD.2是否满足故障确认条件即是否满足N>M/2，若判断为满足则执行步骤305，否则执行步骤306；所述故障确认条件为：不重复的上报者OSD进程所在节点总数超过目标OSD进程所在节点的伙伴节点总数M的一半。

MON可在每次将OSD故障消息压入目标OSD进程的故障检测队列后进行故障检测，判断队列中的消息是否满足故障确认条件；也可由故障检测队列对象自己监控压入队列的消息是否满足故障确认条件，当满足故障确认条件时，通过事件触发向MON上报OSD故障处理请求。

本公开中的故障确认条件为：不重复的上报者OSD进程所在节点总数超过目标OSD进程所在节点的伙伴节点总数的一半。

基于图4的应用场景，在OSD.2的故障检测队列中仅包含OSD.11,OSD.12和OSD.3发送的OSD故障消息的情况下，上报者OSD进程所在节点总数N＝2，OSD.2的伙伴节点总数M＝3，集群OSD节点总数S＝4，N>M/2的条件成立，但N>S/2的条件不成立，根据本公开中故障确认条件的定义，可判断OSD.2满足故障确认条件，因此可将OSD.2标记为故障状态。可见，如果以不重复的上报者OSD进程所在节点总数超过集群中OSD节点总数S的一半为判断OSD进程是否故障的条件，将造成故障漏报。

步骤305.MON确认目标OSD进程故障，标记OSD.2为故障状态；

在标记目标OSD进程故障后，MON可将目标OSD进程的故障检测队列中的OSD故障消息清空，未下一轮检测做好准备。

步骤306.MON继续接收OSD故障消息，在接收到关于OSD.2的OSD故障消息时，执行步骤302。

图3的步骤流程是针对目标OSD进程为OSD.2的OSD故障心跳检测方法的步骤流程，针对其他OSD进程的处理逻辑类似，本公开不做赘述。

图5为本公开一实施例中OSD进程上报OSD故障消息的时序逻辑示意图，在该实施例中，为了消除多次单点故障累积效应产生的故障误报，增加了OSD故障消息老化清理机制。以下结合图5说明老化清理机制的实现原理。

假设在t0时刻前，OSD.B刚刚给OSD.C进程发送了心跳检测报文，在t0时刻前，OSD.C还未产生故障2。在t0时刻，OSD.A刚给OSD.C发送心跳检测报文后，就检测出OSD.C网络故障，立刻向MON上报OSD.C故障消息。

通常，OSD心跳检测报文的发送周期为0.5～5.9s，等待心跳回复的时间为20s，因此，假设OSD.B与OSD.C之间也建立有心跳检测机制，则OSD.B接收到OSD.C发送的心跳响应报文的最长响应时间通常不会超过20s+5.9s，取整为26s。

基于以上分析，该实施例中，MON可启动一个扫描线程，周期性(例如5s)扫描每个OSD进程的故障检测队列中的OSD故障消息，判断OSD故障消息中的故障产生时间是否超过预设的老化时间，若超过预设的老化时间，则从故障检测队列中删除该OSD故障消息。通过此方法可消除OSD故障消息的累积效应，避免导致MON误将OSD标记为故障状态的问题产生。其中，为了保险起见，可将老化时间设置为最长响应时间的n倍，n可取大于1的整数，例如取n＝3时，老化时间为：(20+6)*3＝78s。

图6为本公开一实施例提供的一种电子设备结构示意图，该设备600包括：诸如中央处理单元(CPU)的处理器610、通信总线620以及存储介质630。其中，处理器610与存储介质630可以通过通信总线620相互通信。存储介质630内存储有计算机程序，当该计算机程序被处理器610执行时即可实现本公开提供的方法的各步骤的功能。

其中，存储介质可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。另外，存储介质还可以是至少一个位于远离前述处理器的存储装置。处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(ApplicationSpecific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable GateArray，FPGA)或其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

应当认识到，本公开的实施例可以由计算机硬件、硬件和软件的组合、或者通过存储在非暂时性存储器中的计算机指令来实现或实施。所述方法可以使用标准编程技术，包括配置有计算机程序的非暂时性存储介质在计算机程序中实现，其中如此配置的存储介质使得计算机以特定和预定义的方式操作。每个程序可以以高级过程或面向对象的编程语言来实现以与计算机系统通信。然而，若需要，该程序可以以汇编或机器语言实现。在任何情况下，该语言可以是编译或解释的语言。此外，为此目的该程序能够在编程的专用集成电路上运行。此外，可按任何合适的顺序来执行本公开描述的过程的操作，除非本公开另外指示或以其他方式明显地与上下文矛盾。本公开描述的

过程(或变型和/或其组合)可在配置有可执行指令的一个或多个计算机系统的5控制下执行，并且可作为共同地在一个或多个处理器上执行的代码(例如，可执行指令、一个或多个计算机程序或一个或多个应用)、由硬件或其组合来实现。所述计算机程序包括可由一个或多个处理器执行的多个指令。

进一步，所述方法可以在可操作地连接至合适的任何类型的计算平台中实现，包括但不限于个人电脑、迷你计算机、主框架、工作站、网络或分布0式计算环境、单独的或集成的计算机平台、或者与带电粒子工具或其它成像装置通信等等。本公开的各方面可以以存储在非暂时性存储介质或设备上的机器可读代码来实现，无论是可移动的还是集成至计算平台，如硬盘、光学读取和/或写入存储介质、RAM、ROM等，使得其可由可编程计算机读取，

当存储介质或设备由计算机读取时可用于配置和操作计算机以执行在此所描5述的过程。此外，机器可读代码，或其部分可以通过有线或无线网络传输。

当此类媒体包括结合微处理器或其他数据处理器实现上文所述步骤的指令或程序时，本公开所述的发明包括这些和其他不同类型的非暂时性计算机可读存储介质。当根据本公开所述的方法和技术编程时，本公开还包括计算机本身。

0以上所述仅为本公开的实施例而已，并不用于限制本公开。对于本领域技术人员来说，本公开可以有各种更改和变化。凡在本公开的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (10)

1.一种OSD故障心跳检测方法，其特征在于，该方法应用于分布式存储集群中的监视器MON，所述方法包括：

监视器MON接收对象存储设备OSD进程基于心跳检测机制上报的OSD故障消息，所述OSD故障消息中携带上报者OSD进程所在节点的标识、目标OSD进程所在节点的标识；

MON将接收到的OSD故障消息存入目标OSD进程的故障检测队列；

统计目标OSD进程的故障检测队列中不重复的上报者OSD进程所在节点总数N；

根据故障检测队列中的OSD故障消息，判断目标OSD进程是否满足故障确认条件；所述故障确认条件为：不重复的上报者OSD进程所在节点总数N超过目标OSD进程所在节点的伙伴节点的总数M的一半；所述伙伴节点是指节点上的OSD进程之间建立心跳检测机制的节点；

当判定目标OSD进程满足故障确认条件时，MON标记所述目标OSD进程为故障状态。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述OSD故障消息中还携带故障产生时间；

MON周期性扫描每个OSD进程的故障检测队列中的OSD故障消息，判断OSD故障消息中的故障产生时间是否超过预设的老化时间，若超过预设的老化时间，则从故障检测队列中删除该OSD故障消息。

3.根据权利要求1所述的方法，其特征在于，

目标OSD进程所在节点的伙伴节点总数M由MON基于自身所维护的集群映射关系中获得，集群映射关系中包括OSD进程之间是否建立心跳检测机制的信息；

所述MON接收目标OSD进程在与伙伴节点上的OSD进行建立心跳检测机制后上报的伙伴关系建立成功消息，记录所述目标OSD进程所在节点的伙伴节点信息。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在标记目标OSD进程故障后，所述MON将所述目标OSD进程的故障检测队列中的OSD故障消息清空。

5.一种OSD故障心跳检测装置，其特征在于，该装置应用于分布式存储集群中的监视器MON中，所述装置包括：

消息接收模块，用于接收对象存储设备OSD进程基于心跳检测机制上报的OSD故障消息，所述OSD故障消息中携带上报者OSD进程所在节点的标识、目标OSD进程所在节点的标识；

入队列模块，用于将接收到的OSD故障消息存入目标OSD进程的故障检测队列；

统计模块，用于统计目标OSD进程的故障检测队列中不重复的上报者OSD进程所在节点总数N；以及获取目标OSD进程所在节点的伙伴节点的总数M；

故障判断模块，用于根据故障检测队列中的OSD故障消息，判断目标OSD进程是否满足故障确认条件；所述故障确认条件为：不重复的上报者OSD进程所在节点总数N超过目标OSD进程所在节点的伙伴节点的总数M的一半；所述伙伴节点是指节点上的OSD进程之间建立心跳检测机制的节点；

故障标记模块，用于当判定目标OSD进程满足故障确认条件时，标记所述目标OSD进程为故障状态。

6.根据权利要求5所述的装置，其特征在于，所述OSD故障消息中还携带故障产生时间，所述装置还包括：

消息老化模块，用于周期性扫描每个OSD进程的故障检测队列中的OSD故障消息，判断OSD故障消息中的故障产生时间是否超过预设的老化时间，若超过预设的老化时间，则从故障检测队列中删除该OSD故障消息。

7.根据权利要求5所述的装置，其特征在于，

所述统计模块从所述MON自身所维护的集群映射关系中获得目标OSD进程所在节点的伙伴节点总数M，所述集群映射关系中包括OSD进程之间是否建立心跳检测机制的信息；

所述消息接收模块还用于接收目标OSD进程在与伙伴节点上的OSD进行建立心跳检测机制后上报的伙伴关系建立成功消息，记录所述目标OSD进程所在节点的伙伴节点信息。

8.根据权利要求5所述的装置，其特征在于，所述装置还包括：

清理模块，用于在标记目标OSD进程故障后，将所述目标OSD进程的故障检测队列中的OSD故障消息清空。

9.一种电子设备，其特征在于，包括处理器、通信接口、存储介质和通信总线，其中，处理器、通信接口、存储介质通过通信总线完成相互间的通信；

存储介质，用于存放计算机程序；

处理器，用于执行存储介质上所存放的计算机程序时，实施权利要求1至4任一项所述的方法步骤。

10.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序当被处理器执行时实施如权利要求1至4中任一项所述的方法步骤。

Images