2016-02-21 20:47:47
来 源
云头条
网络通信
盛科的张总给我们分享了他目前看到的SDN最新动态,一些技术流派,一些SDN应用,特别是在云计算里面的应用.

一.SDN现状和一些误解

我今天主要分享一下我目前看到的SDN最新动态,一些技术流派,一些SDN应用,特别是在云计算里面的应用。SDN在13,14这两年被炒得非常火,到了今年,感觉声音边小一些了,所以很多人在问,是不是SDN不行了?我的看法不是这样的,我认为按照Gartner的技术成熟度曲线,现在SDN走到了谷底之后,开始向上。

但是现在业界对SDN仍然存在很多误解,我这里得把它澄清一下。

盛科网络张卫峰SDN分享

最常见的一个,尽管一再有人来澄清,但是还是会被误解,就是总是把openflow等同于sdn,一说到sdn,就以为是openflow的实现。如果非要说openflow=sdn,那只能说这就是狭义的sdn。广义的sdn则是控制跟转发分离,有开放的API和集中的控制器。这是广为接受的定义。

第二个误解,总是有人觉得如果用了sdn,就是一个或者几个控制器在那里控制一切,所以常常会质疑,这样sdn网络如何scale如果真的sdn是这样的话,那确实没有可扩展性。但是实际上,SDN并不是要让控制器去控制一切,而只是让用户可以通过控制器去控制他想控制的东西,对于对那些业务无价值的东西,完全没必要去控制,而可以仍然靠传统协议去做。

举了个例子,在数据中心出口,相对公网IP的出入两个方向进行限流,向下的方向,可以有很多个端口,用户使用SDN想得到的价值,只是限流,至于限流之后,报文如何转发,其实他并不想去控制,这个时候,怎么办?让传统的mac学习去做。

再比如,在网络虚拟化的应用里面,对用户最有价值的部分,需要sdn去控制的部分在哪里?在边缘,边缘承担着识别VM,识别租户,创建虚拟网络的重任,而核心汇聚呢?只是一个报文转发而已,那这种情况下,你为什么要用SDN去控制核心汇聚呢?没必要。

然后相关的第三点误解,跟第二点有关系。就是认为SDN交换机,必须是交换机上没有任何控制协议,所有的控制都在控制器上,但实际上,很多场景,在交换机上仍然可以有控制协议,只是它需要提供出接口来,让用户去控制想控制的东西。

用一个类比来说明,人体有植物神经和动物神经,前者比如呼吸,心跳,后者比如举手投足,如果前者也要靠大脑来控制,那肯定来不及。SDN也是同样道理。

第四点,有人认为OpenFlow交换机需要任意灵活才行。但是实际上,既无必要,也不可能。Openflow交换机的灵活性,其实是体现在它可以满足各种不同场景的需求,但是在任何一个特定场景下,其实不需要任意灵活,某个特定场景,总是有固定的模式,比如匹配特定的字段,做特定的动作。

基于这样的一个事实,其实可以通过组合现有的转发表项,来支持不同的openflow场景。并非说一定要SDN芯片才行。当然,如果芯片能够对SDN支持得好,那可以支持更多的场景,有更小的限制。

第五点,现在一提到云计算网络虚拟化,说用到了SDN,马上就有人会问能跟不同SDN交换机互通吗?或者能跟Ryu, ODL, FL, ONoS等控制器对接吗?答案是一般情况都不能。因为对于SDN来说,它一定意味着基于场景的定制,不可能随便拿一个控制器,随便拿一个SDN交换机,就能支持一个SDN应用,特别是网络虚拟化这种复杂应用,一定是要特定的控制器,或者基于商业控制器做很多定制,还要对SDN交换机做一些定制。那种随便拿一个控制器和交换机就可以直接用的想法是理想化,不现实的。

我这里说的都是硬件SDN交换机,不包括纯软件的,如OVS。

二.SDN交换机的各种实现流派

其实误解还有很多,我就不去一一列举了,接下来再说说SDN交换机的各种流牌。

  • 第一种实现,就是纯openflow的实现。不支持任何传统协议。像我们的V330/V350/V580,目前就是这样。很多厂商都宣称实现了openflow1.3,但是实际上能力差异很大,这主要不是设备商的能力差异,而是芯片的差异。但是很多人不知道,以为买了个宣称of1.3的交换机,就真的都能支持所有能力了。实际上能支持到50%就差不多了。比如我们在一个客户那里竞标,客户的一个要求很简单,就是要求匹配IP后能修改IP,这是openflow1.0就要求的。我们的设备报价很高,对手的客户关心很硬,但是最后这个标被我们拿到了,为什么?就是因为我们能支持修改IP,对方不能。为什么会这样?因为我们用了盛科自己的能很好支持SDN的芯片,对方用了商业通用芯片。而这个需求是客户刚需,没得商量。
  • 第二种实现,是hybrid,所谓的混合模式,就是交换机转发面先进行openflow的pipeline处理,如果openflow对这个报文不感兴趣或者没有直接丢弃也没直接转发掉,就继续走后面的普通二三层处理。比如我在前面举得那个例子,先使用openflow进行限流的处理,处理完之后走普通二层mac转发,学习。应该说这是第一种的超集,OVS就支持这种处理。我们很快也会支持。
  • 第三种实现,则是完全跟openflow没关系,交换机内部仍然是传统交换机,有各种传统二三层协议。但是比传统交换机多了一点,它能够提供出open API来,这里的Open API有很多种,而且大多数都是私有的,比如rest API, JSON RPC API, netconf, XMPP。比如juniper的contrail,就用XMPP, CISCO的ACI,是用它自己私有的一个协议opflex。Arista用JSON RPC。我们也支持JSON RPC,我们给客户做得云方案中,有一套方案就是用了JSON RPC。 这种方案有一个很大的好处,就是不需要考虑跟传统网络交互的问题,而又可以通过API控制。只是它不是标准的,这一点有人不喜欢,但是更多客户无所谓,能解决问题就行。

基本上总结下来,就这三种,其他万变不离其宗

三. SDN在云计算之外的一些应用场景

接下来我说一下SDN目前的一些主流应用场景,先说一个相对简单一些,但是现在很多大公司都在做的,就是在广域网的应用。

大家所熟知的一个就是Google的B4网络,用SDN来做流量调度,带宽优化,提高利用率。这是比较复杂的,现在很多运营商都在搞。

还有简单一些的,比如一些IDC在全国有很多机房,一些客户租用了他们多个机房,需要连在一起,二层互通。还要能限制带宽。现在就有IDC要用SDN来做这事,有的已经做了(比如我们一个客户澳洲电信)。用户可以自助服务,自助申请互联,自助调整带宽。光跟我提过这个需求,让我们帮他们做的IDC就有5家,现在电信要建立除了移动和固网之外的第三张网,就是DCI网络。

还有一些小的应用,比如基于SDN的方案,来做扛D攻击,入侵检测服务器检测到攻击之后,通过控制器给SDN交换机下发流表,同时控制边界路由器,将流引到SDN交换机,进行流量清洗,这是我们日本一个客户的做法。 国内还有一个一线的IDC客户,玩法则另有不同,说起来比较复杂,有兴趣的后面可以细聊。这里我就不多说了。

还有一些边边角角的奇怪的应用,比如我们一个客户,因为视频接收设备接在网络里面,收到一些报文的干扰,导致有马赛克。他们又查不出原因在哪里,索性就在链路上,串一个SDN交换机,这个交换机把需要的视频节目放过,其他报文全部丢弃,然后问题就解决了。

四. SDN在云计算里面的应用场景

前面把一些次要的场景都讲完了,最后我就专门来讲一下,SDN在云计算里面的应用。这是重头戏,也是目前SDN应用最广泛的领域。

说到SDN在云计算网络虚拟化里面的应用,也有误解。一说到SDN,有人马上就想到SDN交换机,但是其实,目前的各种网络虚拟化方案,有很多是用纯软件的方案来做的。

典型代表:OpenStack neutron原生态方案,Vmware的NSX, MidoKura公司的MidoNet,Nuage公司的方案等等。

他们用的都是纯软件,网络虚拟化的所有动作都发生在服务器,国内的比如青云,也是如此。 而且,并非这些方案都是用到了OpenFlow,基本上没有用纯OpenFlow的,就算用了OpenFlow,也都是结合了传统的东西。

有的方案压根跟openflow无关,比如Nuage,Juniper Contrail。当然neutron原生方案,L2部分确实用到了openflow,而且是很复杂的多级流表。华为的dragonflow也是,而且华为的dragonflow是L2/L3都用openflow,不像neutron,是个混杂品。

这里还有一个说法需要矫正,就是有人把openflow跟overlay对立或者并列,其实这个不对。Overlay只是一种组网方案,openflow是一个控制协议,所以实际网络中,可以是这样的:控制器通过openflow协议控制vSwitch来构建一个overlay网络。

纯软件方案大家实现各异,细节没办法在这里讲,这个得另外写文章。我后面再讲一下,硬件SDN在网络虚拟化中可以起到什么作用。

硬件SDN实现网络虚拟化的典型代表是Cisco。

它的ACI就是这样一个方案,其他一些设备商或多或少也都有一些自己的方案。但是也有设备商只推软件方案的。

当然,我们公司也有自己的基于硬件SDN的一套方案,目前已经在多家客户那里部署或者POC了。 很多人都知道Ucloud用了我们很多SDN设备,这个涉及到客户机密我不好多说,只能说一点,UCLoud有它自己的用法,而且实际上,我们已经正式部署的那些客户,每家都有不同,都体现了云计算对SDN的一些需求,我后面一个一个列举一下。

使用硬件SDN交换机做网络虚拟化,大概的思路就是,把tunnel overlay的工作,做到TOR交换机上,交换机上可以来识别VM,识别组网,push/pop tunnel header,如果再进一步,还可以做一些限流,security group(静态,无状态的)。如果做得更好一些,可以把分布式L2/L3都做在硬件SDN TOR。每个TOR都是它所挂的VM的L3 GW。这就是所谓的分布式路由。

但是硬件SDN来做这个网络虚拟化,有不少限制,第一个,流表数量没有软件那么大,当然,我们计算过,应该够用。 第二个,有些工作做不了,比如NAT/LB/FW/VPN等等,这些仍然需要专门的南北向Internet GW,只不过SDN TOR仍然可以帮这些GW来offload tunnel。这样有些硬件防火墙不支持tunnel的话,可以跟SDN交换机一起工作。

这是一个概览。下面我就分别说一下几个需求点,或者说场景。

硬件SDN做网络虚拟化的第一个需求点

是希望通过SDN交换机来offload一些工作,提升性能。我们自己做过对比测试,确实比原生态neutron提升很大,而且很重要的一点是,性能恒定。不像我们测试纯软件方案的时候,每次测出来的结果都不同,挺郁闷。它能提升性能的原因主要有着几个 1)把tunnel工作放到交换机,网卡的TOE模块就仍然可以发挥作用,做TCP分片加速 2),tunnel操作本身也消耗CPU 3)如果能把一些复杂流表操作也放到TOR,那就更好了。

当然现在也开始有一些网卡可以做vxlan,具体效果如何我没试过,不知道。

第二个场景,用SDN交换机来做P+V

所谓的P+V就是物理裸机接入到虚拟网络,因为在纯软件方案中,vxlan可以终结在vswitch,但是对于物理机,没有vswitch,所以最好的方案其实就是把vxlan终结在SDN TOR,SDN TOR作为tunnel gateway。这种方案包括vmware都支持,支持跟一些硬件SDN TOR对接,所以可以认为是一个刚需。

我们有四五家客户都是因为场景1和2找我们的。

第三个场景,使用SDN来支持service chain引流,特别是跟云安全结合。

在传统网络里面,要做安全,很好做,安全方案跟网络是松耦合,只需要在出口设备旁挂或者串接FW就可以了。但是到了云里面,一切都变了。

我至少聊过国内20家以上做云安全的,大家都跟我讲了同一个需求,如何在云里面,把东西向流量引导vFW, vWaf,或者硬件FW上去。

为什么这个这么难做?因为在云里面,一方面,VM都是动态的,但是它应用的安全策略却是固定的,那么你如何做到策略跟随?策略跟随是思科ACI一直强调的一个卖点。第二个原因,现在很多云使用tunnel overlay,VM的原始报文,在服务器内部就封装到tunnel里面去了,对物理网络不可见,这种情况对引流就造成了更大的困扰。刚刚一个小时之前,国内一个做安全的兄弟还在问我这个问题,说如果解决了这个问题,他们可以去影响政务云标准。

如果使用SDN TOR来做tunnel overlay,那么这个问题就会容易多了,因为SDN TOR可以来识别VM,识别报文,可以接受来自控制器的安全策略,可以在SDN TOR和安全设备之间建立起tunnel连接,把流引过去。

当然,这个从原理上来看,是没问题,但是实际操作的时候,实现还是会比较复杂。但是我们看看思科ACI的宣传点就知道,这肯定是一个很好的路子,关键在于你能把它做得足够好用。

第四个场景也很奇葩,我们有三家客户(据合作伙伴说其实还有别的客户也有需求),是因为这个原因找我们的。

这里面,有两个客户,要解决的问题是,他们自己或者他们的客户有很多Vmware的传统产品(不支持NSX),他们现在又引入了KVM, XEN,要跟Vmware混合组网,而且要使用vxlan。但是NSX太贵,不想买NSX。那怎么办?业界对此也有方案,有人是在Vmware计算节点里面起一个VM,在这个VM里面实现了一个vswitch的功能,所有同服务器内的其他VM要往外发包,就先到这个VM里面绕一圈,比如我看HP的helion就有这样的做法。但是这种做法的问题显而易见,性能太差。

还有一个客户,因为他们用了Power服务器,而且还有AIX,里面的vSwitch更是简单的要命。也是想支持tunnel overlay。

无论是前者还是后者,要解决的问题是一样的。所以我们给出的方案就是使用SDN TOR,在vswitch里面只是做基本的vlan,这个不用NSX就能支持,power自己也能支持。但是报文送出来之后,SDN TOR上把vlan转换成vxlan VNI。这样就可以很好的解决这个问题。我们有一个国内给广电领域提供服务的客户,就用这个方案给各个电视台做。电视台用了大量Vmware。

基本上云计算的场景,主要就是这些。如果非要再加一个的话,那是一个小场景。 一些IDC,客户买了多个公网IP,然后是每个IP给一个带宽,比如10个公网IP,每个给10M带宽,坏处是彼此之间不能共享,然后需求就是在出口处,放一个SDN交换机,把这些公网IP捆绑起来共享带宽,用户就很happy了,而且不能是手动来做,是要跟云平台联动。

五. 问答环节

Q:是否觉得云方面或是虚拟化方面的sdn的需求比来自其他的越来越多?
A:对,需求特别多。特别是很多做云的公司,没有网络人才,对网络比较恐惧,所以更容易有需求。这里面有些其实是伪需求,只是因为不懂,而有些是真的

Q:盛科的service chain方案,如何标记流的?
A:这个一般是根据五元组

Q:重叠地址五元组可能会失效吧?
A:VNI+五元组

Q:感谢大神的精彩分享,关于DCI,如果木有mpls骨干网,怎么解决?
A:现在也有用GRE或者VxLAN的,我觉得没必要非用mpls

Q:不是需要组播支持吗?
A:既然说到这个问题,我就再多讲一点,这里存在另外一个误解
很多人都认为vxlan跟nvgre的区别是vxlan需要组播,这完全是无稽之谈。两者都可以不需要组播。两者的区别只是在于第一,封装格式不同,前者是UDP,后者GRE,第二用来做负载均衡的方式不同,前者把hash值放在UDP source port里面,后者把hash指放在GRE Key里面,除此之外就没区别了。哦,不对,还有区别,前者是思科,arista等推的,后者是微软,阵营不同:)

Q:听人讲华三的说可以不用NSX直接vmware接Sdn tor支持 vxlan,盛科有这个方案?是否可行
A:见我上面第四个场景

Q:你们的产品有用来解决裸机和虚拟网络打通的商用案例么?
A:见我上面第二个场景。

Q:有集成的管理方案吗?我碰上这个case了,管理方案太复杂了,好几层
A:这个是我们客户自己做得管理平台,如果需要,我可以帮忙问问他们卖不卖

Q:前面提到某用户希望用盛科SDN交换机修改IP地址,能介绍下需求吗?是要做NAT?thx
A:这里有很多个场景,日本那个客户,是做完流量清洗之后,把目的IP改掉,原路返回去,避免对端再把它送回来,然后在内网络里面这个被修改过的IP可路由,这样避免使用tunnel。
还有是做简单的负载均衡,类似LVS,只是不需要有状态,不需要到7层
还有一个则是广电把外部的节目源统一编址。

Q:能介绍一下sdn交换机的硬件架构么,是ASIC还是NPU
A:对于交换机来说ASIC是主流。华为有NPU,但是这个只能作为补充,不能作为主力。成本,功耗,吞吐量都是问题

Q:为什么不用NPU去做?ASIC不够灵活
A:成本太高,研发成本也很高,如果市场足够大,需求足够刚性,那说不定也会有人做,呵呵。否则都是吸引眼球宣传宣传。

Q:盛科交换机是不是已经有出方向openflow流表支持?
A:这个是可以做的

Q:问下抗D场景,用的SDN交换机是纯openflow的还是hybrid?检测到攻击模式=》切换OF下流表drop……
A:对,用流表来做清洗。 关于这个案例,我们那个日本客户写了三篇非常详细的帖子,发在网上,把来龙去脉前因后果都写了,你们可以去看看。连测试步骤都写得很清楚。Http://packetpushers.net/centec-v330-my-kind-of-openflow-switch/
我们国内还有一个大的IDC,用法跟这个日本的不同,但是目前我还不能透露。

Q:检测DDOS用什么?In-Mon?
A:检测跟我们无关,我也不知道他们怎么做的。

Q:刚才介绍的分布式路由,有案例介绍下吗
A:有的啊,都部署了几个了。理论上就是把DVR那一套做到SDN交换机。

Q:说到的国内服务商DCI互联自服服务,自助调整带宽等是直接你们平台上(cloud manager),还是跟用户OSS API?
A:DCI这个跟云没关系,是目前他们是给客户提供了web界面,用户可以自己去操作,你们可以去看看pacnet的服务,如果是他们用户的话。

Q:dvr做在tor sw上,物理tor sw的冗余是如何解决的?
A:这是个好问题,现在是使用mlag,确实这里处理起来比较复杂,需要复制

Q:Pacnet的案例,很好奇你们怎么跟Vello集成
A:Vello的平台,集成了我们的交换机和另外一个公司的光传输设备,给客户提供整体方案。我们帮他们做了不少定制。

国内现在缺少像vello这样独立的第三方SDN应用和服务提供商。魏总的未来网络准备朝这方面努力

作者简介:张卫峰,盛科网络SDN&云计算CTO,《深度解析SDN-利益、战略、技术、实践》一书作者。数据通信和芯片设计领域资深专家,有十几年的网络实践经验,对SDN、网络虚拟化、传统二三层交换机、数据传输设备,从管理面到协议控制面一直到芯片转发面,都有着深刻的理解。
转载自:云头条

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