文章一开头,作者就浇了一大盆冷水,分析了SDN的尴尬处境,以及实现SDN所面临的困难.SDN是模式迁移的大动作,不是一朝一夕能够完成的,首先是SDN能否被接受,其次是实施过程中的问题怎样解决.随后,作者又给了个定心丸吃,表示SDN是势在必行的,并给出了一些中肯的意见
文章一开头，作者就浇了一大盆冷水，分析了SDN的尴尬处境，以及实现SDN所面临的困难。SDN是模式迁移的大动作，不是一朝一夕能够完成的，首先是SDN能否被接受，其次是实施过程中的问题怎样解决。随后，作者又给了个定心丸吃，表示SDN是势在必行的，并给出了一些中肯的意见，提醒大家不要迷信SDN。
现如今，在网络界炒作的最热闹的概念莫过于软件定义网络(SDN, Software Defined Networking)。一时间，SDN风生水起，凡是提到网络，言必称SDN。仿佛有了SDN，从此网络就要走上一条铺满鲜花的康庄大道了。但热闹了一阵子之后，SDN的应用却是雷声大，雨点小，只听楼梯响，不见人下来，真正端得上台面的只有可怜兮兮的Google一个案例，用来连接Google各个数据中心的B4 WAN网络，勉强算得上差强人意，却也看不出有什么普遍推广的意义。其他的所谓杀手级的应用(Killer Application)不过是存在于宣传家的噱头和运行在研究者实验室的Mininet上。也许如下几点可以解释其中的原因。
首先，SDN是模式迁移(Paradigm Shift)的大动作。SDN所谋者大，不是原有技术之上的添砖加瓦，也不是原有系统框架的修缮补阙。SDN时代的到来，网络界将面临数十年未有之变局。正如Thomas S. Kuhn的著作The Structure of Scientific Revolutions中所描述的科学革命的模式迁移一样，SDN是网络技术领域的结构性的革命性的模式迁移。这种模式迁移都不是一朝一夕能够完成的。科学发展的历史上，从Ptolemaic的地心说到Copernicus的日心说(Copernican Revolution)，从Aristotle的力学到Newton的力学，从Newton的万有引力到Einstein的相对论，以及原子理论的发现，无不经过了长期的痛苦的挣扎，才得以从旧的理论过渡到新的理论。虽然SDN不能和上面列举的科学革命相提并论，但是SDN绝不是传统L2/L3网络的development-by-accumulation式的量变过程。众所周知，SDN最基本的原则包括隔离控制平面(Control Plane)和数据平面(Data Plane)，管理集中化(Management Centralization)，和可编程(Programmable)。这就决定了SDN是另起炉灶从而重建传统网络的运行模式、管理模式和开发模式的质变跳跃。与此同时，SDN的出现，也改变了网络提供商和客户之间的关系。交换芯片(ASIC)商业化的实现，网络客户有机会实施白盒子(White Box)策略。在建设网络设施时，能够以BYOD( Bring Your Own Device )和BYOA( Bring Your Own Application )的方式采购组合不同供应商的软硬件产品，不仅节约了成本，也大大减少了网络客户与单一供应商绑定的风险。传统网络供应商的收益也因此受到影响，利益所关，他们会或多或少抵制这一转变的进程。所有这一切都决定了SDN不可能一蹴而就。
其次，SDN的实现面临诸多挑战。控制平面和数据平面的分离使得Controller要管理成千上万台交换机，并且还要满足网络规模动态的(Dynamic)可伸缩的需求。实现这种可伸缩性(Scalibility)，对于大规模的网络，当然不是单独的一个Controller所能承受之重，需要采取分而治之(divide and conquer)的策略，即将网络分成不同的部分，由多个Controller分别管理。这又会引起其他问题，为了向上层应用提供统一的网络视图(Network View)和北向开发接口(North-bound API)，使得上层应用的开发者可以只面对单一的逻辑的基于Controller的应用开发平台，Controller之间需要做复杂的数据同步，这些数据包括网络拓扑变更、链路端口状态、流量(Traffic)统计信息等等。Controller也可能因故障退出或宕机，所以，还必须有相应的机制保证系统的可靠性(Reliability)，比如采用Master/Slave的架构，这无疑又增加了数据同步的复杂性。实践证明，越是复杂的系统越是难以部署和维护。必须使用有效的技术，来解决可伸缩性和可靠性的问题，从而得到高可用性(Availability)的SDN解决方案。声势浩大的Open Source项目OpenDaylight迄今也才发布一个开发者版本，也许可以作为SDN具有高难度和高挑战性的一个明证。SDN的实现还要克服硬件的限制，目前，市场上真正的SDN的芯片还不多见。比如说所谓的OpenFlow交换机，大都是采用变通的方法来实现的。因为昂贵的TCAM表的大小非常有限，就只能拿交换机L2的转发表(FIB)和L3的路由表(RIB)来凑数。这样一来，Controller给交换机下发的Flow Entry必须要和转发表的表项或路由表的表项相一致，因此Flow Entry的匹配条件(match)和动作(action)就要受限于MAC表和路由表的表达能力。开发者会不经意间发现，表面上做的东西看起来是高大上的OpenFlow和SDN，到头来玩的还是原来的L2的转发(Forwarding)和L3的路由(routing)。就好像梦中以为自己是在开飞机了，醒来一看屁股底下坐的还是原来的拖拉机啊。因此，Google的B4网络就只好使用自己定制开发的OpenFlow交换机。另外，SDN还要实现自身网络与外部L2/L3网络的路由转换，以达到SDN网络和L2/L3网络的互联互通的目的。
最后，网络向SDN的变迁(Migration)尚没有可行的廉价的解决之道。尽管SDN的优越性和美好前景被传说的活灵活现。如利用SDN可以大规模减少客户的CAPEX(Capital Expenditure)和OPEX(Operating Expense)，提高设备的投资回报率(Return on Investment)，如2015年SDN的市场规模将达到几十亿美元。但对客户而言，包括运营商、云计算数据中心(Data Center)，以及企业，都不会傻到立马将自己网络基础设施切换到SDN模式，因为对自身业务的影响和风险没有办法准确评估。另外，从上面对SDN的技术难度的分析可以看出，传统网络到SDN的转换也绝非易事。在传统网络和SDN之间并不存在一个双向开关，只要简单地把这个开关置为SDN模式就万事大吉了，必要的时候，还可以再切换回来。因此，大多数客户对SDN还是会选择谨慎的态度，或持续观望，或以小的项目进行探索性的尝试。
从另一方面讲，网络的确到了不得不变革的时候了，这基本上是一个业界的共识。一方面，传统网络的控制平面分布在五花八门的不同提供商的设备上，通过各种网络协议将这些设备连接在一起，需要一个设备一个设备的人工配制。因此，这是一个静态配制的复杂的脆弱的系统，部署一个网络系统颇费时日，往往需要几天甚至几个星期的时间。难得的是，网络的这一模式已经保持了20多年基本没有变化了。另一方面，运行在网络平台上的应用伴随着互联网革命的兴起却发生了深刻的变化。尤其是云计算和移动计算的到来，要求应用或服务的部署要以妙级的速度完成，而不是几天或几个星期。而且这些服务或应用要求很高的弹性(Resiliency)和灵活性(Flexibility)。如臭名昭著的火车票网上订票系统12036就是没有解决好服务的弹性和灵活性的问题，在节假日的售票高峰期，系统基本处于瘫痪状态。大规模多租户云计算数据中心(Multi-tenant Cloud Computing Data Center)要求隔离不同租户的应用，而动态变化的应用之间要建立成千上万的网络连接。比如，一般地，一个Web/Cloud Application分为表示层(Presentation Tier)、业务逻辑层(Business Tier)和数据层(Data Storage Tier)。这样的层次结构就是为了满足应用的灵活性和安全性。在三层之间必须建立多条网络连接以进行数据交换。网络连接的建立需要一个设备一个设备的人工配置。随着应用数量的增长，当前的静态的网络模型承受的压力也会越来越大。互联网应用和服务的这种变化和网络模型的不变是一个尖锐的矛盾，传统的网路模型面对互联网的应用和服务需求就好像电影《让子弹飞》中用马匹来拖动沉重火车头一样力不从心。虽然，电影里面看起来几匹马拉着火车头在铁轨上欢快地奔驰如飞，但电影毕竟是电影。解决这个矛盾的技术是虚拟化(Virtualization)，计算资源和存储资源的虚拟化已经基本完成，因此，普遍认为，网络业已成为虚拟化和云计算的最后一块绊脚石，而SDN是解决网络虚拟化的有效手段。总而言之，对于SDN的起步公司(Start-up)而言，SDN是大势所趋，一定会发生，所以要有信心；SDN是一个过程，不会马上发生，所以要有耐心。我笃信，一定会有致力于SDN的起步公司在网络模式迁移的大潮中取得巨大的成功，甚至会替代当前网络产业界如Cisco那样的大鳄。但究竟鹿死谁手呢？我没有足够的数据来给出可信的分析和预测。以下的几点看法是我的一些小见识。
不能迷信SDN。SDN不是像一些中医神棍胡吹的包治百病的“神药”，人世间，这样的“神药”从来就没有存在过。SDN是新的模式(Paradigm)，所以很适合用来空谈吹牛。但SDN的确给出了特有的方法论和相应的工具或模型，但从来不是具体的解决方案。所以，起步公司要根据用户的具体需求，给出自己的SDN解决方案，开发出相应的产品，来帮助用户解决问题，在给用户带来实实在在的价值的同时，实现自己的价值。在开始一个SDN项目之前，要清楚的知道期望解决的问题是什么，达到的目标是什么，得到的好处是什么。B4之所以成功，就是因为问题和目标非常明确，那就是通过基于SDN的流量工程(Traffic Engineering)提高WAN的物理连接的利用率。
不能为SDN而SDN。如上文所述，在网络模式迁移的浪潮中，我们要理解这一根本变化对网络世界的意义和影响。抱残守缺，脚步向前走，眼睛往后看，都不会有所作为。这就意味着我们不能再固守原有的L2/L3的网络技术了，不能将SDN视为对现有网络模型的重新实现。若认识水平局限于此，就将错过SDN的大风景。比如，如果把下面的例子看作SDN的全部就大错特错了：基于OpenFlow/Open Virtual Switch的技术框架，做一个Web界面，通过简单的Controller，以OVSDB方式配置OpenFlow的交换机(如创建Bridge，将端口加入Bridge)，并向Controller控制的交换机下发OpenFlow Entries，更新交换机L2表和L3表，最终定义L2转发的行为和L3路由的行为。这不过是用Web GUI替代原来的ssh/telnet，非但没有简化配置，甚至配置变得更为复杂。因此，只是为SDN而SDN，不过是新瓶装老酒，没有任何价值。其实，对于开发者而言，相对过去的分布式的控制平面，SDN带来的最大的好处当然是可编程，而可编程的基础和前提是可以通过Controller提供的应用开发平台的API获取全局的网络视图(View)，包括网络拓扑(Network Topology)、网络设备和连接的状态以及流量统计数据(Counters)。有了这些，就能以直接的方式比较快的开发出更具智能的网络应用，如流量工程(Traffic Engineering)、负载均衡(Workload Balance)、防火墙等。另外，还有一些更为具体的应用，比如两个运营商的网络之间只允许交换特定服务(如Web Application)的数据流(Application-Specific peering)，将特定的数据流重定向到事先配置好的目的网络(Redirection Through Middleboxes)。可以说，网络视图之于SDN，就如同地图和交通数据之于汽车导航系统一样必不可少。汽车导航系统当然要根据地图和交通状况来为用户算出合理的路线(Route)，若把每辆使用导航系统的车看作是网络中的数据包(Frame/Package)，那么，这看起来不就是流量工程的概念吗？
利用开源(Open Source)的力量。与SDN相关的开源的项目着实不少，Controller的开源项目就有NOX/POX、NodeFlow、Floodlight、OpenDaylight、Ryu、ovs-controller等。L3路由系统有Xorp、Quaqqa和EXaBGP等。另外，还有一些特殊的应用，如Google的RouteFlow提供了基于OpenFlow的虚拟IP路由服务(virtualized IP routing services)，很有想象力，而Flowvisor可作为在OpenFlow交换机和Controller之间的代理服务，实现虚拟化的网络切片(Slice)。Frenetic竟给出了一种网络编程语言，支持以模块化的方式开发网络应用，很值得关注。文献[2]使用Frenetic和BGPExa实现了SDX(Software Defined Internet Exchange)的实验系统。而Google的B4也用到了Quagga和Onix。有些SDN开源项目对于上文提的SDN的技术挑战给出了解决方案，因此，利用开源，可以使资源非常有限的起步公司更加专注在开发网络应用来满足用户需求上。Brocade基于OpenDaylight的Helium版本，发布了自己商业化的Vyatta Controller，这是一个很值得SDN的起步公司关注的事件。开源的精神是开放、共享和交流，起步公司在利用开源资源的同时，别忘了为开源做出应有的贡献，这也是在业界增加影响力的有效途径。
以做互联网产品的精神做SDN。在互联网公司有过工作经验的人都了解，互联网产品尤其是移动设备上面的应用的研发与其他软件的研发有些许不同。最突出的一点就是这些应用和服务的设计和开发完全以用户体验(UX, User eXperience)为中心，这一趋势可能是受到Apple或者说是Steve Jobs的影响。一言以蔽之，好的用户体验就是做出来的产品卓尔不群(Good and Different)，如图中的那把SENZ的伞就是一个较好的例子，它与众不同，且美观实用，是我比较喜欢的设计。而在设计研发互联网产品的过程中，互联网公司对用户体验的追求具体表现在：第一，制造需求。不期望用户完全了解需求，而认为用户并不真正知道想要的需求是什么，或者说对需求是模糊的，因此，需求要靠开发团队发掘出来，在制造需求时，有的公司更多的是靠经验和直觉，如Apple；有的公司更多的是靠大规模的数据分析，如Google。第二，消除痛点(Pain Point)。不断地发现用户在使用产品过程中的所谓痛点，这些痛点，是产品持续改进的动力和目标。第三，崇尚简约。让用户在完成一项功能时，所做的操作尽可能的简单，且容易明白。Apple的产品常常追求极致的简单，使得从孩童到老妪都可以轻而易举使用iPhone/iPad执行想要的功能。支撑产品使用简单的背后是开发团队的才华、创造能力(Creativity)、以及必不可少的艰辛付出。第三，注重细节。对产品的任何部分，哪怕看起来多么的微不足道，都要精雕细琢，精益求精，做得好到不能再好。对照以上四点，让我们检查一下当前的网络系统：第一，有的网络需求是很明确的，无须发掘，如在IaaS的云计算数据中心中，虚拟机(Virtual Machine)的动态迁移的需求，VLAN的4096个编码空间已不足用的问题。另外，可以将网络用户按照不同的需求梳理分类，分别发掘他们最关切的需求，做到自己的产品或解决方案中。让用户看到自己的产品和解决方案之后，会眼前一亮，立马感觉这就是TA想要的。第二，当前网络的痛点可谓数不胜数，已经到了虱子多了不痒的程度，需要改进的地方太多，这正是SDN存在的理由。第三，当前网络的管理配置繁冗复杂，让管理员疲于奔命，苦不堪言。第四，SDN往往是一个很大的系统，若对系统的每个部分都做到完美无缺，真不是一件容易的事儿。比如说，交换机的失败多数情况是由于软件的错误引起的，因此，如果对于交换机操作系统的每个细节，不放过任何的内存泄漏和core dump的因素，那么系统的可靠性和稳定性将会大幅提升。我想，对于以上四点，当别人做不到或做不好的时候，你做到了，而且做的很好。那你就是江湖中故老相传的独孤求败，求一败而不可得，想不成功，不也是很难吗？！
参考文献：
1. Thomas S. Kuhn. The Structure of Scientific Revolutions. The University of Chicago Press, 1996.
2. Thomas D. Nadeau and Ken Gray. SDN: Software Defined Networks. O’Reilly Media, Inc., 2013
3. SDX:A Software Defined Internet Exchange. Arpit Gupta, Laurent Vanbever, Muhammad Shahbaz, Sean P. Donovan, Brandon Schlinker, Nick Feamster, Jennifer Rexford,, Scott Shenker, Russ Clark, Ethan Katz-Bassett. SIGCOMM’14, August 17–22, 2014, Chicago, IL, USA. Available at
http://gtnoise.net/papers/2014/gupta-sigcomm2014.pdf
4. OpenDaylight.
http://www.opendaylight.org/
5. RouteFlow.
https://sites.google.com/site/routeflow/
6. Frenetic.
http://frenetic-lang.org/
7. Software Defined Networking.
https://www.coursera.org/course/sdn
8. Christopher Monsanto, Joshua Reich, Nate Foster, Jennifer Rexford, David Walker. Composing Software-Defined Networks. Available at http://frenetic-lang.org/publications/composing-nsdi13.pdf
9. Sushant Jain, Alok Kumar, Subhasree Mandal, Joon Ong, Leon Poutievski, Arjun Singh, Subbaiah Venkata, Jim Wanderer, Junlan Zhou, Min Zhu, Jonathan Zolla, Urs Hlzle, Stephen Stuart and Amin Vahdat. B4: Experience with a Globally-Deployed Software Defined WAN. SIGCOMM’13, August 12–16, 2013, Hong Kong, China. Available at http://cseweb.ucsd.edu/~vahdat/papers/b4-sigcomm13.pdf
10. What is a Software Defined Network. https://www.youtube.com/watchv=lPL_oQT9tmc&feature=youtu.be
11. Software Defined Networking(SDN) & Network Virtualization. COPYRIGHT 2013 ALCATEL-LUCENT.
12. Siamak Azodolmolky. Software Defined Networking with OpenFlow. Packt Publishing, 2013.
13. SDN The Next Steps. digital spotligh. Network World. Available at http://resources.idgenterprise.com/original/AST-0124359_NWW_SDN3_6_25_14.pdf
14. Brocade unveils OpenDaylight SDN controller. http://www.networkworld.com/article/2686047/sdn/brocade-unveils-opendaylight-sdn-controller.html
转载自：北京品科科技（Pica8）Yanmin Jia @贾彦民
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
