CN104579975B - 一种软件定义网络控制器集群的调度方法 - Google Patents

Abstract

本发明涉及一种软件定义网络控制器集群的调度方法，采用了控制器集群的方案，可以将负载压力分摊给各个控制器节点，避免了将所有负载压力集中给单个控制器节点导致处理性能较低的问题。集群中的每个控制器节点相应配置一份Hash表，每个控制器节点只允许修改其拥有的Hash表中由其负责接管的交换机的标识以及其负载因子，每个控制器节点修改了其拥有的Hash表中的数据时，需将其修改的数据同步到其他控制器节点中，由其他控制器节点相应更新各自拥有的Hash表中的数据；本发明可以根据Hash表中的数据确定相应的控制器节点对交换机进行接管，而不需要引入第三方管理者，不会导致整个集群受限于第三方管理者的性能。

Description

一种软件定义网络控制器集群的调度方法

技术领域

本发明涉及网络技术领域，具体涉及一种软件定义网络控制器集群的调度方法。

背景技术

目前，软件定义网络(Software Defined Network,SDN)控制器的调度方案大致包括两种，一种是基于双机热备的调度方案，其架构如图1所示，平时由主控制器节点负责接管所有的交换机，在主控制器节点出现宕机时，由备控制器节点接管所有的交换机；其缺点是负载压力都集中在单个控制器节点上，处理性能较低。

另一种是通过第三方管理者进行控制器集群的调度方案，其架构如图2所示，在所有控制器节点之外加入一个第三方管理者，负责管理调度集群中的所有控制器节点；所有的控制器节点都是通过该第三方管理者分配交换机的接管任务；如果控制器节点出现宕机，第三方管理者将重新调度交换机接管任务；其缺点是如果第三方管理者出现宕机，会影响整体网络系统的运行，同时，由于控制器集群的节点数量上限受第三方管理者的程序调度性能影响，使得第三方管理者的性能会成为整体集群的瓶颈。

发明内容

本发明针对现有技术中软件定义网络控制器的调度方案处理性能较低或受限于第三方管理者的性能等技术问题，提出一种具有更高性能的软件定义网络控制器集群的调度方法。

本发明提出的一种软件定义网络控制器集群的调度方法，所述软件定义网络控制器集群包括若干控制器节点；每个控制器节点相应拥有一份Hash表，每份Hash表的数据包括：各个控制器节点的标识、各个控制器节点负责接管的交换机的标识、各个控制器节点的负载因子；其中，每个控制器节点只允许修改其拥有的Hash表中由其负责接管的交换机的标识以及其负载因子；每个控制器节点修改了其拥有的Hash表中的数据时，需将其修改的数据同步到其他控制器节点中，由其他控制器节点相应更新各自拥有的Hash表中的数据；

所述调度方法包括控制器节点选举方法，所述控制器节点选举方法包括：

本控制器节点获取需要选举接管的交换机的标识；

根据本控制器节点拥有的Hash表中的数据，判断是否接管获取到的标识对应的交换机。

优选地，所述根据本控制器节点拥有的Hash表中的数据，判断是否接管获取到的标识对应的交换机的步骤包括：

根据本控制器节点拥有的Hash表中的数据，判断获取到的标识对应的交换机是否已被其他控制器节点接管；

若是，则本控制器节点放弃接管；若否，则根据本控制器节点接管的交换机数量判断是否接管。

优选地，所述根据本控制器节点接管的交换机数量判断是否接管的步骤包括：

根据本控制器节点拥有的Hash表中的数据，判断本控制器节点接管的交换机数量是否最小；若是，则根据是否有其他控制器节点接管的交换机数量与本控制器节点接管的交换机数量相等判断是否接管。

优选地，所述根据是否有其他控制器节点接管的交换机数量与本控制器节点接管的交换机数量相等判断是否接管的步骤包括：

根据本控制器节点拥有的Hash表中的数据，判断是否有其他控制器节点接管的交换机数量与本控制器节点接管的交换机数量相等；

若否，则本控制器节点进行接管；若是，则根据本控制器节点的标识序号判断是否接管。

优选地，所述根据本控制器节点的标识序号判断是否接管的步骤包括：

根据本控制器节点拥有的Hash表中的数据，判断本控制器节点的标识序号在所有接管交换机数量与其相等的控制器节点的标识序号中是否最小；

若是，则本控制器节点接管进行接管。

优选地，本控制器节点对获取到的标识对应的交换机进行接管后还包括：

本控制器节点修改其拥有的Hash表中由其负责接管的交换机的标识以及其负载因子，并将其修改的数据同步到其他控制器节点中；由其他控制器节点相应更新各自拥有的Hash表中的数据。

优选地，本控制器节点具体通过TCP将其修改的数据同步到其他控制器节点中。

优选地，本控制器节点通过openflow协议发送请求接管的数据包给交换机，以实现对获取到的标识对应的交换机的接管。

优选地，所述调度方法还包括同步数据修复方法，所述同步数据修复方法包括：

查询本控制器节点拥有的Hash表中是否存在异常数据，若是，则对本控制器节点所拥有的Hash表中的数据进行修复，同时对其他控制器节点所拥有的Hash表中相应的数据进行同步修复。

优选地，所述调度方法还包括负载均衡方法，所述负载均衡方法包括：

根据本控制器节点拥有的Hash表中的数据判断本控制器节点是否处于负载空闲状态，若是，则主动接管负载繁忙的控制器节点的交换机。

有益效果：本发明提出的软件定义网络控制器集群的调度方法，其采用的是控制器集群的方案，可以将负载压力分摊给各个控制器节点，避免了现有技术双机热备的调度方案中将所有负载压力集中给单个控制器节点导致处理性能较低的问题；

同时，本发明的集群中的每个控制器节点相应配置一份Hash表，并限定每个控制器节点只允许修改其拥有的Hash表中由其负责接管的交换机的标识以及其负载因子，每个控制器节点修改了其拥有的Hash表中的数据时，需将其修改的数据同步到其他控制器节点中，由其他控制器节点相应更新各自拥有的Hash表中的数据；因此，本发明可以根据Hash表中的数据确定相应的控制器节点对交换机进行接管，而不需要引入第三方管理者，故而不会导致整个集群受限于第三方管理者的性能。

基于所述Hash表，本发明可以实现各个控制器节点之间的冗余及负载均衡，大大提高了整个集群的性能及效率。

附图说明

图1是现有技术中双机热备的架构示意图。

图2是现有技术中通过第三方管理者进行控制器集群的架构示意图。

图3是本发明提出的一种软件定义网络控制器集群的调度方法实施例的架构示意图。

图4是本发明提出的一种软件定义网络控制器集群的调度方法实施例中控制器节点选举方法的整体流程图。

具体实施方式

为了便于本领域技术人员理解，下面将结合附图以及实施例对本发明进行进一步描述。

本发明提出的一种软件定义网络控制器集群的调度方法实施例，请参阅图3，所述软件定义网络控制器集群包括若干控制器节点(控制器节点至少在2个以上)；每个控制器节点相应拥有一份Hash表，每份Hash表的数据包括：各个控制器节点的标识、各个控制器节点负责接管的交换机的标识、各个控制器节点的负载因子；其中，每个控制器节点只允许修改其拥有的Hash表中由其负责接管的交换机的标识以及其负载因子；每个控制器节点修改了其拥有的Hash表中的数据时，需将其修改的数据同步到其他控制器节点中，由其他控制器节点相应更新各自拥有的Hash表中的数据。

本实施例中的Hash表的形式如表1所示：

表1

控制器节点的标识序号	当前接管交换机的标识	负载因子
			NodeId 1	swId1	1
NodeId 2	SwId4、swId5、swId6	3
			NodeId 3	swId7、swId8	2
NodeId 4	Empty	0
			...	...	...

在表1中，NodeId 1至NodeId 4为各个控制器节点的标识序号，swId1是标识序号为NodeId 1的控制器节点当前接管的交换机的标识；同时可以看出表1中，标识序号为NodeId 1的控制器节点的负载因子(也即权重，可表示为weight)为1。

在本实施例中，负载因子优选采用比例的形式，以便于负载均衡运算。例如，从表1可以看出，标识序号为NodeId 1的控制器节点当前只接管1个交换机(swId1)，其负载因子为1；标识序号为NodeId 2的控制器节点当前接管3个交换机(SwId4、swId5、swId6)，其负载因子为3；标识序号为NodeId 3的控制器节点当前接管2个交换机(swId7、swId8)，其负载因子为2；这三者的负载因子为1：3：2。同时，为了使整个集群的性能较佳，负载因子的值优选控制在1至10以内。

表1中涉及的其他符号可以根据上述解释进行相应理解。

本实施例中的Hash表可以在集群中实现控制器节点选举、同步数据修复以及负载均衡等方案。本实施例重点介绍控制器节点选举的方案。

具体的，本实施例中软件定义网络控制器集群的调度方法包括控制器节点选举方法，所述控制器节点选举方法整体包括步骤S100和步骤S200：

S100、本控制器节点获取需要选举接管的交换机的标识；

S200、根据本控制器节点拥有的Hash表中的数据，判断是否接管获取到的标识对应的交换机。

本实施例中，所述控制器节点选举方法主要应用于两种情况：一是，当有新的交换机连接到本集群时，本集群中的每个控制器节点都会收到响应，收到响应的每个控制器节点都会运行所述控制器节点选择算法；二是，当有控制器节点宕机时，其接管的交换机需要通过选举被其他正常的控制器节点接管，其他正常的控制器节点基于所述控制器节点选择算法确定是否进行接管。

本实施例中的控制器节点选举方法主要基于各控制器节点配置的Hash表中的数据来实现，每个控制器节点都可以通过TCP实现Hash表数据的同步更新，同时，各个控制器节点可以通过openflow协议发送请求接管的数据包给交换机，以实现对获取到的标识对应的交换机的接管。

为了更好地实现本实施例的目的，以下对所述控制器节点选举方法做进一步优化及详细介绍。

本实施例中，步骤S200具体包括步骤S210和步骤S220：

S210、根据本控制器节点拥有的Hash表中的数据，判断获取到的标识对应的交换机是否已被其他控制器节点接管；

S220、若是，则本控制器节点放弃接管；若否，则根据本控制器节点接管的交换机数量判断是否接管。

所述Hash表以表1为例，如果步骤S100获取到的标识是表1中swId1至swId8中的任一个，则说明该标识对应的交换机已经被控制器节点接管。例如，假设这里获取到的标识是“swId8”，本控制器节点的标识序号是“NodeId 2”，通过查表1可知本控制器节点并没有接管标识为“swId8”的交换机，标识为“swId8”的交换机正被标识序号为“NodeId 3”的控制器所接管，因此本控制器节点放弃接管；如果步骤S100获取到的标识是“swId9”,通过查表可知，标识为“swId9”的交换机没有被任何控制器节点接管，因此，本控制器节点可根据自身当前接管的交换机数量判断是否接管。

从表1所示可知，标识序号为NodeId 1至NodeId 4的控制器节点接管的交换机数量分别为1个、3个、2个和0个。

本实施例中，为了防止交换机丢失，只有在交换机已被其他控制器节点接管的情况下，本控制器节点才会放弃对该交换机的接管，否则会一直执行选举方法，直到该交换机被接管；但在判断交换机未被其他控制器节点接管的情况下，本控制器节点未必会直接接管。优选的，本控制器节点会结合自身状况，判断自身是否是当前最符合进行接管的控制器节点，以相应确定是否进行接管。因此，本实施例在步骤S220的基础上做了进一步优化。

具体的，步骤S220中根据本控制器节点接管的交换机数量判断是否接管的步骤具体包括步骤S230：

S230、根据本控制器节点拥有的Hash表中的数据，判断本控制器节点接管的交换机数量是否最小；若是，则根据是否有其他控制器节点接管的交换机数量与本控制器节点接管的交换机数量相等判断是否接管。

同时，步骤S230还可进一步优化，具体的，步骤S230中根据是否有其他控制器节点接管的交换机数量与本控制器节点接管的交换机数量相等判断是否接管的步骤包括步骤S240和步骤S250：

S240、根据本控制器节点拥有的Hash表中的数据，判断是否有其他控制器节点接管的交换机数量与本控制器节点接管的交换机数量相等；

S250、若否，则本控制器节点进行接管；若是，则根据本控制器节点的标识序号判断是否接管。

上述步骤S230至步骤S250的主要作用是避免各个控制器节点之间出现接管秩序混乱(例如，出现多个控制器节点同时接管或均不接管某个交换机的情况)，而设定出的接管规则，以提高对控制器节点的规范化管理。

本实施例中，步骤S250中根据本控制器节点的标识序号判断是否接管的步骤具体包括步骤S260和步骤S270：

S260、根据本控制器节点拥有的Hash表中的数据，判断本控制器节点的标识序号在所有接管交换机数量与其相等的控制器节点的标识序号中是否最小；

S270、若是，则本控制器节点接管进行接管。

步骤S260至步骤S270主要是为了对控制器节点做进一步规范化管理，即先使用标识序号较小的控制器节点，再使用标识序号较大的控制器节点，方便用户对控制器节点的应用及管理。当然，本实施例中显然也可以是其他方式，例如，先使用标识序号较大的控制器节点，再使用标识序号较小的控制器节点。

本实施例中，本控制器节点对获取到的标识对应的交换机进行接管后还包括步骤S300：

S300、本控制器节点修改其拥有的Hash表中由其负责接管的交换机的标识以及其负载因子，并将其修改的数据同步到其他控制器节点中；由其他控制器节点相应更新各自拥有的Hash表中的数据。

以上步骤S100至步骤S300整合后的整体流程请参阅图4。

在本实施例的优选方案中，除了所述控制器节点选举方法之外，本实施例提出的一种软件定义网络控制器集群的调度方法还包括同步数据修复方法，所述同步数据修复方法包括：

查询本控制器节点拥有的Hash表中是否存在异常数据，若是，则对本控制器节点所拥有的Hash表中的数据进行修复，同时对其他控制器节点所拥有的Hash表中相应的数据进行同步修复。

在本实施例中，每个控制器节点都可以通过openflow协议查询当前连接到本集群中的所有交换机的标识。通过遍历本地(本控制器节点)Hash表，查询一个交换机被多少个控制器节点接管，如果有且只有一个控制器节点接管，说明给交换机处于正常状态；如果没有控制器节点接管该交换机，本控制器节点将及时通过openflow协议接管该交换机，并通知给其他控制器节点。如果有两个或两个以上的控制器节点接管了该交换机，说明其中一个或多个控制器节点的的数据存在异常；如果本控制器节点包含在其中，本控制器节点需要通过openflow协议发送查询信息，及时修复或更新本控制器节点上Hash表的数据，同时其他控制器节点所拥有的Hash表中相应的数据进行同步修复或更新。

在本实施例进一步优选的方案中，除了所述控制器节点选举方法、同步数据修复方法之外，本实施例提出的一种软件定义网络控制器集群的调度方法还包括同步数据修复方法还包括负载均衡方法，所述负载均衡方法包括：

根据本控制器节点拥有的Hash表中的数据判断本控制器节点是否处于负载空闲状态，若是，则主动接管负载繁忙的控制器节点的需要放弃的交换机，直至本控制器节点达到负载饱和状态。

本实施例中，每个控制器节点会定时自身是否处于负载空闲状态，如果处于负载空闲状态，则继续计算还需要接管多少个交换机才能达到负载饱和状态，然后再去计算其他控制器节点是否处于负载繁忙状态，如果其他控制器节点处于负载繁忙，其需要放弃一个或多个交换机使自身处在负载饱和状态以内，(负载空闲状态的)本控制器节点会主动接管负载繁忙的控制器节点需要放弃的交换机(本控制器节点先接管该交换机，再通知原控制器节点放弃对该交换机的接管)，直到负载饱和状态。这里的接管工作可以不更新本控制器节点拥有的Hash表中的数据，更新数据的工作可以在同步数据修复方法中完成。

综上所述，本实施例提出的一种软件定义网络控制器集群的调度方法，由于采用的是控制器集群的方案，可以将负载压力分摊给各个控制器节点，避免了现有技术双机热备的调度方案中将所有负载压力集中给单个控制器节点导致处理性能较低的问题。本实施例的集群中的每个控制器节点相应配置一份Hash表，并限定每个控制器节点只允许修改其拥有的Hash表中由其负责接管的交换机的标识以及其负载因子，每个控制器节点修改了其拥有的Hash表中的数据时，需将其修改的数据同步到其他控制器节点中，由其他控制器节点相应更新各自拥有的Hash表中的数据；因此，本实施例可以根据Hash表中的数据确定相应的控制器节点对交换机进行接管，而不需要引入第三方管理者，故而不会导致整个集群受限于第三方管理者的性能，因而大大提升了整体集群的效率和性能。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种软件定义网络控制器集群的调度方法，所述软件定义网络控制器集群包括若干控制器节点；其特征在于，每个控制器节点相应拥有一份Hash表，每份Hash表的数据包括：各个控制器节点的标识、各个控制器节点负责接管的交换机的标识、各个控制器节点的负载因子；其中，每个控制器节点只允许修改其拥有的Hash表中由其负责接管的交换机的标识以及其负载因子；每个控制器节点修改了其拥有的Hash表中的数据时，需将其修改的数据同步到其他控制器节点中，由其他控制器节点相应更新各自拥有的Hash表中的数据；

所述调度方法包括控制器节点选举方法，所述控制器节点选举方法包括：

本控制器节点获取需要选举接管的交换机的标识；

根据本控制器节点拥有的Hash表中的数据，判断是否接管获取到的标识对应的交换机。

2.根据权利要求1所述的软件定义网络控制器集群的调度方法，其特征在于，所述根据本控制器节点拥有的Hash表中的数据，判断是否接管获取到的标识对应的交换机的步骤包括：

根据本控制器节点拥有的Hash表中的数据，判断获取到的标识对应的交换机是否已被其他控制器节点接管；

若是，则本控制器节点放弃接管；若否，则根据本控制器节点接管的交换机数量判断是否接管。

3.根据权利要求2所述的软件定义网络控制器集群的调度方法，其特征在于，所述根据本控制器节点接管的交换机数量判断是否接管的步骤包括：

根据本控制器节点拥有的Hash表中的数据，判断本控制器节点接管的交换机数量是否最小；若是，则根据是否有其他控制器节点接管的交换机数量与本控制器节点接管的交换机数量相等判断是否接管。

4.根据权利要求3所述的软件定义网络控制器集群的调度方法，其特征在于，所述根据是否有其他控制器节点接管的交换机数量与本控制器节点接管的交换机数量相等判断是否接管的步骤包括：

根据本控制器节点拥有的Hash表中的数据，判断是否有其他控制器节点接管的交换机数量与本控制器节点接管的交换机数量相等；

若否，则本控制器节点进行接管；若是，则根据本控制器节点的标识序号判断是否接管。

5.根据权利要求4所述的软件定义网络控制器集群的调度方法，其特征在于，所述根据本控制器节点的标识序号判断是否接管的步骤包括：

根据本控制器节点拥有的Hash表中的数据，判断本控制器节点的标识序号在所有接管交换机数量与其相等的控制器节点的标识序号中是否最小；

若是，则本控制器节点接管进行接管。

6.根据权利要求1至5任一所述的软件定义网络控制器集群的调度方法，其特征在于，本控制器节点对获取到的标识对应的交换机进行接管后还包括：

本控制器节点修改其拥有的Hash表中由其负责接管的交换机的标识以及其负载因子，并将其修改的数据同步到其他控制器节点中；由其他控制器节点相应更新各自拥有的Hash表中的数据。

7.根据权利要求6所述的软件定义网络控制器集群的调度方法，其特征在于，本控制器节点具体通过TCP将其修改的数据同步到其他控制器节点中。

8.根据权利要求7所述的软件定义网络控制器集群的调度方法，其特征在于，本控制器节点通过openflow协议发送请求接管的数据包给交换机，以实现对获取到的标识对应的交换机的接管。

9.根据权利要求8所述的软件定义网络控制器集群的调度方法，其特征在于，所述调度方法还包括同步数据修复方法，所述同步数据修复方法包括：

查询本控制器节点拥有的Hash表中是否存在异常数据，若是，则对本控制器节点所拥有的Hash表中的数据进行修复，同时对其他控制器节点所拥有的Hash表中相应的数据进行同步修复。

10.根据权利要求9所述的软件定义网络控制器集群的调度方法，其特征在于，所述调度方法还包括负载均衡方法，所述负载均衡方法包括：

根据本控制器节点拥有的Hash表中的数据判断本控制器节点是否处于负载空闲状态，若是，则主动接管负载繁忙的控制器节点的需要放弃的交换机，直至本控制器节点达到负载饱和状态。