在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?

在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?


在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?

      一个技术之所以能红,那必然是因为当前网络大家不能满意,有很多不爽的地方,就是现在的不如意成全了新技术的茁壮、发展和成熟。那当前网络具体问题在哪呢?我们先看看以下几个场景。


在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?

在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?

在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?


1 传统网络到底怎么了?


      上面几个场景体现了传统网络中的种种问题,虽然现实中没有这么夸张,但是也真实反映了一些客户痛点。


      但是实际上并不是设备厂商店大欺客,实在是传统的基于TCP/IP的网络架构对这些需求无能为力。下面我们来简单分析一下


1:创新困难,创新周期长


      传统TCP/IP网络设备结构是控制平面和转发平面深度耦合的结构。这里简单解释一下控制平面和转发平面。简单来说,控制平面就是一台网络设备的大脑,我收到一个报文,应该怎么处理,是丢弃,还是转发,从哪个接口转发出去,这些都是控制平面需要决定得。而转发平面就很简单,控制平面告诉我怎么处理,我就怎么处理好了。


      那么如果一个大型网络有几十甚至几百台网络设备,那么如何保证这些网络设备能够良好的配合,完成任务呢。显而易见,所有的网络设备都必须遵循一定的标准,从而保证网络能够动作统一。但是一个网络中的设备不一定都是一个厂家的,厂家间也难免你看不起我,我看不起你的。于是大家就推选了一些“德高望重”的人(IETF、IEEE等组织)负责制定这些标准,这就是所谓的标准协议,比如OSPF、BGP这些。


      于是,当我们要部署一个新业务时,就必须先去商讨这些标准,商讨完后,再进行开发,验证,最后,由于网络中每台设备都需要了解这些标准,所以我们需要在每台设备上都进行更新。这么一套下来,没有个3、5年还真是难以完成。


2:协议复杂,运维难度大,运维成本高


      上面我们说到了标准协议,现在标准协议是越来越多,每年仅IETF发布的关于网络设备的标准协议就有上千,而且还在以每年接近翻倍的速度增加。如此多的协议别说都精通,就是看一遍也去了半条命了,所以也难怪现在各厂家维保的要价越来越高,这活确实难做啊。


3:路径规划能力弱


      前面我们说过,在一个网络中,为了使所有设备能通力配合,一般来说,所有设备都需要遵循一定的标准协议。那么体现在网络最重要的功能路径选择上,就是一系列路由协议了。我们先来看一个场景:


在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?


      如图,现在有A(10G)、B(5G)两个业务流量都希望能从RouterA转发到RouterD,很显而易见,有两条路可以选择,RouterA—RouterC—RouterD和RouterA—RouterB—RouterC—RouterD,但是如果这4台路由器都运行了OSPF路由协议,那么由于OSPF协议是基于最短路径算法的,协议会选择带宽较大的那条路,即RouterA—RouterC—RouterD这条路径,于是这条路径就会变得拥挤不堪,10G的带宽无法完全承载A和B两个业务。


      这时我们就很奇怪,为什么不能让业务A走RouterA—RouterC—RouterD,而业务B走RouterA—RouterB—RouterC—RouterD呢?很遗憾,以目前的路径选择协议来说,无法实现这个需求。


      究其原因,我们目前主流的路径选择协议大多是采用最短路径算法(为了避免环路),业务A和业务B的目标都是从RouterA到RouterD,那么他们的最短路径必然只有一条(或者等价的多条路径),于是就造成了上面的情况。


2  那么SDN又是何方神圣?


      相信大家都急不可耐的想认识一下SDN了,他是谁,为什么这么厉害。别急,相亲还要先了解一下对方的生辰八字、属相星座呢是吧。我们先来感性认识一下SDN。


      一直以来,网络世界都被一众运营商和设备商大佬把持着,是一个相对封闭的世外桃源。但是随着互联网的飞速发展,传统网络越来越难以满足新业务的需求。矛盾越来越难以调和,大佬们不得不出来通过添加新协议、新设备等手段来缓解问题,但是却成效甚微。于是,人民群众中滋生了革命的想法,现有的网络架构既然无法继续演进发展,为何不推倒重来,重新定义网络呢?


      于是越来越多的人加入革命者的行列,开始探索新的网络发展道路,但却一直没有一个较为完善的理论诞生,直到2006年,美国斯坦福大学在GENI项目的资助下成立了Clean Slate课题,斯坦福大学Nick McKeown教授为首的研究团队提出了Openflow的概念用于校园网络的试验创新,后续基于Openflow给网络带来可编程的特性,SDN(software defines network)的概念应运而生


      SDN概念的提出,在已经沉寂多年的网络世界中刮起了一股创新的热潮。很快,在2009年Openflow发布了第一个商用版本Openflow1.0,标志着SDN正式有了一份较为完善的理论体系,并具备了向传统IP网络宣战的实力。


      有了理论体系还不够,将理论转变为实际应用才是硬道理。当然这一步仅靠一些散兵游勇肯定是不行的,我们需要有组织有纪律的正规军。于是2011年,在Nick McKeown教授的倡导下,开放网络基金会(ONF)成立了。基金会是非盈利性组织,宗旨就是加速SDN的实际部署。基金会一经成立,立刻吸引了新兴的IT厂商和运营商的加入。一时之间,SDN风头无两,各种研究也在如火如荼的进行中。


      说到这里,我们就来看看,到底SDN有什么样的魅力,能在短短几年里变成了网络世界的网红呢?


3  SDN的基础:转控分离,集中控制


      SDN顾名思义,就是软件定义网络,其最基本的特点就是它的转控分离网络架构,在前文中我们提到,传统网络设备分为控制平面和转发平面。控制平面负责指挥,转发平面负责执行。但是在SDN网络中就大不一样了,SDN网络新增了一个网络部件--SDN控制器,这个控制器完全由软件实现,它就如同网络的大脑,可以指挥网络中的所有设备。相应的,所有其他的网络设备就不再需要自己的控制面了,只需要听从控制器的命令进行转发就可以了,我们称之为转发器。于是SDN网络的简单模型如图:


在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?


      大家可以看到,所有我们常见的路由器、交换机等转发设备都变成了统一的转发器,而所有的转发器都直接接受控制器的指挥。我们可以把SDN网络和城市的交通路网做一下对比,转发器就相当于交叉路口负责指挥的交警,而控制器就如同交通调度中心,交通调度中心了解整个城市的交通状况,根据每条路的路况,合理的安排车流量(数据流量)。


      那么这个新的网络架构能不能解决传统网络面临的难题呢?我们一个一个来看一下:


1:创新困难,创新周期长


      在传统网络中,没有交通调度中心,每个交警自己根据自己的判断去指挥车流量,如果需要优化交通情况,无疑需要把所有交警都叫到一起,大家一起商量商量,你那边什么情况,我这边什么困难,你一言我一语,等达成了一致,还需要给所有的交警做一次培训,让大家都学习一下新的规章制度,这效率无疑十分低下。


      有了交通调度中心后,交警就轻松了,不需要自己去指挥车流量,调度中心让怎么走,我就怎么指挥,如果需要优化交通情况,那调度中心直接根据全局的情况进行优化,优化后的方案也不需要让交警明白,交警只要能明白最简单的左转右转命令就可以了。这样,无疑节省了大量的时间


2:协议复杂运维难度大,运维成本高


      之前我们说到传统网络协议多如牛毛,那为什么有这么多协议呢?很简单,因为并不是每辆车都只需要向左转向右转就可以了,还有一些特殊的需求。比如:有的车希望能有专用的车道(v*n),有的车到了一个路口,希望可以把车上的东西同时送到3个地方去(组播),还有的车甚至希望能一直插队,别的车等红灯,我可以直接闯(QOS)。有了新的需求,就需要制定一系列新的规章制度来满足这些要求,比如需要将东西送到3个地方,那么交警就需要记住,从XX地方来的车,需要给他指3个方向。于是随着需求的越来越多,交警需要掌握的交通规则也就越来越多。


      而有了交通调度中心,这些特殊的需求再也不用这么麻烦了,交警还是只负责指方向、拦车、放行这些简单的动作,至于指哪里,指几个方向,哪些车拦住,哪些车放行,听指挥就行啦。


3:路径规划能力弱

在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?


      还是这个例子,在传统网络中,交警A只能了解到交警D那边的两条路分别有多宽,根据这个信息,他指挥车流都从A-C-D这条路走,而每条路的路况他无法知道,所以就容易造成A-C-D非常拥塞而另一条路却无人问津。


      有了交通调度中心后,一切都不一样了,交通调度中心可以从全局得知整体得路况信息,从而在A-C-D车流量较大的时候,让交警指挥车流量从A-B-C-D这条路走


      这是有的小伙伴就会问,为什么交警不能自己去了解一下路况呢?实际上,并不是交警不想去了解,而是如果每个交警都需要去了解所有的路况,压力就太大了,就算有些交警中的精英可以达到这个要求,也不可能保证每个交警都能扛得住对吧。而有了调度中心,就只需要调度中心去了解路况就可以了,这样可操作性就大了很多。 


      到这里,我们已经将SDN的大致思想解释了一下,光有思想还不行,还需要有能实打实落地的手段,否则那就不叫思想了,只能叫梦想。


4  SDN的武器:Openflow


      前面我们说到,SDN凭借着转控分离的网络架构,解决了很多传统网络中难以解决的难题,但是问题来了,这种架构怎么实现呢?我们的控制中心如何获取实时路况,并且下发命令给各个交警呢?


      我们的革命者们同时也开发了一个新的协议:Openflow,该协议用于调度中心和交警之间进行沟通,并指导转发器进行转发。具体来说,openflow需要解决以下3个问题:


1:建立调度中心和交警之间的沟通通道


      首先,调度中心和交警之间需要有一条顺畅并且安全的沟通通道,所以openflow协议规定了控制器和转发器之间必须要有一条三层可达的链路,通过该链路建立TCP连接,并采用了安全的算法进行加密(比如TLS)。同时,链路需要通过定时的Hello进行保活,保证链路出现问题时能及时发现。


2:从交警那里收集各个路口的路况


      由于是统一管理,每个路口的性能指标需要规范化,比如路口一共有几条分叉路口(端口),每条路有多宽,能承担多少车流量(带宽),每条路是不是有事故导致通行不畅(链路故障),每条路目前的车流量大小(链路占用率)以及路口的调度能力(设备表项大小)等。这些数据必须以统一的格式上传调度中心。同时,如果哪个路口修了新的路,也需要将上述指标主动上报给调度中心。这部分内容很好实现,只需要定义一个标准的消息格式即可。


3:告诉交警如何指挥车辆


      前面我们说过,交警只需要听从调度中心的命令即可,但是如果针对每一辆车调度中心都要给交警下发一个指令未免也太效率低下了。于是革命者们想了一个法子,让调度中心给每个交警一张表,这张表的内容简单来说就是

在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?

      交警们收到这张表,就直接根据车辆信息直接进行指挥,同时记录下每种车辆的数量用于统计本路口的指标。这样一来,就不用每辆车都需要调度中心直接下命令,交警直接可以自己进行指挥。


      可以看到,这张表无疑就是整个openflow协议的核心,我们称之为流表。在openflow协议提出之初,革命者们的初衷很简单,传统网络中各种各样的转发协议太复杂了,我们就根据流量本身的属性,针对每种流量在定义一个动作,这种方式无疑会大大简化设备上的转发流程,于是在openflow1.0版本中,流表是长这样的:


在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?


      在匹配域中装着车辆的各种信息,在最初的想法中,革命者是想通过一个可扩展的数据结构使流表可以匹配任何数量和种类的车辆信息(比如TLV架构)。


      可是理想很丰满,现实很骨感,openflow1.0推出后,遇到了一系列的阻碍,其中最主要的两个问题就是转发效率和成本的问题,怎么回事呢?


      原来现在交通指挥已经智能化了,交警们拿到这张表以后,首先会把这张表存到一个智能终端(转发芯片),指挥交通时,直接使用智能终端进行指挥,这台智能终端主要的成本就在存储流表的存储器(TCAM)上。以前,需要储存的表都比较小,如路由表仅包含目的IP、下一跳、出接口等几项。而这次的新表要求能匹配任意的车辆信息。


      我们举个例子:如果交警仅关注车辆从哪里来(SIP),和到哪里去(DIP),假设车辆可能会从A、B、C三个地方来,可能会到a、b、c三个地方去。则我们需要几条表项呢?我想表应该是这样的

在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?

      我需要9条表项就可以包含所有的车辆情况(Aa、Ab、Ac、Ba、Bb、Bc、Ca、Cb、Cc),而如果现在交警还需要关注车辆所属的城市(假设车辆可能来自m城市或者n城市),那么简单算一下,我们就需要18条表项来包含所有的车辆情况(Aam、Abm、Acm、Bam、Bbm、Bcm、Cam、Cbm、Ccm、Aan、Abn、Acn、Ban、Bbn、Bcn、Can、Cbn、Ccn)


      可以看到,随着需要匹配的字段数量的增加,表项数目会指数级的增加。这无疑增加了需要的存储器大小,交警查看这些表项的时间也会增加,从而导致了成本增高以及转发效率的降低。


      为了解决这个问题,革命者在openflow1.1版本中,引入了多表的机制。还是以上面例子继续说,刚才我们说假设车辆可能会从A、B、C三个地方来,可能会到a、b、c三个地方去则需要9条表项,我们现在把这个表分成两个表。

在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?

      先匹配表一(车辆从哪里来),再去匹配表二(车辆要去哪里)。可以看到,表一加上表二已经可以包含所有车辆的情况,但是表项的数量却减少为6条,表项数量从乘法关系变成了加法关系。


      这样无疑大幅减少了流表的大小,表项数量的减少同时也降低了交警查表所需要的时间。一举解决了成本和查表效率的问题。


      在后续的OpenFlow1.2、OpenFlow1.3和OpenFlow1.4版本中,革命者们还做了一系列优化,包括增加了大量可以匹配的车辆信息,同时也增加了调度中心的数量,保证在一个调度中心故障的情况下交警依然可以从其他调度中心获得指令等。


5  大佬们的反击:谁说SDN一定要openflow?


      革命者们如火如荼的进行这SDN的研究,新的网络架构也越来越得到大家认可,很多饱受传统网络困扰的IT厂商也加入到研究行列中,一方面,他们想藉此让自己的网络脱离传统运营商和设备商的控制,另一方面,他们更想在这一波革命浪潮中占得先机,在未来的网络世界中分一杯羹。


      于此同时,我们的运营商和设备商大佬们在干什么呢?SDN的兴起无疑对大佬们是一次巨大的打击。


      对运营商来说:新的网络架构让网络彻底软件化,自己辛辛苦苦建立的庞大的传统基础设施彻底沦为转发管道,网络的主导权以后就要拱手让人,无疑是难以接受。


      对于设备商来说:这更是致命打击,我们的核心就是网络控制权。转控分离的网络架构直接击中要害,以后交换机都要沦为白牌交换机,再无利润可言。


      但是大佬们纵横网络世界数十年,自然不可能束手待毙,毕竟大佬们在网络控制方面的技术还是有明显优势,同时就算交换机都沦为白牌,数据转发还是大佬们得老本行,你SDN再牛,硬件上还是得依赖我们。


      于是大佬们做了两手应对,一方面,积极参与SDN方案的讨论,争取在新的领域也获得话语权,毕竟我们有钱有技术,说话也还有一些分量。另一方面,传统网络目前的体量如此庞大,立刻全部替换为SDN网络绝对不现实,我们承认SDN转控分离思想是先进的,但是你革命派到现在也就是提出了几个不成熟的理论,离真正实现SDN还远着呢。我也要对外提出我对SDN的看法,谁说SDN就是依赖openflow的完全转控分离?


      于是,大佬们一合计,拿出了自己的方案:Overlay技术。实际大佬们的想法很简单,前面说的传统网络的问题,目前困扰客户最大的还是网络不够灵活,业务的快速发展导致对网络有越来越多的需求,但是网络的发展速度却跟不上业务的发展速度。


      而overlay技术说白了,就是让真正的逻辑网络不依赖于物理网络的一种方式,怎么理解呢?我们以目前最火热的overlay技术VXLAN为例:


在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?


      这是我们经典的三层布局,网关设在汇聚交换机,三层IGP,二层xSTP。然而云计算的兴起,服务器的虚拟化大量应用,对网络提出了新的要求。服务器虚拟化实际上就是将服务器资源灵活调度,可以将一台服务器搞成多台逻辑的服务器,或者将多台服务器变成一台逻辑的服务器,这样就可以使业务更加灵活的部署。


      既然是逻辑的服务器,那么客户当然希望逻辑服务器可以部署在任意的物理服务器上,这样才能更加有效的利用物理资源嘛,于是这就要求整个网络服务器都必须在同一网段中。像上图中,服务器区A中的逻辑服务器就没法部署到服务器区B中,道理很简单,网段不一样。


      那么怎么实现这个诉求呢?大家可能会说,很简单啊,重新规划一下,把所有的服务器都放到一个网段呗。


      在规模较小的网络中,确实可以这么做,但是如果网络规模非常大,xSTP的收敛性能和算法限制都是没法支持大型二层网络的。


      第二个方法,既然xSTP不能支持规模大的网络,那我们就开发一个能支持这么大网络的协议呗。事实上,也确实有协议可以支持,如L2MP类技术TRILL、FP等。但是这类协议就要求网络的设备都支持新的功能,可能还需要转发芯片进行升级,这又回到我们开头说的,少则3年,多则5年,还要进行全网设备升级,很多客户都觉得不能接受。


      那么怎样能让现有网络不做任何变化,又能实现我们的需求呢?这时,服务器虚拟化的思想启发了我们,既然服务器可以变成逻辑的服务器,并且可以部署于任意的物理服务器上,那网络为何不能摆脱物理网络的束缚,在物理网络之上,构建一个逻辑的网络呢。这就是overlay技术核心思想那么具体如何实现呢?


在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?


      可以看到,我们理想的网络应该是这样,所有服务器都连到外面物理网络中,物理网络是什么样我不需要知道,我只需要知道,这个物理网络是基于IP转发的,所以我的报文想去哪就告诉它我的目的IP是哪里就行了。


      于是我们的转发方法也就很简单了,举例,如果ServerA想访问ServerB,那么我肯定会先封装一个普通二层报文:


在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?


      源MAC是MACA,目的MAC是MACB。那么第二件事是我需要告诉物理网络,把我送到ServerB那里,怎么送到ServerB那里呢,我就要告诉物理网络我要去的目的IP,于是我在原来的原始的二层报文外面,再加一层IP网络的封装,像这样:


在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?


      这样,在物理网络中,他就根据前面紫色的内容正常转发,等出了这个物理网络,我们再把前面这层东西去掉。ServerB收到的还是原始的二层报文。


      当然,这里只是给大家讲了overlay技术最基本的思想,如VXLAN协议的封装,转发并非这么简单,还需要考虑二层隔离,网关处理等等问题,这里就不展开讨论了,有兴趣的同学可以去看下红宝书VXLAN专题。


      我们再来总结一下overlay技术,可以看到,实际上,物理网络成了我的一个工具,为我进行单纯的IP转发,而实际的逻辑网络再也不用看物理网络的脸色了,我想怎么部署就怎么部署,后面转发的时候我给你物理网络封装一个IP报头,你帮我转发就行了。这个封装和解封装的过程可以放在服务器上通过软件实现。不管物理网络是基于IP、基于MPLS、或者基于其他,都不要紧,你是基于什么转发,我就给你外面加一个你需要报头就可以了。

 

      所以overlay技术很大程度的提高了网络的灵活性,并且不用对现有物理网络做任何变动。同时,封装的过程和内容可以通过软件实现,这就是为什么大佬们认为overlay技术也继承了SDN的思想,并且相对openflow有其优势。这种方案不像openflow那样激进,属于对现有网络的改良,所以我们暂且称之为改良派


6  SDN的未来


      革命派和改良派依然在激烈的博弈,各种知名的不知名的,老油条新兵蛋子都加入到这场网络世界话语权的争夺战中,一台大戏已经开始,我们不禁要问,SDN到底会向什么方向发展呢?


      这里我就大言不惭的说下自己的看法,一家之言,大家权作笑柄:


      对于革命派:革命派是坚定的支持基于openflow的完全的转控分离,从根本上改变目前的网络架构。革命派的理论是先进的,进展也非常快,已经有很多厂商推出了自己的openflow控制器和openflow交换机。但是总体来说,目前这个路线还是不成熟的,缺少成体系的解决方案,同时技术上也存在很多被诟病的地方,比如:openflow至今没有定义完善的流表转发模型,导致各个厂家实现不一,难以通过一个控制器进行控制。SDN目前只定义了控制面和转发面,对于管理面的问题却一直没有得意解决。又比如,SDN控制器大多是基于linux和windows系统的,从而导致易于被攻击。所以革命派想要真正革命成功还需要很长一段时间。


      对于改良派:改良派通过一系列网络虚拟化技术提高了网络的灵活性、缓解了一些传统网络的顽疾。如软件overlay一类技术也声称自己可编程,可灵活的自定义网络的控制面,同时也可平滑演进。这类技术最大限度的改善了现存的体量庞大的传统网络,但是从本质上来说,其和SDN彻底转控分离的思想还是有所差异。同时,overlay技术本身也并不是完美无瑕,其在和传统二三层网络互通,网关处理方面也同样存在一些缺陷。


      不管如何,统治了网络世界几十年的TCP/IP体系也许真需要改变了,可能在不远的将来,本文开头的对话会变成。


在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?

在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?

在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?


相关阅读



温馨提示:
请搜索“ICT_Architect”“扫一扫”下面二维码关注公众号,获取更多精彩内容。

在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?

专注做一个有情怀的技术分享平台

在这个SDN年代,企业网络演变,直接影响老板对我的态度变化?