NFCloud：基于OpenContrail的NFV实践

温曙光 贺 鹏 姜海洋 关洪涛 谢高岗

网络功能虚拟化(Network Function Virtualization,NFV)[1]是欧洲电信标准组织ETSI在2012年提出的一项愿景，借助云计算、虚拟化和SDN技术把电信设备从目前的专用平台迁移到通用的X86平台上来，帮助运营商和数据中心更加敏捷地为客户创建和部署网络特性，降低设备投资和运营费用。

NFV是从电信领域提出来的概念，“网络功能”在NFV白皮书中主要是指电信网络的功能模块(Network Function，NF)，比如IP Multimedia Subsystem(IMS)、Evolved Packet Core(EPC)。随着技术的发展与相互融合，NFV的概念已经突破了原始的定义从电信网络进入数通网络领域[2]，研究机构和相关的公司开始探索利用NFV的方法和工具将数据网络中的面向连接的网络功能服务化，常见的网络功能有：防火墙、网络地址转换NAT、因特网入侵防护监测和保护IDS/IPS、缓存Cache、深度数据包检测DPI、广域网加速、Web防火墙WAF、漏洞扫描等。

OpenContrail[3]正是Juniper瞄准这一市场机会推出的开源解决方案，为云计算平台提供网络虚拟化(Network Virtualization, NV)和网络功能虚拟化的能力。它采用Openstack[4]作为云资源管理平台，具有良好的可扩展性。本文介绍的NFCloud是我们基于OpenContrail构建的用于数据通讯领域的NFV系统，具有敏捷灵活、融合、高性能和高可用的特点。

1 业务模型

OpenContrail的NFV业务模型如图1所示。租户的业务运行在虚拟机A1～A6中，这些虚拟机连接到租户网络A/A1/A2上，租户网络是在基础网络(物理网络)上利用overlay技术构建的虚拟网络(Virtual Net, VNet)。OpenContrail的NFV功能允许在租户的两个VNet间(如图1上部所示)或者VNet和Internet间(如图1下部所示)增加以下两种形式的功能：1)一组服务实例串接形成一条服务链(如图1下部的FW和LB业务)，这两个网络间的流量会依次经过整条服务链上的每一个虚拟的网络功能(Virtual Network Function, vNF)服务实例，每个vNF都在两个网络间转发流量；2)一个并联的vNF服务实例(如图1下部的IPS业务)，这两个网络间的流量会被镜像到vNF，vNF可以对流量进行离线的深度数据包分析而无需转发。整条服务链既可以做二层转发也可以做三层转发，依据实际部署和应用场景而定。

在OpenContrail的模型中，接入vNF的一端必须是租户的虚拟网络，这一要求将其提供NFV的能力限定于云平台之上。NFCloud在调研之后提出来，NFV平台应该满足下列的需求。

1)将NFV的业务能力扩展到物理网络中，也就是说，NFV平台能为物理网络加载vNF服务。

2)提供多租户的环境，不同的用户能运行不同的vNF服务，他们之间是相互隔离的。

3)vNF能以服务链的形式串联或者并联在租户物理网络出口。

4)vNF能以云主机的形式部署在网络边缘。跟服务链上的服务不同，云主机有可达的IP地址，用户可以通过地址直接连接到云主机上。云主机的地址可以跟用户在同一个网段，也可以在网管单独分配的网段。

根据这样的需求，NFCloud所支持的业务模型如图2所示。图2左边是一般的园区网络结构，上面的路由器与Internet相连提供出口服务，下面的核心交换机提供大容量的交换网络，往下通过接入层接入不同的用户，用户间的流量一般是通过IP地址或者VLAN标签区分。在出口路由器下，NFCloud部署透明网关(Transparent GateWay,TGW)，将用户的物理网络流量引入到各自订购的虚拟服务链中来。如图2所示，用户1订购了一组服务；而其他用户尚未订购服务。所有的用户都可以随时登陆NFCloud系统启用或者停用订阅的服务。服务分为两种：服务链和云主机。服务链处理所有从该用户与Internet之间的流量，云主机则是一台用户可以访问的虚拟机。跟OpenContrail一样，服务链里面又包括串联服务和并联服务。从用户的视角出发，NFCloud在用户的物理网络出口提供了虚拟网关(Virtual Gateway, VG)的功能，在VG上，用户可以根据自己的需求，加载不同的业务。在NFCloud平台上，用户可以租赁vNF服务，也可以称为“租户”，因此在本文的讨论中，“用户”和“租户”的意义可以互换。

图1 OpenContrail的NFV功能的业务模型

图2 NFCloud的业务模型

NFCloud实现的4点需求，尤其是将NFV的业务能力扩展到物理网络这一点，使得我们可以将NFV这一强大的工具用于改造传统的物理网络上。它的架构使得它适合于部署在网络服务提供商出口，如园区网络、数据中心网络出口，或者运营商侧的汇聚链路上，提供面向多租户的虚拟网络服务和近用户侧的云计算能力。

2 系统架构

图3所示的是NFCloud的系统架构。整个架构采用微服务架构耦合，这是当前分布式系统开发的一种较为流行的架构。它将系统里面的各个组件划分为多个独立运行的服务，相互之间采用RESTful API请求、远过程调用或者消息队列的方式进行服务。每个服务完成的工作相对比较简单，清晰。按照各个服务所部署的位置，在NFCloud系统中有三类节点：控制节点、计算节点和透明网关转发设备。

图3 NFCloud的系统架构

控制节点运行各个子系统的控制平面。NFCloud-web是用户的入口，提供交互操作界面，它将用户的网络配置下发到透明网关控制平面TGW-control，从Openstack生成虚拟机组成服务链，服务链的配置下发到Opencontrail；Openstack和Opencontrail再通过其内部的机制管理计算节点。vNF-webproxy是vNF的管理平面提供的一个操作界面代理，允许用户从NFCloud-web直接管理vNF应用。TGW-control通过BGP协议跟Opencontrail协商服务链的隧道信息，并将它们存放在ZooKeeper里通知到透明网关转发设备TGW-forwarder。

计算节点是运行服务链和云主机虚拟机的服务器。计算节点由Openstack和Opencontrail管理，NFCloud在Openstack和Opencontrail上层开发的组件并不直接和计算节点交互。计算节点运行虚拟交换机(Virtual Switch，vSwitch)，负责为虚拟机构建VNet和服务链。计算节点之间的网络互连由高速的光纤(10G/40G)互连，这个高速互连网络称为Fabric网络。

透明网关转发设备T G W-forwarder则是将用户的物理网络与vNF联通的关键设备。它通过上下行链路串入到物理网络中，通过Fabric网络与计算节点相连。TGW-forwarder从Zookeeper中获取TGW-control写入的用户配置和路由信息。TGW-forwarder将用户的流量加上2层隧道头送给服务链或者云主机中的vNF，把处理完的流量再送回到物理网络中。

控制节点和计算节点都是标准的X86服务器；而TGW-forwarder作为网络接入设备，既可以采用X86服务器，也可以采用众核处理卡或者NP。在标准部署中，一套完整的NFCloud系统，包括一个主控制节点和一个备份控制节点，多个计算节点和一个透明网关转发设备。

3 挑战与解决方案

在通信通讯领域，服务提供商一直强调连接服务的高性能和高可靠性。而作为通信能力服务化的一种技术手段，NFV正是因为其在性能和可靠性方面达不到电信运营商的标准而成为其商业化的障碍[5-6]。在我们与客户的接触中发现，NFCloud提出的业务模型的接受度是非常高的，他们对OpenContrail底层能提供的性能和可靠性同样表现了不满意的态度。下面讨论NFCloud在性能和可靠性方面所做的工作。

3.1 透明网关

从功能的角度来看，透明网关属于传统的数据平面设备，其处理逻辑如图4所示：对流量按照上层定义的属性进行分类，如果它属于本设备的报文则进行协议栈处理；如果是送入vNF的数据包，按照用户进行数据包分类，即属于某个用户服务链或者云主机则加上隧道头从Fabric网络送入NFCloud后端的云虚拟机里，其余的报文直接转发；如果是vNF发送到物理网络的数据包，则解封装，提取出接口，恢复二层头发送到上下行网络中。

从部署的角度来看，透明网关串接到园区网络、数据中心网络出口或者运营商侧汇聚链路上。前者的链路多以1G速率为主，在这种场景下，基于X86平台DPDK[7]的纯软件的透明网关也可以满足性能要求。而对于后两种场景，目前的链路以10G/40G的光纤接入为主，即使只将少部分流量导入到NFCloud云中，由于所有的流量都需要经过透明网关进行用户查找，因此，对透明网关的性能压力是巨大的。为应付高速率链路对透明网关的性能需求，NFCloud在集成了众核处理器+交换芯片的硬件平台上开发了高性能透明网关，其结构如图5所示。

在图5中，TGW-forwarder的中心是交换芯片，对外提供上下行链路和Fabric接口，对内连接两边的众核处理芯片，两块芯片分别处理上下行的流量。从网络进来的流量经过交换芯片进行类型判断和用户查找：如果不需要额外处理的报文直接就转发；如果需要进行上层协议处理和隧道处理的报文，交换芯片会插入相应的用户信息送给CPU处理。这个结构把图4中性能关键的部分放到了交换芯片，包类型判断用交换芯片的ACL规则实现，用户查找用TCAM实现。由于使用了交换芯片，提高了透明网关转发平面的性能和可靠性。

图4 透明网关转发数据包处理流程

图5 基于众核处理器平台的透明网关转发平面

3.2 虚拟交换机

透明网关将服务链的流量通过Fabric网络送到服务链或者云主机中的vNF进行处理。vNF是虚拟机中的应用程序，而计算节点上面运行虚拟交换机(Virtual Switch, VS)软件处理Fabric接口和虚拟机的虚拟接口之间的报文交换。虚拟交换机由于其连接着物理接口和虚拟接口，其采用的技术直接决定了IO接口数据转发的性能，因此，VS的性能优化尤其重要。

主流的VS架构，多采用基于内核的数据通路+vhost-net+virtio的方式进行虚拟交换[8]，其结构如图6(a)所示。由于Linux内核中网络协议栈的通用性，基于内核的数据通路的额外开销较多，在1次IO中需要2次内存分配和释放+1次数据包拷贝；另外，由于涉及到驱动、协议栈、iptables/ebtables等多层功能，处理也较复杂。基于内核的数据通路很难提供超过1Gb/s线速的性能。为追求更高的性能，VS都开始朝着用户态交换的架构演进，以消除内核协议栈过重的额外开销。用户态交换把图6(a)都迁移到了用户态来如图6(b)所示，变成了DPDK+vhost-user+virtio。相较原来的基于内核数据通路的方式而言，减少了1次内存分配和释放，由于不需要考虑过多通用的功能，处理可以专注在虚拟交换上。在这种模式下，VS的性能可以提高到3Gb/s线速。

除了VS的架构外，降低VS处理的复杂性对性能也有较好的提升。原生的VS为全功能的处理设计了通用而复杂的流表规则和动作集。已有研究表明，通过算法的优化，比如Hypersplit[9]，流表cache可以对通用的流表匹配有较好的加速作用。而NFCloud将服务链IO的处理进行了大幅简化，避免了复杂的流表规则和动作集，比一些通用的优化算法效果更好，能将性能再次提升10%左右。

图6 基于内核态和用户态通路的VS架构

3.3 服务实例

服务实例是运行在虚拟机里面的vNF，一般是基于DPDK开发的用户态程序，对租户的流量进行业务处理。从虚拟化的角度来提升虚拟机的性能，Openstack和KVM社区有很多共性的优化的方法，比如大页面的使用，NUMA亲和性的绑定，VCPU和物理CPU的绑定等，这些方法同样适合于在NFV场景，因此我们都已经把这些优化技术引入到NFCloud系统中。从NFV的特性下手去提高服务实例的性能，NFCloud主要是从网络流量的IO着手，对vNIC的virtio-net前后端驱动进行改造，使其能够支持vNF对网络流量进行并行化处理和批处理。

1)vNF应用对流量进行并行化处理。虽然多核处理器已经发布超过10年，但由于并行编程的难度，许多NF应用在利用多核处理器的能力上仍然表现不佳。根据我们之前已有的研究成果总结[10]，网络流量并行编程模型主要有三种，即Run-To-Complete(RTC)模型、Software-Pipeline(SPL)模型以及由上面两种模型共同衍生出来的混合模型，包括Supra-linear模型、Multi-Snort、Para-Snort等。混合模型的出发点是SPL模型中的每一个Pipeline的复杂度是不均等的，对于较复杂的Pipeline应该采用RTC再进行并行化。Para-Snort模型在NF应用中适合网络流量处理特性因而性能较好，而且Para-Snort模型的编程复杂度较低开发容易。因此Para-Snort模型在新一代NF应用的开发中占据了主流的地位。

对于Para-Snort模型，在作者其它研究表明[11]，数据包捕获+负载均衡越靠近底层，从用户态→内核态→硬件越往下走，整个系统的可扩展性和性能就越好。在NFCloud中，数据包捕获+负载均衡是实现在虚拟交换层+vNIC上，将virtio-net的前后端都改造为支持多队列收发的并行结构，使得数据包从网卡进入系统就能够被并行处理，减少后续处理的拷贝和同步开销，极大地提高了vNF应用的性能。

2)vNF应用对流量进行批处理。我们建议vNF应用一次从网卡上收多个数据包进行处理；发送时则缓存多个数据包一次发送。从IO上来说，批处理可以减少系统开销；从应用来说，批处理可以提高代码和数据的热度，提高Cache命中率。

3.4 可用性

由于数据通讯处于互联网应用的基础地位，高可用性是天然的业务要求。而云管理平台在单个业务的可用性方面，主要是上层业务做负载均衡+冗余备份，在NFCloud控制平面也采用相同的方法(如图3所示部署的备份控制节点)。而对于NFV工作的数据通讯层上的可用性，包括Openstack在内的云管理平台都缺乏足够的保护措施。NFCloud在这方面做了增强，从手段来说是冗余+监控+保护，从保护范围来说是系统→服务链→单个vNF应用三级。

1)vNF应用监控和服务链状态监控。前者是对vNF是否正常进行业务转发进行监控，后者对某个租户的整条业务链转发进行监控。这两种方式都是通过主动发送探测包并监控返回来的探测包来推测被监控对象的行为和状态。这两套机制都是借用802.1AG协议的Connectiv Fault Management(CFM)的状态机。当监测应用或者服务链的的行为异常时，NFCloud会通知控制平面尝试做修复工作，比如重启虚拟机，暂时将流量跳过某一级或全部应用，或者跟ECMP联动。

2)Equal Cost Multi Path(ECMP)冗余备份，利用负载均衡对vNF进行备份。ECMP是一种网络层的负载均衡技术，如图7所示，对于FW这个vNF运行了3个相同的虚拟机对流量进行处理。当NFCloud采用vNF应用监控和服务链状态监控的方法监测到某一个FW虚拟机失效时，FW前一级的VS将会知道并跳过失效的FW虚拟机。它既提供良好的可扩展性，也提供冗余备份能力。

3)入口短路保护，采用光保护交换机对透明网关TGW和整套云平台进行监控。其工作原理如图8所示，光保护交换机放置在TGW-forwarder前，两者之间有一条心跳线。在系统正常工作时，光保护交换机会将上下行间的流量送给TGW-forwarder；当系统不能正常工作时，比如光保护交换机掉电、两者时间的光纤无信号或者没有心跳时，光保护交换机直接将上下行的流量透传，从而保护上下行间的链路。

图7 ECMP对业务进行负载均衡

图8 光保护交换机的工作原理

4 总结

NFV成为改造网络的一个强大的工具，有许多网络服务提供商正在计划将它们的服务迁移到NFV平台上去。本文总结了我们在Opencontrail上构建面向数据通讯NFV平台——NFCloud时遇到的问题和解决方法。NFCloud的核心价值在于解决以下两个问题：NFV应该怎样提供业务能力和NFV平台如何满足服务提供商的技术要求。

NFV应该怎样提供业务能力？我们在调研了好几种商用和开源的NFV平台后发现，vNF的主要运行模式包括Middlebox服务和主机服务[12]，我们将这两种业务抽象为在出口的服务链和在边缘的云主机。所有的NFV平台都提供运行云主机这种能力。而对于服务链业务，对于加载网络的Middlebox业务，这是特别合适的业务模式，但是，服务链业务在各种NFV平台中的功能要么缺失，要么有较大的局限性(只能用于VNet之间)，要么使用较复杂。NFCloud将NFV平台业务能力总结为4点需求：扩展到物理网络、多租户、提供服务链功能、提供云主机功能。这使得NFCloud适合部署在网络出口，如园区网络、数据中心网络出口，或者运营商侧的汇聚链路上，提供面向多租户的虚拟网络服务和近用户侧的云计算能力。

NFV平台如何满足服务提供商的技术要求？NFV底层使用云计算技术来运行vNF。这两者在技术要求上并不一致：NFV在数据通路上提供虚拟服务，要求高性能和高可用性；而云计算正是允许牺牲部分性能来解决资源弹性使用的问题。在整个数据通路上我们采用了多种技术来提高性能：使用专用的众核处理平台来实现10G的透明网关转发平面；采用用户态交换并简化规则处理来提高虚拟交换的性能；在virtio接口上提供并行化和批处理能力来提高vNF自身的性能。在可用性上，NFCloud采用监控+冗余+保护手段对系统→服务链→单个vNF应用三级的可用性进行加强。

参考文献

[1]ETSI: Network Function Virtualization[EB/OL].[2016-01-02].http://www.etsi.org/technologies-clusters/technologies/nfv

[2]华一强,郭晓琳,杨艳松.NFV及其在IP网中应用的探讨[J].邮电设计技术,2015(2):11-16

[3]Opencontrail: An open-source network virtualization platform for the cloud[EB/OL].[2016-01-02].http://www.opencontrail.org/

[4]Openstack: Open source software for creating private and public clouds[EB/OL].[2016-01-02].http://www.openstack.org/

[5] 李晨,段晓东,陈炜,等.SDN和NFV的思考和实践[J].电信科学,2014(8):23-27

[6]史凡,解云鹏,胡晓娟,等.SDN/NFV技术对电信网络架构的价值和引入要点分析[J].电信网技术,2015(4):1-4

[7]DPDK: a set of libraries and drivers for fast packet processing[EB/OL].[2016-01-03].http://www.dpdk.org/

[8]Rusty Russell.Virtio: towards a de-facto standard for virtual I/O devices[J].ACM SIGOPS Operating Systems Review,2008(5): 95-103

[9]贺鹏.高效包分类方法研究[D].北京:中国科学院大学,2015

[10]姜海洋.网络入侵检测系统并行化技术研究[D].北京:中国科学院大学,2015

[11]温曙光,谢高岗.libpcap-MT:一种多线程的通用数据包捕获库[J].计算机研究与发展,2011(5):756-764

[12]薛淼,符刚.基于SDN/NFV的Service Chaining关键技术研究[J].邮电设计技术,2015(2):1-6