微信号:infoqchina

介绍:有内容的技术社区媒体

别管定义啦:SDN落地的实践与思考(上)

2014-12-05 17:45 张卫峰


半年之前写过一篇文章讨论SDN的本质,当时就说这会是一个系列文章,后面还要写一下SDN的落地。这一等就是半年多,其间有朋友问过我为什么还不写——不是我不想写,是有些问题还没想清楚。直到现在我也不敢说我完全想清楚了,但是毕竟有了更多的实践,实践过程中不停地思考,加上不断有媒体朋友找我约稿,我想还是写一写吧。这篇文章可以看作是对我三年SDN工作历程的一个总结和反思。我在这篇文章会回顾一下人们对SDN定义的争议,SDN的落地实践,阻碍SDN落地的一些障碍,给出一些对SDN落地的建议和看法。


SDN的定义回顾


现在大多数人对SDN的定义是控制跟转发分离+开放的编程接口,包括Gartner也是这样的定义。Gartner的数据中心云计算行业分析总监曾绍清告诉我,他们认为思科的ACI不是SDN,因为ACI并非是控制和转发分离,它只是把策略管理的功能分离到了控制器上,控制协议(OSPF、BGP等)仍然运行在交换机上。但是我曾经在国外著名的通信技术媒体lightreading上看到他们综合一些专家的意见给出的定义,该定义里面只提到了开放的可编程接口以及由此带来的业务敏捷性。就我个人的观点来看,我更倾向于lightreading的定义(具体请参阅我的第一篇文章)。不过,正如青云CEO Richard接受InfoQ采访的时候说过的,每个人对SDN都有不同的定义,这个并不重要,我深以为然,重要的是SDN带来的价值。所以,以后大家不要把精力浪费在讨论SDN的定义上吧。


SDN在网络虚拟化中的应用


总有人说没看到SDN有落地案例,但是你去看一些国外专业的咨询机构,总能看到他们的报告中,SDN的市场份额在逐年增加,且趋势向好。是有人在撒谎吗?No。


咨询报告中说的SDN市场份额在增加,主要是强调SDN现在最大的一个应用场景——网络虚拟化中的应用。很多人说没看到SDN有落地案例,那是因为他们潜意识里面只把控制器+硬件SDN交换机的应用认为是SDN应用,云平台+虚拟交换机他们认为不是SDN。而事实上,以VMware的NSX为代表的网络虚拟化的应用早已经是被广泛认可的SDN的典型落地案例。


目前看到的基于SDN的网络虚拟化解决方案有以下三种:


1,纯软件方式,以VMware的NSX为代表。除了NSX,还有Juniper的Contrail、Midokura的MidoNet以及Vyatta、Nuage、Plumgrid等公司的商业网络虚拟化方案。这些公司的实现方式都不太一样,但是都在不同程度上用到了SDN技术。有的只是把一些策略管理的东西放在控制器上,转发表项还是由虚拟交换机自己来生成,而有的则是控制器来下发转发表项。而目前影响最广泛的OpenStack的网络组件Neutron,则两种方式都支持,Neutron更是一种标准的SDN架构。由于本文的目的不是介绍技术细节,所以这里就不深入展开来讲了。


2,硬件方式,以思科的ACI为代表,即将网络虚拟化在硬件中实现(当然也不排除会用到vRouter)。


3,软件+硬件方式。盛科网络推出的SDN方案即属于此类(Arista也有类似方案),本质上它是一个软件方案的思路,只是把部分对性能影响最大的操作offload到硬件SDN交换机,可以认为是一个超级网卡。并且它为NSX之类的软件方案提供了SDN交换机作为Tunnel Gateway来满足物理服务器跟虚机混合组网的需求。


华为和华三也都相应的都有自己的解决方案,只是目前看到的他们都是推整体云计算解决方案,没有把网络部分整出一个方案来单独卖。


无论纯软件还是硬件的SDN解决方案,在云计算数据中心里面,应用的越来越广泛,所以如果要谈SDN的落地,这是目前最大的,最不容忽视的一个。


SDN在别的领域的应用


除了在网络虚拟化领域的应用,SDN交换机在别的领域也有一些应用,但是从应用广度和影响力来看,都比不上在网络虚拟化中的应用。从我们自己以及国外一些案例来看,落地的SDN的应用,其驱动力主要可以归结为两大类:业务层面灵活性的需求,转发层面灵活性的需求。前者的价值要远大于后者。


一、业务层面灵活性的需求


这主要是强调可编程。通过开放的可编程接口,提供给用户原来无法获得的对网络配置管理和策略部署的灵活性控制。前段时间著名的运营商亚太环通(Pacnet)宣布在天津的一个IDC正式启用,他们宣称里面使用了SDN技术来为用户提供自助调整带宽的功能,其实该功能早就部署在了他们新加坡、澳大利亚,香港等国家和地区的其他数据中心。该功能是通过定制化的SDN交换机实现的,其中的千兆交换机是盛科提供的。这是一个很典型的体现业务灵活性的例子。用户可以在他们提供的一个界面上,随时按需修改自己的出口带宽。而且不仅如此,一个用户可能租用了他们多个数据中心,通过SDN创建的MPLS隧道把用户在多地的数据连通之后,可以通过SDN动态调整这些隧道的带宽,一旦出现故障或者拥塞,还可以自动重新选路。没有SDN,要做到这一步很难。


但是大家更关心的是SDN在企业网里面如何用。并不是所有企业网都适合使用SDN,什么样的企业网需要用SDN呢?这个问题后面再分析。国外一个著名设备商N,他们有挺多的SDN案例,特别是有些案例规模还是较大的,不像某些公司挂羊头卖狗肉的宣传,我至少知道他们有一个案例是很值得拿出来讲一讲的(这个案例在国外网站上也有介绍)。他们给某电视台的一个新的网络进行了SDN化设计,该网络有一个特点,就是拓扑和策略都是灵活易变的,比如这个星期是为一个大型演出节目准备的,而下个星期就变成为一个体育节目准备,如果没有SDN,他们需要靠人工去插拔线修改拓扑,重新划分物理和逻辑网络等,非常麻烦,在人工很贵的国外,这个问题特别突出。使用了SDN之后,整个物理网络基本不动,每次就依靠SDN将网络重构。这个案例还包括无线AP,也是SDN化的。而且值得关注的是,他们并非全部使用SDN,而是一个混合的网络,既有SDN,又有传统的。即在需要SDN的时候SDN,不需要的时候就用传统,深得SDN的精髓。


在我们碰到的案例中,也有一个复杂度没这么高,但是需要对网络灵活控制的。该网络管理员说他管理了一个较大的实验室,每天都有人在里面做不同的实验,对这些不同的人,网络中都需要有一些不同的安全控制策略,每次都去找他该配置,他不胜其烦。而这个时候,如果建立一套用户权限体系,用户可以自行登录申请,一旦认证通过,根据他的权限,控制器可以自行下发安全控制策略到交换机上,SDN的业务灵活性充分体现出来。


二、转发层面灵活性的需求


这主要是针对一些非常特定的场景,主要是为了匹配或者修改特定字段,通常是传统交换机不支持的(其实芯片也许能支持,只是交换机系统没做)。这些场景我们也碰到不少,比如用来做DDoS防攻击(日本Sakura Internet的应用),用来做负载均衡+NAT,用来做TAP应用(价格是专业的TAP设备的至少1/5),用来将PPPoE跟IP区分开并灵活控制等等。还有一些用户提出来过,但是需要辅助FPGA或者NP才能做到的。这类应用主要的灵活性体现在转发面上而不是控制面。


SDN落地的障碍


硬件SDN的落地进展并不顺利。虽然现在慢慢有了一些更多的案例,但是离规模部署还很远。我跟Gartner的曾绍清一起探讨过原因,曾说Gartner经过调查,形成了一些他们的看法。


Gartner的观点认为,以下几个问题阻碍了SDN的落地:


1,厂商的直接支持而欠缺传统渠道的支持


2,SDN的革命性变革而使销售难度大增,传统厂商偏向销售Ethernet Fabric等容易接受的产品


3,SDN的用户价值较难从单一产品成本分析中体现


4,用户的开发团队开发的东西,运维团队不接受


我个人觉得Gartner的观点都很有道理,相对来说看得比较宏观。我根据我们的客户交流和项目实践中碰到过的一些问题,也谈谈我的看法。我的观点其实跟Gartner有不少相通之处,算是一枚硬币的两个面。我认为一个用户要想把SDN在他的网络中落地,必须同时满足这三个条件,缺一不可。而现实中,这三个条件同时满足的不多,这也导致了SDN的落地缓慢。


1,用户必须清楚地知道自己网络中存在的问题,然后带着这些问题来寻找方案。我经常碰到一些人问我,你帮我看看SDN能用在我们网络中什么地方?这种用户是没办法让SDN落地的。SDN是用来实现用户的业务敏捷性的,不是用来全面替代传统网络的,如果你都不知道自己有什么问题,怎么引入SDN?我碰到的最终能落地的,都是明确知道自己网络中的问题,迫切想找方案来解决的。


2,用户做决策的人必须要足够有魄力,而且能够协调开发部门(或者第三方开发)和使用部门之间的关系。某互联网大厂告诉我,他们的自研交换机项目之所以能成功,全面在自己的网络中替换商用交换机,就是因为他们的研发和运维都归一个领导管,这个领导要求运维部门必须用自己研发的交换机,有问题也在所不惜。而其它大厂之所以进展不顺,则恰好相反,研发部门和运维部门彼此独立。SDN这里也是如此,如Gartner所言,SDN的革命性变革,必然导致传统运维使用上的不适用,人都有使用自己习惯的东西的惰性,如果没有强制命令来保证运维人员使用新的工作方式,确实会比较难推。盛科就给一个互联网大厂做过一个SDN项目,该项目很顺利地解决了一些核心技术需求,但是反倒是在推到运维那里的时候碰到了障碍。其实那些障碍可大可小,如果严格按照传统运维规则去要求,那就会阻碍重重,但是如果愿意给与新生事物足够的耐心,让它在使用中慢慢完善,那就可以顺利推行下去。这都取决于决策人员的魄力和权责范围。


3,用户的研发部门或者第三方研发人员必须有足够的研发能力,能够有充分的理性选择合适的技术。整个SDN体系中的核心是什么?是交换机吗?是控制器吗?都不是!核心是应用程序。在SDN中,用户自己或者用户委托的第三方必须有足够的能力去研发上层应用软件,必须知道这些应用软件如何去通过控制器控制交换机。很多人通常会问SDN交换机厂商:你们除了交换机,还有控制器卖吗?我假设我们有,你拿去就能用吗?不能!因为设备商提供的控制器不知道用户要用来做什么应用,所以它实际上提供的只是一些基础API以及实现这些API的内部逻辑,如何用这些API,那是用户或者用户委托的第三方需要去考虑的事情。


国外的SDN为什么部署得比国内多?至少我看到的原因之一是,国外有一些独立的第三方的SDN应用提供商,他们有能力架设起最终用户和SDN设备商之间的桥梁,把用户需求和SDN设备以及控制器结合在一起,打包交付给用户。比如前面讲的亚太环通的SDN应用,就是一个第三方软件提供商把盛科SDN交换机、另外一个厂商的SDN光传输设备、开源的控制器加上他们自己的应用程序结合在一起,一起交付给客户。而且他们进行技术选择的时候,非常理性不会刻意地去追求标准,他们追求的是满足客户需求,所以有不少私有化的扩展。盛科推到欧洲、日本、美国去的SDN设备,也都是因为有强有力的第三方合作伙伴或者客户本身有强有力的研发能力。否则SDN交换机只能在实验室玩玩。我也很遗憾地看到过一些反面例子,本来他们或者他们的客户确实有SDN的需求,但是他们自己不愿意或者没有能力去针对控制器做二次开发,也不愿意花钱去请第三方开发,而在没有量的保证的时候,设备商也不愿意去做太多定制开发,最终导致落地受阻。





 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 Ramdajs函数编程 2016年麦肯锡(McKinsey)全球数据,物流,服务和金融的研究报告 Cashew——轻量级REST框架 一个通信工程师的爱情表白! Vue.js:60分钟组件快速入门(上篇)