纯粹个人理解之SDN (一)

顺着卫峰最近这篇文章的东风,也分享一下我的理解,欢迎讨论:
SDN(Software-Defined Networking,软件定义网络)首次走进大众视野是因为入选《MIT Technology Review》的2009年十大未来技术,斯坦福大学教授Nick McKeown的团队开发了一种OpenFlow技术,帮助网络研究人员打开了一扇门,只要在路由器或交换机上部署OpenFlow,他们就能在普通电脑上用软件编程的方式远程控制路由器,按照自己的意愿重新定义整个网络,称之为软件定义网络SDN。

实际上SDN不仅仅是个网络新概念,更重要的是一个革命性的网络生态系统。Patterson和Hennessy在《计算机组成与设计》一书中这样描述计算机产业:
“This is not a dry and dreary field, where progress is glacial and where new ideas atrophy from neglect. This race to innovate has led to unprecedented progress since the inception of electronic computing in the late 1940s. Had the transportation industry kept pace with the computer industry, for example, today we could travel from New York to London in a second for a penny. Take just a moment to contemplate how such an improvement would change society—living in Tahiti while working in San Francisco, going to Moscow for an evening at the Bolshoi Ballet—and you can appreciate the implications of such a change.”

“这不是一个枯燥沉闷、进展缓慢的领域,也不是新想法会被忽视而遭到扼杀的领域。自二十世纪40年代末电子计算机出现以来,这个行业的创新速度已经导致了空前的进步。假如交通运输业也能始终保持计算机行业的发展速度,今天我们就可以花几美分在大约1秒钟内穿越大洋。想象一下,如果以这种进步来改变我们的社会,你就可以住在Tahiti(位于南太平洋东部),而在旧金山工作,晚上还可以去莫斯科出席芭蕾舞会。你能理解这种发展速度的意义了吧。”

与PC的创新速度相比,网络产业的创新显得停滞不前,每一个新想法需要等待数年才能完成技术标准化,这个新技术的采用需要征得设备厂商和用户的一致认可,对共识的需求加剧了创新的难度。出于商业利益和市场地位的考虑,产业界在位者也不会发自内心地推动网络产业的创新速度。

Nick教授认为支撑PC产业的快速革新有三个原因:

  • PC产业找到了一个简单、通用的硬件底层,比如英特尔的x86指令集,类似于我们说话一样,要表达的意思可以无限可能,但汉字和词语本身是简单的,这些就是我们交流的一个通用底层。
  • PC功能的软件定义方式,这里的软件定义就意味着灵活可编程,这种特点使得应用程序获得爆炸式的增长,几乎满足了今天各种可能的需求,另外基础软件也获得了极大的创新,比如从早期的DOS到现在Windows。
  • PC软件的开源文化,Linux的蓬勃发展已经充分验证开源软件的成功,埃里克-雷蒙德在传奇文章《大教堂与市集》中对比了两种软件开发模式,“大教堂”说的是传统的封闭式开发模式,是一种严格管理下的等级分明的组织形式,从工业革命开始就成为标准的生产方式,而“市集”模式下,每件事情都是自下而上协调安排的。雷蒙德对开源软件的一个著名论断:“Given enough eyeballs,all bugs are shallow”,通俗点说,只要有足够多的人去尝试,就不存在棘手的问题。

假如网络能像PC这样,满足简单通用硬件底层、软件定义功能和开源模式三要素,相信一定能获得更快的创新速度。于是SDN作为下一代网络体系结构诞生了,Nick教授理解的SDN如下所示。

纯粹个人理解之SDN (一)

传统的网络系统架构如左上图所示,其中的网络设备如同1960年代的IBM360,专用的功能软件和操作系统,再加上定制化的硬件,完全是一个封闭的黑盒子。而SDN系统架构如右上图所示,网络的控制部分从封闭盒子中分离出来,控制部分的这种变化,使得网络更加类似今天的PC。整个网络的功能取决于软件实现的控制部分,这样用户(比如Google)就可以在一个逻辑点上控制整个网络,不受设备厂商(比如Cisco)的限制,从而简化网络的设计和运营。SDN的控制部分也分为控制层和应用层,前者称为SDN控制器,类似PC的操作系统,后者包括具体的应用程序。

在封闭盒子中依然保留的是通用硬件底层,也就是网络转发面。与x86指令集一样,通用转发面使得网络设备尽可能的简单通用,不再需要理解、处理和实现大量的网络协议,只需要从SDN控制部分接收操作指令。从图中可以看出,OpenFlow是SDN控制部分与硬件底层的接口协议,实际上OpenFlow好比是SDN的x86指令集(Instruction-Set Architecture,ISA),定义了软件编程网络设备转发面的基本原语,采用flow的概念来识别基于预定义规则匹配的网络流量。SDN控制软件可以静态或动态编程这些规则,定义网络设备的功能,从而控制整个网络,部署新的网络应用和服务。

可以看出,斯坦福的Nick教授从“Refactoring Functionality”的角度来定义SDN。与此同时,伯克利的Scott Shenker教授却从“Redefining Abstractions”的角度来思考SDN。

Scott将网络与其他领域的系统类比,准确的说,网络还不能算是一门学科,以操作系统为例,作为一门学科有三个特点:通常教学操作系统基本原理,容易管理和持续演进,而网络是教授大量通信协议,难于管理且演进速度很慢。这是因为网络最初的设计目标是传输数据包,追求设计的简单性,正是因为这种简单性使得互联网如此成功,但是如今对网络的需求已经不仅仅是传输数据包,还包括TE(流量工程)、QoS和DPI等,使得网络控制面变得越来越复杂,非常难管理。

Don Norman曾经说过:当需要系统更好地工作时,需要管理好复杂性;当需要系统更容易使用时,需要提取简单性。Scott教授认为网络从来没有搞清楚这两者之间的界限,依然在管理复杂性阶段,比如我们眼中的网络专家就是那些掌握所有协议细节的人。那么对于网络来说:怎样才能提取出简单性呢?他以编程为例分析,早期的机器语言没有抽象,必须处理所有底层细节,这时“管理好复杂性”就非常关键,后来的高级编程语言运用了抽象,出现了操作系统、文件系统和面向对象等抽象概念,编程变得非常容易。可见,抽象是提取简单性的关键。

对于网络来说,数据面的网络协议分层已经是一种抽象,但是控制面没有抽象。摆在面前的是两个问题:一是如何找到这些抽象点;二是如何定义控制面的问题,然后分而解之。一般来说,网络控制面要完成三个任务,没有通信保证时的处理,计算每个网络设备的配置信息,按照给定的网络协议工作。

类比编程的抽象,三个任务分别对应三种抽象方式:对分布式状态的抽象,也就是global network view,控制部分不是原来的分布式网络协议,而是采用API的软件程序;对配置过程的抽象,是网络的abstract view,控制程序只描述用户期望的网络行为,不负责在网络设备上的实现;对通用转发模型的抽象,就是OpenFlow了,简单来说是后续要讨论的流表选项,action>。

按照Scott的观点,SDN完成了对网络三个任务的抽象:分布式状态、配置过程和转发模型,使得更加容易实现控制部分,只需要在API上写程序,不需要像原来一样设计新的网络协议,指定对网络的预期目标就好,不需要具体的实现。从SDN的这些抽象来看,假如有一个对应的网络操作系统,需要收集网络单元的拓扑信息,分发控制命令,且必须可扩展和灵活。Scott的思考中有一个很有意思的结论,SDN控制程序的任务就是从网络拓扑中计算出最优化的网络设备配置信息。

对比一下Nick和Scott的观点,我们会发现前者对SDN的阐释更加容易理解,尤其通过与PC的类比,感觉豁然开朗,视为“深入”。后者的阐释比较晦涩,有点形而上的意思,“抽象”本身就很难理解,视为“浅出”。

后来看到Larry Peterson在2013年的演讲《Zen and the Art of Network Architecture》,再次感受到“技术是可以用哲学方式思考的”。我们再来解读一下SDN的本质属性:

首要的当然是“控制与转发的分离”,这里的分离一方面是指decouple,所谓解耦合,在控制与转发之间定义了清晰的开放接口,让控制和转发都可以独立演进,在不断改进的同时还能向后兼容;另一方面这里的decouple又特指物理位置上的远离,这一点与PC的控制/处理分离是不同的,与分布式系统的通信类似,依赖于消息。

其次是“控制面的抽象,转发面的抽象”,前者是指摆脱之前控制面的功能堆砌,解决一个问题多一个协议,多一个协议多一个控制面功能的尴尬,为了使得网络易用,控制面需要抽象,一旦抽象也能持续演进。与PC的类比来看,控制面的抽象就是控制面的软件层次化,一方面NOS负责对转发面的机器级控制,同时给上层应用提供良好的开放接口,另一方面应用在更高抽象级别上建立模型,这样一来,控制面本身也是NOS与Apps的分离,也能独立演进,并且可以借鉴计算机发展以来软件工程积累的经验;后者是指对网络数据包处理行为进行通用化,建立通用转发抽象模型,一个关键是通用转发模型的体系结构,一旦这个定下来,之后就是修修补补和具体实现了。

再次才是“逻辑上的集中控制”,个人认为这一点已经不那么清晰明确了(也可能是自己的局限性,没理解透),尤其再加上Logically这个修饰词,还有Kadoo的local controller的概念,到底(Logically) Centralized Controller在实现层面是怎么操作的?当网络的规模足够庞大时,就需要分布式的控制器集群来作为整个网络的控制面,这是一种层次型的分布式协作系统,还是将巨量的任务分成块来处理?我更愿意把最终的控制面理解成一个逻辑上的a big controller,一边是network global view,另一边是传统软件工程师。

为什么要弄清楚SDN的本质属性?其实之前挺不愿意去讨论“本质属性”的,因为以我的理解深度可能还没到这个程度,更多愿意分析别人目前在各个方向上的成果,开源项目和产业界的产品策略,但后来发现如果要“保持SDN学习/研究的专注性,保持对各个技术方向的敏锐性”,就必须先弄清楚这个。假如什么都是SDN,那么SDN就什么都不是了。

转载自:杨泽卫博客@杨泽卫


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/4573.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于14-12-08
6