前言
无论你是基于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模型
SDN controller HA模型图
如上图：这就是SDN controller HA模型。当Master controller出现故障，Slavecontroller通过心跳线感知，马上要求vSwitch切换角色。Slave controller变成Master。等故障的controller重启，角色变回Slave即可。
这个方案有一个明显的缺点，同一时间只有一个SDNcontroller在工作，这样整体的网络规模受限于单个SDNcontroller的首包处理性能。Slave controller的存在无法分担首包的压力，这样的工作态度不太好。
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的同步模型。
自同步模型：
SDN controller Cluster模型
如上图：AA模型只需要一对一的同步，但是如果N多个Controller之间，就类似与画星星一样，这样模型的收敛时间会变得很长，而且SDN controller之间选举算法也变得非常复杂。我们需要针对这样的模型设计高可靠容错的机制，因为一旦这个模型数据同步出现问题，我们很难排除究竟是哪个Controller出现坏数据。不过只要算法做得足够高效，并且合理规避风险，自同步模型是完全可以满足大规模网络的需求的。SDN controller的扩张性也有足够高。
统一管理模型（三层模型）
如上图：既然SDN controller之间的同步如此复杂，我们可以单独将同步这个功能抽离出来变成一个角色。这个角色负责多Controller之间的同步，而Controller就可以专心负责业务功能，不用过多关系同步的问题。这样的设计模型我们统称“三层模型”。也是很多Cluster方案在演进过程中的必经之路。这样的模型在HP的一个项目中，有见过。自同步模型的问题都在这个方案上得到很好解决。但是Sync Manager却成为了单点，所以SyncManager需要做HA。假设SDN controller的数量达到一定的量级之后，SyncManager也会网络收敛的瓶颈。这样岂不是SyncManager需要做Cluster？四层模型？三层模型在我的观点上已经是极限了。所以Sync Manager也不是万灵药。
我们回到云计算，假设Cluster模型扩张到最大规模也就是在每个NC（计算节点）上运行一个SDN Controller。这时候，其实我们还需不需要做SDNcontroller的角色切换呢？
SDN controller分布式模型
如上图：SDN controller分布式模型最大的特点是SDNcontroller只负责管理本地的交换机，SDNcontroller之间不存在心跳，假设SDNcontroller1发生故障了，就重启SDN controller1进程。如果NC宕机了，就迁移VM。这样也是一个高可用方案。SDN controller之间的数据同步是通过分布式数据库完成。在云计算中，大量使用的分布式数据库，技术相对成熟。所以我们不用但是分布式数据库的可靠性。我们只需要设计好远程方法调用，让应用对分布式无感知。这样的设计SDN controller的首包处理能力会随着NC的增加而提升。并且如果其中一个实例出现大量的首包（如：DDos攻击），影响范围也只是VM所在的NC，这样我们可以做出很多有效的处理。这样的模式，我认为是未来SDN云网络发展的一个重要的分界线。只要在真正意义上，摆脱SDN controller的瓶颈，才能将SDN推向一个产品化之路。
总结
我们分析了很多SDN相关的模型，这样模式都是在实际的项目场景中，发展演进的产物。我们在设计SDN网络的过程中，不能只看到SDN的长处，而忽略它的短处。SDN的集中化管理、控制转发分离特性恰恰是我们设计者的痛点。我们既要原汁原味地保留SDN的特性的同时还需要坚持走高可用、高扩展产品化之路。所以逻辑值集中，模型上分布才是SDN技术的一大精髓。
本文转自d1net（转载）
