一个高速lvs-dr替代系统设计 -- 基于dpdk的高性能负载均衡器

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
简介:


LVS DR 原理

LVS-DR不同于普通的haproxy代理机制,它在网络中的作用层级更加底层。haproxy一般代理应用层的应用数据,所有的数据都会通过haproxy收发,导致了haproxy是一个性能瓶颈。而lvs-dr作用在IP和数据链路层,效率更高,并且只代理进入proxy的数据,应用的返回数据由应用服务器直接返回给client。

 


pros

cons

haproxy

可以基于端口做代理

真实server与proxy不需要在一个二层网络

单点问题

进出流量都走proxy,负载高

lvs-dr

只有request请求通过proxy,response数据直接返回给客户,性能高。

proxy和server必须在同一个二层网络

 


 

整个数据包的处理流程如下:

  1. Client要访问192.168.1.2上的服务

  2. request数据经过路由到达我们的proxy,上面运行着负载均衡器,负载均衡器通过策略算法,把目标MAC改成真实的Server MAC,并发送给目标MAC(这里决定了proxy和server只能在同一个二层网络中)

  3. Server收到请求后,将响应数据直接通过路由发送给client,不再经过proxy

 

 

基于DPDKDR架构

为什么要用DPDK呢?因为lvs是基于linux内核的,而linux内核处理包的速度太慢(10G网卡34Mpps),特别是对小包的处理,导致了性能瓶颈。而利用DPDK技术可以绕过linux内核从而直接处理网络数据报,写的好的话可以达到线速(10G网卡14Mpps)。

 

这个负载均衡器主要由两部分组成,转发器(Forwarder)和健康检查器(Monitor)。


Monitor通过ping或者arp的方式检查Server的状态,如果无法连接,则将此Server设置成unreachable的状态。

Forwarder通过hash算法把同一个来源的数据报发往同一个Server,以保证连接的一致性。

 

 

技术细节的考虑

来看看现在的设计距离google的设计还差多远?


还差着一个集群这么远。。。。。。。。。

目前只有单个proxy的设计,那作为一个集群要怎么玩呢?

首先是DNS层面,根据来源返回一个就近的VIP地址(如果在多个数据中心部署了的话)

然后是Router层面,使用了ECMP,把大量的请求分发到不同的负载均衡器上。

这就带来了一个问题,如何让同一个来源的请求总是能够到达同一个Server呢?有两个方法。

  1. 通过配置ECMP,把相同来源的请求都发往相同的负载均衡器。

  2. 使用一致性hash算法,让不同的负载均衡器在处理同一个请求时都能够转发到同一台Server。

 

 现有技术

在构思这篇博文的时候还没注意到VPP刚出的LoadBalancing,之前一直想自己实现一个lb application或者基于ovs-dpdk进行修改。但是搜索了一下之后发现了VPP LoadBalancing plugin这个plugin就是仿照了Maglev进行设计和实现的。

不知道VPP是何技术的可以去google一下,这是cisco开源的sdn技术,类似于openvswitch,自称转发性能比openvswitch高不知道哪去了。VPP底层基于dpdk或者netmap的技术实现高速收发数据报。

VPP实现的LB跟上面说的有一部分不太一致,就是从proxy到server的过程,VPP是用gre tunnel技术实现的,这样就不需要server和proxy在同一个二层网络里了,相应的,tunnel技术会增加每个封包的长度,需要相应的修改MTU,启用Jumbo Frame

最后的最后,至于VPP的LB性能如何,怎么用,我现在并没有试过:P

 

 Reference

  1. http://www.infoq.com/cn/articles/Maglev-Vortex

  2. http://oilbeater.com/%E5%8D%9A%E5%AE%A2/2016/11/21/google-loadbalancert.html

  3. https://docs.fd.io/vpp/16.12/md_plugins_lb-plugin_README.html

  4. https://github.com/chrisy/vpp/tree/master/plugins/lb-plugin

  5. http://www.xinghaixu.com/archives/472

 


      本文转自Tenderrain 51CTO博客,原文链接:http://blog.51cto.com/tenderrain/1983570,如需转载请自行联系原作者




相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
相关文章
|
11月前
|
负载均衡 算法 安全
slb高性能
【11月更文挑战第4天】
151 3
|
5月前
|
负载均衡 前端开发 JavaScript
LVS-DR模式、keepalived、Nginx与Tomcat合作,打造动静分离,高效负载均衡与高可用性
为了采用这样的架构,你需要对LVS-DR、Keepalived、Nginx与Tomcat有一定的理解和掌握,同时也需要投入一些时间去研究和配置,但是一旦你把它运行起来,你将会发现,这一切都是值得的。
198 11
|
8月前
|
负载均衡 网络协议 Linux
LVS,软负载均衡
LVS(Linux Virtual Server)是一项广泛应用的负载均衡技术,由章文嵩博士于1998年发起,自Linux 2.4.24版本起成为官方内核的一部分。LVS通过四层负载均衡技术实现高性能、高可用的服务器集群,支持多种调度算法和工作模式(如D-NAT、full-NAT、IP隧道、DR),适用于HTTP、数据库等应用。相比7层负载均衡器(如Nginx、HAProxy),LVS具有更高的并发处理能力和更低的资源消耗,适合大规模流量分发。本期文章详细介绍了LVS的工作原理、优势与不足,并对比了常见的负载均衡产品,帮助读者根据具体需求选择合适的解决方案。
1075 5
LVS,软负载均衡
|
10月前
|
负载均衡 算法 Linux
LVS+Keepalived:实现高效软负载均衡的利器
本文介绍了如何使用LVS(Linux Virtual Server)和Keepalived搭建高可用负载均衡集群。LVS通过不同调度算法将请求转发给后端服务器,而Keepalived基于VRRP协议实现服务高可用,避免IP单点故障。具体步骤包括环境准备、安装配置ipvsadm和Keepalived、启动服务及测试。文中还详细解释了配置文件中的关键参数,并提供了故障转移测试方法。最后,文章简要对比了软件、硬件和云负载均衡方案的特点,帮助读者选择合适的负载均衡策略。
1487 4
|
负载均衡 网络协议 算法
LVS 负载均衡部署的三种模式 与搭建dr模式具体步骤
LVS 负载均衡部署的三种模式 与搭建dr模式具体步骤
|
运维 负载均衡 网络协议
LVS+Keepalived 负载均衡
LVS+Keepalived 负载均衡
291 8
LVS+Keepalived 负载均衡
|
域名解析 运维 负载均衡
LVS+Keepalived 负载均衡(二)28-1
【8月更文挑战第28天】LVS+Keepalived 负载均衡 配置 LVS VIP
208 5
|
负载均衡 网络协议
使用LVS搭建集群实现负载均衡(二)安装使用
【8月更文挑战第8天】使用LVS搭建集群实现负载均衡(二)安装使用
204 5
|
存储 负载均衡 算法
使用LVS搭建集群实现负载均衡(一)
【8月更文挑战第8天】使用LVS搭建集群实现负载均衡
601 5
|
缓存 负载均衡 算法
在Linux中, LVS负载均衡有哪些策略?
在Linux中, LVS负载均衡有哪些策略?