CN110113205B - 一种基于软件定义网络技术的网络排障系统及其工作方法 - Google Patents

Abstract

本发明公开了一种基于软件定义网络技术的网络排障系统及其工作方法，系统主要包括消息拦截器、监控平台、交互客户端、故障检测应用和探针生成器。拦截器截获控制器的OpenFlow报文，并为新流表追加镜像等动作后再下发，匹配表项的数据包将被镜像至监控平台处进行包括旅途组装、钩子触发、数据统计存储等处理过程，用户通过客户端与故障检测应用查询处理结果并加以解释，从而完成网络监控与故障分析功能。本发明在现有网络及硬件条件下，提供了一个包括问题抽象、查询语言、监控平台与故障检测应用等组件在内的无缝自动化排障的解决方案，适用于数据中心网络环境，并可覆盖多种常见网络故障，另还提供了设计良好的API接口以便于功能扩展。

Description

一种基于软件定义网络技术的网络排障系统及其工作方法

技术领域

本发明涉及网络技术领域，具体涉及一种基于软件定义网络技术的网络排障系统及其工作方法。

背景技术

随着数据中心网络规模的不断扩大，结构和功能日趋复杂，流量快速增长，如云计算、云存储与流媒体服务等新型网络应用层出不穷，无疑对现行网络的配置、运行与管理提出了更加严峻的挑战。在此背景下，软件定义网络(Software Defined Networking,SDN)这种新型网络架构应运而生，并通过其数控分离以及管控软件化、集中化的核心思想，充分满足了数据中心服务器集中管控的需求，增加了实际配置和操作的灵活性与可控性，较好适应各种网络应用需求的同时，还有效降低了运维工作的难度，目前已被广泛应用于各大数据中心。

作为承载包括网络搜索、社交媒体、电子商务等在线服务的关键基础设施，数据中心网络的任何故障都会导致服务性能降低甚至不可用，由此造成的损失难以估量。因此，快速排障的需求向来十分迫切。网络的整体行为由转发状态控制，后者在实际运行过程中则可能被各种网络应用不断修改从而变得不可预测。网络状态跨设备分布以及网络应用多样化的特点，使得网络排障从来不是一个简单的任务，在数据中心网络等大规模复杂网络环境中，排障问题则更加棘手。

尽管如今网络因部署并承载着更多的网络协议与网络应用而变得日益复杂，但是用于网络排障的工具仍然十分原始：运维人员往往只能依靠traceroute/ping、SNMP与NetFlow等初级工具来诊断故障。由于工具功能有限，排障过程中人工的大量涉入在所难免，运维人员不得不依赖其专业技巧与实践经验去定位、分析每一次故障。显然，目前的排障手段距离自动化排障仍然十分遥远。

目前的数据中心网络排障系统往往将流量采集与故障分析过程解耦合，经常借助于不同的工具与系统完成各自功能后，再由人工涉入实现串联，并不能实现无缝自动化排障，而这同时也意味着更长的故障持续时间，更高的运维成本，新型网络应用的部署进程也随之放缓。

发明内容

发明目的：是为了弥补现有网络排障工具的不足，本发明提出一种基于软件定义网络技术的网络排障系统及其工作方法，在现有网络及硬件条件下，提供一个无缝自动化的网络排障解决方案，可适用于数据中心网络环境，并能够实时获知网络状态，支持多种常见异常场景的检测与分析。

技术方案：本发明所述的一种基于软件定义网络技术的网络排障系统，包括：

消息拦截器，用于拦截控制器与交换机通信的OpenFlow报文，并为控制器下发的每个流表项追加镜像与编码两个动作后再下发至交换机，使得匹配表项的数据包将被镜像至监控平台；

监控平台，用于捕获镜像数据包，对数据包进行拓扑排序，得到由数据包在网络中各跳位置处产生的镜像包构成的有序链表；还用于对捕获的数据进行统计；以及根据查询端的查询条件执行匹配操作并返回查询结果；

查询端，用于向监控平台发送查询条件并接收查询结果。

进一步地，所述监控平台根据镜像数据包中包含的交换机及其转发状态信息进行拓扑排序。

进一步地，所述交换机及其转发状态信息包括交换机ID、输出端口号与流表版本号。

进一步地，所述查询端使用包括以下过滤条件的数据包进行查询：数据包头部、交换机ID或数据路径ID(dpid)、输入端口号(inport)、输出端口号(outport)以及交换机状态(流表版本号，version)。

进一步地，所述查询端包括：交互客户端，用于接收用户输入的查询语句，将其转换成过滤规则后下发至监控平台，并将其返回的信息呈现给用户；以及故障检测应用，用于提供网络故障的发现与分析功能，并通过查询排序信息与统计信息、释放探测包进行故障定位。

进一步地，所述监控平台还用于对每条有序链表执行异常检测操作，对于检测出异常的记录存储其完整信息，对于正常记录则仅存储统计的聚合数据。

根据上述的网络排障系统的工作方法，包括以下步骤：

1)消息拦截器分别建立其与控制器及与各交换机之间的OpenFlow连接；

2)拦截器截获控制器下发的携带新流表项的OpenFlow报文，向其对应流表项中追加编码与镜像两个动作后再下发至交换机；

3)监控平台捕获到镜像数据包，并对其进行拓扑排序、数据统计、以及信息存储；

4)查询端输入描述网络流数据包旅途特征的查询语句，进行实时与历史查询，并配合注入探针重放流量的方式进行故障定位。

有益效果：与现有排障系统相比，本发明具有以下有益效果：

1、SDN解决方案：集中式控制便于测量逻辑的统一部署，基于原生的OpenFlow协议和控制器，以及SDN交换机普遍支持的流表动作，易于实现；

2、抽象建模：提出数据包旅途排障抽象，将故障现象与可疑流量(网络属性、转发行为)相关联，从而支持基于该抽象构造查询条件，对流量进行筛选与匹配以简化排障工作；

3、灵活查询：提出一种与上述抽象相配套的查询语言，它结合拓扑路径、交换机状态等信息，描述数据包在网络中经历的旅途特征，将对特定数据包旅途的查询过程等价转换为对该数据包头部字段、路径以及沿途交换机状态的匹配过程，根据匹配结果感知网络状态；

4、带外传输、集中处理：镜像流量在交换机中编码插入状态信息后通过带外传输，不影响原数据包的转发。由专门的收集服务器(集群)集中处理，充分利用了交换机提供的网络内部可见性与端系统的计算能力；

5、主动测量与被动测量相结合：一方面收集现行流量进行分析处理，正常流量存储聚合数据，异常(环路、丢包)流量完整存储；另一方面可构造探测包并注入至网络中的指定位置以重放历史流量或发送调试流量，帮助恢复历史数据与发现异常模式；

6、面向数据中心网络的扩展(可选)：通过分析数据中心网络流量特点，针对占总流量绝大多数的TCP流量中的特殊数据包(如SYN/FIN/RST)与含Debug标记的调试流量包，预先安装一批少量但精心设计的OpenFlow镜像流表项，在全网范围内捕捉到一致的、完整的相关数据包轨迹用于分析。一方面尽可能减少了镜像带来的额外流量；另一方面也避免了因采样的盲目性与随机性导致测量结果不准确的问题。

附图说明

图1为根据本发明实施例的基于软件定义网络技术的网络排障系统架构图；

图2为根据本发明实施例的数据包旅途抽象实例示意图；

图3为根据本发明实施例的消息拦截器组成结构图；

图4为根据本发明实施例的监控平台工作原理图。

具体实施方式

下面结合附图对本发明的技术方案进行进一步说明。应当了解，以下提供的实施例仅是为了详尽地且完全地公开本发明，并且向所属技术领域的技术人员充分传达本发明的技术构思，本发明还可以用许多不同的形式来实施，并且不局限于此处描述的实施例。对于表示在附图中的示例性实施方式中的术语并不是对本发明的限定。

图1示出了根据本发明实施例的网络排障系统架构，该系统是在现有网络及硬件条件下提出的一个包括问题抽象、查询语言、监控平台与故障检测应用等组件的无缝自动化排障系统，适用于数据中心网络环境，能够实时获知网络状态，支持多种异常场景的检测与分析，另还提供了设计良好的API接口以便于功能扩展。如1图所示，系统包括以下组件：

消息拦截器：拦截控制器与交换机通信的OpenFlow报文，并为控制器下发的每个流表项追加镜像与编码两个动作后再下发至交换机。

监控平台：捕获镜像数据包，并对其进行旅途组装、钩子触发、数据统计、异常检测和信息存储等处理操作，还提供持久化的异常旅途记录以及多种不同类型的计数器以供用户查询分析。这里的镜像包不仅携带有原数据包的完整头部，还在特殊头部字段处编码有交换机及其转发状态信息，包括交换机ID、输出端口号与流表版本号。特殊头部字段指在系统中未使用的头部字段，在实际部署时可由用户自行指定。

交互客户端：接收用户输入的查询语句，将其转换成旅途过滤规则后下发至监控平台，并将其返回的旅途信息呈现给用户进行监控与分析。

故障检测应用：提供特定网络故障的发现与分析功能，并通过查询旅途与计数器信息、释放探测包等机制帮助理解、定位与解决故障。故障检测应用可包括丢包、环路、高延迟、负载不均衡等常见故障场景，每种故障各自对应一个独立应用。

探针生成器：接收来自故障检测应用的调用请求，利用模板定制生成探测包，将其某特殊标志位置位后发送至网络中的指定位置以重放历史流量或发送调试流量。

本发明提出了一种叫做数据包旅途的概念抽象，其对应实例是一个由同一数据包在网络中各跳位置处产生的镜像包构成的有序链表。图2是数据包旅途实例示意图。在某一时段内，监控平台所包含的收集服务器捕获到来自不同交换机，但属于同一数据包的镜像包。收集服务器根据镜像包携带的头部、转发路径(交换机ID与输入/输出端口号)以及交换机状态信息(流表版本号)，分别构造对应的Postcard实例对象。对象的本质是一种数据结构，内部封装了关于该实体的各项属性及方法。这里的postcard对象可以认为是一个对应镜像包的数据封装实体，内部包含数据包头部、交换机ID、输出端口号与当前交换机的流表版本号等信息。之后将这些Postcard对象经由拓扑排序串联成一个有序链表，即为一个数据包旅途(Packet Journey)实例。

作为一种网络抽象，数据包旅途揭示了一个数据包在网络中流经的真实情况，包括转发路径、以及每一跳交换机的状态及对应的包修改，从而可以回答如下问题：

(1)由初始头部可知，该数据包刚进入网络时是什么样子；

(2)由交换机ID与输出端口可知，该数据包被转发至何处；

(3)由头部修改情况可知，该数据包在转发过程中是如何变化的；

(4)由流表状态与对应流表内容可知，该数据包为什么如上转发。

一个数据包旅途实例在收集服务器处被组装完成后，交互式客户端和检测应用程序可通过一种叫做PJF(Packet Journey Filter)的正则化语言，依据头部信息、特定路径、途径的交换机状态，对其进行查询匹配。JPF是为了与上述数据包旅途抽象机制相配套，本发明所提出的一种网络查询语言，是一种语法类似于正则表达式的形式化语言，它结合拓扑路径、交换机状态等信息，描述数据包在网络中经历的旅途特征，将对特定数据包旅途的查询过程等价转换为对该数据包头部字段、路径以及沿途交换机状态的匹配过程，根据匹配结果来感知网络状态。利用该语言，用户能够根据故障现象构造过滤条件，以此对数据包旅途记录进行查询，从而可将故障现象与可疑流量(网络属性与转发行为)相互关联以便于排障。

一般地，一条PJF语句由若干个PF(Postcard Filter)组成，PF用于在某交换机处匹配一个特定数据包，它由若干个过滤条件组成：数据包头部、交换机ID或数据路径ID(dpid)、输入端口号(inport)、输出端口号(outport)以及交换机状态(流表版本号，version)。一般地，一个PF写作如下形式：--bpf[not]<BPF>--dpid[not]<switch ID>--inport[not]<input port>--outport[not]<output port>--version[not]<version>

其中，<BPF>是伯克利数据包过滤表达式(Berkeley Packet FilterExpression)，用于描述数据包头部字段特征，“not”可选，用于取非。一个PF至少包含以上过滤条件中的任意一个。例如，匹配一个源IP为A，从除了P之外的任意端口进入交换机S的IP数据包，对应PF可写作：

--bpf“ip src A”--dpid S--inport not P

一条PJF语句是由若干个PF组成的正则表达式，其中每个PF都由双括号括起。简单地，一条由X和Y两个PF组成的PJF语句，其常见用法示例如下：

·以X开始：^{{X}}

·以X结束：{{X}}$

·经过X：{{X}}

·经过链路XY：{{X}}{{Y}}

·先经过X，再经过Y：{{X}}.*{{Y}}

·经过X，但从未到达Y：^{{X}}[^{{Y}}]*$

基于PJF已经能够描述一些常见的网络故障问题，如：

·可达性：主机A无法与主机B通信

PJF描述：^{{--bpf“ip src A and dst B”--dpid X--inport p1}}[^{{--dpidY--outport p2}}]*$

说明：X、p1分别是与主机A直连的交换机与输入端口，Y、p2分别是与主机B直连的交换机与输出端口。

·必经点：特定类型流量未经过指定中途点

PJF描述：{{--bpf“traffic_class”--dpid not“waypoint_id”}}{{--dpid not“waypoint_id”}}*$

说明：traffic_class描述流量类型，waypoint_id指该类型流量必须经过的特定交换机。

上述系统基于软件定义网络技术完成排障逻辑部署，用户启动交互客户端与故障检测应用，分别查询并分析监控平台捕获的来自SDN交换机的镜像流量与主动注入的探测包对应的旅途记录及相关计数器信息，达到网络状态感知与故障诊断的目的。此外系统还提供丰富的故障相关信息，帮助快速定位、分析与解决故障，常见故障场景如丢包、环路、负载不均衡等。

系统具体工作流程如下：

1)启动消息拦截器，分别建立拦截器与控制器、拦截器与各交换机间的OpenFlow连接，此后控制器与各交换机之间的每条消息都将被消息拦截器代理转发。

图3是消息拦截器的组成结构图，拦截器由消息代理与报文修改两个子模块构成。前者用于截获与发送OpenFlow协议报文，后者用于向前者所截获到的FLOW_ADD、FLOW_MOD与PACKET_OUT报文对应流表项的动作列表中追加如下两个动作(Action)：

转发至镜像端口：匹配该表项的数据包除正常转发外，交换机还会为其拷贝生成一个副本经镜像端口发往收集服务器。该表项指为消息拦截器截获的FLOW_ADD、FLOW_MOD与PACKET_OUT报文中所包含的流表项，因为这些报文都会携带一个要下发至交换机的新流表项。

插入交换机状态：将镜像交换机的ID、输出端口号以及当前流表版本号编码至镜像包的未使用字段中。

根据上述策略，由于对每个新下发的流表项都追加镜像动作，匹配这些表项的数据包都被镜像，会导致镜像流量较大，因此一般适用于中小型网络；而对于大型复杂网络，本发明还提供选择性镜像策略，即预先下发针对关键流量数据包的流表项，仅镜像匹配这部分表项的数据包。具体可结合数据中心网络流量特点，针对占总流量绝大多数的TCP流量中的特殊数据包(如SYN/FIN/RST)与含Debug标记的调试流量包，预先安装少量但精心设计的OpenFlow镜像流表项，在全网范围内捕捉到一致的、完整的相关数据包轨迹用于分析。用户可根据真实网络环境情况自行选择：如在中小型规模、利用率较低的网络中，本功能无需开启；而在数据中心网络等大规模、利用率较高的网络中，为降低网络负载，保持网络较高性能，建议采用本功能对系统性能进行优化。

本发明采用了带外传输和集中处理的遥测流量处理方法，镜像流量在交换机中编码插入状态信息后通过带外传输，不影响原数据包的转发。由专门的收集服务器(集群)集中处理，充分利用了交换机提供的网络内部可见性与端系统的计算能力。

2)启动监控平台，开始如图4所示的工作流程：

a)镜像捕获：在此阶段，监控平台通过部署多个处理服务器以扩展其处理能力。平台参考MapReduce的shuffle过程，利用哈希函数映射的方法确定其目的服务器，从而将由镜像包构造而来的Postcard均匀发送至各收集服务器上，同时确保Postcard的空间局部性，即同一个数据包的所有镜像包最终将被发送到同一个服务器进行处理。

b)旅途组装：每当某处理服务器从其它服务器处收到属于同一个数据包的所有Postcard后，服务器就会利用交换机ID、输出端口结合网络拓扑等信息对它们进行一次拓扑排序，排序后得到的有序链表即为一条数据包旅途记录。具体的拓扑排序方法例如：把整个网络拓扑看成一个图，其中交换机为图的顶点，交换机之间的链路为图的边，根据各Postcard中包含的交换机ID和输出端口配合拓扑信息(包含交换机以及各链路情况)确定真实路径的各段链路，再结合网络拓扑图信息确定该路径中的各个交换机的先后顺序，进而得到对应的Postcard的先后顺序，最终得到一个Postcard有序链表，即一条数据包旅途记录。

c)钩子触发：利用交互客户端或故障检测应用排障时，根据其调试策略有时会预先下发相应查询条件，处理服务器会维护一个包含这部分查询语句的总集合，并记录各查询对应的应用程序。而一旦有数据包旅途记录组装完成，服务器都会将它与其维护的查询集合中的每一个查询条件执行匹配操作，并在匹配成功时向应用程序发出通知，并返回具体的数据包旅途信息。该过程类似钩子机制(或回调)，在特定事件发生时触发相关方法。其中查询语句为应用程序下发至收集服务器的钩子，旅途与查询匹配成功即事件发生，通知并发送旅途信息给下发钩子的应用程序就是为此钩子设置的处理方法(回调函数)。

d)数据统计：对于捕获到的流量，处理服务器还将统计网络流五元组、链路ID、数据包个数、数据包大小等数据，并定期存储至数据库中，由后者将数据聚合汇总成不同类型的计数器。探测包旅途仅作实时匹配而无需存储。

e)异常检测：对于未能触发钩子的数据包旅途记录，则检查该旅途是否存在异常，如丢包或环路，将异常旅途记录打上相应异常标记后完整存储，正常旅途记录则不予存储。

f)信息存储：存储异常旅途记录和多种类型的计数器。

g)历史查询：在故障发生后再利用应用程序排障时，可以通过向持久化的旅途记录以及计数器发起查询以获取足够的故障相关信息帮助排障。持久化的旅途记录是指已经存储到数据库磁盘中的旅途记录，这是为了与监控平台实时拼装好的旅途记录相互区分，后者存在处理服务器的内存中，还未进行持久化存储操作。

3)启动交互客户端，输入描述网络流数据包旅途特征的查询语句，对旅途记录进行实时与历史查询以完成网络监控与状态感知。

4)运维人员接收到网络异常报告后，如应用程序性能较低，出现如高延迟、低吞吐量、超时甚至目的地不可达等情况，可先通过交互式客户端输入描述具体旅途特征的PJF语句，通过分析返回的旅途记录获知可能的故障原因，如设备故障、链路拥塞、丢包、环路等情况，然后根据异常类型启动相应故障检测应用，后者通过实时、历史查询旅途记录与计数器，以及注入探针重放流量等方式，对该网络异常问题进行定性、定量分析。

通过采用上述主动测量与被动测量相结合的网络测量方法，一方面收集现行流量进行分析处理，另一方面还可构造探测包并注入到网络中的指定位置以重放历史流量或发送调试流量，帮助恢复历史数据与发现异常模式。

应当了解，虽然以上采用特定次序描绘了各操作，但这并不应该理解为要求必须以所示出的特定次序或以顺序次序执行。在一定环境下，步骤中的一个或多个可以忽略，或者并行执行，或者以其他顺序来执行，可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本发明的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地，在单个实现的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实现中。

Claims (9)

1.一种基于软件定义网络技术的网络排障系统，其特征在于，所述系统包括：

消息拦截器，用于拦截控制器与交换机通信的OpenFlow报文，并为控制器下发的每个流表项追加镜像与编码两个动作后再下发至交换机，使得匹配表项的数据包将被镜像至监控平台；

监控平台，用于捕获镜像数据包，对镜像数据包进行拓扑排序，得到由数据包在网络中各跳位置处产生的镜像包构成的有序链表；还用于对捕获的数据进行统计；以及根据查询端的查询条件执行匹配操作并返回查询结果；

查询端，用于向监控平台发送查询条件并接收查询结果。

2.根据权利要求1所述的基于软件定义网络技术的网络排障系统，其特征在于，所述监控平台根据镜像数据包中包含的交换机及其转发状态信息进行拓扑排序。

3.根据权利要求2所述的基于软件定义网络技术的网络排障系统，其特征在于，所述交换机及其转发状态信息包括交换机ID、输出端口号与流表版本号。

4.根据权利要求2所述的基于软件定义网络技术的网络排障系统，其特征在于，所述查询端使用包括以下过滤条件的数据包进行查询：数据包头部、交换机ID或数据路径ID、输入端口号、输出端口号以及交换机流表版本号。

5.根据权利要求1所述的基于软件定义网络技术的网络排障系统，其特征在于，所述监控平台对捕获的数据进行统计的信息包括网络流五元组、链路ID、数据包个数、数据包大小。

6.根据权利要求1所述的基于软件定义网络技术的网络排障系统，其特征在于，所述查询端包括：

交互客户端，用于接收用户输入的查询语句，将其转换成过滤规则后下发至监控平台，并将其返回的信息呈现给用户；

故障检测应用，用于提供网络故障的发现与分析功能，通过查询排序信息与统计信息、释放探测包进行故障定位。

7.根据权利要求6所述的基于软件定义网络技术的网络排障系统，其特征在于，所述查询端还包括：探针生成器，用于接收来自故障检测应用的调用请求，利用模板定制生成探测包，将其某特殊标志位置位后发送至网络中的指定位置以重放历史流量或发送调试流量。

8.根据权利要求1所述的基于软件定义网络技术的网络排障系统，其特征在于，所述监控平台还用于对每条有序链表执行异常检测操作，对于检测出异常的记录存储其完整信息，对于正常记录则仅存储统计的聚合数据。

9.根据权利要求1-8中的任一项所述的网络排障系统的工作方法，其特征在于，所述方法包括以下步骤：

1)消息拦截器分别建立其与控制器及与各交换机之间的OpenFlow连接；

2)消息拦截器截获控制器下发的携带新流表项的OpenFlow报文，向其对应流表项中追加编码与镜像两个动作后再下发至交换机；

3)监控平台捕获到镜像数据包，并对其进行拓扑排序、数据统计、以及信息存储；

4)查询端输入描述网络流数据包旅途特征的查询语句，进行实时与历史查询，并配合注入探针重放流量的方式进行故障定位。

Images