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

他们看不到云计算网络的用户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大流量测试，使用vSwitch800多个带宽MB，后来在iPerf与此同时，迅 雷下载模拟实际网络流量，带宽立即下降到500多个MB，有高达300MB带宽损失了。因此，结论是虚拟交换机必须存在性能问题，需要优化。即使对于那些技术特别好、能够优化软件的人来说，他也不能否认无论你如何优化，网络处理都应该占用计算资源，而网络只是一种工具，计算是核心价值。

前面是定量测试。让我们做一些理论分析。现在服务器的性能如此强大，网卡加速。为什么虚拟交换机仍然存在性能问题？我的分析主要有以下原因。

vSwitch做Tunnel内存中报文的移动和复制会影响性能。

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

流表搜索在软件中消耗较大，尤其是流表数量较大，TCP当短连接较多时。