技术干货--SDNcontroller高可用之路.docVIP

技术干货?| SDN controller高可用之路 2016-04-15?林冬艺?品高云计算 【编者的话】 “技术干货”系列文章意在分享技术牛人的知识干货，每期主题都不一样哟！期待各位读者在文后发表留言，来一场技术上的交流和思想上的碰撞！本期将由品高云架构师林冬艺带来“SDN controller高可用之路”的分享。 【分享嘉宾】 林冬艺，从SDN概念诞生来一直在关注和研究，目前在BingoCloud SDN云网络团队任职，主要负责云网络、云网络 安全、NFV、高性能云网络的架构与设计。现在BingoCloudOS 产品的SDN相关功能主要来自林冬艺所在团队 。 【分享正文】 前言 无论你是基于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模型落地不成问题。也可以满足一定