侧边栏壁纸
博主昵称
WX

  • 累计撰写 13 篇文章
  • 累计收到 1 条评论

LVS 工作原理图文讲解

W●X
2021-08-11 / 0 评论 / 57 阅读 / 正在检测是否收录...

LVS 工作原理图文讲解,非常详细!

一、负载均衡由来

在业务初期,我们一般会先使用单台服务器对外提供服务。随着业务流量越来越大,单台服务器无论如何优化,无论采用多好的硬件,总会有性能天花板,当单服务器的性能无法满足业务需求时,就需要把多台服务器组成集群系统提高整体的处理性能。不过我们要使用统一的入口方式对外提供服务,所以需要一个 流量调度器 通过均衡的算法,将用户大量的请求均衡地分发到后端集群不同的服务器上。这就是我们后边要说的 负载均衡。
使用负载均衡带来的好处:

• 提高了系统的整体性能
• 提高了系统的扩展性
• 提高了系统的可用性

二、负载均衡类型
广义上的负载均衡器大概可以分为 3 类,包括:DNS 方式实现负载均衡、硬件负载均衡、软件负载均衡。
2.1 DNS 实现负载均衡
DNS 实现负载均衡是最基础简单的方式。一个域名通过 DNS 解析到多个 IP,每个 IP 对应不同的服务器实例,这样就完成了流量的调度,虽然没有使用常规的负载均衡器,但也的确完成了简单负载均衡的功能。

通过 DNS 实现负载均衡的方式,最大的优点就是实现简单,成本低,无需自己开发或维护负载均衡设备,不过存在一些缺点:

• 服务器故障切换延迟大,服务器升级不方便。我们知道 DNS 与用户之间是层层的缓存,即便是在故障发生时及时通过 DNS 修改或摘除故障服务器,但中间由于经过运营商的 DNS 缓存,且缓存很有可能不遵循 TTL 规则,导致 DNS 生效时间变得非常缓慢,有时候一天后还会有些许的请求流量。
• 流量调度不均衡,粒度太粗。DNS 调度的均衡性,受地区运营商 LocalDNS 返回 IP 列表的策略有关系,有的运营商并不会轮询返回多个不同的 IP 地址。另外,某个运营商 LocalDNS 背后服务了多少用户,这也会构成流量调度不均的重要因素。
• 流量分配策略比较简单,支持的算法较少。DNS 一般只支持 RR 的轮询方式,流量分配策略比较简单,不支持权重、Hash 等调度算法。
• DNS 支持的 IP 列表有限制。我们知道 DNS 使用 UDP 报文进行信息传递,每个 UDP 报文大小受链路的 MTU 限制,所以报文中存储的 IP 地址数量也是非常有限的,阿里 DNS 系统针对同一个域名支持配置 10 个不同的 IP 地址。
• 实际上生产环境中很少使用这种方式来实现负载均衡,毕竟缺点很明显。文中之所以描述 DNS 负载均衡方式,是为了能够更清楚地解释负载均衡的概念。一些大公司一般也会利用 DNS 来实现地理级别的负载均衡,实现就近访问,提高访问速度,这种方式一般是入口流量的基础负载均衡,下层会有更专业的负载均衡设备实现的负载架构。
2.2 硬件负载均衡
硬件负载均衡是通过专门的硬件设备来实现负载均衡功能,类似于交换机、路由器,是一个负载均衡专用的网络设备。目前业界典型的硬件负载均衡设备有两款:F5 和 A10。这类设备性能强劲、功能强大,但价格非常昂贵,一般只有 “土豪” 公司才会使用此类设备,普通业务量级的公司一般负担不起,二是业务量没那么大,用这些设备也是浪费。
硬件负载均衡的优点:

• 功能强大:全面支持各层级的负载均衡,支持全面的负载均衡算法。
• 性能强大:性能远超常见的软件负载均衡器。
• 稳定性高:商用硬件负载均衡,经过了良好的严格测试,经过大规模使用,稳定性高。
• 安全防护:除了具备负载均衡外,还具备防火墙、防 DDoS 攻击等安全功能,貌似还支持 SNAT 功能。

硬件负载均衡的缺点:

• 价格昂贵,就是贵。
• 扩展性差,无法进行扩展和定制。
• 调试和维护比较麻烦,需要专业人员。

注:至今没有用过硬件负载均衡,不过有幸曾经与 F5 有过一面之缘。
2.3 软件负载均衡
软件负载均衡,可以在普通的服务器上运行负载均衡软件,实现负载均衡功能。目前常见的有 Nginx、HAproxy、LVS。其中的区别:

• Nginx :是 7 层负载均衡,支持 HTTP、E-mail 协议,貌似也支持 4 层负载均衡了。
• HAproxy :是 7 层负载均衡软件,支持 7 层规则的设置,性能也很不错。OpenStack 默认使用的负载均衡软件就是 HAproxy。
• LVS :是纯 4 层的负载均衡,运行在内核态,性能是软件负载均衡中最高的,因为是在四层,所以也更通用一些。

软件负载均衡的优点:

• 简单:无论是部署还是维护都比较简单。
• 便宜:买个 Linux 服务器,装上软件即可。
• 灵活:4 层和 7 层负载均衡可以根据业务进行选择;也可以根据业务特点,比较方便进行扩展和定制功能。

三、开源负载均衡器 LVS
软件负载均衡主要包括:Nginx、HAproxy 和 LVS。其实三款负载均衡软件都十分常用。四层负载均衡基本上都会使用 LVS,据了解如 BAT 等大厂都是 LVS 重度使用者,就是因为 LVS 非常出色的性能,能为公司节省很大成本。
了解到很多大公司使用的 LVS 都是定制版的,做过很多性能方面的优化,比开源版本性能会高出很多。目前只有淘宝开源过优化过的 alibaba/LVS,支持 FNAT 模式,但是也很久没有更新过了。另外爱奇艺去年开源出了 DPDK 版本的 LVS,名叫 DPVS,性能非常强悍。 https://github.com/iqiyi/dpvs
目前较为熟悉的负载均衡软件是 LVS,且大部分中小型公司使用开源的 LVS 足够满足业务需求。
3.1 netfilter基本原理
LVS 是基于 Linux 内核中 netfilter 框架实现的负载均衡系统,所以要学习 LVS 之前必须要先简单了解 netfilter 基本工作原理。netfilter 其实很复杂也很重要,平时我们说的 Linux 防火墙就是 netfilter,不过我们平时操作的都是 iptables,iptables 只是用户空间编写和传递规则的工具而已,真正工作的是 netfilter。通过下图可以简单了解下 netfilter 的工作机制:

netfilter 是内核态的 Linux 防火墙机制,作为一个通用、抽象的框架,提供了一整套的 hook 函数管理机制,提供诸如数据包过滤、网络地址转换、基于协议类型的连接跟踪的功能。
通俗点讲,就是 netfilter 提供一种机制,可以在数据包流经过程中,根据规则设置若干个关卡(hook 函数)来执行相关的操作。netfilter 总共设置了 5 个点,包括:PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING

• PREROUTING :刚刚进入网络层,还未进行路由查找的包,通过此处;
• INPUT :通过路由查找,确定发往本机的包,通过此处;
• FORWARD :经路由查找后,要转发的包,在POST_ROUTING之前;
• OUTPUT :从本机进程刚发出的包,通过此处;
• POSTROUTING :进入网络层已经经过路由查找,确定转发,将要离开本设备的包,通过此处;

当一个数据包进入网卡,经过链路层之后进入网络层就会到达 PREROUTING,接着根据目标 IP 地址进行路由查找,如果目标 IP 是本机,数据包继续传递到 INPUT 上,经过协议栈后根据端口将数据送到相应的应用程序;应用程序处理请求后将响应数据包发送到 OUTPUT 上,最终通过 POSTROUTING 后发送出网卡。如果目标 IP 不是本机,而且服务器开启了 forward 参数,就会将数据包递送给 FORWARD 上,最后通过 POSTROUTING 后发送出网卡。
3.2 LVS基本原理
LVS 是基于 netfilter 框架,主要工作于 INPUT 链上,在 INPUT 上注册 ip_vs_in HOOK 函数,进行 IPVS 主流程,大概原理如图所示:

• 当用户访问 www.sina.com.cn 时,用户数据通过层层网络,最后通过交换机进入 LVS 服务器网卡,并进入内核网络层。
• 进入 PREROUTING 后经过路由查找,确定访问的目的 VIP 是本机 IP 地址,所以数据包进入到 INPUT 链上。
• IPVS 是工作在 INPUT 链上,会根据访问的 vip+port 判断请求是否 IPVS 服务,如果是则调用注册的 IPVS HOOK 函数,进行 IPVS 相关主流程,强行修改数据包的相关数据,并将数据包发往 POSTROUTING 链上。
• POSTROUTING 上收到数据包后,根据目标 IP 地址(后端服务器),通过路由选路,将数据包最终发往后端的服务器上。

开源 LVS 版本有 3 种工作模式,每种模式工作原理截然不同,说各种模式都有自己的优缺点,分别适合不同的应用场景,不过最终本质的功能都是能实现均衡的流量调度和良好的扩展性。主要包括以下三种模式:

• DR 模式
• NAT 模式
• Tunnel 模式

另外必须要说的模式是 FullNAT,这个模式在开源版本中是模式没有的,代码 没有合并进入内核主线版本,后面会有专门章节详细介绍 FullNAT 模式。下边分别就 DR、NAT、Tunnel 模式分别详细介绍原理。
3.3 DR 模式实现原理
LVS 基本原理图(上图)中描述的比较简单,表述的是比较通用流程。下边会针对 DR 模式的具体实现原理,详细的阐述 DR 模式是如何工作的。

其实 DR 是最常用的工作模式,因为它的强大的性能。下边以一次请求和响应数据流的过程来描述 DR 模式的具体原理。
(一)实现原理过程
① 当客户端请求 www.sina.com.cn 主页,经过 DNS 解析到 IP 后,向新浪服务器发送请求数据,数据包经过层层网络到达新浪负载均衡 LVS 服务器,到达 LVS 网卡时的数据包:源 IP 是客户端 IP 地址 CIP,目的 IP 是新浪对外的服务器 IP 地址,也就是 VIP;此时源 MAC 地址是 CMAC,其实是 LVS 连接的路由器的 MAC 地址(为了容易理解记为 CMAC),目标 MAC 地址是 VIP 对应的 MAC,记为 VMAC。
② 数据包到达网卡后,经过链路层到达 PREROUTING 位置(刚进入网络层),查找路由发现目的 IP 是 LVS 的 VIP,就会递送到 INPUT 链上,此时数据包 MAC、IP、Port 都没有修改。
③ 数据包到达 INPUT 链,INPUT 是 LVS 主要工作的位置。此时 LVS 会根据目的 IP 和 Port 来确认是否是 LVS 定义的服务,如果是定义过的 VIP 服务,就会根据配置的 Service 信息,从 RealServer 中选择一个作为后端服务器 RS1,然后以 RS1 作为目标查找 Out 方向的路由,确定一下跳信息以及数据包要通过哪个网卡发出。最后将数据包通过 INET_HOOK 到 OUTPUT 链上(Out 方向刚从四层进入网络层)。
④ 数据包通过 POSTROUTING 链后,从网络层转到链路层,将目的 MAC 地址修改为 RealServer 服务器 MAC 地址,记为 RMAC;而源 MAC 地址修改为 LVS 与 RS 同网段的 selfIP 对应的 MAC 地址,记为 DMAC。此时,数据包通过交换机转发给了 RealServer 服务器(注:为了简单图中没有画交换机)。
⑤ 请求数据包到达 RealServer 服务器后,链路层检查目的 MAC 是自己网卡地址。到了网络层,查找路由,目的 IP 是 VIP(lo 上配置了 VIP),判定是本地主机的数据包,经过协议栈后拷贝至应用程序(比如这里是 nginx 服务器),nginx 响应请求后,产生响应数据包。以目的 VIP 为 dst 查找 Out 路由,确定吓一跳信息和发送网卡设备信息,发送数据包。此时数据包源、目的 IP 分别是 VIP、CIP,而源 MAC 地址是 RS1 的 RMAC,目的 MAC 是下一跳(路由器)的 MAC 地址,记为 CMAC(为了容易理解,记为 CMAC)。然后数据包通过 RS 相连的路由器转发给真正客户端。
从整个过程可以看出,DR 模式 LVS 逻辑非常简单,数据包通过路由方式直接转发给 RS,而且响应数据包是由 RS 服务器直接发送给客户端,不经过 LVS。我们知道一般请求数据包会比较小,响应报文较大,经过 LVS 的数据包基本上都是小包,上述几条因素是 LVS 的 DR 模式性能强大的主要原因。
(二)优缺点和使用场景
• DR 模式的优点

  1. 响应数据不经过 lvs,性能高
  2. 对数据包修改小,信息保存完整(携带客户端源 IP)
    • DR 模式的缺点
  3. lvs 与 rs 必须在同一个物理网络(不支持跨机房)
  4. rs 上必须配置 lo 和其它内核参数
  5. 不支持端口映射
    • DR 模式的使用场景

如果对性能要求非常高,可以首选 DR 模式,而且可以透传客户端源 IP 地址。
3.4 NAT 模式实现原理
lvs 的第 2 种工作模式是 NAT 模式,下图详细介绍了数据包从客户端进入 lvs 后转发到 rs,后经 rs 再次将响应数据转发给 lvs,由 lvs 将数据包回复给客户端的整个过程。

(一)实现原理与过程
① 用户请求数据包经过层层网络,到达 lvs 网卡,此时数据包源 IP 是 CIP,目的 IP 是 VIP。
② 经过网卡进入网络层 prerouting 位置,根据目的 IP 查找路由,确认是本机 IP,将数据包转发到 INPUT 上,此时源、目的 IP 都未发生变化。
③ 到达 lvs 后,通过目的 IP 和目的 port 查找是否为 IPVS 服务。若是 IPVS 服务,则会选择一个 RS 作为后端服务器,将数据包目的 IP 修改为 RIP,并以 RIP 为目的 IP 查找路由信息,确定下一跳和出口信息,将数据包转发至 output 上。
④ 修改后的数据包经过 postrouting 和链路层处理后,到达 RS 服务器,此时的数据包源 IP 是 CIP,目的 IP 是 RIP。
⑤ 到达 RS 服务器的数据包经过链路层和网络层检查后,被送往用户空间 nginx 程序。nginx 程序处理完毕,发送响应数据包,由于 RS 上默认网关配置为 lvs 设备 IP,所以 nginx 服务器会将数据包转发至下一跳,也就是 lvs 服务器。此时数据包源 IP 是 RIP,目的 IP 是 CIP。
⑥ lvs 服务器收到 RS 响应数据包后,根据路由查找,发现目的 IP 不是本机 IP,且 lvs 服务器开启了转发模式,所以将数据包转发给 forward 链,此时数据包未作修改。
⑦ lvs 收到响应数据包后,根据目的 IP 和目的 port 查找服务和连接表,将源 IP 改为 VIP,通过路由查找,确定下一跳和出口信息,将数据包发送至网关,经过复杂的网络到达用户客户端,最终完成了一次请求和响应的交互。
NAT 模式双向流量都经过 LVS,因此 NAT 模式性能会存在一定的瓶颈。不过与其它模式区别的是,NAT 支持端口映射,且支持 windows 操作系统。
(二)优点、缺点与使用场景

• NAT 模式优点

a. 能够支持 windows 操作系统    b. 支持端口映射。如果 rs 端口与 vport 不一致,lvs 除了修改目的 IP,也会修改 dport 以支持端口映射。

• NAT 模式缺点

a. 后端 RS 需要配置网关    b. 双向流量对 lvs 负载压力比较大

• NAT 模式的使用场景

如果你是 windows 系统,使用 lvs 的话,则必须选择 NAT 模式了。

3.5 Tunnel 模式实现原理

Tunnel 模式在国内使用的比较少,不过据说腾讯使用了大量的 Tunnel 模式。它也是一种单臂的模式,只有请求数据会经过 lvs,响应数据直接从后端服务器发送给客户端,性能也很强大,同时支持跨机房。下边继续看图分析原理。

(一)实现原理与过程
① 用户请求数据包经过多层网络,到达 lvs 网卡,此时数据包源 IP 是 cip,目的 ip 是 vip。
② 经过网卡进入网络层 prerouting 位置,根据目的 ip 查找路由,确认是本机 ip,将数据包转发到 input 链上,到达 lvs,此时源、目的 ip 都未发生变化。
③ 到达 lvs 后,通过目的 ip 和目的 port 查找是否为 IPVS 服务。若是 IPVS 服务,则会选择一个 rs 作为后端服务器,以 rip 为目的 ip 查找路由信息,确定下一跳、dev 等信息,然后 IP 头部前边额外增加了一个 IP 头(以 dip 为源,rip 为目的 ip),将数据包转发至 output 上。
④ 数据包根据路由信息经最终经过 lvs 网卡,发送至路由器网关,通过网络到达后端服务器。
⑤ 后端服务器收到数据包后,ipip 模块将 Tunnel 头部卸载,正常看到的源 ip 是 cip,目的 ip 是 vip,由于在 tunl0 上配置 vip,路由查找后判定为本机 ip,送往应用程序。应用程序 nginx 正常响应数据后以 vip 为源 ip,cip 为目的 ip 数据包发送出网卡,最终到达客户端。
Tunnel 模式具备 DR 模式的高性能,又支持跨机房访问,听起来比较完美了。不过国内运营商有一定特色性,比如 RS 的响应数据包的源 IP 为 VIP,VIP 与后端服务器有可能存在跨运营商的情况,有可能被运营商的策略封掉。Tunnel 在生产环境确实没有使用过,在国内推行 Tunnel 可能会有一定的难度吧!
(二)优点、缺点与使用场景

• Tunnel 模式的优点

a. 单臂模式,对 lvs 负载压力小    b. 对数据包修改较小,信息保存完整    c. 可跨机房(不过在国内实现有难度)

• Tunnel 模式的缺点

a. 需要在后端服务器安装配置 ipip 模块    b. 需要在后端服务器 tunl0 配置 vip    c. 隧道头部的加入可能导致分片,影响服务器性能    d. 隧道头部 IP 地址固定,后端服务器网卡 hash 可能不均    e. 不支持端口映射

• Tunnel 模式的使用场景

理论上,如果对转发性能要求较高,且有跨机房需求,Tunnel 可能是较好的选择。

3.6 涉及的概念术语
上述内容中涉及到很多术语或缩写,这里简单解释下具体的含义,便于理解。

• CIP:Client IP,表示的是客户端 IP 地址。
• VIP:Virtual IP,表示负载均衡对外提供访问的 IP 地址,一般负载均衡 IP 都会通过 Virtual IP 实现高可用。
• RIP:RealServer IP,表示负载均衡后端的真实服务器 IP 地址。
• DIP:Director IP,表示负载均衡与后端服务器通信的 IP 地址。
• CMAC:客户端的 MAC 地址,准确的应该是 LVS 连接的路由器的 MAC 地址。
• VMAC:负载均衡 LVS 的 VIP 对应的 MAC 地址。
• DMAC:负载均衡 LVS 的 DIP 对应的 MAC 地址。
• RMAC:后端真实服务器的 RIP 地址对应的 MAC 地址。

基础性的原理知识,暂时理解到这里就可以了,下一篇以实践的方式来进一步了解 LVS 的工作原理和基本使用。

  • END -
    推荐阅读:

《运维三十六计》:运维生存必备宝典
运维工程师不得不看的经验教训和注意事项
一篇文章全面了解运维监控知识体系
服务器产生大量 TIME_WAIT 状态的排查过程
Nginx 性能优化有这篇就够了!
超全整理!Linux性能分析工具汇总合集
回顾 Kubernetes 最近 6 个版本重点更新
如何画出一张合格的技术架构图?
16 张图带你快速入门 Ansible
30个Linux Shell脚本经典案例(下)
10 个Linux Awk文本处理经典案例
Kubernetes 架构师的进阶之路

LVS 3种工作模式实战及Q&A!
原创 肖邦Linux DevOps技术栈 今天
作者:肖邦Linux
博客地址:https://blog.csdn.net/liwei0526vip

通过上一篇的内容我们大概对 LVS 有了直观认识,理解了 LVS 的一些基本工作原理。这篇文章通过实践操作的方式,搭建实际测试环境,一步一步配置 LVS 的几种模式。
上一篇:LVS 工作原理图文讲解,非常详细!

我们知道 LVS 工作模式有 DR、NAT、Tunnel 模式,这篇文章中会针对每个模式进行实践操作,通过实验来更深入理解工作原理。我们需要至少 4 台服务器来进行模拟实验。
• 操作系统:CentOS release 6.5 (Final)
• 内核版本:2.6.32-754.15.3.el6.x86_64
• 相关服务器:1 台客户端服务器,1 台负载均衡服务器,2 台后端真实服务器(模拟负载均衡调度)
注:为了简单,我的几台服务器都是在都一个二层网络,如果有条件的话可以模拟更逼真一些。
再了解下本章用到的两个组件:
• IPVS。LVS 是基于内核态的 netfilter 框架实现的 IPVS 功能,工作在内核态。那么用户是如何配置 VIP 等相关信息并传递到 IPVS 呢,就需要用到了 ipvsadm 工具。
• ipvsadm 工具。ipvsadm 是 LVS 用户态的配套工具,可以实现 VIP 和 RS 的增删改查功能。它是基于 netlink 或 raw socket 方式与内核 LVS 进行通信的,如果 LVS 类比于 netfilter,那么 ipvsadm 就是类似 iptables 工具的地位。

一、DR 模式操作实践
1.1 实验环境
客户端:10.211.102.46
负载均衡:VIP=10.211.102.47 DIP=172.16.100.10
后端1:172.16.100.20
后端2:172.16.100.30

1.2 负载均衡服务器配置
安装 ipvsadm 工具:
$ yum install ipvsadm
配置vip服务:
$ vim lvs_dr.sh

内容如下:

vip=10.211.102.47
rs1=172.16.100.20
rs2=172.16.100.30
/sbin/ipvsadm -C # 清除原有规则
/sbin/ipvsadm -A -t $vip:8088 -s rr # 添加vip:8088的tcp服务
/sbin/ipvsadm -a -t $vip:8088 -r $rs1:8088 -g # 添加rs1服务器
/sbin/ipvsadm -a -t $vip:8088 -r $rs2:8088 -g # 添加rs2服务器

执行脚本

$ /bin/bash lvs_dr.sh
查看服务配置情况:
$ ipvsadm -ln -t 10.211.102.47:8088
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.211.102.47:8088 rr
-> 172.16.100.20:8088 Route 1 0 0
-> 172.16.100.30:8088 Route 1 0 0
1.3 后端服务器配置
后端服务器需要安装 nginx 服务:

安装 nginx 启动并侦听 8088 端口

$ yum install nginx

rs 配置 lo 和其它内核参数

$ vim rs_dr.sh # 内容如下:
vip=10.211.102.47
ifconfig lo:0 $vip broadcast $vip netmask 255.255.255.255 up
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce
执行脚本:
$ /bin/bash rs_dr.sh
$ ifconfig lo:0 # 查看rs的lo:0接口配置信息
lo:0 Link encap:Local Loopback

      inet addr:10.211.102.47  Mask:255.255.255.255
      UP LOOPBACK RUNNING  MTU:16436  Metric:1

注:这些步骤需要在两个 RS 上都进行相关操作。
1.4 测试
上述所有步骤执行完毕后,如果一切都顺利的话,执行测试命令会出现如下结果:
$ curl 10.211.102.47:8088
hello from rs1...
$ curl 10.211.102.47:8088
hello from rs2...
实验成功!两次请求分别被调度到了两台的后端服务器上了。感兴趣的话,在后端服务器上抓包观测实际数据包的各个字段是否符合预期。
1.5 常见问题
通过上述步骤,完成最简单的 DR 模式配置。在负载均衡服务器上配置的信息容易理解,而在后端服务器上配置了 lo 和内核参数,下边以问题的方式来解释清楚这些含义。
Q:为什么需要在 lo 接口配置 vip ?
A:我们知道如果服务器收到的数据包 IP 地址不是本机地址(没开启转发模式),就会丢弃。后端服务器收到 DR 模式的数据包,此时目标 IP 是 VIP,服务器会认为此数据包不是发送给本机的,会丢弃。而我们在 lo 接口上配置 VIP 后,服务器就能够正常接收此数据包,发送给相应的应用程序了。因此,在 lo 上配置 vip 能够完成接收数据包并将结果返回给 client。
Q:为什么需要配置 arp_ignore 参数?
A:我们在 lo 上配置了 vip,正常情况下,其它设备发送 vip 的 arp 请求时,除了负载均衡设备会响应 arp 请求之外,后端服务器也会响应 vip 的 arp 请求,这样请求设备不知道哪个是准确的了,反正就是乱了。我们在参数中配置 arp_ignore=1 之后,后端服务器只会响应目的 IP 地址为接收网卡上的本地地址的 arp 请求。由于 vip 配置了在 lo 上,所以其它接口收到相关的 arp 请求都会忽略掉,这样保证了 arp 请求正确性。这也说明了为什么 vip 必须配置在 lo 接口上而不是其它接口上了。
Q:为什么需要配置 arp_announce 参数?
A:当后端服务器向客户端发送响应数据包时,源地址和目的地址确定,通过目标地址查找路由后,发送网卡也是确认的,也就是源 MAC 地址是确认的,目的 MAC 地址还不确定,需要获取下一跳 IP 对应的 MAC 地址,就需要发送 arp 请求了。发送的 arp 请求目的 IP 就是下一跳的地址,而源 IP 是什么呢?系统通常默认会取数据包的源 IP 作为 arp 的源 IP。我们认真想一下,源 IP 不就是 VIP 么,假设以 VIP 为源 IP 发送 arp 请求,那下一跳(路由器)学习到的 MAC 地址和 IP 地址对应关系就会错乱,因为负载均衡设备上的 VIP 对应的 MAC 地址肯定与这个不同,导致整个系统 arp 紊乱。
而我们配置参数 arp_announce=2 后,操作系统在发送 arp 请求选择源 IP 时,就会忽略数据包的源地址,选择发送网卡上最合适的本地地址作为 arp 请求的源地址。
二、NAT 模式操作实践
2.1 实验环境
客户端:10.211.102.46
负载均衡:VIP=10.211.102.47 DIP=172.16.100.10
后端1:172.16.100.20
后端2:172.16.100.30

2.2 负载均衡服务器配置
安装 ipvsadm 并执行相关配置:
$ yum install ipvsadm
$ vim lvs_nat.sh # 内容如下
echo 1 > /proc/sys/net/ipv4/ip_forward
vip=10.211.102.47
rs1=172.16.100.20
rs2=172.16.100.30
/sbin/ipvsadm -C
/sbin/ipvsadm -A -t $vip:8088 -s rr
/sbin/ipvsadm -a -t $vip:8088 -r $rs1:8088 -m
/sbin/ipvsadm -a -t $vip:8088 -r $rs2:8088 -m

执行脚本

$ /bin/bash lvs_nat.sh

查看服务配置信息:

$ ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.211.102.47:8088 rr
-> 172.16.100.20:8088 Masq 1 0 0
-> 172.16.100.30:8088 Masq 1 0 0

2.3 后端服务器配置
后端服务器安装和配置如下:
$ yum install nginx # 安装 nginx,启动并侦听 8088 端口

vim rs_nat.sh # 如下内容

route add default gw 172.16.100.10 dev eth0 # 默认网关配置为负载均衡的 DIP

执行脚本(两个rs都需要执行)

$ /bin/bash rs_nat.sh
2.4 测试
上述所有步骤执行完毕后,如果一切都顺利的话,执行测试命令会出现如下结果:
$ curl 10.211.102.47:8088
hello from rs1...
$ curl 10.211.102.47:8088
hello from rs2...
实验成功!两次请求分别被调度到了两台的后端服务器上了。感兴趣的话,在后端服务器上抓包观测实际数据包的各个字段是否符合预期。
2.5 常见问题
Q:在后端服务器为何要设置默认网关指向负载均衡设备?
A:由于 NAT 模式是双向流量都经过 LVS 设备,所以后端服务器需要将响应报文发送给 LVS 设备,不过此时的数据包目的 IP 是客户端的 IP,可能是外网的任何一个网段,需要通过设置路由的方式,将数据包转发给 LVS ,因为不可能穷举所有的网段地址,所以必须要设置默认的网关来指向 LVS。最后也要强调一下,负载均衡设备需要开启 ipv4 的 forward 参数。
三、Tunnel 模式操作实践
3.1 实验环境
客户端:10.211.102.46
负载均衡:VIP=10.211.102.47 DIP=172.16.100.10
后端1:172.16.100.20 ,注,rs 与 DIP 可以不在一个网段,只要三层通就行。
后端2:172.16.100.30
3.2 负载均衡服务器配置
安装 ipvsadm 并执行相关配置:
$ yum install ipvsadm
$ vim lvs_tunnel.sh # 内容如下
vip=10.211.102.47
rs1=172.16.100.20
rs2=172.16.100.30
/sbin/ipvsadm -C
/sbin/ipvsadm -A -t $vip:8088 -s rr
/sbin/ipvsadm -a -t $vip:8088 -r $rs1:8088 -i
/sbin/ipvsadm -a -t $vip:8088 -r $rs2:8088 -i

执行脚本

$ /bin/bash lvs_tunnel.sh
查看服务配置信息:
$ ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.211.102.47:8088 rr
-> 172.16.100.20:8088 Tunnel 1 0 0
-> 172.16.100.30:8088 Tunnel 1 0 0
3.3 后端服务器配置
后端服务器安装和配置如下:
$ yum install nginx # 安装 nginx,启动并侦听 8088 端口

vim rs_tunnel.sh # 如下内容

vip=10.211.102.47
modprobe ipip
ifconfig tunl0 $vip broadcast $vip netmask 255.255.255.255 up
echo "0" > /proc/sys/net/ipv4/ip_forward
echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce
echo "0" > /proc/sys/net/ipv4/conf/all/rp_filter
echo "0" > /proc/sys/net/ipv4/conf/tunl0/rp_filter

执行脚本(两个rs都需要执行)

$ /bin/bash rs_tunnel.sh

3.4 测试
上述所有步骤执行完毕后,如果一切都顺利的话,执行测试命令会出现如下结果:
$ curl 10.211.102.47:8088
hello from rs1...
$ curl 10.211.102.47:8088
hello from rs2...
实验成功!两次请求分别被调度到了两台的后端服务器上了。感兴趣的话,在后端服务器上抓包观测实际数据包的各个字段是否符合预期。
3.5 常见问题
Q:为何需要设置 rp_filter 参数?
A:默认 rp_filter 参数设置为 1,Linux 会反向校验源 IP 的路由,如果源和目的 IP 路由出口不是一个网卡,就会被丢弃。因为数据包到后端服务器物理网卡后会被转发给虚拟网卡 tunl0 接口,这时进入的网卡是 tunl0,而源 IP 的路由出口网卡肯定不是 tunl0,所以数据包会被丢弃。配置 rp_filter 参数为 0,就相当于关闭了这个校验。

四、LVS 的几种调度算法
在上面的一些实验过程中,会发现 ipvsadm 命令最后边的 -s rr ,就表示的是调度算法,其中 rr 就是最简单的轮询调度算法,下边先简单介绍负载均衡 LVS 支持的几种调度算法,其中橙色标注为最常用的。
• 轮询 rr - 这种算法是最简单的,就是按依次循环的方式将请求调度到不同的服务器上,该算法最大的特点就是简单。轮询算法假设所有的服务器处理请求的能力都是一样的,调度器会将所有的请求平均分配给每个真实服务器,不管后端 RS 配置和处理能力,非常均衡地分发下去。
• 加权轮询 wrr - 这种算法比 rr 的算法多了一个权重的概念,可以给 RS 设置权重,权重越高,那么分发的请求数越多。实际生产环境的服务器配置可能不同,根据服务器配置适当设置权重,可以有效利用服务器资源。
• 最少连接 lc - 这个算法会根据后端 RS 的连接数来决定把请求分发给谁,比如 RS1 连接数比 RS2 连接数少,那么请求就优先发给 RS1。
• 加权最少链接 wlc - 这个算法比 lc 多了一个权重的概念。
• 基于局部性的最少连接调度算法 lblc - 这个算法是请求数据包的目标 IP 地址的一种调度算法,该算法先根据请求的目标 IP 地址寻找最近的该目标 IP 地址所有使用的服务器,如果这台服务器依然可用,并且有能力处理该请求,调度器会尽量选择相同的服务器,否则会继续选择其它可行的服务器。
• 复杂的基于局部性最少的连接算法 lblcr - 记录的不是要给目标 IP 与一台服务器之间的连接记录,它会维护一个目标 IP 到一组服务器之间的映射关系,防止单点服务器负载过高。
• 目标地址散列调度算法 dh - 该算法是根据目标 IP 地址通过散列函数将目标 IP 与服务器建立映射关系,出现服务器不可用或负载过高的情况下,发往该目标 IP 的请求会固定发给该服务器。
• 源地址散列调度算法 sh - 与目标地址散列调度算法类似,但它是根据源地址散列算法进行静态分配固定的服务器资源。

  • END -
0

评论 (0)

取消