本文转自:http://www.csdn.net/article/2014-05-10/2819711-OpenFlow-table
width="22" height="16" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2014-05-10%2F2819711-OpenFlow-table&type=3&count=&appkey=&title=OpenFlow%E5%A4%9A%E7%BA%A7%E6%B5%81%E8%A1%A8%E6%98%AF%E5%BD%93%E5%89%8D%E7%9A%84%E7%83%AD%E7%82%B9%E8%AF%9D%E9%A2%98%EF%BC%8C%E4%BD%86%E7%BC%BA%E5%B0%91%E5%AE%9E%E9%99%85%E5%BA%94%E7%94%A8%E6%A1%88%E4%BE%8B%EF%BC%8C%E6%9C%AC%E6%96%87%E4%B8%AD%E7%9B%9B%E7%A7%91%E5%BC%A0%E5%8D%AB%E5%B3%B0%E5%88%86%E4%BA%AB%E4%BA%86OpenFlow%E5%A4%9A%E7%BA%A7%E6%B5%81%E8%A1%A8%E5%9C%A8%E5%AE%9E%E9%99%85%E7%BD%91%E7%BB%9C%E6%96%B9%E6%A1%88%E4%B8%AD%E7%9A%84%E8%BF%90%E7%94%A8%E3%80%82%E8%AF%A5%E6%96%B9%E6%A1%88%E6%98%AF%E5%9F%BA%E4%BA%8ESDN%E7%9A%84%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%E6%96%B9%E6%A1%88%EF%BC%8C%E5%B0%86%E5%BD%B1%E5%93%8D%E7%BD%91%E7%BB%9C%E6%80%A7%E8%83%BD%E7%9A%84%E5%B7%A5%E4%BD%9C%E4%BB%8E%E6%9C%8D%E5%8A%A1%E5%99%A8Offload%E5%88%B0TOR%E4%BA%A4%E6%8D%A2%E6%9C%BA%E4%B8%8A%E3%80%82&pic=&ralateUid=&language=zh_cn&rnd=1432689849424" frameborder="0" scrolling="no" allowtransparency="true">摘要:OpenFlow多级流表是当前的热点话题,但缺少实际应用案例,本文中盛科张卫峰分享了OpenFlow多级流表在实际网络方案中的运用。该方案是基于SDN的性能优化方案,将影响网络性能的工作从服务器Offload到TOR交换机上。
编者按:OpenFlow多级流表是当前的热点话题,但目前缺少实际的应用案例,盛科基于SDN提出一种性能优化方案,将影响网络性能的一些工作从服务器Offload到TOR交换机上去做,将TOR交换机作为服务器网卡的一部分,并且该方案已经在实际网络中进行了部署。本文中,盛科张卫峰分享了OpenFlow多级流表在这个方案中的运用。以下为原文:
作者简介: 盛科张卫峰,熟悉二三层路由交换、PTN/IPRAN技术、芯片设计,对SDN/OpenFlow技术也有深刻的研究和理解。著有《深度解析SDN》。新浪微博ID:@ 盛科张卫峰
先说个题外话
众所周知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或者NvGRE)后,从服务器网卡发出去,通过中间的物理网络,送到目的服务器上的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上查流表,去掉VlanTag,识别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);
- 基于VM或者租户的策略应用;
- 传递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主动发过来查询VlanId/TunnelId的。所有的流表项配置消息都仅仅发生在Controller和SDN TOR之间,将Neutron Server所需要控制的节点数量从Hypervisor的数量级降低到TOR的数量级,可以大大缓解控制面的压力,提高云平台的可扩展性。
总结
SDN时代的网络,不再是以设备为中心,而是以应用为中心,应用驱动网络变革。这就需要很多深度定制的工作,云计算网络尤其如此。OpenFlow协议设计了多级流表,一直以来我们都没看到有什么典型的应用场景。本文所介绍的这个例子,可以算是OpenFlow多级流表的一个绝佳实践,我们能看到这个方案带来的明显的优势。
- 它基于标准的OpenFlow接口,可以防止厂商锁定,只要厂商支持OpenFlow多级流表,且能支持相应的匹配字段和编辑动作。
- 让Server专注于计算,将流表查找、Tunnel加解封装、QoS、Security Group等网络处理功能都Offload到TOR,可以大大减轻Server负担,提升网络性能。
- 分布式L3 Gateway的设计,特别是将L3 Gateway做到TOR上,可以避免集中式L3 Gateway带来的single point failure的风险,并消除它的性能瓶颈。而且是将router功能做在TOR而非hypervisor,可提升路由性能。
- 将云平台需要控制的网络节点数量从Hypervisor的数量变为TOR的数量,降低了一个数量级,有效减轻云平台的可扩展性压力。特别是在VM迁移的时候,需要去更新的节点数量降低一个数量级。
- 可以很好地支持非虚拟化环境。
- TOR仍然可以对用户数据应用策略,进行监控,极大缓解了纯软件方案带来的网络不可视问题