说三道四技术文摘-感悟人生的经典句子
说三道四 > 文档快照

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

HTML文档下载 WORD文档下载 PDF文档下载
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多级流表的一个绝佳实践,我们能看到这个方案带来的明显的优势。

  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仍然可以对用户数据应用策略,进行监控,极大缓解了纯软件方案带来的网络不可视问题。
备案号:鲁ICP备13029499号-2 说三道四 www.s3d4.cn 说三道四技术文摘