干货 | 携程基于DPDK的高性能四层负载均衡实践

作者简介

 

Yellowsea,携程资深技术支持工程师,负责四层负载均衡研发及私有云k8s cloud provider开发,关注Kubernetes、Linux Kernel、分布式系统等技术领域。

前言

在携程的服务流量接入架构中,一般是采用四层负载均衡与七层负载均衡相结合的方式,其中四层负载均衡支撑着业务运行的关键部分。在业务流量不断增长的过程中,不断考验着四层负载均衡的性能及可靠性。由于原硬件四层负载均衡存在成本高、采购周期长、HA工作模式等问题,原有的体系难以满足快速增长的业务需求,迫切需要在开源社区中寻找高性能四层负载均衡软件化的解决方案。

本文主要讲述基于开源的DPVS打造携程的高性能四层软件负载均衡TDLB (Trip.com Dpdk LoadBalancer),其极大的提升了设备的转发性能,具有高可靠、可扩展、易使用等特性。


一、TDLB高性能实现

传统LVS负载均衡的功能与硬件设备类似,但由于其性能存在瓶颈,难以满足携程四层负载均衡服务的实际业务场景需求。DPVS (https://github.com/iqiyi/dpvs) 结合DPDK的特性,解决了LVS的性能瓶颈,同时又能满足原有的负载均衡服务需求。


1.1 DPDK

在内核中,从网卡获取数据包是通过硬件中断模式完成,内核态与用户态的切换耗时,而且切换导致cache命中率下降,影响处理数据包的性能。

在DPDK中采用kernel bypass的设计,通过应用程序主动轮询的方式从网卡获取数据包,使应用程序维持在用户态运行,避免内核态与用户态切换的耗时问题,提升处理数据包时cache的命中率。


1.2 会话无锁

初期的LVS采用全局的会话资源供多个core同时使用,多个core之间会产生资源的竞争,带来了锁的问题。

2d8a5baacce6b94c17df7ce1e6953ede.png

TDLB主要使用fullnat模式,为了避免core与core之间的资源竞争,我们设计了percore的会话,作为有状态的四层负载均衡必须保证入向流量与出向流量分配至同一个core,出向流量才能匹配上原先建立的会话。

入向流量可以利用RSS将数据包散列至各个队列,而每个core绑定对应的队列,对于相同的数据包 (sip,sport,dip,dport) RSS会被分配至同一core。为了保证出向回程流量还经过原先的core可以为每个core分配不同的SNAT IP,在fullnat模式中,client IP会被转化成SNAT IP,到达server后,server回应报文的目的ip就是原先的SNAT IP,此时可以借助网卡的FDIR (Flow Director) 技术来匹配SNAT IP,将回程报文分配至对应的core,确保数据流的出向流量与入向流量分配至同一core。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值