掌桥专利:专业的专利平台
掌桥专利
首页

一种四层负载均衡的数据处理方法及相关装置

文献发布时间:2023-06-19 18:46:07


一种四层负载均衡的数据处理方法及相关装置

技术领域

本申请涉及计算机技术领域,特别是涉及一种四层负载均衡的数据处理方法及相关装置。

背景技术

目前,为了保持入口流量的稳定运行,一般采用四层负载均衡。四层负载均衡工作在网络七层开放式系统互联模型的第四层——传输层,基于IP(Internet Protocol,网际互连协议)和端口进行负载分摊。四层负载均衡服务器在接收到客户端请求后,通过修改数据包的地址信息将数据包转发到应用服务器。

相关技术中,一般软负载均衡方案是基于Linux内核的网络协议栈实现的,负载均衡集群对应用的高并发、高可用起着决定性的作用。然而,在高并发时,受限于Linux内核的处理能力,负载均衡设备的抗负载能力难以满足需求。

因此,如何提高负载均衡设备的抗负载能力,成为本领域技术人员关注的重点问题。

发明内容

基于上述问题,本申请提供了一种四层负载均衡的数据处理方法及相关装置,可以提高负载均衡集群的抗负载能力。

本申请实施例公开了如下技术方案:

第一方面,本申请提供了一种四层负载均衡的数据处理方法,所述方法包括:

接收访问端发送的数据包;

基于所述数据包携带的信息,从多个网卡接收队列中确定用于接收所述数据包的第一网卡接收队列;

通过所述第一网卡接收队列以及预先建立的用户态轻量级IP协议栈,向多个IP虚拟服务器IPVS中与所述第一网卡接收队列对应的第一IPVS转发所述数据包;

基于所述第一IPVS中预先配置的负载均衡策略,确定多个真实服务器中与所述数据包对应的目的真实服务器;

向所述目的真实服务器转发所述数据包。

可选地,所述基于所述数据包携带的信息,从多个网卡接收队列中确定接收所述数据包的第一网卡接收队列,包括:

基于所述数据包携带的源IP、源端口、目的IP、目的端口以及协议类型信息以及预设的分流机制,从多个网卡接收队列中确定接收所述数据包的第一网卡接收队列。

可选地,所述基于所述数据包携带的信息,从多个网卡接收队列中确定接收所述数据包的第一网卡接收队列之后,所述方法还包括:

将所述数据包通过直接存储器访问技术保存到处理器缓存或内存中。

可选地,所述通过所述第一网卡接收队列以及预先建立的用户态轻量级IP协议栈,向多个IP虚拟服务器IPVS中与所述第一网卡接收队列对应的第一IPVS转发所述数据包,包括:

多个转发CPU中与所述第一网卡接收队列绑定的第一转发CPU从所述第一网卡接收队列获取所述数据包;

通过预先建立的用户态轻量级IP协议栈,所述第一转发CPU向多个IP虚拟服务器IPVS中与所述第一转发CPU绑定的第一IPVS转发所述数据包。

可选地,所述多个转发CPU中与所述第一网卡接收队列绑定的第一转发CPU从所述第一网卡接收队列获取所述数据包,包括:

多个转发CPU中与所述第一网卡接收队列绑定的第一转发CPU周期性轮询所述第一网卡接收队列,获取所述数据包。

可选地,所述向所述目的真实服务器转发所述数据包,包括:

将所述数据包携带的目的IP以及目的端口修改为所述目的真实服务器的IP以及端口,以向所述目的真实服务器转发所述数据包。

可选地,所述向所述目的真实服务器转发所述数据包之后,所述方法还包括:

接收所述目的真实服务器发送的响应数据;

通过所述第一转发CPU以及所述第一IPVS向所述访问端转发所述响应数据。

第二方面,本申请提供了一种四层负载均衡的数据处理装置,所述装置包括:接收模块,CPU确定模块,第一转发模块,目的真实服务器确定模块以及第二转发模块;

所述接收模块,用于接收访问端发送的数据包;

所述接收队列确定模块,用于基于所述数据包携带的信息,从多个网卡接收队列中确定用于接收所述数据包的第一网卡接收队列;

所述第一转发模块,用于通过所述第一网卡接收队列以及预先建立的用户态轻量级IP协议栈,向多个IP虚拟服务器IPVS中与所述第一网卡接收队列对应的第一IPVS转发所述数据包;

所述目的真实服务器确定模块,用于基于所述第一IPVS中预先配置的负载均衡策略,确定所述数据包对应的目的真实服务器;

所述第二转发模块,用于向所述目的真实服务器转发所述数据包。

第三方面,本申请提供了一种服务器,所述服务器包括:

存储器,用于存储计算机程序;

处理器,用于执行所述计算机程序时实现如第一方面任一项所述的四层负载均衡的数据处理方法的步骤。

第四方面,本申请提供了一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如第一方面任一项所述的四层负载均衡的数据处理方法的步骤。

相较于现有技术,本申请具有以下有益效果:

本申请提供了一种四层负载均衡的数据处理方法,该方法中,首先,接收访问端发送的数据包;然后,基于数据包携带的信息,从多个网卡接收队列中确定用于接收数据包的第一网卡接收队列;接着,通过第一网卡接收队列以及预先建立的用户态轻量级IP协议栈,向多个IP虚拟服务器IPVS中与第一网卡接收队列对应的第一IPVS转发所述数据包;继而,基于第一IPVS中预先配置的负载均衡策略,确定多个真实服务器中与数据包对应的目的真实服务器;最后,向目的真实服务器转发数据包。由此,本申请实施例采用内核旁路技术,绕过Linux内核协议栈,而采用建立的用户态轻量级IP协议栈,缩短了协议栈数据处理流程,减少了CPU性能消耗,提高了负载均衡设备的抗负载能力。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种负载均衡设备结构图;

图2为本申请实施例提供的一种四层负载均衡的数据处理方法流程图;

图3为本申请实施例提供的一种四层负载均衡的数据处理装置示意图。

具体实施方式

本申请实施例提供了一种四层负载均衡的数据处理方法及相关装置,可以有效提高负载均衡集群的抗负载能力。

在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

当然,上述术语的解释仅为方便理解而做出,而不具有任何限制含义。

为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。

参见图1,为本申请实施例的示例性应用场景。其中,本申请实施例提供的方法可以应用于如图1所示的负载均衡设备中,负载均衡设备可以包括多个网卡、多个转发CPU以及多个IPVS(Internet Protocol Virtual Server,IP虚拟服务器)。多个网卡可以包括网卡1、网卡2,多个转发CPU可以包括CPU1、CPU2、CPU3、CPU4。网卡用于确定与数据包对应的转发CPU,转发CPU用于基于该CPU与IPVS的绑定关系转发数据包,IPVS用于基于预先配置的负载均衡策略为数据包分配真实服务器(Real Servers)。当然,本申请实施例还可以应用到其他场景中,在此不进行限制。

需要注意的是,上述应用场景仅是为了便于理解本申请而示出,本申请的实施方式在此方面不受任何限制。相反,本申请的实施方式可以应用于适用的任何场景。

参见图2,该图为本申请实施例提供的一种四层负载均衡的数据处理方法流程图,该方法是针对Linux虚拟服务器(Linux Virtual Server,LVS)这一开源负载均衡项目面临的Linux内核瓶颈问题,提出的内核优化版负载均衡方案XLB,XLB采用经典的Master/Worker线程模型,其中,Master处理控制面,如参数配置、统计数据的获取等,Worker实现核心负载均衡、调度以及数据转发等功能。

本申请实施例采用内核旁路技术,绕过Linux内核协议栈(TCP/IP协议栈);DPDK(Data Plane Development Kit)是Intel提供的一种内核旁路数据平面开发工具集,专注于网络应用中数据包的高性能处理,DPDK应用程序运行在用户空间,可以绕过Linux内核协议栈对数据包进行处理,从而发挥内核旁路技术高性能、低延迟的特点。如图2所示,该方法可以包括:

S201:负载均衡设备接收访问端发送的数据包。

示例性地,访问端可以通过等价路由(Equal Cost Multi Path,ECMP)经由入口虚拟IP(Virtual IP Address,VIP)向负载均衡设备发起请求,负载均衡设备中的网卡由此可以接收到访问端发送的数据包。

S202:负载均衡设备基于数据包携带的信息,从多个网卡接收队列中确定用于接收数据包的第一网卡接收队列。

作为示例,负载均衡设备中可以包括多个网卡,网卡可以支持多个网卡接收队列,基于数据包携带的例如源IP、源端口、目的IP、目的端口以及协议类型等信息,通过预设的分流机制,可以从多个网卡接收队列中确定接收数据包的第一网卡接收队列。例如,XLB服务启动时,网卡经由DPDK网卡驱动可以进行虚拟化,成为XLB专用网卡,当负载均衡设备接收到数据包时,XLB专用网卡可以通过DPDK网卡驱动的分流机制,从多个网卡接收队列中确定接收数据包的第一网卡接收队列,由此,将数据包分流到确定出的第一网卡接收队列中。

可选地,分流机制可以是硬件接收端缩放(Receive Side Scaling,RSS)算法,具体地,RSS算法可以计算数据包的源IP、源端口、目的IP、目的端口以及协议类型的哈希值,根据哈希值确定网卡接收队列,例如,可以将哈希值与网卡接收队列数取余,得到队列的索引,该索引对应的网卡接收队列即被确定为第一网卡接收队列,将数据包放入第一网卡接收队列。

S203:负载均衡设备通过第一网卡接收队列以及预先建立的用户态轻量级IP协议栈,向多个IP虚拟服务器IPVS中与第一网卡接收队列对应的第一IPVS转发数据包。

作为示例,用户态轻量级IP协议栈是在DPDK的基础上重建的定制化的TCP/IP协议栈,可以只具有基本的IPv4/IPv6、路由、ARP/NS/NA、ICMPv4/ICMPv6的功能,从而缩短了协议栈数据处理流程,减少CPU性能消耗。

示例性地,网卡接收队列数可以与转发CPU数相同,网卡接收队列与转发CPU通过配置文件一一对应绑定,多个转发CPU中与第一网卡接收队列绑定的转发CPU为第一转发CPU,由第一转发CPU从第一网卡接收队列获取数据包,具体地,多个转发CPU中与第一网卡接收队列绑定的第一转发CPU可以周期性轮询所述第一网卡接收队列,获取数据包;多个转发CPU与多个IP虚拟服务器IPVS一一对应绑定,其中,与第一转发CPU绑定的为第一IPVS,第一转发CPU可以通过预先建立的用户态轻量级IP协议栈向第一IPVS转发数据包。

由此,将多个负责转发的进程/线程与转发CPU进行亲和性设置,强行绑定在一起,可以禁止操作系统将转发进程/线程调度到其他CPU,每个转发CPU只有一个进程/线程,没有了多进程/线程并发的情况,也就不存在进程/线程上下文切换的需求。另一方面,使用内核旁路技术后,数据包的收发和处理都在用户态下进行,也不存在用户态和内核态的上下文切换,从而避免了上下文切换,其他进程/线程不会被调度到这些转发CPU,Worker也不会迁移到其他CPU造成缓存失效,不同的转发CPU处理不同的网卡接收队列的数据,分摊工作量,可以实现并行处理和线性扩展,提高负载均衡设备的并行处理能力。

在本申请实施例中,由于每个网卡队列绑定有对应的CPU,该CPU仅仅处理对应的网卡队列的数据,实现了如connection表、neighbor表以及router表等需要频繁修改或查找的关键数据的单核化,从而可以避免各个网卡队列之间的数据处理相互影响。在具体的实施过程中,由于实现了关键数据的单核化,可以避免对数据进行加锁处理。而由于没有加锁处理,在数据处理中可以避免数据锁导致的等待问题,降低数据进行处理的时长,提高处理速度。此外,各个Worker使用DPDK的API处理不同的网卡队列,每个Worker处理某网卡的一个接收队列,一个发送队列,实现了处理能力随CPU核心、网卡队列数的增加而线性增长,提高了处理数据的能力。

S204:负载均衡设备基于第一IPVS中预先配置的负载均衡策略,确定多个真实服务器中与数据包对应的目的真实服务器。

可选地,IP虚拟服务器IPVS可以将数据包携带的目的IP、目的端口以及协议类型与IPVS层中的数据进行比较,若数据匹配,则可以基于该IPVS中预先配置的负载均衡策略,确定多个真实服务器中的哪一个是与该数据包对应的目的真实服务器。其中,负载均衡策略可以包括轮询法、随机法以及最小连接法中的至少一个。

S205:负载均衡设备向目的真实服务器转发数据包。

示例性地,负载均衡设备中的IPVS可以将数据包携带的目的IP以及目的端口修改为目的真实服务器的IP以及端口,以向目的真实服务器转发数据包。可选地,IPVS可以经由CPU以及与真实服务器建立连接的网卡将修改了目的IP以及目的端口的数据包转发至其对应的目的真实服务器。

由此,本申请实施例采用内核旁路技术,绕过Linux内核协议栈,而采用建立的用户态轻量级IP协议栈,缩短了协议栈数据处理流程,减少了CPU性能消耗;此外,将多个负责转发的进程/线程与转发CPU进行亲和性设置,不同的转发CPU处理不同的网卡接收队列的数据,分摊工作量,可以实现并行处理和线性扩展,提高了负载均衡设备的并行处理能力。

在本申请提供的另一些实施例中,基于数据包携带的信息,从多个网卡接收队列中确定接收数据包的第一网卡接收队列之后,该方法还包括:将数据包通过直接存储器访问技术保存到处理器缓存或内存中。示例性地,可以使用零拷贝技术,将数据包从网卡借由DMA(Direct Memory Access,直接存储器访问)控制单元直接复制到内存,也即将数据包复制到用户态,当负载均衡设备需要使用数据包时,可以直接使用被复制到内存中的数据包,由此可以省去数据包在内核态和用户态之间复制的开销,提高负载均衡设备的性能。

可选地,将数据包通过直接存储器访问技术保存到处理器缓存或内存中之后,数据包接收标志位可以设置为表示有新报文;负载均衡设备可以周期性轮询数据包接收标志位,若发现其被设置为表示有新报文,则处理相应的数据包。示例性地,第一网卡接收队列接收数据包后,可以将数据包复制到内存,并将第一网卡接收队列中的数据包接收标志位设置为表示有新报文,当第一转发CPU周期性轮询第一网卡接收队列时,将识别到数据包接收标志位表示有新报文,第一转发CPU基于此可以获取内存中相应的数据包。由此,可以检测是否有新的数据包需要处理,而获取数据包的过程中不需中断处理,即不需要进行中断处理所需的保存CPU状态寄存器信息、中断服务程序以及恢复CPU状态寄存器信息的过程,可以使CPU全力进行数据包的接收和处理,减少接收数据包的处理延时,提高数据处理能力。

在本申请提供的又一些实施例中,参见图1,网卡1与访问端建立连接,网卡2与真实服务器建立连接。负载均衡设备中的网卡2可以接收目的真实服务器发送的响应数据,其中,响应数据为目的真实服务器接收到数据包后产生,而后,可以基于进程/线程与CPU的绑定关系,通过转发数据包过程所用的第一转发CPU和第一IPVS向访问端转发响应数据。

在本申请提供的再一些实施例中,负载均衡设备中的控制面CPU可以与多个转发CPU通过无锁队列进行通信。当Master需要获取Worker的各种统计信息或Master将路由、黑名单等配置同步到各个Worker时,需要进行跨内核通信,即跨CPU通信。为了避免内核间互相影响、相互等待导致性能降低,本申请实施例可以采用DPDK的无锁rte_ring库,保证通信是无锁的。进一步地,可以封装一层异步消息机制来实现Master与Worker之间的跨内核通信,从而使CPU内核间逻辑解耦,解除依赖,避免因互相等待而影响性能。

可选地,在一些实施例中,采用大页内存以提高TLB(Translation LooksideBuffer,页表缓存)的查找命中率。

可选地,在一些实施例中,预先创建内存池作为预分配内存,用于存储负载均衡设备运行过程中所产生或使用的数据,在服务结束之后再归还给操作系统。使用预分配内存可以避免如使用操作系统原生的malloc/free频繁分配和释放内存的操作,提高数据处理效率。

可选地,在一些实施例中,使用NUMA(Non Uniform Memory Access)感知提高内存访问效率。在NUMA结构中,每个CPU访问本地存储都快于访问其他CPU的存储,让CPU访问在同一个NUMA节点的网卡能够提高数据处理效率。

应用上述四层负载均衡的数据处理方法的XLB集群需要部署在具有ECMP的路由器之后,以便于将入口VIP配置在多个XLB集群。XLB适用于四层负载转发,即基于IP和端口进行请求分发。

参见图3,该图为本申请实施例提供的一种四层负载均衡的数据处理装置示意图,该装置包括:接收模块301,CPU确定模块302,第一转发模块303,目的真实服务器确定模块304以及第二转发模块305。

接收模块301,用于接收访问端发送的数据包。

接收队列确定模块302,用于基于所述数据包携带的信息,从多个网卡接收队列中确定用于接收数据包的第一网卡接收队列。

第一转发模块303,用于通过第一网卡接收队列以及预先建立的用户态轻量级IP协议栈,向多个IP虚拟服务器IPVS中与第一网卡接收队列对应的第一IPVS转发数据包。

目的真实服务器确定模块304,用于基于第一IPVS中预先配置的负载均衡策略,确定数据包对应的目的真实服务器。

第二转发模块305,用于向目的真实服务器转发数据包。

由此,本申请实施例采用内核旁路技术,绕过Linux内核协议栈,而采用建立的用户态轻量级IP协议栈,缩短了协议栈数据处理流程,减少了CPU性能消耗,提高了负载均衡设备的抗负载能力。

本申请实施例还提供一种服务器,包括:

存储器,用于存储计算机程序;

处理器,用于执行所述计算机程序时实现如以上实施例所述的四层负载均衡的数据处理方法的步骤。

本申请实施例还提供一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如以上实施例所述的四层负载均衡的数据处理方法的步骤。

需要说明的是,本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于服务器及存储介质实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的服务器及存储介质实施例仅仅是示意性的,其中作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元提示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。

以上所述,仅为本申请的一种具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应该以权利要求的保护范围为准。

技术分类

06120115686768