【计算机网络】LVS四层负载均衡器

https://mobian.blog.csdn.net/article/details/141093263
https://blog.csdn.net/weixin_42175752/article/details/139966198
《高并发的哲学原理》 （基本来自本书）
《亿级流量系统架构设计与实战》

LVS

章文嵩博士创造 LVS(IPVS）
章⽂嵩发现 Cisco 的硬件负载均衡器售价昂贵，于是创建并开源了 LVS（当时称为 IPVS）。如今，互联⽹上的绝⼤部分数据包都由 LVS 或承袭 LVS 思想的软件处理。

融入 Linux Kernel
2004 年，LVS（IPVS）被纳⼊了 kernel 2.4，从此之后，所有 Linux 系统都具备了变⾝为负载均衡器的能⼒。

LVS的优势

• 高性能：LVS工作在内核层，性能高效，能够处理大量并发请求。避免了⽤户态到内核态的上下⽂切换导致的内存读写开销。这样可以⼤幅提升⼤流量下的数据处理能⼒。
• 高可用性：通过配置Keepalived等工具，LVS可以实现高可用性，确保服务的持续运行。
• 灵活性强：支持多种负载均衡算法和工作模式，适应不同的应用场景。

LVS 的基本原理可以⽤⼀句话概括：通过修改 MAC 层、IP 层、TCP 层的数据包，实现了⼀部分交换机和⽹关的功能，从⽽指挥流量到达真正的服务器上。

LVS 只需要对数据包的⽬的 IP 地址进⾏修改，然后利⽤⼆层⽹络做基础的数据转发。这个策略让 LVS 承担了最少的计算和流量转发⼯作，增加了 CPU 和内存的资源利⽤率，从⽽⼤幅提升了单机性能

LVS和Nginx

Nginx 是一种高性能的服务器，其性能远高于业务服务器。但是Nginx毕竟是一个应用层软件，单台Nginx服务器能承载的用户请求也是有上限的，当日活用户发展到一定规模后，就需 Nginx集群才能顶住压力。既然是集群，那么势必需要引人一个中间层作为协调者，其负责决定将用户请求转发到哪台Nginx服务器。这个协调者需要有比 Nginx 更高的性能，它就是LVS。

LVS (Linux Virtual Server, Linux 虚拟服务器）是一个虚拟的服务器集群系统，从Linux 2.6 版本开始它已经成为 Linux 内核的一部分，即LVS运行于操作系统层面。

由于LVS基于OSI参考模型的网络层，免去了请求到应用层的层层解析工作，而且LVS工作于操作系统层面，所以 LVS 相比于Nginx有更高的性能。LVS 用于网络接人层时也被称为四层负载均衡器。

LVS和Nginx在转发请求时的区别：

• Nginx 是基于 OSI 参考模型的第七层（应用层）协议开发的，采用了异步转发形式。Nginx 在保持客户端连接的同时新建一个与业务服务器的连接，等待业务服务器返回响应数据，然后再将响应数据返回给客户端。Nginx 选择异步转发的好处是可以进行失败转移（failover），即：如果与某台业务服务器的连接发生故障，那么就可以换另一个连接，提高了服务的稳定性。Nginx 主要强调的是“代理”。
• LVS 是基于OSI 参考模型的第四层（ 网络层）协议开发的，采用了同步转发形式。当LVS 监听到有客户端请求到来时，会直接通过修改数据包的地址信息将流量转发到下游服务器，让下游服务器与客户端直接连接。LVS 主要强调的是“转发”。

LVS 工作模式

LVS 有三种常⽤模式：

1. NAT 模式：即⽹关模式，双向流量均经过⽹关转发，性能开销最⼤。不仅需要修改请求报文的目标地址，还需要修改响应报文的源地址，适用于小规模集群。
2. TUN 模式：类似于单臂路由，性能⾼且可跨越机房。【单臂路由（router-on-a-stick）是指在路由器的一个接口上通过配置子接口（或“逻辑接口”，并不存在真正物理接口）的方式，实现原来相互隔离的不同VLAN（虚拟局域网）之间的互联互通】。该模式通过IP隧道将请求转发到后端服务器，后端服务器直接将响应报文发回客户端，适用于地理位置分散的集群。
3. DR 模式：仅适⽤于局域⽹，但性能惊⼈，因为回程流量不返回⽹关，直接在局域⽹内传输给客户端。在该模式下，负载均衡器只修改请求报文的目标MAC地址，而不修改IP地址，后端服务器直接将响应报文发回客户端，适用于大规模集群。

DR 模式数据包推演

在 DR 模式下，LVS 只负责修改数据包，不充当⽹关的⾓⾊。因此，需要⼀个⽹关来执⾏公⽹ IP 和私⽹ IP 之间的 NAT 转换。假设客户端 IP 为 123.123.123.123，它向 110.242.68.3 的 80 端⼝发起了⼀个 HTTP 请求。当⽹关接收到⼀个发送给 110.242.68.3 的数据包时，发现协议为 TCP，⽬标端⼝为 80。通过查询⾃⼰的
NAT 表，⽹关发现内部 IP 为 10.0.0.100（即虚拟 IP），内部端⼝为 80。于是，⽹关向局域⽹发送了⼀个
IP 包。由于端⼝和协议保持不变，本次⽹络请求中的关键数据有四个：源 IP 地址、⽬的 IP 地址、源 MAC
地址和⽬的 MAC 地址。

• 客户端发给⽹关的数据包情况为：
  1. 源 ip：123.123.123.123
  2. ⽬的 ip：110.242.68.3
  3. 源 MAC：客户端 MAC
  4. ⽬的 MAC：⽹关 MAC
• ⽹关向局域⽹发出的数据包情况为：
  1. 源 ip：123.123.123.123
  2. ⽬的 ip：10.0.0.100（变了）
  3. 源 MAC：⽹关 MAC（变了）
  4. ⽬的 MAC：LVS MAC（变了）
• LVS 接到该数据包后，会选择⼀个后端服务器，假设它选中的是 10.0.0.1 来真正处理请求，则 LVS 会
  对数据包进⾏如下修改后，再发送给 10.0.0.1：
  1. 源 ip：123.123.123.123
  2. ⽬的 ip：10.0.0.100
  3. 源 MAC：LVS MAC（变了）
  4. ⽬的 MAC：10.0.0.1 的 MAC（变了）
• 10.0.0.1 在收到该数据包后，发现这个包的⽬的 MAC 地址确实是⾃⼰，⽽且⽬的 ip 10.0.0.100（VIP
  ）也是⾃⼰，于是对该数据包进⾏正常的处理，然后将处理结果发送出去：
  1. 源 ip：10.0.0.100
  2. ⽬的 ip：123.123.123.123
  3. 源 MAC：10.0.0.1 的 MAC
  4. ⽬的 MAC：⽹关 MAC（因为⽬的 ip 不在“ip+⼦⽹掩码”所确定的局域⽹范围内，所以该数据包会
     被发送给⽹关）
• ⽹关收到返回的数据包后，通过查询“五元组关系表”，对端⼝和 ip 信息做出正常的 NAT 修改后，将
  数据包发送回 123.123.123.123，请求结束。

DR 模式特点：

1. LVS 只需处理正向数据包，通常正向数据包（请求）远⼩于反向数据包（响应），因此带宽占⽤较低。
2. 反向数据包通过标准的⼆层以太网络传输，每台上游服务器都能达到⾃⼰的线速（⽹络设备接⼝协商速率，
   理论上的最⼤数据传输速率）。
3. 只能在相同的⼆层⽹络下⼯作（即同⼀个局域⽹），架构上有局限，同时安全性较差。
4. 需要在每台上游服务器上将 VIP（10.0.0.100）配置为 lo（本地回环）接⼝的 IP。
5. 需要让每台上游服务器只响应真实 IP（如 10.0.0.1）的 ARP 查询请求，如果不⼩⼼回复了针对 VIP 的
   ARP 请求，将会引发混乱：局域⽹内有多台机器同时声称⾃⼰拥有 10.0.0.100 这个 IP，交换机会崩溃。
   在⽣产环境部署中，由于 LVS 集群是所有流量的⼊⼝，所以其可⽤性需要⾮常⾼，⼀般不会只部署在⼀个机房⾥，因此最常⽤的是 NAT 模式：双向流量都经过 LVS 集群，这样可以实现多地多中心的跨公⽹多活。

Keepalived

LVS 是运⾏在标准以太⽹模型下的负载均衡软件，配合 Keepalived 可以实现⾼可⽤。⽽ OSPF/ECMP 协
议是专业的多链路路由协议，可以实现不丢包的多活。

LVS 拆分了网关单点
LVS 是⽹关型负载均衡继续拆单点的结果：LVS 将⽹关这个单点拆分成了“重定向”和“转发”，⾃⼰只承
担数据包重定向⼯作，将转发留给基础⽹以太⽹来解决，在单机上实现了⾮常⾼的系统容量。在最新的 x86
服务器上，单个 LVS 即使在开销更⼤的 NAT 模式下也可以实现⼤约 20G 的 TCP 带宽。

Keepalived 是⼀款出⾊的开源软件，专为与 LVS 配合⽽设计，主要功能是构建⾃选举集群。它⽀持独⽴部
署三台机器⽤作控制器集群，也可以将控制器部署到应⽤机器上。与 LVS ⼀样，基于虚拟 IP 技术，可在任
意标准以太⽹内运⾏。

Keepalived 运行原理

1. 两台机器配置同⼀VIP（虚拟 IP）：即两台机器的真实 IP 分别为 10.0.0.101 和 10.0.0.102，但虚拟出
   ⼀个 IP 10.0.0.100，不属于任何物理设备，可在任何机器间切换绑定。
2. 两机频繁通信，通过分数计算确定哪台机器得分更⾼，由该机器向局域⽹发送 VRRP 组播报⽂宣称 VIP
   在我这⾥。
3. 当得分⾼的主机宕机、断⽹或检测到服务进程消失（如 Nginx 挂掉），得分低的机器会在极短时间内接
   替，宣称 VIP 在⾃⼰这⾥。
4. 发送给 VIP 的数据包会在短时间失效后由新机器承接（实测中断时间⼩于 1 秒），实现集群⾼可⽤。

高可用 LVS 集群，LVS 与 Keepalived 结合，基于多台物理机，可实现⾼可⽤负载均衡集群

⾦融级项⽬可在⼀城市跨三个机房做三节点 Keepalived 集群。为何不跨城市？因跨城市属于“两地三中⼼
”⾼可⽤技术领域，⼀般不在⼆层⽹络上进⾏，跨城市专⽤光纤建设费⽤⾼昂，城市内拉光纤更经济实惠。