CN111064613B - 一种网络故障检测方法及装置 - Google Patents
一种网络故障检测方法及装置 Download PDFInfo
- Publication number
- CN111064613B CN111064613B CN201911286017.7A CN201911286017A CN111064613B CN 111064613 B CN111064613 B CN 111064613B CN 201911286017 A CN201911286017 A CN 201911286017A CN 111064613 B CN111064613 B CN 111064613B
- Authority
- CN
- China
- Prior art keywords
- link
- message
- tested
- delay
- service 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0852—Delays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请实施例提供了一种网络故障检测方法及装置,应用于业务集群内第一业务节点中的第一设备,包括:针对各待测链路计算表征统计周期内通过该待测链路所发送消息的消息时延作为链路时延,待测链路为与第一业务节点不同的待测业务节点中各个第二设备与第一设备间的链路,消息时延为向第二设备发送消息至接收到第二设备反馈响应间的时延;针对每一第二设备根据一端为该第二设备的待测链路的链路时延,计算表征统计周期内向该第二设备所发送消息的消息时延作为综合消息时延;根据待测业务节点中综合消息时延超过预设时延的第二设备的数量,检测待测业务节点是否存在网络故障。应用本申请实施例提供的方案能提高对业务节点进行网络故障检测的准确度。
Description
技术领域
本申请涉及网络技术领域,特别是涉及一种网络故障检测方法及装置。
背景技术
随着用户量增加、用户需求增长,通常基于包含多个业务节点的业务集群向用户提供业务。例如,上述业务集群可以是用于提供存储业务的存储集群等。其中,上述业务节点中可以包含多个用于提供业务的设备。
然而受网络超时、网络连接闪断、网络状态震荡、数据丢包等因素的影响,上述业务集群可能会工作在亚健康的网络环境下,导致业务集群内各个业务节点出现网络故障,工作状态不稳定,例如,出现业务节点所提供的业务震荡、业务归零、业务节点内设备频繁报错等现象。严重的情况下,甚至可能会导致业务集群长时间不可用。为此需要对业务集群中各个业务节点进行网络故障检测。
以上述业务集群为基于Ceph存储架构的存储集群为例,上述业务节点为存储节点。每一存储节点中同一PG(Placement Groups,放置组)内的OSD(Object Store Device,对象存储设备)通过互发心跳包的方式检测对端OSD是否存在网络故障。假设,OSD1向OSD2发送Ping心跳包后,若20秒内没有接收到OSD2反馈的心跳回复,则认为OSD2存在网络故障。但是这种情况下,OSD1仅仅认为OSD2这单一一个OSD存在网络故障,不会认为整个业务节点存在网络故障,后续进行OSD隔离时,也仅仅隔离OSD2这一个OSD。所以,站在检测存储节点是否存在网络故障的角度来讲,应用上述方式进行网络故障检测准确率低。
另外,这种情况下,OSD2所属的存储节点中还可能存在其他有网络故障的OSD,但是上述存储节点依然正常提供存储业务,可能会导致整个存储集群存在业务震荡,难以保证存储集群提供连续的存储业务。
发明内容
本申请实施例的目的在于提供一种网络故障检测方法及装置,以提高对业务节点进行网络故障检测的准确度。具体技术方案如下:
第一方面,本申请实施例提供了一种网络故障检测方法,应用于业务集群内第一业务节点中的第一设备,所述方法包括:
针对每一待测链路,计算表征统计周期内通过该待测链路所发送消息的消息时延,作为该待测链路的链路时延,其中,所述待测链路为:与所述第一业务节点不同的待测业务节点中各个第二设备与所述第一设备间的链路,所述消息时延为:向第二设备发送消息至接收到第二设备反馈响应间的时延;
针对每一第二设备,根据一端为该第二设备的待测链路的链路时延,计算表征所述统计周期内向该第二设备所发送消息的消息时延,作为该第二设备的综合消息时延;
根据所述待测业务节点中综合消息时延超过预设时延的第二设备的数量,检测所述待测业务节点是否存在网络故障。
本申请的一个实施例中,所述针对每一待测链路,计算表征统计周期内通过该待测链路所发送消息的消息时延,作为该待测链路的链路时延,包括:
针对每一待测链路,获得统计周期内通过该待测链路发送的每一消息的消息时延,计算所获得消息时延的平均值,作为该待测链路的链路时延。
本申请的一个实施例中,所述每一消息的消息时延为:T2-T1-ΔT;
其中,T1表示向第二设备发送消息的时间戳,T2表示接收到第二设备反馈响应的时间戳,ΔT表示第二设备接收到消息与第二设备生成响应之间的时间差。
本申请的一个实施例中,所述针对每一第二设备,根据一端为该第二设备的待测链路的链路时延,计算表征所述统计周期内向该第二设备所发送消息的消息时延,作为该第二设备的综合消息时延,包括:
针对每一第二设备,计算一端为该第二设备的各待测链路的链路时延的平均值,作为该第二设备的综合消息时延。
本申请的一个实施例中,所述根据所述待测业务节点中综合消息时延超过预设时延的第二设备的数量,检测所述待测业务节点是否存在网络故障,包括:
判断连续预设数量个统计周期内异常设备的数量与所述待测业务节点中第二设备的总数间的比值是否大于预设阈值,所述异常设备为:所述待测业务节点中综合消息时延超过预设时延的第二设备;
若为是,确定所述待测业务节点存在网络故障。
本申请的一个实施例中,所述网络故障检测方法还包括:
在确定所述待测业务节点存在网络故障后,向业务集群的监控进程发送网络故障通知,以使得所述监控进程对所述待测业务节点中的所有第二设备进行业务隔离。
第二方面,本申请实施例提供了一种网络故障检测装置,应用于业务集群内第一业务节点中的第一设备,所述装置包括:
链路时延计算模块,用于针对每一待测链路,计算表征统计周期内通过该待测链路所发送消息的消息时延,作为该待测链路的链路时延,其中,所述待测链路为:与所述第一业务节点不同的待测业务节点中各个第二设备与所述第一设备间的链路,所述消息时延为:向第二设备发送消息至接收到第二设备反馈响应间的时延;
综合时延计算模块,用于针对每一第二设备,根据一端为该第二设备的待测链路的链路时延,计算表征所述统计周期内向该第二设备所发送消息的消息时延,作为该第二设备的综合消息时延;
网络故障检测模块,用于根据所述待测业务节点中综合消息时延超过预设时延的第二设备的数量,检测所述待测业务节点是否存在网络故障。
本申请的一个实施例中,所述链路时延计算模块,具体用于针对每一待测链路,获得统计周期内通过该待测链路发送的每一消息的消息时延,计算所获得消息时延的平均值,作为该待测链路的链路时延。
本申请的一个实施例中,所述每一消息的消息时延为:T2-T1-ΔT;
其中,T1表示向第二设备发送消息的时间戳,T2表示接收到第二设备反馈响应的时间戳,ΔT表示第二设备接收到消息与第二设备生成响应之间的时间差。
本申请的一个实施例中,所述综合时延计算模块,具体用于针对每一第二设备,计算一端为该第二设备的各待测链路的链路时延的平均值,作为该第二设备的综合消息时延。
本申请的一个实施例中,所述网络故障检测模块,具体用于:
判断连续预设数量个统计周期内异常设备的数量与所述待测业务节点中第二设备的总数间的比值是否大于预设阈值,所述异常设备为:所述待测业务节点中综合消息时延超过预设时延的第二设备;
若为是,确定所述待测业务节点存在网络故障。
本申请的一个实施例中,所述网络故障检测装置还包括:
通知发送模块,用于在确定所述待测业务节点存在网络故障后,向业务集群的监控进程发送网络故障通知,以使得所述监控进程对所述待测业务节点中的所有第二设备进行业务隔离。
第三方面,本申请实施例提供了一种电子设备,所述电子设备为业务集群内第一业务节点中的第一设备,所述电子设备包括:处理器和机器可读存储介质,所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令,所述处理器被所述机器可执行指令促使:实现上述第一方面所述的方法步骤。
第四方面,本申请实施例提供了一种机器可读存储介质,存储有机器可执行指令,在被处理器调用和执行时,所述机器可执行指令促使所述处理器:实现上述第一方面所述的方法步骤。
由以上可见,应用本申请实施例提供的方案进行网络故障检测时,计算出每一待测链路的链路时延后,根据计算得到的链路时延,计算每一第二设备的综合消息时延,然后根据待测业务节点中综合消息时延超过预设时延的第二设备的数量,检测待测业务节点是否存在网络故障。也就是说,应用本申请实施例提供的方案检测待测业务节点的网络故障时,综合考虑了待测业务节点中综合消息时延较高的第二设备的数量。当较多的第二设备存在综合消息时延较高的情况时,说明整个待测业务节点的网络状态欠佳,待测业务节点存在网络故障的概率较高,反之,当较少的第二设备存在综合消息时延较高的情况时,不足于说明整个待测业务节点的网络状态欠佳,待测业务节点存在网络故障的概率较低。相比于现有技术而言,应用本申请实施例提供的方案检测待测业务节点是否存在网络故障时,不是仅从待测节点内的单个设备着手检测,而是从待测节点内的所有设备着手检测,因此,应用本申请实施例提供的方案进行网络故障检测,能够提高检测准确度。
另外,由于应用本申请实施例提供的方案能够检测出整个业务节点是否存在网络故障,所以一旦业务节点出现网络故障,后续可以对整个业务节点中的设备进行隔离,从而使得整个业务节点不对外提供业务,这样可以减少存在网络故障的业务节点给整个业务集群带来的业务震荡,从而能够保证业务集群能够提供连续的业务。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1a为本申请实施例提供的第一种网络故障检测方法的流程示意图;
图1b为本申请实施例提供的一种网络结构示意图;
图2为本申请实施例提供的一种设备交互示意图;
图3为本申请实施例提供的另一种网络故障检测方法的流程示意图;
图4为本申请实施例提供的一种网络故障检测装置的结构示意图;
图5为本申请实施例提供的另一种网络故障检测装置的结构示意图;
图6为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。另外,以下所描述的实施例仅用于说明和解释本申请实施例提供的技术方案,并不用于限定本申请。并且在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
由于应用现在有技术对业务节点进行网络故障检测时,存在准确度低的技术问题,为解决这一技术问题,本申请实施例提供了一种网络故障检测方法及装置。
本申请的一个实施例中,提供了一种网络故障检测方法,应用于业务集群内第一业务节点中的第一设备,所述方法包括:
针对每一待测链路,计算表征统计周期内通过该待测链路所发送消息的消息时延,作为该待测链路的链路时延,其中,待测链路为:与第一业务节点不同的待测业务节点中各个第二设备与第一设备间的链路,消息时延为:向第二设备发送消息至接收到第二设备反馈响应间的时延;
针对每一第二设备,根据一端为该第二设备的链路的链路时延,计算表征统计周期内向该第二设备所发送消息的消息时延,作为该第二设备的综合消息时延;
根据待测业务节点中综合消息时延超过预设时延的第二设备的数量,检测待测业务节点是否存在网络故障。
由以上可见,应用本实施例提供的方案检测待测业务节点的网络故障时,综合考虑了待测业务节点中综合消息时延较高的第二设备的数量。当较多的第二设备存在综合消息时延较高的情况时,说明整个待测业务节点的网络状态欠佳,待测业务节点存在网络故障的概率较高,反之,当较少的第二设备存在综合消息时延较高的情况时,不足于说明整个待测业务节点的网络状态欠佳,待测业务节点存在网络故障的概率较低。相比于现有技术而言,应用本实施例提供的方案检测待测业务节点是否存在网络故障时,不是仅从待测节点内的单个设备着手检测,而是从待测节点内的所有设备着手检测,因此,应用本实施例提供的方案进行网络故障检测,能够提高检测准确度。
下面通过具体实施例对本申请实施例提供的网络故障检测方法及装置进行详细说明。
参见图1a,图1a提供了一种网络故障检测方法的流程示意图,该方法应用于业务集群内第一业务节点中的第一设备。
其中,上述业务集群可以是用于向用户提供各种业务的集群。例如,上述业务可以是存储业务、数据处理业务等等。
以上述业务为存储业务为例,这种情况下上述业务集群为存储集群,业务节点中的设备可以是OSD。
另外,上述第一业务节点可以是业务集群中的任一业务节点。具体的,业务集群中的各个业务节点可以是对业务架构进行划分得到的节点。
对于每一业务节点而言,业务节点中可以存在多个设备。
上述第一设备可以是上述第一业务节点中的任一设备。也就是说,上述第一业务节点中可以存在多个设备,上述第一设备仅仅是这多个设备中的一个,而且上述多个设备中的每一设备均可以作为第一设备,执行本申请实施例提供的方案。
具体的,上述网络故障检测方法包括以下步骤S101-S103。
S101:针对每一待测链路,计算表征统计周期内通过该待测链路所发送消息的消息时延,作为该待测链路的链路时延。
其中,上述待测链路为:与第一业务节点不同的待测业务节点中各个第二设备与第一设备间的链路。
上述业务集群中可以包括多个业务节点,上述待测业务节点可以是业务集群中任一一个与第一业务节点不同的业务节点。
待测业务节点中可以存在多个第二设备。对于每一第二设备而言,第二设备与第一设备之间可以存在多条链路。另外,每一第二设备与第一设备之间均可能存在多条链路。综合上述情况,上述待测链路的数量大于等于1。
上述消息时延为:向第二设备发送消息至接收到第二设备反馈响应间的时延。
上述统计周期的时长可以是预先设定的。例如,上述时长可以是2秒、3秒等。
由于上述统计周期对应于一定的时长,因此,对于每一待测链路而言,上述第一设备可能会通过该待测链路向第二设备发送一个消息,也可能发送多个消息。又由于第一设备通过一条待测链路向第二设备发送一个消息时,这一消息对应的消息时延具有个性化,也就是,上述消息时延仅仅反映通过上述待测链路发送上述消息时的消息时延。而对于一条待测链路而言,该待测链路的网络状态在一定时长内是基本稳定的,所以,本实施例中,计算表征统计周期内通过每一条待测链路所发送消息的消息时延,作为每一条待测链路的链路时延。这样每一待测链路的链路时延反映了一个统计周期内这一待测链路的网络状态。
具体的,当一条待测链路的链路时延较高时,可以认为该待测链路在一个统计周期内网络状态较差。反之,当一条待测链路的链路时延较低时,可以认为该待测链路在一个统计周期内网络状态较佳。
计算每一待测链路的链路时延的方式可以参见后续实施例,这里暂不详述。
S102:针对每一第二设备,根据一端为该第二设备的待测链路的链路时延,计算表征上述统计周期内向该第二设备所发送消息的消息时延,作为该第二设备的综合消息时延。
由于每一第二设备与第一设备之间可能会存在多条待测链路,而同一统计周期内每一待测链路的网络状态又可能不同,每一待测链路的网络状态又与第二设备的网络状态相关,所以,可以对该第二设备与第一设备间的待测链路的链路时延进行分析,得到表征统计周期内第一设备向第二设备所发送消息的消息时延,为便于表述,本申请实施例中将得到的上述消息时延称为该第二设备的综合消息时延。这样每一第二设备的综合消息时延反映了一个统计周期内第二设备的网络状态。
具体的,当一个第二设备的综合消息时延较高时,可以认为该第二设备在一个统计周期内网络状态较差。反之,当一个第二设备的综合消息时延较低时,可以认为该第二设备在一个统计周期内网络状态较佳。
本申请的一个实施例中,针对每一第二设备,可以计算一端为该第二设备的各待测链路的链路时延的平均值,作为该第二设备的综合消息时延。
参见图1b,图1b中第一业务节点包括M1和M2共计两个设备,待测业务节点中包括D1、D2和D3共计三个第二设备。下面以M2作为上述第一设备为例进行说明。
在图1b中各个第二设备与M2之间的待测链路以各条直线表示。各个第二设备与M2之间的待测链路以及每一待测链路的链路时延如下所示。
D1与M2间的待测链路包括:L11、L12和L13,这三条待测链路的链路时延分别为t11、t12和t13;
D2与M2间的待测链路包括:L21、L22、L23和L24,这四条待测链路的链路时延分别为t21、t22、t23和t24;
D3与M2间的待测链路包括:L31和L32,这两条待测链路的链路时延分别为t31和t32。
则上述D1的综合消息时延为:(t11+t12+t13)/3,上述D2的综合消息时延为:(t21+t22+t23+t24)/4,上述D3的综合消息时延为:(t31+t32)/2。
本申请的另一个实施例中,针对每一第二设备,还可以将一端为该第二设备的各待测链路的链路时延中的最大值,作为该第二设备的综合消息时延。
当然,还可以从一端为该第二设备的各待测链路的链路时延中选择第一预设数量个最大链路时延,然后计算所选择链路时延的平均值,作为该第二设备的综合消息时延。本申请实施例仅仅以此为例进行说明,综合消息时延的计算方式并不仅限于此。
例如,上述第一预设数量的取值可以根据具体应用场景设定。上述第一预设数量可以是5、6、7等等。
S103:根据待测业务节点中综合消息时延超过预设时延的第二设备的数量,检测待测业务节点是否存在网络故障。
本申请的一个实施例中,可以判断连续预设数量个统计周期内异常设备的数量与待测业务节点中第二设备的总数间的比值是否大于预设阈值,若均大于,确定待测业务节点存在网络故障。
其中,异常设备为:待测业务节点中综合消息时延超过预设时延的第二设备。
具体的,上述预设数量可以为1、2、3、4等。
上述预设阈值可以是50%、60%等。
上述预设时延可以是开发人员按照应用场景的需求、经验等设定的时延。
本申请的另一个实施例中,还可以判断连续预设数量个统计周期内异常设备的数量是否均大于预设数量阈值,若均大于,确定待测业务节点存在网络故障。
在基于连续预设数量个统计周期对待测业务节点进行网络故障检测时,由于上述统计周期一般可以设置较短的时长,且上述预设数量也可以设置的较小,因为,可以在较短的时间内实现针对业务节点的网络故障检测。
例如,上述统计周期的时长为3秒、预设数量为4时,在12秒内即可完成一次针对业务节点的网络故障检测。而现有技术中通过发送心跳包的方式检测网络故障时,一般认为20秒及其以上未收到心跳回复才能判断设备存在网络故障,也就是,20秒及其以上才能完成一次针对设备的网络故障检测。若要完成对业务节点内所有设备的网络故障检测,所需的时间会更长。与此相比,应用本实施例提供的方案进行网络故障检测,能够大大缩短每次对业务节点进行网络故障检测所需要的时间,从而提高网络故障检测的效率。另外,这样能够及时隔离存在网络故障的业务节点内的所有设备,减少存在网络故障的业务节点导致业务集群出现业务震荡的概率。
由以上可见,应用上述各个实施例提供的方案检测待测业务节点的网络故障时,综合考虑了待测业务节点中综合消息时延较高的第二设备的数量。当较多的第二设备存在时延较高的情况时,说明整个待测业务节点的网络状态欠佳,待测业务节点存在网络故障的概率较高,反之,当较少的第二设备存在时延较高的情况时,不足于说明整个待测业务节点的网络状态欠佳,待测业务节点存在网络故障的概率较低。相比于现有技术而言,应用上述各个实施例提供的方案检测待测业务节点是否存在网络故障时,不是仅从待测节点内的单个设备着手检测,而是从待测节点内的所有设备着手检测,因此,应用上述各个实施例提供的方案进行网络故障检测,能够提高检测准确度。
另外,由于应用上述实施例提供的方案能够检测出整个业务节点是否存在网络故障,所以一旦业务节点出现网络故障,后续可以对整个业务节点中的设备进行隔离,从而使得整个业务节点不对外提供业务,这样可以减少存在网络故障的业务节点给整个业务集群带来的业务震荡,从而能够保证业务集群能够提供连续的业务。
鉴于一定时长内,第一设备可能会通过一条待测链路向第二设备发送多个消息,本申请的一个实施例中,针对每一待测链路,可以获得统计周期内通过该待测链路发送的每一消息的消息时延,计算所获得消息时延的平均值,作为该待测链路的链路时延。
本申请的另一个实施例中,针对每一待测链路,还可以获得统计周期内通过该待测链路发送的各个消息的消息时延的最大值,将该最大值确定为该待测链路的链路时延。当然,还可以从通过该待测链路发送的各个消息的消息时延中选择第二预设数量个消息时延,然后计算所选择消息时延的平均值,作为该待测链路的链路时延。本申请实施例仅仅以此为例进行说明,链路时延的计算方式并不仅限于此。
具体的,上述每一消息的消息时延可以借助于第一设备发送该消息的时间戳、第一设备接收到第二设备反馈响应的时间戳等信息确定。
下面以第一设备和第二设备均为OSD为例,结合图2所示的设备交互示意图对第一设备和第二设备进行交互的过程中涉及的各个时间戳进行说明。
图2中OSD1对应于上述第一设备,OSD2对应于上述第二设备。
参见图2,OSD1与OSD2进行交互时,OSD1向OSD2发送消息,将OSD1向OSD2发送消息的时间戳记为T1。
OSD2接收上述消息,将OSD2接收到上述消息的时间戳记为T3。
OSD2接收到上述消息后,对上述消息进行处理,并生成上述消息的响应,将OSD2生成上述响应的时间戳记为T4;
OSD2向OSD1发送上述响应,OSD1接收上述响应,将OSD1接收上述响应的时间戳记为T2。
由以上可见OSD2接收到上述消息后,对上述消息进行处理的时间是OSD1和OSD2交互过程中正常工作的时间,可以不计算在上述消息对应的消息时延之内。
鉴于上述情况,本申请的一个实施例中,上述每一消息的消息时延可以为:T2-T1-ΔT。
其中,T1表示向第二设备发送消息的时间戳,T2表示接收到第二设备反馈响应的时间戳,ΔT表示第二设备接收到消息与第二设备生成响应之间的时间差。
上述ΔT可以携带在第二设备向第一设备反馈的响应中,由第二设备发送至第一设备。
也就是说,对于上述基于图2的举例而言,OSD2向OSD1发送的响应中可以携带T4与T3之间的差值,从而OSD1可以获得上述差值。
本申请的另一个实施例中,上述每一消息的消息时延还可以为T2-T1。
由以上可见,应用上述各个实施例提供的方案,可以快速、高效的计算得到各个待测链路的链路时延。
参见图3,提供了另一种网络故障检测方法的流程示意图,与前述图1所示实施例相比,本实施例中,上述网络故障检测方法还包括下述步骤S104。
S104:在确定待测业务节点存在网络故障后,向业务集群的监控进程发送网络故障通知,以使得监控进程对待测业务节点中的所有第二设备进行业务隔离。
其中,上述监控进程用于对整个业务集群的运行状态进行监控。具体的,上述监控进程可以配置在业务集群包括的部分业务节点上,更进一步的,配置在业务集群内部分业务节点包括的设备中。
例如,假设业务集群包括五个业务节点,则可以在其中三个业务节点上配置监控进程,一个监控进程作为主监控进程,另外两个监控进程作为备监控进程。具体的,上述监控进程配置在上述三个业务节点包括的设备中。
在检测到上述待测业务节点存在网络故障之后,监控进程对待测业务节点中的所有第二设备进行业务隔离,可以使得待测业务节点中的各个第二设备暂时不对外提供业务,从而可以在业务集群中隔离掉工作状态不稳定的业务节点,能够有效防止业务集群出现对外提供业务不稳定的情况。
本申请的一个实施例中,上述第一设备在检测待测业务节点是否存在网络故障的过程中,还可以根据各个第二设备的综合消息时延确定出现网络故障的第二设备,并获得与出现网络故障的第二设备之间连接的源IP地址、目的IP地址、源端口号、目的端口号等。为便于上述监控进程对业务集群中的设备进行管理,上述第一设备可以将上述所获得的信息发送至上述监控进程。
本申请的另一个实施例中,由于上述第一业务节点可以包括多个设备,而每一设备均可以作为上述第一设备,也就是,每一设备均可以检测上述待测业务节点是否存在网络故障。这种情况下,上述监控进程可能会在一定时间内接收到多个反映待测业务节点存在网络故障的消息,一种情况下,监控进程在第一次接收到反映待测业务节点存在网络故障的消息后,可以响应该消息隔离待测业务节点中的所有设备,并拒绝上述一定时间内后续接收到的、反映待测业务节点存在网络故障的消息。
另一种情况下,监控进程还可以统计上述一定时间内接收到的反映待测业务节点存在网络故障的消息的数量,当上述数量大于预设数值时,响应上述消息隔离待测业务节点中的所有设备。
除此之外,上述第一设备还可以向上述监控进程发送各个第二设备的综合消息时延、异常比例等等。其中,上述异常比例为:异常设备的数量与待测业务节点中第二设备的总数间的比例。
本申请的另一个实施例中,上述第一设备还可以将各个第二设备的综合消息时延发送至第一业务节点中的网卡管理进程。上述网卡管理进程可以依据各个第二设备的综合消息时延,检测与上述待测业务节点通信的网口是否存在故障。
与上述网络故障检测方法相对应,本申请实施例还提供了一种网络故障检测装置。
参见图4,本申请实施例提供了一种网络故障检测装置的结构示意图,该装置应用于业务集群内第一业务节点中的第一设备,所述装置包括以下模型401-403。
链路时延计算模块401,用于针对每一待测链路,计算表征统计周期内通过该待测链路所发送消息的消息时延,作为该待测链路的链路时延,其中,所述待测链路为:与所述第一业务节点不同的待测业务节点中各个第二设备与所述第一设备间的链路,所述消息时延为:向第二设备发送消息至接收到第二设备反馈响应间的时延;
综合时延计算模块402,用于针对每一第二设备,根据一端为该第二设备的待测链路的链路时延,计算表征所述统计周期内向该第二设备所发送消息的消息时延,作为该第二设备的综合消息时延;
网络故障检测模块403,用于根据所述待测业务节点中综合消息时延超过预设时延的第二设备的数量,检测所述待测业务节点是否存在网络故障。
本申请的一个实施例中,所述链路时延计算模块401,具体用于针对每一待测链路,获得统计周期内通过该待测链路发送的每一消息的消息时延,计算所获得消息时延的平均值,作为该待测链路的链路时延。
本申请的一个实施例中,所述每一消息的消息时延为:T2-T1-ΔT;
其中,T1表示向第二设备发送消息的时间戳,T2表示接收到第二设备反馈响应的时间戳,ΔT表示第二设备接收到消息与第二设备生成响应之间的时间差。
本申请的一个实施例中,所述综合时延计算模块402,具体用于针对每一第二设备,计算一端为该第二设备的各待测链路的链路时延的平均值,作为该第二设备的综合消息时延。
本申请的一个实施例中,所述网络故障检测模块403,具体用于:
判断连续预设数量个统计周期内异常设备的数量与所述待测业务节点中第二设备的总数间的比值是否大于预设阈值,所述异常设备为:所述待测业务节点中综合消息时延超过预设时延的第二设备;
若为是,确定所述待测业务节点存在网络故障。
由以上可见,应用上述各个实施例提供的方案检测待测业务节点的网络故障时,综合考虑了待测业务节点中综合消息时延较高的第二设备的数量。当较多的第二设备存在综合消息时延较高的情况时,说明整个待测业务节点的网络状态欠佳,待测业务节点存在网络故障的概率较高,反之,当较少的第二设备存在综合消息时延较高的情况时,不足于说明整个待测业务节点的网络状态欠佳,待测业务节点存在网络故障的概率较低。相比于现有技术而言,应用上述各个实施例提供的方案检测待测业务节点是否存在网络故障时,不是仅从待测节点内的单个设备着手检测,而是从待测节点内的所有设备着手检测,因此,应用上述各个实施例提供的方案进行网络故障检测,能够提高检测准确度。
参见图5,提供了另一种网络故障检测装置的结构示意图,与前述图4所示实施例相比,本实施例中,上述网络故障检测装置还包括下述模型404。
通知发送模块404,用于在确定所述待测业务节点存在网络故障后,向业务集群的监控进程发送网络故障通知,以使得所述监控进程对所述待测业务节点中的所有第二设备进行业务隔离。
在检测到上述待测业务节点存在网络故障之后,监控进程对待测业务节点中的所有第二设备进行业务隔离,可以使得待测业务节点中的各个第二设备暂时不对外提供业务,从而可以在业务集群中隔离掉工作状态不稳定的业务节点,能够有效防止业务集群出现对外提供业务不稳定的情况。
与上述网络故障检测方法相对应,本申请实施例还提供了一种电子设备。
参见图6,本申请实施例提供了一种电子设备的结构示意图,该电子设备为业务集群内第一业务节点中的第一设备,该电子设备包括:处理器601和机器可读存储介质602,所述机器可读存储介质602存储有能够被所述处理器601执行的机器可执行指令,所述处理器601被所述机器可执行指令促使:实现本申请实施例提供的网络故障检测方法步骤。
本申请的一个实施例中,提供了一种网络故障检测方法,应用于业务集群内第一业务节点中的第一设备,所述方法包括:
针对每一待测链路,计算表征统计周期内通过该待测链路所发送消息的消息时延,作为该待测链路的链路时延,其中,所述待测链路为:与所述第一业务节点不同的待测业务节点中各个第二设备与所述第一设备间的链路,所述消息时延为:向第二设备发送消息至接收到第二设备反馈响应间的时延;
针对每一第二设备,根据一端为该第二设备的待测链路的链路时延,计算表征所述统计周期内向该第二设备所发送消息的消息时延,作为该第二设备的综合消息时延;
根据所述待测业务节点中综合消息时延超过预设时延的第二设备的数量,检测所述待测业务节点是否存在网络故障。
需要说明的是,上述处理器601被机器可执行指令促使实现的网络故障检测方法的其他实施例,与前述方法实施例部分提及的实施例相同,这里不再赘述。
应用本实施例提供的电子设备检测待测业务节点的网络故障时,综合考虑了待测业务节点中综合消息时延较高的第二设备的数量。当较多的第二设备存在综合消息时延较高的情况时,说明整个待测业务节点的网络状态欠佳,待测业务节点存在网络故障的概率较高,反之,当较少的第二设备存在综合消息时延较高的情况时,不足于说明整个待测业务节点的网络状态欠佳,待测业务节点存在网络故障的概率较低。相比于现有技术而言,应用本实施例提供的电子设备检测待测业务节点是否存在网络故障时,不是仅从待测节点内的单个设备着手检测,而是从待测节点内的所有设备着手检测,因此,应用本申请实施例提供的方案进行网络故障检测,能够提高检测准确度。
与上述网络故障检测方法相对应,本申请实施例还提供了一种机器可读存储介质,存储有机器可执行指令,在被处理器调用和执行时,所述机器可执行指令促使所述处理器:实现本申请实施例提供的网络故障检测方法步骤。
需要说明的是,上述机器可读存储介质可以包括随机存取存储器(Random AccessMemory,RAM),也可以包括非易失性存储器(Non-Volatile Memory,NVM),例如至少一个磁盘存储器。可选的,上述机器可读存储介质还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessing,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置、电子设备和机器可读存储介质实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的较佳实施例而已,并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等,均包含在本申请的保护范围内。
Claims (11)
1.一种网络故障检测方法,其特征在于,应用于业务集群内第一业务节点中的第一设备,所述方法包括:
针对每一待测链路,计算表征统计周期内通过该待测链路所发送消息的消息时延,作为该待测链路的链路时延,其中,所述待测链路为:与所述第一业务节点不同的待测业务节点中各个第二设备与所述第一设备间的链路,所述消息时延为:向第二设备发送消息至接收到第二设备反馈响应间的时延;
针对每一第二设备,根据一端为该第二设备的待测链路的链路时延,计算表征所述统计周期内向该第二设备所发送消息的消息时延,作为该第二设备的综合消息时延;
根据所述待测业务节点中综合消息时延超过预设时延的第二设备的数量,检测所述待测业务节点是否存在网络故障。
2.根据权利要求1所述的方法,其特征在于,所述针对每一待测链路,计算表征统计周期内通过该待测链路所发送消息的消息时延,作为该待测链路的链路时延,包括:
针对每一待测链路,获得统计周期内通过该待测链路发送的每一消息的消息时延,计算所获得消息时延的平均值,作为该待测链路的链路时延。
3.根据所述权利要求2所述的方法,其特征在于,
所述每一消息的消息时延为:T2-T1-ΔT;
其中,T1表示向第二设备发送消息的时间戳,T2表示接收到第二设备反馈响应的时间戳,ΔT表示第二设备接收到消息与第二设备生成响应之间的时间差。
4.根据权利要求1-3中任一项所述的方法,其特征在于,所述针对每一第二设备,根据一端为该第二设备的待测链路的链路时延,计算表征所述统计周期内向该第二设备所发送消息的消息时延,作为该第二设备的综合消息时延,包括:
针对每一第二设备,计算一端为该第二设备的各待测链路的链路时延的平均值,作为该第二设备的综合消息时延。
5.根据权利要求1-3中任一项所述的方法,其特征在于,所述根据所述待测业务节点中综合消息时延超过预设时延的第二设备的数量,检测所述待测业务节点是否存在网络故障,包括:
判断连续预设数量个统计周期内异常设备的数量与所述待测业务节点中第二设备的总数间的比值是否大于预设阈值,所述异常设备为:所述待测业务节点中综合消息时延超过预设时延的第二设备;
若为是,确定所述待测业务节点存在网络故障。
6.一种网络故障检测装置,其特征在于,应用于业务集群内第一业务节点中的第一设备,所述装置包括:
链路时延计算模块,用于针对每一待测链路,计算表征统计周期内通过该待测链路所发送消息的消息时延,作为该待测链路的链路时延,其中,所述待测链路为:与所述第一业务节点不同的待测业务节点中各个第二设备与所述第一设备间的链路,所述消息时延为:向第二设备发送消息至接收到第二设备反馈响应间的时延;
综合时延计算模块,用于针对每一第二设备,根据一端为该第二设备的待测链路的链路时延,计算表征所述统计周期内向该第二设备所发送消息的消息时延,作为该第二设备的综合消息时延;
网络故障检测模块,用于根据所述待测业务节点中综合消息时延超过预设时延的第二设备的数量,检测所述待测业务节点是否存在网络故障。
7.根据权利要求6所述的装置,其特征在于,
所述链路时延计算模块,具体用于针对每一待测链路,获得统计周期内通过该待测链路发送的每一消息的消息时延,计算所获得消息时延的平均值,作为该待测链路的链路时延。
8.根据所述权利要求7所述的装置,其特征在于,
所述每一消息的消息时延为:T2-T1-ΔT;
其中,T1表示向第二设备发送消息的时间戳,T2表示接收到第二设备反馈响应的时间戳,ΔT表示第二设备接收到消息与第二设备生成响应之间的时间差。
9.根据权利要求6-8中任一项所述的装置,其特征在于,
所述综合时延计算模块,具体用于针对每一第二设备,计算一端为该第二设备的各待测链路的链路时延的平均值,作为该第二设备的综合消息时延。
10.根据权利要求6-8中任一项所述的装置,其特征在于,所述网络故障检测模块,具体用于:
判断连续预设数量个统计周期内异常设备的数量与所述待测业务节点中第二设备的总数间的比值是否大于预设阈值,所述异常设备为:所述待测业务节点中综合消息时延超过预设时延的第二设备;
若为是,确定所述待测业务节点存在网络故障。
11.一种电子设备,其特征在于,所述电子设备为业务集群内第一业务节点中的第一设备,所述电子设备包括:处理器和机器可读存储介质,所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令,所述处理器被所述机器可执行指令促使:实现权利要求1-5任一所述的方法步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911286017.7A CN111064613B (zh) | 2019-12-13 | 2019-12-13 | 一种网络故障检测方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911286017.7A CN111064613B (zh) | 2019-12-13 | 2019-12-13 | 一种网络故障检测方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111064613A CN111064613A (zh) | 2020-04-24 |
CN111064613B true CN111064613B (zh) | 2022-03-22 |
Family
ID=70301587
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911286017.7A Active CN111064613B (zh) | 2019-12-13 | 2019-12-13 | 一种网络故障检测方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111064613B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111669340B (zh) * | 2020-07-03 | 2021-06-22 | 全时云商务服务股份有限公司 | 发送带宽控制方法、装置、网络设备及可读存储介质 |
CN115914038B (zh) * | 2022-11-11 | 2024-04-09 | 中国联合网络通信集团有限公司 | 劣化转发设备检测方法、装置、设备及存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105490837A (zh) * | 2015-11-24 | 2016-04-13 | 广州市百果园网络科技有限公司 | 一种网络监控处理方法以及装置 |
CN107678918A (zh) * | 2017-09-26 | 2018-02-09 | 郑州云海信息技术有限公司 | 一种分布式文件***的osd心跳机制设置方法及装置 |
CN108235751A (zh) * | 2017-12-18 | 2018-06-29 | 华为技术有限公司 | 识别对象存储设备亚健康的方法、装置和数据存储*** |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8443231B2 (en) * | 2010-04-12 | 2013-05-14 | Symantec Corporation | Updating a list of quorum disks |
US9239749B2 (en) * | 2012-05-04 | 2016-01-19 | Paraccel Llc | Network fault detection and reconfiguration |
-
2019
- 2019-12-13 CN CN201911286017.7A patent/CN111064613B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105490837A (zh) * | 2015-11-24 | 2016-04-13 | 广州市百果园网络科技有限公司 | 一种网络监控处理方法以及装置 |
CN107678918A (zh) * | 2017-09-26 | 2018-02-09 | 郑州云海信息技术有限公司 | 一种分布式文件***的osd心跳机制设置方法及装置 |
CN108235751A (zh) * | 2017-12-18 | 2018-06-29 | 华为技术有限公司 | 识别对象存储设备亚健康的方法、装置和数据存储*** |
Also Published As
Publication number | Publication date |
---|---|
CN111064613A (zh) | 2020-04-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109951576B (zh) | 用于监视服务的方法、设备和存储介质 | |
US11671342B2 (en) | Link fault isolation using latencies | |
US7995574B2 (en) | Detection of forwarding problems for external prefixes | |
US10581756B2 (en) | Nonintrusive dynamically-scalable network load generation | |
US8347143B2 (en) | Facilitating event management and analysis within a communications environment | |
TW213994B (zh) | ||
CN108418710B (zh) | 一种分布式监控***、方法及装置 | |
CN111064613B (zh) | 一种网络故障检测方法及装置 | |
CN106789445B (zh) | 一种广电网络中网络设备的状态轮询方法和*** | |
JP2008236267A (ja) | 伝送装置、試験方法および伝送装置制御プログラム | |
EP3232620B1 (en) | Data center based fault analysis method and device | |
US11262391B1 (en) | Power outage detection | |
CN111355600B (zh) | 一种主节点确定方法和装置 | |
CN112261133A (zh) | Cdn节点控制方法、装置、服务器及存储介质 | |
CN111565133B (zh) | 专线切换方法、装置、电子设备和计算机可读存储介质 | |
US20090116395A1 (en) | Communication apparatus and method | |
US8018864B2 (en) | Relay device and communication-path managing method | |
US20050234919A1 (en) | Cluster system and an error recovery method thereof | |
CN108235800B (zh) | 一种网络故障探测方法、控制中心设备及计算机存储介质 | |
CN108512698B (zh) | 一种网络容灾方法、装置及电子设备 | |
US11606282B2 (en) | Method and device for detecting network reliability | |
US9100302B2 (en) | Methods and systems for monitoring multicast availability | |
CN111934909B (zh) | 主备机ip资源切换方法、装置、计算机设备和存储介质 | |
EP3355530A1 (en) | Method, apparatus and device for processing service failure | |
EP3756310B1 (en) | Method and first node for managing transmission of probe messages |
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 |