星空体育入口：掌握负载均衡的关键，看这20张图片！

星空体育入口：掌握负载均衡的关键，看这20张图片！: 时间：2024-07-07 来源：zoc7RcITctunhMtq7EzA 人气：

[[416980]] 首先

我们要来彻底揭开负载均衡器 LVS 的神秘面纱，相信大家观看了《你管这玩意儿叫负载均衡?这篇文章提到了一些困惑点，例如，LVS 看似只有类似路由器的转发功能，但为何它被称为四层（传输层）负载均衡器星空体育网页版？让我们一起逐步揭示LVS的神秘之处，文章将通过图解来深入探讨LVS的工作原理。建议大家了解网络的连接方式和数据包的收发机制，这将有助于更好地理解本文的知识点。如果缺乏相关概念，强烈建议参考我之前写的这篇文章，以便于更加明确地理解网络的连接方式。如果你以前没有看过，也没有关系，本文将会解释一些必要的知识点，希望能让每个人都能理解。「x」「n」负载均衡器的诞生\n小章公司的DAU（日活跃用户量）在很长一段时间内都不超过10，因此他只部署了一台服务器，毕竟多一台服务器需要额外的费用，而且即使服务器宕机也不会影响到太多的用户。由于意外，小章的业务迅速增长，dau 达到了好几万，眼看就要超过十万。小章赶紧升级了机器的内存和CPU等配置以暂时应对问题。然而，小章意识到单台机器性能无论怎么提升都会遇到瓶颈。因此，他决定通过多部署几台机器，将流量平均分配到这些机器上。

的分配方法可以很简单，就是利用DNS负载均衡。在域名解析服务器上设定负载均衡策略，使流量会被随机分发到其中一台机器上。这个方案存在两个显著问题：占用过多的公共 IP 地址，现在租用一个公共 IP 地址需要花费数千。DNS 缓存可能导致严重故障。解决第一个问题只需花钱，但解决第二个问题不仅仅是增加投入。DNS 解析通常需要经过根域名服务器、顶级域名服务器和权威域名服务器三个步骤才能解析域名对应的 IP 地址。这个过程非常耗时，因此常常会使用 DNS 缓存，包括浏览器缓存、操作系统缓存、路由器缓存和 ISP 缓存等几种类型。每次发起域名解析请求，都会逐个在这四个缓存中查找。若命中缓存，则直接返回对应的IP地址。例如，Chrome缓存1分钟，ISP缓存则可能长达1到2小时。然而问题是，如果某台机器宕机，而缓存中依然可能保留了该域名的IP地址，请求方无法察觉。只要缓存未过期，请求方将持续向宕机机器发送流量，导致线上故障，这当然是不可接受的。在处理

问题时，小章突然想起了一句计算机领域的经典名言：“没有什么问题是添加一层解决不了的，如果有，那就再加一层”。为什么不在 DNS 和服务器之间增加一层，让负载均衡的工作由这个中间层来完成呢？小章脑海中浮现出以下架构图：

从图中可以看出，这个负载均衡器（以下简称为 LB）具有以下特点：

• 对外使用公网 IP（以下简称 VIP）承接所有流量，与真实服务器（即 RS，以下简称为 RS）在同一个内网通信 • LB 只负责转发请求的工作，实际处理逻辑由背后的 RS 完成。RS 处理完后会将响应包发送给 LB，然后 LB 再传送给客户端。\n因此，网络拓扑图的更新如下所示：\nNAT\n接下来需要重点关注 LB 的工作原理，首先要明确的是，当我们说收到一个请求时，实际上就是收到了一个数据包。那么，这个数据包的内容是什么样的呢？TCP四元组指源IP、目的IP、源端口和目的端口，这四个参数独一无二地确定了一条连接。在传输过程中，这些值不会改变。当负载均衡（LB）接收到数据包时，需要将它转发给背后的服务器。为此，需要将目标IP地址改为服务器的IP地址，例如假设服务器的IP地址是192.168.0.3，那么修改后的数据包如下：

。在服务器处理数据包后，由于数据包需要被返回给客户端，因此服务器的网关需要设置为LB的内部IP地址，即192.168.0.1，以便数据包能够成功返回。这样，LB就能成功接收到所有响应数据包了。此刻的数据包情况如下：为何响应数据包需要通过负载均衡器呢？这是为了维持四元组不变。负载均衡器接收到数据包后将源IP改为VIP，客户端才能辨认这是对前次请求的正确响应。当前的数据包内容如下：\n为什么RS的响应数据包需要经过LB呢？因为为了确保四元组不变，LB在接收数据包后会将源IP改为VIP，这样客户端才能识别这是针对之前请求的正确响应。\n背景信息：客户端请求和响应数据包的四元组不能被改变。修改后的网络数据包

是这样的，所以总结 LB 主要工作原理：就是修改进出数据包的 IP。首先将目的IP改为RS的IP，然后传递数据包给RS进行处理，RS处理后再将数据包发送给网关（LB），LB再将源IP修改为其出口的VIP。只要四个元组不变，客户端就能正常收到所请求的响应。为了让大家更直观地了解负载均衡对IP的修改，我制作了一张动图，相信大家看了后会更深刻地理解。从客户端的角度来看，它以为自己在与 LB 路由器背后的 RS 通信，但实际上它只是与 LB 通信。LB 只是起到了虚拟服务器的作用，因此我们将它称为 LVS（Linux 虚拟服务器）。LVS 只具有修改 IP 地址和转发数据包的功能。由于在数据包的进出过程中 LVS 均修改了 IP 地址，因此我们将此模式称为 NAT（网络地址转换）模式。可以看到，在这种工作模式下，网络请求包和网络响应包都必须进行转发。 LVS。看起来这个问题好像已经得到了完美的解决，但是我们忽略了一个因素：每个网络数据包都有大小限制。根据图示所示，在每个数据包中，每个有效载荷（通常为应用层数据）的大小通常不应超过1460字节。在客户端发送请求数据（例如HTTP请求）时，如果超过了1460个字节，就需要将数据分包传输。服务端接收到所有分包后再将其组装成完整的应用层数据。因此，很明显，LVS应该将同一个请求（即四元组相同）的分包转发给同一个RS。否则，如果将分包传输给不同的RS，数据就会变得不完整。因此，LVS需要根据四元组来记录数据包应该发送到哪个RS，具有相同四元组的数据包都应该发送到同一个RS。

四元组的 IP 位于 IP 头中，而端口号则位于 TCP 头中。这意味着 LVS 需要去除 TCP 头来获取端口号，然后根据四元组是否相同来判断是否将数据转发至相同的 RS。每个四元组对应一个 TCP 连接，因此 LVS 具备连接跟踪的能力，连接是在传输层中定义的。我相信你现在理解了一个问题的起源：“LVS具有数据包转发功能，为何称其为四层负载均衡”。经过这种设计，通过LVS负载均衡的机制，成功消除了单机的瓶颈问题，小张的公司成功应对了C10K（一万并发连接），C20K等挑战。。。。经历了瓶颈期后，小章发现了一个严重问题：随着并发数的增加，LVS 已经无法满足要求。由于所有数据包均需经过 LVS 进出，使得它成为了巨大的瓶颈。随着 RS 水平扩展数量的增加，LVS 的崩溃是早晚的事情。是否可以让 LVS 仅负责请求包的转发，而将响应数据直接由 RS 返回给客户端呢？如下所示：

画外音：红色虚线表示数据包的流程，可以看到响应数据包并没有经过 LVS。如果采用这种方式，响应包将不再需要经过 LVS，LVS 的负载压力将自然得到释放。我们称之为 DR（Direct Router，直接路由）模式。

现在有了解决方案，但如何实现呢？这个设计方案需要注意两点：首先 LVS 必须处理所有请求流量并根据负载均衡算法将其转发给 RS；其次，RS 处理完后不经过 LVS，直接将数据包转发给路由器再发送给客户端。这意味着 RS 必须拥有与 LVS 同样的 VIP（四元组不能改变），并且它们必须在同一个子网里（更准确地说，是同一个 VLAN，因为是通过交换机通信的）。因此，LVS 和 RS 都需要两个 IP，一个是 VIP，另一个是子网 IP。那么一个主机如何才能拥有两个 IP 呢？我们都知道，计算机连接网络必须先将网线插入网卡。一个网卡对应一个IP地址，因此一台主机若配备两个网卡，则拥有两个IP地址。但许多人可能不了解的是，一个网卡也可以设置多个IP地址。此外，网卡通常分为两种类型：物理网卡和虚拟网卡。物理网卡是指能够插入网线的网卡。若有多个网卡，通常会将它们命名为 eth0、eth1 等。。。如果一张网卡对应多个 IP 地址，以 eth0 为例，通常会将它们命名为 eth0、eth0:0、eth0:1。。。如果一台机器只有一个网卡，但相应地有两个IP地址（192.168.1.2和192.168.1.3），那么这个网卡的名称被称为"eth0"，而对应的另一个IP地址则被称为"eth0:0 "。\n虚拟网卡通常被称为"loopback"，主要用于本地应用程序之间的网络通信。即使没有网线连接，这些应用程序之间也可以通过虚拟网卡进行通信。与物理网卡一样，虚拟网卡也可以绑定任何可用的IP地址。如果配置了虚拟网卡上的IP地址，则只要有物理网卡，就可以接收和处理目标IP地址为虚拟网卡上IP地址的数据包。 "loopback"默认绑定到本地IP地址"127.0.0.1"。如果需要绑定其他 IP 地址，则通常对应的网卡命名为 lo:0、lo:1 等。星空体育网站。。。

背景声：普通服务器通常会配备LVS系统，这个系统通常会以双网卡的形式存在，一方面因为每个网卡的带宽都是有限的，使用双网卡可以相当于提升一倍的带宽；另一方面也可以作为热备份，如果其中一个网卡损坏了，那么另外一个可以顶替上去。在理解了上述概念后，我们可以对拓扑图进行以下完善:

或许你已经注意到了，RS 的 VIP 绑定在 lo:0 虚拟网卡上，而非物理网卡上。这是为何呢？主要是为了确保所有请求都会传递到 LVS 上。

1. arp_ignore=1

首先要了解的是 LVS 和 RS 都位于同一个子网中。我们需要了解子网的工作原理：子网通常是以太网，使用 MAC 地址进行通信，位于 OSI 模型的第二层。一开始，子网中的计算机互相不知道彼此的 MAC 地址，需要通过 ARP 协议根据 IP 地址来获取其对应的 MAC 地址。获取到 MAC 地址后，首先会在本地的 ARP 表中记录此 IP 地址对应的 MAC 地址（下次就直接在本地缓存中查找 MAC 地址），然后将 IP 对应的 MAC 地址附加到包头上，并将包传输出去。这样，交换机就能够找到对应的计算机了。由于客户端请求了VIP后，请求到达了图中的路由器，路由器需要将请求转发给对应该VIP的机器，因此它首先发起了一个ARP请求，希望能获取到VIP对应的MAC地址。现在面临的问题是，由于三台机器的 IP 地址都是相同的 VIP，如果它们都响应了 ARP 请求，就会导致一个 IP 地址对应了三个 MAC 地址。那么路由器应该使用哪个 MAC 地址呢？解决这一问题解决方案很简单：因为所有请求都经过 LVS，所以只需要让 LVS 响应 arp 请求，阻止另外两台 RS 对 VIP 的 arp 响应就可以。当请求到达 LVS 后，LVS 需要将数据包转发给 RS（假设是 RS2），这时也需要使用 arp 协议获取 RS 的 mac 地址。需要注意的是，LVS 会发送 arp 请求到 RS2 的内网 IP 地址：115.205.4.217（该 IP 地址绑定在物理网卡 eth0 上）。根据以上所述，RS无法响应虚拟网卡绑定的VIP的arp请求，但可以响应物理网卡绑定的IP的arp请求。这就是RS需要将VIP绑定在虚拟网卡上，而将内网IP绑定在物理网卡上的实际原因，即为满足arp响应的需求。

通常服务器会自动响应所有 IP 的 arp 请求，因此需要对 RS 进行额外配置。即：在设置 net.ipv4.conf.all.arp_ignore=1 和 net.ipv4.conf.lo.arp_ignore=1 时，arp_ignore=1 表示的意思是：当目标IP地址是传入接口上已配置的本地地址时，仅回复请求。仅回应目标IP为接收网卡（即物理网卡）上的IP的ARP请求，而忽略目标IP为虚拟网卡上VIP的ARP请求。完成以上设置后，由于仅有 LVS 会响应 VIP 的 ARP 请求（路由器在接收到 LVS 的 ARP 响应后会将 VIP 对应的 MAC 地址记录在 ARP 缓存表中），因此所有请求都会被引导至 LVS 上。接下来，LVS 会成功将数据包发送至 RS2，RS2 处理完后即将数据包从网卡发送出去。但需注意的是，RS2 不能直接通过物理网卡 eth0 发送数据包，因为这样会导致源 IP 被修改为 eth0 的 IP（即 115.205.4.217），进而使四元组发生变化（原因就是协议栈的关系）。因此，我们还需要进行进一步的配置。要让数据包通过lo接口发送，请执行以下操作：

route add -host 115.205.4.214 dev lo:0 # 通过添加一条路由，设置目标 IP为 VIP的数据包将通过lo接口发送。这将确保响应报文的源 IP将设置为 VIP

，然后通过eth0发送。这种方式可以确保四元组不会发生变化。

2. arp_announce=2

接下来有另一个问题，RS2如何将数据包传递给它的网关（即路由器）呢？由于它们仍在同一子网中，因此要通过ARP方式获取网关的MAC地址，然后将网关的MAC地址装载到以太网包头，以便传递给网关。

星空体育入口

2. arp_announce=2

下面还有一个问题：RS2应该如何将数据包发送到它的网关（即路由器）？由于它们位于同一子网中，因此RS2首先要通过ARP获取网关的MAC地址，然后在以太网包头上加入网关的MAC地址来将数据包发送到网关。

但是需要注意的是，在通过ARP获取网关的MAC地址时，网卡会广播发送包含「源IP地址」、「目标IP地址」和「源MAC地址」的ARP请求广播包。在通常情况下，源 IP 可以是数据包的源 IP 或物理网卡上的 IP 进行选择。然而，在 DR 模式下，源 IP 只能选择物理网卡上的 IP，原因是什么？我们知道目标IP是网关的IP，因此网关会对这个arp请求做出响应。但是，同时在收到这个arp响应后，网关还会更新本地arp表：将源IP => 源MAC的对应关系添加进去。这里的源MAC是RS2的MAC地址。还记得之前提到的路由器arp缓存表中保存了LVS的VIP与LVS的MAC地址的对应关系吗？换言之，如果从RS2发送的arp请求中，源IP为数据包的源IP（即VIP），网关收到arp响应后会更新路由表，将VIP的MAC地址更改为RS2的MAC地址！这样，在下一次客户端请求路由器时，数据包会直接被转发给 RS2，无需经过 LVS。因此，RS2需要使用其物理网卡（eth0）对应的IP地址（即115.205.4.217）作为源IP来发出ARP请求，以获取网关的MAC地址。这样就可以避免上述问题的出现。与arp_ignore=1相同，我们需要手动配置该项：

net.ipv4.conf.all.arp_announce=2 net.ipv4.conf.lo.arp_announce=2

arp_announce=2表示忽略IP数据包的源IP地址，并选择发送网卡上最合适的本地地址作为ARP请求的源IP地址。以上内容可能有些抽象，请稍加理解。请多读几遍，认真理解一下。其实主要是为了避免路由器 ARP 缓存表错误地更新了 VIP 的Mac地址为RS的Mac地址。根据上面的介绍，DR模式比较复杂，需要在RS上进行额外的配置，所以在线上一般使用NAT模式。但问题是，如何解决NAT模式下LVS的单点故障问题呢？毕竟所有流量都要经过LVS，会成为一个巨大的风险。随着RS的不断扩容，单点LVS很可能成为问题。此外，由于LVS作为所有RS的网关，它们都必须在相同的网段下运行。在阿里云这样的公有云平台上进行部署显然是不现实的。在公有云中很可能分布着各种资源，这意味着跨 VLAN 通信，而采用 NAT 显然无法满足需求。因此，在 NAT 的基础上出现了 FullNAT，实际上是为了适应公有云而产生的一种方式。在 FullNAT 模式下，LVS 仅将数据包的目标 IP 改为 RS 的 IP；而在 FullNAT 模式下，LVS 还会将源 IP 地址改为 LVS 内网 IP （这是通过 LVS 内核模块 ip_vs 完成的）。值得注意的是，LVS 内网 IP 和 RS 的 IP 可能位于不同的网段下，在公有云平台上通常会部署在企业内网中。这种设置让 LVS 能够实现跨网段与 RS 的通信，避免了单点瓶颈，多台 LVS 可以将请求转发给 RS。根据图示，已配置了两台 LVS，它们与 RS 不位于相同子网，却可以互相通信。部分读者可能会关注一个问题：LVS 转发给 RS 的数据包源 IP（即客户端 IP）被更换成内网 IP，这意味着 RS 接收到的数据包不包含客户端 IP。有时客户端 IP 在数据分析中很重要（比如分析不同地区的下单情况需要客户端 IP），对此情况，LVS 会在接收请求包后在数据包的 TCP Header 中插入客户端 IP信息。如下图所示，现在有两台LVS服务器进行部署，它们与RS的内部网络不在同一个网段中，但仍然可以相互通信。部分读者可能会关注一个问题：LVS将要转发到RS的数据包源IP（即客户端IP，client_ip）被替换成了内网IP。这意味着RS收到的数据包不包含client_ip，而client_ip有时对我们分析数据非常重要（例如，如果要分析不同地理位置的订单分布情况，则需要client_ip）。为此，LVS会在接收到请求包后在数据包的TCP头中插入client_ip。

这幅图便是TCP头部，client_ip被放入了TCP选项字段中，然后只要安装了TOA模块在RS上便能够读取client_ip。TCP选项字段也提醒我们，在设计技术方案时适当增加一些冗余字段能够提高程序的可扩展性。通过

的总结，相信大家已经理解了 LVS 的 NAT、DR和FullNAT的工作原理。除此之外，LVS还有一种TUNNEL隧道模式，但这种模式生产上不太常用，因此我们不进行介绍。此外，每个LVS通常会进行双机热备，备机通过定时发送心跳包来感知LVS的主机存活情况。同时，请注意虚线部分：备机还可以感知服务器的存活情况，如果服务器挂了，LVS会将其剔除，确保LVS转发的流量不会发送到宕机的机器上。小章是指章文嵩博士，他在1998年领导了LVS项目的开发。最初，该项目只有NAT、DR和TUNNEL三种模式。然而，随着阿里云上服务的兴起，这三种模式已无法满足实际部署的需求。因此，他指导团队基于NAT进行改造，推出了FullNAT。值得一提的是，LVS是为数不多由中国人开发并得到Linux官方认可的开源软件之一，已整合至Linux内核中。这展示出这个项目的重要价值和贡献。

这篇文章是从微信公众号"码海"转载而来，可以扫描下方二维码关注该公众号。如需转载本文，请与码海公众号联系。这组数据包括了一些数字，其中包括了一些x和n，还有一个p。