网络虚拟化协议GENEVE

作者简介:肖宏辉,毕业于中科院研究生院,思科认证网络互连专家(CCIE),8年的工作经验,其中6年云计算开发经验,关注网络,OpenStack,SDN,NFV等技术,OpenStack和ONAP开源社区活跃开发者。本文所有观点仅代表作者个人观点,与作者现在或者之前所在的公司无关。

去年看到过一篇文章[1],说是通过OpenVSwitch的测试,GENEVE的性能要略优于VXLAN。我相信大多数人的反应可能跟我的第一反应一样,这不又是一种Overlay协议吗?为什么性能会更好?难道有什么黑科技?我们这次来分析一下GENEVE有什么不一样。

网络虚拟化

要说清楚来龙去脉,需要从网络虚拟化开始说起。网络虚拟化(Networking Virtualization)是在一个underlay网络上划分出多个overlay网路。原本只支持一套网络的设备,通过网络虚拟化,现在可以用来支持多套网络。网络虚拟化本身不是一个新的技术,从其诞生之日起,各种各样的协议就被提出,远的有VLAN(IEEE 802.1Q)、MPLS(RFC3031),近的有VXLAN(RF7348)、NVGRE(RFC7637),STT。那究竟是网络虚拟化的什么特性,导致了这么多相关的协议被提出?

如果我们把网络中的所有节点看成一个分布式系统,那么underlay网络为这个分布式系统的各个节点提供了网络连接。而各种各样的网络虚拟化协议,则为这个分布式系统的各个节点提供了通信所使用的协议。比如说,在一个云环境里面,所有的服务器共同组成了一个部署虚机的分布式系统。underlay网络连接这个分布式系统的各个节点(各个服务器),而网络虚拟化协议用来封装各个节点之间传递的数据(虚机之间的网络数据)。

虚机间的网络数据基本都是以太帧,但是不同的应用场景,系统规模,对于协议的要求也不一样。所以才会有这么多网络虚拟化协议。目前的各种网络虚拟化的协议,本质上来说都是一样的。那就是,以一定的格式封装原始网络数据,再辅以一定的元数据(metadata),来实现附加的功能。元数据对于网络虚拟化来说不是一个陌生的概念,网络标识符(Virtual Network Identifier,VNI)就是一种元数据。通过VNI可以识别并隔离多个租户(tenant)网络。

现在比较流行的网路虚拟化协议是VXLAN,有24bit的VNI,可以对应1600万个不同的tenant网络。VXLAN的提出常常说是为了解决VLAN(12bit VNI)所提供的租户网络数不够的问题。现在来看1600万这个数字是足够大了,但是能保证以后一直够用吗?因为在VLAN被提出的时候,4000多个租户网络已经很够用了。只是随着云计算和数据中心规模的发展,渐渐变的不够用。那么激进点看,随着技术的发展,24bit的VNI会不会也有不够用的一天?

退一步说,就算24bit的VNI是够用的,现在一些新的应用需要网络虚拟化协议里面携带其他的元数据。例如加入port ID来作为安全规则的识别符。假设port ID是16bit,那24bit的VNI只剩下8bit用来标识租户网络,这明显是不够用的。

所以,尽管现有的网络虚拟化协议能满足当前的需求,但是随着技术的发展和使用场景的变化,并不能保证它们能够一直满足需求。解决办法有两种,一种是到时候再定义新的协议,另一种是定义一种灵活,可扩展的网络虚拟化协议。GENEVE采用的是后者。

GENEVE

GENEVE这个单词对应的是瑞士城市日内瓦,但是这个网络协议本身与日内瓦应该没什么关系。这个单词是Generic Network Virtualization Encapsulation的简称,对应中文是通用网络虚拟化封装,由IETF草案定义[2]。

GENEVE的作者称,他们考虑了所有可能的应用场景,发现一个固定长度的元数据(例如前面提到的VNI)不能适应所有可能的场景。同时,他们也参考了其他一些常青的协议,例如BGP,LLDP,IS-IS。这些协议已经存在几十年了,并且现在还很流行。背后的原因在于,这些协议并不是一成不变,而是随着技术的发展,支持了新功能的扩展。例如BGP,最基本的路由选择算法一直没有改变,但是却从只支持IPv4到支持IPv6,VPNv4,VPNv6等其他地址族。

所以,他们提出了一种网络虚拟化协议,这个协议的元数据本身是可扩展的。这样,就算需求变化了,这个协议也能扩展以满足需求。这个协议就是GENEVE。

在实现上,GENEVE与VXLAN类似,仍然是Ethernet over UDP,也就是用UDP封装Ethernet。VXLAN header是固定长度的(8个字节,其中包含24bit VNI),与VXLAN不同的是,GENEVE header中增加了TLV(Type-Length-Value),由8个字节的固定长度和0~252个字节变长的TLV组成。GENEVE header中的TLV代表了可扩展的元数据。我们来看一下GENEVE header:

  • Version(2bit):没什么好说的,目前是0
  • Opt Len(6bit):以4字节为单位,表明Variable Length Options的长度。因为只有6bit,所以Variable Length Options最多是252(63*4)字节。
  • O(1bit):表明这是一个OAM包,包含了控制信息,而非数据。Endpoint可以根据这个bit来优先处理这个包。
  • C(1bit):表明在Variable Length Options里面,存在一个或者多个Critical的option。当C被置位时,Variable Length Options必须被解析,如果当前Endpoint不支持GENEVE解析,那么应该丢弃数据包。如果C没有被置位,那么Endpoint可以根据Opt Len直接丢弃所有的Variable Length Options。
  • Rsvd.(6bit):保留字段。
  • Protocol Type(16bit):被封装的协议类型,例如Ethernet就是0x6558。这个字段的存在,使得GENEVE封装其他的二层协议成为可能。
  • VNI(24bit):老朋友了。
  • Reserved(8bit):保留字段。
  • Variable Length Options:由TLV构成,包含了可扩展的元数据。

性能考虑

从协议格式可以看出,GENEVE与其他网络虚拟化协议的主要区别在于一个长度可变的header。这使得GENEVE变得灵活,可扩展。但是可扩展和高性能从来都是矛盾的。因为可扩展意味着更多的元数据来支持更多的功能,而高性能却要求更少的数据传输和处理。对此GENEVE定义了O和C位(参见上面协议格式分析),使得Endpoint能够更灵活的处理数据,以减少额外的元数据对性能带来的影响。

控制层考虑

尽管某些网络虚拟化协议里面包含了对控制层的描述,例如VXLAN(RFC7348)就包含了一个基于组播的learn-flood控制层,但是在实际使用中,这些协议通常只被当做数据格式的描述。试问多少人知道RFC7348里面有基于组播的flood-learn?

另外,在VXLAN的使用过程中,控制层可能有很多种,例如EVPN,例如SDN controller。这两种控制层比基于组播的控制层要流行的多。而所有这些控制层之间的差别是巨大的。

所以,GENEVE的作者认为,GENEVE应该只关注协议数据格式。他们力求设计一种适用于多种控制层的协议,而非只针对某一种控制层。这样就算控制层变化了,协议本身也不至于被弃用。

underlay负载均衡考虑

几乎所有的underlay网络(例如CLOS架构)都会利用多条等价路径(ECMP)来提高传输的并发性。我们把两个虚机之间的一个传输层连接称为一个数据流。为了达到最好的负载均衡的性能,不同的数据流应当被分布到不同的线路上。而相同的数据流应当被分到同一个线路上,这样才能保证数据的顺序,减少不必要的确认重传。

对于GENEVE来说,因为Ethernet Frame被封装在UDP里面,ECMP设备看到的不是虚机的IP/MAC,而是Tunnel Endpoint的IP/MAC。每个Tunnel Endpoint可能连接多个不同的虚机,而对于两个相同Tunnel Endpoint之间的网络流量,在underlay网络上唯一能看到的不一样的地方就是外层UDP的source port。因此,GENEVE规定,使用外层UDP的source port用来标识实际的数据流。首先,对于同一个数据流来说,外层UDP的source port应该是一样的,其次这个UDP source port,应该根据实际的数据流计算得出,例如根据数据流的五元组。这样,ECMP设备不需要读取内层报文的信息,只需要根据外层UDP的source port,就能完成ECMP的路径选择算法。而这个时候的UDP source port,也不再标识一个UDP连接,而是用来标识overlay的数据流。为了减少重复,GENEVE协议认为应该使用source port的整个16bit(而不是常用的50000-65535)。

兼容性考虑

如果你熟悉VXLAN或者NVGRE的协议格式,你可能已经发现了,如果不考虑Variable Length Options,GENEVE与VXLAN还有NVGRE是不冲突的。特别是VXLAN,也是将Ethernet Frame封装在UDP里面,这样,一些现有的针对VXLAN的优化,例如硬件offload,RSS,可以直接应用在GENEVE上。

OVN

OpenVSwitch的衍生项目OVN(Open Virtual Network)应该是GENEVE的最大拥趸。本文最开始提到的文章[1],也是出自OVN的开发人员。根据OVN的文档[3],OVN只支持GENEVE和STT作为网络虚拟化协议。这是因为OVN除了24bit的VNI之外,还要在overlay数据中传输15bit的源网络端口,和16bit的目的网络端口,以支持更高效的ACL和组播。GENEVE因为是可扩展的,自然是支持传递额外的元数据。STT因为本身的元数据是64bit的,也放得下OVN想要传递的内容。至于其他的协议,例如VXLAN,NVGRE,是没有可能满足OVN的需求。

我们再回过头来看看[1],为什么测试结果显示GENEVE性能要略优于VXLAN。由于VXLAN的普及,目前支持GENEVE的硬件不多,所以测试都是在支持VXLAN RSS的网卡上进行。并且在测试中,GENEVE还额外传递了OVN所需的15bit的源网络端口,和16bit的目的网络端口,也就是说,GENEVE传递的数据更多。

尽管有这些因素的存在,GENEVE的结果要好于VXLAN。首先,这个结果表明了,GENEVE能很好的兼容VXLAN,因为就算是VXLAN的主场,GENEVE最后还是赢了。但是兼容性并不能解释最后的现象,文章本身也没有分析原因,只是提到了UDP checksum。OVN默认打开了GENEVE上的UDP checksum。因为Linux系统内核的一些优化,使得GENEVE数据包被网卡收到之后,网卡会计算并验证外层UDP的checksum。如果验证通过了,网卡会汇报给系统内核。这样系统内核在解析GENEVE时,将不再计算内层报文的任何checksum。相应的网络数据处理会更快一些。而VXLAN协议规定外层UDP的checksum应该为0,这样外层UDP的checksum就没有办法被验证,而内层报文的checksum需要再计算一遍,相应的网络数据处理就要慢一点。

[1] https://blog.russellbryant.net/2017/05/30/ovn-geneve-vs-vxlan-does-it-matter/

[2] https://tools.ietf.org/html/draft-ietf-nvo3-geneve-06

[3] http://www.openvswitch.org//support/dist-docs/ovn-architecture.7.html


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。
  • 本文链接https://www.sdnlab.com/20693.html
分享到:
相关文章
条评论

登录后才可以评论

肖宏辉 发表于18-04-12
1