翁建毅:SDN实践之路

2016-12-28


谢谢大家!我是来自于大河云联的翁建毅,今天主题是SDN实践之路。我们是一家基于SDN的初创公司,成立一年多,跟大家分享一下这一年多我们在SDN实践上碰到的问题,以及背后的思考。

我之前的工作经历主要在互联网基础架构和云计算方向,所以今天的分享会更多的站在程序员的角度、程序开发的角度去讲。公司创立一年多,主要专注在SDN广域网这个方向,我们主要提供云和数据中心、数据中心和数据中心广域互联的解决方案。目前CanalON率先在国内正式商用,大河云联总部位于杭州,提供杭州、北京、成都、广州的大量研发工作机会。简历投递:zhaopin@fabric4cloud.com

什么是SDN?老调重弹下。传统的网络像是我们创造了一些小人,这些小人精通几种语言,我们把小人连接在一起,他们通过一定的协商会话,手拉手组成了这个网络。SDN是我们把这些小人弱化了,变成一个一个木头人,类似棋子。紧接着我们造了一个机器人去挪动这些棋子,下这盘棋。这幅图左侧的那个人跟我们每次做版本发布的时候,我内心的写照是一样的,我们做了一个机器人,当它开始下棋了,我不知道它会发生什么事情,内心是很忐忑的。SDN的核心是为了造一个会下棋的机器人吗?不完全是。SDN的核心是开放,开放管理接口、开放数据、开放网络管理智能。只有开放才能让我们用更创新的方式去玩这个网。我们几年前开始讲SDN的时候,谈的更多的是Openflow和控制器,今年大家都在讲的是场景、业务编排,那是因为开始应用了。随着应用的推广和深入,也许明年大家就会开始谈到SDN的运维(SDN ops)、数据,再下一步会谈SDN智能。这是发展的必然趋势。

我们在初创的时候,感觉这条路是这样的,我们定了一个目标,做了一个计划,路是直的。一年发展下来,回头去看这条路,很不好走。有很多问题、很多坑。我们的方案应用的主要场景是全球骨干网,解决SDN全球骨干网的管理和调度等问题。当时生态蓬勃发展,控制器也有很多开源项目,能拿到的方案,都是上面是一个Controller,下面直接管理几台SDN交换机。但把这种架构直接应用到一张全球网络的管理,有点怪,很不合适。我们面临的最大问题是延时变大了、稳定性变低了。当时提出了一些设计思想,包括三条铁律,分享其中一条是:控制转发分离,限制控制平面异常时候对转发平面的管理能力,提供一个业务的保护,就像机器人三定律的不可以伤害人。一个中心思想是中央控制、分区自治,这是什么意思,在广域上如果所有事件,都汇报到中央控制器处理,那故障收敛等等都无法得到保障。我们进行了局部自治权的下放。

第一次提出的架构是,我们设计了一个中央的控制器叫CanalCore,边缘控制器当时采用了开源项目O。我们在实际使用这套开源控制器的时候碰到了很多问题,比如Barrier Timeout机制不成效,Node连接不稳定时候产生的UP/Down的事件乱序,统计线程异常停止,DataStore的数据不一致等。紧接着在第二版架构中,我们实现了自己的边缘控制器CanalEdge。同时增加了业务编排层SmartControl,编排层对外提供了一层完整的API,CanalAPI。我们基于这套API实现了一个Portal管理界面,也跟一些云做了集成对接的尝试。

完成了第二版架构的实现后,就像你造了一艘船,只有真正放到海上才知道会碰到什么问题。就像这张图一样,本来风平浪静的航行,也许突然就会碰到一个深渊。列举几个问题:
第一,网络设备跟控制器的连接断开了,它是脱网还是宕机了?如果只是脱网了,控制器不应该去干扰它的,因为数据的正常转发还在走。但如果宕机了就马上要干预。
第二,带内还是带外管理?一张广域的SDN网的节点我们怎么样去管理它?如果是做带外网,相当于又要建一张IP网。
还有一个是控制层和转发层的流表一致性。如果控制转发发生了不匹配,肯定是要会出致命问题的。怎样保证控制层转发层的流表一致性,包括控制信令可达、时序等等一系列的问题。
我们踩过的坑很多,这里面有很多很麻烦的问题。

接下来我讲一下部署。SDN的方案,我们去网上搜一下,你会看到SDN的架构都是非常复杂的,有各种层次,很丰富的组成。但是怎么部署,它是一个软件还是一套平台?这个东西不知道大家有没有概念,当这样的东西出现在你面前的时候,你怎么样去落地它?这里面我们也碰到了很多很有趣的事情。一开始的时候,是以一个平台化的视角要去做这个东西的,觉得它是一个网络即服务的平台,就应该按平台的思路去设计。做着做着,客户说,给你一台服务器,你把你的东西装上去,这就很尴尬了,我们做的集群化的东西至少是三台起,客户说我给你一台服务器,你自己玩吧。我们又改,改成了类似软件交付的模式,就像今天很多商业化的控制器卖软件的形式一样。紧接着他给了两台服务器就问你能不能做高可用?今天我们在高可用上也做了很多努力,包括做了选举的改善、防脑裂、脏数据保护等功能。为什么一开始就给了一两台服务器?因为他可能只有三台交换机啊。

那什么时候会出现集群?这个平台不可避免最终要提供给大众去使用,它是需要平台化的。什么时候去做平台化。我们现在的策略是在边缘的这一侧会软硬件一体化的提供控制器,在中央控制器、编排以及往上业务可以提供平台化的解决方案。这也符合现在客户的实际情况,体量都是由小到大,我们可以很灵活的适配和部署。面向两种不同的场景,在南向的管理上,我们使用软硬件一体的控制器,北向面向于广大受众,他是一个平台,会以集群化、互联网化的方式去解决。如果两个乱搭,会很奇怪。比如今天你买了一个控制器的软件装在一台服务器上,然后宣称我要开放给整个互联网的用户去使用,这是不现实的。

接下来讲Ops,为什么叫SDN Ops?网络运维的代名词是CLI和流量图,软件运维的代名词是什么?大家看看这张图,他是由一整套工具链组成的,这是两个完全不同的领域。研发内部,会讲持续集成,那么最近大热的Devops,是平台化软件从研发往运维延伸,是在讲持续交付。那么SDN可能还要再往前一步,服务交付。从持续交付到服务交付,这其实是有很多挑战性的工作的。你提供给最终用户的是他可以点点鼠标就可以购买的服务。所以SDN Ops会包含这么一整个链条,最难的地方是在于人、在于团队,怎么样在一个有限的团队里,进行跨界体系的融合,是比较难的一个地方。

最后讲一下数据,我们做了很多很切实的工作,从左到右是数据从产生、搜集、处理、存储到最终的消费,这是我们的整个DataFlow。这里面会包含流量、流速、日志、事件、拓扑快照等等数据。我们在存储层设计了一层统一数据源,只要是在SDN网产生的数据都可以被拿来消费。在应用消费侧,可以借助我们提供的CanalData框架,简化数据的应用。我们在上面开展了很多数据的分析、统计工作。除了这些数据图表。最右侧那个图里是一段代码,我们在线玩数据的一个小平台,我们的数据工程师可以在这样一个平台上写一些简单的代码,验证他的想法,去做一些数据分析。一旦比较成形之后,我们就会把它迭代到现在的产品中去。

最终我们形成了这样一套结构,由SDN业务、运维支撑和数据组成,初步完成了三大组件的布局。当然,还有很长的路要走。运维支撑、数据,是SDN核心业务外,需要大家一起去努力的。

随着SDN应用的深入,网络将变得不可思议的复杂,人终有一天将管理不过来,这一时刻即将来临。人工的网络控制会被机器决策取代,由数据驱动。打个比方比如速记员这份工作,最终打败他的不是更快的速记员,而是机器,是机器学习,像最近开的一些会,它的速记是由机器直译出来的,准确率已经超过人了。所有这些前提是网络的开放,开放管理、开放数据、开放智能,我们才有这么大的想象空间。

最后,感谢SDN生态,因为开放给了我们这次创新的机会,也感谢风雨同舟的伙伴们,让我们一起为梦想坚持。谢谢大家!

(转自SDNLab, http://www.sdnlab.com/18215.html)

扫描二维码分享到微信