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交换机接入物理服务器

在不少人的理解中，以为云计算数据中心里面，所有的服务器都虚拟化了，实际上这个理解跟事实相去甚远，不仅在很多公有云和私有云中有大量物理服务器存在，甚至有些云里面物理服务器还占了大头。我接触到的绝大多数真正有大量客户实践的云，基本上都有这个需求。原因也多种多样，有的是现存的一些老的服务器没有虚拟化能力，有的是客户要跑一些非常消耗资源的应用，使用虚机性能太差