CN101610209B - 一种多核并行的网络业务流处理方法及设备 - Google Patents

Abstract

本发明涉及一种多核并行的网络业务流处理方法，包括从网络中捕获数据包，将数据包匹配成多组业务流并生成业务流分配列表，以便多核处理器根据所述业务流分配列表对业务流进行处理，其特征在于在生成业务流分配列表之后还包括：获取各个处理核心的负载情况；确定各组业务流的活跃级别；根据所述负载情况和所述活跃级别对所述业务流分配列表进行更改，从而对业务流进行动态分配。本发明通过动态地将网络业务流分配到多个处理核心，有效地调节了各处理核心的负载，充分利用了多核处理器的处理性能。

Description

一种多核并行的网络业务流处理方法及设备

技术领域

本发明涉及一种多核并行的网络业务流处理方法及设备。

背景技术

随着互联网的不断发展，以往的网络处理机制已经无法适应网络的发展。同时，随着硬件技术的飞速发展，出现了多核处理技术。多个处理核心共享缓存、存储空间、总线等资源，使得多个处理核心并行计算成为可能；也为提高网络数据包处理性能提供了新的解决方案。

以往，对于网络业务流的处理都由多核处理器中的一个处理核心来执行，无法有效调节各处理核心的负载，以达到硬件使用平衡和充分利用硬件资源。近来，出现了把网络业务流分配到多个处理核心的技术。但是，这些技术一般是把网络业务流随机或静态地绑定到多个处理核心，在一定程度上利用了多核处理能力。但是在网络业务流量不断涌变情况下，将业务流随机或静态绑定到多个处理核心的策略无法实时均衡多个处理核心的负载，不能高效地利用多个处理核心处理网络业务。

因此，需要一种多核并行的网络业务流处理方法及设备，以均衡多个处理核心的负载，并充分利用多核系统资源。

发明内容

本发明提供了一种多核并行的网络业务流处理方法及设备。

在第一方面，本发明提供了一种多核并行的网络业务流处理方法，该方法包括从网络中捕获数据包，将数据包匹配成多组业务流并生成业务流分配列表，以便多核处理器根据所述业务流分配列表对业务流进行处理。并且该方法在生成业务流分配列表之后还包括，获取各个处理核心的负载情况；确定各组业务流的活跃级别；根据所述负载情况判断负载是否平衡；找出负载高和负载低的处理核心，在负载高的处理核心上找出活跃级别高的业务流组；更改业务流分配列表，将负载高的处理核心上活跃级别高的业务流组对应到负载低的处理核心，从而对业务流进行动态分配。

在本发明的第一方面中，优选地，利用数据包信息进行哈希处理来生成所述业务流分配列表，列表中每项包括一组业务流对应的哈希值及其对应的处理核心信息。

在本发明的第一方面中，优选地，更改步骤包括：将所述活跃级别量化为各个处理核心的占用率；根据预定的均衡规则对所述占用率和负载进行均衡处理，得出业务流和处理核心的对应关系；根据所述对应关系对所述业务流分配列表进行更改。

在本发明的第一方面中，优选地，所述均衡规则是：根据所述负载和所述占用率计算估计负载；各处理核心的估计负载不超过第一阈值；和/或各处理核心的估计负载之差不超过第二阈值。

在第二方面，本发明提供了一种多核并行的网络业务流处理设备，包括数据包捕获模块，业务流匹配模块，其中，数据包捕获模块用于从网络中捕获数据包，业务流匹配模块用于将数据包匹配成多组业务流并生成业务流分配列表，以便多核处理器根据所述业务流分配列表对业务流进行处理。并且该设备还包括处理核心负载获取模块、业务流活跃级别确定模块、业务流动态分配模块。该处理核心负载获取模块用于获取各个处理核心的负载情况。该业务流活跃级别确定模块用于确定各组业务流的活跃级别。该业务流动态分配模块用于根据所述负载情况判断负载是否平衡，并找出负载高和负载低的处理核心，在负载高的处理核心上找出活跃级别高的业务流组，更改业务流分配列表，将负载高的处理核心上活跃级别高的业务流组对应到负载低的处理核心，从而对业务流进行动态分配。

在本发明的第二方面中，优选地，所述业务流匹配模块包括：利用数据包信息进行哈希处理来生成所述业务流分配列表的模块，列表中每项包括一组业务流对应的哈希值及其对应的处理核心信息。

在本发明的第二方面中，优选地，所述业务流动态分配模块包括：将所述活跃级别量化为各个处理核心的占用率的模块；根据预定的均衡规则对所述占用率和负载进行均衡处理，得出业务流和处理核心的对应关系的模块；根据所述对应关系对所述业务流分配列表进行更改的模块。

本发明通过动态地将网络业务流分配到多个处理核心，有效地调节了各处理核心的负载，充分利用了多核处理器的处理性能。

附图说明

下面将参照附图对本发明的具体实施方案进行更详细的说明，其中：

图1是本发明的网络业务流处理设备的示意图；

图2是业务流匹配并将其静态绑定到处理核心的示意图；

图3是本发明的一个具体实施例的业务流动态分配的流程图；

图4是本发明的另一个具体实施例的业务流动态分配的流程图。

具体实施方式

图1是本发明的网络业务流处理设备的示意图。

如图1所示，该设备包括数据包捕获模块100、业务流匹配模块120、动态分配模块140，业务流分配列表180、业务流处理模块160-1、160-2、160-3...160-n，其中，动态分配模块140包括业务流活跃级别确定模块140-1、CPU负载获取模块140-2、业务流分配模块140-3。

数据包捕获模块100从网络链路捕获数据包，并将其发送到业务流匹配模块120。优选地，数据包捕获模块是以太网网卡、DAG卡等等。

业务流匹配模块120将捕获到的数据包匹配成业务流。数据包是网络中数据传输的基本单位，而业务流是指根据数据包的<源IP地址，目的IP地址，源端口号，目的端口号，协议号>构成的五元组而划分的数据包的集合。具体地说，业务流匹配模块120根据数据包包头中包含的上述五元组信息，将数据包划分到相应的集合中，使之与相应的业务流相对应。

在数据包被匹配成业务流基础上，依据业务流的特征对其进行分组。也就是说，是在数据包共有特征的基础上，业务流也具有数据包的五元组信息特征。在分组中，可以以五元组种的某项或多项特征为依据，再对业务流进行分组。通常地，通过判断源端网络地址IP和端口Port对业务流进行分组。

业务流匹配的结果是生成一个业务流分配列表，表中每项包含了各组业务流信息及其对应的处理核心信息。在初始阶段，匹配好的各组业务流所对应的是一个静态绑定的处理核心。

在动态分配模块140中，业务流活跃级别确定模块140-1确定各组业务流的活跃级别，CPU负载获取模块140-2获取多核处理器中各处理核心的负载，而业务流分配模块140-3根据业务流活跃级别和处理核心负载，按照一定的规则将业务流分配给多个处理核心，即对业务流分配列表180中每一表项中的处理核心信息进行更改，将需要重新分配的一组业务流划归给某个处理核心。

优选地，每隔一段时间执行一次业务流动态分配。

最后，根据业务流分配列表，分配好的业务流并行地在多个业务流处理模块上接受处理，多个业务流处理模块分别运行在多核处理器的多个处理核心上(图中未示出)。

应当指出，数据包捕获模块100、业务流匹配模块120、动态分配模块140、业务流分配列表可以整合到一个硬件设备中，比如以太网网卡。

图2是业务流匹配并将其静态绑定到处理核心的示意图。

如图2所示，在捕获到数据包之后，根据其中的数据包信息对数据包将其匹配成业务流。如前所述，数据包包头中包含有五元组信息。根据数据包信息中五元组信息中的一项或任意多项来进行哈希处理，生成一个业务流分配列表。比如，根据数据包的源、目的IP地址进行哈希处理，或者根据数据包的源、目的端口号进行哈希处理，又或根据数据包的协议类型，即协议域信息来进行哈希处理，甚至根据五元组信息的任意结合来进行哈希处理。业务流分配列表中的每一表项分别包括了一组业务流对应的按特定哈希处理生成的哈希值及其对应的处理核心信息。

例如，在第一表项中，包括一组业务流所对应的哈希值(HV，hasn value)及这组业务流所对应的CPU信息，即这组业务流所对应的处理核心信息是CPU1。同理可知，HV2对应的业务流组由CPU2负责处理，HV3对应的业务流组由CPU3负责处理，以此类推。应当指出，每个处理核心有可能负责处理一个或多个业务流组。这样，就将捕获到的数据包按照其信息匹配成多组业务流，并且将每组业务流都静态绑定到一个处理核心。

应当指出，图中的n可以是任意的整数，其不意味着对处理核心个数以及业务流组个数的限制。

图3是本发明的一个具体实施例的业务流动态分配的流程图。

如图3所示，动态分配流程从300开始。

在步骤310，获取各个处理核心的负载情况。

可以有多种方法来获得各个处理核心的负载状况，甚至可以直接从操作系统中得到CPU的负载状况。例如，在Linux系统上，有很多方法可以获得系统的负载情况。比如，CPU负载可以通过调用uptime或者查看/proc/loadavg得到；又或如可以列举进程，取得每一个进程的句柄，从而得到每个进程的核心态和用户态时间。每隔一段时间，算出所有进程消耗的时间，得到CPU的使用率。

在步骤320，根据负载情况判断各处理核心的负载是否平衡。例如，根据预定的判断规则，比如各处理核心之间的负载之差超出10％即可判断负载已经失衡。如果负载平衡，则整个流程在步骤370结束。如果负载不平衡，则流程进行到步骤330.

在步骤330，根据所获得的各处理核心的负载情况，找出负载偏高以及偏低的处理核心。具体地，可以预先设定一个负载平衡值，比如各处理核心满载的50％。然后，高于该平衡值的处理核心判定为负载偏高，而低于该平衡值的处理核心判定为负载偏低。

在步骤340，确定每组业务流的活跃级别。

众所周知，业务流的定义是具有同一组特性(源IP地址、目的IP地址、源端口号、目的端口号、协议类型、开始时间和结束时间)的数据分组的集合。如果一个业务流在一定的超时时间内没有新的数据分组到来，可以称之为停止流，否则称其为活跃流。再进一步，可以通过量化的方法来定义业务流的活跃级别。

优选地，可以用每组业务流中包括的包数和/或字节数来确定每组业务流的活跃级别。例如，在Linux系统上，可以通过看/proc/net/dev来得到网络流量，从而计算出业务流的活跃级别。

应当指出，可以只通过每组业务流包含的数据包的数量来确定业务流的活跃级别，也可以只通过每组业务流所包含的字节数来确定该组业务流的活跃级别，又或通过每组业务流所包含的数据包数量以及所包含的字节数这两者的结合来确定该组业务流的活跃级别。同理于判断处理核心的负载高低，也可以用一个阈值来划分业务流的活跃级别，甚至可以设置几个阈值，从而划分出若干个活跃级别。

优选地，也可以直接用每组业务流对应于各个处理核心(或整个多核处理器)的占用率来表示其活跃级别。

在步骤350，在负载偏高的处理核心上找出活跃级别高的业务流组。

在步骤360，对业务流分配列表进行更改，将在负载偏高的处理核心上活跃级别高的业务流组所对应的处理核心信息更改为负载偏低的处理核心信息。优选地，所述处理核心信息是CPU ID。

比如，由于有可能存在个别大流量的5元组业务流，所以在更改业务流分配列表(负载均衡)的过程中可能会导致来回调整业务流分配列表。在这种情况下，可以根据两个处理核心的负载对待调整的业务流做出进一步的限制。也就是说，通过预先估计进一步限定待调整的高活跃级别业务流的选择范围，从中排除调整后仍然可能造成负载不平衡的业务流。

例如，处理核心1负载为64％，处理核心2负载为35％，它们分别对应上述的负载偏高和偏低的处理核心(预定负载高于50％为负载偏高，负载低于50％为负载偏低)。将业务流的活跃级别量化为处理核心的占用率，假如处理核心1上存在一个活跃级别高(预定占用率高于10％为活跃级别高)的业务流组，其对应的处理核心占用率为30％。显而易见，为了负载平衡，在更改业务流分配列表时不将该业务流组划归给处理核心2。这样，就避免了将个别大流量的业务流组(这里为处理核心占用率30％的业务流组)划归给处理核心2而造成处理核心负载仍然失衡的情况。

本领域的技术人员应当理解，业务流分配列表的具体更改规则可以是各种各样的，其都服务于调节负载，最终达到负载平衡。

然后，流程回到步骤320，继续判断负载是否平衡。

显而易见，步骤330与步骤340的时序关系是可以变化的。因此，在本发明的教导下，本领域的技术人员可以设计出各种流程变体，而这些变体都在本发明的构思之内。

图4是本发明的另一个具体实施例的业务流动态分配的流程图。

如图4所示，流程从400开始。

在步骤410，确定每组业务流的活跃级别。

在步骤420，将每组业务流的活跃级别量化为其对应于一个处理核心/多核处理器的占用率。

在步骤430，获取每个处理核心的负载。

在步骤440，按照预定的规则，利用步骤420和步骤420获得的处理核心的占用率和处理核心负载，进行均衡处理，得出每组业务流组和各个处理核心的对应关系。

均衡处理可以有各种各样的规则。比如，根据处理核心的占用率和当前负载计算出处理核心的估计负载。优选地，将处理核心的占用率和负载(优选地，都以百分比形式体现)两两相加得出处理核心的估计负载。那么，均衡规则例如可以是估计负载不能高于95％，或者估计负载之差不能高于10％，等等。本领域的技术人员应该理解，可以在本发明的教导下设计出其他的均衡规则及其实现过程。

在步骤450，根据在步骤440得出的对应关系对业务流分配列表进行更改，将每组业务流所对应的处理核心信息更改为均衡后的结果。

在步骤460，整个动态分配流程结束。

在图4的流程中，关于确定业务流活跃级别和获得处理核心负载的步骤类似于图3，并且可以有其他的实现方法，因此不再赘述。

以上对本发明的具体描述旨在说明具体实施方案的实现方式，不能理解为是对本发明的限制。本领域普通技术人员在本发明的教导下，可以在详述的实施方案的基础上做出各种变体，这些变体均应包含在本发明的构思之内。本发明所要求保护的范围仅由所述的权利要求书进行限制。

Claims (12)

1.一种多核并行的网络业务流处理方法，包括从网络中捕获数据包，将数据包匹配成多组业务流并生成业务流分配列表，以便多核处理器根据所述业务流分配列表对业务流进行处理，其特征在于在生成业务流分配列表之后还包括：

获取各个处理核心的负载情况；

确定各组业务流的活跃级别；

根据所述负载情况判断负载是否平衡；

找出负载高和负载低的处理核心，在负载高的处理核心上找出活跃级别高的业务流组；

更改业务流分配列表，将负载高的处理核心上活跃级别高的业务流组对应到负载低的处理核心，从而对业务流进行动态分配。

2.根据权利要求1的方法，其特征在于：

利用数据包信息进行哈希处理来生成所述业务流分配列表，列表中每项包括一组业务流对应的哈希值及其对应的处理核心信息。

3.根据权利要求2的方法，其特征在于：

所述数据包信息是数据包的IP地址和/或端口号和/或协议域信息。

4.根据权利要求1的方法，其特征在于所述

负载高低是根据预定负载阈值而判断得到。

5.根据权利要求1的方法，其特征在于所述更改步骤包括：

将所述活跃级别量化为各个处理核心的占用率；

根据预定的均衡规则对所述占用率和负载进行均衡处理，得出业务流和处理核心的对应关系；

根据所述对应关系对所述业务流分配列表进行更改。

6.根据权利要求5的方法，其特征在于所述均衡规则是：

根据所述负载和所述占用率计算估计负载；

各处理核心的估计负载不超过第一阈值；和/或

各处理核心的估计负载之差不超过第二阈值。

7.根据权利要求1的方法，其特征在于：

根据各组业务流所包含的数据包和/或字节数来确定业务流的活跃级别。

8.一种多核并行的网络业务流处理设备，包括数据包捕获模块和业务流匹配模块，其中，数据包捕获模块用于从网络中捕获数据包，业务流匹配模块用于将数据包匹配成多组业务流并生成业务流分配列表，以便多核处理器根据所述业务流分配列表对业务流进行处理，其特征在于还包括：

处理核心负载获取模块，获取各个处理核心的负载情况；

业务流活跃级别确定模块，用于确定各组业务流的活跃级别；

业务流动态分配模块，用于根据所述负载情况判断负载是否平衡，并找出负载高和负载低的处理核心，在负载高的处理核心上找出活跃级别高的业务流组，

更改业务流分配列表，将负载高的处理核心上活跃级别高的业务流组对应到负载低的处理核心，从而对业务流进行动态分配。

9.根据权利要求8的设备，其特征在于所述业务流匹配模块包括：

利用数据包信息进行哈希处理来生成所述业务流分配列表的模块，列表中每项包括一组业务流对应的哈希值及其对应的处理核心信息。

10.根据权利要求8的设备，其特征在于所述

负载高低是根据预定负载阈值而判断得到。

11.根据权利要求8的设备，其特征在于所述业务流动态分配模块包括：

将所述活跃级别量化为各个处理核心的占用率的模块；

根据预定的均衡规则对所述占用率和负载进行均衡处理，得出业务流和处理核心的对应关系的模块；

根据所述对应关系对所述业务流分配列表进行更改的模块。

12.根据权利要求8的设备，其特征在于所述业务流活跃级别确定模块包括：

根据各组业务流所包含的数据包和/或字节数来确定业务流的活跃级别的模块。

Images