厦门做网站优化的公司,wordpress自动提交百度,有了源码怎么搭建网站,做网站全体教程SDN的技术已经发展了好几年了#xff0c;而云计算的历史更长#xff0c;两者的结合更是作为SDN的一个杀手级应用在近两年炒得火热#xff0c;一些知名咨询公司的关于SDN逐年增加的市场份额的论断#xff0c;也主要是指SDN在云计算网络中的应用。 关于SDN在云计算网络中的应… SDN的技术已经发展了好几年了而云计算的历史更长两者的结合更是作为SDN的一个杀手级应用在近两年炒得火热一些知名咨询公司的关于SDN逐年增加的市场份额的论断也主要是指SDN在云计算网络中的应用。 关于SDN在云计算网络中的应用目前有两个主要的流派一个是VMware为代表的”软”派另外一个则是以思科为代表的“硬”派。前者主要是指整个网络虚拟化方案的核心逻辑都是实现在服务器中的Hypervisor之上物理网络只是一个管道;而后者则是指网络虚拟化的核心逻辑实现在物理网络中(主要边缘的机顶交换机即TOR)只有交换机实现不了的部分才放到服务器或者别的专用设备中。这两种方案各有千秋也各有粉丝。 但是世界从来都不是单极的也不是两极而是多极现实网络中有很多各种非常规的需求这些需求并不是靠这两个方案就可以解决的或者说虽然他们能解决但是不是最优的包括实现难度、性能和价格。作为一个长期使用硬件SDN为用户提供解决方案的从业者我在这里想来介绍一下现实世界中硬件SDN交换机是如何来解决一些云计算网络中的特定场景需求的这些需求无论公有云还是私有云都可能会碰到私有云(包括托管云)居多因为定制的需求在私有云中更常见。 需要特别说明的是这里的这些场景用思科的ACI都可以做到因为本质上ACI的思路也是用硬件SDN来支持网络虚拟化。但是由于很多用户因为各种原因并不想使用思科ACI(如价格太贵、厂商锁定、国产化趋势等)所以他们需要另外的方案(我并不是说ACI不好相反纯粹从技术的角度我个人很欣赏ACI)。 云计算网络对SDN控制器和交换机的定制要求 很多人对SDN交换机在云计算网络中的应用都会有一些误解。最典型的误解有两个一个是总有人问你们用的控制器是哪个控制器?能跟OpenDayLight/Ryu/ONOS对接吗?另外一个则是觉得只要拿一台SDN交换机来就可以支持云计算网络场景无论是哪个厂商的哪种SDN交换机。之所以有这两个误解是因为很多人还没理解到SDN就意味着跟应用相关的定制以为随便拿着一个通用的东西就可以来做云计算网络了。云计算网络作为一种特定的SDN场景其控制器通常都是专门针对云计算这个场景设计的功能单一就是完成云计算网络的需求甚至都可能没有显式的控制器而是隐藏在云平台里面(比如直接实现在OpenStack Neutron Server中的代码逻辑)。这种场景中的控制器没法用作通用SDN控制器反之通用SDN控制器也没法直接用于云计算网络场景。至于第二个问题为什么说是误解那也就很容易理解了连控制器都需要为云计算场景定制更不要说SDN交换机了。所以并非是随便拿一个SDN交换机过来就能支持云计算网络场景而需要有专门的深度定制。比如我们盛科网络就专门针对这个场景设计了相应的控制器和交换机功能。 场景1使用硬件SDN交换机提升性能 在这种场景中用户使用Tunnel Overlay的方式部署网络虚拟化。但是由于vSwitch对Tunnel(VxLAN或者NvGRE)的操作对性能影响比较大(吞吐量偏低延时偏大抖动比较大具体影响大小要看每个公司对它的实现和优化)所以这个时候可以借助SDN TOR交换机来进行tunnel offload把对性能影响比较大的tunnel操作offload到SDN TOR交换机上其它所有操作保持在服务器中不变逻辑上可以认为SDN TOR交换机是vSwitch的扩展。如果更进一步则可以把分布式东西向L3 Gateway也放到SDN TOR上这样SDN TOR等于是深度参与到网络虚拟化中。 并非所有用户都认可这种模式但是有人喜欢。目前这种场景我们已经在几个中小型的私有云和某著名IDC云中部署了对这些云最大的帮助就是优良的性能和稳定性。数据流程见下图。 场景2使用硬件SDN交换机接入物理服务器 在不少人的理解中以为云计算数据中心里面所有的服务器都虚拟化了实际上这个理解跟事实相去甚远不仅在很多公有云和私有云中有大量物理服务器存在甚至有些云里面物理服务器还占了大头。我接触到的绝大多数真正有大量客户实践的云基本上都有这个需求。原因也多种多样有的是现存的一些老的服务器没有虚拟化能力有的是客户要跑一些非常消耗资源的应用使用虚机性能太差或者性能不可预测有的是客户的某些服务器是定制化的服务器有的是出于安全考虑从物理上就不想跟别人共享还有的则是用户自带服务器压根就不想云服务提供商来动等等总之原因是千奇百怪但是都是客户真实需求。 对于这个需求如果使用Vlan组网那还是比较容易搞定的不用SDN交换机也勉强可以因为要做隔离的话直接在普通交换机上配置Vlan就行了。但是一旦使用Tunnel那问题就来了Tunnel VTEP配置在哪里?有人说可以在服务器上只起一个虚机然后也安装vSwitch这样当然也可以做但是性能受损不是客户希望的相当于欺骗客户;还有人说专门设计一个特殊的vSwitch安装在服务器上这样理论上肯定也行但是工作量就大了(不仅仅是设计这个vSwitch的工作量还有云平台控制的工作量)一般人搞不定。更何况如果是用户自带设备根本不想你去动这两种办法都行不通。对于这个场景包括VMware在内的很多专业网络虚拟化解决方案提供商一般的做法都是通过一台硬件SDN交换机作为VTEP Gateway来将这些物理服务器接入到虚拟网络中去物理服务器不需要做任何事情。而且这种场景对作为VTEP Gateway的SDN交换机来说还有一个比较重要的要求是目前用某大牌交换芯片的所有交换机都做不到的那就是需要交换机既能支持Tunnel bridging也能支持Tunnel Routing(否则没法做分布式L3 Gateway)当前用该大牌芯片的交换机只能支持前者无法支持后者。思科的ACI之所以能支持后者是因为他们用了自己一颗芯片。当然该芯片提供商后面的芯片据说会解决这个问题。 盛科网络的SDN交换机用的是自研交换芯片从第一代芯片开始就支持Tunnel bridging routing。 目前针对这个场景的SDN交换机已经大量部署和即将部署在多个公有云中。该场景架构见下图(注SDN的控制协议未必是OpenFlow也可以是私有协议) 场景3使用硬件SDN交换机接入硬件防火墙 云计算网络中使用硬件防火墙这个很常见。特别是企业私有云托管云甚至公有云里面也有。很多用户明确提出我原来用我的硬件防火墙用得很好你要让我上云可以一定要把我的硬件防火墙用起来。那问题就来了以前在传统网络中用户数据想经过防火墙很简单把防火墙串接在网络出口或者配置一个ACL把流引过去就可以了。但是在云计算的网络里面有可能某个防火墙只是为某几个用户或者某一组应用服务的甚至这个防火墙压根就这个用户自带的你不能把它物理上串接在网络出口必须要将流量引到放在某个机柜的防火墙上但是这个时候用传统ACL不合适因为VM是动态产生的策略也可能动态变化你需要动态在交换机上配置ACL。用什么来做最合适?毫无疑问是SDN交换机动态策略跟随本来就是SDN的强项思科的ACI最核心的东西就是动态策略跟随。 如果云计算网络中使用了Tunnel那问题会更麻烦因为很多硬件防火墙不支持Tunnel必须要有另外一个地方终结Tunnel然后将Tunnel转换成Vlan送到防火墙谁来做这个事情最合适?毫无疑问那就是支持Tunnel的SDN交换机。 有人说这样的话防火墙仍然会受4K Vlan的限制。其实不然因为Tunnel向Vlan转换的时候这里的Vlan可以是每端口唯一的而不需要是全局唯一的。当然这个也需要交换机能支持才行。盛科的SDN交换机就可以很好地支持这个需求。 场景4使用硬件SDN交换机支持多个Hypervisor混合组网 说是多个Hypervisor其实最多的还是说VMware跟其它Hypervisor的混合组网。因为无论是KVM还是Xen那些开源的云平台或者第三方中立的私有云平台都能支持得很好云平台可以完全控制这些Hypervisor。但是VMware是一个闭源的Hypervisor没办法随心所欲控制。很多客户都用了VMware以前的老产品现在VPC比较热无论是赶时髦也好还是真的有需求也好他们都想能支持VPC特别是基于Tunnel Overlay的VPC。有人说那好办啊VMware不是有NSX专门来干这事吗?尽管它提供了对OpenStack的driver但是NSX非常贵一般客户用不起或者觉得不划算。这些客户要引入一些开源的KVMXEN但是又不想丢弃以前的VMware还想让这些Hypervisor一起组成VPC网络。那怎么办呢? 一个有效的解决方案就是使用SDN交换机接入使用了VMware的服务器云平台调用vCenter的接口配置VMware使用Vlan标识租户的network然后在SDN交换机上将Vlan转换成Tunnel如果要让VM的流量送到防火墙去做过滤也都可以通过SDN交换机去做。该方案已经由我们的一个行业云服务提供商合作伙伴成功在其行业客户中部署该行业客户群大量使用了VMware产品。而且我们发现有类似需求的私有云很多说白了就是不想花钱买NSX而又想有某些NSX的功能。该方案架构见下图。 场景5使用硬件SDN交换机按需部署Vlan 这个场景不算是刚需有些客户不在乎但是也有客户在乎。当前很多小型私有云中还是使用了Vlan的组网方式毕竟简单易部署且性能好。但是用Vlan来组网除了扩展性不如Tunnel Overlay之外它还有另外一个小问题因为VM可以随便迁移而每个VM都绑到一个特定Vlan当VM迁移走的时候Vlan也需要跟着迁移。而在Vlan组网的方案里面Vlan必须对中间的物理网络可见这就意味着交换机端口上的Vlan配置要经常动态变化。为了规避这个问题现在一般的做法都是预先把所有可能用到的vlan在所有的交换机的所有端口上都全部使能。这样带来的问题是所有广播(如ARP/DHCP)、组播、未知单播的报文每次都会被发送到整个物理网络的所有服务器上最终在服务器里面才丢弃这种做法一方面浪费了带宽另外一方面也有潜在的安全问题。 对于这种问题的一个很简单的解决方案就是引入SDN交换机动态按需去配置Vlan。 总结 张卫峰(盛科网络SDN云计算CTO 兼 软件研发部门总监《深度解析SDN》一书作者。)对于SDN交换机在上述场景中的应用用一句话来总结就是运用之妙存乎一心。现实中的需求真的是千奇百怪我这里列出来的还都是相对有一些共性大家容易理解的需求。还有一些一般人理解不了的甚至我都无法理解的需求都还没列出来。面对这些需求的时候通常你是别指望用常规手段能去解决而SDN或许就能帮你一臂之力这也许就是SDN的魅力之一吧。当然这里说的SDN交换机不一定是OpenFlow交换机更多的时候通过在传统交换机里面引入一个Cloud Agent提供开放的API(JSON RPC或者REST API)也许是一种更好的接地气的实现方式因为它天然可以跟传统网络无缝对接并且不需要对汇聚和核心设备有任何特殊需求这是我们在千百次的实践中总结出的宝贵经验。 作者张卫峰 来源51CTO
