前言

无论你是基于 SDN 做物理网络的大二层,还是基于 SDN 做云计算的网络支撑。商用的基于 SDN 产品都有一个不可避免的门槛,就是 SDN controller 的高可用。

交换机已经失去了对网络的控制权,控制转发分离意味着 SDN controller 需要更加稳固。如果 SDNcontroller 出现单点故障,这样整个网络系统都会失去控制,甚至会带来不可逆的灾难。

在我们设计 SDN controller 的部署模式的时候,就需要充分考虑 SDNcontroller 的单点问题。目前也有一种常用的手动去解决 SDNcontroller 的单点问题,就是 HA。

大部分的开源 SDN controller 都支持 HA(如:ODL、Flooldlight),哪怕我们开发设计一个 HA 模式也不是一件代价很大的事情。HA 模式确实可以解决 SDN controller 的单点故障,但是无法解决 SDNcontroller 的首包处理的单点性能瓶颈。这也是我们今天讨论的重点,分析几种 SDN controller 的部署模式。

SDN controller 如何做高可用?

在讲述 SDN controller 的部署模型之前,我们还是先了解一下 SDN controller 的高可用实现原理。有了原理的支撑,对于后续的模型会有更清晰的理解。

其实 OpenFlow(>= 1.2)协议本身就支持对交换机的角色管理。对于交换机,SDN controller 有 Master、Slave 两种角色,并且在同一时间只有一个 Master。

不同的角色有不同的权限,当然这个可以通过 SDN controller 修订。简要说 Master 角色可以接收首包、推送流表、监听交换机的信息(交换机的 ADD、Remove、Port change)等等,而 Slava 角色只能监听交换机的信息。SDN controller 可以通过 OpenFlow 协议要求交换机更换角色,SDN controller 的高可用就是基于这样的规则下实现的。假设其中一个 SDN controller 出现故障,另外的 SDNcontroller 马上要求交换机切换角色即可。

下面来看一个 SDN controller 的主/备设计模型

640

SDN controller HA 模型图

如上图:这就是 SDN controller HA 模型。当 Master controller 出现故障,Slavecontroller 通过心跳线感知,马上要求 vSwitch 切换角色。Slave controller 变成 Master。等故障的 controller 重启,角色变回 Slave 即可。

这个方案有一个明显的缺点,同一时间只有一个 SDNcontroller 在工作,这样整体的网络规模受限于单个 SDNcontroller 的首包处理性能。Slave controller 的存在无法分担首包的压力,这样的工作态度不太好。

下面再来看一个 SDN controller 的主主设计模型

2

SDN controller AA 模型图

如上图:这是 HA 模型的演进版,SDN controller1 既是 vSwitch1、vSwitch2 的 Master,又是 vSwitch3、vSwitch4 的 Slave。SDN controller2 既是 vSwitch3、vSwitch4 的 Master,又是 vSwitch3、vSwitch4 的 Slave。假设 SDN controller1 出现故障,SDNcontroller2 会接管 vSwitch1,vSwitch2。这样的设计有效地分摊了 SDN controller 的首包压力。

AA 模式在技术上其实存在几个难点,第一,SDN controller 之间处理心跳以外,还需要知道各自接管的交换机信息。第二,SDN controller 之间需要实现负载均衡,假设新的交换机接入进来,需要选择最空闲的 SDN controller 接管。第三,自修复功能,假设有交换机脱管了,需要重新接管过来。第四,远程方法问题,应用层不可能知道哪个 Controller 现在负责哪个交换机,这时候就需要 SDNcontroller 实现多控制器之间的远程方法调用。只要解决这些技术难点,SDN controller AA 模型落地不成问题。也可以满足一定规模的网络。

竟然 AA 模型已经做出来的,我们离集群模型还远吗?SDNcontroller cluster 模型最难的地方是多控制器之间的同步问题。分析一下两种最常见的 SDN controller 的同步模型:自主同步模型和统一管理同步模型。

●自主同步模型:

3

SDN controller Cluster 的自主同步模型图

如上图:AA 模型只需要一对一的同步,但是如果 N 多个 Controller 之间,就类似与画星星一样,这样模型的收敛时间会变得很长,而且 SDN controller 之间选举算法也变得非常复杂。我们需要针对这样的模型设计高可靠容错的机制,因为一旦这个模型数据同步出现问题,我们很难排除究竟是哪个 Controller 出现坏数据。

不过只要算法做得足够高效,并且合理规避风险,自同步模型是完全可以满足大规模网络的需求的。SDN controller 的扩张性也有足够高。

●统一管理模型

4

统一管理同步模型(三层模型)

如上图:既然前一个模式下的 SDN controller 之间的同步如此复杂,我们可以单独将同步这个功能抽离出来变成一个角色。这个角色负责多 Controller 之间的同步,而 Controller 就可以专心负责业务功能,不用过多关系同步的问题。这样的设计模型我们统称“三层模型”。也是很多 Cluster 方案在演进过程中的必经之路。

自同步模型的问题都在这个方案上得到很好解决。但是 Sync Manager 却成为了单点,所以 SyncManager 需要做 HA。假设 SDN controller 的数量达到一定的量级之后,SyncManager 也会网络收敛的瓶颈。这样岂不是 SyncManager 需要做 Cluster?四层模型?三层模型在我的观点上已经是极限了。所以 Sync Manager 也不是万灵药。

我们回到云计算,假设 Cluster 模型扩张到最大规模也就是在每个 NC(计算节点)上运行一个 SDN Controller。这时候,其实我们还需不需要做 SDNcontroller 的角色切换呢?

5

SDN controller 分布式模型

如上图:SDN controller 分布式模型最大的特点是 SDNcontroller 只负责管理本地的交换机,SDNcontroller 之间不存在心跳,假设 SDNcontroller1 发生故障了,就重启 SDN controller1 进程。如果 NC 宕机了,就迁移 VM,并在另外的 NC 中构建 controller 相关的业务规则,SDN controller 之间的数据同步是通过分布式数据库完成。

在云计算中,分布式数据库已经开始大量使用,技术相对成熟。所以我们不用担心分布式数据库的可靠性。我们只需要设计好远程方法调用,让应用对分布式无感知。这样的设计 SDN controller 的首包处理能力会随着 NC 的增加而提升。并且如果其中一个实例出现大量的首包(如:DDos 攻击),影响范围也只是 VM 所在的 NC,这样我们可以做出很多有效的处理。这样的模式,我们认为也是未来 SDN 云网络发展的一个重要的分界线。只要在真正意义上,摆脱 SDN controller 的瓶颈,才能将 SDN 推向一个产品化之路。

总结

我们分析了很多 SDN 相关的模型,这些模式都是在实际的项目场景中,发展演进的产物。我们在设计 SDN 网络的过程中,不能只看到 SDN 的长处,而忽略它的短处。SDN 的集中化管理、控制转发分离特性恰恰是我们设计者的痛点。我们既要原汁原味地保留 SDN 的特性的同时还需要坚持走高可用、高扩展产品化之路。所以逻辑值集中,模型上分布才是 SDN 技术的一大精髓。

参考文献:https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.3.pdf