CN105933153A - 集群故障监测方法及装置 - Google Patents

集群故障监测方法及装置 Download PDF

Info

Publication number
CN105933153A
CN105933153A CN201610261291.9A CN201610261291A CN105933153A CN 105933153 A CN105933153 A CN 105933153A CN 201610261291 A CN201610261291 A CN 201610261291A CN 105933153 A CN105933153 A CN 105933153A
Authority
CN
China
Prior art keywords
server
test
list
residue
access
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.)
Pending
Application number
CN201610261291.9A
Other languages
English (en)
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.)
LeTV Holding Beijing Co Ltd
LeTV Information Technology Beijing Co Ltd
Original Assignee
LeTV Holding Beijing Co Ltd
LeTV Information Technology Beijing Co 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 LeTV Holding Beijing Co Ltd, LeTV Information Technology Beijing Co Ltd filed Critical LeTV Holding Beijing Co Ltd
Priority to CN201610261291.9A priority Critical patent/CN105933153A/zh
Publication of CN105933153A publication Critical patent/CN105933153A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0677Localisation of faults
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/10Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/106Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps

Abstract

本发明实施例提供一种集群故障监测方法及装置。根据服务器集群的结构获取集群中每一服务器的接入路径;在同一接入交换机下,按照预设策略选取第一服务器和第二服务器组成测试对;根据所述第一服务器以及所述第二服务器的所述接入路径对所述测试对进行数据收发测试;获取所述数据收发测试的结果并根据所述数据收发测试结果获取第一服务器和第二服务器之间的收发带宽;当判断所述收发带宽大于预设的带宽阈值,判定所述第一服务器和所述第二服务器无故障。实现了服务器集群故障的实时监测以及故障快速发现。

Description

集群故障监测方法及装置
技术领域
本发明实施例涉及大数据处理技术领域,尤其涉及一种集群故障监测方法及装置。
背景技术
服务器集群就是指将很多服务器集中起来一起进行同一种服务,在客户端看来服务器集群就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度,也可以用多个计算机做备份,从而使得任何一个机器坏了整个系统还是能正常运行。一旦在服务器上安装并运行了群集服务,该服务器即可加入群集。群集化操作可以减少单点故障数量,并且实现了群集化资源的高可用性。
通常在分布式服务器集群中,一个大的作业被拆分为多个任务,并将这多个任务分发给集群中的多个服务器并行处理的,从而能够实现高效率的数据处理。但是,若这个服务器集群中,某一服务器出现运行缓慢的状况,则其对整个服务器集群的影响是相当大的,它会拖慢整个集群对作业的处理速度。集群中某一服务器的挂机是很容易检测出来的,然而运行缓慢这种故障不同于服务器挂机,很难直观地检测到这种故障。
因此,如何找到出现故障的服务器是一个很关键的步骤,这一步骤关系着整个服务器集群是否能够正常运行。
发明内容
本发明实施例提供一种集群故障监测方法及装置,用以解决现有技术中的集群中服务器出现故障从而拖慢整个集群运行状态的缺陷,实现集群故障的高效监测。
本发明实施例提供一种集群故障监测方法,包括:
根据服务器集群的结构获取集群中每一服务器的接入路径;
在同一接入交换机下,按照预设策略选取第一服务器和第二服务器组成测试对;
根据所述第一服务器以及所述第二服务器的所述接入路径对所述测试对进行数据收发测试;
获取所述数据收发测试的结果并根据所述数据收发测试结果获取第一服务器和第二服务器之间的收发带宽;
当判断所述收发带宽大于预设的带宽阈值,判定所述第一服务器和所述第二服务器无故障。
本发明实施例提供一种集群故障监测装置,包括:
信息获取模块,用于根据服务器集群的结构获取集群中每一服务器的接入路径;
测试模块,用于在同一接入交换机下,按照预设策略选取第一服务器和第二服务器组成测试对;根据所述第一服务器以及所述第二服务器的所述接入路径对所述测试对进行数据收发测试;
分析模块,用于获取所述数据收发测试的结果并根据所述数据收发测试结果获取第一服务器和第二服务器之间的收发带宽;当判断所述收发带宽大于预设的带宽阈值,判定所述第一服务器和所述第二服务器无故障。
本发明实施例提供的集群故障监测方法及装置,根据服务器集群中每一服务器的接入路径构建测试对并对所述测试对进行数据的收发测试,从而判断两台服务器之间的带宽是否出现异常,并以此进行服务器集群故障的判断,实现了服务器集群故障的实时监测以及故障快速发现。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例一的技术流程图;
图2为本申请实施例二的技术流程图;
图3为本申请实施例三的装置实施例结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
图1是本申请实施例一的技术流程图,结合图1,本申请实施例一种集群故障监测方法,可由如下的步骤实现:
步骤S110:根据服务器集群的结构获取集群中每一服务器的接入路径;
步骤S120:在同一接入交换机下,按照预设策略选取第一服务器和第二服务器组成测试对;
步骤S130:根据所述第一服务器以及所述第二服务器的所述接入路径对所述测试对进行数据收发测试;
步骤S140:获取所述数据收发测试的结果并根据所述数据收发测试结果获取第一服务器和第二服务器之间的收发带宽;
步骤S150:当判断所述收发带宽大于预设的带宽阈值,判定所述第一服务器和所述第二服务器无故障。
具体的,在步骤S110中,所述获取集群中每一服务器的接入路径,即获取每一所述服务器接入的接入交换机以及核心交换机是哪一个。通常,基于大数据分布式集群结构如下:服务器连接接入交换机,接入交换机连接核心交换机。接入交换机有48个下行端口,最多可以连接48台服务器,带宽为10Gbits/s。接入交换机有2个上行端口,分别连接两个核心交换机,以防止单个核心交换机故障导致整个集群不可用,每个上行端口带宽为40Gbits/s,共80Gbits/s。核心交换机有48个下行口。这样一套核心交换机下最多有48*48=2304台服务器。这一套两台核心交换机的流量最大为3840Gbits/s。
根据上述集群的结构,连接在核心交换机1的接入交换机1下的服务器的接入路径可能有一下的描述结果:
/机房/核心交换机1/接入交换机1/1
/机房/核心交换机1/接入交换机1/2
/机房/核心交换机1/接入交换机1/3
..........
/机房/核心交换机1/接入交换机1/48
连接在核心交换机2的接入交换机2下的服务器可由如下的接入路径:
/机房/核心交换机2/接入交换机2/1
/机房/核心交换机2/接入交换机2/2
/机房/核心交换机2/接入交换机2/3
..........
/机房/核心交换机2/接入交换机2/48
本步骤中,获取到每一服务器的接入路径后,需将每一服务器的IP地址与所述接入路径进行匹配,所述IP地址用于后续步骤的数据收发测试。
例如,将服务器的IP写入节点可得到如下的结果;
/机房/核心交换机1/接入交换机1/1/192.0.x.1
/机房/核心交换机1/接入交换机1/2/192.0.x.2
/机房/核心交换机1/接入交换机1/3/192.0.x.3
..........
/机房/核心交换机n/接入交换机1/服务器48/192.0.x.48
需要说明的是,本申请实施例中,采用zookeeper为每一服务器写路径。由于zookeeper是成熟的分布式系统的可靠协调系统,本实施例中不再赘述。
具体的,在步骤S120中,所述预设策略是预先设定好的测试对选取策略,可以包括如下的方式:
其一:对所述同一交换机下的每一所述服务器进行编号,按所述编号依次选取两个所述服务器组成所述测试对;
这一选取策略中,假设同一接入交换机下,有48台按照顺序编号的服务器,则可直接按照顺序,编号为1的服务器和编号为2的服务器组成测试对,编号为3的服务器和编号为4的服务器组成测试对等等,直至编号为47的服务器与编号为48的服务器组成测试对。
其二:对所述编号为奇数的所述服务器进行列表得到奇数服务器列表,对所述编号为偶数的服务器进行列表得到偶数服务器列表;
按照所述奇数服务器列表以及所述偶数服务器列表的顺序依次选择一个所述编号为基数的服务器以及一个所述编号为偶数的服务器组成所述测试对。
具体的,步骤S130中,对所述测试对进行数据收发测试,所述数据收发测试具体包括如下的步骤:
S131:所述第二服务器通过预设协议向预设端口发送数据包并记录当前发送时刻的第一时间戳,其中,所述预设端口由所述第一服务器监听;
S132:第一服务器通过所述预设端口接收所述数据包并向第二服务器发送回复数据;
S133:第二服务器接收所述回复数据并记录当前接收时刻的第二时间戳;
S134:根据所述第一时间戳和所述第二时间戳获取所述第一服务器和所述第二服务器之间的带宽。
上述步骤中,由于每一服务器的接入路径以及IP地址都是已知的,因此在数据发送以及接收的过程中,直接读取目标数据发送的目标服务器的IP地址即可快速实现数据发送。
还需说明的是,本申请实施例中,选择数据测试对时,优先选择同一接入交换机下的服务器,若同一接入交换机下存在奇数个服务器,从而导致剩余一个服务器没有其他服务器与之配对时,则按照所述接入交换机在核心交换机下的接入顺序,将所述接入交换机下的剩余服务器注册在所述核心交换机的剩余服务器列表中;
对于超大规模分布式集群,配对服务器的选取非常重要,不能是任意的。如一个交换机下的48台服务器都和其它交换机下的服务器配对,那么他的交换机到核心交换机的带宽会成为瓶颈。
例如,接入交换机1包含有47台服务器,则组成所述测试对时,一定有一台服务器是落单的,则将这台落单的服务器注册在接入交换机1所在的核心交换机的剩余服务器列表中。同理,若是接入交换机4中也有一台服务器是落单的,则同样可以将这台落单的服务器注册在所述核心交换机的剩余服务器列表中。
例如,注册结果可以是:
/机房/核心交换机1/1 192.0.x.1
/机房/核心交换机1/4 192.0.y.1
待核心交换机1下所有接入交换机的落单服务器都列在所述核心交换机的剩余服务器列表之后,按照所述预设策略选取两个服务器组成所述测试对。当所述核心交换机的剩余服务器列表中包含奇数个所述服务器时,一定有一个服务器是落单没有配对的,此时,将剩余未配对的所述服务器按照所述核心交换机在机房下的接入顺序注册在所述机房的剩余服务器列表中;在所述机房的剩余服务器列表中,按照所述预设策略选取两个服务器组成所述测试对。
当所述机房的剩余服务器列表中包含奇数个所述服务器时,将未配对的所述服务器与预留的桩服务器组成所述测试对。
具体的,在步骤S140中,所述第一服务器和所述第二服务器之间的收发带宽是根据所述第一时间戳和所述第二时间戳之间的差值以及所述第一服务器和所述第二服务器之间的收发的数据量计算得到的,通常两个服务器之间发送的数据都是预设的固定值,例如10G,从而计算出的带宽与预设的带宽阈值有可比性。收发数据量除以所述第一时间戳和所述第二时间戳之间的差值得到的就是两个服务器之间的带宽。
具体的,在步骤S150中,所述预设的带宽阈值是数据在服务器之间收发的理论速度。对于一个大规模的集群而言,所述带宽阈值应当至少有四个值,记为第一带宽阈值、第二带宽阈值、第三带宽阈值与第四带宽阈值。
其中,第一带宽阈值针对于同一接入交换机下的服务器而言,在同一接入交换机下进行数据收发测试时,其数据传输是不跨接入交换机的,数据传输速度最快,相应的第一带宽阈值也应当是四个带宽阈值中最大的;第二带宽阈值针对所述核心交换机的剩余服务器列表中的服务器,这些服务器是跨接入交换机的,其数据传输的速度相对较慢一点,因此,理论上,第二带宽阈值应当小于第一带宽阈值。第三带宽阈值针对所述机房的剩余服务器列表中的服务器,这些服务器是跨核心交换机的,理论上,第三带宽阈值小于第二带宽阈值。第四带宽阈值是针对桩服务器与所述机房的剩余服务器列表中剩余的服务器而言的。
获取第一服务器和第二服务器之间的收发带宽之后,进一步读取所述第一服务器和所述第二服务器的接入路径,判断二者是否跨接入交换机以及是否跨核心交换机,从而选择合适的带宽阈值进行服务器故障的判断。通常情况下,若两个服务器之间的收发带宽大于理论值,即,传输速度大于理论速度,则可直接判定两个服务器之间数据传输正常,无延迟,无故障。
另,本申请实施例中,当判断所述收发带宽小于或等于预设的带宽阈值,则可判定两个服务器之间一定是存在故障的,但是不知道具体是第一服务器有故障还是第二服务器有故障。因此,优选的,本申请实施例在上述步骤之后,还可以包括如下步骤:
步骤S160:选取第三服务器以及第四服务器分别与所述第一服务器和所述第二服务器组成两个所述测试对;其中,所述第三服务器和所述第四服务器为传输无故障的所述测试对。
本步骤中,首先保证选取的第三服务器和第四服务器是正常运行的服务器,可以将第一服务器和第三服务器组成测试对,将第二服务器和第四服务器组成测试对,也可以将第一服务器和第四服务器组成测试对,将第二服务器与第三服务器组成测试对。如此一来,组成的两个新测试对中,分别包含一个运行正常的服务器。再进行数据收发测试时,收发带宽小于或等于带宽阈值的测试组中,除运行正常的服务器之外,另一服务器一定是故障服务器。
本实施例中,根据服务器集群中每一服务器的接入路径构建测试对并对所述测试对进行数据的收发测试,从而判断两台服务器之间的带宽是否出现异常,并以此进行服务器集群故障的判断,实现了服务器集群故障的实时监测以及故障快速发现。
图2是本申请实施例二的技术流程图,结合图2,本申请实施例一种集群故障监测方法,还可以由如下的步骤实现:
步骤S201:根据服务器集群的结构获取集群中每一服务器的接入路径;
步骤S202:在同一接入交换机下,按照预设策略选取第一服务器和第二服务器组成测试对;
步骤S203:根据所述第一服务器以及所述第二服务器的所述接入路径对所述测试对进行数据收发测试;
步骤S204:所述第二服务器通过预设协议向预设端口发送数据包并记录当前发送时刻的第一时间戳,其中,所述预设端口由所述第一服务器监听;
步骤S205:第一服务器通过所述预设端口接收所述数据包并向第二服务器发送回复数据;
步骤S206:第二服务器接收所述回复数据并记录当前接收时刻的第二时间戳;
步骤S207:根据所述第一时间戳和所述第二时间戳获取所述第一服务器和所述第二服务器之间的带宽;
步骤S208:当判断所述收发带宽小于或等于预设的带宽阈值,判定所述第一服务器或所述第二服务器存在故障;
步骤S209:选取第三服务器以及第四服务器分别与所述第一服务器和所述第二服务器组成两个所述测试对;其中,所述第三服务器和所述第四服务器为传输无故障的所述测试对。
步骤S210:当判定两个所述测试对中所述第一服务器所在的所述测试对的所述收发带宽小于所述预设的收发带宽,则判定所述第一服务器存在故障;或,当判定两个所述测试对中所述第二服务器所在的所述测试对的所述收发带宽小于所述预设的收发带宽,则判定所述第二服务器存在故障。
本实施例中,根据服务器集群中每一服务器的接入路径构建测试对并对所述测试对进行数据的收发测试,从而判断两台服务器之间的带宽是否出现异常;当判定两台服务器之间存在收发异常时,利用收发无故障的服务器与收发异常的两台服务器组成测试对再进行数据的收发测试,从而判定故障服务器,实现了服务器集群故障的实时监测以及故障快速发现。
图3是本申请实施例三的装置结构示意图,结合图3,本申请实施例一种集群故障监测装置,包括如下的模块:
信息获取模块310,用于根据服务器集群的结构获取集群中每一服务器的接入路径;
测试模块320,用于在同一接入交换机下,按照预设策略选取第一服务器和第二服务器组成测试对;根据所述第一服务器以及所述第二服务器的所述接入路径对所述测试对进行数据收发测试;
分析模块330,用于获取所述数据收发测试的结果并根据所述数据收发测试结果获取第一服务器和第二服务器之间的收发带宽;当判断所述收发带宽大于预设的带宽阈值,判定所述第一服务器和所述第二服务器无故障。
其中,所述预设的策略包括:对所述服务器集群中的每一所述服务器进行编号并按所述编号依次选取两个所述服务器组成所述测试对;或,
获取所述编号为奇数的所述服务器对应的奇数服务器列表,获取所述编号为偶数的所述服务器对应的偶数服务器列表;;
按照所述奇数服务器列表以及所述偶数服务器列表的顺序依次选择一个所述编号为基数的服务器以及一个所述编号为偶数的服务器组成所述测试对。
其中,所述测试模块320还用于:当所述接入交换机下存在奇数个所述服务器时,将所述接入交换机下的剩余服务器按照所述接入交换机在核心交换机下的接入顺序注册在所述核心交换机的剩余服务器列表中;其中,所述剩余服务器为奇数个所述服务器中没有其他服务器与之组成测试对的服务器。
其中,所述测试模块320还用于:在所述核心交换机的剩余服务器列表中,按照所述预设策略选取两个服务器组成所述测试对。
其中,所述测试模块320还用于:当所述核心交换机的剩余服务器列表中包含奇数个所述服务器时,将剩余未配对的所述服务器
按照所述核心交换机在机房下的接入顺序注册在所述机房的剩余服务器列表中;在所述机房的剩余服务器列表中,按照所述预设策略选取两个服务器组成所述测试对。
所述测试模块320还用于:当所述机房的剩余服务器列表中包含奇数个所述服务器时,将未配对的所述服务器与预留的桩服务器组成所述测试对。
其中,所述测试模块320具体用于:所述第二服务器通过预设协议向预设端口发送数据包并记录当前发送时刻的第一时间戳,其中,所述预设端口由所述第一服务器监听;第一服务器通过所述预设端口接收所述数据包并向第二服务器发送回复数据;第二服务器接收所述回复数据并记录当前接收时刻的第二时间戳;根据所述第一时间戳和所述第二时间戳获取所述第一服务器和所述第二服务器之间的带宽。
其中,所述测试模块320还用于:当判断所述收发带宽小于或等于预设的带宽阈值,选取第三服务器以及第四服务器分别与所述第一服务器和所述第二服务器组成两个所述测试对;其中,所述第三服务器和所述第四服务器为传输无故障的所述测试对;
当判定两个所述测试对中所述第一服务器所在的所述测试对的所述收发带宽小于所述预设的收发带宽,则判定所述第一服务器存在故障;或,
当判定两个所述测试对中所述第二服务器所在的所述测试对的所述收发带宽小于所述预设的收发带宽,则判定所述第二服务器存在故障。
图3所示装置可以执行图1及图2所示实施例的方法,实现原理和技术效果参考图1及图2所示实施例,不再赘述。
应用实例
以下部分将结合一个具体的应用场景,以一个实际的例子对本申请实施例的技术方案进行进一步阐述。
服务器集群系统先保留一台服务器作为桩,它监听54321端口,用于和剩余服务器中找不到配对的服务器配对。
步骤一、利用zookeeper为每一服务器写路径,每一个接入交换机下的服务器的,注册一个顺序节点,路径可以是这样的:
/机房/核心交换机1/接入交换机1/1
/机房/核心交换机1/接入交换机1/2
/机房/核心交换机1/接入交换机1/3
..........
/机房/核心交换机1/接入交换机1/n
将服务器的IP写入节点;
/机房/核心交换机1/接入交换机1/1/192.0.x.1
/机房/核心交换机1/接入交换机1/2/192.0.x.2
/机房/核心交换机1/接入交换机1/3/192.0.x.3
..........
/机房/核心交换机n/接入交换机m/服务器n/192.0.x.n
如果最后一个编号为奇数,则执行步骤二,否则比对编号为偶数的服务器路径列表和编号为奇数的服务器的路径列表,按照顺序,将一个奇数服务器和一个偶数服务器配对,执行测试步骤。
例如,注册的名称为1的服务器结点,往名称为2的服务器结点中打数据。则名称为“/机房/核心交换机1/接入交换机1/1192.0.x.1”和名称为“/机房/核心交换机1/接入交换机1/2192.0.x.2”是一对可以互相打数据的服务器对。
等同步服务发出服务器节点1的同步时,进行数据传输,然后把相关结点删除。
两台服务器的测试步骤具体如下,假设两台测试服务器分别为A,B,测试的目的是计算AB服务器之间的带宽。首先可以在其中的一台服务器,例如服务器B监听一个端口(如54321),另一台服务器A通过预定协议,往服务器B的监听端口发送一段数据如10GB,服务器B收到数据进行回复,服务器A在发送之前记录当时系统时间t1,再收到服务器B的回复后再次记录系统时间t2,这两次时间相减,可以得到发送数据所花费的时间t,用发送的数据除以所花费的时间,就是两台服务器之间的带宽。
步骤二、根据步骤一判断得知每个接入交换机下最多有一台服务器不能参加测试,因在同一个接入交换机下没有与之配对的另一服务器。这将这些服务器顺序注册在核心交换机下,例如:
/机房/核心交换机1/1192.168.1.87
/机房/核心交换机1/2192.168.2.32
.....
如果最后一个编号为奇数,则执行步骤三,否则比对编号为偶数的服务器路径列表和编号为奇数的服务器的路径列表,按照顺序,即可将一个奇数服务器和一个偶数服务器配对,执行测试步骤。如注册的名称为1的结点,往名称为2的结点中打数据。
等同步服务发出阶段2的同步时,进行数据传输,然后把相关结点删除。
步骤三、从步骤二中判断得知每个核心交换机下最多有一台服务器不能参加测试,可将这些服务器注册在/机房。
/机房/1 192.168.1.123
/机房/2 192.168.2.128
....
如果最后一个编号为奇数,则和预留的桩结点配对。否则比对编号为偶数的服务器路径列表和编号为奇数的服务器的路径列表,按照顺序,即可将一个一个奇数服务器和偶数服务器配对,执行测试步骤。如注册的名称为1的结点,往名称为2的结点中打数据。
每个步骤的测试,如果服务器A到服务器B的速度明显慢于理论速度,则无法判断是服务器A慢,服务器B慢,还是都慢。判断方法如下,选取另外的速度正常的服务器对,服务器C、服务器D,已经测试从服务器C到服务器D传输数据的带宽正常。现在服务器A和服务器D,服务器C和服务器B组成两个新的配对,并进行数据传输测试,如果服务器A到服务器D的传输速度慢,则服务器A有问题。
以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机装置(可以是个人计算机,服务器,或者网络装置等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (14)

1.一种集群故障监测方法,其特征在于,包括如下的步骤:
根据服务器集群的结构获取集群中每一服务器的接入路径;
在同一接入交换机下,按照预设策略选取第一服务器和第二服务器组成测试对;
根据所述第一服务器以及所述第二服务器的所述接入路径对所述测试对进行数据收发测试;
获取所述数据收发测试的结果并根据所述数据收发测试结果获取第一服务器和第二服务器之间的收发带宽;
当判断所述收发带宽大于预设的带宽阈值,判定所述第一服务器和所述第二服务器无故障。
2.根据权利要求1所述的方法,其特征在于,所述预设的策略包括:
对所述同一接入交换机下的每一所述服务器进行编号,按所述编号依次选取两个所述服务器组成所述测试对;或,
获取所述编号为奇数的所述服务器对应的奇数服务器列表,获取所述编号为偶数的所述服务器对应的偶数服务器列表;
按照所述奇数服务器列表以及所述偶数服务器列表的顺序依次选择一个所述编号为基数的服务器以及一个所述编号为偶数的服务器组成所述测试对。
3.根据权利要求2所述的方法,其特征在于,按照预设策略选取第一服务器和第二服务器组成测试对,还包括:
当所述接入交换机下存在奇数个所述服务器时,将所述接入交换机下的剩余服务器按照所述接入交换机在核心交换机下的接入顺序注册在所述核心交换机的剩余服务器列表中;
在所述核心交换机的剩余服务器列表中,按照所述预设策略选取两个服务器组成所述测试对。
4.根据权利要求3所述的方法,其特征在于,所述方法还包括:
当所述核心交换机的剩余服务器列表中包含奇数个所述服务器时,将剩余未配对的所述服务器按照所述核心交换机在机房下的接入顺序注册在所述机房的剩余服务器列表中;
在所述机房的剩余服务器列表中,按照所述预设策略选取两个服务器组成所述测试对。
5.根据权利要求4所述的方法,其特征在于,所述方法还包括:
当所述机房的剩余服务器列表中包含奇数个所述服务器时,将未配对的所述服务器与预留的桩服务器组成所述测试对。
6.根据权利要求5所述的方法,其特征在于,对所述测试对进行数据收发测试,具体包括:
所述第二服务器通过预设协议向预设端口发送数据包并记录当前发送时刻的第一时间戳,其中,所述预设端口由所述第一服务器监听;
第一服务器通过所述预设端口接收所述数据包并向第二服务器发送回复数据;
第二服务器接收所述回复数据并记录当前接收时刻的第二时间戳;
根据所述第一时间戳和所述第二时间戳,获取所述第一服务器和所述第二服务器之间的带宽。
7.根据权利要求1所述的方法,其特征在于,所述方法还包括:
当判断所述收发带宽小于或等于预设的带宽阈值,选取第三服务器以及第四服务器分别与所述第一服务器和所述第二服务器组成两个所述测试对;其中,所述第三服务器和所述第四服务器为传输无故障的所述测试对;
当判定两个所述测试对中所述第一服务器所在的所述测试对的所述收发带宽小于所述预设的收发带宽,则判定所述第一服务器存在故障;或,
当判定两个所述测试对中所述第二服务器所在的所述测试对的所述收发带宽小于所述预设的收发带宽,则判定所述第二服务器存在故障。
8.一种集群故障监测装置,其特征在于,包括如下的模块:
信息获取模块,用于根据服务器集群的结构获取集群中每一服务器的接入路径;
测试模块,用于在同一接入交换机下,按照预设策略选取第一服务器和第二服务器组成测试对;根据所述第一服务器以及所述第二服务器的所述接入路径对所述测试对进行数据收发测试;
分析模块,用于获取所述数据收发测试的结果并根据所述数据收发测试结果获取第一服务器和第二服务器之间的收发带宽;当判断所述收发带宽大于预设的带宽阈值,判定所述第一服务器和所述第二服务器无故障。
9.根据权利要求7所述的装置,其特征在于,所述预设的策略包括:
对所述同一接入交换机下中的每一所述服务器进行编号,按所述编号依次选取两个所述服务器组成所述测试对;或,
获取所述编号为奇数的所述服务器对应的奇数服务器列表,获取所述编号为偶数的所述服务器对应的偶数服务器列表;
按照所述奇数服务器列表以及所述偶数服务器列表的顺序依次选择一个所述编号为基数的服务器以及一个所述编号为偶数的服务器组成所述测试对。
10.根据权利要求9所述的装置,其特征在于,所述测试模块还用于:
当所述接入交换机下存在奇数个所述服务器时,将所述接入交换机下的剩余服务器按照所述接入交换机在核心交换机下的接入顺序注册在所述核心交换机的剩余服务器列表中;
在所述核心交换机的剩余服务器列表中,按照所述预设策略选取两个服务器组成所述测试对。
11.根据权利要求10所述的装置,其特征在于,所述测试模块还用于:
当所述核心交换机的剩余服务器列表中包含奇数个所述服务器时,将剩余未配对的所述服务器按照所述核心交换机在机房下的接入顺序注册在所述机房的剩余服务器列表中;
在所述机房的剩余服务器列表中,按照所述预设策略选取两个服务器组成所述测试对。
12.根据权利要求11所述的装置,其特征在于,所述测试模块还用于:
当所述机房的剩余服务器列表中包含奇数个所述服务器时,将未配对的所述服务器与预留的桩服务器组成所述测试对。
13.根据权利要求8所述的装置,其特征在于,所述测试模块具体用于:
所述第二服务器通过预设协议向预设端口发送数据包并记录当前发送时刻的第一时间戳,其中,所述预设端口由所述第一服务器监听;
第一服务器通过所述预设端口接收所述数据包并向第二服务器发送回复数据;
第二服务器接收所述回复数据并记录当前接收时刻的第二时间戳;
根据所述第一时间戳和所述第二时间戳获取所述第一服务器和所述第二服务器之间的带宽。
14.根据权利要求8所述的装置,其特征在于,所述测试模块还用于:
当判断所述收发带宽小于或等于预设的带宽阈值,选取第三服务器以及第四服务器分别与所述第一服务器和所述第二服务器组成两个所述测试对;其中,所述第三服务器和所述第四服务器为传输无故障的所述测试对;
当判定两个所述测试对中所述第一服务器所在的所述测试对的所述收发带宽小于所述预设的收发带宽,则判定所述第一服务器存在故障;或,
当判定两个所述测试对中所述第二服务器所在的所述测试对的所述收发带宽小于所述预设的收发带宽,则判定所述第二服务器存在故障。
CN201610261291.9A 2016-04-25 2016-04-25 集群故障监测方法及装置 Pending CN105933153A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610261291.9A CN105933153A (zh) 2016-04-25 2016-04-25 集群故障监测方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610261291.9A CN105933153A (zh) 2016-04-25 2016-04-25 集群故障监测方法及装置

Publications (1)

Publication Number Publication Date
CN105933153A true CN105933153A (zh) 2016-09-07

Family

ID=56836072

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610261291.9A Pending CN105933153A (zh) 2016-04-25 2016-04-25 集群故障监测方法及装置

Country Status (1)

Country Link
CN (1) CN105933153A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106656606A (zh) * 2016-12-27 2017-05-10 北京奇虎科技有限公司 数据通路的测试方法、测试服务器及测试系统
CN111130917A (zh) * 2018-10-31 2020-05-08 北京国双科技有限公司 线路测试的方法、装置及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140067859A1 (en) * 2012-09-04 2014-03-06 Salesforce.Com, Inc. Facilitating dynamically controlled fetching of data at client computing devices in an on-demand services environment
CN104202375A (zh) * 2014-08-22 2014-12-10 广州华多网络科技有限公司 同步数据的方法及系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140067859A1 (en) * 2012-09-04 2014-03-06 Salesforce.Com, Inc. Facilitating dynamically controlled fetching of data at client computing devices in an on-demand services environment
CN104202375A (zh) * 2014-08-22 2014-12-10 广州华多网络科技有限公司 同步数据的方法及系统

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
严代彪: "军车多区域无线集群通信故障检测方法研究", 《计算机仿真》 *
张毅: "多集群计算环境故障监控管理系统", 《计算机工程与科学》 *
梁佼: "高性能服务器故障诊断方法的研究与设计", 《万方数据》 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106656606A (zh) * 2016-12-27 2017-05-10 北京奇虎科技有限公司 数据通路的测试方法、测试服务器及测试系统
CN111130917A (zh) * 2018-10-31 2020-05-08 北京国双科技有限公司 线路测试的方法、装置及系统

Similar Documents

Publication Publication Date Title
CA2407342C (en) Analysis of network performance
CN105165054B (zh) 网络服务故障处理方法,服务管理系统和系统管理模块
CN100536403C (zh) 一种通信网络智能巡检的方法及设备
CN101035037B (zh) 检测网络通信质量的方法、系统及相关装置
CN111817911B (zh) 一种探测网络质量的方法、装置、计算设备及存储介质
CN105897507B (zh) 节点设备的状态检测方法和装置
CN106302017B (zh) 高并发小流量网络测速系统及方法
CN111800354B (zh) 消息处理方法及装置、消息处理设备及存储介质
CN109428785A (zh) 一种故障检测方法和装置
CN106982244B (zh) 在云网络环境下实现动态流量的报文镜像的方法和装置
CN109104335A (zh) 一种工控设备网络攻击测试方法与系统
CN106301987B (zh) 一种报文丢失检测方法、装置及系统
CN106411629A (zh) 一种用于监控cdn节点的状态的方法和设备
CN103684818A (zh) 检测网络通道故障的方法及装置
CN107426051B (zh) 分布式集群系统中节点的工作状态的监测方法、装置及系统
US20160205011A1 (en) Method and Device for Testing Link Performance, Logic Processor and Network Processor
CN107294767A (zh) 一种直播网络传输故障监测方法及系统
CN111200544B (zh) 一种网络端口流量测试方法和装置
KR101640476B1 (ko) 네트워크의 테스트 분석시스템 및 그 분석방법
CN101252477B (zh) 一种网络故障根源的确定方法及分析装置
CN103995901B (zh) 一种确定数据节点失效的方法
CN105933153A (zh) 集群故障监测方法及装置
CN110674096A (zh) 节点故障排查方法、装置、设备及计算机可读存储介质
CN114401258A (zh) 短信发送方法、装置、电子装置和存储介质
CN106506265B (zh) 检测fpga芯片挂死的方法及装置

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20160907