• SDN 是什么


    be3d4b74daeec5cb84bcf59fbc7ab88bfe2a4250

    SDN,Software Defined Network,软件定义(的)网络,这些年方兴未艾,愈演愈烈。但是,笔者以为,SDN 也有愈演愈劣的趋势。而且,现在业界关于什么叫 SDN,也是众说纷坛,莫衷一是。笔者在此试图梳理一下,SDN 到底是什么!

    一、SDN 发展的三条主线

    SDN 从诞生到发展,有三条非常关键的主线:

    • 第一条主线的主角是斯坦福大学。2008年,斯坦福大学 Nick McKeown 教授等人提出了 OpenFlow 的概念,并基于OpenFlow 为网络带来的可编程的特性,进一步提出了SDN(Software Defined Network,软件定义网络)的概念。2009年,SDN 概念入围Technology Review年度十大前沿技术,自此获得了学术界和工业界的广泛认可和大力支持。2009年12月,OpenFlow 规范发布了具有里程碑意义的可用于商业化产品的1.0版本。
    • 第二条主线的主角是 Google。Google 的 B4 网络 SDN 改造,给业界打了一针巨大无比的鸡血。 Google的改造分为三个阶段。第一阶段在2010年春天完成,第二阶段是到 2011年中完成,第三个阶段在2012年初完 成,整个B4网络完全切换到了 OpenFlow 网络。经过改造之后,链路带宽利用率提高了3倍以上,接近100%。这个给业界带来无法形容的冲击和震撼。笔者以为,SDN 开始爆发性发展,自此方始!
    • 第三条主线的主角是 Cisco。2012年6月,思科推出了ONE(Open Network Environment)战略。2013年4月,思科与其他公司一起发起成立了Open Daylight 开源组织,开发 SDN 控制器。思科这两件事情,其主旨都在“重新定义 SDN”。在此之前,SDN 还是与 Openflow 基本画上等号的,Cisco 站住来说,SDN 不等于 Openflow,这个我们从 ONE 的架构与 ODL 的架构可见一斑,如下图所示:
    0ce059f52ea1580fe56a556441973fd5ff37be0b

    图1 Cisco onePK 架构

    4ecdeb25d7d998ef48f074e9dd7fb224c3eb6da1

    图1 ODL 架构

    图1 是“onePK(One Platform Kit)”,是为了支撑 Cisco 的 ONE 战略。图2 是 ODL 的架构。这些架构,我们只需要关注图中红框的部分。onePK 红框部分,都是 Cisco 的设备,Cisco 的意思是:我家的设备就是 SDN,我给你包装一个 API(onePK) 就行了。ODL 红框部分的意思是:SDN 的协议,除了 OpenFlow,也可以是其他协议(NETCONF, BGP 等等)

    这三条主线非常有意思。斯坦福大学(Nick McKeown 教授等人)发明了 SDN,试图重新定义网络,Google 则将 SDN 推向了第一个高潮,而 Cisco 则希望将 SDN 转个方向,重新定义 SDN!如果说,斯坦福大学发现了一股清流,Google 则是掀起了一股巨浪,而 Cisco 就是搅浑这一池春水!(注:与思科一起成立 ODL 的公司有:IBM、微软、Big Switch、博科、思杰、戴尔、爱立信、富士通、英特尔、瞻博网络、NEC、惠普、红帽和VMware)

    二、SDN 的三大流派

    恰恰来说,前面所说的三条主线,演化为了 SDN 的三大流派:

    1、软件定义网元

    我们仍然套用 SDN 的命名方法,把软件定义网元命名为:Softeware Defined Network Element(SDNE)。网元指的就是交换机、路由器等等这些网络设备。

    这一流派源于斯坦福大学的 OpenFlow。斯坦福大学提出的 SDN 概念,以 OpenFlow 协议为基础,强调控制面与转发面分离,强调集中控制。但是,集中控制,这个词,如果抠字眼的话,其含义是有分歧的。

    • 一种含义是控制器心中有整个网络,基于这张网络做路径规划/计算,然后再针对每一个网元下发转发规则。
    • 另一种含义是,虽然一个控制器可以管理(控制)整个网络中的所有(相关)网元,但是这个控制器心中只有一个个独立的网元,而不是一张网络。控制器是每个网元自身做交换规则配置。比如我们在 Neutron 实现模型中所描述的计算节点中的 br-ex 和 br-int。

    这两种含义,都是一个控制器管理(控制)所有(相关)网元,也即集中控制。但是,后一种含义,其实只是离散地单个网元的控制。软件定义网元(SDNE),就是属于后一种含义。由于 OpenFlow 自身协议的缺陷和相关硬件的转发性能问题,其应用场景非常有限。现在基于 OpenFlow(或者其他类似的协议)做 SDNE,并不是主流。或者是一些小公司/创业公司,或者是大公司在极度有限的场景内,在推出 SDNE 相关产品。SDNE 流派,从表面上看,是继承了 SDN 的纯正地位,实际上已经对正统的 SDN 做了裁剪。这一流派虽然力量不大,但是仍然是现在业界延续 SDN 香火的主要力量。

    2、软件定义网管

    软件定义网管,Software Defined Network Management System,SDNMS。这一流派源于 Cisco 那个所谓的“重新定义 SDN”。Cisco 又是推出 ONE 战略,又是整一个 ODL 开源,虽然 ODL 开源号称也支持 OpenFlow,但是 Cisco 的本质是把传统设备做个包装,换个马甲,摇身一变为 SDN。话又说说来,当设备还是那个设备时,无论它是软的(VNF)还是硬的(PNF,传统路由器/交换机),其业务发放,除了象网管一样,做个配置,又能做什么?笔者在一个微信群里,看到有人转发一篇文章,如下图所示:

    59f5b1e796ea9b7e2322a2fad97787095997ee0e

    图3 某厂的 SDN 宣传资料(笔者还是将该厂的名字隐去吧,^_^)

    在该篇文章中,其宣称:控制器只负责业务下发,不负责转发表项的计算。转发表项的计算使用成熟度高的标准 BGP-EVPN 协议完成。这就是当前业界拿着网管当作控制器当作 SDN 来大肆宣传的典型案例。现在业界这种声音非常大,非常主流。他们在宣传时,还有一个经典的理论:网管的架构不好,网管的接口抽象的不好。(说的好像它的架构就很好,它的接口就很抽象似的。)我们不比较是网管与那个所谓的控制器,谁的架构好,谁的接口抽象。我们要认清一点:

    两个软件系统,做的事情(功能)是一样的,架构好坏,接口是否抽象,那是纯软件设计/开发的事情,那取决于设计开发这个系统的“人”,而不是冠一个 SDN 的名头,架构啥的就能自动变好。这个基本逻辑要清楚!如果连这样的逻辑都没有......这个业界主流声音,有两大可怕的后果:(1)思想上,混淆了 SDN 的概念;(2)行动上,浪费大量的人力物力,重新做一遍网管。

    对于那些没有网管产品的公司/组织来说(比如某些公司,比如绝大多数开源组织),重新做一遍网管,没有任何问题,因为它们本来就没有网管。而对于那些已经有巨形网管产品的公司来说,这样的想法,是要命的!

    3、软件定义网络优化

    软件定义网络优化,Software Defined Network Optimization,SDNO。SDNO 与 SDN Orchestrator 的简称重复了,请您注意不要搞混,^_^。这一流派,起源于 Google,与 Google 稍有不同的是,Google 采用的网元是 OpenFlow 网元(交换机),而这一流派采用的是传统的网元。这一流派也有一点 Cisco 的影子。不过 Cisco 流派的本质是网管,而这一流派的本质还是网络优化,所以我们还是把这一流派归为 Google 流派。前文说过,由于 OpenFlow 的限制,OpenFlow 网元(交换机)的应用场景并不多,所以这一流派采用传统网元,并没有什么不好,反而是非常正确。网络优化,指的是网络流量优化,在满足 QoS 的前提下,尽量提高网络的利用率。这一流派细分为两点:(A)静态最优路径计算;(B)动态路径调优。

    静态最优路径计算,就是先期计算一条路由的最优路径(一般是最短路径)。但是这个方法一个是没有全局的观念,一个是没有动态调优的能力,而且传统的路由协议,也基本上具有这样的能力,所以这一点,我们就不展开讲述了。不过需要指出的是,这一小流派,也是有一定的市场,他们往往拿着这一小点跟网管 PK,说它们不仅仅是做个网管,还做个路径计算。唉,不知道怎么说他们为好:(1)这是一个纯算法的编程,不是 SDN 独有的;(2)网管早已具备这样的能力。好了,不吐槽了,我们来看看动态路径调优。我们先举一个例子,如下图所示:

    c1779037e9eea77b6aee63cd62c24c8dd37d15b6

    图4 动态路径调优示例

    图中,一条流的路径,原本规划是:R1-R2-R3。但是,当这条路径拥塞时,会动态调整为一条较为空闲的路径:R1-R4-R3。这就是动态路径调优的一个简单的示意。从技术高大上的角度而言,动态路径调优,是这三个流派中技术含量最高的。但是,偏偏就是流派在 SDN 业界的声音最小。这一流派的鼻祖 Google,当年偶露一小手,就名动江湖,为什么这一流派却难成气候呢?是其他公司都傻吗?也不完全都傻,^_^

    这一流派有很多技术难点需要克服:流量实时监控与预测;大象流老鼠流的区分与预测;流的 QoS 的定义。这些技术难点,都难以克服。笔者就不展开描述这些技术难点了,您只需要关注一个词“预测”,就能想象有多难!比如上图中的例子,当你把一个流调整到 R1-R4-R3 路径时,突然间风云突变,R1-R2-R3 路径变空闲了,R1-R4-R3 变拥塞了。唉,被公司开除了,你都不知道找谁说理去!

    但是,这些那点为什么 Google 就能克服呢? Google 有什么黑科技吗?网上有一篇文章讲的非常好,“不要为了 SDN 而 SDN - Google 的 SDN 和你没关系”(https://www.douban.com/group/topic/47582532/),建议您阅读一下。笔者这里简略摘抄几条:

    (1)昂贵的跨国链路和海缆:相对于国内的传输链路,海缆和跨国链路会是天价。

    (2)N年的MPLS-TE部署经验

    (3)数据等级的分类:Google B4的海缆和跨国链路的平均利用率能维持在95%以上,这是一个极为惊人的数字。但在这个数字背后,我们可以读出什么?

    1. 内部数据已经有严格的等级区分了:什么样的数据是高优先级,什么是中、低优先级已经明确定义了。从服务器入口开始对应用就开始标识、限速;
    2. 各等级流量大小明确:从入口开始,每一种业务会有多少流量已经非常清楚了,这样才能汇总出整体各个等级的流量,才可以指定汇总的CoS等级规划。否则流量CoS是木有办法做的,这也是国内常常没有办法做CoS的原因;
    3. 中低优先级的牺牲成就了高利用率:CoS不能产生带宽,能维持高利用率是因为高优先级流量的轻载,然后用中低优先级去填充,那么故障、高优先级有突发流量等状况发生时低优先级一定会被延迟或者丢弃;

    总结起来就是三点:(1)需求强烈;(2)经验足,技术好;(3)流量状况自己能够掌握。对不起,满足这三点的,好像就是只有 Google 一家公司。Google 的网络,跑着是自己家的流量,那么这些流量它自己就可以规划,而我们要面对的是一个未知的网络,谁知道这个网络里的流量是什么情况,谁知道这个网络里的流应该是什么等级?Google 恰恰是没有黑科技,而是从源头上来讲,我们(除了 Google 以外所有人)与 Google 所面对的复杂度是完全不可同日而语的。

    另外,网络动态调优,还有一个悖论:不在现网做大量测试,就没法稳定,没法商用;但是,没有一个现网能允许一个不稳定的程序在其上面做大量测试。这就形成了一个死循环。而 Google 恰巧也能打破这个死循环,因为它的流量成本非常高,“昂贵的跨国链路和海缆:相对于国内的传输链路,海缆和跨国链路会是天价”。高昂的成本能够促使其下定决心来打破这个死循环,很遗憾,我们好像找不到还有谁家有动力打破这个死循环。第三点,Google 是自己研发。自己最懂自己的网络,这一点,也是无法比拟的。

    正是有这三点保证,Google 能够偶露峥嵘,而其他公司要想做到,几乎不大可能。这也正是这一流派,看起来很美,其实非常势微的原因。(笔者猜想,这同时也是 Google 为什么在露一手以后,极少在 SDN 业界发音的原因。他也找不到第二个相同的 story 了。事了拂衣去 深藏功与名!)

    4、小结

    我们上一张“SDN 成熟度”图谱,这个图谱,是鄙人定义的。如下图所示:

    c978256a0848a2ac39c6969bb75665a330909ec5

    图5 SDN 成熟图图谱

    横坐标表示“通用硬件成熟度”,纵坐标表示“流量优化(全局网络)成熟度”。我们先讲 SDNE(软件定义网元),由于 OpenFlow 自身的限制,SDNE 当前还是只能局限在有限的场景中应用,所以我把它的通用硬件成熟度,归结为“0.1”。而 SDNE 流派,如果抛开 OpenFlow 不谈,其实它也是个网管,也是控制器心中没有全网(全网在人的心中),也是仅仅做个配置而已,所以我把它的“流量优化(全局网络)成熟度”归结为“0”。

    以 SDNE 为参照物,那么很自然地,我们就可以把 SDNMS(软件定义网管)这一流派归结为(0, 0)这一维度,既没有通用硬件成熟度,也没有流量优化(全局网络)成熟度。SDNO-1,静态网络优化,比 SDNE 稍微好一点,毕竟做了一些静态全局最优路径计算,所以我把归结为(0, 0.1)这一维度。我们再看看伟大的 Google,其实也才属于(0.1, 0.2)这一维度。它使用的是 OpenFlow 交换机,所以通用硬件成熟度是 0.1,而它的动态流量优化是建立在“流量尽在掌握”的前提下做的,所以我只把它的流量优化(全局网络)成熟度归结为 0.2。

    图中,我把两个成熟度为“1”的地方,都画了个圆圈,其实我是比较委婉,我本来是想画个红叉的。在当前阶段,动态流量优化几乎不可能,也许将来大数据、人工智能技术成熟以后,这一块可以突破。而统一硬件成熟度这一块,OpenFlow 已经没有希望,现在替换 OpenFlow 的相关软硬件技术也有,不过笔者以为,那也是不解决问题。硬件成熟度要想达到“1”,短期内,也是几乎不可能。

    两个不可能,鄙人觉得,可以给我们一些启示:作为产品规划,大公司可以冷静下来了,当前现状,SDN 不适合去大张旗鼓做一个产品,而是应该转为纯理论研究。至于小公司/创业公司,在 SDNE(软件定义网元)这一领域可以赚点钱,这无可厚非,尽管去发展。至于那个 SDNMS(软件定义网管),如果您当前没有这个网管,那么您就做,如果您需要的话,而如果您想继续鼓吹这就是 SDN,那就鼓吹吧,毕竟这个世界需要谎言。如果您当前已经有一个巨型网管产品,笔者奉劝一句:停下来吧,不要再重做一遍网管!!!至于 SDNO-1,静态网络优化,它的体量还不足以成为一个产品,也就是一个模块,建议集成到网管中里面吧,不要拿这个来说事,给自己重新做一遍网管找个理由了!不要以狼性为幌子,做公司的罪人!不要以行动的勤奋,掩盖思考的懒惰!补充一句,我一直都没有提 SDN 协同器。那么 SDN 协同器应该划归为哪一个维度呢?你猜......

    三、SDN 的本质

    在我心中,SDN 的本质,如下图所示:

    6364223cf0e246059bcb985b9b5aca82e40d432d

    图6 SDN 的本质

    在我心中,SDN 的本质,只需要达到(1, 0.1)即可,不需要达到(1, 1),当然,能达到更好。一个通用的硬件,加上一个静态最优路径算法,就是我心中的 SDN 的本质。至于 Google 的那个海缆价格太贵,那是个别需求,不影响大局。

    我以前说过,SDN 的本质是“淘宝 + 百度”,有人把我这个观点理解为“SDN 就是白盒化”,对不起,您误解了我的观点。分析一个技术的本质,首先要看这个技术的经济效益体量。如果一个技术的经济效益体量也就产生三毛二毛的利润,那么这个技术,我们没必要去分析其本质。

    从经济学原理讲(这个原理是我瞎编的,^_^),专业化产生封闭,标准化产生分工,而社会化大分工,巨大提高社会生产率。复杂化、专业化,会产生个别企业的高利润,而标准化、简单化,社会化大分工,会产生全民的高收益。

    SDN 的本意,以 OpenFlow 为基础(我们假设 OpenFlow 行得通),推导出标准化的硬件和简单化的软件。我们想象一下这个场景:硬件已经标准化,那就是唾手可得(这是我说从淘宝买硬件的原因),通信协议基础包,届时肯定是开源了,只需要在其基础上做个性化需求即可(这是我说在百度上搜索软件的原因)。

    OpenFlow 当前有各种各样的问题,那是技术本身的问题,这不影响 SDN 的本质。SDN 的本质如果能实现,那必然是全社会的电信生产效率巨大提高,全民付出的电信资费极度降低。当前的科学证明,宇宙中的速度不能超过光速。对于科学,我们需要保持敬畏!SDN 的本质能否实现,从科学角度讲,是可能的,还是不可能,这同样需要思考!另一个层面的思考!


    来源:标哥说天下 作者:李宗标 
  • 相关阅读:
    day 28 客户端服务端架构介绍,互联网协议,互联网协议补充,三次握手与四次挥手
    day25 单例模式实现方法一 单例模式实现方法二
    day24 反射/定制__str__方法控制对象的打印格式/定制__del__方法回收系统资源/元类介绍以及默认元类type创造类的过程/自定义元类控制类的创建过程/自定义元类控制类的调用过程
    day 23 封装之如何隐藏、封装之隐藏属性的底层原理、封装的真正意义、property特性、绑定方法与非绑定方法
    day22 组合、菱形继承问题、C3算法与mro介绍、在子类派生的新方法中重用父类功能的两种方式、super()严格以来继承关系、多态与鸭子类型
    day21 对象定制自己独有的属性/属性查找/绑定方法/小结/继承介绍/继承与派生
    day19 正泽表达式,sys模块,打印进度条,subprocess模块
    day18 logging模块的补充/jason序列化与反序列化/json补充/pickle序列化与反序列化/time模块/datetime模块/random模块/os模块
    day17 包的使用 logging模块的基本用法
    day16 面向过程编程/模块介绍/import导入模块/ from...import导入模块/循环导入问题/模块的搜索路径/区分python文件的两种用途/软件开发的目录规范
  • 原文地址:https://www.cnblogs.com/twodog/p/12141016.html
Copyright © 2020-2023  润新知