LVS与Keepalived详解（一）负载均衡集群介绍

前言

一、什么是LVS？

LVS 的全称是 Linux Virtual Server，即 Linux 虚拟服务器。

它是一个由章文嵩博士（Dr. Wensong Zhang）发起和领导的自由软件项目。LVS 的核心是一个基于 Linux 操作系统 的 负载均衡器，它能够将大量的网络请求（如 Web 访问、数据库查询等）智能地、高效地分发到一组后端服务器（称为 Real Server）上。

LVS 工作在 Linux 内核层面，因此性能非常高，远超许多在应用层（如 Nginx、HAProxy）实现的负载均衡软件。它通常被认为是 四层（Layer 4, 传输层）负载均衡 的经典解决方案，主要基于 IP 地址和端口号进行请求转发。

LVS 的三种工作模式：

1. NAT 模式（网络地址转换）

   • 原理：LVS 服务器同时作为客户端和后端服务器的网关。它修改请求和响应数据包的地址。
   • 优点：后端服务器可以是任何操作系统，只需配置网关指向 LVS。
   • 缺点：LVS 容易成为性能瓶颈，因为所有进出后端服务器的流量都要经过 LVS。

2. TUN 模式（IP 隧道）

   • 原理：LVS 将请求数据包封装在一个新的 IP 包中（IPIP 隧道），转发给后端服务器。后端服务器解包后直接响应给客户端，不再经过 LVS。
   • 优点：响应流量不经过 LVS，解决了 NAT 模式的瓶颈问题，支持跨机房部署。
   • 缺点：需要在后端服务器上配置隧道接口，部署稍复杂。

3. DR 模式（直接路由） - 最常用

   • 原理：LVS 只修改请求数据包的 MAC 地址，将其直接转发给后端服务器。后端服务器处理请求后，使用自己的 IP 直接响应客户端。
   • 优点：性能最高，响应流量不经过 LVS。
   • 缺点：LVS 和后端服务器必须在一个物理局域网（LAN）内，且需要在后端服务器上配置虚拟 IP（VIP）和 ARP 抑制。

二、四层（L4）负载均衡的最佳解决方案是什么？

关于“四层（L4）负载均衡的最佳解决方案”，答案并不是一个简单的软件或硬件名字，而是：没有唯一的“最佳”方案，只有针对特定场景的“最合适”的方案。

选择取决于你的性能需求、预算、功能要求、运维能力和业务场景。

下面将从几个维度来分析不同的解决方案。

2.1解决方案分类与对比（负载均衡的三种方式介绍）

四层负载均衡解决方案大致可以分为三类：

2.1.1 硬件负载均衡 (Hardware Load Balancer)

• 代表产品：F5 BIG-IP, A10 Networks, Citrix NetScaler、深信服、华三、绿盟
• 优点：
  • 极致性能：基于专用硬件（ASIC芯片），性能极高，吞吐量大，延迟低。
  • 高可靠性：设备本身通常采用主动-备用集群模式，可靠性极高。
  • 功能丰富：除了负载均衡，还集成了防火墙（WAF）、DDoS防护、SSL加速等高级功能。
  • 厂商支持：提供专业的技术支持和售后服务。
• 缺点：
  • 极其昂贵：设备和许可证费用非常高，是中小公司的沉重负担。
  • 扩展性差：扩展需要购买更多硬件，不够灵活。
  • 封闭性：功能依赖厂商，定制化能力弱。
• 最佳适用场景：
  • 对性能和稳定性有极端要求的大型企业、金融、电信核心业务。
  • 需要集成高级安全功能（如全链路SSL加密、高级WAF）的场景。

2.1.2 软件负载均衡 (Software Load Balancer)

• 代表产品：
  • LVS (Linux Virtual Server)（千万级）：正如之前讨论的，是四层负载的标杆。
  • HAProxy（千万级）：既能做四层（TCP），也能做七层（HTTP）负载均衡，非常灵活和强大。
  • Nginx（5万~20万）：虽然以七层HTTP负载均衡闻名，但从1.9版本开始也支持四层（TCP/UDP）负载均衡。
• 优点：
  • 成本极低：开源免费，只需在普通服务器上部署即可。
  • 灵活性高：可随意部署在任何环境（物理机、虚拟机、云）。
  • 可扩展性强：性能不够时，简单增加服务器节点即可横向扩展。
  • 透明可控：源码开放，可根据业务需求进行定制和深度优化。
• 缺点：
  • 性能开销：运行在操作系统用户态/内核态，需要消耗CPU等资源，峰值性能通常低于硬件方案。
  • 运维复杂度：需要自行搭建、配置、维护和高可用保障（如LVS+Keepalived）。
• 最佳适用场景：
  • 绝大多数互联网公司的首选，尤其是在成本控制和技术自主性要求高的场景。
  • LVS 非常适合做高性能、高并发的通用TCP/UDP流量分发。
  • HAProxy 非常适合需要对协议进行精细控制（如MySQL、Redis、HTTP等）的场景。

2.1.3 云负载均衡 (Cloud Load Balancer)

• 代表产品：AWS ELB/ALB/NLB, Google Cloud CLB, 阿里云SLB, 腾讯云CLB
• 优点：
  • 开箱即用：无需部署和维护，一键创建，自动扩展。
  • 高可用性：云服务商默认提供高可用保障，无需自己操心。
  • 按需付费：通常按使用量（连接数、流量）计费，成本模型灵活。
  • 与云生态集成：无缝集成云上的其他服务（如自动伸缩组、安全组）。
• 缺点：
  • 黑盒性：底层实现不可见，出现问题排查困难。
  • 功能限制：功能由云厂商决定，可能缺少某些高级定制功能。
  • 成本可能变高：在超大流量下，长期使用的总成本可能超过自建软件方案。
  • vendor lock-in ：存在一定的厂商锁定风险。
• 最佳适用场景：
  • 云上业务的首选，尤其是创业公司和中型项目，希望快速上线且减少运维投入。
  • 业务流量波动巨大的场景，需要负载均衡器能自动弹性伸缩。

2.2 总结与选择建议

如何选择？

1. 如果你的业务在公有云上：

   • 优先考虑云厂商提供的负载均衡器（如AWS NLB/ALB）。这是最省心、最云原生、集成度最高的选择，除非你有非常特殊的理由不用它。

2. 如果你是自建数据中心的大型互联网公司：

   • LVS + Keepalived 通常是四层负载均衡的“事实标准”和最佳选择。它提供了接近硬件的性能，同时拥有软件方案的极致灵活性和低成本。用它来承载最核心、流量最大的入口业务（如电商、视频、社交）。
   • HAProxy 可以作为LVS的补充，用于需要更多协议层控制的内部服务（如数据库、微服务）。

3. 如果你是传统企业，预算充足且对稳定性有极端要求：

   • 可以考虑硬件负载均衡器，将其作为整个数据中心流量的总入口和安全屏障。

因此，回到问题：四层负载均衡有最佳解决方案吗？

• 从性能和稳定性看，硬件方案（F5） 是标杆。
• 从综合性价比、可控性和行业实践看，LVS 是自建环境中最受推崇的“最佳”解决方案。
• 从易用性和现代化看，云负载均衡器是云上的最佳选择。

所以，“最佳”取决于你的技术栈、团队能力和业务需求。但对于绝大多数技术驱动型公司而言，LVS 在四层负载均衡领域的地位，至今依然非常稳固，是当之无愧的经典解决方案。

三、为什么要使用LVS？

使用 LVS 的主要原因可以归结为以下几点：

1. 高性能与高吞吐量：LVS 工作在内核层，通过 IP 负载均衡技术，其转发效率极高，能处理惊人的并发连接和流量，可以轻松应对百万级别的并发请求，而其上限甚至可能超越千万级。这是许多应用层负载均衡器难以比拟的。
2. 高可用性（High Availability）：通过将请求分发到多台后端服务器，LVS 避免了单点故障。如果其中一台后端服务器宕机，LVS 可以自动检测到并将其从服务器池中移除，确保服务不中断。
3. 可扩展性（Scalability）：当业务增长，服务器负载增加时，可以通过简单地增加后端服务器来横向扩展系统的处理能力。LVS 对外呈现一个单一的虚拟 IP，扩展过程对客户端完全透明。
4. 成本效益：LVS 是开源软件，无需支付昂贵的商业负载均衡硬件（如 F5, A10）费用。它可以在普通的 PC Server 上运行，构建出性能极强的负载均衡系统。
5. 透明性：对于客户端而言，它们只与一个虚拟 IP（VIP）通信，完全感知不到后端有多少台服务器以及它们是如何工作的。这简化了客户端的配置和连接管理。

总结：使用 LVS 是为了构建一个高性能、高可用、可扩展的服务器集群系统。

四、为什么要使用LVS+Keepalived集群？

这是一个非常重要的问题。LVS 本身是一个非常强大的负载均衡器，但它 本身存在一个单点故障（SPOF）问题。

• 问题：如果那台运行 LVS 软件的服务器宕机了，那么整个集群的入口就断了，所有服务都无法访问。LVS 解决了后端服务器的单点问题，但自己却成了新的单点。

Keepalived 就是为了解决 LVS 的单点问题而生的。

Keepalived 是一个基于 VRRP 协议（虚拟路由冗余协议）的实现，它的核心作用是：

1. 为 LVS 提供高可用（High Availability）：

   • 你可以部署 两台（或多台） 安装有 LVS 和 Keepalived 的服务器。
   • 这些服务器通过 VRRP 协议进行通信，共同虚拟出一个 虚拟 IP（VIP），这个 VIP 就是对外提供服务的地址。
   • 在同一时间，只有一台服务器持有这个 VIP 并承担流量转发工作，这台服务器称为 Master（主）。
   • 另一台（或多台）服务器处于 Backup（备） 状态，随时待命。
   • Keepalived 会持续检查 Master 服务器的健康状态（通过心跳线）。如果 Master 服务器宕机，Backup 服务器会立即检测到，并接管 VIP，升级为新的 Master，继续提供服务。
   • 这个过程对客户端是透明的，它们几乎感知不到服务的切换，从而实现了 LVS 负载均衡器本身的高可用。

2. 管理 LVS 配置和后端服务器健康检查：

   • Keepalived 不仅可以管理 VIP，还可以直接读取它的配置文件来动态地管理 LVS 的规则（如添加/删除后端服务器）。
   • 它还能定期对后端服务器（Real Server）进行健康检查（如检查特定 TCP 端口是否开启），如果发现某台服务器失效，就自动将其从 LVS 的转发队列中移除；当服务器恢复时，再自动将其加入。

因此，LVS + Keepalived 的组合形成了一个完美的解决方案：

• LVS：负责高性能的流量负载均衡。
• Keepalived：
  1. 负责 LVS 自身的高可用，解决其单点故障问题。
  2. 负责 管理 LVS 配置 和 后端服务器的健康检查。

这个组合共同构建了一个既 高性能 又 高可用 的完整集群架构，是互联网公司基础架构中非常经典和核心的组件。

-------------------------------------以下是正文---------------------------------------

一、什么是集群？

1.1 核心思想：人多力量大

集群 的核心思想非常简单，就是 “人多力量大” 和 “团结就是力量”。

它指的是将多台独立的计算机（称为节点） 通过软件和网络连接起来，让它们协同工作，共同完成一项任务。从外部看来，这一个集群就像一个单一的、功能更强大的系统。

您可以把它想象成：

• 蚂蚁搬家：一只蚂蚁力量很小，但一群蚂蚁分工协作，就能搬动比它们自身重很多倍的食物。这群蚂蚁就是一个“集群”。
• 狼群狩猎：一匹狼很难捕获大型猎物，但狼群通过分工、协作和围攻，可以成功捕猎。这个狼群就是一个“集群”。

与集群相对的概念是“单机系统”，即所有任务都由一台服务器完成。这台服务器一旦出现问题，整个服务就完全中断了。

1.2 为什么要使用集群？它的主要目标是什么？

构建集群主要为了实现以下三个关键目标：

1. 高可用性

   • 目标：保证服务7x24小时不间断。
   • 如何实现：在集群中，如果有一台服务器（节点）宕机了，它的工作任务会立刻被自动转移到其他健康的服务器上。对用户来说，服务几乎没有中断，感觉不到后台发生了故障。这消除了“单点故障”。
   • 比喻：就像一队士兵站岗，其中一个士兵累了，队长会立刻让另一名休息好的士兵顶替他的位置，保证哨位始终有人。

2. 高性能/负载均衡

   • 目标：处理超高并发的用户请求或极其复杂的计算任务。
   • 如何实现：将一个巨大的计算任务拆分成无数个小任务，分发给集群中成百上千台计算机同时计算，最后将结果汇总。或者将海量的用户请求，分摊给多台服务器分别处理，避免单一服务器被压垮。
   • 比喻：原本需要一个人抄写100本书，任务繁重。现在找来100个人，每人同时抄写1本，效率极大提升。这就是“负载均衡”。

3. 高可扩展性

   • 目标：能够根据业务需求，平滑地增加或减少系统的处理能力。
   • 如何实现：当业务增长、流量变大时，不需要更换更昂贵的大型机，只需要向集群中添加更多的普通商用服务器即可线性地提升整个集群的能力。这种方式成本更低、更灵活。
   • 比喻：一个仓库不够用了，就在旁边盖一个新的仓库，而不是费尽力气去改造和扩大原来的旧仓库。

1.3 集群的主要类型

根据目标侧重点不同，集群主要分为以下几类：

1.4 一个简单的例子：访问淘宝网

当你访问淘宝这种大型网站时，背后就是一个极其复杂的集群系统在为你服务：

1. 你的请求首先到达 负载均衡集群（如Nginx, LVS），它像一个前台接待，决定把你的请求分发给哪一组具体的应用服务器。
2. 应用服务器处理你的搜索、商品浏览等请求，如果需要数据，它会向背后的 数据库集群（如MySQL主从复制集群）请求数据。
3. 数据库集群本身也是一个高可用集群，主数据库负责写数据，从数据库负责读数据。如果主库宕机，会自动切换到一个从库顶上，保证数据不丢失、服务不停机。
4. 你看到的商品图片，则存储在 分布式存储集群（如阿里云的OSS）中。

这一切复杂的协作，对你来说都是透明的，你感受到的只是一个快速、稳定、永不宕机的“淘宝网”。

二、什么是负载均衡集群？

负载均衡集群 是一组相互协作的服务器（称为一个“集群”），通过一个或多个负载均衡器作为统一的流量入口，将来自客户端的请求或网络负载智能地分发到集群中的多台后端服务器上。

其核心目标是：

1. 提升性能：通过并行处理，分担单一服务器的压力，提高整体系统的吞吐量和响应速度。
2. 提高可用性：当集群中某台服务器发生故障时，负载均衡器能够自动将流量路由到其他健康的服务器，从而保证服务不中断，实现高可用性。
3. 增强可扩展性：当业务增长时，可以通过简单地增加后端服务器数量来线性地提升系统处理能力，而无需修改应用架构。

2.1 核心组成部分

一个典型的负载均衡集群包含三个主要角色：

1. 负载均衡器：

   • 是整个系统的大脑和流量调度中心。
   • 它对外提供一个或多个虚拟IP地址，客户端只访问这个IP，而不直接访问后端服务器。
   • 负责执行负载均衡算法、健康检查和管理会话保持等。可以设置主备，解决“单点故障”。

2. 后端服务器池：

   • 是真正处理业务请求的服务器群体，也称为“服务器农场”或“节点”。
   • 这些服务器通常提供完全相同的服务（即运行相同的应用程序）。

3. 共享存储（可选）：

   • 对于需要共享状态或数据的应用（如用户会话文件、数据库文件），后端服务器通常会访问一个共享的存储系统（如NAS、SAN或分布式文件系统），以保证数据一致性。可以设置主备，解决“单点故障”。

2.2 负载均衡的工作原理

1. 客户端请求：客户端向负载均衡器的虚拟IP发起请求。
2. 流量接收：负载均衡器接收该请求。
3. 算法决策：负载均衡器根据预设的负载均衡算法（如轮询、加权轮询等），从健康的服务器池中选择一台最合适的后端服务器。
4. 请求转发：负载均衡器将客户端的请求转发给选中的后端服务器。转发方式有多种（见第四部分）。
5. 响应返回：后端服务器处理请求，并将响应返回。响应可能直接返回给客户端（DSR模式），或先返回给负载均衡器，再由负载均衡器返回给客户端（NAT模式）。
6. 健康检查：负载均衡器持续地对所有后端服务器进行健康检查（通过发送心跳包或检测特定端口）。如果发现某台服务器宕机或服务无响应，则将其从可用的服务器池中移除，确保不会有流量被发送到故障节点。

2.3 主要的负载均衡算法

负载均衡器根据不同的算法做出决策，常见的有：

• 轮询：依次将每个新请求分发到下一台服务器，循环往复。简单公平，但不考虑服务器性能差异。
• 加权轮询：在轮询的基础上，为性能更强的服务器分配更高的权重，使其处理更多的请求。
• 最少连接：将新请求发送到当前连接数最少的服务器。非常适合处理长连接（如FTP、数据库连接）等场景。
• 加权最少连接：在最少连接的基础上，考虑服务器的权重。
• 源IP哈希：根据客户端的源IP地址计算哈希值，将同一IP的请求总是转发到同一台服务器。这能很好地实现会话保持，但可能导致负载不均。
• 最短响应时间：将请求转发到平均响应时间最短的服务器，追求最佳用户体验。

2.4 部署模式（流量转发方式）

根据网络模型的不同，主要有三种部署模式：

1. 四层负载均衡：

   • 工作在OSI模型的传输层（TCP/UDP）。
   • 仅根据IP地址和端口号进行转发，效率极高，速度快。
   • 代表技术：LVS（Linux Virtual Server）。

2. 七层负载均衡：

   • 工作在OSI模型的应用层（HTTP/HTTPS/FTP等）。
   • 可以解析应用层协议内容，根据URL、Cookie、消息头等信息进行更智能的转发（例如，将/api/的请求转发到API服务器组，将/static/的请求转发到静态资源服务器组）。
   • 功能强大，但处理开销比四层大。
   • 代表技术：Nginx、HAProxy。

3. 混合模式：

   • 在实际架构中，常采用分层设计。前端用四层负载均衡（如LVS）承接巨大流量并进行初次分发，后端再用七层负载均衡（如Nginx）进行更精细的业务逻辑分发。

2.5 主要优势

• 高并发处理：轻松应对大量用户访问，避免单点瓶颈。
• 故障容错：自动屏蔽故障节点，保证服务连续性，实现高可用。
• 横向扩展：通过增加服务器即可提升性能，扩展性强，成本可控。
• 维护便利：可以在不中断服务的情况下，对后端服务器进行升级、打补丁或下线维护。

2.6 典型应用场景

• Web网站和应用：几乎所有大型网站（如淘宝、百度、Google）都使用负载均衡集群来服务海量用户。
• API服务：为移动应用或微服务架构提供高可用的API接口。
• 数据库读写分离：将写操作指向主数据库，读操作分发到多个从数据库。
• 游戏服务器：将玩家分配到不同的游戏服务器实例，以平衡负载。
• 音视频流媒体：将用户请求分发到不同的流媒体服务器节点。

三、集群负载均衡调度技术的工作模式分析

集群负载均衡调度技术中最核心的工作模式有三种。这三种模式主要基于OSI网络模型的第4层（传输层），关注的是如何将网络连接和请求分发到后端服务器。

这三种经典模式是：

1. 地址转换模式（NAT）
2. 直接路由模式（DR）
3. IP隧道模式（IP Tunneling）

1. 地址转换模式（NAT Mode）

NAT模式是负载均衡器作为网关，通过修改数据包的网络地址来实现流量转发的模式。

工作原理：

1. 请求过程：
   • 客户端发送请求到负载均衡器（LB）的虚拟IP（VIP）。
   • LB接收到请求后，根据调度算法（如轮询、最小连接数等）选择一台后端真实服务器（RS）。
   • LB将请求数据包的目标IP地址（VIP）修改为选中的RS的真实IP地址，然后将包转发给RS。
2. 响应过程：
   • RS处理请求后，发送响应包。RS的默认网关必须指向LB。
   • 响应包的目标IP是客户端IP，但会先发送到LB。
   • LB收到响应包后，将响应包的源IP地址（RS的IP）修改为VIP，然后将包发送回客户端。
     

特点：

• 优点：
  • 可以隐藏后端服务器的真实IP地址，安全性较好。
  • 配置相对简单，后端服务器可以位于任何网络位置，只要LB能访问到即可。
• 缺点：
  • 性能瓶颈： 进出双向的所有流量都必须经过LB。LB需要处理请求和响应两次NAT操作，当流量很大时，LB容易成为性能瓶颈。
  • 后端服务器的网关必须指向LB，增加了网络配置的复杂性。

适用场景： 小型系统或测试环境，对性能要求不高的场景。

2. 直接路由模式（DR Mode）

DR模式是性能最高、最常用的模式。它的核心思想是让响应流量（通常数据量很大）不经过负载均衡器，直接返回给客户端。

工作原理：

1. 请求过程：

   • 客户端发送请求到LB的VIP。
   • LB接收到请求后，根据调度算法选择一台后端RS。
   • LB不修改请求包的IP地址，而是只修改目标MAC地址，将其改为选中RS的MAC地址，然后将数据帧转发给RS。

2. 响应过程：

   • RS服务器上必须配置一个Loopback（回环）接口，并绑定相同的VIP地址，同时需要抑制该VIP的ARP响应。
   • RS收到请求后，发现目的IP（VIP）就在自己的本地环回接口上，于是直接处理该请求。
   • 处理完成后，RS直接构建响应包（源IP是VIP，目标IP是客户端IP），并通过自己的默认网关（而不是LB）直接将响应包发送给客户端。

   

特点：

• 优点：
  • 极致性能： LB只处理入站请求，出站的大流量响应数据直接由RS发往客户端，极大减轻了LB的负担，避免了性能瓶颈。
• 缺点：
  • 配置复杂： 需要在所有RS上配置Loopback和VIP，并设置ARP抑制，运维成本较高。
  • 网络限制： LB和所有RS必须位于同一个物理局域网（二层网络） 内，因为MAC地址转发只能在二层网络中进行。

适用场景： 高性能要求的Web服务、流媒体服务等响应数据量远大于请求数据量的业务，是大型互联网公司的首选方案。

3. IP隧道模式（IP Tunneling Mode）

IP隧道模式通过IP封装技术（如IPIP）将请求转发给后端服务器，类似于DR模式，响应流量也直接返回。

工作原理：

1. 请求过程：
   • 客户端发送请求到LB的VIP。
   • LB接收到请求后，根据调度算法选择一台后端RS。
   • LB将原始的客户端请求数据包作为一个新的IP数据包的载荷（Payload），用一个新的IP头进行封装。新IP头的源地址是LB的IP，目标地址是RS的IP。
   • 这个封装后的包通过IP隧道发送给RS。
2. 响应过程：
   • RS收到封装包后，进行解封装，得到原始的客户端请求包。
   • RS发现原始包的目标IP（VIP）配置在自己的隧道接口上，于是处理该请求。
   • 处理完成后，RS直接构建响应包（源IP是VIP，目标IP是客户端IP），并通过自己的默认网关直接将响应包发送给客户端。
     

特点：

• 优点：
  • 与DR模式一样，响应流量不经过LB，性能高。
  • 可跨网段部署： LB和RS可以不在同一个局域网，只要IP可达即可，扩展性更强。
• 缺点：
  • 配置复杂，需要在RS上支持IP隧道协议。
  • 建立隧道需要额外支出每个节点都需要公网地址。
  • IP封装和解封装带来额外的CPU开销。

适用场景： 需要高性能且LB与RS无法部署在同一个局域网的场景，例如跨机房、跨地域的负载均衡。

三种工作模式对比总结

如何选择？

• 追求极致性能且网络可控：优先选择 DR 模式。
• RS需要跨网段或跨地域部署：选择 IP隧道模式。
• 简单测试或小规模部署：可以使用 NAT 模式。

这三种模式是构建高性能、高可用集群（如LVS, Linux Virtual Server）的理论基础。在现代云环境中，虽然底层实现可能被抽象化，但其核心思想依然适用。