如何定义新一代云SDN？

早在2015年，品高云正式上线了BingoSDN v3.0版本，并成为品高云操作系统(BingoCloudOS)V6.0的云网络核心组件。至今三年多的时间里，BingoSDN v3.0服务了各行各业不同的应用系统，在包括政府、公安、轨道交通、金融、军工以及教育等行业发挥了其重要作用。

不夸张地说，BingoSDN v3.0拥有着非常出色的性能，它的虚拟网络性能损耗比只占物理服务器的2%，同时可支持创建13亿个VPC，并且经过了权威的第三方测试……(之前我们已经分享了很多关于BingoSDN v3.0的内容，感兴趣的读者可以到通过文末的相关阅读深入了解)。BingoSDN v3.0的成功让我们对SDN云网络的发展之路充满信心，但同时也给BingoSDN v4.0带来更高的要求和更大的挑战。在BingoSDN v4.0的设计之初，我们就在反复地思考：云网络的未来将会怎样发展?未来的挑战是什么?

经过了2年多的打磨，BingoSDN v4.0终于伴随着BingoCloudOS V8.0的迭代正式上线投入使用，并且已经在多个行业用户中稳定运行。设计一个满意的作品真的来之不易，BingoSDN v4.0的每一条血管、每一个毛孔、每一个细胞都是我们亲手打造的，希望通过下文，可以分享我们对新一代SDN的一些思考。

本期大咖 >>

林冬艺

从SDN概念诞生以来一直在关注和研究，任职于BingoCloud SDN云网络团队，主要负责云网络、云网络安全、NFV、高性能云网络等的架构与设计。目前，BingoCloudOS产品的SDN相关功能主要来自林冬艺所在团队 。

一、跨地域多中心SDN控制器容灾问题

随着云计算的不断普及，受物理数据中心的地理条件限制，一云多中心成为云计算发展的必经过程，此时，云网络跨地域容灾则是我们首先要面对的问题。基于此深入思考，我们能否在BingoSDN v4.0中做到整个云的计算节点在只剩下一台服务器的情况下也能正常工作?如果实现这一点，云网络的容灾能力将可以不止提升一个级别。

二、新型应用架构带来的冲击

Docker、K8S、FaaS(Function as a Service)概念的兴起，使得网络的地址空间快速扩张。在过去虚拟机的时代，一台物理服务器能虚拟出30台虚拟机就已经很了不起了，但是现在仅凭一台物理服务器就虚拟出上千个 Docker 也丝毫都不夸张。同时，FaaS的到来对网络的响应速度提出了更高的要求：在高并发情况下，要想一秒内启动上百台Docker，在函数执行完成后瞬间释放，对云网络的弹性响应速度要求极严格，这需要SDN控制器以最快的速度、最短的传输距离和最高效的处理方式完成首包的处理下发流表。

三、黑盒网络问题

我们从BingoSDN v3.0开始就一直坚持使用标准的Openflow协议，并且没有对协议本身做太多的修改，这令我们的运维同事倍感压力。因为以前传统云网络Bridge、VLAN、Route、IPtables四件套走天下的模式，在SDN云网络面前彻底没用了——在SDN云网络中这些都只是一条一条看不懂的流表规则，而且流表规则与VPC组网逻辑没有任何联系。就是这样的黑盒网络，让许多运维同事需要不少时间来适应。当然，我们做了很多运维的培训工作以及运维 工具 来帮助他们，不过我们还是希望BingoSDN v4.0能彻底解决这样的问题，让流表一眼就能看明白。

四、网络隔离不再只是Subnet

Subnet的隔离方式是我们普遍熟悉的，但不知道大家有没有发现它有一个弊端：同一个Subnet地址是连续的。我们在想，能不能实现192.168.1.1-3-5-7-是一个Subnet，而192.168.1.2-4-6-8是一个Subnet，并且它们的VLAN或者VXLAN是相同ID，还能通过策略授权指定地址呢?

这样设计并不是在玩杂技，而是因为我们现实的用户就有很多这样的需求，尤其是政务云用户。在私有云和混合云中经常存在专线复用隔离或者特定安全事件的及时隔离等情况，这种需求往往非常麻烦：只能通过物理交换机的ACL策略完成，还有可能遗留很多隐患。如果在BingoSDN v4.0中可以像安全组一样实现这些，将使得网络隔离的粒度更细，并且更加友好。

▼

最终我们还是把BingoSDN v4.0做出来了，它完美解决了上述的问题和挑战，并且现在已经在包括公安行业、金融行业和传媒行业等用户中上线使用。我们甚至还在设计与开发的过程中做出了很多新鲜的功能，这也算是BingoSDN v4.0的一些小彩蛋了。

五、分布式SDN控制器模型

跨地域多中心容灾和新型应用架构对网络响应速度有着很高的要求，我们认为迫切需要把BingoSDN v3.0的集群模型演进成分布式模型，这是BingoSDN v4.0最大的变革：在每一台计算节点上部署一个SDN控制器，本地SDN控制器仅负责控制本地的虚拟交换机，SDN控制器节点之间通过消息队列同步网络位置与VPC配置信息，这样我们就踏上分布式的道路了。

在消息队列的选型上，我们花费了大量的精力。我们希望实现的是一个完全分布式(每个计算节点都是消息队列节点)的消息队列，因此Kafka、 Redis 等集群模式的消息队列不适合我们这种完全分布式的模型。如果消息队列也成为故障单点，那就不是真正意义上的分布式了。而RabbitMQ的网络分区以及在分布式的场景之下暴露出的非常多的问题，让我深刻地明白为什么OpenStack会在最新版里面把RabbitMQ替换掉。

我们认为，消息队列应该更轻、更稳定、更高效。我们的目标是即使宕机到只剩一台计算节点时它的网络依旧正常，我们不想作出妥协。两个月之后，我们基于ZeroMQ的Socket机制成功重新定义了一套消息队列模型，这套模型非常轻量级，而且很快。有趣的是消息持久化的机制结合了云平台能力，让它变得有点像迅雷P2P机制，所以经常被同事们调侃这是SDN迅雷。那天以后全世界都优雅了很多——SDN控制器和虚拟交换机更近了，它们通过Unix Socket进行通讯，哪怕物理网络中断也不会造成影响，本地通讯和轻负载还令网络响应速度有了质的飞跃。

六、SDN可视化运维

可视化运维的动态拓扑图

其中一条流表的分析视图

我们团队从来不按套路出牌，所以我们打造的可视化运维平台可以看到每一条流表，包括历史流表，也可以了解每条流表推送的原因是什么，比方说，外部网络访问虚拟机、虚拟机发起ARP寻址、安全组没有授权拦截等等。后续我们还能做到：分析这条流表是SDN控制器的哪一个模块、哪一行代码计算出来的流表;还可以看到整个云网络的逻辑拓扑与物理拓扑。我们相信，未来SDN可视化运维会成为BingoSDN产品的一个爆点。

七、微隔离

微隔离的功能实现其实并不难，因为我们没有依赖VLAN或者VXLAN的隔离方式，纯粹的标准Openflow流表使得我们控制网络的粒度可以精细到传输层的端口。只不过没想到的是，当我们刚把测试版本做出来就有了用户需求，所以我们在BingoSDN v3.0上也支持微隔离功能，目前也已经有部分用户在使用了。微隔离也算是BingoSDN v4.0的一个排头兵吧。

八、写在最后

BingoSDN v4.0目前已经正式上线了。总的来说，相对于BingoSDN v3.0版本，新版本由集中式架构转换为控制器下沉至云节点的分布式架构，网络控制处理能力得到了横向扩展。另外，BingoSDN v4.0增加了对微隔离技术的支持，统一子网和安全组可以进行二次隔离;还可通过SDN仲裁机制保证网络可用性，支持跨IDC容灾以及超大规模组网。基于BingoSDN v4.0的可视化运维平台，排障更轻松，有效帮助用户提升运维质量和效率。

问题和挑战从来不会让我们停下脚步，而是激励我们不断向前。未来，我们将继续升级完善BingoSDN，为SDN云网络的发展贡献一份力量，为用户带来更优质的服务与产品使用体验。