CN119341896B - 业务集群的处理方法、装置、设备、介质及程序产品 - Google Patents
业务集群的处理方法、装置、设备、介质及程序产品 Download PDFInfo
- Publication number
- CN119341896B CN119341896B CN202411892142.3A CN202411892142A CN119341896B CN 119341896 B CN119341896 B CN 119341896B CN 202411892142 A CN202411892142 A CN 202411892142A CN 119341896 B CN119341896 B CN 119341896B
- Authority
- CN
- China
- Prior art keywords
- path
- abnormal
- service
- network element
- communication
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请实施例公开了一种业务集群的处理方法、装置、设备、介质及程序产品。其中的方法包括:获取业务集群中多个业务流的第一通信元素组;获取业务集群中异常业务设备的第二通信元素组;基于第一通信元素组与第二通信元素组,从业务集群中筛选出异常业务流;根据异常业务流的源端对应的GPU卡和目的端对应的GPU卡,确定异常业务流的通信路径;对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息。采用本申请实施例能够显著降低业务集群在异常排查期间的等待时间,从而提升任务执行效率。
Description
技术领域
本申请涉及计算机技术领域,尤其涉及通信领域,具体涉及一种业务集群的处理方法、装置、设备、介质及程序产品。
背景技术
业务集群是包括大量业务设备和网元设备的网络集群。随着科学技术的快速发展,任务往往需要巨大的算力支持,因此任务执行所使用的高性能网络集群往往组网规模巨大,设备和链路条数多,导致故障频率高,任务无法长时间稳定运行。
经实践发现,当业务集群中的任务执行发生异常时,现有主流方案是通过人工检测来定位业务集群中的异常原因,如人工采集业务集群中每个业务设备的设备日志并告警逐台设备对比分析;这导致定界或定位业务集群中的异常原因所需时间较长,业务集群在异常排查期间的等待将造成大量算力流失,降低任务执行效率。
发明内容
本申请实施例提供一种业务集群的处理方法、装置、设备、介质及程序产品,能够显著降低业务集群在异常排查期间的等待时间,从而提升任务执行效率。
一方面,本申请实施例提供了一种业务集群的处理方法,业务集群中包括多个业务设备和多个网元设备,任意两个业务设备之间通过至少一个网元设备进行通信连接;每个业务设备中包括至少一个GPU卡;该方法包括:
获取业务集群中多个业务流的第一通信元素组,业务流是指从源端的业务设备中一个GPU卡,流向目的端的业务设备中一个GPU卡的数据流;第一通信元素组包括业务流的源端对应的GPU卡的标识和目的端对应的GPU卡的标识;
获取业务集群中异常业务设备的第二通信元素组,第二通信元素组包括异常业务设备中异常GPU卡的标识,以及与异常GPU卡进行通信的GPU卡的标识;
基于第一通信元素组与第二通信元素组,从业务集群中筛选出异常业务流;
根据异常业务流的源端对应的GPU卡和目的端对应的GPU卡,确定异常业务流的通信路径,通信路径中包括异常业务流依次经过的多个目标网元设备;
对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息。
另一方面,本申请实施例提供了一种业务集群的处理装置,业务集群中包括多个业务设备和多个网元设备,任意两个业务设备之间通过至少一个网元设备进行通信连接;每个业务设备中包括至少一个GPU卡;该装置包括:
获取单元,用于获取业务集群中多个业务流的第一通信元素组,业务流是指从源端的业务设备中一个GPU卡,流向目的端的业务设备中一个GPU卡的数据流;第一通信元素组包括业务流的源端对应的GPU卡的标识和目的端对应的GPU卡的标识;
获取单元,还用于获取业务集群中异常业务设备的第二通信元素组,第二通信元素组包括异常业务设备中异常GPU卡的标识,以及与异常GPU卡进行通信的GPU卡的标识;
处理单元,用于基于第一通信元素组与第二通信元素组,从业务集群中筛选出异常业务流;
处理单元,还用于根据异常业务流的源端对应的GPU卡和目的端对应的GPU卡,确定异常业务流的通信路径,通信路径中包括异常业务流依次经过的多个目标网元设备;
处理单元,还用于对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息。
在一种实现方式中,业务集群中包括X级组网,X级组网中包括层级分布的X层子网络,每层子网络中包括多个网元设备,X为整数且X≥2;处理单元,用于根据异常业务流的源端对应的GPU卡和目的端对应的GPU卡,确定异常业务流的通信路径时,具体用于:
根据异常业务流的源端对应的GPU卡,异常业务流的目的端对应的GPU卡,以及,X级组网中每层子网络中的网元设备,得到X层子网络之间的多个路径组;每个路径组中包括一个或多个等价路径,等价路径的两个路径端点分别为相邻的两层子网络中的网元设备;
根据多个路径组和异常业务流在X层子网络之间的流向,构建有向图;
对有向图进行路径搜索处理,得到异常业务流的通信路径。
在一种实现方式中,处理单元,用于根据异常业务流的源端对应的GPU卡,异常业务流的目的端对应的GPU卡,以及,X级组网中每层子网络中的网元设备,得到X层子网络之间的多个路径组时,具体用于:
根据异常业务流的源端对应的GPU卡的标识,在X级组网中的第一层子网络中确定异常业务流的起始网元设备;
根据异常业务流的目的端对应的GPU卡的标识,在X级组网中的第一层子网络中确定异常业务流的终点网元设备;
基于起始网元设备和终点网元设备,在X层子网络中进行路径连接处理,得到X层子网络之间的多个路径组。
在一种实现方式中,X层子网络中的任一层子网络表示为第i层子网络,i为整数且1≤i≤X;处理单元,用于基于起始网元设备和终点网元设备,在X层子网络中进行路径连接处理,得到X层子网络之间的多个路径组时,具体用于:
当i=1时,根据起始网元设备和第i+1层子网络,按照边界网关协议查询起始网元设备对应的多个第一路径组;每个第一路径组的对端设备为第i+1层子网络中的一个网元设备;
令i=i+1,若i=X,则根据每个第一路径组的对端设备和终点网元设备,按照边界网关协议查询每个第一路径组的对端设备分别对应的第X路径组;第X路径组的对端设备为终点网元设备;
其中,X层子网络之间的多个路径组包括:多个第一路径组,以及每个第一路径组的对端设备分别对应的第X路径组。
在一种实现方式中,处理单元,还用于:
令i=i+1,若i<X,则根据多个第i-1路径组中每个第i-1路径组的对端设备和第i+1层子网络,按照边界网关协议查询每个第i-1路径组的对端设备分别对应的多个第i路径组;
当i=X时,根据每个第X-1路径组的对端设备和第X-1层子网络,按照边界网关协议查询每个第X-1路径组的对端设备分别对应的多个第X路径组;
令i=i-1,若i>2,则根据多个第2X-i-1路径组中每个第2X-i-1路径组的对端设备和第i-1层子网络,按照边界网关协议查询每个第i+1路径组的对端设备分别对应的多个第2X-i路径组;第2X-i路径组的对端设备为第i-1层子网络中的一个网元设备;
当i=2时,根据每个第2X-i-1路径组的对端设备和终点网元设备,按照边界网关协议查询每个第2X-i-1路径组的对端设备分别对应的第2X-2路径组;第2X-2路径组的对端设备为终点网元设备;
其中,X层子网络之间的多个路径组包括:多个第一路径组、多个第i路径组、多个第2X-i路径组以及第2X-i路径组的对端设备分别对应的第2X-2路径组。
在一种实现方式中,处理单元,用于根据多个路径组和异常业务流在X层子网络之间的流向,构建有向图时,具体用于:
将多个路径组中的多个网元设备作为有向图的节点;
按照异常业务流在X层子网络之间的流向,将多个节点进行连接,得到有向图。
在一种实现方式中,有向图中包括起始节点、终点节点和X-1个中间层,每个中间层中包括一个或多个中间节点,X-1个中间层中的任一个中间层表示为第j个中间层,j为整数且1≤j≤X-1;处理单元,用于对有向图进行路径搜索处理,得到异常业务流的通信路径时,具体用于:
当j=1时,从起始节点开始,遍历起始节点和第一个中间层中的各中间节点之间的路径,得到起始节点对应的多个第一权重值;一个第一权重值为起始节点和第一个中间层中一个中间节点之间路径的权重值;
令j=j+1,当j>X-1时,分别计算第j-1个中间层中各中间节点和终点节点之间路径的第X权重值;一个第X权重值为第j-1个中间层中一个中间节点和终点节点之间路径的权重值;
基于多个第一权重值和第X权重值,从有向图中确定出最短路径作为异常业务流的通信路径。
在一种实现方式中,处理单元,还用于:
令j=j+1,若j≤X-1,则从第j-1个中间层中各中间节点开始,遍历第j个中间层中各中间节点和第j-1个中间层中各中间节点之间的路径,得到第j个中间层中各中间节点对应的多个第j权重值;
基于多个第一权重值,第j个中间层中各中间节点对应的多个第j权重值以及第X权重值,从有向图中确定出最短路径作为异常业务流的通信路径。
在一种实现方式中,获取单元,用于获取业务集群中异常业务设备的第二通信元素组时,具体用于:
获取业务集群上异常业务设备上报的一个或多个第二通信元素组;
对一个或多个第二通信元素组进行数据去重处理,得到去重处理后的第二通信元素组。
在一种实现方式中,处理单元,用于对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息时,具体用于:
获取一个或多个检测指标;检测指标包括以下至少一种:流量拥塞指标和拥塞程度指标;
采用一个或多个检测指标中的每个检测指标,对多个目标网元设备中的每个目标网元设备进行指标分析处理,得到每个目标网元设备在每个检测指标下的指标信息;
根据每个目标网元设备在每个检测指标下的指标信息,对异常业务流进行异常分析,得到异常业务流的异常信息;异常业务流的异常信息用于描述异常业务流的异常原因。
在一种实现方式中,网元设备中包括芯片;处理单元,还用于:
获取参考路径,参考路径中包括:异常业务流的源端对应的GPU卡,和异常业务流的目的端对应的GPU卡之间的业务流,所经过的多个参考网元设备;参考路径是芯片基于异常业务流的第一通信元素组所规划得到的;
将参考路径上的多个参考网元设备,和通信路径上的多个目标网元设备进行比较,得到比较结果;
若比较结果为:多个参考网元设备和多个目标网元设备相同,且多个参考网元设备之间的通信连接顺序和多个目标网元设备之间的通信连接顺序相同,则触发执行对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息的步骤;
若比较结果为:多个参考网元设备和多个目标网元设备不相同,或者多个参考网元设备之间的通信连接顺序和多个目标网元设备之间的通信连接顺序不相同,则对芯片进行异常原因分析,得到芯片的异常信息。
在一种实现方式中,处理单元,还用于:
根据异常业务流的异常信息,对业务集群进行集群调整处理,得到调整后的业务集群;
其中,调整后的业务集群不存在异常业务流。
在一种实现方式中,处理单元,还用于根据异常业务流的异常信息,对业务集群进行集群调整处理,得到调整后的业务集群时,具体用于:
若异常业务流的异常信息所描述的异常原因为,异常业务流的源端对应的GPU卡故障,则在业务集群中对异常业务流的源端对应的GPU卡进行替换处理,得到替换后的业务集群。
另一方面,本申请实施例提供了一种计算机设备,该设备包括:
处理器,用于加载并执行计算机程序;
计算机可读存储介质,该计算机可读存储介质中存储有计算机程序,该计算机程序被处理器执行时,实现上述业务集群的处理方法。
另一方面,本申请实施例提供了一种计算机可读存储介质,计算机可读存储介质存储有计算机程序,该计算机程序适于由处理器加载并执行上述业务集群的处理方法。
另一方面,本申请实施例提供了一种计算机程序产品,计算机程序产品包括计算机指令,计算机指令被处理器执行时实现上述的业务集群的处理方法。
在本申请实施例中,在业务集群存在异常的情况下,计算机设备会获取异常时段内该业务集群中多个业务流的第一通信元素组,该第一通信元素组中包括业务流的源端对应的GPU卡的标识和目的端对应的GPU卡的标识。同时,计算机设备还获取业务集群中异常业务设备的第二通信元素组,该第二通信元素组中包括异常业务设备中异常GPU卡的标识以及与异常GPU卡进行通信的GPU卡的标识。由于异常时段内业务集群中存在通信的所有业务设备产生的业务流均被采集,因而计算机设备基于所有业务设备产生的业务流的第一通信元素组,和异常业务设备产生的第二通信元素组,就可以从业务集群中的全部业务流中筛选出存在异常的异常业务流;将针对所有业务设备的故障排查范围缩小至针对异常业务流的故障排查范围,极大地缩短了异常原因分析所耗费的时间。进一步,计算机设备根据异常业务流的源端对应的GPU卡和目的端对应的GPU卡,就能够从业务集群中还原出异常业务流依次经过的多个目标网元设备所组成的通信路径;相比于需要对业务集群中每个业务设备进行设备分析而言,将故障排除范围进一步缩小到针对异常业务流的通信路径中包括的多个目标网元设备,计算机设备只需对多个目标网元设备进行设备分析处理,能够快速分析得到异常业务流的异常信息。由此可见,本申请实施例有效的将业务集群存在异常时异常业务流的通信路径还原出来,相比于故障产生时对业务集群中全部业务设备进行分析而言,将需要排查的故障排查范围域(或称为故障域)由参与业务集群中任务的全部业务设备,缩小到在异常时间段内仅存在通信关系且上传第二通信元素组的异常业务设备,具体是异常业务设备产生的异常业务流的通信路径(即根因GPU卡的通信路径);极大地提高了业务集群中故障的处理效率,避免业务集群中业务设备的算力浪费的同时,节省任务执行的成本。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1a是一种二级组网的网络架构示意图;
图1b是一种三级组网的网络架构示意图;
图2a是一种现有主流的人工采集任务进行故障排查的流程示意图;
图2b是本申请一个示例性实施例提供的一种故障排查的流程示意图;
图3是本申请一个示例性实施例提供的一种业务集群的处理系统的架构示意图;
图4是本申请一个示例性实施例提供的一种业务集群的处理方法的流程示意图;
图5是本申请一个示例性实施例提供的一种对第一通信元素组和第二通信元素组进行比较的示意图;
图6a是本申请一个示例性实施例提供的一种调用数据预处理模块构建有向图的示意图;
图6b是本申请一个示例性实施例提供的一种调用数据预处理模块还原异常业务流的通信路径的流程示意图;
图7是本申请一个示例性实施例提供的一种二级组网下确定X层子网络之间的多个路径组的示意图;
图8是本申请一个示例性实施例提供的一种三级组网下确定X层子网络之间的多个路径组的示意图;
图9是本申请一个示例性实施例提供的一种有向图的示意图;
图10a是本申请一个示例性实施例提供的一种在二级组网对应的有向图中确定出最短路径的示意图;
图10b是本申请一个示例性实施例提供的一种在三级组网对应的有向图中确定出最短路径的示意图;
图11是本申请一个示例性实施例通过的一种快速恢复异常业务流的通信路径的整体流程的示意图;
图12是本申请一个示例性实施例提供的另一种业务集群的处理方法的流程示意图;
图13a是本申请一个示例性实施例提供的一种在有向图中找到异常业务流的端到端路径进行可视化展示的示意图;
图13b是本申请一个示例性实施例提供的一种在有向图中未找到异常业务流的端到端路径进行可视化展示的示意图;
图14是本申请一个示例性实施例提供的一种使用流量拥塞指标(Packet FlowContex,PFC)和拥塞程度指标(Explicit Congestion Notification,ECN),对异常业务流的端到端路径上的目标网元设备进行设备分析处理的结果示意图;
图15是本申请一个示例性实施例提供的一种业务集群的处理装置的结构示意图;
图16是本申请一个示例性实施例提供的一种计算机设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
在本申请实施例中,提供了一种业务集群的处理方案;该方案能够在业务集群存在异常时快速定位可能存在异常的异常业务流,并还原该异常业务流的通信路径,只需针对异常业务流的通信路径进行异常原因分析,极大地缩短了故障排查时间,提升了故障排查效率,从而提高业务集群中任务的执行效率。
业务集群是指在局域网或互联网中连接多个服务器,通过软件或硬件在多个服务器之间实现资源共享和任务分配,共同完成相同业务中任务的高性能计算系统。其中,业务是指为实现某项目标而开展的一系列活动,任务是具体的活动内容或目标;业务可以看作是多个任务组成的集合,每个任务都是业务的一部分。在业务集群中,支持将业务的多个任务分配到不同的服务器中进行独立处理,并收集各服务器针对不同任务执行所得到的中间结果,对中间结果进行汇总,得到业务的执行结果。根据业务领域不同,用于实现业务的业务集群有所差异;业务集群可以包括但是不限于:模型训练业务对应的模型训练集群、数据处理业务对应的数据处理集群以及资源管理业务对应的资源处理集群,等等;在本申请实施例中,以业务集群为模型训练集群为例对业务集群的处理方案进行阐述,特在此说明。
业务集群中包括:用于执行任务(如模型训练集群中执行的模型训练任务)的多个业务设备和提供业务设备之间连接通信的多个网元设备;业务集群中的任意两个业务设备之间通过至少一个网元设备进行通信连接。下面对业务集群中的业务设备和网元设备等相关概念进行介绍,其中:
(1)业务设备。
业务设备即为前述提及的用于执行任务的服务器。业务集群为模型训练集群时,业务集群中的业务设备是用于进行模型训练的高性能计算机服务器;这些服务器通常具备高性能计算能力、大容量存储空间和高速网络连接,能够满足大规模机器学习和深度学习任务的需求。其中,业务集群中每个业务设备中包括或配置有至少一个GPU(GraphicsProcessing Unit,图形处理单元)网卡(或简称为GPU卡);业务设备中配置的GPU网卡是业务设备执行任务的关键组件,如用于加速计算密集型任务的执行,实现图像识别、目标检测和图像等任务,以及并行处理文本数据实现自然语言处理等。业务设备执行任务主要依赖于该业务设备中部署的GPU网卡,因此业务设备也可以称为GPU设备。
(2)网元设备。
网元设备是在业务集群中用于传输信息的网络设备;网元设备包括但是不限于:服务器、路由器、交换器或其他具备信息传输能力的设备。在本申请实施例中,支持给网元设备划分层级或层次,不同层级的网元设备之间可以进行相互连接,用于在业务集群中的业务设备之间传输信息。本申请实施例支持将业务集群中的多个网元设备划分层级后的网络称为X级组网,X级组网中包括层级分布的X层子网络,每层子网络中包括多个网元设备;X为整数且X≥2。X层子网络之间层级分布指的是X层子网络按照划分维度(如功能维度)依次排列为多层;每层子网络承担特定的功能,从而构建一个高效且可靠的网络系统。
业务集群中的任意两个业务设备通过至少一个网元设备进行通信连接,具体是通过X级组网进行通信连接。在本申请实施例中,将业务集群中任意两个业务设备通过X级组网进行通信连接时传输的数据称为业务流,该业务流可以理解为一组有序、有起点和终点的字节数据序列。在业务集群中两个业务设备之间传输的业务流的源端(source,缩写为src)和目的端(Destination,缩写为dst)均为业务设备中集成的GPU网卡。考虑到业务流的源端和目的端均为业务设备中集成的GPU网卡,因此,在业务集群中任意两个业务设备通过X级组网进行通信时传输的业务流也可以理解为:从源端的业务设备中的一个GPU网卡,流向目的端的业务设备中的一个GPU网卡的数据流。其中,将业务流传输中发送业务流的一侧称为源端,将接收业务流的一侧称为目的端。
其中,业务流是依据通信元素组在业务集群中进行传输。如前述,业务流实质是字节数据序列,该字节数据序列中包括业务流的通信元素组,该通信元素组中包括与业务流的传输相关的多个字段。通信元素组包括五元组,业务流的五元组中包括:源端的业务设备中发出业务流的GPU卡的标识、目的端的业务设备中接收业务流的GPU卡的标识、源端的业务设备中发出业务流的GPU卡所使用的端口(port)的端口号、目的端的业务设备中接收业务流的GPU卡所使用的端口的端口号、以及源端的业务设备和目的端的业务设备进行数据传输所使用的通信协议的协议号。进一步的,根据通信元素组中包括的元素或字段数量不同,通信元素组还可以包括三元组或二元组等。三元组中包括:源端的业务设备中发出业务流的GPU卡的标识、目的端的业务设备中接收业务流的GPU卡的标识、源端的业务设备中发出业务流的GPU卡所使用的端口的端口号。二元组(可以表示为(SIP/DIP),SIP为源端对应的GPU卡的标识,DIP为目的端对应的GPU卡的标识)中包括:源端的业务设备中发出业务流的GPU卡的标识、目的端的业务设备中接收业务流的GPU卡的标识。为便于阐述,可以将发送业务流的GPU网卡称为源GPU网卡,该源GPU网卡的标识称为源GPU卡标识;将接收业务流的GPU网卡称为目的GPU网卡,该目的GPU网卡的标识称为目的GPU卡标识;将发出业务流的GPU卡所使用的端口称为源端口,端口号称为源端口号,将接收业务流的GPU卡的端口称为目的端口,端口号称为目的端口号。
在本申请实施例中,业务集群中的业务设备之间通过直接存储器访问技术(Remote Direct Memory Access,RDMA)进行业务流的传输。直接存储器访问技术是一种网络通信技术,允许业务设备在业务集群中通过网元设备直接访问其他业务设备的内存,而无需经过业务设备中部署的操作系统。也就是说,业务集群中的任意两个业务设备之间允许业务流直接从一个业务设备的内存,通过网元设备传输到另一个业务设备的内存,业务流的传输无需两个业务设备的操作系统的介入。由于业务流传输绕过业务设备的操作系统,显著提高业务集群中的业务流传输速度,降低网络延迟,同时减轻业务设备的中央处理器(Central Processing Unit,CPU)和操作系统的负担。
基于上述描述可知,根据X的取值不同,业务集群的网络架构的复杂程度也有所不同。例如,X=2时,业务集群中的二级组网的网络架构示意图可以参见图1a;如图1a所示,二级组网中包括两层子网络,分别为第一层子网络和第二层子网络,每层子网络中均包含有网元设备。其中,第一层子网络中的网元设备用于直接和业务集群中的业务设备进行通信连接,以及用于和第二层子网络中的网元设备进行通信连接,以便于业务设备中发出的业务流能够经由第一层子网络中的网元设备传输至网络中;第二层子网络中的网元设备用于和第一层子网络中的网元设备进行通信连接,以便于将业务流在网络中进行传输。在本申请实施例中,第一层子网络中的网元设备称为GPULA(GPU Load Advisor,GPU负载引导)设备,第二层子网络中的网元设备称为GPULC(GPU Load Controller,GPU负载控制)设备;GPULA设备和GPULC设备之间协同工作,帮助业务集群更好地管理资源,优化集群性能,确保业务集群中任务的顺利执行。
再如,X=3时,业务集群中的三级组网的网络架构示意图可以参见图1b;如图1b所示,三级组网中包括三层子网络,分别为第一层子网络、第二层子网络和第三层子网络,每层子网络中均包含有网元设备。其中,第一层子网络和第二层子网络的相关内容和二级组网中的第一层子网络和第二层子网络是相同的,在此不做赘述。三级组网中还包括第三层子网络,第三层子网络中的网元设备称为SGLC(Super GPULC,超级GPU负载控制)设备;该第三层子网络中的网元设备用于和第二层子网络中的网元设备进行通信连接,以实现业务流在网络中的传输。
为便于阐述,后续以业务集群中的X级组网为二级组网或三级组网为例,对本申请实施例提供的业务集群的处理方案进行介绍,特在此说明。以X级组网为图1a所示的二级组网为例;业务集群中的业务设备1001需要向业务设备1002发送信息时,业务设备1001通过其内部部署的一个GPU网卡通过端口将业务流发送至二级组网中第一层子网络中的一个网元设备GPULA。该网元设备GPULA根据路由协议(如边界网关协议(Border GatewayProtocol,BGP))进行路由选择,具体是选择网元设备GPULA和第二层子网络中的一个或多个网元设备GPULC进行通信连接。第二层子网络中接收到业务流的网元设备GPULC,根据业务流中的目的端口字段在第一层子网络中确定能够接收该业务流的网元设备GPULA。再由该网元设备GPULA将业务流传输至业务集群中的业务设备1002,以实现业务设备1001和业务设备1002之间的业务流传输。
在实际应用中,对于业务集群的运维人员而言,其只能知晓和业务设备中的某GPU网卡进行通信连接的第一层子网络中的网元设备,对于X级组网内部的相邻层级的网元设备之间的通信网络路径或链路是无法感知的。也就是说,对于运维人员而言,业务集群内的X级组网内部基本为黑盒状态,导致业务集群存在异常(如出现故障停止执行训练任务,或者任务执行速度显著下降,或者执行结果出现较大偏差等)时,运维人员由于无法感知X级组网之间的通信网络路径,需要人工采集每个业务设备的设备日志,并告警逐台业务设备对比分析来分析异常原因,耗费较大的时间成本,如模型训练任务被中断后耗时基本在24小时以上,导致异常原因排查期间业务设备大量算力流失,浪费算力资源的同时降低任务执行效率。
为缩短业务集群中故障排查时间,提高任务执行效率,本申请实施例提供的业务集群的处理方案,旨在通过网络流量控制技术(Solution for Network Monitoring,sflow)自动计算还原业务集群中GPU网卡之间的通信路径。业务集群的处理方案具体是通过业务集群中的sflow代理采集到存在异常的异常时间段内该业务集群上的RDMA通信数据(如通信元素组),将RDMA通信数据预处理为有向图的结构,进一步对该有向图进行路径搜索(如利用图论中的深度优先遍历搜索算法)找到异常业务流在业务集群中的GPU网卡之间的真实通信网络路径(或称为传输路径或通信路径等等)。如此,从原本黑盒状态的业务集群中可以还原出异常业务流的通信路径,基于该通信路径进行进一步的异常原因分析和排查,有效地克服由于GPU网卡导致任务执行(如AI(Artificial Intelligence,人工智能)模型训练任务的执行)中断所带来的业务设备的低利用率,显著提升业务设备的利用率和算力使用率,如业务设备等待故障排查的时长从24小时缩短到1分钟以内,极大地提升了任务的执行效率,减少了因任务中断导致的资源和成本浪费。
具体实现中,在业务集群中的全部或部分网元设备中部署有sflow代理;sflow技术是一种IEEE(Institute of Electrical and Electronics Engineers,电气电子工程师协会)标准的基于报文采样的网络流量检测技术;通过在网元设备上设置采样率,该sflow代理按照设定的采样率采集流经网元设备的业务流的报文,该报文是传输的数据单元,在本申请实施例中主要是指业务流的第一通信元素组。这样,当业务集群中存在异常情况时,业务集群中的网元设备中的sflow代理采集异常时间段内的多个业务流的第一通信元素组,并将多个业务流中每个业务流的第一通信元素组上报至计算机设备。同时,业务集群中的业务设备中部署有TCCL(Tencent Collective Communication Library,集合通信库)模块,该TCCL模块支持通过异构并行通信技术,实现了GPU卡间数据的高效传输;当业务设备产生异常时,该业务设备中的TCCL模块向计算机设备上报异常业务设备的第二通信元素组;该第二通信元素组中包括异常业务设备中异常GPU卡的标识,以及与该异常GPU卡之间进行通信的GPU卡的标识。
由于异常时段内业务集群中存在通信的所有业务设备产生的业务流均被sflow采集,那么sflow采集的全量业务流中包括异常业务设备发出的异常业务流;因而,计算机设备基于所有业务设备产生的业务流的第一通信元素组,和异常业务设备产生的第二通信元素组,就可以从业务集群中的全部有业务流中筛选出存在异常的异常业务流。计算机设备可以根据异常业务流的源端对应的GPU卡和目的端对应的GPU卡,在X级组网中还原出异常业务流的通信路径,就可以将故障排查范围从全部业务设备缩小至异常业务流的源端和目的端之间的通信路径。计算机设备对异常业务流的通信路径中包括的多个目标网元设备进行设备分析处理,即可以确定异常业务流的异常信息,该异常信息是描述异常业务流产生异常的原因的一段话,如网络原因、目标网元设备故障或者GPU卡故障等。
经实践发现,采用本申请实施例提供的业务集群的处理方案来分析业务集群异常原因时具有明显优势。下面以本申请方案与现有主流业务集群异常分析方案进行比对为例,对本申请实施例的优势进行说明,其中:
现有主流的业务集群异常原因分析方案是,通过人工采集任务执行所涉及到的所有业务设备的告警日志来分析和解决问题。如图2a所示,业务集群异常原因分析方案的过程通常包括:采集设备日志、分析告警信息、逐台设备对比和定界定位等步骤;各步骤的具体实现过程如下:①采集设备日志:运维人员需要登录到业务集群中的每个业务设备上,收集每个业务设备相关的日志文件;该收集过程需要人工实现,可能涉及到大量的业务设备,非常耗时。②分析告警信息:告警信息通常包含了业务设备的运行状态的关键信息;然而由于告警信息可能来自不同的系统和设备,因此需要人工对比和分析,以确定产生问题的某些设备或者系统。③逐台业务设备对比:运维人员需要对比多个业务设备的日志和性能指标,具体需要撰写脚本仔细比对和分析,以便于定位到网络或者业务设备/网元设备问题,找出产生根源的异常业务设备。④定界定位:在确定了可能的异常业务设备后,运维人员还需要进一步分析,以确定问题的具体原因(如业务设备的光模块、PFC反压等),该定界定位过程可能涉及到代码审查、硬件检测等多个方面。由此可见,当业务集群存在异常时,如模型训练集群发生训练中断时,业务设备会产生对应的错误日志,此时需要运维人员手动登录每个业务设备,收集对应的日志文件进行异常业务设备的定界和定位;这导致业务集群中一次普通的任务执行中断耗时通常都在24小时以上,在此期间业务设备和其他计算资源都处于等待状态,导致大量算力流失,影响当前的任务执行的同时,还可能影响到其他依赖这些业务设备执行的项目(如依赖于业务集群执行任务的其他业务)。该现有主流业务集群异常原因分析方案存在如下缺点:①耗时长:如前述由于X级组网之间的通信路径具有黑盒性,导致运维人员需要采集所有参与任务执行的业务设备的日志,涉及大量业务设备,导致从发现异常到最终定位并解决问题,可能需要数小时甚至数天的时间;等待期间内业务设备和其他计算资源都处于闲置状态,浪费业务设备的算力的同时降低任务执行效率。②人工成本高:需要专业的运维人员撰写脚本人工分析和比对所有业务设备的指标信息,从而找到可能的异常业务设备,增加了人力成本。③错误风险高:人工操作和分析过程中可能出现误判或遗漏,导致问题未能得到彻底解决。
本申请实施例提供的业务集群的处理方案,是利用业务集群中原本的sflow来自动采集异常时间段内业务集群中的业务流的第一通信元素组,以及利用业务设备中部署的TCCL模块自动上报的第二通信元素组(TCCL模块上报第二通信元素组的示意图可以参见图2b),来自动定位异常业务流,并根据该异常业务流在业务集群中还原出异常业务流的通信路径;一方面,无需人工收集日志信息,提高了异常排查效率,极大地降低了异常排查成本,另一方面,将运维人员需要排查的故障范围从产生异常时业务集群中存在通信的全部业务设备,缩小为异常业务流的通信路径,运维人员只需要关注异常业务流的通信路径,整体排查故障时间从天级(如以天为单位)缩小到分钟级(如以分钟为单位),能够较快的定位异常问题,实现任务的快速恢复,从而提高任务执行效率。
本申请实施例提出的业务集群的处理方案部署于计算机设备中,该计算机设备是独立于业务集群,用于进行业务集群的异常原因分析的独立设备。当业务集群发生异常情况时业务集群中的sflow代理向该计算机设备上报业务集群中的全量业务流的第一通信元素组,以及异常业务设备中的TCCL模块向该计算机设备上报第二通信元素组;计算机设备在接收到全量业务流的第一通信元素组和异常业务设备的第二通信元素组后,按照业务集群的处理方案的具体实现逻辑将异常业务流的通信路径还原处理,进一步结合基础检测模块等对通信路径中的多个目标网元设备进行设备分析处理,以定界是网络问题或设备问题,如异常业务设备的哪些问题导致的异常等。其中,基础检测模块是具备设备检测能力的专属模块或设备。
为便于理解上述提及的业务集群的处理方案,下面结合图3所示的场景示意图,对本申请实施例涉及的处理系统进行简单介绍。如图3所示,该系统中包括业务集群,业务集群中包括多个业务设备,如业务设备301和业务设备302等,业务集群中还包括X级组网,X级组网为二级组网,且二级组网中每一层子网络中包括多个网元设备,如第一层子网络中包括网元设备303和网元设备304,第二层子网络中包括网元设备305、网元设备306和网元设备307等等。系统中还包括计算机设备308,该计算机设备308可以为终端或服务器。本申请实施例对系统中的业务设备和网元设备的数量不作限定,对计算机设备的设备类型和设备数量也不作限定,如计算机设备可以为单独的服务器和/或终端,或者计算机设备为分布式网络中的单个服务器和/或终端等等。
其中:①计算机设备为终端,终端可以包括但不限于:智能手机(如部署安卓(Android)系统的智能手机,或部署互联网操作系统(Internetworking OperatingSystem,IOS)的智能手机)、平板电脑、便携式个人计算机、移动互联网设备(MobileInternet Devices,MID)、车载设备、头戴设备、智能聊天机器人和飞行器等终端设备,本申请实施例并不对终端设备的类型进行限定,在此说明。②计算机设备为服务器,服务器可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式网络(或称为分布式系统),还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network,CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。③计算机设备包括终端和服务器,也就是说,本申请实施例提供的业务集群的处理方案由终端和服务器共同执行,服务器用于实现业务集群的处理方案的后台逻辑实现,终端可以向运维人员进行数据的可视化输出,如向运维人员输出TCCL模块上报的第二通信元素组,或者向运维人员输出异常业务流的通信路径等,通过可视化的分析过程展示,极大地方便了运维人员对业务集群的故障排查。
需要说明的是,业务集群中的设备(如业务设备或网元设备)和计算机设备之间可以通过有线或无线通信方式进行直接或间接地连接,本申请在此不做限制。
下面结合图3所示的二级组网,对本申请实施例提供的业务集群的处理方案的流程进行简单介绍。具体实现中,假设业务集群为模型训练集群;模型训练集群中的业务设备301和业务设备302之间进行业务流的传输,以实现AI模型训练任务。若在模型训练任务执行的某时间段(称为异常时间段、异常时段)模型训练集群出现异常,如模型训练集群中的业务设备301发生异常时,与该业务设备301进行通信的业务设备302也会出现异常,进而导致整个模型训练集群的训练速度变慢,那么模型训练集群中网元设备(如第一层子网络和第二层子网络中的全部或部分网元设备,如网元设备303、网元设备304、网元设备305、网元设备306和网元设备307)中部署的sflow代理会采集该异常时间段内模型训练集群中存在通信的全部业务设备之间的全量业务流(或称为多个业务流)中每个业务流的第一通信元素组,并将该全量业务流的第一通信元素组的发送至计算机设备308。同时,模型训练集群中的异常业务设备301中的TCCL模块还会将异常业务设备301产生的第二通信元素组上报至计算机设备308。
计算机设备308在获取到多个业务流的第一通信元素组和异常业务设备的第二通信元素组后,基于第一通信元素组和第二通信元素组确定源端对应的GPU卡的标识和目的端对应的GPU卡的标识均相同的第三通信元素组,该第三通信元素组即作为异常业务流的通信元素组。然后,计算机设备根据第三通信元素组,从模型训练集群中还原出异常业务流的通信路径,该通信路径中包括异常业务流在二级组网中异常经过的多个目标网元设备;如通信路径为图3所示的GPULA1→GPULC1→GPULA2,GPULA1、GPULC1和GPULA2为目标网元设备。如此,计算机设备只需要对异常业务流的通信路径进行设备分析处理,即可以得到异常业务流的异常信息,该异常信息描述了模型训练集群中产生异常业务流的异常原因;详细地,计算机设备调用基础检测模块来对通信路径中的每个目标网元设备进行指标分析,并根据分析得到的指标信息(如GPU利用率、RDMA流量和ECN报文等),基于通信路径的设备及接口逐跳进行网络状况关联分析,定位是网络还是设备的问题,有效地将整体排障时间从一天级缩小到分钟级,同时联动业务侧进行模型训练任务的快速恢复执行,提高任务执行效率。
由此可见,本申请实施例引入计算机设备308集成业务集群的处理方案,这样在业务集群存在异常时,通过该计算机设备308可能自动地对业务集群的异常原因进行分析,相比于现有主流方案中需要运维人员手动维护业务集群而言,极大地节省了人工成本和时间成本,且智能化的异常原因分析可以提高异常原因分析的准确性,且利用计算机设备来进行异常原因分析缩短了故障排查时间,从而提高业务集群中的任务执行的效率。
根据上述对本申请实施例提供的业务集群的处理方案和处理系统的简单介绍,还需说明如下几点:
①本申请实施例上述提及的图3所示系统架构是为了更加清楚的说明本申请实施例的技术方案,并不构成对于本申请实施例提供的技术方案的限定。本领域普通技术人员可知,随着系统架构的演变和新业务场景的出现,本申请实施例提供的技术方案对于类似的技术问题,同样适用。也就是说,图3所示的处理系统的架构示意图为示例性架构示意图;在实际应用中,该处理系统所包括的设备数量和种类可以发生变化,本申请实施例对处理系统的架构示意图不作限定。例如,图3所示系统中的计算机设备308的数量可能为多个,多个计算机设备组成分布式系统,通过该分布式系统将本申请实施例提供的业务集群的处理方案的具体实施过程分配到不同的计算机设备中进行执行,有效地提高了业务集群的处理方案的执行效率。
②本申请实施例除了支持使用sflow代理进行第一通信元素组的采集来还原异常业务流的通信路径外,还支持采用其他方式来获取X层子网络之间的路径信息。例如,可以使用INT(Inband-Network Telemetry,带内网络遥测技术)来采集每一对通信会话的路径信息X层子网络之间的路径信息;INT技术主要是通过使用额外的服务器发出探测流,该探测流在业务集群中用来跟随每一条业务流的实施路径,从而实现业务流的路径信息的获取。
③本申请实施例中相关数据收集处理应该严格根据相关法律法规的要求,获取个人信息需得到个人主体的知情或同意(或具备信息获取的合法性基础),并在法律法规及个人信息主体的授权范围内,开展后续数据使用及处理行为。例如,本申请实施例运用到具体产品或技术中时,如计算机设备获取第一通信元素组和第二通信元素组时,需要获得运维人员的许可或者同意,且相关数据的收集、使用和处理(如对业务集群中的异常原因进行分析过程等)需要遵守相关地区的相关法律法规和标准。
基于上述描述的业务集群的处理方案,本申请实施例提出更为详细的业务集群的处理方法,下面将结合附图对本申请实施例提出的业务集群的处理方法进行详细介绍。图4示出了本申请一个示例性实施例提供的一种业务集群的处理方法的流程示意图,该处理方法可以由计算机设备来执行,计算机设备是前述图3所示的计算机设备308,如计算机设备308为终端或服务器。业务集群的处理方法可包括但不限于步骤S401-S405:
S401:获取业务集群中多个业务流的第一通信元素组。
如前述,业务流是指从业务集群中的业务设备中的一个GPU卡,流向至另一个业务设备中的一个GPU卡的数据流;业务流的第一通信元素组是指该业务流的五元组,任一业务流的第一通信元素组可以表示为:(源GPU卡标识,目的GPU卡标识,源端口号,目的端口号,协议号)。在业务集群中X级组网内部之间的通信路径为黑盒的情况下,计算机设备能够通过业务流的第一通信元素组定位该业务流在业务集群中的两端位置,为后续探索该业务流在X级组网中的通信路径给予引导,即有利于后续还原该业务流在X级组网中的通信路径。
具体实现中,在业务集群中的任务执行出现异常时,业务集群的网元设备中部署的sflow代理采集的多个业务流中每个业务流的第一通信元素组,并将每个业务流的第一通信元素组发送至计算机设备,此时计算机设备获取到业务集群中异常时间段内各业务流的第一通信元素组。其中,sflow代理采集的业务流的第一通信元素组包括:业务集群中出现异常的异常时间段内,业务集群中所有参与任务执行并发生通信的业务设备上产生的业务流的第一通信元素组。在业务集群中出现异常时计算机设备只需获取异常时间段内的全量业务流的第一通信元素组,相比于采集任务执行的全时段(即任务从开始执行到执行结束的时间段)内的业务流而言,针对性地对异常时间段内的业务流的第一通信元素组进行采集,不仅降低数据采集量,而且避免为任务正常执行时产生的业务流进行分析,提高数据分析效率。
S402:获取业务集群中异常业务设备的第二通信元素组。
如前述,业务集群中的业务设备中部署有TCCL模块;当业务集群中的某个业务设备产生异常中断时,该业务设备中的TCCL的实现中会出现告警信息,该告警信息中包含了存在异常的业务设备中产生的第二通信元素组;告警信息可以表示为错误内容(ERR CQE),第二通信元素组为前述提及的三元组,三元组表示为:(源GPU卡标识,目的GPU卡标识,源端口号)。其中,存在异常的业务设备在本申请实施例中称为异常业务设备,该异常业务设备中的TCCL模块会向计算机设备上报异常时间段内受到影响的所有第二通信元素组;该第二通信元素组包括异常业务设备中存在异常的异常GPU卡的标识,以及与该异常GPU卡进行通信的GPU卡的标识,此处与异常GPU卡进行通信的GPU卡即为会受到异常GPU卡的影响的GPU卡。
在业务集群中业务设备中往往会包括多个GPU卡,如一个业务设备中包括8个GPU卡,该多个GPU卡之间会通过硬件总线(PCI(Peripheral Component Interconnect,外围部件互连)或NVLink(NVIDIA NVLink,高速总线及通信协议)等)进行通信,而不是通过X级组网进行通信。基于此,当业务设备中的某个GPU卡出现异常(该GPU卡称为异常GPU卡)时,除了与异常GPU卡通过X级组网进行通信的其他业务设备上的GPU卡会受到影响外,与该异常GPU卡部署在同一业务设备的其他GPU网卡也会受到影响,因此该其他GPU网卡也会上报计算机设备异常。由此可见,计算机设备获取到的业务集群中异常业务设备上报的第二通信元素组的数量为多个,多个第二通信元素组中包括:通过X级组网进行通信的业务流的第二通信元素组,以及,通过硬件总线进行通信的硬件通信的第二通信元素组。
进一步的,通过X级组网进行通信的业务流的第二通信元素组中,又包括由于根因GPU卡产生的第二通信元素组和受根因GPU卡影响的非根因GPU卡产生的第二通信元素组;也就是说,业务集群中不仅直接产生异常的异常业务设备上报第二通信元素组,受到异常影响的异常业务设备也会上报第二通信元素组。例如,业务节点A中的根因GPU卡故障引起异常,而该根因GPU卡和业务节点B中的非根因GPU卡通过X级组网进行通信,那么不仅业务节点A中的TCCL会上报根因GPU卡产生的第二通信元素组,业务节点B中的TCCL同样上报非根因GPU卡产生的第二通信元素组。由此可见,根因GPU卡是指直接产生异常或者受到故障直接影响的GPU卡(或者直接受到异常设备(如网元设备等影响的GPU卡,或者存在故障的GPU卡等)),而非根因GPU卡是指受到根因GPU卡的影响而导致任务执行速度下降或任务停止执行的GPU卡。
S403:基于第一通信元素组和第二通信元素组,从业务集群中筛选出异常业务流。
前述步骤S402中提到,计算机设备获取到的多个第二通信元素组中,不仅包括通过X级组网进行通信的业务流的第二通信元素组,还包括通过硬件总线进行通信的硬件通信的第二通信元素组,而通过硬件总线进行通信的硬件通信的第二通信元素组不会有端到端路径产生。端到端路径是指:从根因的异常GPU卡(或称为根因GPU卡),通过X级组网流向至另一个业务设备的GPU卡的业务流,在X级组网中所经过的网元设备所组成的通信路径。也就是说,只有根因GPU卡才能够还原出完整的端到端路径,而非根因GPU卡由于和根因GPU卡之间的通信被中断,因此非根因GPU卡也不能还原得到完整的端到端路径。换句话说,有完整的端到端路径意味着:业务集群中一个业务设备中的根因GPU卡,和位于业务集群中除该业务设备外的其他业务设备中的GPU卡之间,需要经过X级组网中的网元设备进行连接,从而根因GPU卡通过X级组网影响目的GPU卡标识对应的GPU卡的任务执行速度。
进一步的,前述步骤S401中提到,计算机设备能够获取到业务集群中异常时间段内的全量业务流的第一通信元素组;因此,如果业务集群中存在异常业务流,则全量业务流的第一通信元素组中一定包括异常业务设备中TCCL模块上报的异常业务流的第二通信元素组。本申请实施例主要对业务集群异常时,异常业务流在X级组网中进行传输时可能引起异常的原因进行分析。因此,计算机设备可以对第一通信元素组和第二通信元素组进行比较,具体是根据TCCL模块上报的异常的第二通信元素组中的源GPU卡标识和目的GPU卡标识,在全量业务流的第一通信元素组中检测所有具有相同源GPU卡标识和目的GPU卡标识的第一通信元素组;为便于区分,具有相同源GPU卡标识和目的GPU卡标识的第一通信元素组可以称为第三通信元素组。如果将第一通信元素组和第二通信元素组的比较,比较结果为:存在相同源GPU卡标识和目的GPU卡标识的第一通信元素组和第二通信元素组,表明从第一通信元素组中寻找到异常业务流的第一通信元素组;也就是说,能够实现从异常的第二通信元素组中剔除掉通过硬件总线进行通信的第二通信元素组,寻找到的第三通信元素组均是异常的业务流的通信元素组。如果将第一通信元素组和第二通信元素组进行比较,比较结果为空,即不存在源GPU卡标识和目的GPU卡标识均相同的第一通信元素组和第三通信元素组,表明业务集群中引起异常的原因可能不是异常业务流,则退出针对异常业务流的后续操作。
示例性地,对第一通信元素组和第二通信元素组进行比较的示意图可以参见图5。如图5所示,假设业务集群中包括业务设备A、业务设备B和业务设备C,每个业务设备中包括8个GPU卡,业务设备A中包括的8个GPU卡的标识分别为A1、A2、A3、A4、A5、A6、A7和A8,同理业务设备B中包括的8个GPU卡的标识分别为B1、B2、…、B7和B8,业务设备C中包括的8个GPU卡的标识分别为C1、C2、…、C7和C8。假设异常时间段内sflow代理上报至计算机设备的业务流的第一通信元素组包括:(A1,B1,源端口号1,目的端口号1,协议号)、(B1,C2,源端口号1,目的端口号2,协议号)、(B3,C2,源端口号2,目的端口号3,协议号);并且,异常业务设备上报的第二通信元素组包括:(B1,C2,源端口号1)、(B1,B2,源端口号1)、(B1,B3,源端口号1)、(B1,B4,源端口号1)以及(B1,B5,源端口号1)等等。因此,将每个第二通信元素组分别和每个第一通信元素组进行比较,找到源GPU卡标识和目的GPU卡标识均相同的第一通信元素组为(B1,C2,源端口号1,目的端口号2,协议号),则该第一通信元素组(B1,C2,源端口号1,目的端口号2,协议号)作为第三通信元素组,根据该第三通信元素组即可以确定异常业务流的源端和目的端,从而确定异常业务流。
此外,从业务设备中的TCCL通信库实现来看,一条业务流对应一个队列对(QueuePair,QP),一个队列对由发送队列(Send Queue,SQ)和接收队列(Receive Queue,RQ)组成,发送队列用于发送消息,而接收队列用于处理接收到的消息。当从源端的GPU卡发送到目的端的GPU卡的业务流的magSize(即消息的大小,表示消息数据的字节数量)超过某个阈值(如32MB(兆字节))时,会将该业务流对应多个队列对来发送,此时多个队列对中的每个队列对的各第二通信元素组是相同的。因此,TCCL模块上报给计算机设备的第二通信元素组可能存在重复;为此,计算机设备在获取到业务集群中异常业务上报的一个或多个第二通信元素组后,在将第二通信元素组和第一通信元素组进行比较之前,会先对一个或多个第二通信元素组进行数据去重处理,具体是按照源GPU卡标识、目的GPU卡标识和源端口号进行去重,旨在从一个或多个第二通信元素组中删除重复的第二通信元素组,得到去重后的第二通信元素组。
举例来说,假设计算机设备接收到的第二通信元素组分别为:(B1,C2,源端口号1)、(B1,C2,源端口号1)、(B1,C2,源端口号1)、(B1,B2,源端口号1)、(B1,B3,源端口号1)和(B1,B4,源端口号1);计算机设备对第二通信元素组进行数据去重处理时,对重复的3个第二通信元素组(B1,C2,源端口号1)、(B1,C2,源端口号1)、(B1,C2,源端口号1)中的两个重复的第二通信元素组进行删除,保留一个第二通信元素组即可。那么,经过数据去重处理后的第二通信元素组包括:(B1,C2,源端口号1)、(B1,B2,源端口号1)、(B1,B3,源端口号1)和(B1,B4,源端口号1)。
通过上述对第二通信元素组的去重处理,可以有效去除重复的第二通信元素组,在进行第二通信元素组和第一通信元素组的比较时,可以降低比较所需的资源和时间成本,提高比较结果的准确性。
需要说明的是,本申请实施例对计算机设备获取第一通信元素组和第二通信元素组的获取顺序不作限定;如计算机设备先获取到第一通信元素组,再获取到第二通信元素组,或者,计算机设备先获取到第二通信元素组,再获取第一通信元素组,或者,计算机设备同时获取到第一通信元素组和第二通信元素组。
S404:根据异常业务流的源端对应的GPU卡和目的端对应的GPU卡,确定异常业务流的通信路径。
基于前述步骤得到异常业务流的第三通信元素组后,计算机设备根据该第三通信元素组中的源GPU卡标识和目的GPU卡标识,就能够知晓该异常业务流的源端和目的端;而业务集群中的X级组网是确定的,因此计算机设备可以基于异常业务流的第三通信元素组中源端对应的GPU卡和目的端对应的GPU卡,以及X级组网中网元设备,判断异常业务流的通信路径是否存在,该通信路径为端到端路径,该通信路径中包括异常业务流依次经过的多个目标网元设备,即异常业务流在X级组网中依次经过的多个目标网元设备。如果异常业务流的端到端路径存在,则该异常业务流是根因GPU卡对应的业务流;如果异常业务流的端到端路径不存在,则该异常业务流是受到根因GPU卡影响的非根因GPU卡对应的业务流。因此,在异常业务流在X级组网中的传输路径是黑盒状态的情况下,本申请实施例能够从黑盒状态的X级组网中还原出异常业务流的通信路径,极大地方便了对异常业务流的异常原因排查,且有效确保异常原因排查的准确性。
在本申请实施例支持利用二元组来还原异常业务流的通信路径,该二元组为五元组中的源端对应的GPU卡标识和目的端对应的GPU卡标识;也就是说,在还原异常业务流的通信路径过程中,本申请实施例只使用五元组中的源端对应的GPU卡标识和目的端对应的GPU卡标识,极大地简化了计算。如图6a所示,计算机设备将异常业务流的二元组输入至数据预处理模块,利用该数据预处理模块来根据异常业务流的二元组(即源端对应的GPU卡的标识和目的端对应的GPU卡的标识),以及X级组网中网元设备还原异常业务流的通信路径。其中,该数据预处理模块可以部署于计算机设备中,或者部署于独立于计算机设备的其他设备中。计算机设备调用数据预处理模块还原异常业务流的通信路径的具体实施过程可以参见图6b,包括但是不限于步骤s11-s13;其中:
s11:计算机设备根据异常业务流的源端对应的GPU卡,异常业务流的目的端对应的GPU卡,以及X级组网中每层子网络中的网元设备,得到X层子网络之间的多个路径组。
计算机设备在根据第三通信元素组,已知异常业务流的源端对应的源GPU卡标识和目的端对应的目的GPU卡标识的情况下,本申请实施例支持利用X级组网之间的边界网关协议(如BGP协议,参见前述相关概述)还原异常业务流在相邻层子网络之间可能传输的多个路径组。其中,路径组或称为ECMP(Equal-Cost Multipath Routing,等价路径)组;每个ECMP组中包括从同一起点到达同一目的地(或称为终点)的一个或多个等价路径,多个等价路径是指具有相同路径开销的多个路径,每个等价路径的起点和终点分别为相邻层子网络中的网元设备,起点称为起始网元设备,终点称为终点网元设备。
具体实现中,计算机设备还原异常业务流在X级组网中相邻层子网络之间可能传输的多个路径组的具体实施过程可以包括但不限于:
(1)计算机设备根据异常业务流的第三通信元素组中源端对应的GPU卡的标识,在X级组网中的第一层子网络中确定异常业务流的起始网元设备。
计算机设备根据第三通信元素组中的源端对应的GPU卡的标识,可以确定业务集群中存在异常的源GPU卡。然后,业务设备中的业务设备和X级组网中的第一层子网络中的网元设备之间的连接链路是在构建业务集群时就确定的,因此在确定异常的源GPU卡后,计算机设备进一步确定X级组网中的第一层子网络中与该异常的源GPU卡相连的网元设备,此时与异常的源GPU卡相连的网元设备称为异常业务流的起始网元设备。
(2)计算机设备根据异常业务流的第三通信元素组中目的端对应的GPU卡的标识,在X级组网中的第一层子网络中确定异常业务流的终点网元设备。
计算机设备根据第三通信元素组中的目的端对应的GPU卡的标识,可以确定业务集群中存在异常的目的端GPU卡。然后,业务设备中的业务设备和X级组网中的第一层子网络中的网元设备之间的连接链路是在构建业务集群时就确定的,因此在确定异常的目的端GPU卡后,计算机设备进一步确定X级组网中的第一层子网络中与该异常的目的端GPU卡相连的网元设备,此时与异常的源目的端GPU卡相连的网元设备称为异常业务流的终点网元设备。
需要说明的是,在一些情况下,计算机设备可能根据第三通信元素组中的源端对应的GPU卡的标识,在业务集群中不到异常的GPU卡,或者找不到与异常的GPU卡相连接的起始网元设备。同理,计算机设备可能根据第三通信元素组中的目的端对应的GPU卡的标识,在业务集群中不到异常的GPU卡,或者找不到与异常的GPU卡相连接的终点网元设备。例如,业务集群发生设备迁移,如起始网元设备进行迁移(如网元设备中光模块故障时更换光模块导致的设备迁移等),就会出现异常的GPU卡的标识存在但找不到起始网元设备。计算机设备在找不到起始网元设备或者终点网元设备的情况下,直接返回,即退出异常业务流的后续还原操作。
(3)计算机设备基于起始网元设备和终点网元设备,在X层子网络中进行路径连接处理,得到X层子网络之间的多个路径组。
具体地,计算机设备基于起始网元设备和终点网元设备,在X层子网络中搜索相邻层的子网络之间的路径组的过程中,如果能够找到从起点网元设备到终点网元设备之间的全部ECMP组,表明该异常业务流存在完整的端到端路径,则认为该异常业务流的起点网元设备和起点网元设备对应的第一通信元素组就是根因GPU卡的通信元素组。反之,如果发现任意相邻层的子网络之间的路径组不存在,如找不到从起点网元设备到终点网元设备之间的一个或多个ECMP组,表明该异常业务流是受到根因GPU卡的影响的业务流;由于通信在根因GPU卡处已中断,因而在X级组网中不能还原出该异常业务流的端到端路径,那么确定不可能是该异常业务流的非根因GPU卡(即该异常业务流的第三通信元素组中的源GPU卡标识对应的GPU卡和目的GPU卡标识对应的GPU卡)引起的异常,则退出针对该非根因GPU卡的异常分析,继续对根因GPU卡进行异常原因分析。
下面对计算机设备基于起始网元设备和终点网元设备,在X层子网络中搜索相邻层的子网络之间的路径组的具体过程进行介绍。为便于阐述,本申请实施例将X层子网络中的任一层子网络表示为第i层子网络,i为整数且1≤i≤X;那么基于起始网元设备和终点网元设备在X层子网络中进行路径连接处理的过程可以包括:
①当i=1时,根据起始网元设备和第i+1层子网络,按照边界网关协议查询起始网元设备对应的多个第一路径组,多个第一路径组中的每个第一路径组的对端设备为第i+1层子网络中的一个网元设备;此情况下,边界网关协议定义了:当i=1时,从起始网元设备出发找到起始网元设备到第i+1层子网络中每个网元设备之间的一个或多个等价路径,起始网元设备到第i+1层子网络中任一网元设备之间的一个或多个等价路径作为一个第一路径组,多个第一路径组的对端设备均为第i+1层子网络的网元设备。其中,i=1时,第i+1层子网络为X级组网中的第二层子网络,每个第一路径组的对端设备为第2层子网络(或表示为第二层子网络)中的一个网元设备;所谓第一路径组的对端设备是指第一路径组中包括的任一条路径所到达的目的设备。
②令i=i+1,若i=X,则根据每个第一路径组的对端设备和终点网元设备,按照边界网关协议查询每个第一路径组的对端设备分别对应的第X路径组,每个第一路径组的对端设备为终点网元设备。此情况下,边界网关协议定义了:当i=X=2时,从每个第一路径组的对端设备出发,找到每个第一路径组的对端设备到终点网元设备之间的一个或多个等价路径,一个第一路径组的对端设备到终点网元设备之间的一个或多个等价路径作为一个第一路径组。
由于i=X=2,则X级组网之间的可能传输情况均已找到,则确定X层子网络之间的多个路径组包括:多个第一路径组,以及每个第一路径组的对端设备分别对应的第X路径组。举例来说,业务集群中的X级组网为二级组网,令i=i+1时,i=2,此时i=X=2,则根据第i-1路径组(此时第i-1路径组为第1路径组,或表示为第一路径组)的对端设备和终点网元设备,按照边界网关协议查询每个第一路径组的对端设备分别对应的第二路径组(或表示为第2路径组)。此情况下,二级组网中二层子网络之间的多个路径包括:多个第一路径组和每个第一路径组的对端设备分别对应的第二路径组。
③令i=i+1,若i<X,则根据多个第i-1路径组中每个第i-1路径组的对端设备和第i+1层子网络,按照边界网关协议查询每个第i-1路径组的对端设备分别对应的多个第i路径组;每个第i路径组的对端设备为第i+1层子网络中的网元设备。此情况下,边界网关协议定义了:当i<X时,从每个第i-1路径组的对端设备出发,找到每个第i-1路径组的对端设备到第i+1层子网络中每个网元设备之间的一个或多个等价路径,一个第i-1路径组的对端设备到第i+1层子网络中一个网元设备之间的一个或多个等价路径作为一个第i路径组。例如,若X=3,即业务集群中的X级组网为三级组网,则令i=i+1时,i=2,此时i<X,则根据多个第一路径组中每个第一路径组的对端设备和第三层子网络(或表示为第3层子网络),按照边界网关协议查询每个第一路径组的对端设备分别对应的多个第二路径组。
④循环执行上一步骤,当i=X时,根据每个第X-1路径组的对端设备和第X-1层子网络,按照边界网关协议查询每个第X-1路径的对端设备分别对应的多个第X路径组,此时任一第X路径组的对端设备为第X-1层子网络中的网元设备。此情况下,边界网关协议定义了:当i=X,X不等于2时,从每个第X路径组的对端设备出发,找到每个第X路径组的对端设备到第X-1层子网络中每个网元设备之间的一个或多个等价路径。例如,X=3时,根据每个第2路径组的对端设备和第二层子网络,按照边界网关协议查询每个第2路径组的对端设备分别对应的多个第三路径组,此时任一第三路径组的对端设备为第二层子网络中的网元设备。
⑤令i=i-1,若i>2,则根据多个第2X-i-1路径组中每个第2X-i-1路径组的对端设备和第i-1层子网络,按照边界网关协议查询每个第2X-i-1路径组的对端设备分别对应的多个第2X-i路径组;第2X-i路径组的对端设备为第i-1层子网络中的一个网元设备。此情况下,边界网关协议定义了:当i>2,X不等于2时,从每个第2X-i-1路径组的对端设备出发,找到每个第2X-i-1路径组的对端设备到第i-1层子网络中每个网元设备之间的一个或多个等价路径。例如,X=5,i=4时,根据多个第五路径组中每个第五路径组的对端设备,和第三层子网络,按照边界网关协议找到每个第五路径组的对端设备分别对应的多个第六路径组。
⑥循环执行上一步骤,当i=2时,根据每个第2X-i-1路径组的对端设备和终点网元设备,按照边界网关协议查询每个第2X-i-1路径组的对端设备分别对应的第2X-2路径组;第2X-2路径组的对端设备为终点网元设备。此情况下,边界网关协议定义了:当i=2,X不等于2时,从每个第2X-i-1路径组的对端设备出发,找到每个第2X-i-1路径组的对端设备到终点网元设备之间的一个或多个等价路径。
在步骤⑥执行结束时,i=2,则X级组网之间的可能传输情况均已找到,则确定X层子网络之间的多个路径组包括:多个第一路径组、多个第i路径组、多个第2X-i路径组以及第2X-i路径组的对端设备分别对应的第2X-2路径组。
需要说明的是,上述步骤①-步骤⑥概括了X≥2的每种组网情况下,根据第三通信元素组中源端对应的GPU卡的标识和目的端对应的GPU卡的标识,还原或确定异常业务流在X层子网络之间的多个路径组的具体实施过程。其中,步骤①和②是X=2时,即业务集群中包括的X级组网为二级组网时,还原异常业务流在二层子网络之间的多个路径组的具体实施过程;步骤①、③-⑥是X>2时,即业务集群中包括的X级组网的层级数量大于2(如三级组网)时,还原异常业务流在X层子网络之间的多个路径组的具体实施过程。此外,如果在上述步骤①-步骤⑥或步骤①、③-⑥中的任一个步骤中,基于第三通信元素组未寻找到路径组(如由于受到根因GPU卡的影响,通信在根因GPU卡处中断,导致非根因GPU卡并不能在X级组网中寻找到路径组),则确定该第三通信元素组为非根因GPU卡的通信元素组,则退出流程。
为便于理解,下面结合附图分别对X=2和X=3时,还原异常业务流在X层子网络之间的多个路径组的具体实施过程进行示例性介绍。
X=2时,还原异常业务流在二层子网络之间的多个路径组的流程示意图可以参见图7。如图7所示,假设第三通信元素组中源端对应的GPU卡为业务设备A中的GPU卡A1,目的端对应的GPU卡为业务设备B中的GPU卡B2;二级组网中的第一层子网络中包括三个网元设备,分别为CPULA1、CPULA2和CPULA3,第二层子网络中包括三个网元设备,分别为CPULC1、CPULC2和CPULC3;并且,起始网元设备为第一层子网络中的CPULA1,终点网元设备为第一层子网络中的CPULA2。那么,基于图7所示的二级组网还原二层子网络之间的多个路径组的过程包括:当i=1时,根据起始网元设备CPULA1和第二层子网络,按照边界网关协议查询起始网元设备CPULA1对应的多个第一路径组;其中,第一路径组的数量和第二层子网络的网元设备的数量相同,三个第一路径组分别为:GPULA1→GPULC1、GPULA1→GPULC2、GPULA1→GPULC3,且每个第一路径组中的等价路径的数量可以为一条或多条,对此不作限定。
进一步的,令i=i+1=2,此时确定i=X,则根据每个第一路径组的对端设备和终点网元设备CPULA2,按照边界网关协议查询每个第一路径组的对端设备分别对应的第2路径组。其中,第一路径组GPULA1→GPULC1的对端设备为GPULC1,对端设备GPULC1对应的第2路径组为GPULC1→CPULA2;同理,第一路径组GPULA1→GPULC2的对端设备为GPULC2,对端设备GPULC2对应的第2路径组为GPULC2→CPULA2;同理,第一路径组GPULA1→GPULC3的对端设备为GPULC3,对端设备GPULC3对应的第2路径组为GPULC3→CPULA2。综上,计算机设备得到二级组网下,三个第一路径组和三个第二路径组。
X=3时,还原异常业务流在三层子网络之间的多个路径组的流程示意图可以参见图8。如图8所示,假设第三通信元素组中源端对应的GPU卡为业务设备A中的GPU卡A1,目的端对应的GPU卡为业务设备B中的GPU卡B2;三级组网中的第一层子网络中包括三个网元设备,分别为CPULA1、CPULA2和CPULA3,第二层子网络中包括三个网元设备,分别为CPULC1、CPULC2和CPULC3,第三层子网络中包括两个网元设备,分别为SGLC1和SGLC2;并且,起始网元设备为第一层子网络中的CPULA1,终点网元设备为第一层子网络中的CPULA2。那么,基于图8所示的三级组网还原三层子网络之间的多个路径组的过程包括:当i=1时,根据起始网元设备CPULA1和第二层子网络,按照边界网关协议查询起始网元设备CPULA1对应的多个第一路径组;其中,第一路径组的数量和第二层子网络的网元设备的数量相同,三个第一路径组分别为:GPULA1→GPULC1、GPULA1→GPULC2、GPULA1→GPULC3,且每个第一路径组中的等价路径的数量可以为一条或多条,对此不作限定。
进一步的,令i=i+1=2,此时确定i<X,则根据多个第一路径组中每个第一路径组的对端设备和第三层子网络,按照边界网关协议查询每个第一路径组的对端设备分别对应的多个第二路径组。其中,第一路径组GPULA1→GPULC1的对端设备为GPULC1,对端设备GPULC1对应的第二路径组为GPULC1→SGLC1和GPULC1→SGLC2;同理,第一路径组GPULA1→GPULC2的对端设备GPULC2,对端设备GPULC2对应的第二路径组为GPULC2→SGLC1和GPULC2→SGLC2;同理,第一路径组GPULA1→GPULC3的对端设备为GPULC3,对端设备GPULC3对应的第二路径组为GPULC3→SGLC1和GPULC3→SGLC2。
更进一步的,令i=i+1=3,此时确定i=X,则根据每个第X-1路径组(即第二路径组)的对端设备和第X-1层子网络(即第二层子网络),按照边界网关协议查询每个第X-1路径组的对端设备分别对应的多个第X路径组。其中,第二路径组GPULC1→SGLC1、第二路径组GPULC2→SGLC1和第二路径组GPULC3→SGLC1的对端设备均为SGLC1,对端设备SGLC1对应的第三路径组分别为:SGLC1→GPULC1、SGLC1→GPULC2和SGLC1→GPULC3;同理,第二路径组GPULC1→SGLC2、第二路径组GPULC2→SGLC2和第二路径组GPULC1→SGLC2的对端设备均为SGLC2,对端设备SGLC2对应的第三路径组为SGLC2→GPULC1、SGLC2→GPULC2和SGLC2→GPULC3。
更进一步的,令i=i-1=2,此时确定i=2,则根据每个第2X-i-1路径组(即第三路径组)的对端设备和终点网元设备GPULA2,按照边界网关协议查询每个第2X-i-1路径组的对端设备分别对应的第2X-2路径组。其中,第三路径组SGLC1→GPULC1和第三路径组SGLC2→GPULC1的对端设备均为GPULC1,对端设备GPULC1对应的第四路径组为GPULC1→GPULA2;同理,第三路径组SGLC1→GPULC2和第三路径组SGLC2→GPULC2的对端设备均为GPULC2,对端设备GPULC2对应的第四路径组为GPULC2→GPULA2;同理,第三路径组SGLC1→GPULC3和第三路径组SGLC2→GPULC3的对端设备均为GPULC3,对端设备GPULC3对应的第四路径组为GPULC3→GPULA2。综上,计算机设备得到二级组网下,三个第一路径组、六个第二路径组、六个第三路径组和三个第四路径组。
s12:计算机设备根据多个路径组和异常业务流在X层子网络之间的流向,构建有向图。
有向图是一幅具有方向性的图,有向图由一组节点和有方向的边组成,每条有方向的边连着一对有序的节点。如前述,在X级组网中从起始网元设备流向至终点网元设备的异常业务流也是具有方向性的,因此本申请实施例支持根据步骤s11在X级组网中找到的X层子网络之间的多个路径组,来构建异常业务流对应的有向图。
具体实现中,计算机设备将X层子网络之间的多个路径组中的多个网元设备作为有向图的节点;然后,按照异常业务流在X层子网络之间的流向,将多个节点进行连接,即得到异常业务流对应的有向图。有向图中包括起始节点、终点节点和X-1个中间层,每个中间层中包括一个或多个中间节点。以X级组网为二级组网为例,如图9所示,根据图7所示的多个路径组构建的有向图中节点包括:起始节点GPULA1,中间节点GPULC1、GPULC2和GPULC3,终点节点GPULA2。其中,起始节点GPULA1分别和中间节点GPULC1、中间节点GPULC2和中间节点GPULC3进行连接,且连接后的箭头方向为GPULA1→GPULC1、GPULA1→GPULC和GPULA1→GPULC3,各中间节点又和终点节点GPULA2连接,连接后的箭头方向为GPULC1→GPULA1、GPULC2→GPULA1和GPULC3→GPULA1。
s13:计算机设备对有向图进行路径搜索处理,得到异常业务流的通信路径。
其中,该异常业务流的通信路径,可以理解为根因GPU卡对应的端到端路径。异常业务流对应的有向图是带权的有向图;所谓带权的有向图是指有向图中每条边均具有权重值,任一条边的权重值可以代表该边的一个节点到另一个节点之间的距离或时间等参数。在后续实施例中以边的权重值代表两个节点之间的距离为例进行阐述,那么边的权重值越大,表明该边的两个节点之间的距离越大,反之边的权重值越小,表明该边的两个节点之间的距离越小。本申请实施例支持对带权的有向图进行路径搜索处理,旨在从有向图中搜索出最短路径作为异常业务流的通信路径;这是考虑到层级子网络之间的边界网关协议也支持选择最短路径来传输业务流,因此将搜索的最短路径作为异常业务流的通信路径更符合真实情况下X级组网之间传输业务流的传输情况。
本申请实施例支持采用路径遍历算法从带权的有向图中搜索最短路径;如路径遍历算法为深度优先遍历算法(Depth First Search,DFS)等。下面以有向图的X-1个中间层中的任一个中间层表示为第j个中间层为例,对从有向图中搜索最短路径的过程进行介绍,j为整数且1≤j≤X-1。
具体实现中,当j=1时,从有向图的起始节点开始,遍历起始节点和X-1个中间层中的第一个中间层中的各中间节点之间的路径,得到起始节点对应的多个第一权重值;一个第一权重值为起始节点和第一个中间层中一个中间节点之间路径的权重值,如权重值为距离。然后,令j=j+1,当j>X-1时,分别计算第j-1个中间层中各中间节点和终点节点之间路径的第X权重值;一个第X权重值为第j-1个中间层中一个中间节点和点节点之间路径的权重值。此情况下,计算机设备基于多个第一权重值和第X权重值,从有向图中确定出最短路径作为异常业务流的通信路径。反之,若j≤X-1,则从第j-1个中间层中各中间节点开始,遍历第j个中间层中各中间节点和第j-1个中间层中各中间节点之间的路径,得到第j个中间层中各中间节点对应的多个第j权重值。此情况下,计算机设备基于多个第一权重值,第j个中间层中各中间节点对应的多个第j权重值以及第X权重值,从有向图中确定出最短路径作为异常业务流的通信路径。
以X=2为例,从有向图中确定出最短路径的示例性过程可以参见图10a。如图10a所示,当j=1时,计算起始节点对应的三个第一权重值,即起始节点GPULA1分别到中间节点GPULC1、GPULC2和GPULC3的边的权重值,分别为1、3和2;当j=j+1=2时,确定j>X-1=1,分别计算第一个中间层中各中间节点和终点节点GPULA2之间路径的第X权重值(即第二权重值),如中间节点GPULC1、中间节点GPULC2和中间节点GPULC3到终点节点之间的边的第二权重值分别为2、1和2。然后,基于三个第一权重值和三个第二权重值,从有向图中确定出最短路径为GPULA1→GPULC1→GPULLA2,则将端到端路径GPULA1→GPULC1→GPULLA2作为异常业务流的通信路径。
以X=3为例,从有向图中确定出最短路径的示例性过程可以参见图10b。如图10b所示,当j=1时,计算起始节点对应的三个第一权重值,即起始节点GPULA1分别到中间节点GPULC1、GPULC2和GPULC3的边的权重值,分别为1、3和2。令j=j+1=2,此时j=X-1=2,计算机设备从第一个中间层中各中间节点开始,遍历第2个中间层中各中间节点之间的路径,得到第2个中间层中各中间节点对应的多个第二权重值。示例性地,第一个中间层中的中间节点GPULC1分别到第二个中间层中的中间节点SGLC1和中间节点SGLC2之间的边的两个第二权重值分别为1和1;同理,第一个中间层中的中间节点GPULC2分别到第二个中间层中的中间节点SGLC1和中间节点SGLC2之间的边的两个第二权重值分别为1和2;同理,第一个中间层中的中间节点GPULC3分别到第二个中间层中的中间节点SGLC1和中间节点SGLC2之间的边的两个第二权重值分别为2和3。进一步的,令j=j+1=3,此时j>X-1=3,则分别计算第二个中间层中各中间节点和终点节点之间路径的第X权重值;其中,第二个中间层中的中间节点SGLC1到终点节点GPULA2之间的边的第三权重值为2,第二个中间层中的中间节点SGLC2到终点节点GPULA2之间的边的第三权重值为1。最后,基于三个第一权重值、三个第二权重值和两个第三权重值,从有向图中确定出最短路径为GPULA1→GPULC1→SGLC2→GPULA2,则将端到端路径GPULA1→GPULC1→SGLC2→GPULA2作为异常业务流的通信路径。
需要说明的是,上述步骤s11-s13以业务集群中的X级组网分别为二级组网和三级组网为例,对计算机设备根据边界网关协议在X级组网中还原异常业务流的通信路径的具体实施过程进行介绍,并不会对本申请实施例产生限定。也就是说,本申请实施例提供的上述还原通信路径的过程还可以适用于更为复杂的X级组网架构,特在此说明。
综上所述,通过上述步骤S401-S404所示的具体实施过程,计算机设备可以基于业务集群中的全量业务流的第一通信元素组和异常业务设备上报的第二通信元素组,构建出异常业务流的源端对应的GPU卡和目的端对应的GPU卡对应的有向图,再从有向图中搜索出最短路径作为异常业务流的通信路径。上述过程无需人工参与,极大地加速了异常业务流的通信路径的还原效率,从而减少故障节点发现时间,能够达到将故障发现时间从平均4小时缩短到3分钟以内,排障效率提高80倍。
为便于连贯理解步骤S401-S404所示的具体实施过程,下面结合图11以X级组网分别为二级组网和三级组网,边界网关协议为BGP邻居路由为例,对计算机设备快速恢复异常业务流的通信路径的整体流程进行介绍。如图11所示:计算机设备获取到业务集群中的全量业务流的第一通信元素组,和异常业务设备上报的第二通信元素组。计算机设备将第一通信元素组和第二通信元素组进行比较,若比较结果为:不存在源GPU卡标识和目的GPU卡标识均相同的第一通信元素组和第二通信元素组,则退出流程;若比较结果为:存在源GPU卡标识和目的GPU卡标识均相同的第一通信元素组和第二通信元素组,则得到异常业务流的第一通信元素组(或称为第三通信元素组)。计算机设备根据异常业务流的第一通信元素组中源端对应的GPU卡标识(即源GPU卡标识)在业务集群中检测是否存在起始网元设备,以及根据异常业务流的第一通信元素组中目的端对应的GPU卡标识(即目的GPU卡标识)在业务集群中检测是否存在终点网元设备;若起始网元设备和终点网元设备中的任一个不存在,则退出流程;若起始网元设备和终点网元设备均存在,则计算机设备根据起始网元设备的下一跳BGP邻居路由,找到从起始网元设备出发的第一路径组,该第一路径组的对端设备为X级组网中的第二层子网络中的GPULC设备;再根据第一路径组的对端设备的下一跳BGP邻居路由,找到从第一路径组的对端设备出发的第二路径组。
当X级组网为二级组网时,第二路径组的对端设备为X级组网中第一层子网络中的GPULA设备,具体是第一层子网络中的终点网元设备。此时,根据多个第一路径组和多个第二路径组,构建异常业务流对应的有向图。当X级组网为三级组网时,第二路径组的对端设备为三级组网中的第三层子网络中的SGLC设备,那么计算机设备继续根据第二路径组的对端设备的下一跳BGP邻居路由,找到从第二路径组的对端设备出发的第三路径组,该第三路径组的对端设备为GPULC设备;计算机设备继续根据第三路径组的对端设备的下一条BGP邻居路由,找到从第三路径组的对端设备出发的第四路径组,该第四路径组的对端设备为X级组网中第一层子网络中的GPULA设备,具体是第一层子网络中的终点网元设备。此时,根据多个第一路径组、多个第二路径组、多个第三路径组和多个第四路径组,构建异常业务流对应的有向图。最后,计算机设备在构建得到异常业务流的有向图后,采用路径遍历算法从带权的有向图中搜索出最短路径,作为异常业务流的端到端路径。
S405:对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息。
基于前述步骤从黑盒的X级组网中还原出异常业务流的端到端路径后,本申请实施例支持根据基础检测模块对异常业务流的端到端路径上的目标网元设备进行设备分析处理,旨在分析是目标网元设备的故障引起的异常业务流,还是X级组网的网络故障引起的异常业务流,从而实现对异常业务流的异常原因分析,便于运维人员更好地基于分析得到的异常原因对业务集群进行调整,从而实现任务的快速恢复执行。其中,基础检测模块可以是部署于计算机设备中,或者部署于独立于计算机设备的其他设备中的模块;该基础检测模块具备对异常业务流的端到端路径中的目标网元设备进行设备分析处理的能力。
综上所述,一方面,本申请实施例有效的将业务集群存在异常时,根因GPU卡的通信路径还原出来,相比于故障产生时对业务集群中全部业务设备进行分析而言,将需要排查的故障排查范围域由参与业务集群中任务的全部业务设备,缩小到在异常时间段内仅存在通信关系且上传第二通信元素组的异常业务设备,具体是根因GPU卡的通信路径;极大地提高了业务集群中针对故障的处理效率,避免业务集群中业务设备的算力浪费的同时,节省任务执行的成本。另一方面,对于网络运维而言,在任务执行的过程中很多故障体现为疑似网络问题,通过本申请实施例提供的业务集群的处理方案,可以准确判断是网络问题还是端侧(即目标网元设备)的问题,实现故障排查的精准定位,从而在任务执行过程中帮助业务的快速恢复执行。
图12示出了本申请一个示例性实施例提供的另一种业务集群的处理方法的流程示意图,该处理方法可以由计算机设备来执行,计算机设备是前述图3所示的计算机设备308,如计算机设备308为终端或服务器。业务集群的处理方法可包括但不限于步骤S1201-S1208:
S1201:获取业务集群中多个业务流的第一通信元素组。
S1202:获取业务集群中异常业务设备的第二通信元素组。
S1203:基于第一通信元素组和第二通信元素组,从业务集群中筛选出异常业务流。
S1204:根据异常业务流的源端对应的GPU卡和目的端对应的GPU卡,确定异常业务流的通信路径。
需要说明的是,步骤S1201-S1204所示的具体实施过程,和前述图4所示实施例中步骤S401-S404所示的具体实施过程是相同的,可以参见步骤S401-S404所示的具体实施过程的相关描述,在此不作赘述。
此外,本申请实施例支持对数据预处理模块针对第一通信元素组和第二通信元素组进行路径还原的结果进行可视化展示,便于运维人员直观地感知针对第三通信元素组的真实传输路径的还原情况。示例性地,基于第一通信元素组和第二通信元素组构建得到有向图后,在有向图中找到异常业务流的端到端路径的可视化展示可以参见图13a;如图13a所示,在计算机设备(如带有显示屏幕的终端)中显示第三通信元素组,以及根据该第三通信元素组还原得到的端到端路径。示例性地,基于第一通信元素组和第二通信元素组未还原出异常业务流的端到端路径的示意图可以参见图13b;如图13b所示,在计算机设备中显示第三通信元素组,且显示结果提示信息1301,该结果提示信息1301用于提示未找到第三通信元素组对应的端到端路径,也就是说根据该第三通信元素组不能还原得到端到端路径,此时该第三通信元素组对应的异常业务流为受根因GP卡影响的业务流,而不是根因GPU卡对应的业务流。
S1205:获取参考路径,并将参考路径上的多个参考网元设备,和通信路径上的多个目标网元设备进行比较,得到比较结果。
S1206:若比较结果为:多个参考网元设备和多个目标网元设备不相同,或者多个参考网元设备之间的通信连接顺序和多个目标网元设备之间的通信连接顺序不相同,则对芯片进行异常原因分析,得到芯片的异常信息。
S1207:若比较结果为:多个参考网元设备和多个目标网元设备相同,且多个参考网元设备之间的通信连接顺序和多个目标网元设备之间的通信连接顺序相同,则触发执行对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息的步骤。
步骤S1205-S1207中,在本申请实施例中,计算机设备基于前述步骤还原得到异常业务流的端到端路径后,还支持根据该还原的真实端到端路径(或称为真实通信路径)进一步对运维人员在业务集群中所采用的并行通信路径进行合理性分析,帮助运维人员合理规划业务集群的硬件部署。其中,在业务集群中的网元设备上部署有芯片,该芯片可以为网络接口板或者网络接口卡,或者网卡,用于根据sflow代理采集的业务流的第一通信元素组,来规划或指定需要经过该网元设备进行传输的业务流的传输路径。其中,对并行通信路径进行合理性分析,主要是指对运维人员在网元设备中部署的芯片的路径规划能力进行合理性分析,以检测芯片规划路径的能力是否达到预期效果。如果未达到预期效果,则运维人员可以对芯片进行更换,以提高业务集群中网元设备中芯片规划传输路径的能力。
考虑到网元设备中的芯片本身存在故障,或者芯片规划传输路径的能力较弱时均会引起业务集群中的任务执行异常;基于此,本申请实施例支持在将异常业务流的端到端路径上的目标网元设备进行设备分析处理之前,先对芯片进行合理性分析,排查是否芯片引起的任务执行异常,更为有效且准确地实现故障排查。
具体实现中,计算机设备获取芯片基于异常业务流的第一通信元素组规划得到的参考路径,该参考路径中包括:异常业务流的源端对应的GPU卡,和异常业务流的目的端对应的GPU卡之间的业务流,在X级组网中所经过的多个参考网元设备。换句话说,该参考路径是网元设备中的芯片在接收到sflow代理采集的异常业务流的第一通信元素组后,根据该第一通信元素组为异常业务流规划的路径。进一步的,计算机设备将芯片规划的参考路径和按照本申请实施例还原的异常业务流的真实通信路径进行比较,具体是将参考路径上的多个参考网元设备和真实通信路径上的多个目标网元设备进行比较,得到比较结果;也就是说此处的比较,不仅比较参考网元设备和目标网元设备是否相同,而且比较多个参考网元设备之间的通信连接顺序,和多个目标网元设备之间的通信连接顺序是否相同。
如果比较结果为:参考网元设备的数量和目标网元设备的数量相同,多个参考网元设备中的每个参考网元设备,均和多个目标网元设备中的一个目标网元设备相同,且多个参考网元设备之间的通信连接顺序和多个目标网元设备之间的通信连接顺序相同,表明芯片基于异常业务流的第一通信元素组规划或指定的参考路径,和按照步骤S1201-S1204还原得到的真实通信路径是相同的,则确定芯片规划传输路径的能力达到预期效果;此情况下,执行下述步骤S1208以分析异常业务流的通信路径上各目标网元设备,来分析异常业务流的产生原因。
如果比较结果为:参考网元设备的数量和目标网元设备的数量不相同,或者,多个参考网元设备中的任一个参考网元设备,和多个目标网元设备中的一个目标网元设备不相同,或者多个参考网元设备之间的通信连接顺序和多个目标网元设备之间的通信连接顺序不相同,表明芯片基于异常业务流的第一通信元素组规划或指定的参考路径,和按照步骤S1201-S1204还原得到的真实通信路径是不相同的,则确定芯片规划传输路径的能力未达到预期效果,那么异常业务流的产生可能是由芯片引起的;此情况下,运维人员需要先对芯片进行异常原因分析,得到芯片的异常信息,该芯片的异常信息描述了芯片异常的原因,以便于利用该芯片的异常信息指导运维人员对芯片进行调整和优化。
S1208:对通信路径上的各目标网元设备进行设备分析处理,得到异常业务流的异常信息。
在异常业务流的通信路径上的各目标网元设备进行设备分析处理,旨在分析是网络引起的异常业务流还是目标网元设备引起的异常业务流。在本申请实施例中,支持对通信路径上的各目标网元设备进行网络指标的对比来实现设备分析处理。具体地,计算机设备调用基础检测模块来对通信路径上的各目标网元设备进行网络指标的对比;其中,基础检测模块对通信路径上的各目标网元设备进行网络指标的对比的过程可以包括:获取一个或多个检测指标,该检测指标包括以下至少一种:流量拥塞指标、拥塞程度指标、GPU利用率和RDMA流量等。然后,采用一个或多个检测指标中的每个检测指标,对多个目标网元设备中的每个目标网元设备进行指标分析处理,得到目标网元设备在每个检测指标下的指标信息,如检测指标的数量为3,那么每个目标网元设备对应有3个指标信息,一个指标信息对应一种检测指标;目标网元设备在任一检测指标下的指标信息,是将目标网元设备输入到基础检测模块后,基础检测模块采用该任一检测指标对目标网元设备进行指标分析处理所得到的指标数据。这样,根据每个目标网元设备在每个检测指标下的指标信息,对异常业务流进行异常分析,得到异常业务流的异常信息;具体是综合同一目标网元设备在各检测指标下的指标信息,对该目标网元设备进行综合分析,得到每个目标网元设备在综合分析后的设备分析结果,再根据每个目标网元设备的设备分析结果对异常业务流进行异常分析,得到异常业务流的异常信息。
示例性地,使用PFC流量和ECN报文对异常业务流的端到端路径上的目标网元设备进行指标分析处理的结果示意图可以参见图14;如图14所示,假设端到端路径为:GPULA-006→GPULC-0614→GPULA-014。那么,计算机设备将端到端路径GPULA-006→GPULC-0614→GPULA-014输入至基础检测模块,该基础检测模块采用PFC流量和ECN报文两种检测指标,对端到端路径中的每个目标网元设备进行指标分析处理,分别得到目标网元设备GPULA-006对应的综合指标信息1401、目标网元设备GPULC-0614对应的综合指标信息1402和目标网元设备GPULA-014对应的综合指标信息1403。如图14所示,每个目标网元设备在各检测指标下的指标信息可以进行图文展示;如目标网元设备GPULA-006的综合指标信息中同时包括检测指标“PFC流量”对应的指标信息14011和检测指标“ECN报文”对应的指标信息14012。在图14所示的指标信息中,三个目标网元设备在ECN指标下的指标信息均为0,那么看三个目标网元设备在PFC指标下的指标信息,三个目标网元设备在PFC指标下的指标信息不为0,则对三个目标网元设备在PFC指标下的指标信息在故障时刻前后一段时间进行累加计算,分析可得异常业务流所经过的各目标网元设备上均有大量的PFC报文出现,从而定界是X级组网的网络问题引起的异常,而非目标网元设备本身出现问题(光模块故障或温度过高等)引起的异常。
由此可见,采用图文形式来综合展示目标网元设备在各检测指标下的指标信息的方式,极大地方便了运维人员同时结合多个检测指标分析目标网元设备,便于运维人员更快且更准确的进行异常业务流的异常原因分析。
进一步的,本申请实施例支持计算机设备根据异常业务流的异常信息,对业务集群进行集群调整处理,得到调整后的业务集群;对业务集群进行调整,旨在确保调整后的业务集群执行任务时不会再因为相同的异常原因产生异常业务流。例如,若异常业务流的异常信息所描述的异常原因为:异常业务流的端到端路径上的某个目标网元设备出现故障,那么采用不存在故障的新的网元设备对该目标网元设备进行替换,以保证业务的快速恢复执行。再如,如果异常业务流的异常信息所描述的异常原因为:由于网络问题导致业务执行异常,则进一步排查网络问题,如重启网络等。又如,若异常业务流的异常信息所描述的异常原因为:异常业务流的源端对应的GPU卡故障,则在业务集群中对异常业务流的源端对应的GPU卡进行替换处理,得到替换后的业务集群,该替换后的业务集群中不再包含故障的GPU卡,从而实现业务的快速恢复执行。需要说明的是,根据异常业务流的异常信息所描述的异常原因不同,运维人员对业务集群的集群调整处理的方式也不相同;上述仅给出三种示例性的异常原因下对业务集群的集群调整处理方式,并不会对本申请实施例产生限定,特在此说明。
综上所述,本申请实施例提供的业务集群的处理方案,能够快速发现业务集群中的故障原因,快速定位到故障的端到端路径,有效降低故障排查时间,从而提高业务恢复效率。一方面,能够减少故障发现时间,排障效率显著提升。另一方面,对于网络运维而言,不再对业务集群的故障排查模糊的定位为疑似网络问题,而是可以准确的判断故障是网络问题还是端侧(网元设备)问题,提高故障排查的准确性,实现业务执行的快速恢复。
上述详细阐述了本申请实施例的方法,为了便于更好地实施本申请实施例的上述方案,相应地,下面提供了本申请实施例的装置。本申请实施例中,术语“模块”或“单元”是指有预定功能的计算机程序或计算机程序的一部分,并与其他相关部分一起工作以实现预定目标,并且可以通过使用软件、硬件(如处理电路或存储器)或其组合来全部或部分实现。同样的,一个处理器(或多个处理器或存储器)可以用来实现一个或多个模块或单元。此外,每个模块或单元都可以是包含该模块或单元功能的整体模块或单元的一部分。
图15示出了本申请一个示例性实施例提供的一种业务集群的处理装置的结构示意图;该业务集群中包括多个业务设备和多个网元设备,任意两个业务设备之间通过至少一个网元设备进行通信连接;每个业务设备中包括至少一个GPU卡,该处理装置可以用于执行图4和图12所示的方法实施例中的部分或全部步骤。请参见图15,该装置包括如下单元:
获取单元1501,用于获取业务集群中多个业务流的第一通信元素组,业务流是指从源端的业务设备中一个GPU卡,流向目的端的业务设备中一个GPU卡的数据流;第一通信元素组包括业务流的源端对应的GPU卡的标识和目的端对应的GPU卡的标识;
获取单元1501,还用于获取业务集群中异常业务设备的第二通信元素组,第二通信元素组包括异常业务设备中异常GPU卡的标识,以及与异常GPU卡进行通信的GPU卡的标识;
处理单元1502,用于基于第一通信元素组与第二通信元素组,从业务集群中筛选出异常业务流;
处理单元1502,还用于根据异常业务流的源端对应的GPU卡和目的端对应的GPU卡,确定异常业务流的通信路径,通信路径中包括异常业务流依次经过的多个目标网元设备;
处理单元1502,还用于对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息。
在一种实现方式中,业务集群中包括X级组网,X级组网中包括层级分布的X层子网络,每层子网络中包括多个网元设备,X为整数且X≥2;处理单元1502,用于根据异常业务流的源端对应的GPU卡和目的端对应的GPU卡,确定异常业务流的通信路径时,具体用于:
根据异常业务流的源端对应的GPU卡,异常业务流的目的端对应的GPU卡,以及,X级组网中每层子网络中的网元设备,得到X层子网络之间的多个路径组;每个路径组中包括一个或多个等价路径,等价路径的两个路径端点分别为相邻的两层子网络中的网元设备;
根据多个路径组和异常业务流在X层子网络之间的流向,构建有向图;
对有向图进行路径搜索处理,得到异常业务流的通信路径。
在一种实现方式中,处理单元1502,用于根据异常业务流的源端对应的GPU卡,异常业务流的目的端对应的GPU卡,以及,X级组网中每层子网络中的网元设备,得到X层子网络之间的多个路径组时,具体用于:
根据异常业务流的源端对应的GPU卡的标识,在X级组网中的第一层子网络中确定异常业务流的起始网元设备;
根据异常业务流的目的端对应的GPU卡的标识,在X级组网中的第一层子网络中确定异常业务流的终点网元设备;
基于起始网元设备和终点网元设备,在X层子网络中进行路径连接处理,得到X层子网络之间的多个路径组。
在一种实现方式中,X层子网络中的任一层子网络表示为第i层子网络,i为整数且1≤i≤X;处理单元1502,用于基于起始网元设备和终点网元设备,在X层子网络中进行路径连接处理,得到X层子网络之间的多个路径组时,具体用于:
当i=1时,根据起始网元设备和第i+1层子网络,按照边界网关协议查询起始网元设备对应的多个第一路径组;每个第一路径组的对端设备为第i+1层子网络中的一个网元设备;
令i=i+1,若i=X,则根据每个第一路径组的对端设备和终点网元设备,按照边界网关协议查询每个第一路径组的对端设备分别对应的第X路径组;第X路径组的对端设备为终点网元设备;
其中,X层子网络之间的多个路径组包括:多个第一路径组,以及每个第一路径组的对端设备分别对应的第X路径组。
在一种实现方式中,处理单元1502,还用于:
令i=i+1,若i<X,则根据多个第i-1路径组中每个第i-1路径组的对端设备和第i+1层子网络,按照边界网关协议查询每个第i-1路径组的对端设备分别对应的多个第i路径组;
当i=X时,根据每个第X-1路径组的对端设备和第X-1层子网络,按照边界网关协议查询每个第X-1路径组的对端设备分别对应的多个第X路径组;
令i=i-1,若i>2,则根据多个第2X-i-1路径组中每个第2X-i-1路径组的对端设备和第i-1层子网络,按照边界网关协议查询每个第i+1路径组的对端设备分别对应的多个第2X-i路径组;第2X-i路径组的对端设备为第i-1层子网络中的一个网元设备;
当i=2时,根据每个第2X-i-1路径组的对端设备和终点网元设备,按照边界网关协议查询每个第2X-i-1路径组的对端设备分别对应的第2X-2路径组;第2X-2路径组的对端设备为终点网元设备;
其中,X层子网络之间的多个路径组包括:多个第一路径组、多个第i路径组、多个第2X-i路径组以及第2X-i路径组的对端设备分别对应的第2X-2路径组。
在一种实现方式中,处理单元1502,用于根据多个路径组和异常业务流在X层子网络之间的流向,构建有向图时,具体用于:
将多个路径组中的多个网元设备作为有向图的节点;
按照异常业务流在X层子网络之间的流向,将多个节点进行连接,得到有向图。
在一种实现方式中,有向图中包括起始节点、终点节点和X-1个中间层,每个中间层中包括一个或多个中间节点,X-1个中间层中的任一个中间层表示为第j个中间层,j为整数且1≤j≤X-1;处理单元1502,用于对有向图进行路径搜索处理,得到异常业务流的通信路径时,具体用于:
当j=1时,从起始节点开始,遍历起始节点和第一个中间层中的各中间节点之间的路径,得到起始节点对应的多个第一权重值;一个第一权重值为起始节点和第一个中间层中一个中间节点之间路径的权重值;
令j=j+1,当j>X-1时,分别计算第j-1个中间层中各中间节点和终点节点之间路径的第X权重值;一个第X权重值为第j-1个中间层中一个中间节点和终点节点之间路径的权重值;
基于多个第一权重值和第X权重值,从有向图中确定出最短路径作为异常业务流的通信路径。
在一种实现方式中,处理单元1502,还用于:
令j=j+1,若j≤X-1,则从第j-1个中间层中各中间节点开始,遍历第j个中间层中各中间节点和第j-1个中间层中各中间节点之间的路径,得到第j个中间层中各中间节点对应的多个第j权重值;
基于多个第一权重值,第j个中间层中各中间节点对应的多个第j权重值以及第X权重值,从有向图中确定出最短路径作为异常业务流的通信路径。
在一种实现方式中,获取单元1501,用于获取业务集群中异常业务设备的第二通信元素组时,具体用于:
获取业务集群上异常业务设备上报的一个或多个第二通信元素组;
对一个或多个第二通信元素组进行数据去重处理,得到去重处理后的第二通信元素组。
在一种实现方式中,处理单元1502,用于对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息时,具体用于:
获取一个或多个检测指标;检测指标包括以下至少一种:流量拥塞指标和拥塞程度指标;
采用一个或多个检测指标中的每个检测指标,对多个目标网元设备中的每个目标网元设备进行指标分析处理,得到每个目标网元设备在每个检测指标下的指标信息;
根据每个目标网元设备在每个检测指标下的指标信息,对异常业务流进行异常分析,得到异常业务流的异常信息;异常业务流的异常信息用于描述异常业务流的异常原因。
在一种实现方式中,网元设备中包括芯片;处理单元1502,还用于:
获取参考路径,参考路径中包括:异常业务流的源端对应的GPU卡,和异常业务流的目的端对应的GPU卡之间的业务流,所经过的多个参考网元设备;参考路径是芯片基于异常业务流的第一通信元素组所规划得到的;
将参考路径上的多个参考网元设备,和通信路径上的多个目标网元设备进行比较,得到比较结果;
若比较结果为:多个参考网元设备和多个目标网元设备相同,且多个参考网元设备之间的通信连接顺序和多个目标网元设备之间的通信连接顺序相同,则触发执行对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息的步骤;
若比较结果为:多个参考网元设备和多个目标网元设备不相同,或者多个参考网元设备之间的通信连接顺序和多个目标网元设备之间的通信连接顺序不相同,则对芯片进行异常原因分析,得到芯片的异常信息。
在一种实现方式中,处理单元1502,还用于:
根据异常业务流的异常信息,对业务集群进行集群调整处理,得到调整后的业务集群;
其中,调整后的业务集群不存在异常业务流。
在一种实现方式中,处理单元1502,还用于根据异常业务流的异常信息,对业务集群进行集群调整处理,得到调整后的业务集群时,具体用于:
若异常业务流的异常信息所描述的异常原因为,异常业务流的源端对应的GPU卡故障,则在业务集群中对异常业务流的源端对应的GPU卡进行替换处理,得到替换后的业务集群。
根据本申请的一个实施例,图15所示的业务集群的处理装置中的各个单元可以分别或全部合并为一个或若干个另外的单元来构成,或者其中的某个(些)单元还可以再拆分为功能上更小的多个单元来构成,这可以实现同样的操作,而不影响本申请的实施例的技术效果的实现。上述单元是基于逻辑功能划分的,在实际应用中,一个单元的功能也可以由多个单元来实现,或者多个单元的功能由一个单元实现。在本申请的其它实施例中,该业务集群的处理装置也可以包括其它单元,在实际应用中,这些功能也可以由其它单元协助实现,并且可以由多个单元协作实现。根据本申请的另一个实施例,可以通过在包括中央处理单元(CPU)、存取存储介质(RAM)、只读存储介质(ROM)等处理元件和存储元件的例如计算机的通用计算设备上运行能够执行如图4和图12所示的相应方法所涉及的各步骤的计算机程序(包括程序代码),来构造如图15中所示的业务集群的处理装置,以及来实现本申请实施例的业务集群的处理方法。计算机程序可以记载于例如计算机可读记录介质上,并通过计算机可读记录介质装载于上述计算设备中,并在其中运行。
本申请实施例有效的将业务集群存在异常时异常业务流的通信路径还原出来,相比于故障产生时对业务集群中全部业务设备进行分析而言,将需要排查的故障排查范围域由参与业务集群中任务的全部业务设备,缩小到在异常时间段内仅存在通信关系且上传第二通信元素组的异常业务设备,具体是异常业务设备产生的异常业务流的通信路径;极大地提高了业务集群中故障时的处理效率,避免业务集群中业务设备的算力浪费的同时,节省任务执行的成本。
图16示出了本申请一个示例性实施例提供的一种计算机设备的结构示意图。请参见图16,该计算机设备包括处理器1601、通信接口1602以及计算机可读存储介质1603。其中,处理器1601、通信接口1602以及计算机可读存储介质1603可通过总线或者其它方式连接。其中,通信接口1602用于接收和发送数据。计算机可读存储介质1603可以存储在计算机设备的存储器中,计算机可读存储介质1603用于存储计算机程序,计算机程序包括程序指令,处理器1601用于执行计算机可读存储介质1603存储的程序指令。处理器1601(或称CPU(Central Processing Unit,中央处理器))是计算机设备的计算核心以及控制核心,其适于实现一条或多条指令,具体适于加载并执行一条或多条指令从而实现相应方法流程或相应功能。
本申请实施例还提供了一种计算机可读存储介质(Memory),计算机可读存储介质是计算机设备中的记忆设备,用于存放程序和数据。可以理解的是,此处的计算机可读存储介质既可以包括计算机设备中的内置存储介质,当然也可以包括计算机设备所支持的扩展存储介质。计算机可读存储介质提供存储空间,该存储空间存储了计算机设备的处理系统。并且,在该存储空间中还存放了适于被处理器1601加载并执行的一条或多条的指令,这些指令可以是一个或多个的计算机程序(包括程序代码)。需要说明的是,此处的计算机可读存储介质可以是高速RAM存储器,也可以是非不稳定的存储器(non-volatile memory),例如至少一个磁盘存储器;可选的,还可以是至少一个位于远离前述处理器的计算机可读存储介质。
在一个实施例中,该计算机可读存储介质中存储有一条或多条指令;由处理器1601加载并执行计算机可读存储介质中存放的一条或多条指令,以实现上述业务集群的处理方法实施例中的相应步骤;该业务集群中包括多个业务设备和多个网元设备,任意两个业务设备之间通过至少一个网元设备进行通信连接;每个业务设备中包括至少一个GPU卡;具体实现中,计算机可读存储介质中的一条或多条指令由处理器1601加载并执行如下步骤:
获取业务集群中多个业务流的第一通信元素组,业务流是指从源端的业务设备中一个GPU卡,流向目的端的业务设备中一个GPU卡的数据流;第一通信元素组包括业务流的源端对应的GPU卡的标识和目的端对应的GPU卡的标识;
获取业务集群中异常业务设备的第二通信元素组,第二通信元素组包括异常业务设备中异常GPU卡的标识,以及与异常GPU卡进行通信的GPU卡的标识;
基于第一通信元素组与第二通信元素组,从业务集群中筛选出异常业务流;
根据异常业务流的源端对应的GPU卡和目的端对应的GPU卡,确定异常业务流的通信路径,通信路径中包括异常业务流依次经过的多个目标网元设备;
对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息。
在一种实现方式中,业务集群中包括X级组网,X级组网中包括层级分布的X层子网络,每层子网络中包括多个网元设备,X为整数且X≥2;计算机可读存储介质中的一条或多条指令由处理器1601加载并在执行根据异常业务流的源端对应的GPU卡和目的端对应的GPU卡,确定异常业务流的通信路径时,具体执行如下步骤:
根据异常业务流的源端对应的GPU卡,异常业务流的目的端对应的GPU卡,以及,X级组网中每层子网络中的网元设备,得到X层子网络之间的多个路径组;每个路径组中包括一个或多个等价路径,等价路径的两个路径端点分别为相邻的两层子网络中的网元设备;
根据多个路径组和异常业务流在X层子网络之间的流向,构建有向图;
对有向图进行路径搜索处理,得到异常业务流的通信路径。
在一种实现方式中,计算机可读存储介质中的一条或多条指令由处理器1601加载并在执行根据异常业务流的源端对应的GPU卡,异常业务流的目的端对应的GPU卡,以及,X级组网中每层子网络中的网元设备,得到X层子网络之间的多个路径组时,具体执行如下步骤:
根据异常业务流的源端对应的GPU卡的标识,在X级组网中的第一层子网络中确定异常业务流的起始网元设备;
根据异常业务流的目的端对应的GPU卡的标识,在X级组网中的第一层子网络中确定异常业务流的终点网元设备;
基于起始网元设备和终点网元设备,在X层子网络中进行路径连接处理,得到X层子网络之间的多个路径组。
在一种实现方式中,X层子网络中的任一层子网络表示为第i层子网络,i为整数且1≤i≤X;计算机可读存储介质中的一条或多条指令由处理器1601加载并在执行基于起始网元设备和终点网元设备,在X层子网络中进行路径连接处理,得到X层子网络之间的多个路径组时,具体执行如下步骤:
当i=1时,根据起始网元设备和第i+1层子网络,按照边界网关协议查询起始网元设备对应的多个第一路径组;每个第一路径组的对端设备为第i+1层子网络中的一个网元设备;
令i=i+1,若i=X,则根据每个第一路径组的对端设备和终点网元设备,按照边界网关协议查询每个第一路径组的对端设备分别对应的第X路径组;第X路径组的对端设备为终点网元设备;
其中,X层子网络之间的多个路径组包括:多个第一路径组,以及每个第一路径组的对端设备分别对应的第X路径组。
在一种实现方式中,计算机可读存储介质中的一条或多条指令由处理器1601加载并还执行如下步骤:
令i=i+1,若i<X,则根据多个第i-1路径组中每个第i-1路径组的对端设备和第i+1层子网络,按照边界网关协议查询每个第i-1路径组的对端设备分别对应的多个第i路径组;
当i=X时,根据每个第X-1路径组的对端设备和第X-1层子网络,按照边界网关协议查询每个第X-1路径组的对端设备分别对应的多个第X路径组;
令i=i-1,若i>2,则根据多个第2X-i-1路径组中每个第2X-i-1路径组的对端设备和第i-1层子网络,按照边界网关协议查询每个第i+1路径组的对端设备分别对应的多个第2X-i路径组;第2X-i路径组的对端设备为第i-1层子网络中的一个网元设备;
当i=2时,根据每个第2X-i-1路径组的对端设备和终点网元设备,按照边界网关协议查询每个第2X-i-1路径组的对端设备分别对应的第2X-2路径组;第2X-2路径组的对端设备为终点网元设备;
其中,X层子网络之间的多个路径组包括:多个第一路径组、多个第i路径组、多个第2X-i路径组以及第2X-i路径组的对端设备分别对应的第2X-2路径组。
在一种实现方式中,计算机可读存储介质中的一条或多条指令由处理器1601加载并在执行根据多个路径组和异常业务流在X层子网络之间的流向,构建有向图时,具体执行如下步骤:
将多个路径组中的多个网元设备作为有向图的节点;
按照异常业务流在X层子网络之间的流向,将多个节点进行连接,得到有向图。
在一种实现方式中,有向图中包括起始节点、终点节点和X-1个中间层,每个中间层中包括一个或多个中间节点,X-1个中间层中的任一个中间层表示为第j个中间层,j为整数且1≤j≤X-1;计算机可读存储介质中的一条或多条指令由处理器1601加载并在执行对有向图进行路径搜索处理,得到异常业务流的通信路径时,具体执行如下步骤:
当j=1时,从起始节点开始,遍历起始节点和第一个中间层中的各中间节点之间的路径,得到起始节点对应的多个第一权重值;一个第一权重值为起始节点和第一个中间层中一个中间节点之间路径的权重值;
令j=j+1,当j>X-1时,分别计算第j-1个中间层中各中间节点和终点节点之间路径的第X权重值;一个第X权重值为第j-1个中间层中一个中间节点和终点节点之间路径的权重值;
基于多个第一权重值和第X权重值,从有向图中确定出最短路径作为异常业务流的通信路径。
在一种实现方式中,计算机可读存储介质中的一条或多条指令由处理器1601加载并还执行如下步骤:
令j=j+1,若j≤X-1,则从第j-1个中间层中各中间节点开始,遍历第j个中间层中各中间节点和第j-1个中间层中各中间节点之间的路径,得到第j个中间层中各中间节点对应的多个第j权重值;
基于多个第一权重值,第j个中间层中各中间节点对应的多个第j权重值以及第X权重值,从有向图中确定出最短路径作为异常业务流的通信路径。
在一种实现方式中,计算机可读存储介质中的一条或多条指令由处理器1601加载并在执行获取业务集群中异常业务设备的第二通信元素组时,具体执行如下步骤:
获取业务集群上异常业务设备上报的一个或多个第二通信元素组;
对一个或多个第二通信元素组进行数据去重处理,得到去重处理后的第二通信元素组。
在一种实现方式中,计算机可读存储介质中的一条或多条指令由处理器1601加载并在执行对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息时,具体执行如下步骤:
获取一个或多个检测指标;检测指标包括以下至少一种:流量拥塞指标和拥塞程度指标;
采用一个或多个检测指标中的每个检测指标,对多个目标网元设备中的每个目标网元设备进行指标分析处理,得到每个目标网元设备在每个检测指标下的指标信息;
根据每个目标网元设备在每个检测指标下的指标信息,对异常业务流进行异常分析,得到异常业务流的异常信息;异常业务流的异常信息用于描述异常业务流的异常原因。
在一种实现方式中,网元设备中包括芯片;计算机可读存储介质中的一条或多条指令由处理器1601加载并还执行如下步骤:
获取参考路径,参考路径中包括:异常业务流的源端对应的GPU卡,和异常业务流的目的端对应的GPU卡之间的业务流,所经过的多个参考网元设备;参考路径是芯片基于异常业务流的第一通信元素组所规划得到的;
将参考路径上的多个参考网元设备,和通信路径上的多个目标网元设备进行比较,得到比较结果;
若比较结果为:多个参考网元设备和多个目标网元设备相同,且多个参考网元设备之间的通信连接顺序和多个目标网元设备之间的通信连接顺序相同,则触发执行对通信路径上的各个目标网元设备进行设备分析处理,得到异常业务流的异常信息的步骤;
若比较结果为:多个参考网元设备和多个目标网元设备不相同,或者多个参考网元设备之间的通信连接顺序和多个目标网元设备之间的通信连接顺序不相同,则对芯片进行异常原因分析,得到芯片的异常信息。
在一种实现方式中,计算机可读存储介质中的一条或多条指令由处理器1601加载并还执行如下步骤:
根据异常业务流的异常信息,对业务集群进行集群调整处理,得到调整后的业务集群;
其中,调整后的业务集群不存在异常业务流。
在一种实现方式中,计算机可读存储介质中的一条或多条指令由处理器1601加载并在执行根据异常业务流的异常信息,对业务集群进行集群调整处理,得到调整后的业务集群时,具体执行如下步骤:
若异常业务流的异常信息所描述的异常原因为,异常业务流的源端对应的GPU卡故障,则在业务集群中对异常业务流的源端对应的GPU卡进行替换处理,得到替换后的业务集群。
基于同一发明构思,本申请实施例中提供的计算机设备解决问题的原理与有益效果与本申请方法实施例中业务集群的处理方法解决问题的原理和有益效果相似,可以参见方法的实施的原理和有益效果,为简洁描述,在这里不再赘述。
本申请实施例还提供一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述业务集群的处理方法。
本领域普通技术对象可以意识到,结合本申请中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术对象可以对每个特定的应用,使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时,全部或部分地产生按照本申请实施例所述的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程设备。计算机指令可以存储在计算机可读存储介质中,或者通过计算机可读存储介质进行传输。计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如,同轴电缆、光纤、数字线(DSL))或无线(例如,红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据处理设备。可用介质可以是磁性介质(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如,固态硬盘(Solid State Disk,SSD))等。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术对象在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。
Claims (17)
1.一种业务集群的处理方法,其特征在于,所述业务集群中包括多个业务设备和多个网元设备,任意两个所述业务设备之间通过至少一个所述网元设备进行通信连接;每个所述业务设备中包括至少一个GPU卡;所述方法包括:
获取所述业务集群中多个业务流的第一通信元素组,所述业务流是指从源端的所述业务设备中一个所述GPU卡,流向目的端的所述业务设备中一个所述GPU卡的数据流;所述第一通信元素组包括所述业务流的源端对应的所述GPU卡的标识和目的端对应的所述GPU卡的标识;
获取所述业务集群中异常业务设备的第二通信元素组,所述第二通信元素组包括所述异常业务设备中异常GPU卡的标识,以及与所述异常GPU卡进行通信的GPU卡的标识;
基于所述第一通信元素组与所述第二通信元素组,从所述业务集群中筛选出异常业务流;
根据所述异常业务流的源端对应的所述GPU卡和目的端对应的所述GPU卡,确定所述异常业务流的通信路径,所述通信路径中包括所述异常业务流依次经过的多个目标网元设备;
对所述通信路径上的各个所述目标网元设备进行设备分析处理,得到所述异常业务流的异常信息。
2.如权利要求1所述的方法,其特征在于,所述业务集群中包括X级组网,所述X级组网中包括层级分布的X层子网络,每层子网络中包括多个网元设备,X为整数且X≥2;所述根据所述异常业务流的源端对应的所述GPU卡和目的端对应的所述GPU卡,确定所述异常业务流的通信路径,包括:
根据所述异常业务流的源端对应的所述GPU卡,所述异常业务流的目的端对应的所述GPU卡,以及,所述X级组网中每层子网络中的网元设备,得到所述X层子网络之间的多个路径组;每个路径组中包括一个或多个等价路径,所述等价路径的两个路径端点分别为相邻的两层子网络中的网元设备;
根据所述多个路径组和所述异常业务流在所述X层子网络之间的流向,构建有向图;
对所述有向图进行路径搜索处理,得到所述异常业务流的通信路径。
3.如权利要求2所述的方法,其特征在于,所述根据所述异常业务流的源端对应的所述GPU卡,所述异常业务流的目的端对应的所述GPU卡,以及,所述X级组网中每层子网络中的网元设备,得到所述X层子网络之间的多个路径组,包括:
根据所述异常业务流的源端对应的所述GPU卡的标识,在所述X级组网中的第一层子网络中确定所述异常业务流的起始网元设备;
根据所述异常业务流的目的端对应的所述GPU卡的标识,在所述X级组网中的第一层子网络中确定所述异常业务流的终点网元设备;
基于所述起始网元设备和所述终点网元设备,在所述X层子网络中进行路径连接处理,得到所述X层子网络之间的多个路径组。
4.如权利要求3所述的方法,其特征在于,所述X层子网络中的任一层子网络表示为第i层子网络,i为整数且1≤i≤X;所述基于所述起始网元设备和所述终点网元设备,在所述X层子网络中进行路径连接处理,得到所述X层子网络之间的多个路径组,包括:
当i=1时,根据所述起始网元设备和第i+1层子网络,按照边界网关协议查询所述起始网元设备对应的多个第一路径组;每个第一路径组的对端设备为所述第i+1层子网络中的一个网元设备;
令i=i+1,若i=X,则根据每个第一路径组的对端设备和所述终点网元设备,按照所述边界网关协议查询每个第一路径组的对端设备分别对应的第X路径组;所述第X路径组的对端设备为所述终点网元设备;
其中,所述X层子网络之间的多个路径组包括:所述多个第一路径组,以及每个第一路径组的对端设备分别对应的第X路径组。
5.如权利要求4所述的方法,其特征在于,所述方法还包括:
令i=i+1,若i<X,则根据多个第i-1路径组中每个第i-1路径组的对端设备和第i+1层子网络,按照所述边界网关协议查询每个第i-1路径组的对端设备分别对应的多个第i路径组;
当i=X时,根据每个第X-1路径组的对端设备和第X-1层子网络,按照所述边界网关协议查询每个第X-1路径组的对端设备分别对应的多个第X路径组;
令i=i-1,若i>2,则根据多个第2X-i-1路径组中每个第2X-i-1路径组的对端设备和第i-1层子网络,按照所述边界网关协议查询每个第i+1路径组的对端设备分别对应的多个第2X-i路径组;所述第2X-i路径组的对端设备为所述第i-1层子网络中的一个网元设备;
当i=2时,根据每个第2X-i-1路径组的对端设备和所述终点网元设备,按照所述边界网关协议查询每个第2X-i-1路径组的对端设备分别对应的第2X-2路径组;所述第2X-2路径组的对端设备为所述终点网元设备;
其中,所述X层子网络之间的多个路径组包括:所述多个第一路径组、所述多个第i路径组、所述多个第2X-i路径组以及第2X-i路径组的对端设备分别对应的第2X-2路径组。
6.如权利要求2-5任一项所述的方法,其特征在于,所述根据所述多个路径组和所述异常业务流在所述X层子网络之间的流向,构建有向图,包括:
将所述多个路径组中的多个网元设备作为有向图的节点;
按照所述异常业务流在所述X层子网络之间的流向,将多个节点进行连接,得到有向图。
7.如权利要求6所述的方法,其特征在于,所述有向图中包括起始节点、终点节点和X-1个中间层,每个中间层中包括一个或多个中间节点,所述X-1个中间层中的任一个中间层表示为第j个中间层,j为整数且1≤j≤X-1;所述对所述有向图进行路径搜索处理,得到所述异常业务流的通信路径,包括:
当j=1时,从所述起始节点开始,遍历所述起始节点和第一个中间层中的各中间节点之间的路径,得到所述起始节点对应的多个第一权重值;一个第一权重值为所述起始节点和所述第一个中间层中一个中间节点之间路径的权重值;
令j=j+1,当j>X-1时,分别计算第j-1个中间层中各中间节点和所述终点节点之间路径的第X权重值;一个第X权重值为所述第j-1个中间层中一个中间节点和所述终点节点之间路径的权重值;
基于所述多个第一权重值和所述第X权重值,从所述有向图中确定出最短路径作为所述异常业务流的通信路径。
8.如权利要求7所述的方法,其特征在于,所述方法还包括:
令j=j+1,若j≤X-1,则从所述第j-1个中间层中各中间节点开始,遍历所述第j个中间层中各中间节点和第j-1个中间层中各中间节点之间的路径,得到所述第j个中间层中各中间节点对应的多个第j权重值;
基于所述多个第一权重值,所述第j个中间层中各中间节点对应的多个第j权重值以及所述第X权重值,从所述有向图中确定出最短路径作为所述异常业务流的通信路径。
9.如权利要求1所述的方法,其特征在于,所述获取所述业务集群中异常业务设备的第二通信元素组,包括:
获取所述业务集群上异常业务设备上报的一个或多个第二通信元素组;
对所述一个或多个第二通信元素组进行数据去重处理,得到去重处理后的所述第二通信元素组。
10.如权利要求1所述的方法,其特征在于,所述对所述通信路径上的各个所述目标网元设备进行设备分析处理,得到所述异常业务流的异常信息,包括:
获取一个或多个检测指标;所述检测指标包括以下至少一种:流量拥塞指标和拥塞程度指标;
采用所述一个或多个检测指标中的每个检测指标,对所述多个目标网元设备中的每个目标网元设备进行指标分析处理,得到每个目标网元设备在每个所述检测指标下的指标信息;
根据每个目标网元设备在每个所述检测指标下的指标信息,对所述异常业务流进行异常分析,得到所述异常业务流的异常信息;所述异常业务流的异常信息用于描述所述异常业务流的异常原因。
11.如权利要求1或10所述的方法,其特征在于,所述网元设备中包括芯片;所述对所述通信路径上的各个所述目标网元设备进行设备分析处理,得到所述异常业务流的异常信息之前,还包括:
获取参考路径,所述参考路径中包括:所述异常业务流的源端对应的所述GPU卡,和所述异常业务流的目的端对应的所述GPU卡之间的业务流,所经过的多个参考网元设备;所述参考路径是所述芯片基于所述异常业务流的第一通信元素组所规划得到的;
将所述参考路径上的所述多个参考网元设备,和所述通信路径上的所述多个目标网元设备进行比较,得到比较结果;
若所述比较结果为:所述多个参考网元设备和所述多个目标网元设备相同,且所述多个参考网元设备之间的通信连接顺序和所述多个目标网元设备之间的通信连接顺序相同,则触发执行所述对所述通信路径上的各个所述目标网元设备进行设备分析处理,得到所述异常业务流的异常信息的步骤;
若所述比较结果为:所述多个参考网元设备和所述多个目标网元设备不相同,或者所述多个参考网元设备之间的通信连接顺序和所述多个目标网元设备之间的通信连接顺序不相同,则对所述芯片进行异常原因分析,得到所述芯片的异常信息。
12.如权利要求1所述的方法,其特征在于,所述方法还包括:
根据所述异常业务流的异常信息,对所述业务集群进行集群调整处理,得到调整后的所述业务集群;
其中,调整后的所述业务集群不存在所述异常业务流。
13.如权利要求12所述的方法,其特征在于,所述根据所述异常业务流的异常信息,对所述业务集群进行集群调整处理,得到调整后的所述业务集群,包括:
若所述异常业务流的异常信息所描述的异常原因为,所述异常业务流的源端对应的所述GPU卡故障,则在所述业务集群中对所述异常业务流的源端对应的所述GPU卡进行替换处理,得到替换后的所述业务集群。
14.一种业务集群的处理装置,其特征在于,所述业务集群中包括多个业务设备和多个网元设备,任意两个所述业务设备之间通过至少一个所述网元设备进行通信连接;每个所述业务设备中包括至少一个GPU卡;所述装置包括:
获取单元,用于获取所述业务集群中多个业务流的第一通信元素组,所述业务流是指从源端的所述业务设备中一个所述GPU卡,流向目的端的所述业务设备中一个所述GPU卡的数据流;所述第一通信元素组包括所述业务流的源端对应的所述GPU卡的标识和目的端对应的所述GPU卡的标识;
所述获取单元,还用于获取所述业务集群中异常业务设备的第二通信元素组,所述第二通信元素组包括所述异常业务设备中异常GPU卡的标识,以及与所述异常GPU卡进行通信的GPU卡的标识;
处理单元,用于基于所述第一通信元素组与所述第二通信元素组,从所述业务集群中筛选出异常业务流;
所述处理单元,还用于根据所述异常业务流的源端对应的所述GPU卡和目的端对应的所述GPU卡,确定所述异常业务流的通信路径,所述通信路径中包括所述异常业务流依次经过的多个目标网元设备;
所述处理单元,还用于对所述通信路径上的各个所述目标网元设备进行设备分析处理,得到所述异常业务流的异常信息。
15.一种计算机设备,其特征在于,包括:
处理器,适于执行计算机程序;
计算机可读存储介质,所述计算机可读存储介质中存储有计算机程序,所述计算机程序被所述处理器执行时,实现如权利要求1-13任一项所述的业务集群的处理方法。
16.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有计算机程序,所述计算机程序适于被处理器加载并执行如权利要求1-13任一项所述的业务集群的处理方法。
17.一种计算机程序产品,其特征在于,所述计算机程序产品包括计算机指令,所述计算机指令被处理器执行时实现如权利要求1-13任一项所述的业务集群的处理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202411892142.3A CN119341896B (zh) | 2024-12-20 | 2024-12-20 | 业务集群的处理方法、装置、设备、介质及程序产品 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202411892142.3A CN119341896B (zh) | 2024-12-20 | 2024-12-20 | 业务集群的处理方法、装置、设备、介质及程序产品 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN119341896A CN119341896A (zh) | 2025-01-21 |
CN119341896B true CN119341896B (zh) | 2025-03-25 |
Family
ID=94270997
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202411892142.3A Active CN119341896B (zh) | 2024-12-20 | 2024-12-20 | 业务集群的处理方法、装置、设备、介质及程序产品 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN119341896B (zh) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110752952A (zh) * | 2019-10-25 | 2020-02-04 | 腾讯科技(深圳)有限公司 | 网络故障定位方法、装置、网络设备及计算机存储介质 |
CN117714325A (zh) * | 2023-12-26 | 2024-03-15 | 北京字跳网络技术有限公司 | 服务器集群的网络监测方法、装置、电子设备及存储介质 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10375193B2 (en) * | 2014-11-26 | 2019-08-06 | Hughes Network Systems, Llc | Source IP address transparency systems and methods |
WO2024045002A1 (en) * | 2022-08-31 | 2024-03-07 | Lenovo (Beijing) Ltd. | Multicast scheme improvement for 5g virtual network |
CN118741568A (zh) * | 2023-03-29 | 2024-10-01 | 中国联合网络通信集团有限公司 | 网络质量检测系统、方法、设备和介质 |
-
2024
- 2024-12-20 CN CN202411892142.3A patent/CN119341896B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110752952A (zh) * | 2019-10-25 | 2020-02-04 | 腾讯科技(深圳)有限公司 | 网络故障定位方法、装置、网络设备及计算机存储介质 |
CN117714325A (zh) * | 2023-12-26 | 2024-03-15 | 北京字跳网络技术有限公司 | 服务器集群的网络监测方法、装置、电子设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN119341896A (zh) | 2025-01-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20200021511A1 (en) | Performance analysis for transport networks using frequent log sequence discovery | |
CN103001811B (zh) | 故障定位方法和装置 | |
CN112564964B (zh) | 一种基于软件定义网络的故障链路检测与恢复方法 | |
CN114124204B (zh) | 一种双备路olp光线路保护切换方法及装置 | |
JP5251538B2 (ja) | 異常箇所特定プログラム、異常箇所特定装置、異常箇所特定方法 | |
CN113542074B (zh) | 一种可视化管理kubernetes集群的东西向网络流量的方法及系统 | |
CN114401516B (zh) | 一种基于虚拟网络流量分析的5g切片网络异常检测方法 | |
CN112769605A (zh) | 一种异构多云的运维管理方法及混合云平台 | |
CN112559237B (zh) | 运维系统排障方法、装置、服务器和存储介质 | |
CN116723136B (zh) | 应用fcm聚类算法的网络检测数据的方法 | |
CN113938407A (zh) | 基于带内网络遥测系统的数据中心网络的故障检测方法及装置 | |
Guo et al. | FullSight: A feasible intelligent and collaborative framework for service function chains failure detection | |
KR102006149B1 (ko) | 망분리 환경에서의 중계망 관제장치 및 관제방법 | |
CN117729576A (zh) | 告警监控方法、装置、设备及存储介质 | |
CN115049493B (zh) | 一种区块链数据追踪方法、装置及电子设备 | |
CN110071843B (zh) | 一种基于流路径分析的故障定位方法及装置 | |
CN111884859A (zh) | 一种网络故障诊断方法、装置及可读存储介质 | |
CN119341896B (zh) | 业务集群的处理方法、装置、设备、介质及程序产品 | |
CN117896163B (zh) | 一种网络流量监控系统 | |
CN118487990A (zh) | 服务器集群流量控制方法、装置和服务器集群 | |
CN117376107A (zh) | 一种智能化网络管理方法、系统、计算机设备及介质 | |
CN117714325A (zh) | 服务器集群的网络监测方法、装置、电子设备及存储介质 | |
CN112866009B (zh) | 一种综合服务站虚拟网络故障诊断方法及装置 | |
CN112491601B (zh) | 流量拓扑生成方法、装置、存储介质及电子设备 | |
CN114050964B (zh) | 基于数据网业务路径变化对网络异常进行预判的方法 |
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 |