OpenFlow多级流表在云计算中的应用

本文转自：https://www.csdn.net/article/2014-05-10/2819711-OpenFlow-table

**

OpenFlow多级流表在云计算中的应用

**

OpenFlow多级流表是当前的热点话题，但目前缺少实际的应用案例，盛科基于SDN提出一种性能优化方案，将影响网络性能的一些工作从服务器Offload到TOR交换机上去做，将TOR交换机作为服务器网卡的一部分，并且该方案已经在实际网络中进行了部署。本文中，盛科张卫峰分享了OpenFlow多级流表在这个方案中的运用。

众所周知，OpenFlow里面很多行为都是协议无关的，在很多人看来都是脱离实际地要求任意灵活，纯属瞎胡闹。比如要求流规则中至少匹配12元组，比如要求任意数量的多级流表，即难实现又找不到应用。但事实上，它的要求是否合理，完全取决于你怎么去理解他。在讲正文之前，先顺便聊一下这个题外话。如果你对OpenFlow标准的理解是：厂家的实现必须要能同时匹配12元组，必须要能支持任意数量的多级流表，必须要能在刘表之间任意跳转，那我可以告诉你，这种要求是做不到的，也是不合理的，这并不是OpenFlow的本意，OpenFlow的本意在于要求你能满足各种实际应用的需求，场景一种需要匹配Mac，那你要能匹配Mac；场景二中需要匹配IP，那你要匹配IP；场景三种需要你先匹配Mac，再匹配IP，你要能做到；场景四中要求你先匹配IP,再匹配Mac，你也要能做到。

现有的纯软件Tunnel Overlay云计算网络解决方案

题外话说完了，回头再讲正题。尽管如此，就算是理性的人，也还是觉得难以找到OpenFlow多级流表的实际应用案例。今天我就来分享一个在实际生产网络中对OpenFlow多级流表的运用，这个实际生产网络就是IaaS云网络，已经在客户那里实际部署。

我们都知道现在最主流的IaaS云计算网络的解决方案就是纯软件的Tunnel Overlay，为什么最主流？因为灵活嘛，而且能解决问题。包括现在最火的OpenStack，使用Tunnel Overlay方式组网的也很多，它在转发面的大概工作流程就是一个VM发送报文到vSwitch，vSwitch加上Tunnel Header（VxLAN隧道或GRE）后，从服务器网卡发出去，通过中间的物理网络，送到目的服务器上的vSwitch，vSwitch将Tunnel解封装后，原始报文转发到目的的VM。

基于硬件的OpenFlow四级流表架构

纯软件的Tunnel Overlay方案虽然灵活，但是有不同程度的性能问题（程度取决于每个云平台研发团队对它的优化力度），而且云计算网络中通常都会因为各种各样的原因，有非虚拟化的设备，这些设备如果要接入到tunnel overlay的网络中，必须借助于硬件TOR交换机作为tunnel gateway。

盛科网络一直都在为各种应用场景进行SDN定制，云计算网络作为SDN的目前最重要的应用领域，自然也不例外。现在盛科基于SDN提出一种性能优化方案，将影响网络性能的一些工作从服务器Offload到TOR交换机上去做，从理念上讲并不是把TOR交换机作为物理网络的一部分，而是作为服务器网卡的一部分。该方案已经在部分客户网络中部署。现在我们来分享一下OpenFlow多级流表在这个方案中的运用。

在该方案中，云平台（如OpenStack）跟SDN TOR交换机紧密集成，通过Controller控制SDN TOR交换机的流表下发，来完成虚拟网络转发路径的建立。VM将报文送到vSwitch，vSwitch直接将报文加上VLAN通过网卡送到TOR交换机，TOR上查流表，去掉VLAN Tag，识别VM，进而识别Tenant，可选地，可以对VM或者Tenant应用一些策略（如限流，安全过滤），然后查表，如果是跨机架送到别的TOR，则加上Tunnel，经过中间物理网络，送到目的TOR，目的TOR剥去Tunnel Header后查表转发（仍然可以先应用策略），到了服务器上，vSwitch查本地流表（只需要维护本地VM信息）后，转发到目的VM。

为了完成整个过程，盛科专门针对云计算的应用场景，利用交换机芯片内置的N-FlowTM技术，专门研发出一种四级流表的OpenFlow模型。

每张Flow Table完成的具体功能如下：
Table ID为0的功能：
VM识别（基于macSa）
租户识别（基于macSa or VLAN）
Tunnel识别（基于Tunnel VniId）
传递metadata到后面

Table ID为1的功能：
全局安全或者QoS策略应用
决定下一级table跳转到2还是3

Table ID为2的功能：
二层流表转发到Port或者Tunnel

Table ID为3的功能：
三层流表转发到Port或者Tunnel

跟云平台的集成

云平台直接通过盛科提供的（或者用户自己写的）插件跟一个集中式的Controller打交道（当然用户也可以处于扩展性的考虑自己设计分布式的Controller），通过这个Controller的标准OpenFlow接口去控制交换机，大量的工作（抽象信息翻译成流表）是在插件里面做的。这种架构的一个好处是可以兼容不同厂商的设备，只要这些设备都能支持云平台所需要的OpenFlow的能力（比如多级流表），支持足够数量的Tenant和VM。

Controller跟TOR交换机之间的消息不仅有OpenFlow消息，还需要OVSDB消息，用来创建Tunnel（OpenFlow并不支持创建Tunnel）。

原则上这种架构可以跟任何云平台集成，我们以OpenStack为例来说明如何将多级流表SDN TOR交换机继承到云平台中。

计算节点上的OVS Agent跟盛科插件之间只有Query消息，是OVS Agent主动发过来查询VLAN Id/TunnelId的。所有的流表项配置消息都仅仅发生在Controller和SDN TOR之间，将Neturon Server所需要控制的节点数量从Hypervisor的数量级降低到TOR的数量级，可以大大缓解控制面板的压力，提高云平台的可扩展性。

总结

SDN时代的网络，不再是以设备为中心，而是以应用为中心，应用驱动网络变革。这就需要很多深度定制的工作，云计算网络尤其如此。OpenFlow协议设计了多级流表，一直以来我们都没有看到有什么典型的应用场景。本文所介绍的这个例子，可以算是OpenFlow多级流表的一个绝佳实践，我们能看到这个方案带来的明显的优势。

1.它基于标准的OpenFlow接口，可以防止厂商锁定，只需要厂商支持OpenFlow多级流表，且支持相应的匹配动作和编辑动作。
2.让Server专注于云计算，将流表查找、Tunnel加解封装、QoS、Security Group等网络处理功能都Offload到TOR,可以大大减轻Server负担，提升网络性能。
3.分布式L3 Gateway的设计，特别将L3 Gateway做到TOR上，可以避免集中式L3 Gateway带来的single point failure的风险，并消除它的性能瓶颈。而是将router功能坐在TOR而非hypervisor，可以提升路由性能。
4.将云平台需要控制的网络节点数量从hypervisor的数量变为TOR的数量，降低了一个数量级，有效减轻云平台的可扩展性压力。特别是在VM迁移的时候，需要去更新的节点数量降低一个数量级。
5.可以很好地支持费虚拟化环境。
6.TOR仍然可以对用户数据应用策略，进行监控，极大缓解了纯软件方案带来的网络不可视问题。