如何定义新一代云SDN？
            早在2015年，品高云正式上线了BingoSDN v3.0版本，并成为品高云操作系统（BingoCloudOS）V6.0的云网络核心组件。至今三年多的时间里，BingoSDN v3.0服务了各行各业不同的应用系统，在包括政府、公安、轨道交通、金融、军工以及教育等行业发挥了其重要作用。联系品高云家的小表妹（ID：pingaoyunzzm）了解更多。
不夸张地说，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的一些思考。
本期大咖  林冬艺

跨地域多中心容灾和新型应用架构对网络响应速度有着很高的要求，我们认为迫切需要把BingoSDN v3.0的集群模型演进成分布式模型，这是BingoSDN v4.0最大的变革：在每一台计算节点上部署一个SDN控制器，本地SDN控制器仅负责控制本地的虚拟交换机，SDN控制器节点之间通过消息队列同步网络位置与VPC配置信息，这样我们就踏上分布式的道路了。
在消息队列的选型上，我们花费了大量的精力。我们希望实现的是一个完全分布式（每个计算节点都是消息队列节点）的消息队列，因此Kafka、Redis等集群模式的消息队列不适合我们这种完全分布式的模型。如果消息队列也成为故障单点，那就不是真正意义上的分布式了。而RabbitMQ的网络分区以及在分布式的场景之下暴露出的非常多的问题，让我深刻地明白为什么OpenStack会在最新版里面把RabbitMQ替换掉。
我们认为，消息队列应该更轻、更稳定、更高效。我们的目标是即使宕机到只剩一台计算节点时它的网络依旧正常，我们不想作出妥协。两个月之后，我们基于ZeroMQ的Socket机制成功重新定义了一套消息队列模型，这套模型非常轻量级，而且很快。有趣的是消息持久化的机制结合了云平台能力，让它变得有点像迅雷P2P机制，所以经常被同事们调侃这是SDN迅雷。那天以后全世界都优雅了很多——SDN控制器和虚拟交换机更近了，它们通过Unix Socket进行通讯，哪怕物理网络中断也不会造成影响，本地通讯和轻负载还令网络响应速度有了质的飞跃。
SDN可视化运维
可视化运维的动态拓扑图

微隔离的功能实现其实并不难，因为我们没有依赖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云网络的发展贡献一份力量，为用户带来更优质的服务与产品使用体验。
相关阅读：

为什么说建设大规模云网络需要SDN？
品高云SDN vs OpenStack云网络
品高云SDN技术评估报告

联系我们
如想了解更多品高云操作系统 V8.0 或索取产品文档，请联系品高云家的客服小表妹！添加她为好友，任何需求一键直达。
"