CN104468390B - 软件定义网络中基于分布‑集中式架构模型的多控制器负载均衡的方法 - Google Patents

Abstract

目前在软件定义网络中，主要存在两种多控制器的架构模型：分布式多控制器架构模型以及集中式多控制器架构模型。这两种架构模型既有优点，也有不足：分布式多控制架构模型虽然可以有效避免单一控制器在性能和可靠性方面的问题，但在多个分布式控制器之间传递消息的时延较长；集中式多控制器架构模型虽然可以有效的减少控制器之间消息传递的时延，但是仍存在集中化控制的种种弊端。因此本发明中提出了一种分布—集中式的多控制器架构模型来避免之前的架构模型的不足。在这个基础上，还提出了基于分布—集中式架构模型的多控制器负载均衡的方法，使得整个网络的负载可以均衡分配。

Description

软件定义网络中基于分布-集中式架构模型的多控制器负载 均衡的方法

技术领域

本发明涉及网络技术领域，特别是涉及软件定义网络技术。

背景技术

随着移动互联网、大数据、云计算等的快速发展，传统的网络技术框架已经不能满足使用需求的增长，在这种背景下，软件定义网络(Software Defined Networking SDN)这种新型的基于软件的网络架构被提出，SDN网络的主要特点为解耦了网络的控制平面和数据平面，支持集中化的网络管理。其中控制器负责对整个网络的控制，需要全局的把握网络视图，提升网络的交付质量。

集中化的网络控制，使得控制器担负了更大的责任，整个网络使用单一的控制器，会存在如下问题：

1、如果控制器出现安全问题或故障，将直接影响整个网络中的交换设备不能进行正常的工作，导致SDN网络的服务能力下降，甚至全网瘫痪。

2、随着交换设备数目的增长，使得单一控制器和交换设备之间的流量增长，但是单一控制器的带宽是有限的。

3、随着网络规模的增大，边缘处的交换设备和控制器进行通信时会有较长时间的时延。

由于以上问题的存在，需要引入多台控制器进行合作处理，从而避免单一控制器在性能、可靠性等方面的问题。

目前主要存在的两种多控制架构模型：

1、分布式多控制器架构模型。该架构模型采用的是分布式的思想，每个控制器和其管理的交换设备组成一个自治区域，每个自治区域由控制器单独管理，不同自治区域通过消息的传输来交换各自的信息。这种架构模型虽然有效的避免了单一控制器在性能和可靠性方面的问题，但是距离较远的自治区域之间的信息传递仍存在较大的时延。

2、由超级控制器(super controller)集中管理的集中式多控制器架构模型。该架构模型采用的是集中式的思想，在多控制器上加入super controller对其他控制器进行集中式的管理。这种架构模型虽然由于super controller的出现，较小了多控制器之间的信息传递时延，但是由于在多控制器上又出现的集中式的管理，仍存在集中化网络控制中的种种弊端。

由于现存的两个多控制架构模型都有各自的优点和弊端，因此急需提出一种新的多控制架构模型来进一步完善。

在SDN网络技术中，底层的交换设备是不能进行转发决策的，它只需要从控制器处接收流表，并且按照流表的策略进行转发。如果交换机收到一个流表中没有匹配项的数据包，则交换机就将发送Packet_in消息给控制器，且将数据包的全部或部分内容作为Packet_in消息的附带一起发送给控制器。控制器在收到Packet_in消息之后，对转发策略进行决策，生成流表项，并发送 Flow_Mod消息向交换机写入流表，从而完成了控制器向交换机写入一个与数据包相关的流表的过程，并指定该数据包按照此流表的动作列表处理。

但是随着网络流量的不断增大，交换机收到的不能匹配流表项的数据包个数不断增加，在控制器处排队等待处理的Packet_in消息的个数不断增大。一旦单一的控制器不能处理排队等待的Packet_in消息，那么就需要引入多控制器模式对Packet_in消息进行处理。多控制器模式的引入，其中的一个重要问题就是在多控制器之间的负载，也就是Packet_in消息如何均匀高效的分配。

发明内容

为了克服上述现有技术的不足，即多控制器架构模型的缺陷和多控制器之间的负载均衡问题，本发明提供了一种软件定义网络中基于分布—集中式架构模型的多控制负载均衡的方法。

在本发明中，首先提出了分布—集中式架构的多控制器模型。在该模型中，多个控制器组成一个集群，每个控制器的地位相同，通过信令交互各自的负载信息，集群内部的连接情况用图1表示，该图为全连接、有向图，集群之间的控制器不直接相连；超级控制器和各个集群中的每个控制器直接相连，这里的超级控制器可以是SDN网络中的控制器设备或是其他专用的负载分配设备，它主要用来对集群中控制器的负载进行集中的调度，具体的架构模型如图2所示。

设置负载状态的判定门限，如图3所示，其中的参数(以下称为H₁)，辅助门限1进行判定，避免在负载转移时出现乒乓效应。这里的乒乓效应指：当两个控制器的负载状态(V_i)均在门限边缘时，此时盲目的转移负载，会引起负载在两个控制器之间来回传递，大量浪费通信资源。其中，V_i表示控制器i的负载状态，计算公式为：

式中：表示：下层交换设备不能处理的，上传到控制器i处需要由控制器i下发处理决策的数据包，在控制器i处排队的个数；P_max表示：控制器i 处可以容纳的上述数据包的最大个数。

根据负载状态V_i的不同的数值范围，可分成4个状态：

状态1：负载状态值在0-H₁之间，此时控制器i处排队等待处理的数据包可以完全由本控制器处理，并且由于没有超过门限1的参数H₁，不需要和集群中的其他控制器交互信息；

状态2：负载状态值在H₁-门限1之间，此时控制器i处排队等待处理的数据包虽然也可以由本控制器处理，但是已经进入负载超额的预警状态，需要开始收集本集群中其他邻居控制器的消息，准备向集群中的其他控制器分担负载；

状态3：负载状态值在门限1-门限2之间，则在控制器i处排队等待处理的超额数据包需要分配给本集群中的其他控制器处理，分配的原则为：按照 H₁与其他邻居控制器负载状态的差值的比例进行分配，这样可以有效的避免乒乓效应；

若仍有部分超额数据包在控制器i所属集群内部不能被分配处理，则需要上传到超级控制器分配给其他集群处理，分配的原则为：首先按照每个集群的负载分配函数的比例来确定每个集群被分配的数目，再在集群内部按照门限1 与各个控制器负载状态的差值的比例进行分配，当集群中某一控制器此时的负载状态已经大于门限1，则不对其分配负载；

状态4：负载状态值在门限2以上，则在控制器i处排队等待处理的超额数据包需要直接上传到超级控制器，从而协调到其他集群处理，分配的原则为：首先按照每个集群的负载分配函数的比例来确定每个集群被分配的数目，再在集群内部按照门限1与各个控制器负载状态的差值的比例进行分配，当集群中某一控制器此时的负载状态已经大于门限1，则不对其分配负载。

附图说明

图1为：本发明中一种典型的集群内部的控制器的图；

图2为：本发明中一种典型的软件定义网络的总体网络架构图；

图3为：本发明中一种典型的用来区分不同状态的门限图；

图4为：本发明中一种SDN基于分布—集中式架构模型的多控制器负载均衡方法流程图；

图5为：本发明中一种SDN基于分布—集中式架构模型的多控制器负载均衡方法流程图；

图6为：本发明中一种SDN基于分布—集中式架构模型的多控制器负载均衡方法流程图。

具体实施方式

在本模型中设定m个集群，分别记为：1,2…m；每个集群中有n个控制器，分别记为：1,2…n。假设所有的控制器的总处理能力是相同的，即均最多可以容纳P_max个Packet_in消息排队等待处理(此方法也适用于各控制器处理能力不同的场景，具体方法类似)，当排队的消息个数再增加，控制器将不再接收。

在网络尚未开始接收数据包时，super controller测试与集群中每个控制器传输信息的时延，并根据公式2计算出第k个集群的平均时延：

式子中，D_si为第k个集群中的控制器i和super controller之间的传输时延。计算结束之后，将计算结果按照不同集群分别存储。

启动网络，集群中的控制器开始向super controller上传load_notice信令，该信令的作用是将控制器的负载状态上报给super controller，且信令的发送周期为T，load_notice信令的格式为：

源控制器地址

目的控制器地址

Vi

源控制器地址表示：发出此信令的控制器IP地址；目的控制器地址表示： supercontroller的IP地址；V_i表示：发出此信令的控制器i的负载状态。

super controller将来自同一个集群的控制器的V_i值存在一个行向量中，最终形成有m行n列的状态矩阵V：

其中矩阵V的第i行表示来自集群i所属控制器的负载状态，第i行第j 个元素表示集群i中控制器j的负载状态。

super controller根据每个行向量的值，计算出每个集群的avg_V_k：

根据式2和式3计算出super controller和某一个集群k的负载分配函数S_k：

且α+β＝1，该分配函数考虑了2个分配策略参数：1)集群的剩余处理能力参数α；2)super controller和集群K的传输时延参数β。通过设定不同的值，可以确定剩余处理能力和传输时延在判断时所占的比例是多少，具体的值可以自行设定。

图4为本发明中SDN基于分布—集中式架构模型的多控制器负载均衡方法流程图，其具体步骤如下：

步骤401：控制器C₁₁检测自身的负载状态值是否超过H₁。

步骤402：根据检测到的负载状态值来确定接下来的步骤：如果负载状态值大于H₁，则执行步骤403；否则，继续执行步骤401，如图2的状态1。

步骤403：此时集群1中的控制器C₁₁的检测到自身的负载状态V₁>H₁，如图2的状态2，使得该控制器开始收集本集群中其他邻居控制器的消息，准备向集群中的其他控制器分配负载，即C₁₁向集群中的其他邻居控制器发送 overload_notice信令，通知其他控制器自身的负载将可能要过载，并询问邻居控制器的负载状况。且overload_notice信令的发送周期也为T。其格式为：

源控制器地址

目的控制器地址

源控制器地址表示：负载状态超过H₁的控制器C₁₁的IP地址；目的控制器地址表示：和C₁₁相连的集群中的控制器的IP地址。C₁₁有几个相连的控制器，将会分别发送几个overload_notice信令，在此将发送n-1个overload_notice 信令。

步骤404：收到overload_notice信令的控制器j要做如下的判断：

步骤405：收到overload_notice信令的控制器回复load_able信令，格式如下：

源控制器地址

目的控制器地址

Vj

源控制器地址表示：收到overload_notice信令的控制器的IP地址；目的控制器地址表示：发出overload_notice信令的控制器的IP地址，即控制器C₁₁的IP地址；V_j为收到overload_notice信令的控制器的负载状态。

步骤406：C₁₁将读取收到的load_able信令，了解有哪些集群中的邻居控制器可以进行负载分配以及可以接收的负载数目，并且将load_able信令中的源控制器地址和V_j数目对应存储到向量A，该向量的更新周期也为T。完成向量A的存储之后，返回步骤401，继续检测自身的负载状态。

步骤407：收到overload_notice信令的控制器对该信令不做处理。

图5为本发明中SDN基于分布—集中式架构模型的多控制器负载均衡方法流程图，其具体步骤如下：

步骤501：控制器C₁₁检测自身的负载状态值是否超过门限1(th₁)。

步骤502：根据检测到的负载状态值来确定接下来的步骤：如果负载状态值大于th₁，则执行步骤503；否则继续执行步骤501。

步骤503：此时C₁₁的负载状态V₁超过了th₁，如图2的状态3，C₁₁读取此时存储的向量A，计算出C₁₁需要分配给其他控制器的负载为：

V₁-H₁ (5)

生成空的负载分配向量E，E的维数与此时向量A的维数相同，用来存放将要计算得到的负载分配结果。

步骤504：计算C₁₁在本集群中的邻居控制器可以处理的最大负载量和为：

步骤505：进行如下判断：

当出现情况1时，说明C₁₁的全部相邻的控制器可以满足C₁₁的负载分配请求，在本集群内部就可以将负载分担，执行步骤506-509。

当出现情况2时，说明C₁₁的全部相邻的控制器不能满足C₁₁的负载分配请求，就需要将大于该集群负载分担能力的负载上传至super controller处交由其他集群处理，执行步骤510-516。

步骤506：该过程是由超载控制器向集群内部发起的负载均衡过程，计算负载分配向量E中的元素e_j，对应的为第j个控制器的负载分配比例：

通过这种比例分配方法可以有效的避免出现乒乓效应的出现。第j个控制

e_j*(V₁-H₁)*P_max

器将被分配到的Packet_in数据包的个数为。

步骤507：根据向量E，控制器C₁₁从排队的Packet_in消息的队尾取对应个数的Packet_in消息，在队列前加入如下传输信令：

源控制器地址

目的控制器地址

Packet_in数据包个数

源控制器地址表示：超载的C₁₁控制器的IP地址；目的控制器地址表示：被分配到对应个数Packet_in消息的控制器的IP地址。

形成如下传输格式：

按照以上格式，传输给相应的控制器，实现负载均衡。

步骤508：相应的控制器收到分配来的Packet_in消息之后，完成转发决策生成流表，并生成相应的Flow-Mod消息，在队列前加入如下传输信令：

源控制器地址

目的控制器地址

Packet_in数据包个数

源控制器地址表示：接受C₁₁处超载的Packet_in消息的控制器的IP地址；目的控制器地址表示：超载的C₁₁控制器的IP地址。

形成如下传输格式，传输给过载的控制器C₁₁

步骤509：C₁₁收到该消息队列之后，下发Flow-Mod消息给对应的交换设备，从而完成转发任务，之后C₁₁返回到步骤501继续检测自身的负载状态。

步骤510：该过程是由超载控制器向集群内部和super controller发起的负载均衡过程，在集群处只处理可以承担的负载，其数值为：

用步骤506-509对P_s*P_max个Packet_in数据包进行处理。

步骤511：计算出不能被集群内部分担的Packet_in消息的数目为：

(V₁-H₁-V_s)*P_max (10)

在排队的Packet_in消息队尾选取对应数目的数据包，并在队列前加入如下传输信令：

源控制器地址

目的控制器地址

Packet_in消息个数

源控制器地址表示：超载的C₁₁控制器的IP地址；目的控制器地址表示： supercontroller的IP地址。

从而形成如下传输格式：

上传到super controller，交由super controller进行处理。

步骤512：此时super controller收到了N个Packet_in消息，将立即查看该周期内除了数据包来源集群的其他集群的控制器状态矩阵V。例如，当前super controller收到了来自集群1中的数据包，这时super controller就立即查看除了集群1的其他集群的(m-1)*n维的状态矩阵，并且生成(m-1)*n维的空的负载分配矩阵R，用来存放之后计算得到的负载分配的结果。

步骤513：按照公式4计算出该周期内每个集群的负载分配函数：S_k， k＝2,…,m。

根据负载分配函数的计算值，成比例的将负载进行分配，第i个集群的分配比例为：

查看第i行状态矩阵的数值，来确定第i个集群中第j个控制器的分配比例：

将计算的结果存入到负载分配矩阵R中，矩阵R计算完成之后，分配给第i个集群的第j的控制器的数据包个数即为：R_ij*N。

步骤514：super controller生成如下格式的传输信令：

源控制器地址

超载控制器地址

目的控制器地址

Packet_in消息个数

源控制器地址表示：super controller的IP地址；超载控制器地址表示：实际超载的控制器的IP地址，即为C₁₁控制器的IP地址；目的控制器地址表示：应该分配相应个数的控制器的IP地址。

加入对应数目的Packet_in消息之后，传输给相应的控制器，从而完成负载均衡过程。

步骤515：相应的控制器收到分配来的Packet_in数据包之后，完成转发决策生成流表，并生成相应的Flow-Mod消息，按照如下的消息格式传输给super controller。

源控制器地址表示：生成Flow-Mod消息的控制器的IP地址；超载控制器地址表示：实际超载的控制器的IP地址，即为C₁₁控制器的IP地址；目的控制器地址表示：supercontroller的IP地址。

步骤516：super controller收到Flow-Mod消息队列之后，根据超载控制器地址转发给控制器C₁₁，C₁₁收到该消息队列之后，下发Flow-Mod消息给对应的交换设备，从而完成转发任务，之后C₁₁返回到步骤501继续检测自身的负载状态。

图6为本发明中SDN基于分布—集中式架构模型的多控制器负载均衡方法流程图，其具体步骤如下：

步骤601：super controller检测各集群的平均负载状态值avg_V_k是否超过门限2(th₂)。

步骤602：根据检测到的平均负载状态值来确定接下来的步骤：如果某一集群的平均负载状态值大于th₂，则执行步骤603；否则继续执行步骤601。

步骤603：此时集群2的控制器C₂₁、C₂₄流量激增，使得super controller 检测到集群2的avg_V₂大于门限2，如图2的状态4，super controller发起负载均衡过程。supercontroller开始向集群2中负载状态V_j大于门限2的控制器下发load_ask信令，即supercontroller向C₂₁、和C₂₄下发load_ask信令，格式如下：

源控制器地址

目的控制器地址

Packet_in消息个数

其中，源控制器地址表示：super controller的IP地址；目的控制器地址表示：负载状态大于门限2的控制器的IP地址，即控制器C₂₁和控制器C₂₄的IP 地址；Packet_in消息个数＝(V_j-th₁)*P_max，V_j为负载状态大于门限2的控制器的负载状态，即控制器C₂₁和控制器C₂₄的负载状态。

步骤604：集群2中的控制器收到传输信令之后，按照信令中要求的 Packet_in消息个数，从队尾选取相应个数的Packet_in消息，并生成对应的传输信令：

源控制器地址

目的控制器地址

Packet_in消息个数

源控制器地址表示：负载状态大于门限2的控制器的IP地址；目的控制器地址表示：super controller的IP地址；Packet_in消息个数为load_ask信令对应要求上传的消息个数。

在信令后加入数据包，传输给super controller:

步骤605：super controller统计收到的数据包以及来源：从C₂₁控制器收到了M个Packet_in消息、从C₂₄控制器收到了N个Packet_in消息。按照不同控制器的来源，逐控制器分配负载。例如，首先为控制器C₂₁进行负载均衡。

步骤606：查看该周期内除了数据包来源集群的其他集群的的控制器状态矩阵。也就是说，super controller将查看除了集群2的其他集群的(m-1)*n维的状态矩阵，并且生成(m-1)*n维的空的负载分配矩阵R，用来存放之后计算得到的负载分配结果。

步骤607：按照公式4计算出该周期内每个集群的负载分配函数： S_k,k＝2,…,m。

根据负载分配函数的计算值，成比例的将负载进行分配，第i个集群的分配比例为：

查看第i行状态矩阵的数值，来确定第i个集群中第j个控制器的分配比例：

将计算的结果存入到负载分配矩阵R中，矩阵R计算完成之后，分配给第i个集群的第j的控制器的数据包个数即为：R_ij*M，M为控制器C₂₁上传到 super controller的Packet_in消息的个数。

步骤608：super controller生成如下格式的传输信令：

源控制器地址

超载控制器地址

目的控制器地址

Packet_in消息个数

源控制器地址表示：super controller的IP地址；超载控制器地址表示：实际超载的控制器的IP地址，即为C₂₁控制器的IP地址；目的控制器地址表示：应该分配相应个数的控制器的IP地址。

加入对应数目的Packet_in消息之后，传输给相应的控制器，从而完成负载均衡过程。

步骤609：相应的控制器收到分配来的Packet_in数据包之后，完成转发决策生成流表，并生成相应的Flow-Mod消息，按照如下的消息格式传输给super controller。

源控制器地址表示：生成Flow-Mod消息的控制器的IP地址；超载控制器地址表示：实际超载的控制器的IP地址，即为控制器C₂₁的IP地址；目的控制器地址表示：supercontroller的IP地址。

步骤610：super controller收到Flow-Mod消息队列之后，根据超载控制器地址转发给控制器C₂₁，控制器收到该消息队列之后，下发Flow-Mod消息给对应的交换设备，从而完成转发任务。

步骤611：完成控制器C₂₁的负载均衡过程之后，返回到步骤607对控制器C₂₄进行负载均衡，直到将super controller处排队的负载全部处理完成。全部处理完成之后返回到步骤601，继续检测各个集群的平均负载状态。

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

Claims (8)

1.一种软件定义网络中基于分布一集中式架构模型的多控制负载均衡的方法，其特征在于：应用于分布—集中式架构的多控制器模型，所述模型中包括m个集群，分别记为：1,2…m；每个集群中包括n个控制器，分别记为：1,2…n；在各个集群的上层布设超级控制器，所述超级控制器与各个集群中的每个控制器连接，所述方法包括：通过控制器集群内部发起和超级控制器发起的两种负载均衡机制，所述负载均衡机制包括：

根据集群的剩余处理能力、集群和超级控制器的传输延时确定所述集群的负载分配函数其中a+β＝1，avg_V_k为集群平均负载状态，avg_D_sk为超级控制器与集群平均时延；

根据所述负载分配函数来实现多控制器之间的负载均衡过程。

2.根据权利要求书1所述的一种软件定义网络中基于分布一集中式架构模型的多控制负载均衡的方法，其特征在于，所述超级控制器，功能是进行负载的分配，可以是软件定义网络中的控制器设备或是专用的负载分配设备。

3.根据权利要求1所述的一种软件定义网络中基于分布一集中式架构模型的多控制负载均衡的方法，其特征在于：当某一控制器收到了来自底层不能处理的数据包时，就需要分配给其他控制器协助处理，其他控制器在生成相应的流表项之后，转发给该控制器，再下发给交换设备。

4.根据权利要求1所述的一种软件定义网络中基于分布一集中式架构模型的多控制负载均衡的方法，其特征在于：通过设定控制器负载状态的门限1和门限2，其中门限2大于门限1，来决定超量的负载是在集群内部分配处理，还是分配到其他集群处理。

5.根据权利要求1所述的一种软件定义网络中基于分布一集中式架构模型的多控制负载均衡的方法，其特征在于：当控制器的负载状态超过门限1时，超额的负载将在该控制器的集群内部被分配处理，如果集群内部不能全部处理，再上传至超级控制器处交由其他集群处理；当控制器的负载状态超过门限2时，直接将超额的负载上传至超级控制器处，由超级控制器交由其他集群处理。

6.根据权利要求1所述的一种软件定义网络中基于分布一集中式架构模型的多控制负载均衡的方法，其特征在于：通过信令的交互，超级控制器知道和自己直接相连的所有控制器的负载状态，并以一定的时间进行更新。

7.根据权利要求1所述的一种软件定义网络中基于分布一集中式架构模型的多控制负载均衡的方法，其特征在于：设置一个值小于门限1的参数，在负载均衡时根据公式计算控制器i的负载状态值，i为1,2…n中的任一值，所述公式为：

其中，V_i表示控制器i的负载状态，表示：下层交换设备不能处理的，上传到控制器i处需要由控制器i下发处理决策的数据包，在控制器i处排队的个数；P_max表示：控制器i处可以容纳的上述数据包的最大个数，根据所计算的负载状态值的不同的数值范围，可分成4个状态：

状态1：负载状态值在0-参数之间，此时控制器i处排队等待处理的数据包可以完全由本控制器处理，不需要和集群中的其他控制器交互信息；

状态2：负载状态值在参数-门限1之间，此时控制器i处排队等待处理的数据包虽然也可以由本控制器处理，但是已经进入负载超额的预警状态，需要开始收集本集群中其他邻居控制器的消息，准备向集群中的其他控制器分担负载；

状态3：负载状态值在门限1-门限2之间，则在控制器i处排队等待处理的超额数据包需要分配给本集群中的其他控制器处理，分配的原则为：按照参数与其他邻居控制器负载状态的差值的比例进行分配，这样可以有效的避免乒乓效应；

状态4：负载状态值在门限2以上，则在控制器i处排队等待处理的超额数据包需要直接上传到超级控制器，从而协调到其他集群处理，分配的原则为：首先按照每个集群的负载分配函数的比例来确定每个集群被分配的数目，再在集群内部按照门限1与各个控制器负载状态的差值的比例进行分配，当集群中某一控制器此时的负载状态已经大于门限1，则不对其分配负载。

8.根据权利要求7所述的一种软件定义网络中基于分布一集中式架构模型的多控制负载均衡的方法，其特征在于：在进行集群内部负载均衡时，要将超载控制器的负载状态均衡到该参数值以下。