基于open的SDN控制平面可扩展性（二）

控制平面可扩展性

制约 SDN 控制平面可扩展性的主要原因有以下几点:

(1) 流的细粒度处理需求使得控制器需要响应更多的流请求事件.虽然控制器可以通过主动决策机制提 前将控制逻辑部署到数据转发单元,减少数据平面和控制器之间的处理开销,但控制逻辑的变化通 常是动态的,尤其是当网络拓扑改变或者存在移动结点时.在 OpenFlow 网络中,提前安装流表项也将 使大量流表空间无法释放,浪费资源,而实际上大部分流的持续时间是很短的.
(2) 接入控制、负载均衡、资源迁移等新型应用需求逐渐增加到控制平面当中,控制器需要对日趋复杂 的管控功能进行有效的整合,这进一步增加了控制平面的处理开销.
(3) 传统分布式网络设备仅根据局部的路由信息来实现路由转发,而控制平面需要维护全局的网络状态 信息,这也使得控制平面的可扩展性不仅需要考虑性能的需求,而且要考虑网络状态的一致性.
(4) 在网络规模增大、数据平面转发设备数量增多的环境下,单控制器设备可能难以满足性能需求.

1. DIFANE

控制器在交换机中选出权威交换机，权威交换机管理分区内所有的交换机。
控制器主动将分区规则安装到所有的 OpenFlow 交换机上,并根据全局网络信息主动在权威交换机上安装权威规则。

当普通交换机产生新的数据流时,它根据自 身的分区规则直接和自己分区内的权威交换机进行通信.由于权威交换机已提前部署了权威规则,因而可以向 普通交换机安装缓存规则,同时,直接将请求数据转发给目的地而无须再返回给源交换机。

由于权威交换机能够管理普通交换机的流建立请求,因此,控制器仅需要管理整个网络 的区域划分和权威交换机的流触发规则

2. DevoFlow

考虑到当前的OpenFlow交换机流建立过程和统计信息收集过程将会消耗大量数据平面和控 制平面之间的带宽，DevoFlow 采取了两种方 式来减小 OpenFlow 交换机和控制器的信息交互:规则复制和局部操作.

带通配符的流表项一般由硬件TCAM实现,而精确匹配的流表项由软件实现,因而同时也减少 了 TCAM 资源的消耗

在包含通配符的流表项中“操作”字段上增加了CLONE标志,如果该标志清零,则匹配该流表 项的报文按正常情况处理;如果该标志被置位,则直接根据匹配报文建立精确匹配的微流,从而细化每一条微流 的统计信息.
局部操作方式包括多路径支持和快速重路由。
多路径支持是指为 OpenFlow 交换机中可复制的通配符流表 项提供多个可能的输出端口,DevoFlow 根据概率分布将报文输出到特定端口中,而不是采用传统的等价多路径路由方式(ECMP).
快速重路由给 OpenFlow 交换机指定了 1 条到多条备用路径,从而在链路失效时立即转用备 用路径,而不是转发给控制器。快速重路由可通过安装不同优先级的流表来实现,但是需要在链路失败时将高优先级的流表项删除或者进行覆盖.

DevoFlow 考虑了流建立请求和获取统计信息的双重开销.
针对统计信息收集过程的开销,DevoFlow 采用 3 种方法来提高统计信息收集效率:采样、触发和报告、近似统计.采样方法将统计信息按照一定的样本概率转发给控制器;触发和报告通过设置阈值,在统计信息满足阈 值条件时将统计信息发给控制器;近似统计则只将流量最大的 k 条流的统计信息发给控制器.通常情况下,这 k 条流包含了 80%~99%的数据流.

3. HyperFlow

通过部署多台控制器来 管理OpenFlow 交换机,在每台控制器能够同步全网络视图的同时,只需要管理特定区域中的OpenFlow 交换机.

控制器之间通过消息的发布-订阅模式来来传输网络 事件,每个控制器将订阅数据信道、控制信道和自身信道。
- 域内的网络和应用程序事件将发布给数据信道；
- 针对特定控制器的事件将分别发送给该控制器信道.
- 另外,每台控制器必须将自身的网络状态信息 定期发布给到控制信道,以利于控制器的发现和故障检测.

HyperFlow 是基于为广域网设计的分布式文件系统 WheelFS 而设计的,网络事件在不同控制器之间以文件的更新形式来实现.

全网络视图的更新将与网络状态信息发布的周期时间和传输时延相关,这由 WheelFS 的 实现机制决定,因此,这种实现方式适用于网络状态事件更新不频繁、对网络状态一致性要求不高的网络,对于 网络状态事件频繁更新的网络,或者对于数据中心或较大规模网络,HyperFlow 有可能面临性能瓶颈.

4. Onix

Onix提出了一整套面向大规模网络的分布式 SDN 部署方案.

Onix 网络架构主要由物理网络基础设施、网络连接基础设施、Onix 和网络控制逻辑这 4 部分 组成.

• 物理网络基础设施允许 Onix 读写网络状态;
• 网络连接基础设施提供 Onix 和物理网络基础设 施之间的通信连接;
• Onix 采用分布式架构向上层控制逻辑提供网络状态的编程接口;
• 网络控制逻辑则通过 Onix 提供的 API 来决策网络行为.
• 网络信息库(network information base,简称 NIB)用于维护网络全局的状态,Onix 的 设计关键就在于维护 NIB 的分发机制,从而保证整个网络状态信息的一致性.
  
  三种方式实现控制平面一致性：
  （1）分区，和 HyperFlow 一样,随着网络规模的增大,数据转发平面必须由不同的控制器进行分区管理. Onix 通过不同的实例管理每个域,并根据 NIB 来配置数据平面.
  （2）聚合，整个Onix网络将形成一个分层的拓扑结构,每个Onix实例需要维护本分区的路由决策,分区间 的路由决策则由 Onix 实例构成的集群共同决策.在网络规模增大、网络事件更新频繁的情况下,顶 层的控制逻辑将无法完全匹配网络事件的更新速度.为此,Onix 实例需要知道本域内的拓扑情况,而 将其余的 Onix 实例管理的网络看作是一个聚合的逻辑结点。
  （3）一致性和稳定性，根据不同的网络需求,Onix 提供两种方式来实现 NIB 的更新分发机制:带复制的事 务性数据库模式和 DHT 模式,前者的主要目标是提供一种可靠的分发机制,适用于网络事件更新缓 慢、对稳定性和一致性要求较高的网络;后者则通过通用 API、软状态触发器和坐标机制等 DHT 实 现机理,构建快速响应的分布式拓扑结构,适用于网络事件更新频繁、对网络可用性要求较高的网络.

5. Devolved controller

多路径区域划分问题在图论中是 NP 难问题,Devolved controller[36]针对多控制器管控区域划分问题提出了两种启发式算法:路径-分区算法(path- partition approach)和分区-路径算法(partition-path approach)

图片水印

去除水印，CSD博客中，将watermark代码中后面部分全部去掉即可， 如下图。

---

参考文献

[1]左青云, 陈鸣, 赵广松,等. 基于OpenFlow的SDN技术研究[J]. 软件学报, 2013(05):1078-1097.
[2] SDN核心技术剖析和实战指南