基于软件定义的数据中心网络控制技术*

2018-09-29谢卫，陈松

通信技术 2018年9期

谢卫，陈松

（中国电子科技集团公司第三十研究所，四川成都 600045）

0 引言

基于软件定义的数据中心网络采用控制平面和数据平面分离的思想，分离出的控制平面为应用程序提供北向编程接口，并通过南向接口来控制数据平面的转发行为。集中式运行的网络控制平面具有灵活和细粒度的控制能力，是网络的“大脑”，在软件定义网络中具有举足轻重的作用。本文将介绍分布式网络控制器集群的系统架构和控制模型，以满足大规模软件定义数据中心网络对网络控制的可扩展性、可靠性和其他性能的要求。

1 分布式集群控制器的架构

软件定义网络采用逻辑上集中的控制方式，这种方式一方面大大增加了网络控制的灵活性，另一方面带来了网络控制的可扩展性问题。分布式控制器集群可以有效解决网络控制的可扩展性问题。对于一个大规模软件定义网络，高效的分布式控制器集群应该满足三点要求：（1）具有良好的可扩展性；（2）具有高可靠性；（3）具有简单和高效的一致性保证机制。此外，随着硬件性能的快速提升和用户对数据中心网络灵活性方便的需求，虚拟化技术得到了快速发展，并在数据中心网络中得到了广泛应用。在服务器端，多个虚拟机可同时运行于同一个物理服务器上，以共享物理计算资源。控制器软件可以充分利用虚拟化的计算资源运行。

基于实际数据中心网络的特点，采用分布式分层分域控制架构较为合适。集群分布式控制架构的网络层次化结构能够简化网络规划，保证网络重构的快速性和准确性，充分发挥网络整体性能，减轻网络开销，实现网络分级分权分域管理，提高网络的可用性和可靠性。根据组网能力指标要求和保障需求，数据中心控制网络可以采用分层结构设计，如支持底层域控制L1、中间域控制L2和顶层域L3的三级组网模式[1]。如图1所示，整体架构中共有十几个基本区域（L1），每个区域内包含上百个网络节点，可将这十个区域根据不同需求组合为几个中型区域（L2）；顶层区域（L3）则负责管理三个中型区域。

图1 集群分布式分层分域控制架构

上层控制器将下层控制器当作网络节点进行控制，主要用于多区域间的寻路。各区域内有对应的控制器，各层控制器的权限不同，从顶层到底层，权限依次降低。L3控制器控制着整个网络，但是其不具体去对某个子区域内的路由进行管理，而是由其将指令发送到中型区域的L2控制器，中型区域的控制器再将指令分发到L1控制服务器以执行具体的网络操作。

图1中，各个区域内的控制服务器以虚线表示逻辑互连。由于各个区域内的网络分别由不同的控制器控制，为了在更大范围内实现控制服务器之间的相互通信和资源共享，两者之间的互联便成为一种信息快速传达的最好方式。本架构中各个区域内的控制服务器之间的互联是在应用层。而在图1中，同一区域内的控制服务器之间是以虚线互连，之间并没有实际的链路。例如，在基本区域的三个控制服务器之间以虚线互连，这个逻辑互连的网络由一个中型区域的控制器控制，同一层次控制域内的控制器相互协作，通过对等P2P协作控制其自身管理的区域。可以实现的功能包括网络可视化、流量工程优化和拓扑呈现。在物理拓扑发现和监测网络的过程中，需要交互大量从子区域内收集的信息，这需要每个控制器相互协调，通过同一层次的对等网络实现信息交互和共享，然后综合分析后将信息汇聚上报给顶层的控制器，使其依据这些数据做出相应的决策。

2 网络控制的一致性问题

软件定义网络存在两个控制一致性问题：状态更新一致性问题和网络状态视图一致性问题。状态更新一致性问题是指在控制器更新交换机流规则的过程中，由于控制消息下发先后和传输时延的影响，不同交换机上流表生效的时间存在差异，从而导致不同的交换机可能采用不同的流规则来处理同一条流，最终导致流路由成环、路由策略改变、流隔离失败等问题。目前，状态更新一致性问题的解决方案主要包括按一定顺序更新交换机控制策略、在数据包上打标签和使用精确的时间同步方法。这些方法都能取得较好效果，因此本项目中将重点研究网络状态视图一致性问题。

在大规模实际软件定义网络中，为了解决控制的可扩展性和可靠性，软件定义网络必然会使用分布式的网络控制器集群。分布式网络控制器集群采用多个控制器来控制网络，其中每个控制器负责控制一部分网络节点。然而，实际网络中，由于网络失效、通信延时、状态更新不及时等问题的影响，控制器集群中的不同控制器可能会看到不同的网络状态视图，从而导致控制器集群做出相互冲突甚至错误的网络控制策略，通常被称为网络状态视图不一致问题。

为了解决网络状态视图不一致问题，现有的分布式控制器集群架构如ONIX、ONOS、ODL等，都采用传统一致性保证机制，如Paxos或RAFT来保证多个分布式控制器上网络状态视图的一致性。这些传统的一致性保证机制基本都采用基于共识的机制，即当网络事件发生后，多个控制器之间需要先对该网络事件达成共识，然后才能执行相应操作。然而，应用这种基于共识机制的同步方案明显具有如下三点不足。第一，对网络事件的响应时间较慢。当网络事件发生后，控制器对该事件的响应必须在控制器达成共识后。第二，可用性较差。基于共识机制的同步方案中，只有当一定数量（比如一半及以上的）控制器都意识到网络事件后才算达成共识，如果网络中的一些控制器失效，且存活的控制器数量不足总法定数量，那么该共识机制不可用。第三，这些一致性保证机制会引入很大延时。为了提高网络控制的实行性和可靠性，需要简化和改进现有分布式控制器集群的一致性保证机制。

本文在控制器上增加了控制器代理模块，在交换机上增加了交换代理模块。每个控制器通过控制器代理模块周期性地向网络中的其他控制器通告它所在网络域中的网络事件日志，以实现控制器集群上网络事件日志的一致性。为了及时感知数据平面状态的变化，控制器代理模块还会定期向交换机发送探测消息，以探测交换机的状态。控制器代理模块会根据收到的网络事件日志和探测到的交换机状态，使用状态合并算法保证状态的一致性。当某个控制器观测到网络事件日志或者数据面状态发生了改变，它就触发控制策略重计算，以生成新的数据面配置。该方法的核心思想是控制器意识到网络事件后立马响应，避免了传统方案多控制器间达成共识所需要的时间，以及不需要达成共识所需法定人数的条件，避免传统方案某些场景不适用的情况。

3 多网络控制器的部署问题

在软件定义网络中，控制器的部署将会影响控制器处理网络事件的能力。例如，控制器响应交换机请求的网络时延与部署位置密切相关；当考虑网络可靠性时，每个节点至少要通过分离路径连接到至少2个控制器。控制器的部署问题主要需要解决两个问题：（1）确定控制器的部署数目，即在满足网络管理性能需求的情况下最少需要多少控制器；（2）确定控制器在拓扑中的位置以及每个控制器控制的网络节点（确定每个控制器的控制范围）。控制器部署问题主要考虑的性能目标包括部署代价、控制时延、控制器负载和可靠性要求[2]。

软件定义网络控制器部署问题为NP难问题。因此，拟采用近似算法进行求解。基于以往的研究经验，拟主要尝试的近似算法包括基于随机搜索的算法、基于多目标规划的算法和基于聚类的算法。基于随机搜索的算法的基本原理是采用有效的随机搜索算法（如模拟退火、遗传算法等）在解空间中搜索最好的解。基于随机搜索的算法的关键是如何确定各种算法参数，以使得算法收敛快、优化性能好。基于多目标规划的算法首先将控制器部署问题转化为一个多目标优化问题，而控制器部署的最优解取决于多个性能目标的满足程度，在多个性能尺度之间和各种约束条件之间求得一个合理的折中值，如用Pareto最优解作为控制器部署问题的解。基于聚类的算法根据选择的性能尺度和约束条件，将N个交换机（或网络节点）划分为K个类别，使每个类别内的交换机与控制器间关系的相似度较大，而交换机与其他类别的控制器间关系的相似度较小。K为控制器的数量，每个类别表示控制器的管理域。例如，可以使用函数g表示管理域间连接链路，代价函数f表示管理域内控制器与交换机见平均传输时延，通过使f和g最小化来对网络中管理域进行划分。

4 分布式网络控制器负载均衡策略

单台物理控制器受限于处理能力与资源的分配，且扩展性不够。因此，数据中心必须考虑采用分布式网络控制器的集群工作方式，以满足数据中心要求的可扩展性、可靠性。但是，集群工作下，控制器的负载均衡策略是一项待突破的关键技术。

根据控制器集群的南向接口集群要求，需要为每个交换机在OpenFlow集群中选择master/slave控制器。控制器的选择原则之一，是要保证最后的负载均衡；选择的原则之二，是要保证选择的控制器异常后对负载均衡的破坏程度最小。

负载均衡策略负责负载均衡计算和维护负载均衡的稳定性。根据以上两个原则，在负载均衡算法设计上，使用负载因子和影响因子作为集合选择的根本依据。

负载因子的设计，本质上是最小连接数思想。使用控制器管理的交换机数量，作为master/slave控制器选择的指标之一。该因子用来标识控制器的负载情况。负载因子越大，负载越重；反之，越轻[3]。

影响因子的设计，本质上是离散分布思想。使用控制器所接管交换机的slave连接分布情况，作为master/slave控制器选择的指标之二。该因子用来标识控制器异常后，负载均衡遭到破坏的程度，或者说它是对负载均衡影响的衡量。影响因子越大，破坏程度越高。理想情况下的影响因子应该为0，即异常后无破坏。实际中，很难保证影响因子一直为0，一般会在0附近波动，但在一定范围内波动可视为正常无破坏[4]。

第一步：计算控制器接管的交换机的slave链接在剩余OpenFlow集群成员中的分布值；

第二步：使用方差计算分布情况。

master/slave控制器的选择原则为负载尽量小，影响因子尽量小。以下是选择规则：（1）选择负载因子最小的控制器；（2）如果存在两台及以上相同最小负载因子的控制器，则选择影响因子最小的控制器；（3）如果最小影响因子的控制器存在多台，随机选择一台控制器。

如图2所示，向网络中加入一个交换机，三台服务器中负载因子最小的为S2和S3，两者的影响因子相同。这里选S3作为新进入交换机的mater控制器，S1为slave控制器。

图2 新加入交换机的master控制器选取策略

调整影响因子，使用slave重分布策略。该策略保障控制器上接管的交换机的slave连接均匀分布在剩余OpenFlow集群成员中，使得影响因子尽量接近理想值。slave重分布的触发条件是影响因子超出一定范围。分布策略的关键在于计算需要重分布的交换机，以及这些交换机的slave链接需要迁移到哪台控制器。迁移原则为高于理想值的slave链接向低于理想值的控制器迁移。

具体的slave重分布规则如下。

第一步：计算出控制器理想情况下和实际情况下的slave分布值；

第二步：找出实际情况下slave分布值低于理想值的控制器集合A，实际情况下，slave分布值高于理想值的控制器集合B；

第三步：计算A集合中每台控制器允许迁过来的交换机数和B集合中每台控制器可以迁移的交换机数；

第四步：从B集合中依次迁移交换机至A中的首位控制器，直到其slave分布值达到理想值；

第五步：执行第四步，直到B为空。

图2为加入新交换机后的网络情形，S3的影响因子由0.25增加到1。假设影响因子允许范围为0～0.3，则S3的影响因子超出范围，应进行slave重分布。因此，做了如图3所示的slave调整[5]。

图3 交换机slave重分布

当新的控制器动态加入集群工作时，如果不进行接入管理，那么将没有交换机会连接至此台控制器；如果在进行接入管理的情况下，没有任何其他策略进行处理，那么此台控制器只能成为所有交换机的slave控制器，没有任何业务；如果有策略进行了负载转移，但是新加入控制器并不能成为任何其他交换机的slave。因此，集群扩展策略旨在解决新加入控制器的接入和rebalance问题，负责集群的动态扩展和进行负载转移，从而始终保证集群的高可扩展性。