揭开 LVS 神秘的面纱

2019-07-04 15:31:24 浏览数 (1)

文章目录

  • 揭开 LVS 神秘的面纱
    • 一 前言
    • 二 认识 LVS
    • 三 了解三种模式
      • 3.1 Virtual Server via Network Address Translation（VS/NAT）
      • 3.2 Virtual Server via IP Tunneling（VS/TUN）
      • 3.3 Virtual Server via Direct Routing（VS/DR）
    • 四 每种模式的优缺点
      • 4.1 NAT 模式
      • 4.2 TUN 模式
      • 4.3 DR 模式
    • 五 八种负载调度算法
    • 六 总结
    • 七 参考资料

揭开 LVS 神秘的面纱

一 前言

作为一名具备多年经验的老运维，LVS 的名声可谓如雷贯耳，一直都在寻找一个机会系统化地收集整理相关资料。时至今日，终于有时间详细地学习和了解 LVS 相关的知识。

LVS 是linux virtual server的简写，意为：Linux虚拟服务器，这是一个由章文嵩博士在1998年5月发起的一个自由软件项目。Linux 2.4 以后的内核版本，已经集成了 LVS 的各个功能模块，我们可以直接使用LVS提供的各种功能。

二 认识 LVS

LVS集群的特点可以归结如下：

  • 功能

有实现三种IP负载均衡技术和八种连接调度算法的IPVS软件。在IPVS内部实现上，采用了高效的Hash函数和垃圾回收机制，能正确处理所调度报文相关的ICMP消息（有些商品化的系统反而不能）。虚拟服务的设置数目没有限制，每个虚拟服务有自己的服务器集。它支持持久的虚拟服务（如HTTP Cookie和HTTPS等需要该功能的支持），并提供详尽的统计数据，如连接的处理速率和报文的流量等。针对大规模拒绝服务（Deny of Service）攻击，实现了三种防卫策略。

有基于内容请求分发的应用层交换软件KTCPVS，它也是在Linux内核中实现。有相关的集群管理软件对资源进行监测，能及时将故障屏蔽，实现系统的高可用性。主、从调度器能周期性地进行状态同步，从而实现更高的可用性。

  • 适用性

后端服务器可运行任何支持TCP/IP的操作系统，包括 Linux，各种 Unix（如FreeBSD、Sun Solaris、HP Unix等），Mac/OS 和 Windows NT/2000等。

负载调度器能够支持绝大多数的 TCP 和 UDP 协议：

协议

内容

TCP

HTTP，FTP，PROXY，SMTP，POP3，IMAP4，DNS，LDAP，HTTPS，SSMTP等

UDP

DNS，NTP，ICP，视频、音频流播放协议等

无需对客户机和服务器作任何修改，可适用大多数 Internet 服务。

  • 性能

LVS服务器集群系统具有良好的伸缩性，可支持几百万个并发连接。配置100M网卡，采用 VS/TUN 或 VS/DR 调度技术，集群系统的吞吐量可高达1Gbits/s；如配置千兆网卡，则系统的最大吞吐量可接近10Gbits/s。

  • 可靠性

LVS 服务器集群软件已经在很多大型的、关键性的站点得到很好的应用，所以它的可靠性在真实应用得到很好的证实。有很多调度器运行一年多，未作一次重启动。

  • 软件许可证

LVS集群软件是按 GPL（GNU Public License）许可证发行的自由软件，这意味着你可以得到软件的源代码，有权对其进行修改，但必须保证你的修改也是以 GPL 方式发行。

根据 LVS 工作模式的不同，LVS 工作模式分为三种：NAT 模式、TUN 模式、DR模式。

三 了解三种模式

3.1 Virtual Server via Network Address Translation（VS/NAT）

通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。架构参考下图：

3.2 Virtual Server via IP Tunneling（VS/TUN）

采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。架构参考下图：

3.3 Virtual Server via Direct Routing（VS/DR）

VS/DR通过改写请求报文的 MAC 地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地 提高集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连在同一物理网段上。架构参考下图：

四 每种模式的优缺点

4.1 NAT 模式

优点：

  • 服务器可以运行任何支持TCP/IP的操作系统，它只需要一个IP地址配置在调度器上，服务器组可以用私有的IP地址。
  • 采用内部 IP，服务节点隐蔽，安全性较好。
  • 原理、配置简单，容易理解。

缺点：

  • 伸缩能力有限， 当服务器结点数目升到20时，调度器本身有可能成为系统的新瓶颈，因为在NAT中请求和响应报文都需要通过负载调度器。

4.2 TUN 模式

优点：

  • 可以调度百台以上的服务器（同等规模的服务器），而它不会成为系统的瓶颈。可以用来构建高性能的超级服务器。
  • 原理、配置简单，容易理解。

缺点：

  • TUN技术对服务器有要求，即所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议。
  • 节点暴露，安全性不如 NAT 模式。

4.3 DR 模式

优点：

  • 可以调度百台以上的服务器（同等规模的服务器），而它不会成为系统的瓶颈。可以用来构建高性能的超级服务器。
  • 跟 TUN 模式相比，这种方法没有IP隧道的开销。

缺点：

  • 要求负载调度器与实际服务器都有一块网卡连在同一物理网段上，服务器网络设备（或者设备别名）不作ARP响应，或者能将报文重定向（Redirect）到本地的Socket端口上。
  • 节点暴露，安全性不如 NAT 模式。

整合一下，得到下表：

模式

优点

缺点

NAT

服务器可以运行任何支持TCP/IP的操作系统。采用内部 IP，服务节点隐蔽，安全性较好。原理、配置简单，容易理解。

伸缩能力有限。当服务器结点数目升到20时，调度器本身有可能成为系统的新瓶颈，因为在NAT中请求和响应报文都需要通过负载调度器。

TUN

可以调度百台以上的服务器（同等规模的服务器），而它不会成为系统的瓶颈。可以用来构建高性能的超级服务器。原理、配置简单，容易理解。

TUN技术对服务器有要求，即所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议。节点暴露，安全性不如 NAT 模式。

DR

可以调度百台以上的服务器（同等规模的服务器），而它不会成为系统的瓶颈。可以用来构建高性能的超级服务器。跟 TUN 模式相比，这种方法没有IP隧道的开销。

要求负载调度器与实际服务器都有一块网卡连在同一物理网段上，服务器网络设备（或者设备别名）不作ARP响应，或者能将报文重定向（Redirect）到本地的Socket端口上。节点暴露，安全性不如 NAT 模式。

  1. 服务器可以运行任何支持TCP/IP的操作系统。
  2. 采用内部 IP，服务节点隐蔽，安全性较好。
  3. 原理、配置简单，容易理解。
  4. 伸缩能力有限。当服务器结点数目升到20时，调度器本身有可能成为系统的新瓶颈，因为在NAT中请求和响应报文都需要通过负载调度器。

TUN

  1. 可以调度百台以上的服务器（同等规模的服务器），而它不会成为系统的瓶颈。可以用来构建高性能的超级服务器。
  2. 原理、配置简单，容易理解。
  3. TUN技术对服务器有要求，即所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议。
  4. 节点暴露，安全性不如 NAT 模式。

DR

  1. 可以调度百台以上的服务器（同等规模的服务器），而它不会成为系统的瓶颈。可以用来构建高性能的超级服务器。
  2. 跟 TUN 模式相比，这种方法没有IP隧道的开销。
  3. 要求负载调度器与实际服务器都有一块网卡连在同一物理网段上，服务器网络设备（或者设备别名）不作ARP响应，或者能将报文重定向（Redirect）到本地的Socket端口上。
  4. 节点暴露，安全性不如 NAT 模式。

五 八种负载调度算法

针对不同的网络服务需求和服务器配置，IPVS调度器实现了如下八种负载调度算法：

  • 轮询（Round Robin）

调度器通过"轮询"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。

  • 加权轮询（Weighted Round Robin）

调度器通过"加权轮询"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

  • 最少链接（Least Connections）

调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。

  • 加权最少链接（Weighted Least Connections）

在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

  • 基于局部性的最少链接（Locality-Based Least Connections）

“基于局部性的最少链接” 调度算法是针对目标IP地址的负载均衡，目前主要用于 Cache 集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务器，将请求发送到该服务器。

  • 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）

"带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于 Cache 集群系统。它与 LBLC 算法的不同之处是它要维护从一个 目标 IP 地址到一组服务器的映射，而 LBLC 算法维护从一个目标 IP 地址到一台服务器的映射。该算法根据请求的目标 IP 地址找出该目标 IP 地址对应的服务器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小连接"原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

  • 目标地址散列（Destination Hashing）

"目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

  • 源地址散列（Source Hashing）

"源地址散列"调度算法根据请求的源 IP 地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

六 总结

本文大量引用了章博士原文，并在此基础之上作了一些延申与总结，旨在学习、交流，也为将来自己查阅资料时节约时间。由于时间仓促，难免疏漏，望诸位多多指教。

编程算法 nat NAT网关 tcp/ip

0 人点赞