软件定义网络:昨天今天明天
软件定义网络:昨天今天明天
- 昨天:传统网络的发展。
- 今天:传统网络的缺陷;先行者ForCES,后来者SDN;后来者为什么能取代先行者?
- 明天:软件定义网络取代以TCP/IP为核心的传统网络?
昨天:故事从很久很久以前讲起
在第一台巨型计算机到第一台路由器的发明,再到今天的大型互联网络的崛起,网络大爆炸时代,这中间的过程凝聚了前人的思想精华和无数次辛勤的努力,最终形成了目前由TCP/IP四层和以太网所主导的互联网络。其中,网络设备的发展是这篇博文所要关注的地方:由最初的端到端PC连接无法实现长距离通信,到中继器保障长距离PC通信;由中继器接口不足,到集线器拓展接口;由集线器无法分割冲突域,到网桥交换机冲突域的划分;由二层交换机无法选择最佳路径,到三层路由器实现动静态路由选择,最终来到了互联网时代。应用需求推动了技术发展,技术为应用发展提供支持,这两句话贯穿整个传统网络的发展历程。
也就是说,传统网络的发展,是一个添砖加瓦式:不断出现问题不断解决问题 的发展历程。现如今的我们深受互联网所带来的好处:通过智能手机,笔记本电脑等设备,无时无刻不在影响着我们的生活;这些都需要归功于前人的思索和尝试以及为解决问题所打上的补丁。
今天:网络架构缺陷无法满足业务需求
现如今,进入4G时代,网络流量暴增,对网络的需求以指数增长的形式上升,于是对原有技术的变革成为了各大IT公司的主要竞争力;数据中心,云计算,虚拟化等新兴技术逐渐进入人们的视野。与此同时,传统网络架构的问题逐渐浮现:可拓展性问题令人头疼,网络拥塞令人焦虑,中间网络设备配置困难,互联网公司链路开销巨大等等;传统网络到了一个瓶颈:现有的架构无法满足越来越巨大的需求。
问题一:传统网络中间设备厂商多,配置难。
由于传统网络的中间设备 如交换机 路由器等 的生产厂商繁多,比如思科 华为,造成了中间设备的种类多,而各大网络设备生产厂商用于配置中间网络设备的命令和软件各不相同,这就导致了第一个大问题:人们想要对不同种类的网络设备进行统一配置,是一件十分的困难的事情。
2014年3月份的ONS大会,与会者展示了一个统计:在一个具有十六个机架的中小型数据中心上,在所有的网络设备上配置协议需要人工输入八万条命令;而且由于命令的不统一,经常出现为达到同一个目的而使用不同命令的情况。
问题二:流量可视化难,控制网络拥塞难。
现如今,网络直播,QQ微信,百度云阿里云等等网络需求,导致了网络流量暴增,每时每刻在网络上都有大量的流量在跑。就像我们的交通一样,车一多,拥塞自然无法避免。
网络拥塞是网络中的一个永恒的问题。在TCP协议中,我们有为了避免网络拥塞而应用的种种协议:慢启动,拥塞避免,滑动窗口机制,防止小包等等;但在网络需求量如此巨大,网络流量指数级暴增的今天,如何解决网络拥塞,提高网络传输效率仍然是一个难以解决的问题。
控制拥塞最好的方法就是避免拥塞的出现。于是我们提出了流量可视化的概念,倘若我们能够实时监视到网络的状态,比如这条链路是否拥塞是否不堪重负,带宽利用率是否达到要求,我们就可以针对当前的网络做出适当的策略选择,从而应用到具体网络,最后避免网络拥塞的发生。
但是很遗憾,现在的控制转发平面耦合的网络架构决定了实现流量可视化的技术是难以实现的,底层的网络设备没有办法做到实时反馈,我们用户也没有办法做到实时监控。用户真正得知网络出现拥塞往往为时已晚:丢失数据报。
问题三:中间网络路由汇聚慢,分布式架构显瓶颈
当中间网络的某一条链路出现故障,并且在连接这条链路的路由器检测到这一故障之后,传统路由协议(比如RIP)所采用的方法是,和邻居路由器交换路由表,每台路由器根据链路更新的信息重新进行最优路径的计算。
但是,现在网络的数量剧增,大型互联网络的出现很大程度上放大了 交换路由更新信息方法的缺陷:路由汇聚过于缓慢。
想象这样的一种情况,在一个非常大的互联网络的左边缘,发生了链路故障,传统的解决方法是路由器交换路由表来更新路由信息,但是这样的“接力棒式的转递”导致右边缘的路由器得到这一消息的时间长,更新速度相比左边缘明显更加缓慢。这样的话是十分不利的:如果由于汇聚缓慢造成了一定的时延,右边缘的路由器仍然向这条故障的链路或者网络设备大量发包,就会造成大量丢包。
问题四:无法按需,不可编程
当我们用户费了九牛二虎之力得到了网络的实时信息(可以理解为通过某种软件,或者通过超能力吧),根据这些信息做出了策略的调整,想要应用到实际的网络中时…发现我们并没有好的办法,直接对实际网络进行部署;我们必须通过修改网络设备的配置,网络设备再对网络进行一些控制。暂且不谈修改各种网络设备的配置是否麻烦,如果修改网络设备的配置无法满足我们的需求,或者说不支持应用我们的策略的话,我们就只能向网络厂商述说我们的苦衷,并让他们对网络设备配置进行修改,从而能够支持我们的策略。
但是,向厂商申请和厂商做出修改本身就是一件非常耗时的事情,如果策略具有即时性,那么当厂商终于修改完毕,将设备给我们的时候,策略已经不再适用了。
简单的来说,就是无法按需:我们的策略(需求)没有办法即时的应用到网络中去。
对于程序员来说,最亲切方便的应用策略方法或者说控制方法,就是编程;但是同样令人扼腕的是,目前的网络架构,并不支持编程化,或者说由软件实现完全的控制。
这四个问题,是目前传统网络架构中问题的四个代表,反映了当前传统网络架构的主要问题:实际网络信息反馈到用户难,用户指定策略下发到实际网络难。
总而言之,传统网络的设计理念(分布式,不可按需,流量控制,不可统一配置)以及 控制转发平面耦合的架构 与目前人们迫切的需求 格格不入!我们需要更换我们固定的思维,来重新思考如何设计网络架构,以满足当代人们的需求。
于是,控制和转发平面分离,这一SDN的核心思想,逐渐进入人们的视野。下面将介绍这个理念的先行实例ForCES是如何解决上述这些问题的。
先行者 ForCES
2004年,Intel,Nokia公司等单位的科研和技术人员,一起提出了一个RFC 3746 Forwarding and Control Element Separation (ForCES) Framework,旨在解决目前网络架构难以解决的问题。2010年,浙江工商大学,IBM,Intel等单位的科研和技术人员又提出了一个新的RFC,在这个RFC里面他们制定了一个新的类似于OpenFlow的协议标准,目前这个RFC已经成为了正式的标准。

(图一:ForCES体系结构)
ForCES 的核心理念是,在传统的中间网络设备上采用分层的思想:在一台网络设备上将控制层从转发层抽象出来,并安装统一的软件,用于控制和管理层面;用户如果有需要,可以键入命令,或者通过图形界面按键操作,将选择的策略配置到具体的网络设备中去;而网络设备也可以即时的向控制层反馈转发层的端口以及链路状态。
ForCES 的这种类似 控制与转发平面分离 的思想,很好的解决了传统网络架构的问题:首先在所有的中间网络设备上安装统一的操作系统,以及配套统一的软件,使得命令统一,虽说一个个的进行命令操作仍然很麻烦,但是可以通过一些其他的手段来优化一个个配置的时间(比如远程控制等);其次,网络可以向用户及时的反馈信息,转发层次通过向处于同一设备的控制层反馈网络实时信息,控制层再将这些信息反馈到用户或者是远程控制系统;最后,用户按需制定策略并下发策略,不再需要通过人工修改配置或者和厂商沟通,交由软件进行实现即可。
这样看来,好像ForCES也不错呀?我们再来看SDN。
后来者 SDN
相比它的先辈ForCES,SDN也一样,采用了 控制和转发平面分离 的思想,来看这张图:
(图二:SDN网络架构)
和ForCES不一样的地方在于,SDN将所有的交换机路由器等中间网络设备的控制层提取出来,组成控制层;最底下的网络设备不参与路径选择和策略制订,它们所做的,仅仅只是根据控制器下发的流表转发数据而已。
有人就会问 既然ForCES和SDN差不多,何必使用SDN这种推倒重来的架构,用基于传统网络架构的ForCES不就好了?
是啊,SDN目前还在起步阶段:控制层控制器交互所使用的东西向协议尚不明确,北向接口API尚未标准化,它的大部分还是处于一个尚未成熟的阶段。完善它看起来似乎还是遥遥无期。而 ForCES需要在传统网络设备上略做修改,以及开发一个成熟的能够支持所有设备的操作系统和其配套的软件,虽说这个软件的开发周期和维护看上去也是一块硬骨头,但是比起SDN的遥遥无期,似乎更容易让大家接收。
但是,就现在而言,各大互联网公司,各大厂商选择了SDN,都来SDN这里掺和;而ForCES已经接近称为历史,无人问津。因此,在SDN中肯定有ForCES以及其它网络结构改革方案没有的,真正触碰到各大互联网公司,各大厂商,也就是广大用户的敏感点的地方。
后来者为什么能取代先行者?
(图三:ForCES网络架构 和 SDN网络架构 的对比,其中左半部分为ForCES网络架构,右半部分为SDN网络架构)
由上图,我们可以很清楚的看到,ForCES网络架构 和 SDN网络架构最大的不同:在ForCES中,每台中间设备都抽象出自己独有的“大脑”(控制层),每台设备都有独一无二的大脑;而SDN则是将所有的底层交换机的“大脑”集中在一起,形成控制层,它的底层设备交换机没有“大脑”。这样对比的话,很容易看到ForCES架构中最大的缺点:底层设备协调性,灵活性不足。由于ForCES的底层网络设备是各自独立控制的,因此不同底层网络设备之间协调性是比较差的;而SDN将所有的底层设备的控制层面全部抽象到了一层,相当于把这些原来分散的控制层面集中了起来。
ForCES的这种分布式控制系统的缺陷,就是底层网络设备之间的可协调性。在分布式系统理论中,著名的CAP理论提到:在容忍网络分区(网络无法连接)的前提下,要么牺牲数据的一致性(同步性);要么牺牲数据的可用性。因此,在大型的ForCES分布式控制网络架构的情况下,随时都有可能出现网络分区,或者其他的不利因素,保证底层网络设备的协调性将是一件十分困难的事情。
做一个不是很恰当的比喻,我们将底层网络设备(比如交换机)看做是人类的四肢,那么ForCES的设计理念是,这四肢都有自己独立的大脑,但是这些大脑都能听得懂主大脑发送过来的信息;SDN的设计理念是,四肢没有大脑,所有的肢体全部由人的主大脑进行控制。当主大脑下发“走路”命令的时候,SDN理念下的肢体能够协调的运作:当我左脚迈出去并落地之后,我的右脚及时抬起并向前迈;而ForCES理念下的四肢就没有那么灵活了:有可能当我左脚迈出去但是还没有落地的情况下,我右脚就抬起来了,四肢之间的协调性并不好。
未来需求及应用的发展趋势,越来越需要原来分散的底层网络设备联合起来,满足一些要求协调性高的应用需求,或者做一些同步的变换。
未来的IT行业会对网络提出什么样的要求,以及发展出什么具体的应用,我们不得而知;但是确定的是,未来IT行业和应用需求是会不断发展的,应用对底层网络设备的协调性,策略下发及实施的实时性,数据处理的速率要求一定是更高的。
因此,SDN网络优于其他基于传统网络的革新方案的原因,不是因为解决了传统网络的缺陷,而是由它的底层网络设备可协调,通过软件控制网络来服务于应用的理念,提供了一种对网络未来的合理想象:服务于应用需求的,由软件所定义,所控制,所主导的高度协调的智能网络。在SDN网络中,软件所提供的可编程性,控制平面和转发平面分离,以及底层网络设备的集中式控制等,都给理想化的智能网络未来提供了可能,而这恰恰就是基于传统网络的革新方案所无法媲美的,这就是软件定义网络的深刻寓意。
而基于传统网络的革新方案,都是针对目前网络问题而研究的;虽然解决了问题,但是它的前景是十分黯淡的。这些方案就像之前所做的那样,出现问题,开发一个新的协议或者添加新的网络设备来解决它,不断的在原有已经十分臃肿的网络上添砖加瓦;仿佛陷入了一个死循环:出现问题,添加东西来解决,出现问题··· 这对于网络的未来无疑是一种灾难性的做法,不久网络就会庞大到难以想象,接近奔溃的边缘,到那时不要说满足日益见长的应用需求,连正常的运作都会难以维系;这就真正的为时以晚了。