CN114448984B - 跨平台通用sdn控制器的适配方法 - Google Patents
跨平台通用sdn控制器的适配方法 Download PDFInfo
- Publication number
- CN114448984B CN114448984B CN202111618426.XA CN202111618426A CN114448984B CN 114448984 B CN114448984 B CN 114448984B CN 202111618426 A CN202111618426 A CN 202111618426A CN 114448984 B CN114448984 B CN 114448984B
- Authority
- CN
- China
- Prior art keywords
- controller
- switch
- controllers
- node
- load balancing
- 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
- 238000000034 method Methods 0.000 title claims abstract description 49
- 230000006978 adaptation Effects 0.000 title claims abstract description 16
- 238000009826 distribution Methods 0.000 claims description 23
- 230000004044 response Effects 0.000 claims description 23
- BCGWQEUPMDMJNV-UHFFFAOYSA-N imipramine Chemical compound C1CC2=CC=CC=C2N(CCCN(C)C)C2=CC=CC=C21 BCGWQEUPMDMJNV-UHFFFAOYSA-N 0.000 claims description 21
- 230000002776 aggregation Effects 0.000 claims description 19
- 238000004220 aggregation Methods 0.000 claims description 19
- 230000008569 process Effects 0.000 claims description 17
- 238000004364 calculation method Methods 0.000 claims description 10
- 238000007726 management method Methods 0.000 description 16
- 238000003860 storage Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 3
- 230000000737 periodic effect Effects 0.000 description 3
- 230000003068 static effect Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000005304 joining Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/12—Discovery or management of network topologies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/30—Decision processes by autonomous network management units using voting and bidding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/10—Packet switching elements characterised by the switching fabric construction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请提供一种跨平台通用SDN控制器的适配方法，引入了主/从模式的Zookeeper加RYU的模式来实现多控制的管理和对全网信息的集中化控制。通过预先设定的选举规则确定一台交换机的主控制器，其余的全部控制器作为只读控制器，在主控制器出现宕机等失效故障时，全部只读控制器立即参与选举，重新确定新的主控制器，避免了SDN单一控制器单点失效和SDN控制器难以适配的问题，实现多控制器的集群化协同工作，进而实现了控制器集群的管理,减轻每台控制器的负载，提高了主控制器的工作效率。多控制器的集群化协同工作为实现多控制器下的流量负载均衡提供了条件。
Description
技术领域
本申请涉及计算机网络技术领域，尤其涉及一种跨平台通用SDN控制器的适配方法。
背景技术
由于互联网应用的爆发式增长，全球信息量每年以指数级的速度增加。目前，诸如路由器的数据转发设备将控制平面和数据转发平面耦合在一起，导致路由器如要支持新功能所需的升级成本和难度极大，安全性也不够高，因此，网络需要一种新的结构来增强可扩展性和服务能力。SDN创造性的将控制平面的逻辑和转发平面分离，SDN中包括两种设备，交换机和控制器。控制器通过Openflow协议向交换机下发流表规则来控制交换机的转发能力，交换机通过流表完成数据的转发。SDN的核心在于转发逻辑不再固化于硬件，所有的转发逻辑都由控制器通过Openflow协议动态下发至交换机，交换机可以支持各种类型的规则，极大的增强了网络的可扩展性。
但是，相关技术中的SDN分布式架构中控制平面的集中化使得控制器出现单点故障的危害性较大，同时单个控制器可支持的交换机数量有限，不能满足网络规模的不断扩展。
发明内容
有鉴于此，本申请的目的在于提出一种跨平台通用SDN控制器的适配方法用于解决上述问题。
基于上述目的，本申请提供了一种跨平台通用SDN控制器的适配方法，一种跨平台通用SDN控制器的适配方法，其特征在于，在Zookeeper内，每一个/dpid节点均与一个交换机相对应，所述/dpid节点中的/counter节点与所述交换机连接的全部controller控制器相对应，所述/counter节点中的每一个/controllerID子节点分别与所述全部controller控制器中的每一个controller控制器相对应；在Zookeeper内，选取/topology节点存储全网拓扑信息，所述/topology节点中的每一个/IP子节点分别与Zookeeper内的全部控制器中的每一个控制器相对应，所述方法包括：
通过选举规则确定一个所述controller控制器作为所述交换机的主控制器；
通过所述主控制器周期性的获取链路信息，并将所述链路信息存入所述主控制器对应的所述/IP子节点；
利用所述主控制器访问所述/topology节点，以获取全网拓扑信息；
基于所述全网拓扑信息和所述链路信息，通过全部控制器的集群管理实现负载的均衡分配；
响应于确定全部控制器中的任意一个所述主控制器在执行分配的过程中失效，在剩余的全部所述controller控制器中通过所述选举规则确定所述交换机对应的新的主控制器。
从上面所述可以看出，本申请提供的跨平台通用SDN控制器的适配方法，引入了Master/Slaves(主/从)模式的Zookeeper(分布式系统的可靠协调系统)加RYU(开源控制器实践)的模式来实现多控制的管理和对全网信息的集中化控制。对于与一台交换机连接的多个控制器来说，通过预先设定的选举规则确定交换机的主控制器，其余的全部控制器作为只读控制器，在主控制器出现宕机等失效故障时，全部只读控制器立即参与选举，重新确定新的主控制器，避免了SDN单一控制器单点失效和SDN控制器难以适配的问题，实现多控制器的集群化协同工作，进而去实现了控制器集群的管理，减轻每台控制器的负载，提高了主控制器得工作效率。多控制器的集群化协同工作为实现多控制器下的流量负载均衡提供了条件，并通过引入静态算法和动态算法来实现流量的负载均衡。
附图说明
为了更清楚地说明本申请或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的Zookeeper的示意图；
图2为本申请实施例提供的跨平台通用SDN控制器的适配方法的流程图；
图3为本申请实施例第一次选举示意图；
图4为本申请实施例第二次选举示意图；
图5为本申请实施例的跨平台通用SDN控制器的适配方法步骤100的流程图；
图6为本申请实施例的选举流程图；
图7为本申请实施例的跨平台通用SDN控制器的适配方法步骤500的流程图；
图8为本申请实施例的跨平台通用SDN控制器的适配方法步骤200的流程图；
图9为本申请实施例的链路获取过程示意图；
图10为本申请实施例的跨平台通用SDN控制器的适配方法步骤400的流程图；
图11为本申请实施例的跨平台通用SDN控制器的适配方法步骤420的流程图；
图12为本申请实施例的一次负载均衡的流程图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本申请进一步详细说明。
需要说明的是，除非另外定义，本申请实施例使用的技术术语或者科学术语应当为本申请所属领域内具有一般技能的人士所理解的通常意义。本申请实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。
相关技术中，SDN分布式架构中控制平面的集中化使得控制器出现单点故障的危害性较大，同时单个控制器可支持的交换机数量有限，不能满足网络规模的不断扩展，单一控制器存在单点失效问题，即在网络比较繁重的情况下，全局控制器发生宕机，该网络将不能正常工作，不利于多控制器的集群化协同工作去实现控制器集群的管理,加重每台控制器的负载。虽然可采用将一定数量的控制器物理分布在整个网络中的办法来缓解上述问题，但是不利于整体的维护和延展性，且对于单点失效问题的解决效率较低。
在一些实施例中，如图1和图2所示，一种跨平台通用SDN控制器的适配方法，引入了主/从Master/Slaves模式的分布式系统的可靠协调系统Zookeeper加开源控制器实践RYU的模式来实现多控制的管理和对全网信息的集中化控制。
其中，Zookeeper分布式服务框架是ApacheHadoop的子项目，它主要被用来解决分布式集群中应用系统的一致性问题，如统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。Zookeeper能提供基于类似于文件系统的目录节点树方式的数据存储，但是Zookeeper并不是用来专门存储数据的，它的作用主要是用来维护和监控存储的数据的状态变化,通过监控这些数据状态的变化，从而实现基于数据的集群管理。ZooKeeper的作用如下：
1.配置管理
在一些客户端的应用中，除了代码外还有各种配置，比如数据库连接等。一般使用配置文件的方式，在代码中引入这些配置文件。当只有一种配置且只有一台服务器，并且不经常修改的时候，使用配置文件是一个很好的做法，但是如果配置非常多，有很多服务器都需要这个配置，使用配置文件就无法达到很好地配置效果了。这个时候往往需要寻找一种集中管理配置的方法——Zookeeper，它使用Zab一致性协议来提供一致性。现在有很多开源项目使用Zookeeper来维护配置，比如在开源数据库HBase中，客户端就是连接一个Zookeeper，获得必要的HBase集群的配置信息，然后才可以进一步操作。另外，在开源的消息队列开源流处理平台Kafka中，也使用Zookeeper来维护broker的信息。在Alibaba开源的SOA框架Dubbo中也广泛的使用Zookeeper管理一些配置来实现服务治理。
2.名字服务
为了通过网络访问一个系统，需要得知道对方的IP地址，但是IP地址对他人的访问非常不友好，这个时候我们就需要使用域名来访问。需要在每台计算机里都备有一份域名到IP地址的映射，使用这个方法可以解决一部分问题，但是如果域名对应的IP发生变化，这种方法会失效。于是采用域名服务DNS来解决这个问题。而软件定义网络SDN控制器控制交换机利用协议和端口号识别DNS请求。
3.分布式锁
Zookeeper作为一个分布式协调服务，可以利用Zookeeper来协调多个分布式进程之间的活动。例如：在一个分布式环境中，为了提高可靠性，集群中的每台服务器上都部署着同样的服务。但是，一件事情如果集群中的每个服务器都进行的话，那相互之间就要协调，编程起来将非常复杂。而如果我们只让一个服务器进行操作，那又存在单点失效的问题。通常还有一种做法就是使用分布式锁，在某个时刻只让一个服务器去工作，当这台服务器出问题的时候锁释放，立即转移到另外的服务器。这在很多分布式系统中都是这么做，这种设计还叫做leader选举LeaderElection。比如，本申请中的步骤100中交换机的的主控制器MasterController就是采用这种机制进行选举的。
4.集群管理
在分布式的集群中，经常会出现硬件故障，软件故障，网络问题，导致有些节点会进进出出。有新的节点加入进来，也有老的节点退出集群。这个时候，集群中其他机器需要感知到这种变化，然后根据这种变化做出对应的决策。例如：一个分布式存储系统，有一个中央控制节点负责存储的分配，当有新的存储进来的时候我们要根据现在集群目前的状态来分配存储节点。这个时候就需要动态感知到集群目前的状态，为Zookeeper提供了很强的扩展性。
在Zookeeper中，znode是一个跟Unix文件系统路径相似的节点，可以往这个节点存储或获取数据。Zookeeper底层是一套数据结构。这个存储结构是一个树形结构，其上的每一个节点，我们称之为“znode”，zookeeper中的数据是按照“树”结构进行存储的。而且，znode节点还分为4中不同的类型。每一个znode默认能够存储1MB的数据(对于记录状态性质的数据来说，是足够的)可以使用zkCli命令，登录到zookeeper上，并通过ls、create、delete、get、set等命令操作这些znode节点。
需要说明的是，在接下来的实施例中，带有“/”的节点都为zookeeper上的一个znode节点。
在一些实施例中，如图1所示，在Zookeeper内，每一个/dpid节点均与一个交换机相对应，/dpid节点中的/counter节点与交换机连接的全部controller控制器相对应，/counter节点中的每一个/controllerID子节点分别与全部controller控制器中的每一个controller控制器相对应；在Zookeeper内，选取/topology节点存储全网拓扑信息，/topology节点中的每一个/IP子节点分别与Zookeeper内的全部控制器中的每一个控制器相对应。
其中，znode“/swtat”及其子节点用于完成每个交换机的控制器选举,不同的交换机使用znode“/dpid”作为其唯一标识，使用znode“/counter”及其子节点“/controllerID”作为一台交换机连接的不同的控制器的标识。znode“/mflag”用作判断是否存在主控制器MasterController的标志位，znode“/mlock”用于多控制器选举；znode“/topology"用于存放全网拓扑信息,其子节点“/IP”标识了不同的控制器，znode“/IP”中存放的是JSON格式的设备连接信息。当某台交换机与其MasterController断开连接时，/mflag节点文件便被删除，与之相连的控制器全部参与新的选举。
在一些实施例中，如图1至图4所示，跨平台通用SDN控制器的适配方法包括：
步骤100，通过选举规则确定一个controller控制器作为交换机的主控制器。
在该步骤中，为了区分不同位置及功能的控制器，由于与一个交换机连接的多个控制器位于controller节点，称其为controller控制器。如图3所示，选取与一台交换机连接的三个controller控制器为例进行说明；三台controller控制器根据Zookeeper分布式锁的功能参与交换机主控制器MasterController的选举，三台controller控制器同时对交换机进行锁定，将最先建立锁定关系的controller控制器作为主控制器MasterController，其他controller控制器与交换机存在只读关系，参与同一个交换机选举的不同controller控制器之间通过心跳机制进行连接，为重新选举做准备。
步骤200，通过主控制器周期性的获取链路信息，并将链路信息存入主控制器对应的/IP子节点。
在该步骤中，主控制器控制交换机向位于其他节点的交换机发送自身的信息，并接收位于其他节点交换机发送的信息，就可以得到位于不同节点上的交换机之间的链路信息，将该链路信息发送给主控制器进行保存，控制器周期性的将自己获得链路信息存入Zookeeper。
步骤300，利用主控制器访问/topology节点，以获取全网拓扑信息。
在该步骤中，控制器可访问znode“/topology”节点来获取全网的拓扑信息。使用IP地址作为控制器的标识，则不同的子节点/IP代表不同的控制器中掌握的链路信息和链接信息，以JSON格式存储，示例：
{srcdpid:1,dst:{dpid:2,port:3},time:1433071083}。
控制器遍历所有znode“/IP”即可获取全网的拓扑信息，帮助某一节点的主控制器了解全网的信息，为计算全网集群和服务器的负载做准备。
步骤400，基于全网拓扑信息和链路信息，通过全部控制器的集群管理实现负载的均衡分配。
在该步骤中，通过Zookeeper集群管理的功能来实现位于不同节点的控制器的集群控制，基于SDN多控制器下的流量负载均衡方案采用NAT地址转换(三层转发)与MAC地址转换(二层转发)相结合的方式，通过在不同的子网络之间根据负载均衡算法的计算结果按照指定的负载均衡服务集群或服务器的相关参数对数据流的每一个数据包进行NAT转换和MAC地址的修改，同时确定数据流在交换机上的出口并将其发送给下一级设备。
其中，在主控制器中，根据用户请求对应的数据流的发送方MAC地址和目的端口作为其匹配的参数。凡是符合某个特定的发送方MAC地址和目的端口的数据包在该流表项的生命周期内都不会再向控制器进行汇报，而是根据流表内容进行对应的操作并发往对应的端口，送往之前计算出的负载均衡服务器进行处理。初始分配算法在流表生命周期内将来自同一MAC地址的同一数据流交由同一台负载均衡服务器处理，有效地减少了丢包率。而因为匹配规则是基于MAC地址，不是基于IP地址，这种识别方式对于用户网络中位于NAT设备后的用户也是友好的，有利于NAT用户在使用过程中进行状态保持。这些终端可以被识别为独立终端，增加了算法的识别粒度，进一步提高了算法的效率。
其中，通过引入静态算法和动态算法来实现流量的负载均衡，负载均衡算法的静态分配部分通过概率分布原理实现了流量按权分配的方案。动态调整算法能够针对过载服务器的负载进行平摊，通过动态伸缩区间原理充分利用了每台负载均衡服务器的资源，将当前负载逐级平摊并产生连锁反馈，使负载真正达到平衡状态并不断进行调节，有效地使负载均衡服务器集群保持在正常工作状态。通过分级可以减少位于上级的交换机和其对应主控制器的单点失效的概率。
步骤500，响应于确定全部控制器中的任意一个主控制器在执行分配的过程中失效，在剩余的全部controller控制器中通过选举规则确定交换机对应的新的主控制器。
在该步骤中，如图4所示，选取与一台交换机连接的三个controller控制器为例进行说明，当某台交换机的主控制器因宕机等原因而失效时，交换机对应/dpid节点删除失效的主控制器建立的节点，通过心跳机制维持交换机正常运作的同时，剩余的两台controller控制器立即进行第二次选举，确定新的主控制器。避免了由于单个控制器失效导致的单点失效问题，为全网控制器的集群管理提供保证。
在一些实施例中，如图5和图6所示，通过选举规则确定一个controller控制器作为交换机的主控制器，具体包括：
步骤110，响应于确定交换机不存在/mflag节点，多个controller控制器通过锁定交换机的/mlock节点参与选举，其中，/mflag节点为主控制器对应的节点。
在该步骤中，因为/mflag节点为主控制器对应的节点，在确定交换机不存在/mflag节点时，说明该交换机还没有主控制器，此时参与选举的多个controller控制器同时锁定交换机的/mlock节点参与选举。
步骤120，响应于确定交换机存在/mflag节点，将建立该/mflag节点的controller控制器作为主控制器，其他全部controller控制器均作为只读控制器。
在该步骤中，因为/mflag节点为主控制器对应的节点，在确定交换机存在/mflag节点时，说明该交换机已经有主控制器，该主控制为参与选举的多个controller控制器中最先建立/mflag节点的那个控制器，其余controller控制器在建立/mflag节点时，发现已经存在/mflag节点，则停止选举，作为该交换机的只读控制器。
在一些实施例中，如图4和图7所示，响应于确定全部控制器中的任意一个主控制器在执行分配的过程中失效，在剩余的全部controller控制器中通过选举规则确定交换机对应的新的主控制器，具体包括：
步骤510，交换机删除已失效的主控制器的/mflag节点。
在该步骤中，可选地，当与同一台交换机连接的主控制器和多个只读控制器之间执行心跳机制来维持交换机的正常运行时，说明主控制器已经失效，需要只读控制器通过心跳机制暂时维持交换机的运行，此时，删除交换机对应的/dpid节点中失效主控制器建立的/mflag节点，为接下来的多个只读控制器进行选举留出主控制器对应的/mflag节点的标志位。
步骤520，剩余的全部controller控制器通过锁定交换机的/mlock节点参与选举，将建立新的/mflag节点的controller控制器作为新的主控制器。
在该步骤中，因为/mflag节点为主控制器对应的节点，在确定交换机不存在/mflag节点时，说明该交换机还没有主控制器，此时参与选举的多个controller控制器同时锁定交换机的/mlock节点参与选举，将最先建立/mflag节点的只读控制器作为新的主控制器。若任意一个只读控制器确定交换机存在/mflag节点，说明该交换机已经有主控制器，则停止选举，将该只读控制器继续作为该交换机的只读控制器。通过引入了主/从Master/Slaves模式的Zookeeper加RYU的模式，在保证单点控制器可以开源的同时避免了单点失效的问题。
在一些实施例中，如图8所示，通过主控制器周期性的获取链路信息，具体包括：
步骤210，主控制器周期性向交换机发送Packet-out消息。
在该步骤中，Packet-Out消息是从OpenFlow控制器向OpenFlow交换机发送的消息，是包含数据包发送命令的消息。若OpenFlow交换机的缓存中已存在数据包，而OpenFlow控制器发出“发送该数据包”的命令时，该消息指定了表示相应数据包的buffer_id。使用Packet-Out消息还可将OpenFlow控制器创建的数据包发送至OpenFlow交换机。此时，buffer_id置为-1，在Packet-Out消息的最后添加数据包数据。主控制器周期性的向交换机发送Packet-out消息就是周期性的发送“发送该数据包”的命令。
步骤220，响应于确定交换机接收到Packet-out消息，交换机向全网发送自身的dpid，并接收其他/dpid节点对应的交换机发送的dpid。
在该步骤中，接收到Packet-out消息的交换机执行“发送该数据包”的命令，将自身的dpid发送至全网其他节点，并接收其他交换机发送的dpid。
步骤230，响应于确定接收到其他/dpid节点对应的交换机发送的dpid，交换机向主控制器发送Packet-in消息。
在该步骤中，使用Packet-In消息的目的是为了将到达OpenFlow交换机的数据包发送至OpenFlow控制器。以下2种情况即可发送Packet-In消息：
1.不存在与流表项一致的项目时(Table-miss)，即OFPR_NO_MATCH。
2.匹配的流表项中记载的行动为“发送至OpenFlow控制器”时，即OFPR_ACTION。
发送Packet-In消息时OpenFlow交换机分为两种情况，一种是缓存数据包，一种是不缓存数据包。如果不通过OpenFlow交换机缓存数据包，那么Packet-In消息的buffer_id字段设置为-1，将整个数据包发送至OpenFlow控制器。如果通过OpenFlow交换机缓存数据包，那么以通过SET_CONFIG消息设置的miss_send_len为最大值的数据包数据将发送至OpenFlow控制器。miss_send_len的默认值为128。未实施SET_CONFIG消息的交换时，使用该默认值。在步骤230中对应的是第二种情况。
步骤240，响应于确定接收到Packet-in消息，主控制器接收并保存交换机的链路信息，其中，链路信息为任意两个相邻的/dpid节点之间的路径空间信息。
在该步骤中，主控制器接收带有链路信息的Packet-in消息，将该链路信息保存在该控制器的/IP节点中。
在一些实施例中，参考图9，以两个交换机，且每个交换机有三个端口为例进行解释说明，对于存在多个交换机的网络，下面的分析过程一样成立。
1、SDN主控制器c1通过构造Packet-out消息，向交换机s1的三个端口分别发送LLDP(链路层发现协议)数据包。
2、主控制器c1向交换机s1下发流表，流表规则为：将从Controller端口收到的LLDP数据包从规定端口发送出去。
3、主控制器c1再次向交换机s1下发流表，流表规则为：将从非Controller接收到LLDP数据包发送给主控制器c1。
4、当交换机s2发送的LLDP数据包到达交换机s1，会触发Packet-in消息发往控制器。控制器通过解析LLDP数据包，得到链路的源交换机(s2)，源接口(s2 port3)。通过收到的Packet-in消息知道目的交换机(s1)。
5、同理，当SDN主控制器c2向交换机s2发送Packet-out消息时，可以得知链路源交换机(s1)，源接口(s1 port1)。通过收到的Packet-in消息知道目的交换机(s2)。
如此，主控制器便发现了s1与s2之间的完整链路。
在一些实施例中，利用主控制器访问/topology节点，以获取全网拓扑信息，具体包括：主控制器通过遍历全部其他/IP子节点以获取每一个其他/IP子节点的拓扑信息，全部的拓扑信息组成全网拓扑信息。
其中，znode“/topology"节点用于存放全网拓扑信息,其子节点“/IP”标识了不同的控制器，znode“/IP”中存放的是JSON格式的设备连接信息，一个/IP子节点对应的主控制器通过遍历全部其他/IP子节点以获取每一个其他/IP子节点的拓扑信息，全部的拓扑信息组成/topology节点存储的全网拓扑信息。
在一些实施例红，如图10所示，基于全网拓扑信息和链路信息，通过全部控制器的集群管理实现负载的均衡分配，具体包括：
步骤410，响应于确定接收到用户的服务请求，全部交换机中的用户交换机将服务请求对应的数据流传送至全部控制器中的OpenFlow汇聚交换机。
在该步骤中，当用户访问相关服务时，通过用户交换机将用户请求对应的数据流汇集到OpenFlow汇聚交换机。
步骤420，OpenFlow汇聚交换机对应的全局主控制器根据服务请求对应的数据流生成负载均衡分配表。
在该步骤中，OpenFlow汇聚交换机对应的全局主控制器接收这些数据流并生成负载均衡分配表，此过程为负载均衡算法的静态分配过程，通过概率分布原理生成的负载均衡分配表实现了流量按权分配的方案。
步骤430，基于负载均衡分配表，OpenFlow汇聚交换机对应的负载均衡服务器通过散列计算和动态调整算法对数据流进行负载分配。
在该步骤中，需要对过载服务器或集群的负载进行平摊，通过动态伸缩区间原理充分利用了每台负载均衡服务器的资源，将当前负载逐级平摊并产生连锁反馈，使负载真正达到平衡状态并不断进行调节，有效地使负载均衡服务器集群保持在正常工作状态，对应负载均衡算法的动态分配过程。
其中，逐级的好处在于：在网络拓扑结构中的每一级交换机收到某个与当前流表不匹配的数据流后，会上传其特征信息给主控制器用于决定其最终的负载均衡服务器和该数据流在数据中心网络中的发送/返回路径。通过这种方式，只有在该数据流经过某一级交换机时才需要确定其接下来的发送路径,而不是一次性在Openflow汇聚交换机将路径计算完成。这有助于主控制器及时获得服务器和集群的最新负载信息并根据最新信息计算数据流在下一级中的实际路径。
在一些实施例中，OpenFlow汇聚交换机对应的全局主控制器根据服务请求对应的数据流生成负载均衡分配表，具体包括：全局主控制器根据链路信息计算每个服务器和每个集群的负载能力，基于每个服务器和每个集群的负载能力和OpenFlow汇聚交换机接收到的全部数据流，生成负载均衡分配表。
其中，全局主控制器通过计算每个服务器和每个集群的负载能力，根据OpenFlow汇聚交换机接收到的全部数据流的流量权重生成负载均衡分配表。
在一些实施例中，如图11所示，基于负载均衡分配表，OpenFlow汇聚交换机对应的负载均衡服务器通过散列计算和动态调整算法进行数据流的负载分配，具体包括：
步骤421，响应于确定集群未超载，对该未超载集群内的全部服务器的进行负载分配。
在该步骤中，若集群对应的层级不存在超载集群，则进行服务器层级的负载动态分配。
步骤422，响应于确定集超载，负载均衡服务器通过动态调整算法调整负载均衡分配表，以降低该超载集群分配到新负载的期望值。
在该步骤中，若集群对应的层级存在超载集群，负载均衡服务器通过动态调整算法调整负载均衡分配表降低该超载集群分配到新负载的期望值，来避免该集群分配到新的负载，从而降低该集群的负载，使其回复正常负载，或将其超载的一部分负载进行转移。
在一些实施例中，响应于确定所述集群未超载，对该未超载集群内的全部服务器的进行负载分配，具体包括：响应于确定未超载集群中的任意一个服务器超载，将该服务器作为超载服务器，负载均衡服务器通过动态调整算法调整负载均衡分配表，以减少该超载服务器分配到新负载的概率。
其中，当服务器层级存在超载服务器时，负载均衡服务器通过动态调整算法调整负载均衡分配表减少该超载服务器分配到新负载的概率，避免其收到新的负载导致其崩溃或超长时间超载运行。
在一些实施例中，在负载均衡服务器通过动态调整算法调整负载均衡分配表减少该超载服务器分配到新负载的概率的同时，还包括：负载均衡服务器对数据流进行散列计算，得到实际接受该数据流的服务器；利用该服务器对应的交换机的主控器改变该数据流流出的交换机接口、目的地址和链路层地址，将发送至该超载服务器的数据流传送至负载均衡服务器，以对数据流进行重新分配。
其中，当服务器层级出现超载服务器时，可以通过散列计算得到该超载服务器，进而利用该服务器对应的交换机的主控器改变发送至该超载服务器的数据流的流出的交换机接口、目的地址和链路层地址，将该数据流传送至负载均衡服务器，以对数据流进行重新分配。
在一些实施例中，参考图12，针对来自某个特定MAC地址、流向负载均衡服务器特定端口的数据流为例进行负载均衡分配的解释说明。
(1)用户产生服务请求，通过用户网络交换机传送到OpenFlow汇聚交换机。
(2)OpenFlow汇聚交换机检查是否有可用的集群分配表，若无可用集群分配表则根据不同的业务需求，按照每台服务器的硬件参数或每台机器相对应网络链路的性能参数计算出其负载能力并记录在主控制器中。同时根据每台服务器的负载能力计算出每个服务集群的总负载能力。这一过程完成后，根据不同集群的负载能力执行集群负载均衡分配表的初始化过程，得到一组初始的分配方案。
(3)根据每台服务器上报的当前运行负载参数进行动态调整，找出当前运行总负载超过其总负载警戒线的集群，相应地执行动态调整算法，调整负载均衡分配表使其分配到新负载的期望值降低。
(4)依据来访用户的MAC地址和目标端口进行散列计算，根据散列结果和用户的服务类型将来自用户的数据流分发给正在提供服务的某个服务集群。将结果以OpenFlow流表项(FlowTableEntry)的形式由控制器下发给OpenF1ow交换机，并在主控制器中记录该类型数据流与指定集群的对应关系。
(5)数据流被传送至服务集群的OpenFlow接入交换机时。主控制器检查当前集群是否有服务器的实际负载超过其负载警戒线。如果存在过载服务器，则运行动态调整算法减少其收到新负载的概率。同时对该数据流再次进行散列计算，计算出实际接受该数据流的服务器并通过主控制器下发流表,改变数据流流出的交换机接口、目的地址和链路层地址，从而使其到达负载均衡服务器。
(6)负载均衡服务器对数据流进行处理并向集群的OpenFlow接入交换机返回响应数据。交换机根据之前存储的数据流与服务器的对应关系增加响应数据流所需要的流表。负载均衡服务器向控制器汇报新的负载均衡状态。
(7)响应数据返回用户网络，一次负载均衡过程完成。
需要说明的是，本申请实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本申请实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。
需要说明的是，上述对本申请的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本申请的范围(包括权利要求)被限于这些例子；在本申请的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本申请实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。
另外，为简化说明和讨论，并且为了不会使本申请实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本申请实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本申请实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本申请的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本申请实施例。因此，这些描述应被认为是说明性的而不是限制性的。
尽管已经结合了本申请的具体实施例对本申请进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。
本申请实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本申请实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本申请的保护范围之内。
Claims (9)
1.一种跨平台通用SDN控制器的适配方法，其特征在于，在Zookeeper内，每一个/dpid节点均与一个交换机相对应，所述/dpid节点中的/counter节点与所述交换机连接的全部controller控制器相对应，所述/counter节点中的每一个/controllerID子节点分别与所述全部controller控制器中的每一个controller控制器相对应；在Zookeeper内，选取/topology节点存储全网拓扑信息，所述/topology节点中的每一个/IP子节点分别与Zookeeper内的全部控制器中的每一个控制器相对应，所述方法包括：
通过选举规则确定一个所述controller控制器作为所述交换机的主控制器；
通过所述主控制器周期性的获取链路信息，并将所述链路信息存入所述主控制器对应的所述/IP子节点；
利用所述主控制器访问所述/topology节点，以获取全网拓扑信息；
基于所述全网拓扑信息和所述链路信息，通过全部控制器的集群管理实现负载的均衡分配；
响应于确定全部控制器中的任意一个所述主控制器在执行分配的过程中失效，在剩余的全部所述controller控制器中通过所述选举规则确定所述交换机对应的新的主控制器；
其中，所述基于所述全网拓扑信息和所述链路信息，通过全部控制器的集群管理实现负载的均衡分配，包括：
响应于确定接收到用户的服务请求，全部交换机中的用户交换机将所述服务请求对应的数据流传送至全部控制器中的OpenFlow汇聚交换机；
所述OpenFlow汇聚交换机对应的全局主控制器根据所述服务请求对应的数据流生成负载均衡分配表：
基于所述负载均衡分配表，所述OpenFlow汇聚交换机对应的负载均衡服务器通过散列计算和动态调整算法对所述数据流进行负载分配。
2.根据权利要求1所述的方法，其特征在于，所述通过选举规则确定一个所述controller控制器作为所述交换机的主控制器，具体包括：
响应于确定所述交换机不存在/mflag节点，多个所述controller控制器通过锁定所述交换机的/mlock节点参与选举，其中，所述/mflag节点为所述主控制器对应的节点；
响应于确定所述交换机存在所述/mflag节点，将建立该/mflag节点的所述controller控制器作为所述主控制器，其他全部所述controller控制器均作为只读控制器。
3.根据权利要求2所述的方法，其特征在于，所述响应于确定全部控制器中的任意一个所述主控制器在执行分配的过程中失效，在剩余的全部所述controller控制器中通过所述选举规则确定所述交换机对应的新的主控制器，具体包括：
所述交换机删除已失效的所述主控制器的所述/mflag节点；
剩余的全部所述controller控制器通过锁定所述交换机的/mlock节点参与选举，将建立新的所述/mflag节点的所述controller控制器作为新的主控制器。
4.根据权利要求1所述的方法，其特征在于，通过所述主控制器周期性的获取链路信息，具体包括：
主控制器周期性向交所述换机发送Packet-out消息；
响应于确定所述交换机接收到所述Packet-out消息，所述交换机向全网发送自身的dpid，并接收其他/dpid节点对应的交换机发送的dpid；
响应于确定接收到其他/dpid节点对应的交换机发送的dpid，所述交换机向所述主控制器发送Packet-in消息；
响应于确定接收到所述Packet-in消息，所述主控制器接收并保存所述交换机的所述链路信息，其中，所述链路信息为任意两个相邻的所述/dpid节点之间的路径空间信息。
5.根据权利要求1所述的方法，其特征在于，所述利用所述主控制器访问所述/topology节点，以获取全网拓扑信息，具体包括：
所述主控制器通过遍历全部其他所述/IP子节点以获取每一个其他所述/IP子节点的拓扑信息，全部的所述拓扑信息组成所述全网拓扑信息。
6.根据权利要求1所述的方法，其特征在于，所述OpenFlow汇聚交换机对应的全局主控制器根据所述服务请求对应的数据流生成负载均衡分配表，具体包括：
所述全局主控制器根据所述链路信息计算每个服务器和每个集群的负载能力，基于每个服务器和每个集群的负载能力和所述OpenFlow汇聚交换机接收到的全部所述数据流，生成所述负载均衡分配表。
7.根据权利要求6所述的方法，其特征在于，所述基于所述负载均衡分配表，所述OpenFlow汇聚交换机对应的负载均衡服务器通过散列计算和动态调整算法进行所述数据流的负载分配，具体包括：
响应于确定所述集群未超载，对该未超载集群内的全部服务器进行负载分配；
响应于确定所述集群超载，所述负载均衡服务器通过所述动态调整算法调整所述负载均衡分配表，以降低该超载集群分配到新负载的期望值。
8.根据权利要求7所述的方法，其特征在于，所述响应于确定所述集群未超载，对该未超载集群内的全部服务器的进行负载分配，还包括：
响应于确定未超载集群中的任意一个服务器超载，所述负载均衡服务器通过所述动态调整算法调整所述负载均衡分配表，以减少该超载服务器分配到新负载的概率。
9.根据权利要求8所述的方法，其特征在于，在所述负载均衡服务器通过所述动态调整算法调整所述负载均衡分配表减少该超载服务器分配到新负载的概率的同时，还包括：
所述负载均衡服务器对所述数据流进行散列计算，得到实际接受所述数据流的服务器；
利用该服务器对应的交换机的主控器改变所述数据流流出的交换机接口、目的地址和链路层地址，将发送至该超载服务器的数据流传送至所述负载均衡服务器，以对所述数据流进行重新分配。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111618426.XA CN114448984B (zh) | 2021-12-27 | 2021-12-27 | 跨平台通用sdn控制器的适配方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111618426.XA CN114448984B (zh) | 2021-12-27 | 2021-12-27 | 跨平台通用sdn控制器的适配方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114448984A CN114448984A (zh) | 2022-05-06 |
| CN114448984B true CN114448984B (zh) | 2024-01-09 |
Family
ID=81365545
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111618426.XA Active CN114448984B (zh) | 2021-12-27 | 2021-12-27 | 跨平台通用sdn控制器的适配方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114448984B (zh) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115484214A (zh) * | 2022-09-13 | 2022-12-16 | 杭州迦尔科技有限公司 | 一种工控网络终端类型检测及网络服务质量优化方法 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106713177A (zh) * | 2016-11-21 | 2017-05-24 | 华南理工大学 | 一种多控制器的wmSDN组网方法 |
| CN106936731A (zh) * | 2015-12-31 | 2017-07-07 | 北京华为数字技术有限公司 | 软件定义网络sdn中的报文转发的方法和装置 |
| CN107819695A (zh) * | 2017-10-19 | 2018-03-20 | 西安电子科技大学 | 一种基于sdn的分布式控制负载均衡系统与方法 |
| CN109587071A (zh) * | 2018-11-30 | 2019-04-05 | 北京工业大学 | 基于sdn的微服务负载均衡方法 |
| CN111355658A (zh) * | 2020-02-28 | 2020-06-30 | 电子科技大学 | 基于分布式服务框架的sdn跨域协作方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9866487B2 (en) * | 2014-06-05 | 2018-01-09 | KEMP Technologies Inc. | Adaptive load balancer and methods for intelligent data traffic steering |
-
2021
- 2021-12-27 CN CN202111618426.XA patent/CN114448984B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106936731A (zh) * | 2015-12-31 | 2017-07-07 | 北京华为数字技术有限公司 | 软件定义网络sdn中的报文转发的方法和装置 |
| CN106713177A (zh) * | 2016-11-21 | 2017-05-24 | 华南理工大学 | 一种多控制器的wmSDN组网方法 |
| CN107819695A (zh) * | 2017-10-19 | 2018-03-20 | 西安电子科技大学 | 一种基于sdn的分布式控制负载均衡系统与方法 |
| CN109587071A (zh) * | 2018-11-30 | 2019-04-05 | 北京工业大学 | 基于sdn的微服务负载均衡方法 |
| CN111355658A (zh) * | 2020-02-28 | 2020-06-30 | 电子科技大学 | 基于分布式服务框架的sdn跨域协作方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114448984A (zh) | 2022-05-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Fu et al. | Orion: A hybrid hierarchical control plane of software-defined networking for large-scale networks | |
| US10158533B2 (en) | System and method for base topology selection | |
| EP3229405B1 (en) | Software defined data center and scheduling and traffic-monitoring method for service cluster therein | |
| US9806983B2 (en) | System and method for control flow management in software defined networks | |
| US11637755B2 (en) | SDN network system, controller, and controlling method | |
| CN104202266B (zh) | 一种通信方法、交换机、控制器及通信系统 | |
| CN104753828B (zh) | 一种sdn控制器、数据中心系统和路由连接方法 | |
| CN109905251B (zh) | 网络管理方法、装置、电子设备和存储介质 | |
| US10574595B2 (en) | System and method for elastic scaling of virtualized network functions over a software defined network | |
| Wu et al. | DARD: Distributed adaptive routing for datacenter networks | |
| CN103795805A (zh) | 基于sdn的分布式服务器负载均衡方法 | |
| CN104521199A (zh) | 用于分布式虚拟交换机的适应性基础设施 | |
| CN105357024A (zh) | 用于sdn网络的区域控制设备、域控制设备和控制系统 | |
| US20170230290A1 (en) | Multi-domain centralized content-centric networking | |
| US10848432B2 (en) | Switch fabric based load balancing | |
| CN105049231A (zh) | 一种分层跨域的网络管理控制系统 | |
| CN106656905A (zh) | 防火墙集群实现方法及装置 | |
| CN105656715B (zh) | 用于监测云计算环境下网络设备的状态的方法和装置 | |
| CN106060858A (zh) | 基于OpenFlow扩展协议的软件定义卫星组网的方法及装置 | |
| Gadasin et al. | Routing Management System Formation for Machine-to-Machine Interaction in a Decentralized Environment | |
| CN114448984B (zh) | 跨平台通用sdn控制器的适配方法 | |
| CN110932972B (zh) | 一种数据传输方法、装置及电子设备 | |
| CN106850803B (zh) | 一种基于sdn的加权轮询系统及算法 | |
| Romanov et al. | Construction of the SDN Control Level Based on ONOS | |
| CN104506339A (zh) | 基于profinet的工业以太网网络拓扑管理实现方法 |
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 | ||
| GR01 | Patent grant |