SDN及云计算平台中的网络性能优化

　　你知道吗？当你部署IaaS云计算平台时，就已经在应用SDN了。你知道吗？云计算平台可以在vSwitch和physical Switch之间无缝切换。你知道吗？当前的云计算平台的网络部分有很大的优化空间。本文就带你了解这一切。

　　一、没有SDN，就没有云计算网络

　　SDN起源于校园网络，发扬光大于数据中心。但现在看来很多人对后一句话并没有真正理解，如果你不服气，你能回答我这个问题吗：为什么说SDN很适合数据中心？我相信很多人对此都不甚了解。我这么说有一个依据，因为工作的关系，我跟国内不少做云平台的技术和管理人员聊过，包括提供公有云、私有云服务的公司以及企业内部私有云网络的研发和运维部门 的员工，有很多人跟我说过这样一句话：我们目前还没有开始使用SDN，但正在研究，也许以后会考虑吧。这句话暴露了当前很多从事云计算网络研发和运维的技术人员，对SDN在云计算网络中的应用并不清楚。

　　实际上，当你的数据中心在部署云计算平台（如OpenStack）时，就已在应用SDN了。先来看看OpenStack的网络组件Neutron的整体架构（如图1所示）。

　　

　　这个架构，逻辑上可以分为三个部分。最上面的一部分是OpenStack的控制平台，它通过用户操作直接或者间接向网络组件Neutron发送标准的命令。 第二层是Neutron组件，它通常是位于一个独立的控制节点上（一台服务器），它有一套标准的API对应上层应用发给它的每个命令，这些API包括 create_network、create_port、create_subnet等创建多租户网络以及创建Firewall、Load Balancer等各种业务的API。这套API从SDN的架构来看属于北向接口。在Neutron组件内部有很多个不同的插件（plugin），这些插 件大多数都是vSwitch插件，例如OVS、Linux Bridge和OpenFlow Controller等，也有部分硬件交换机插件，目前已经存在的包括Cisco、Arista和Mellanox，相信后面还会有公司会提交。用户可以 选择自己的网络使用哪种方式，然后选择相应的插件，这些插件会处理Neutron API调用，将它们转换为每种插件对应的switch所提供的API调用，然后通过各自定义的方式，发消息去调用虚拟交换机或者物理交换机提供的API， 这套API从SDN的架构来看属于南向接口。

　　我们再回过头来看看SDN的定义。SDN有很多属性，每个人理解都不同，正是因为如此，所以很 多人对于某一项技术是否是SDN看法不同。实际上，有很多属性是伪属性，它们并不影响对某项技术是否是SDN的判断，比如是否用了OpenFlow，是否 有标准化的编程接口，是否使用了物理交换机，都跟是否是SDN无关。在我看来，SDN有三个核心属性可以用来判断一个技术是否是SDN，这三个属性包括控 制与转发分离、开放的编程接口、集中化的网络控制（关于这点会有歧义，这里集中化网络控制，并不意味着Controller必须是集中式架构，也可以是分 布式的，只是说，所有参与控制的Controller，在被控制的交换机看来，逻辑上只有一个）。

　　然后我们再来看一下 OpenStack（别的云平台也一样）是否符合这三个要求。

　　第一，OpenStack架构中，控制面都是在OpenStack逻辑中（图1中的第一层和 第二层），而转发面则在虚拟交换机或者物理交换机中，绝对的控制与转发分离。

　　第二，无论是南向还是北向，都有开放的编程接口。

　　第三，集中化的 OpenStack控制平台控制着网络中多台服务器和交换机。所以无论从哪个方面看，OpenStack都是标准的SDN架构，OpenStack就是一 个超级Controller。

　　可以说如果没有SDN的理念，就没有OpenStack，你能想象交换机（物理或者虚拟）如果不提供编程接口 出来，OpenStack怎样灵活控制网络吗？特别是网络虚拟化的引入更是离不开SDN的协助（但网络虚拟化不等于SDN，不要搞混了）。而SDN确实为 包括OpenStack在内的云平台提供了无可替代的便利，让云平台的自动化操作成为可能。所以现在可以回答最开始的问题了：为什么说SDN非常适合用在 数据中心？其实更准确地说，是适合部署了云计算网络的数据中心，因为云计算网络要协调的资源非常多，引入一个业务要执行的操作非常复杂，靠手工去操作，一 方面容易出错，另一方面耗时太长，所以需要借助工具进行自动化部署，而使用了SDN的云管理平台使得这一切成为了可能。以后如果再有人问你SDN到底有什 么用，有什么是SDN能做而传统网络设备做不了的，给他讲讲这个例子。

　　但为什么还是有很多做云计算平台的人不认为自己使用了SDN呢？我归 纳了一下，大致有三种原因。

　　第一种，这些人不了解OpenStack Neutron的架构和工作原理，自然就不清楚。就像我在没有深入研究Neutron之前，也不清楚这一点。

　　第二种，很多人潜意识里面觉得没有用到 OpenFlow，就不能算用了SDN。前面提到，用不用OpenFlow并非是否是SDN的判断依据，因为OpenFlow只是SDN的其中一种实现方 式。

　　第三种，有人潜意识里面觉得我都用的是OVS，没有涉及到物理交换机，就觉得不能算是SDN，或者是觉得没有全网都用SDN，只是在网络边缘用到了， 不能算是部署SDN了。这一切都是误解，归根结底还是属于对SDN的本质或者OpenStack架构看得不透彻。

　　对于云计算网络的用户来 说，他们看不到SDN，但这并不代表他们没有享受到SDN带给他们的好处。现在大多数公有云平台的用户都是自助服务的，他们自己创建虚机，自己创建虚拟网 络，自己创建虚拟路由器，自己创建防火墙等，谁在底层支撑着这些动作的顺利执行呢？是SDN架构！没有SDN，就没有这一切！SDN的最高境界就是用户在 享受着SDN带来的便利却并没有意识到自己使用了SDN。

　　

　　二、用物理交换机取代虚拟交换机？

　　云计算网络目前还处于发展的初级阶段，为了支持多租户网络和支持VM的可移动性，网络虚拟化被广泛使用，包括基于VLan的、基于VxLan和基于GRE的。

　　目 前绝大多数网络都使用虚拟交换机（vSwitch）作为网络的边缘，最著名的就是Nicira公司发起的开源虚拟交换机项目OVS。之所以vSwitch 被大量用作网络虚拟化的边缘，跟VMware等软件公司的大力推动密不可分，这涉及到他们的利益，也涉及到网络的控制权之争：究竟是数据中心的系统运维团 队控制虚拟网络还是网络运维团队控制虚拟网络？以Cisco为代表的传统硬件厂商极力反对VMware的这种做法，理由包括网络可视化（Network Visibility）以及性能都是大问题，特别是性能问题。

　　但反对归反对，很多云计算网络的管理员有了先入为主的思维模式，如果有人让他 们切换到使用物理交换机，他们会普遍提出一堆问题，包括以下几个很典型的：会不会被锁定到特定的厂商身上？物理交换机能有虚拟交换机那么灵活满足各种需求 吗？我能像控制虚拟交换机那样方便地控制物理交换机吗？会不会增加网络成本？

　　尽管如此，很多人确实也都同意，使用虚拟交换机，例如OVS，确实有很多性能问题，这是使用物理交换机的方案最吸引人的地方，顺带着还有可扩展性（云管理平台要控制的虚拟网络节点太多）。所以现在问题就变成了：我知道使用物理交换机有这样的好处，但你怎样解决上述顾虑？

　　其实OpenStack的Neutron plugin机制特别是最新版（Havana）引入的ML2 plugin已经给出了答案。前面讲过，Neutron向上提供了一套标准的编程接口，这套接口独立于任何虚拟或者物理的交换机。对管理员来说，根本不需 要关心底下用的是谁的交换机，虚拟的还是物理的。对于数据中心系统研发部门的工程师来说，他们可以通过plugin机制引入多种交换机，虚拟的或者物理 的，前提是这些交换机必须能支持Neutron向上提供出那些API来，如果无法支持，自然就不会出现在我的采购列表里面，而支持了之后，如果以后因为某 些原因想换掉了，也很简单，只要换用另外一个交换机的plugin就可以了。这样第一个厂商锁定问题就没有了。特别是Havana版本引入的ML2 plugin机制，允许一个OpenStack域内同时支持多种交换机的plugin。这样只要管理员愿意，甚至都可以有的节点使用虚拟交换机，有的节点 使用物理交换机，而且可以是不同厂家的，唯一的前提就是这些交换机必须支持通用的Neutron API，这是北向接口标准化的好处。

　　第二个问题，物理交换机能有虚拟交换机那么灵活满足各种需求吗？其实对于特定的场景，这是个很隐蔽的伪命题。一提到灵活性，谁都想要，而且最好是无限灵活。但 如果有人问管理员，我可以满足你的场景中所有的实际需求，但无法提供任意不受约束的灵活性，你要任意灵活的话，需要付出代价，你要不要？我相信绝大多数理 性的管理员都不会要求任意灵活，因为超过需求之外的灵活，是无意义的，而你要为这些无意义的事情付出代价。另外，在有了SDN的机制，交换机可以向上提供 编程接口而不是命令行之后，特别是有了OpenFlow之后，一些交换机特别是为SDN优化过的交换机已可以满足绝大多数甚至全部云计算网络的需求了。退 一步说，不能满足需求的交换机，根据上面第一点，不会进入采购列表。

　　第三个问题，我能像控制虚拟交换机那样方便地控制物理交换机吗？在 SDN控制与转发分离的架构下，管理员通过云平台控制的永远都是直接的北向接口，那是与设备无关的。设备的差异性都被底层的实现给屏蔽掉了，如前所述，只 要底层设备能够提供足够的南向接口，通过换不同的plugin，OpenStack就可以控制不同的交换机，包括物理交换机。

　　第四个问题， 会不会增加我的网络成本？无论哪种方案，TOR交换机总是需要的。现在并不需要增加新的交换机设备，而只是要让原来的TOR交换机支持SDN方式或者换用 能支持SDN的交换机充当TOR。当然，客户都有保护已有投资的需要，往往不想把现有设备替换掉，这也没关系，前面讲过，OpenStack Neutron ML2的架构允许网络中有的网络节点是虚拟交换机，有的是物理交换机，所以想保护已有投资就变得很简单了，只需要在新增节点上用云平台来控制SDN物理交 换机就行了，原有的节点仍然是控制虚拟交换机，这样就可以让整个网络平滑引入物理交换机作为云平台控制的网络节点。

　　

　　三、虚拟交换机的性能需要优化吗？

　　前面讲这么多，其实主要是想要说明，如果云计算网络管理员想要从虚拟交换机切换到物理交换机的话，是很容易做到的，不会有什么损失。但接下来网络管理员马上就会问：为什么要切换？有什么好处？答案有多个，主要的两点是网络可视化和网络性能。

　　网络可视化的问题相对好分析，容易理解。因为如果在Hypervisor上做了Tunnel封装，报文送到TOR交换机上时，交换机已经看不到用户原始报文了，物理网络就很难对原始报文做统计和应用各种策略。而如果Tunnel封装在TOR上面做，则没有这个问题。

　　而对于性能问题大家的看法可能各异，大体可分为三类：

　　第一类是觉得没有什么性能问题；

　　第二类是觉得有，但还可以忍受；

　　第三类是觉得已到了影响业务、无法忍受 的地步了。

　　我相信他们讲的都是他们所看到的事实，为什么结果迥异？我分析过，基本上前面两类，要么是仍然处于试验阶段，还没有大业务的压力，要么是已正式 部署，但网络规模不大或者网络内的业务流量压力不大，当然我也不排除有的人技术能力特别牛，把性能优化到了极致。而第三类，则是已经有很大业务量部署在生 产网络中了，或者是用充分的测试手段模拟过实际的业务。第三类的典型例子就是国内的云服务提供商UCloud，他们有大量实际用户（很多是游戏客户）租用 了他们的公有云网络，业务量很大。和AWS等云计算平台一样，网络处理会占用计算资源，带宽损耗也很大。

　　另外一个云服务提供商 99Cloud也曾经做过这样的实验：先是用iPerf进行大流量测试，使用vSwitch带宽大概能到800多MB，后来在iPerf发包的同时，用迅 雷下载模拟实际网络流量，带宽马上降到了500多MB，有高达300MB的带宽被损耗掉了。所以结论就是，虚拟交换机肯定有性能问题，需要优化。就算是对 于那种技术特别牛，能将软件优化做到极致的人，他也无法否认，你再怎么优化，网络处理也要占用计算资源，而按道理网络只是工具，计算才是核心价值。

　　前面是定量测试，下面我们来进行一些理论分析。现在服务器的性能这么强劲，还有网卡加速，为什么虚拟交换机还有性能问题？我分析主要有以下几个原因。

　　vSwitch做Tunnel加封装和解封装时，报文在内存中的移动和拷贝会影响性能。

　　网卡中的TSO是可以对TCP报文进行分片加速的，但一旦vSwitch给报文加了VxLan或者GRE Tunnel，网卡一看不是TCP报文，就不会进行分片加速了。这对性能损耗也比较大。

　　软件中的流表查找消耗比较大，特别是在流表数量比较大，TCP短连接比较多的时候。

　　图2是使用虚拟交换机OVS的OpenStack网络架构。

　　

　　四、云计算网络性能优化方案

　　针对上述产生性能问题的原因，可以从以下几个方面来对云计算网络进行优化。将Tunnel加封装、解封装的功能Offload到支持SDN的TOR交换机上，这样一方面去掉了服务器上加解封装的开销，另外更重要的是网卡仍然可以通过TSO做TCP报文分片加速。

　　所有的流表都是预先加而非动态报文学习，减少Flow学习带来的冲击。同时通过合理地设置默认流表项（Default Entry）来有效减少流表项数量。有人对流表为什么可以预先加不理解，其实很简单，云计算平台掌握了所有的信息，包括一个租户有多少个VM，每个VM都 挂在哪个交换机的哪个端口下面，每个VM的MAC和IP各是多少，默认网关是什么，同一个租户之间VM的通信使用哪个Tunnel，需要对某个VM应用何 种策略等等。有了这些信息，就足以构建起转发面所需要的流表，既然能预先配置，为什么需要动态学习？为什么需要Flood呢？

　　将流表项查找也Offload到TOR SDN交换机，使用Linux Bridge做内部VM交换或者为了安全可控，让报文无论如何先送到TOR交换机，交换机处理后再送回去。这样延时会稍微大一点点儿。这一步根据用户情况 可选，也可以只做前面两步，流表查找仍然使用服务器内部的OVS。

　　更进一步，将基本的无状态Firewall、基于L2-L4的Load Balancer等（当然，如果是有状态的Firewall或者四层之上的Firewall/Load Balancer，交换机就搞不定了）也都在TOR交换机上面实现，把OpenStack中独立的网络节点服务器完全省掉了。当然这一步对交换机的要求比 较高，不是都能做到。如果做不到没关系，仍然放到服务器内部做。但这一步如果做了，对性能提升也会很明显。

　　L3 Gateway是所有云计算平台所共同面临的瓶颈，比如OpenStack，有专门的网络节点（Server）来充当L3 Gateway，用于支持租户的虚拟Router，由于所有需要路由的报文都要经过这些虚拟Router来转发，充当L3 Gateway的Server就成了瓶颈。有的硬件SDN交换机可以支持这种情况下的L3 Gateway，而且可以做成全分布式的，这样就不再存在性能瓶颈。

　　通过在TOR上启用ARP代理，帮助答复ARP请求，这样就可以避免ARP广播。

　　当然这只是理论分析，还需要实践检验，目前这方面的实践很少。盛科网络在这方面做了尝试，用自己的SDN交换机V350为多家云服务提供商（如 UCloud、99Cloud等）提供了基于硬件交换机的云计算网络解决方案，实现了上述优化措施，并将提交自己的plugin到OpenStack。 UCloud与盛科共同推出了云计算网络解决方案（如图3所示）。

　　

　　当然并非所有云平台都是基于OpenStack的，那是否别的云平台也可以使用硬件交换机代替vSwitch呢？答案是肯定的，其实UCloud的云平台就 并非OpenStack。另外，对于网络虚拟化，有人是用VLan做的，有人用Tunnel overlay技术，这并不影响使用vSwitch还是物理交换机。

　　当然，即便是这样，仍然会有人说，虽然虚拟交换机确实会导致CPU利用 率有点高，但高点就高点，也没什么；虽然虚拟交换机会导致更多的带宽损耗，但损耗点也没关系，反正我的网络也不需要那么高带宽，所以我真没必要使用硬件 SDN方案。这话听起来也有道理，但换个角度想想，公有云的基础架构成本非常高昂，公有云服务商要想赚钱，必须要在保证用户体验的前提下降低成本。怎么降 低？如果能够在一个Server内放更多的虚机，自然就可以降低成本，所以如果能把网络处理的消耗转移到物理交换机，让网络设备去处理网络功 能，Server专注于计算，那就可以省出更多资源来放置更多虚拟机。而所有这一切并不需要引入额外的设备，用得不爽了可以随时切换回原有方案，让SDN TOR交换机只执行普通TOR功能，可以说基本没有什么负面影响，何乐而不为呢？说到底，还是因为大家都被虚拟机厂商影响太深，有了先入为主的成见，特别 是在很多人对网络不是很了解的前提下。

　　五、结语

　　当前，很多从事 云计算的技术人员都是从企业内部的运维和系统研发人员直接转过来的。在传统网络时代，网络对他们来说只是个工具，会操作就行。但到了云计算时代，对云计算平台的开发人员来说，就不仅仅是会用这么简单了，而是提出了更高的要求，需要相关从业人员精通网络原理，这样才能让云计算网络的性能、可扩展性、对业务的 支持都做到最优，现在流行的DevOps概念就体现了这种要求。

　　因此，对这些人来说，深入了解网络技术就变得必不可少。但无论如何，云计算让网络应用变得精彩，让应用创新变得更容易；网络是云计算的基石，没有网络就没有云计算，那么，付出一点学习的代价又算得了什么呢？