2015-03-26 00:00:00
来 源
简书-小七叔叔
SDN
作者由面及点,一步一步细化,叙述了一个传统网管对SDN的切身体会.从SDN诞生的行业大背景开始,接着抽丝剥茧般的剖析SDN技术并分析当前SDN的现状,最后从“我”出发,讲述SDN与我们.

作者由面及点,一步一步细化,叙述了一个传统网管对SDN的切身体会。从SDN诞生的行业大背景开始,接着抽丝剥茧般的剖析SDN技术并分析当前SDN的现状,最后从“我”出发,讲述SDN与我们。

一、行业大背景

1、SDDC(软件定义数据中心)时代的到来

随着云计算时代的到来,爆发式的数据增长,让数据中心的基础架构面临着前所未有的挑战,一场由应用驱动的变革正席卷着整个IT行业,在这场变革中最主流的思路是硬件重构和软件定义,硬件重构由于需要极强的硬件研发能力,显然不太适合传统行业,因此SDDC必然将成为未来数据中心发展的主流方向。

数据中心基础设施资源主要包括:计算资源、网络资源、存储资源。而SDDC正是对这三大资源进行了软件定义,其目的非常一致,都是为了应对数据中心的爆发式扩展问题,具体可以总结为以下几点:

  • 底层无差化,屏蔽底层物理设备差异,增加基础架构的弹性、灵活性、可扩展性;
  • 资源虚拟化,提高资源的利用率,降低设备成本;
  • 管理集中化,提高运维效率,降低人力成本;
  • 应用驱动化,应用按需动态调度基础资源,使基础资源更敏捷的为应用服务。
a network manager think of SDN1

2、SDN诞生背景

在IT领域一个新技术的诞生总有其必然的原因,同样SDN诞生的原因基本可以用12字概括:压力决定动力,需求推动变革。

压力来自何处?宏观上看是因为云计算带来的数据中心爆发式扩展、网络需要更有弹性的服务应用等等,但我个人认为实质是计算资源率先虚拟化后的倒逼。由于网络行业的生态圈相对较为封闭,加之行业的Big Brother们出于商业利益以及市场地位的考虑,对于创新的技术不会发自内心的推动,导致网络行业的创新一直停滞不前。但是当计算虚拟化率先广泛应用后,一方面企业网管人员感受到了传统网络无法支撑由于计算虚拟化后的带来的数据中心更加爆发式的扩展,网络变得非常笨拙,甚至会成为应用快速部署、迭代的负担;另一方面网络行业的大佬们也意识到了危机感,开源组织、新兴的初创公司、跨界而来的软件公司无不虎视眈眈的盯着SDN这块大蛋糕。因此在用户和厂商的共同需求下,SDN终于从概念开始向商业化的逐步推进。

二、SDN技术剖析

1、SDN架构的本质

控制平面和转发平面解耦合
控制平面:主要用于对交换机的转发表或路由器的路由表进行管理,同时负责网络配置,系统管理等方面的操作,控制平面通常由网络操作系统来实现。

转发平面:主要用于对每个数据报文进行处理,使之可以通过网络交换设备,这些操作大多采用专门的硬件实现,主要包括转发策略,背板、输出链路调度等功能,转发平面通常会采用专门设计的ASIC芯片实现性能提升。

在传统的网络交换设备中,控制平面和转发平面是紧密耦合的,被集成到单独的设备盒子中。各个设备的的控制平面被分布到网络的各个节点上,很难对全网的网络情况有全局把控。因此SDN网络一个重要的理念就是把每台单独网络设备中的控制平面从物理硬件中抽离出来,交给虚拟化的网络层处理,整个虚拟化的网络层加载在物理网络上,屏蔽底层物理转发设备的差异,在虚拟空间内重建整个网络。这样一来,物理网络资源被整合成了网络资源池,如同服务器虚拟化技术把服务器资源转化为计算能力池一样,它使得网络资源的调用更加灵活、满足业务对网络资源的按需交付需求。

集中化的网络控制
将控制平面进行集中控制,中央控制器可以获取网络资源的全局信息并根据业务需要进行资源的全局调配和优化,如QOS、负载均衡功能等。同时集中控制后,全网的网络设备都由中央控制器去管理,使的网络节点的部署以及维护更加敏捷。

开放接口,网络可编程
开放南向、北向接口,南向接口控制SDN交换机,北向接口提供应用对网络的按需调度,实现应用和网络的无缝集成。

2、SDN架构核心组件

a network manager think of SDN2

SDN交换机:进行数据转发,自己不产生各个表项,由控制器统一下发,可以是硬件、软件等多种形态。

南向接口:控制器通过南向接口管控SDN交换机,并向其下发各项流表。最著名的南向接口就是openflow,当然南向接口现在有很多种。

SDN控制器:负责整个网络的控制平面,承接物理网络和上层应用。目前市场上厂商的、开源的控制器大大小小有几十种。各个厂商基本都为自己的解决方案配备了独有的控制器,比较有名的开源控制器有:NOX、ONOS、Floodlight、Ryu。

北向接口:通过控制器向上层业务应用开放接口,使业务应用可以便捷的按需调度底层网络资源。由于openflow标准没有定义北向接口,因此北向接口方面还没有什么业内公认的标准,比较有名的有opendaylight的REST。

SDN应用:SDN的最终目标是服务于多样化的应用。因此未来会有越来越多的SDN应用被开发,这些应用能够便捷的通过SDN北向接口按需调用底层网络资源,目前比较有名的是openstack的neutron。

三、SDN的发展现状

1、SDN标准之争

三大SDN标准化组织:
ONF:ONF是一家非盈利性组织,是现在规模最大的SDN标准组织,ONF在南向上定义了开放的openflow协议,但是在北向和控制器上没有统一要求。真心支持openflow的主要是以google、facebook为主的用户群体,以及一些初创厂商。

a network manager think of SDN3

ETSI:由全球多个运营商、电信设备供应商组成,则着力于NFV(网络功能虚拟化)的研究,旨在通过研究发展标准的IT虚拟化技术,使更多网络设备类型能融入到符合行业标准的服务器、交换机和存储设备中。体现了更多的是运营商的需求和思路。

OpenDaylight:由以cisco、juniper为主的IT厂商推出的开源项目,相较ONF,ODL更加清晰的定义了SDN的各个组件,包括控制器、南北向接口等,形成了一个更为完善的生态圈。但是ODL也存在着自己的问题,一方面是由于厂商主导不会考虑用户的感受,另一方面很多业界人士担心一些大的厂商会控制开源社区,以开源为名,将自己的专有化产品推成标准化。

a network manager think of SDN4

不难看出,SDN标准之争实际是各利益集团间的博弈,是控制未来网络行业的话语权之争。

2、SDN实现方式之争

关于SDN的实现方式,主要分为基于专用接口、基于开放协议、基于叠加网络三种。三种都各具特色,也有着各自的不足,为了后面可以更好的理解各个厂商的解决方案,下面先简单介绍下三种实现方式。

基于专用接口
这个方式貌似现在貌似基本没什么人推了,比较经典的是cisco的onePK,目前cisco的N9K应该是支持onePK和ACI两个模式的,大概就是就是向下兼容以前老的cisco设备的各种系统、向上开放API可以统一管理和配置下发,这种方式严格意义上应该不能算是SDN,因为底层的物理设备的转发、控制层面没有解耦,还是跑着以前的传统协议,只能增加了一个统一控制的功能而已。这个实现方式应该不是未来的方向,这里就不多讲了。

基于开放协议
这个我理解其实就是openflow的解决方案,因为搞opendaylight开源项目的厂商们都在搞overlay的解决方案。openflow就是比较经典的SDN模型,称为狭义SDN。是SDN技术的先驱,主要思路就是重建了流表,如下图,然后再由控制器统一将流表下发至物理设备,物理设备按照openflow流表进行转发。传统的物理设备实质是一个包转发的过程,设备上会有一张转发表,不同功能的交换机/路由器分别对数据包进行二层/三层转发,而openflow交换机会维护一张流表,形成一个数据流的概念,我们看下面的流表其实可以看出openflow交换机上是不会出现传统的mac地址表、路由表这些转发表的。

a network manager think of SDN5

基于叠加网络
就是我们常说的overlay的解决方案,就是三层数据包里面再封装一个二层报文,有点类似于隧道技术,使得二层网络得到一个延伸,通过另一种角度来实现SDN的功能,就现在的行业发展来看overlay的实现方式似乎更容易为大家接受,为什么呢?首先我们要知道openflow存在的问题,和overlay方式相比,它最大的问题是需要交换机硬件来支持,并且目前交换机的ASIC芯片都是为二、三层转发而设计的,对于openflow的流表会有很多问题。面对这个问题无论是重构交换机的芯片还是挖掘现有交换机芯片都似乎难以得到传统交换机厂商的支持。而此时以vmware为代表的纯软件overlay的实现方式是完全不存在这个问题的,这会给用户减少很多开销以及落地的难度,因此overlay解决方案更受到了大多数用户的青睐。但是这也并不代表overlay的方式没有问题,其最大的问题是无法管理非虚拟化环境的网络以及软件转发的性能问题,因此后续cisco提出了ACI这种硬件overlay的解决方案,但是ACI也并不是完美的,后面会具体介绍。

(华丽的分割线,上面说了这么多关于SDN概念性的东西,下面来看看SDN能给我们带来什么)

———————————————————————————————————————————————

四、SDN和我们

1、对于SDN在传统行业落地的思考

不是所有的场景都适合使用SDN。SDN是来解决传统网络无法解决的问题,一个本身就比较简单、比较稳定的网络环境中其实是不太适合SDN的,用了SDN反而是化简为烦,SDN比较适合用于一些会频繁扩展、变化的网络环境中,拿我们现在的网络环境看,掌上生活区比较适合用SDN,而传统业务区则不太适合,所以不能期待全网都SDN化。

要充分的考虑成本效益原则。对于非核心业务区域可能SDN会解决一些问题,但带来的利益可能远低于成本,比如前台区域,SDN可能确实会解决人员频繁调动带来的网管不便,但是目前SDN的交换机一般都是虚拟交换机或者是面向数据中心的高端交换机,价格比较高并且一般都不具备poe的功能,不太适合我们目前的网络环境。

对于我们传统行业,没有必要刻意追求接口标准化或者开放性,我们需要的不是技术标准,而是能解决实际问题的方案。因此我们不能盲目的追求或模仿互联网公司,重要的是找到适合自己的解决方案。

SDN是个高度定制化的东西,很难去模仿或复制其他解决方案。定制化是把双刃剑,它给你带来了灵活性,也将让你放慢落地的脚步,传统行业已经习惯了旧有的网络建设模式,一般都是找某C姓厂商或H姓厂商给出解决方案,而这个解决方案一般基本都是行业内比较成熟的方案,而现在这个模式在SDN的网络建设中可能未必行得通,特别是传统行业研发能力有限,而厂商也未必愿意进行定制化的开发。

对于SDN抱着谨慎乐观的态度。不要把SDN想的太美好,目前在传统行业中的落地可能以及落地效益到底如何还要打个问号,但是我相信SDN是代表着网络的未来,我们需要和SDN一起成长,不求站上浪潮之巅,但求不被淹没在时代浪潮之下。

2、SDN可能给我们带来的现实意义

以下纯属个人意淫,等待未来的测试验证:

基础篇:
1)彻底远离广播风暴,再也不要担心因为失误或bug导致的二层风暴问题,彻底远离灾难。

2)虚机快速无差异部署和迁移,系统室的同事未来再问我们哪一排机柜有没有什么什么网络,告诉他:你随意!

进阶篇:
1)底层物理盒子透明,接入交换机再也不用分什么业务一区、业务二区,服务器随便接入任何的物理盒子,由控制器进行逻辑分隔,大大提高物理硬件的利用率以及可扩展性。蔡叔再也不用飞线了,感动!

2)一台网络设备加电上线后,自动完成相关配置,并同步加入监控、网管等各平台中,全程自动化;

终极篇:
1) 当一个应用需要上线时,在自助平台上直接申请网络资源,申请后控制器自动下发策略(包括QOS、安全、复杂均衡等),自动完成相关网络配置。实现应用对网络资源的自动化按需调用。

当然理想很丰满,现实很骨感,未来SDN到底能做到什么程度,不仅仅要看这个行业的发展,也要看网管对自身网络的驾驭以及挖掘能力,但我想这也正是未来网管的价值所在。

3、适合我们的SDN解决方案

SDN没有最好的解决方案,只有最适合我们的解决方案,那么什么才是最适合我们的解决方案呢,我想这可能要经过长期的测试才能有答案,但测试前我们不妨先了解到底有哪些我们可以选择的解决方案呢。

以下观点均为个人理解,只涉及各解决方案的优点以及个人疑问。

Cisco ACI:封闭系统+硬件overlay
Cisco作为网络行业的领军者,以及我们目前设备的最大供应商,我们理应最先关注。简单说就是APIC作为控制器,控制ACI Fabric里面的物理盒子,物理盒子通过传统方式互联,Vxlan网关在物理盒子上。南向用的是OpFlex协议,北向通过Restful API和各平台集成。

优点:
1、cisco一贯高水准的硬件性能;

2、软、硬件兼管的overlay方案

3、网络自动部署、设备即插即用

疑问:
1、对现在盒子不兼容。

2、ACI到底算不算SDN,这个问题业界颇有争议,有部分人认为ACI没有做到转发和控制层面的彻底解耦,底层的物理盒子上仍然再跑传统的协议,用户无法控制这些协议;也有一部分人认为交换机上不跑传统协议只是openflow的定义并不是SDN的定义,而SDN也不是让用户控制一切,而是让用户控制需要控制的、有价值的东西。

3、关于开放性的问题,首先OpFlex是私有协议,虽然cisco现在在推标准化,但是结果如何尚不知晓,但有业界人士提出,Opflex代表着cisco的利益,其他公司很难愿意跟进;其次由于cisco把持着Opendaylight的大多数的开源项目,业界普遍担心cisco利用开源为名推动自己的私有化协议,但正如上文所说作为传统行业的从业人员,单从技术角度没有必要太追求开放性,如果确实可以解决实际问题,我们就应该叫好,但是是否叫座,可能不单单是技术层面的问题了。

Vmware NSX:封闭系统+软件overlay
Vmware(收购的Nicira)应该是最先提出overlay思路的厂商,通过软件overlay的方式,屏蔽掉上层物理设备的差异,通过NSX Controller向下管理虚拟交换机,向上为各平台提供API

优点:
1、由于Vxlan网关在虚拟交换机上,因此不需要改动上层的物理硬件盒子也可以实现,大大节约成本;

2、纯虚拟化的解决方案加上我们现有的vmware的平台,测试、落地相对比较容易。

疑问:
1、软件转发的性能问题

2、怎么管理非虚拟化的网络,不过vmware正在推出自己解决非虚拟化网络的解决方案

3、由于虚拟交换机也处于vmware虚拟化系统中,容易出现和系统面的扯皮和分歧。

Juniper:开放系统+软件overlay
和Vmware NSX的解决方案类似,也是软件overlay的方式,只是Juniper的控制器Contrail Controller是基于开源项目的,而南向用的是标准的XMPP。并且overlay不是采用Vxlan,而是用的类似MPLS VPN的技术实现。其优点和疑问和Vmware NSX基本一致。

华为:Openflow+硬件overlay
华为的解决方案个人觉得是一个比较折中的解决方案,比较像一个大杂烩,首先控制器是基于Opendaylight的Agile

Controller,南向用了标准的openflow,北向通过Restful API和各平台集成,通过物理Vxlan网关的方式来屏蔽物理设备的差异,同时有可以共管非虚拟网络。

优点:看上去很完美,使用开放协议解决了cisco封闭的问题,硬件Vxlan网关解决了vmware无法管理非虚拟化网络以及软件转发性能问题,并且只需要购买新Vxlan网关,原来的硬件盒子可以不变。

疑问:
1、什么都有意味着网络会变的复杂;

2、由于南向用了openflow,所以虚拟交换机一定是华为定制开发的来支持openflow协议的,其他虚拟交换机是否可行?

3、冗余和可靠问题,这个解决方案中,AC和Vxlan网管都很重要,不能有一个出现问题,否则都会影响数据转发。

开源解决方案:openflow+白盒交换机
这个解决方案基本都是互联网公司在推的比较多,他们中强大的如google和facebook之类都基于openflow自己开发白盒交换机,又或者购买一些新创公司的白盒交换机,这些交换机都是做了定制化的硬件重构来满足openflow的一些流表问题。这种方案是一个彻底将控制和转发平面分离并且彻底将物理设备屏蔽的方案,所以主流厂商是比较抗拒的。

优点:
1、openflow协议相对较成熟,得到了大多数厂商的支持;

2、将使用户彻底摆脱厂商的束缚,节约了很多硬件成本。

疑问:
1、传统行业难以落地,由于openflow只定义了南向,意味着要自己要去选择一款支持openflow的开源控制器并自行进行定制开发,并且openflow也没有定义一些网管方面的标准,这些都需要借助一些自研或者第三方的平台来实现,这些对于研发能力较弱的传统行业都是非常艰难的。

2、老的设备都不支持openflow协议,需要重新购买新的盒子,此外现有盒子的ASIC芯片对openflow的多级流表支持的也存在一些问题。

总的来说,目前主流的SDN解决方案就是openflow以及overlay两种,openflow+白盒交换机的方式更代表了大互联网公司以及运营商的诉求,对于传统的行业个人认为overlay的方式更容易落地一些。

4、知识储备
SDN目前依然是一项正在快速发展和迭代的技术,但显然已经成为了未来网络发展的必然趋势,对于SDN技术我们需要保持长期的关注以及足够的知识储备才能跟的上时代浪潮。

SDN专业技术储备
我有的一些资料都已经放到了共享中,还可以登录www.sdnlab.com,这个网站比较不错,收集了很多国内外大牛的技术文章,还会有一些技术的实践文章。

还有就是关注一些大牛的微博和知乎。知乎上有个如何去研究SDN的文章很赞,链接如下:http://www.zhihu.com/question/21834316

相关书籍方面我已经买了很多了,但是觉得书上的东西基本大同小异而且比较滞后。

实验、测试
厂商的解决方案我们会请各个厂商配合测试,但是厂商基本都是闭源的解决方案。如果要做一些开源的实验,基于openflow的可以使用Ryu+mininet,网上用这个来研究SDN的人很多,链接如下:

http://osrg.github.io/ryu/

http://blog.csdn.net/neterpaole/article/details/8512106

如果是基于opendaylight直接去官网应该就可以下到测试软件,这个貌似用人很少http://www.opendaylight.org/

其他技能
linux:大多数的控制器都是基于linux的,需要熟悉常用的linux指令。

编程能力:在控制器上实现各种自动化运维必须拥有一定的编程能力。
转载自:简书-小七叔叔

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。