SDN交换机在不同场景的云计算网络作用解析

　　对于SDN交换机在上述场景中的应用，用一句词来总结，灵活百用。这里说的SDN交换机，不一定是OpenFlow交换机，更多的时候，通过在传统交换机里面引入一个Cloud Agent。提供开放的API（JSON RPC或者REST API），也许是一种更好的接地气的实现方式，

　　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非常贵，一般客户用不起或者觉得不划算。这些客户要引入一些开源的KVM，XEN，但是又不想丢弃以前的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。