基于DPDK的边缘集群内低成本高速通信方案

吴明杰，陈庆奎

1(上海理工大学 管理学院，上海 200093) 2(上海理工大学 光电信息与计算机工程学院，上海 200093)

1 引 言

随着物联网[1]规模的不断扩大，数据的不断增加，基于云的物联网解决方案将承受更大的压力.为了缓解这一现状，越来越多的企业开始将目光转向边缘计算[2]，并将其作为云的延伸扩展，以加快数据分析的速度，减少延迟.边缘计算是一种分散式计算架构，将终端的部分计算需求从原有的云计算中心分配到边缘计算集群中[3].这样不仅能够充分缓解数据中心的计算和通信压力，还能充分利用边缘计算集群的资源，改善用户的响应需求和计算需求.边缘计算的关键不仅仅是计算性能，还需要高速的处理机制和通信机制.

据估计，未来50%的物联网数据将在数据源头附近进行处理，包括设备端和边缘侧.而且，随着边缘AI[4，5]的兴起，使得越来越多的人工智能应用如智能监控、车联网、自动驾驶等被部署在边缘侧.这不仅使得边缘节点所面临的数据量增加，边缘集群内通信的数据量也将骤增，这对边缘集群内的通信带宽提出了更高的要求.

物联网设备的庞大规模，决定了边缘计算节点的数量不可能少，而且是高度分布式的.他们不仅分布在办公室、工厂、校园等场所，有些甚至分布在遥远的、难以访问的地方.边缘计算节点不仅要执行数据采集、程序更新、设备管理和监控、机器学习模型更新等高级功能，而且还要进行实时的数据处理、AI计算等.这些决定了边缘计算节点需要低成本和支持复杂业务的属性.如何以较低的成本实现边缘计算节点对复杂任务的支持，将会是研究热点.

本文针对边缘计算对集群内高速通信的需求，提出一种以较低成本实现更高带宽的通信方案.相比于传统的通信方案，本文提出的方案能够在提供相同带宽的情况下，成本缩减2/3，延迟降低10%，丢包率降低60%.

2 相关工作

随着边缘计算所面临的数据和业务规模增加，边缘节点的实现方式也由单机扩展到了集群，而且集群内的通信数据量和频率的增加，对带宽也提出了更高的要求.虽然现在的网络设备带宽从最初的百兆增加至千兆，但是网络带宽的增长速度远不及网络流量，千兆带宽对于实时性较高的业务也显得捉襟见肘.万兆带宽的高昂价格，也使得其难以普及.在边缘集群内实现万兆带宽连接，将会增加边缘节点的成本负担.

现有的服务器操作系统的bonding模式[6]，可以通过多网卡增加服务器带宽，但其实现复杂，甚至需要专用的通信设备.而且bonding模式下，单条网络连接无法突破单张物理网卡理论速率的限制，要想充分利用多张网卡的叠加带宽，必须运用多线程多连接技术[7]，增加了使用难度，传统的网络协议和处理机制也使得网络带宽的利用率不高.现有通信技术主要从两方面进行改进：一方面通过硬件手段如FPGA等专用硬件进行数据包处理.赖裕平、马秀等人基于轮询系统的特性，提出一种基轮询的mac协议的FPGA设计[8].利用FPGA的可重构和灵活的特性从硬件手段进行通信性能的提升.虽然性能提升明显，降低了传输时延，提高了总线利用率，但是价格昂贵，也没有从根本上解决内核协议性能低下的问题.另一方面通过对现有的传输协议进行改进或者进行数据量压缩.例如Hei X等人提出一种基于UDP的Deque-ERUDP高效传输协议，通过协议动态的提升通信效率，降低网络阻塞[9].而Betzel F等人则从数据角度出发，采用近似压缩削减冗余数据量[10].然而这种方式容易丢失数据细节并消耗大量计算资源.在2014年，Intel针对x86架构推出了一种数据平面开发套件DPDK[11，12]，旨在应对网络中数据包的高速传输.DPDK利用用户态驱动、亲和性、内存大页和轮询等技术，使得网卡的收发速率可接近线速[13，14].DPDK绕过传统的内核协议栈，将数据链路层数据直接交给用户进程处理，减少了通信过程中数据的交付时延[15].DPDK对于多核和多网口的支持，能够成倍地增加通信带宽.DPDK的众多特性，能够极大地提升网络通信效率[16].

在成本受限和高速率传输需求的驱动下，改进网络协议和处理机制、多网口并行通信是一种新的出路.本文基于Intel的DPDK技术提出一种多网卡的高速传输方案.该方案首先利用DPDK用户态驱动技术，将数据包的处理移至用户空间，不仅绕过了系统内核协议栈，使网卡能够接近线速率传输，而且结合DPDK多核多网口的特性[17]，实现了多网口的并行高速传输和带宽叠加；其次，利用操作系统Socket本地回环机制[18，19]，为用户应用提供语言无关的调用接口，并且单条连接能够达到多张网卡的叠加带宽.

3 设 计

DPDK是绕过传统的内核协议栈，能够接近网卡的线速进行数据收发.再结合CPU多核特性，DPDK能够充分利用多张网卡的叠加带宽，使十张千兆网卡的叠加带宽能够与一张万兆网卡相匹敌，但成本却降低了很多.DPDK是C语言开发的，对于其他高级语言的支持不够友好.因此，本文想利用操作系统的套接字机制，实现DPDK对于多语言编程环境的支持.套接字的回环机制作为本地操作系统不同进程间的通信方式之一，能够实现DPDK进程与不同语言的用户进程之间进行通信.为了验证操作系统本地回环机制的带宽，本文在配有DDR3-1600Mhz的服务器上使用Iperf软件进行测试，最终测得本地回环的TCP通信带宽为60Gbps，经过优化的UDP通信带宽为14Gbps.操作系统本地回环机制的带宽不仅能过支持DPDK多张千兆网卡叠加带宽，甚至能够支持DPDK多张万兆网卡的叠加带宽.因此，本文的这种通信方案具有很高的升级空间和应用前景.

3.1 物理拓扑

DPDK利用UIO技术，将数据链路层数据直接交给用户进程处理.因此，用户需要自定义通信协议.DPDK基于数据链路层的数据包处理技术决定了网络拓扑简单，网络设备要求低，仅需要二层网络设备即可实现通信.

图1 物理拓扑Fig.1 Physical topology

如图1所示，本文的方案通过普通网线将服务器的多张网卡与二层交换机相连，对传统的网络结构没有影响.而且，集群节点的扩展与传统的交换机级联技术并无冲突，只需将待扩展服务器的多张网卡通过网线接入二层交换机即可实现.

3.2 系统框架

通过操作系统套接字的本地回环机制，本文的通信方案能够支持不同高级语言应用的使用.如图2所示，虚线左侧为传统通信，右侧为本文的通信方案.本文的通信方案与传统的通信方案相互兼容共存，可以为集群内的主机间提供两套通信方案，能够支持更加复杂的上层任务.本文的通信方案基于DPDK实现底层多网卡的数据收发，通过本地回环机制为用户应用提供统一的使用接口.而且，内部也实现了多网卡的负载均衡以及多应用的带宽均衡机制.

图2 系统框架Fig.2 System framework

4 实 现

4.1 通信模型

本文的通信方案利用本地回环机制为用户提供使用接口，底层的通信过程对用户是透明的.同时，通信过程也是全双工的，即在通信过程中数据发送和接收方可以同时互相通信.如图3所示，集群内主机Node1和Node2的通信过程.

图3 通信模型Fig.3 Communication model

为了实现本文的通信方案，我们自定义了通信协议，各字段含义与占用字节数如图4所示.DPDK是基于数据链路层的数据传输，Ethernet数据帧头内的目的MAC字段需要根据上层应用传入的目的节点决定.因此，需要实现类似于传统ARP网络协议的机制，可以根据节点编号获取目的主机的MAC地址列表，并本地缓存.上层用户应用需要填充服务类型、目的节点编号、目的回环端口、源节点编号、源回环端口、数据长度以及数据字段.Ethernet数据帧头内MAC地址有基于DPDK的模块进行填充，并通过负载均衡算法，选择合适的网口进行发送.

图4 协议字段Fig.4 Protocol field

4.2 内存模型

DPDK提供的许多内存对象模型来应对数据包的高速处理，本文利用MBuf与ring内存模型进行数据的处理.如图5所示，用户应用UA_1首先与本地回环公共端口进行连接(TCP需要，UDP不需要)，连接建立后即可发送数据，并且在接收端口进行数据接收.DPDK模块的主逻辑核在本地回环公共端口进行连接接入和数据接收，如果为TCP连接，需要将用户端的连接端口和连接套接字sock_fd对象记录到TCP_conn_Table 表中，UDP则不需要此步操作.主逻辑核接收到传输数据，首先从DPDK_rte环境中申请MBuf对象，并填充数据段以及节点编号、端口等信息，并将其放入由多个ring组成的公共发送缓冲区Public_send_buffer中.

DPDK模块的多个从逻辑核将从公共发送缓冲区Public_send_buffer中取出待发送MBuf，根据其目的节点和源节点的编号，从Node_MACs_table表中根据负载均衡算法和轮询算法选出本地发送网卡和目的接收网卡，将其MAC地址填充到MBuf的Ethernet数据帧头内，并在相应的网卡端口进行数据发送.多个从逻辑核也从各网卡端口不停地接收数据，根据数据包的服务类型字段和端口字段将数据包发送到对应的本地回环端口上.如果是TCP连接的数据包，需要通过TCP_conn_Table 表查找对应的连接套接字sock_fd，并将数据发送到该sock_fd.

4.3 端口负载均衡模型

对于多端口并行通信，端口负载均衡是必不可少的.传统的端口分发策略包括平衡循环法和权重轮询法，由于其只考虑数据收发的公平性，并未考虑到实际运行环境(如端口负载、端口性能等)，容易出现端口拥塞和大量丢包问题.高效的端口负载均衡算法才能够保证数据的高速率传输，过于复杂的算法并不适用.为了保证数据传输的高效性和稳定性，根据网口的实时负载信息，本文提出一种动态负载均衡机制，如图6所示.

发送核心从公共发送缓冲区Public_send_buffer中取出待发送mbuf，并从中提取五元组信息Quintuple(ptype，s_node，d_node，s_pump，d_pump)，其中s_node表示源节点编号，d_node表示目的节点编号，s_pump表示源端口号，d_pump表示目的端口号，ptype表示服务类型.首先，利用微软拓普利兹算法对提取到的五元组信息计算散列值，并与端口总数进行取模运算，选择出发送网口.根据选择出的网口负载情况，决定是否调用调整函数重新选择合适的发送网口.然后，根据轮询算法选择出目的节点的接收端口.最终得到一个最四元组Quad(s_port，s_mac，d_port，d_mac)，对应信息填入以太网包头后，调用DPDK端口发送数据.

图5 内存模型Fig.5 Memory model

根据DPDK提供的网口统计信息函数所获取到的网卡动态参数，建立网口负载信息模型，对端口选择提供参考.各符号在表1中进行了详细的说明.

图6 端口负载均衡模型Fig.6 Port load balancing model

对于普遍的全双工网卡，我们能够得到6个基本的动态参数N_ip_porti，N_op_porti，N_ib_porti，N_ob_porti，N_imp_porti，N_iep_porti.通过时间周期T进行采集，可以计算出网口在T周期内的各参数的速率状态V_ip_porti，V_op_porti，V_ib_porti，V_ob_porti，V_imp_porti，V_iep_porti，计算方式如公式(1)-式(7)所示.

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

(10)

(11)

(12)

(13)

(14)

表1 符号描述Table 1 Symbol description

为防止负载信息因采集干扰而出现突变，提高负载信息准确性，本文对计算得到的网口负载率进行自动调节，使其平滑过渡.平滑过渡计算公式如公式(15)、公式(16)所示，其中r为调整因子，通常设置为0.8.

Li*_porti(t)=r×Li_porti(t)+(1-r)×Li_porti(t-1)

(15)

Lo*_porti(t)=r×Lo_porti(t)+(1-r)×Lo_porti(t-1)

(16)

为了衡量当前网口负载率相比其他网口负载率是否过高，提出网口负载均衡度.网口负载均衡度能够体现出网口之间负载率的差异程度，对于是否调用调整函数具有参考价值.网口接收负载均衡度和发送负载均衡度由公式(19)、公式(20)给出定义.对于发送网口选择，当网口发送负载均衡度超过用户定义的负载均衡度阈值δ时，调用调整函数重新选择合适的发送网口；对于接收网口选择，当网口接收负载均衡度超过用户定义的负载均衡度阈值δ时，调用调整函数重新选择合适的接收网口.最终返回最优的网口信息四元组Quad(s_port, s_mac, d_port, d_mac).

(17)

(18)

(19)

(20)

4.4 带宽分配模型

由于本地回环机制的带宽远远高于网卡的带宽，因此需要对用户应用的发送进行限制.而且，在多用户应用发送数据时，还必须保证带宽公平性，限制每个用户应用的发送带宽.用户应用在发送数据时，可以根据速率调节模块计算值动态调整实时发送速率.如图7所示，DPDK模块将多网卡的总带宽共享到Share_info中的Total_BW.每个应用在发送数据之前，需要增加Share_info中的应用数量APP_NB.Rate_BW 为DPDK模块对所有网卡可用带宽的实时监控值.

图7 带宽分配模型Fig.7 Bandwidth allocation model

Vavailable_ob_porti(t)=Vmax_ob_porti-V_ob_porti(t)

(21)

(22)

(23)

(24)

(25)

5 实 验

5.1 实验环境

为了验证本文方案的性能，我们使用10台普通主机和一台48口千兆二层交换机搭建边缘集群.服务器配置详细信息如表2所示.每台服务器CPU为8核心Intel Xeon E3-1230 V2@3.3Ghz，两张4口Intel-I350-T4千兆网卡，共8网口.BPCM系统是基于DPDK-17.11.3版本开发，配置了8G大页内存，端口接收队列和发送队列各1个，且大小为1024，可调节.由于服务器CPU为8核心，且有8个网口，为避免CPU核心全占用对实验数据产生影响，本文采用4张网卡作为多网卡传输性能测试，占用5个CPU核心进行数据处理.

表2 主机配置信息Table 2 Host configuration information

实验前，我们首先使用Iperf3软件对主机的本地回环机制的带宽进行了测试，测试结果如表3所示.从表3中可以看出，随着线程数量的增加，TCP和UDP带宽有所增加，但当线程数量超过3时，带宽不再增加.而且在多线程时，各线程均匀分配总带宽.

表3 本地回环带宽测试Table 3 Local loop-back bandwidth test

5.2 性能评估

由于本文方案的DPDK模块并未实现可靠传输，因此选取传统UDP通信进行对比.套接字本地回环机制的TCP和UDP通信带宽远远高于多张网卡的叠加带宽，并非本文方案的通信瓶颈，因此实验中本地回环选取TCP或者UDP，并不会对实验数据产生太大影响.在接下来的实验中，我们方案的本地回环选取UDP作为通信方式.我们讨论了在单张千兆网卡和10张千兆网卡两种情况下传统UDP与本文方案的传输性能.通过多次发送10GB的数据，并且选取数据包大小分别为64B、128B、256B、516B、1024B，统计传输速率、丢包率以及传输延时.

如图8所示，在单张千兆网卡和单条连接的实验中，得益于DPDK用户驱动和内存大页等技术，使数据包的处理时间大幅降低，基于DPDK的本文传输方案在传输速率、丢包率和延时上都优于传统UDP通信.

现有操作系统对于多网卡的并行传输并不友好，虽然内核中提供多网卡的bonding模块，但该模块主要用于网络负载均衡与冗余.要实现带宽的增加，还需要交换机支持IEEE802.3ad 动态链路聚合.bonding模块虽然能够增加总带宽，但是无法突破单个连接的带宽限制(千兆网卡的理论速率).要实现总带宽的传输速率，还需要多连接与多线程技术的配合.为了进行多网卡并行传输性能对比，我们将发送服务器和接收服务器的4张网卡通过Linux系统的bonding模块绑定为模式4，并且启用LAN内交换机的LACP功能.

图8 单张千兆网口-单条连接Fig.8 Single gigabit NIC-single connection

在多网卡单条连接的实验中，传统UDP由于受到操作系统bonding模式底层实现的限制，传输速率无法突破单张网卡的理论速率.本文传输方案基于DPDK多核技术的支持，能够将4张网卡的总带宽充分利用起来，使用户在单条连接内即可使用多张网卡的叠加带宽，实验结果如图9所示.

在多网卡多连接的实验中，传统UDP通信方式中我们创建4个线程，每个线程建立一条连接，每条连接保证使用底层不同的物理网卡，进行并发性数据发送测试，结果如图10所示.传统的UDP虽然也可以使用多张网卡的叠加带宽，但是受限于系统内核协议栈的处理耗时，其带宽利用率不高，丢包率和传输时延大大增加.而且多连接多线程技术会增加编程难度，需要额外的数据同步技术支持，在大多数数据传输场景并不适用.本文的方案能够在单条连接内提供多张网卡的叠加带宽，不仅降低了编程难度，而且传输延时大幅降低.

图9 4张千兆网口-单条连接Fig.9 Four gigabit NICs-single connection

图10 4张千兆网口-多条连接Fig.10 Four gigabit NICs-multiple connections

对本文的端口负载均衡算法性能进行验证，与传统的端口轮询算法进行对比.通过多次发送10GB的数据，并且选取数据包大小分别为64B、128B、256B、516B、1024B.统计了各网口的负载率以及丢包率.如图11(a)所示，本文提出的端口负载均衡算法比轮询算法使各网口的负载率更加均匀，而且丢包率也相应的减少，如图11(b)所示.

图11 端口负载均衡Fig.11 Port load balancing

本文的速率调节模块是为了保证多用户应用带宽公平性和减少用户无效数据传输而设计的.实验中模拟5个应用程序依次发送10GB数据，并且选取数据包大小分别为64B、128B、256B、516B、1024B统计各应用的占用带宽和丢包率.如图12(a)所示，总带宽几乎完全利用，而且各用户应用均匀的分配带宽.图12(a)显示速率调节一定程度上减少丢包率.

图12 多应用带宽分配Fig.12 Multi-application bandwidth allocation

6 总 结

本文在边缘集群内对低成本、高速率通信带宽需求的驱动下，基于DPDK提出廉价多网卡提高带宽的方案.本文的方案不仅能够在单条连接内提供多张网卡的叠加带宽，降低编程难度，而且在可扩展性、可升级性、实施简便性上都更具优势.利用操作系统的Socket本地回环机制，本文的方案还能够为用户提供语言无关的调用接口.通过本文设计的端口负载均衡算法和速率调节模块，能够在均衡使用带宽的同时，减少丢包率和传输时延.最后，我们也做了成本对比，如表4所示，本文的通信方案能够将边缘集群内组网的成本降低2/3，同时提供相同的通信带宽.

本文的工作虽然能够以低成本提供高带宽，但在可靠性方面未进行研究.接下来的工作我们将在硬件可靠性和软件可靠性等方面进一步研究，如多交换机备份，可靠传输协议等.

表4 搭建10台规模万兆带宽连接边缘集群的网络设备成本Table 4 Cost of building 10 sets of 10-Gigabit bandwidth network equipment connected to the edge cluster