提起负载均衡设备,程序员基本都打过交道。硬件的比如 F5、netscaler, 以前在赶集网就用 netscaler, 后来过保也没续... 软件的有 lvs、haproxy,当然了七层的 nginx 也算。关于转发模式也知道一些 dr、nat、tunnel 等等,轮循的算法有 rr、wrr、wlc 等等。但是内部原理除了网络同学,大部分同学只是简单的使用,借着这次调研 dpdk
机会,读读源码,一勺烩了。
背景
现代互联网流量越来越大,网卡吞吐能力也越来越强,从最早的 1gb, 到现在 10gb 是标配,以后可能 100gb, 所以负载均衡设备的线性扩展也遇到了瓶劲。谷歌前几年发布了关于 LB
的论文 Maglev
, 估计是受启发,各大公司相继造 LB
轮子,爱奇异和小米同时用 dpdk
+ lvs
技术开发了自己的负载均衡软件,要是小米先开源,这名和利早就是小米同学的了... 虽然这些技术都是开源并且己知,很成熟的,能站在了巨人的肩膀上,将技术组合起来并开源也很历害,感谢爱奇异的大牛们。
lvs 的问题
IT 行业技术变化真快,刚毕业时 lvs
还是负载均衡界的小甜甜,才过了几年就成了牛夫人。中小公司 lvs
足够好用,但是内核比较低,尤其 fullnat
模式应用非常广泛。那 lvs
问题是什么呢?
主要是内核太慢,网络栈代码写的也不好,各种历史问题,很多 if
语句,这个很影响分支预测的。而lvs
的数据需要经过内核网络栈,再拷贝到用户空间,性能自然上不去。谷歌的 Maglev
完全是绕过了内核,从网卡收数据直接送到 LB
. 这就是所谓的内核旁路 kernel bypass
技术,这个技术现在比较成熟,dpdk
, open onload
, netmap
等等。当年谷歌可是硬撸的,理念和技术水平领先一个时代。
什么是 dpvs
那再回头说什么是 dpvs 呢?dpdk
+ lvs
,可以理解为经过内核旁路的 lvs ++
. 对于原来熟悉 lvs
的人不会陌生。看官网得知,转发模式完全来自 lvs
,就连代码部份函数名都是一样的。
上图是官网的一张图,右侧都是
dpvs
列出的优化点。那这些优化点难不难呢?难,但是,dpdk
都做好了。dpdk
程序最大的特点就是每个逻辑核都有自己的数据,有一个封装好的宏 RTE_PER_LCORE
,即然都本地化了,那自然也没有锁开销。看源码得知,mbuf
分配,定时器这些都是本地化的。
dpvs 优点
lvs
相关的模式,转发算法目前没看到区别。性能优化都是 dpdk
层面的,减少 cpu cache miss, 减少 false sharing,NUMA 友好,绑定 cpu,其实想想这些不都是软件优化共性嘛。
- 用户态内核旁路,少去内核到用户空间的拷贝
- 网卡队列与 cpu 的绑定
-
flow director
增加返程数据亲和性,往返都由同一个 cpu 处理 - cpu 数据本地化,无锁
- 实现轻量级 tcp stack,专用的性能自然好
dpvs 缺点
- 缺点还是有的,由于他是
lvs
衍生出来的,所以lvs
各个模式的缺点他都有。 - 相比
Maglev
, 目前dpvs
更适配intel
网卡,看官网也支持其它厂商网卡。这其实算是dpdk
的限制,毕竟intel
的框架。 - 由于网卡被
dpvs
专用,可能还需要专配一个网卡用于运维,或是开kni
也行。 - 不支持
ipv6
, 现在有强推的趋势,想对标Maglev
, 还是越早支持越好。
小结
先写这些,之后再从源码角度分析 dpvs
业务处理流程,和各种优化的细节。
网友评论