CN111404719B - 网络拓扑信息采集方法及系统 - Google Patents

Abstract

本申请提供一种网络拓扑信息采集方法及系统，方法包括：运维服务器从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点，将采集节点的地址和各被采集节点的地址发送至采集节点；采集节点将采集节点的地址作为源地址和各被采集节点的地址作为目的地址传入预设脚本并执行预设脚本以批量采集各被采集节点与采集节点之间的拓扑信息；运维服务器接收来自采集节点采集的各被采集节点与采集节点之间的拓扑信息并存储。通过将运维服务器的采集压力分摊到节点上进行拓扑信息采集，在降低运维服务器采集压力提高采集效率的同时，提升了网络采集的准确性。在各个采集节点上通过预置脚本作为采集媒介以批量采集拓扑信息，可进一步提高采集效率。

Description

网络拓扑信息采集方法及系统

技术领域

本申请涉及网络技术领域，尤其涉及一种网络拓扑信息采集方法及系统。

背景技术

随着运维技术的不断发展，对于运维(OPS，Operations)平台的要求也越来越多。目前，对于网络拓扑信息的采集，运维平台采用的是一一遍历的方式对节点集群中所有节点进行拓扑信息采集。

然而，实际所使用的节点集群通常都比较庞大，在采用一一遍历方式进行网络拓扑信息采集时，运维平台的采集压力很大，并且采集效率也比较低。

发明内容

有鉴于此，本申请提供一种网络拓扑信息采集方法及系统，以解决运维平台采集压力大、采集效率低的问题。

根据本申请实施例的第一方面，提供一种网络拓扑信息采集方法，所述方法包括：

运维服务器从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点，将所述采集节点的地址和各被采集节点的地址发送至所述采集节点；

所述采集节点将所述采集节点的地址作为源地址和各被采集节点的地址作为目的地址传入预设脚本并执行所述预设脚本，以批量采集各被采集节点与采集节点之间的拓扑信息；

所述运维服务器接收来自所述采集节点采集的各被采集节点与采集节点之间的拓扑信息并存储。

根据本申请实施例的第二方面，提供一种网络拓扑信息采集系统，所述系统包括：

运维服务器，用于从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点，将所述采集节点的地址和各被采集节点的地址发送至所述采集节点；

所述采集节点，用于将所述采集节点的地址作为源地址和各被采集节点的地址作为目的地址传入预设脚本并执行所述预设脚本，以批量采集各被采集节点与采集节点之间的拓扑信息；

所述运维服务器，还用于接收来自所述采集节点采集的各被采集节点与采集节点之间的拓扑信息并存储。

应用本申请实施例，运维服务器通过从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点，并将采集节点的地址和各被采集节点的地址发送至采集节点，采集节点将采集节点的地址作为源地址和各被采集节点的地址作为目的地址传入预设脚本并执行预设脚本，以批量采集各被采集节点与采集节点之间的拓扑信息，最后运维服务器接收来自采集节点采集的各被采集节点与采集节点之间的拓扑信息并存储。

基于上述描述可知，本申请通过将运维服务器的采集压力分摊到节点上进行采集，即通过从节点集群中选择采集节点和被采集节点，以采集节点之间的拓扑信息，从而在降低运维服务器采集压力提高采集效率的同时，也提升了网络采集的准确性。在各个采集节点上通过预置的脚本作为采集媒介，以实现批量采集各节点的拓扑信息，可进一步提高采集效率。

附图说明

图1为本申请根据一示例性实施例示出的一种网络拓扑结构示意图；

图2A为本申请根据一示例性实施例示出的一种网络拓扑信息采集方法的实施例流程图；

图2B为本申请根据图2A所示实施例示出的一种拓扑信息示意图；

图2C为本申请根据图2A所示实施例示出的一种拓扑信息采集流程图；

图2D为本申请根据图2A所示实施例示出的一种网络拓扑提示示意图；

图3为本申请根据图2A所示实施例示出的另一种网络拓扑信息采集方法的实施例流程图；

图4为本申请根据图2A所示实施例示出的又一种网络拓扑信息采集方法的实施例流程图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

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

图1为本申请根据一示例性实施例示出的一种网络拓扑结构示意图，包括运维服务器、管理节点集群和存储节点集群。其中，运维服务器用于对管理节点集群中的管理节点和存储节点集群中的存储节点进行管理，并监控管理节点和存储节点的异常情况；管理节点集群用于对存储节点集群中存储节点进行管理，并监控各存储节点的存储情况；存储节点集群用于存储各种类型数据，如监控视频数据、文本数据、图片数据、语音数据等。

示例性的，管理节点集群中的管理节点数量通常为3～5个，存储节点集群中的存储节点数量通常为上百上千个。

本领域技术人员可以理解的是，上述图1所示的网络拓扑结构仅为一种示例，在实际应用中，对于存储节点数量比较少的网络结构，也可以省略管理节点集群的布设，由运维服务器负责管理存储节点。管理节点集群和存储节点集群通称为节点集群。

目前所采用的拓扑信息采集算法是运维服务器对全网中的所有节点一一遍历进行采集，这对于庞大的节点集群，运维服务器的采集压力很大，并且采集效率也比较低。

另外，这种运维服务器遍历采集方式实际获得的是运维服务器与各节点的拓扑信息，这些拓扑信息正常就认为各节点均正常，但实际节点集群是分级管理机制，上级节点与下级节点之间存在网络拓扑，每级节点之间存在网络拓扑，而运维服务器采集的拓扑信息正常并不代表各节点之间的网络正常，因此由运维服务器采集的拓扑信息准确度并不高。

为解决上述问题，本申请提出一种网络拓扑信息采集方法，运维服务器通过从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点，并将采集节点的地址和各被采集节点的地址发送至采集节点，采集节点将采集节点的地址作为源地址和各被采集节点的地址作为目的地址传入预设脚本并执行预设脚本，以批量采集各被采集节点与采集节点之间的拓扑信息，最后运维服务器接收来自采集节点采集的各被采集节点与采集节点之间的拓扑信息并存储。

基于上述描述可知，本申请通过将运维服务器的采集压力分摊到节点上进行采集，即通过从节点集群中选择采集节点和被采集节点，以采集节点之间的拓扑信息，从而在降低运维服务器采集压力提高采集效率的同时，也提升了网络采集的准确性。在各个采集节点上通过预置的脚本作为采集媒介，以实现批量采集各节点的拓扑信息，可进一步提高采集效率。

下面以具体实施例对本申请提出的网络拓扑信息采集方法进行详细阐述。

图2A为本申请根据一示例性实施例示出的一种网络拓扑信息采集方法的实施例流程图，下面以上述图1所示的网络拓扑结构为例，对所述网络拓扑信息采集方案进行详细说明。本申请实施例中的拓扑信息可以包括网络延迟、丢包率等信息，运维服务器依据这些信息可以决策节点的连通状态，即节点是否掉线。

如图2A所示，所述网络拓扑信息采集方法包括如下步骤：

步骤201：运维服务器从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点，并将该采集节点的地址和各被采集节点的地址发送至采集节点。

在一实施例中，运维服务器可以从节点集群中选择多个采集节点，并为每个采集节点选择需该采集节点采集的被采集节点，以将采集压力分摊到多个节点上，均衡单个采集节点的采集压力。

示例性的，运维服务器可以通过定时任务触发从节点集群中选择采集节点和被采集节点，以实现对节点异常情况的监控。

针对运维服务器如何选择采集节点和被采集节点的过程，可以参见下述图3和图4所示实施例的描述，在此暂不详述。

如上述图1所示的网络拓扑结构，节点集群包含管理节点集群和存储节点集群，存储节点是用来存储各种类型数据的，各存储节点之间需要进行数据的备份传输，除此之外，存储节点还需要与管理节点或运维服务器进行业务交互，为将数据传输与业务交互区分独立进行，存储节点上包含有用于进行数据备份传输的数据口和用于进行业务交互的业务口，与之对应，业务口有业务口的地址，数据口有数据口的地址，二者互不干扰。对于管理节点只是用来与存储节点或运维服务器进行业务交互，因此只包含有业务口。

基于此，当采集管理节点集群与存储节点集群之间的拓扑信息时，运维服务器选择的采集节点为管理节点，被采集节点为存储节点，且发送的采集节点的地址为采集节点业务口的地址，被采集节点的地址为被采集节点业务口的地址；当采集存储节点集群中各存储节点之间的拓扑信息时，运维服务器选择的采集节点和被采集节点均为存储节点，且发送的采集节点的地址为采集节点数据口的地址，被采集节点的地址为被采集节点数据口的地址。

其中，管理节点集群与存储节点集群之间为业务访问网络，存储节点集群内部存储节点之间为数据交互网络。由于管理节点只包含业务口，因此管理节点只有业务口的地址，该地址可唯一标识该节点；由于存储节点包含数据口和业务口，因此存储节点有数据口的地址和业务口的地址，这两个地址均唯一标识该节点。

在一实施例中，针对将该采集节点的地址和各被采集节点的地址发送至采集节点的过程，运维服务器可以通过将各被采集节点的地址生成地址串，并对生成的地址串和该采集节点的地址进行加密，得到加密数据，然后将加密数据和预设的认证字段添加到HTTP请求中并发送至该采集节点。

其中，基于HTTP((Hyper Text Transfer Protocol，超文本传输协议)协议的报文传输方式，不仅允许对传输的数据进行加密，而且还可以通过认证字段在对端验证其有效性，因此通过HTTP请求传输，可以提高网络采集计划的安全性，避免网络采集计划被恶意篡改。

示例性的，地址串的生成方式可以是将各个地址使用特殊字符进行拼接，例如，该特殊字符可以是“@”。

步骤202：采集节点将采集节点的地址作为源地址和各被采集节点的地址作为目的地址传入预设脚本并执行预设脚本，以批量采集各被采集节点与采集节点之间的拓扑信息。

在一实施例中，针对采集节点将采集节点的地址作为源地址和各被采集节点的地址作为目的地址传入预设脚本的过程，采集节点可以从接收到的HTTP请求中提取认证字段，并验证该认证字段是否有效，若有效，则从HTTP请求中提取加密数据并进行解密，得到地址串和本采集节点的地址，并将该地址串作为目的地址和本采集节点的地址作为源地址传入预设脚本。

其中，在验证认证字段的有效性时，可以将提取的认证字段与本地已存储的认证字段进行比较，若一致，则提取的认证字段有效，否则，提取的认证字段无效。

示例性的，采集节点可以通过CLI(command-line interface，命令行界面)调用本地预设脚本，并在向预设脚本传入源地址和目的地址的参数执行预设脚本时，通过执行ping命令，以采集目的地址所指向节点的拓扑信息。

需要说明的是，为了提高拓扑信息的准确度，运维服务器还可以将ping次数发送至采集节点，从而采集节点将ping次数也传入本地的预设脚本。其中，ping次数指的是在采集过程中，向被采集节点发送的数据包的次数，发送的数据包次数越多，采集到的拓扑信息越准确。

示例性的，通常ping命令的默认ping次数为4次，为了提高拓扑信息的准确度，可以设置为ping次数为5次。

示例性的，预设脚本可以是shell脚本，shell脚本是一种命令解析器，预置在shell脚本中的命令能够对传入的参数进行解析，进而执行脚本中的预置命令。由于传入shell脚本的目的地址为包含多个地址的地址串，因此可以一次性采集多个节点的拓扑信息。

需要进一步说明的是，由于采集节点采集每个被采集节点的耗时不同，而为了将所有被采集节点的拓扑信息一并返回，且不影响运维服务器的处理效率可以采用异步返回方式，即采集节点接收到来自运维服务器发送的HTTP请求后，可以向运维服务器返回应答，从而运维服务器在接收到应答后无需等待采集结果的返回，可以继续进行下一任务，从而提高了运维服务器的工作效率。

其中，应答的形式包括两种：一种是验证无效或解密失败的错误码通知，另一种是解密成功的成功接收通知。

步骤203：运维服务器接收来自采集节点采集的各被采集节点与采集节点之间的拓扑信息并存储。

在一实施例中，采集节点在采集到各被采集节点的拓扑信息后，还可以根据被采集节点的地址对拓扑信息进行格式化处理，以将每个被采集节点的拓扑信息以一行显示，然后再将经过格式化处理的拓扑信息发送给运维服务器。

示例性的，如图2B所示，为拓扑信息格式化处理后的显示示意图，采集节点的IP为10.192.81.91，被采集节点的IP有10.192.81.92和10.192.81.93，二者的拼接符为“@”，第一行的解读为：源IP为10.192.81.91，目的IP为10.192.81.92，发送数据包数量为2，接收数据包数量为2，丢包率(百分比)为0，采集传输的总时间为1001毫秒，最小延迟为0.713毫秒，最大延迟为2.148毫秒，平均延迟为3.583毫秒，ICMP(Internet Control MessageProtocol，Internet控制报文协议)包的RTT(Round-Trip Time，往返时延)偏离平均值的程度为1.435；第二行的解读为：源IP为10.192.81.91，目的IP为10.192.81.93，发送数据包数量为2，接收数据包数量为2，丢包率(百分比)为0，采集传输的总时间为1001毫秒，最小延迟为1.457毫秒，最大延迟为3.297毫秒，平均延迟为5.138毫秒，ICMP包的RTT偏离平均值的程度为1.841。

在一实施例中，基于上述步骤201的描述，管理节点只包含业务口，存储节点包含业务口和数据口，管理节点与存储节点之间通过业务口进行业务交互，存储节点之间通过数据库进行数据交互，因此，所采集的管理节点集群与存储节点集群之间的拓扑信息为业务口的拓扑信息，所采集的存储节点集群中各存储节点之间的拓扑信息为数据口的拓扑信息。

针对上述步骤201至步骤203的过程，如图2C所示，为拓扑信息采集流程图，通过在每个节点上预先配置用于与运维服务器交互的agent模块和用于采集拓扑信息的shell脚本，运维服务器向采集节点的agent模块发送基于HTTP协议的拓扑信息采集计划，即HTTP请求，agent模块对HTTP请求进行验证和解密，并通过CLI调用shell脚本，shell脚本执行ping命令，并将采集的各被采集节点的拓扑信息进行格式化处理，再将拓扑信息发送给agent模块，由agent模块将拓扑信息上传至运维服务器。

在一实施例中，运维服务器在接收到各被采集节点与采集节点之间的拓扑信息时，可以依据拓扑信息判断是否存在掉线的被采集节点，若存在，则输出采集节点与被采集节点之间未连通的提示。

示例性的，提示形式可以是连线异常提示形式，也可以是节点图标异常提示形式。

在一示例性场景中，如图2D所示，为一种前端网络拓扑提示示意图，用灰色显示的节点表示处于掉线状态，从图2D中可以看出，管理节点集群中有3个管理节点，其中的管理节点3已掉线，存储节点集群中有5个存储节点，其中的存储节点1和存储节点4已掉线。

在本申请实施例中，运维服务器通过从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点，并将采集节点的地址和各被采集节点的地址发送至采集节点，采集节点将采集节点的地址作为源地址和各被采集节点的地址作为目的地址传入预置的shell脚本并执行shell脚本，以批量采集各被采集节点与采集节点之间的拓扑信息，最后运维服务器接收来自采集节点采集的各被采集节点与采集节点之间的拓扑信息并存储。

基于上述描述可知，通过从节点集群中选择采集节点和被采集节点，以采集节点之间的拓扑信息，并将运维服务器的采集压力分摊到节点上，从而在降低运维服务器采集压力提高采集效率的同时，也提升了网络采集的准确性。在各个采集节点上通过预置的shell脚本作为采集媒介，以实现批量采集各节点的拓扑信息，可进一步提高采集效率。

图3为本申请根据图2A所示实施例示出的另一种网络拓扑信息采集方法的实施例流程图，基于上述图2A所示实施例的基础上，本实施例以采集管理节点集群与存储节点集群之间的拓扑信息为例，对运维服务器从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点的过程进行描述，如图3所示，包括如下步骤：

步骤301：从管理节点集群中获取未掉线的管理节点作为采集节点。

在一实施例中，可以通过获取本运维服务器与管理节点集群中每个管理节点之间的拓扑信息，并依据该拓扑信息获取未掉线的管理节点作为采集节点。

其中，可以依据拓扑信息中的丢包率判断是否掉线，即将丢包率小于某一阈值的管理节点确定为未掉线，否则确定为掉线。该阈值可以根据实践经验设置。如上述图2B所示的丢包率，IP为10.192.81.92的节点和IP为10.192.81.93的节点的丢包率均为0，表示两节点均未掉线。

在一实施例中，通常管理节点集群中所有管理节点会选举出一个主管理节点，通过为该主管理节点映射出一个虚拟地址，并将该虚拟地址作为管理节点集群的地址，从而运维服务器可以利用该虚拟地址管理管理节点集群中的管理节点。其中，该虚拟地址为云存储虚拟IP。

基于此，针对获取本运维服务器与管理节点集群中每个管理节点之间的拓扑信息的过程，运维服务器可以先直接采集与管理节点集群之间的拓扑信息，并依据该拓扑信息判断本运维服务器与管理节点集群之间是否连通，若连通，则再将虚拟地址所映射的主管理节点作为采集节点和其他管理节点作为被采集节点，并将采集节点的地址和各被采集节点的地址发送至采集节点，以由采集节点采集各被采集节点的拓扑信息并返回至本运维服务器。

其中，采集节点为主管理节点，被采集节点为除主管理节点之外的其他管理节点，采集方式与上述步骤202描述的采集方式相同。

在一可选实现方式中，如上述图2C所示，针对获取本运维服务器与管理节点集群中每个管理节点之间的拓扑信息的过程，如果主管理节点上的agent模块异常，则运维服务器在发送包含主管理节点的虚拟地址和其他管理节点的地址的HTTP请求后，接收的是错误码应答，此时，运维服务器可以直接采集与每个管理节点之间的拓扑信息，以依据拓扑信息获取未掉线的管理节点。

步骤302：针对每个采集节点，从存储节点集群中为该采集节点分配需采集的存储节点，并将分配的存储节点作为需该采集节点采集的至少一个被采集节点。

在一实施例中，可以依据采集节点的数量和所有存储节点的数量为每个采集节点分配需采集的存储节点。

示例性的，假设采集节点的数量为3个，所有存储节点的数量为13个，所有存储节点的数量/采集节点的数量为4余1，从而，为每个采集节点先分配4个存储节点，然后将剩余的1个存储节点随机分配到某一采集节点上。

至此，完成上述图3所示实施例的流程，在采集管理节点集群与存储节点集群之间的拓扑信息时，通过将运维服务器的采集压力分摊到各个未掉线的管理节点上，以由管理节点返回采集的拓扑信息，降低运维服务器的采集压力。并且通过为每个管理节点均分配需采集的存储节点，还可以均衡单个节点的采集压力，可进一步提升采集效率和采集准确性。

并且在降低运维服务器采集压力提高采集效率的同时，也提升了网络采集的准确性。

图4为本申请根据图2A所示实施例示出的又一种网络拓扑信息采集方法的实施例流程图，基于上述图2A所示实施例的基础上，本实施例以采集存储节点集群中各存储节点之间的拓扑信息为例，对运维服务器从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点的过程进行描述，如图4所示，包括如下步骤：

步骤401：依据已存储的管理节点集群与存储节点集群之间的拓扑信息，获取业务口未掉线的存储节点。

在一实施例中，在采集存储节点之间的拓扑信息时，运维服务器需要利用存储节点的业务口接收本运维服务器下发的采集计划，因此运维服务器需要依据本地已存储的管理节点集群与存储节点集群之间的拓扑信息获取业务口未掉线的存储节点。

其中，获取业务口未掉线的存储节点的原理，可以与上述步骤301中获取未掉线的管理节点的原理相同。

步骤402：若业务口未掉线的存储节点为1个，则将该存储节点作为采集节点，并将所述存储节点集群中的其他存储节点作为被采集节点。

步骤403：若业务口未掉线的存储节点为多个，则对多个业务口未掉线的存储节点进行分组，每个分组至少包括两个存储节点。

步骤404：针对每个分组，从该分组中选择一个存储节点作为采集节点，并将该分组中其他存储节点作为被采集节点。

针对上述步骤403和步骤404的过程，分组方式可以采用预先设置分组中存储节点的数量的方式，或者也可以采用预先设置分组数量的方式。

示例性的，以每个分组数量为2个存储节点为例，每个分组中分配两个存储节点，一个作为采集节点，另一个作为被采集节点。

需要说明的是，在采集存储节点集群中各存储节点之间的拓扑信息时，由于存储节点的数据口之间均有数据交互，运维服务器在判断某存储节点的数据口是否掉线时，需要依据该数据口与其他未掉线数据口之间的拓扑信息判断，而首次分组采集过程，可能无法得到所有存储节点的数据口状态。因此，运维服务器需要至少向存储节点集群下发两次采集计划，才能判断各个存储节点的数据口是否掉线。

例如，假设分组中的2个存储节点之间的拓扑信息中的丢包率为1，可能是2个存储节点的数据口均掉线了，也可能是其中一个存储节点的数据口掉线了，因此这2个存储节点的数据口状态未知。

又例如，假设分组中2个存储节点之间的拓扑信息中的丢包率为0，则可以直接确定这2个存储节点的数据口均未掉线。

基于此，运维服务器在接收到各分组中采集节点返回的拓扑信息后，可以依据各分组中采集节点与被采集节点之间的拓扑信息，判断是否存在数据口状态未知的存储节点，若存在，则将数据口状态未知的存储节点作为被采集节点，并从数据口未掉线的存储节点中选择一个存储节点作为采集节点，以进行第二次采集，进而运维服务器在接收到采集节点与被采集节点之间的拓扑信息后，由于此次采集节点的数据口未掉线，依据该拓扑信息便可直接判断出被采集节点的数据口是否掉线。

至此，完成上述图4所示实施例的流程，在采集存储节点集群中存储节点之间的拓扑信息时，也是通过将运维服务器的采集压力分摊到各个业务口未掉线的存储节点上，以由存储节点返回采集的拓扑信息，降低运维服务器的采集压力。并且通过将存储节点分组进行采集，可以均衡单个节点的采集压力，可进一步提升采集效率和采集准确性。

基于上述所示实施例，本申请还提出了一种网络拓扑信息采集系统，包括：

运维服务器，用于从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点，将所述采集节点的地址和各被采集节点的地址发送至所述采集节点；

所述采集节点，用于将所述采集节点的地址作为源地址和各被采集节点的地址作为目的地址传入预设脚本并执行所述预设脚本，以批量采集各被采集节点与采集节点之间的拓扑信息；

所述运维服务器，还用于接收来自所述采集节点采集的各被采集节点与采集节点之间的拓扑信息并存储。

在一可选实现方式中，所述节点集群包含管理节点集群和存储节点集群；

当采集管理节点集群与存储节点集群之间的拓扑信息时，所述运维服务器，具体用于在从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点过程中，从所述管理节点集群中获取未掉线的管理节点作为采集节点；针对每个采集节点，从所述存储节点集群中为该采集节点分配需采集的存储节点，并将分配的存储节点作为需该采集节点采集的至少一个被采集节点。

在一可选实现方式中，所述运维服务器，具体用于在从所述管理节点集群中获取未掉线的管理节点作为采集节点过程中，获取本运维服务器与所述管理节点集群中每个管理节点之间的拓扑信息；依据所述拓扑信息获取未掉线的管理节点作为采集节点。

在一可选实现方式中，所述管理节点集群中的每个管理节点包含业务口；所述存储节点集群中的每个存储节点包含业务口和数据口；

当采集管理节点集群与存储节点集群之间的拓扑信息时，所述采集节点的地址为采集节点业务口的地址，所述被采集节点的地址为被采集节点业务口的地址。

在一可选实现方式中，当采集存储节点集群中各存储节点之间的拓扑信息时，所述采集节点的地址为采集节点数据口的地址，所述被采集节点的地址为被采集节点数据口的地址；

所述运维服务器，具体用于在从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点过程中，依据已存储的管理节点集群与存储节点集群之间的拓扑信息，获取业务口未掉线的存储节点；若业务口未掉线的存储节点为1个，则将该存储节点作为采集节点，并将所述存储节点集群中的其他存储节点作为被采集节点；若业务口未掉线的存储节点为多个，则对多个业务口未掉线的存储节点进行分组，每个分组至少包括两个存储节点；针对每个分组，从该分组中选择一个存储节点作为采集节点，并将该分组中其他存储节点作为被采集节点。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (8)

1.一种网络拓扑信息采集方法，其特征在于，所述方法包括：

运维服务器从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点，包括：所述节点集群包含管理节点集群和存储节点集群，当采集管理节点集群与存储节点集群之间的拓扑信息时，从所述管理节点集群中获取未掉线的管理节点作为采集节点；针对每个采集节点，从所述存储节点集群中为该采集节点分配需采集的存储节点，并将分配的存储节点作为需该采集节点采集的至少一个被采集节点；

将所述采集节点的地址和各被采集节点的地址发送至所述采集节点；

所述采集节点将所述采集节点的地址作为源地址和各被采集节点的地址作为目的地址传入预设脚本并执行所述预设脚本，以批量采集各被采集节点与采集节点之间的拓扑信息；

所述运维服务器接收来自所述采集节点采集的各被采集节点与采集节点之间的拓扑信息并存储。

2.根据权利要求1所述的方法，其特征在于，运维服务器从所述管理节点集群中获取未掉线的管理节点作为采集节点，包括：

获取本运维服务器与所述管理节点集群中每个管理节点之间的拓扑信息；

依据所述拓扑信息获取未掉线的管理节点作为采集节点。

3.根据权利要求1所述的方法，其特征在于，所述管理节点集群中的每个管理节点包含业务口；所述存储节点集群中的每个存储节点包含业务口和数据口；

当采集管理节点集群与存储节点集群之间的拓扑信息时，所述采集节点的地址为采集节点业务口的地址，所述被采集节点的地址为被采集节点业务口的地址。

4.根据权利要求3所述的方法，其特征在于，当采集存储节点集群中各存储节点之间的拓扑信息时，所述采集节点的地址为采集节点数据口的地址，所述被采集节点的地址为被采集节点数据口的地址；

运维服务器从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点，包括：

依据已存储的管理节点集群与存储节点集群之间的拓扑信息，获取业务口未掉线的存储节点；

若业务口未掉线的存储节点为1个，则将该存储节点作为采集节点，并将所述存储节点集群中的其他存储节点作为被采集节点；

若业务口未掉线的存储节点为多个，则对多个业务口未掉线的存储节点进行分组，每个分组至少包括两个存储节点；

针对每个分组，从该分组中选择一个存储节点作为采集节点，并将该分组中其他存储节点作为被采集节点。

5.一种网络拓扑信息采集系统，其特征在于，所述系统包括：

运维服务器，用于从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点，包括：所述节点集群包含管理节点集群和存储节点集群，当采集管理节点集群与存储节点集群之间的拓扑信息时，从所述管理节点集群中获取未掉线的管理节点作为采集节点；针对每个采集节点，从所述存储节点集群中为该采集节点分配需采集的存储节点，并将分配的存储节点作为需该采集节点采集的至少一个被采集节点；将所述采集节点的地址和各被采集节点的地址发送至所述采集节点；

所述采集节点，用于将所述采集节点的地址作为源地址和各被采集节点的地址作为目的地址传入预设脚本并执行所述预设脚本，以批量采集各被采集节点与采集节点之间的拓扑信息；

所述运维服务器，还用于接收来自所述采集节点采集的各被采集节点与采集节点之间的拓扑信息并存储。

6.根据权利要求5所述的系统，其特征在于，所述运维服务器，具体用于在从所述管理节点集群中获取未掉线的管理节点作为采集节点过程中，获取本运维服务器与所述管理节点集群中每个管理节点之间的拓扑信息；依据所述拓扑信息获取未掉线的管理节点作为采集节点。

7.根据权利要求5所述的系统，其特征在于，所述管理节点集群中的每个管理节点包含业务口；所述存储节点集群中的每个存储节点包含业务口和数据口；

当采集管理节点集群与存储节点集群之间的拓扑信息时，所述采集节点的地址为采集节点业务口的地址，所述被采集节点的地址为被采集节点业务口的地址。

8.根据权利要求7所述的系统，其特征在于，当采集存储节点集群中各存储节点之间的拓扑信息时，所述采集节点的地址为采集节点数据口的地址，所述被采集节点的地址为被采集节点数据口的地址；

所述运维服务器，具体用于在从节点集群中选择采集节点和需该采集节点采集的至少一个被采集节点过程中，依据已存储的管理节点集群与存储节点集群之间的拓扑信息，获取业务口未掉线的存储节点；若业务口未掉线的存储节点为1个，则将该存储节点作为采集节点，并将所述存储节点集群中的其他存储节点作为被采集节点；若业务口未掉线的存储节点为多个，则对多个业务口未掉线的存储节点进行分组，每个分组至少包括两个存储节点；针对每个分组，从该分组中选择一个存储节点作为采集节点，并将该分组中其他存储节点作为被采集节点。

Images