直击 LVS-剖析负载均衡与高可用的关键技术

一、什么是LVS

LVS(Linux Virtual Server)即Linux虚拟服务器,它是一个基于Linux操作系统的虚拟服务器集群系统,主要用于实现高性能、高可用的网络服务。

LVS的核心功能包括负载均衡和高可用性保障。在负载均衡方面,它能够将来自客户端的大量请求均匀地分配到多台后端服务器上,提高整个系统的处理能力和吞吐量。例如,对于一个繁忙的电商网站,LVS可以把用户的访问请求合理地分发到不同的Web服务器,避免单台服务器因负载过高而崩溃。它支持多种负载均衡算法,如轮询、加权轮询、最少连接等。

在高可用性方面,当集群中的某台服务器出现故障时,LVS能够迅速检测到并自动将请求转发到其他正常运行的服务器上,确保服务不间断。比如在在线视频播放应用中,若某台视频服务器故障,LVS会立即切换,将用户请求导向正常服务器,用户基本不会察觉到服务有中断。

LVS工作在OSI模型的第四层(传输层),主要根据IP地址和端口号等网络层信息来分发请求,对上层应用是透明的,这意味着不同类型的应用服务器都能使用LVS进行负载均衡,而无需对应用程序本身做修改。

它有多种工作模式,如NAT模式(网络地址转换),通过调度器进行IP地址转换来实现请求的分发,但调度器可能成为网络瓶颈;DR模式(直接路由),调度器通过修改数据包的MAC地址将请求直接发给后端服务器,性能较高;TUN模式(IP隧道),调度器将请求封装在新的IP数据包中发给后端服务器,可跨越不同网络区域进行负载均衡等。

二、集群与分布式

集群

集群是一组相互连接的计算机或服务器,它们协同工作,在用户或其他计算机看来,就像一个单一的系统。

  1. 主要特点

    • 高可用性
      • 集群中的多台计算机可以互相备份。当其中一台计算机出现故障时,其他计算机可以接管其任务,确保服务不会中断。例如,在一个电子商务网站的服务器集群中,如果一台服务器硬件发生故障,集群系统会自动将其负载转移到其他正常的服务器上,用户仍然可以正常访问网站进行购物等操作,不会明显感觉到服务受到影响。
      • 通过冗余设计,集群能够在部分组件出现问题时继续运行,大大提高了系统的可靠性和稳定性。
    • 高性能和可扩展性
      • 集群可以通过增加更多的计算机来提高整体的计算能力和处理性能。比如在科学计算领域,当需要处理大规模的数据计算任务时,可以不断向集群中添加计算节点,从而能够更快地完成复杂的计算。
      • 多个计算机并行处理任务,能够分担工作负载,提高系统的吞吐量。例如在一个大型网络游戏的服务器集群中,不同的服务器可以分别处理游戏中的不同区域、不同功能(如玩家登录验证、游戏场景渲染、数据存储等),使得整个游戏系统能够支持大量玩家同时在线并流畅运行。
    • 负载均衡
      • 集群能够将任务均匀地分配到各个节点上。以一个网络搜索服务的集群为例,当用户发起搜索请求时,集群管理系统会根据各服务器的负载情况,将请求分配到负载较轻的服务器上进行处理,这样可以充分利用集群中所有服务器的资源,避免某些服务器过载而其他服务器闲置的情况,提高整个系统的资源利用率和响应速度。
  2. 类型

    • 高性能计算集群(High Performance Computing Cluster,HPCC)
      • 主要用于执行大规模的科学计算和工程计算任务。例如在气象预报中,需要处理大量的气象数据并进行复杂的数学模型计算,高性能计算集群可以并行地进行这些计算,快速得出天气预报结果。它通常由大量的计算节点组成,这些节点通过高速网络连接,运行专门的并行计算软件和算法。
      • 像一些汽车制造商在产品设计阶段,利用高性能计算集群对汽车的结构、空气动力学等进行模拟计算,以优化汽车的性能和安全性。
    • 负载均衡集群(Load Balancing Cluster)
      • 其核心功能是将大量的网络请求或计算任务均衡地分配到多台服务器上。常见的互联网公司的 Web 服务器集群就是负载均衡集群的典型应用。通过负载均衡算法,如轮询、加权轮询等,将用户的网页访问请求分发到不同的服务器上,以保证每台服务器都能在合理的负载范围内运行,提高整个网站的服务质量和响应速度。
    • 高可用性集群(High Availability Cluster)
      • 致力于提供不间断的服务。以银行的在线交易系统为例,高可用性集群确保即使某个服务器出现故障,系统仍然能够正常运行,不会影响客户的资金交易等操作。它通常采用冗余配置,包括冗余的硬件、网络设备和数据存储等,并且通过监控和故障切换机制,在主服务器出现问题时自动切换到备用服务器。
  3. 应用领域

    • 企业应用
      • 许多企业采用服务器集群来运行关键业务应用,如企业资源规划(ERP)系统、客户关系管理(CRM)系统等。这些系统对于企业的日常运营至关重要,集群能够保证它们的高可用性和高性能,确保企业业务的正常进行。
      • 例如,一家大型制造企业使用集群来运行其生产管理系统,保证生产计划的制定、物料需求的计算、生产进度的跟踪等功能能够稳定、高效地运行,不受单个服务器故障的影响。
    • 互联网服务
      • 互联网行业广泛使用集群技术。搜索引擎公司利用大规模的服务器集群来处理海量的搜索请求,并快速返回准确的搜索结果。社交网络平台也依靠集群来存储和处理用户的大量数据,如用户的个人信息、照片、动态等,同时保证服务的高可用性,以满足全球用户随时访问的需求。
    • 科学研究
      • 在科学研究领域,集群被用于各种计算密集型的任务。例如,在天文学中,通过集群对大量的天文观测数据进行分析和处理,寻找新的天体、研究星系的演化等;在生物信息学中,利用集群进行基因序列比对、蛋白质结构预测等复杂计算,加速科学研究的进程。

分布式

分布式系统是一组通过网络进行通信、协调的独立计算机组成的系统,这些计算机共同完成一个任务或一组相关任务。

  1. 主要特点

    • 去中心化
      • 分布式系统没有单一的控制中心。各个节点之间是平等的关系,它们通过分布式算法和协议进行协作。例如在一个分布式文件系统中,文件数据被分散存储在多个不同的节点上,没有一个节点能够完全控制整个文件系统,每个节点都负责管理一部分数据,并与其他节点协同工作来提供完整的文件服务。
    • 容错性强
      • 由于分布式系统中的多个节点可以相互协作,当某个节点出现故障时,系统可以通过其他正常节点继续运行,并可以在合适的时候恢复故障节点的数据或功能。比如在一个分布式数据库中,如果某个数据库节点发生故障,其他节点可以继续提供数据服务,并且系统可以通过数据冗余和复制机制,在故障节点恢复后同步数据,保证数据的一致性。
    • 可扩展性好
      • 可以很容易地添加新的节点来扩展系统的性能和容量。以一个分布式计算平台为例,当计算任务增加时,可以方便地添加新的计算节点来分担计算负载,提高整个系统的计算能力,而不需要对整个系统进行大规模的重构。
  2. 架构类型

    • 客户端 - 服务器架构(Client-Server Architecture)
      • 这是一种常见的分布式架构。客户端向服务器发送请求,服务器接收请求并进行处理,然后将结果返回给客户端。例如,在电子邮件系统中,用户使用的电子邮件客户端(如 Outlook、Foxmail 等)就是客户端程序,它向邮件服务器发送邮件发送、接收等请求,邮件服务器负责处理这些请求并管理邮件数据的存储和转发。
    • 对等网络架构(Peer-to-Peer Architecture,P2P)
      • 在 P2P 架构中,每个节点既可以作为客户端请求服务,也可以作为服务器提供服务。节点之间直接进行通信和资源共享,没有中心服务器的集中控制。例如,在文件共享应用 BitTorrent 中,用户下载文件时,同时也会将已下载的部分上传给其他用户,每个用户的计算机都是一个节点,它们共同组成了一个分布式的文件共享网络。
    • 分布式对象架构(Distributed Object Architecture)
      • 这种架构中,不同的对象分布在网络中的不同节点上,它们通过远程方法调用(Remote Method Invocation,RMI)等机制进行通信和协作。例如,在一个分布式企业应用中,不同的业务对象(如订单对象、客户对象等)可能分布在不同的服务器上,它们通过 RMI 等技术进行交互,共同完成企业的业务流程。
  3. 应用领域

    • 分布式计算
      • 利用分布式系统将一个大型的计算任务分解成多个小任务,分配到不同的计算机上并行计算。例如,在大数据处理中,使用 Hadoop 等分布式计算框架,将大规模的数据处理任务分布到多台计算机上进行,如数据的存储(Hadoop Distributed File System,HDFS)和数据的计算(MapReduce 编程模型),从而能够高效地处理海量数据。
    • 分布式存储
      • 将数据分散存储在多个节点上,提高数据的可靠性和可用性,并可以实现大规模的数据存储。除了前面提到的分布式文件系统,像一些云存储服务(如阿里云 OSS、腾讯云 COS 等)也是基于分布式存储技术,用户的数据被存储在多个数据中心的不同存储设备上,即使某个存储设备出现故障,数据仍然可以从其他设备上恢复。
    • 分布式通信
      • 例如即时通讯应用,用户之间的消息传递是通过分布式的服务器和网络节点来实现的。当用户发送一条消息时,消息会通过分布式的通信系统传递到接收方的设备上,即使部分网络节点出现故障,消息也可以通过其他路径传递,保证通信的可靠性。同时,分布式通信系统可以支持大量用户同时在线和实时通信。

三、LVS集群类型

LVS(Linux Virtual Server)集群主要有以下三种类型:

NAT模式(Network Address Translation,网络地址转换)集群

  1. 工作原理
    • 客户端的请求到达 LVS 调度器,调度器将请求的目标 IP 地址(即后端真实服务器的 IP 地址)转换为自己的 IP 地址,并将请求发送到后端服务器。
    • 后端服务器处理完请求后,将响应返回给调度器,调度器再将响应的源 IP 地址转换回后端服务器的 IP 地址,然后发送给客户端。
  2. 特点
    • 优点
      • 配置简单,只需要一个公网 IP 地址即可实现负载均衡。它可以将多个内网服务器隐藏在调度器后面,提高了服务器的安全性。
    • 缺点:调度器可能成为网络瓶颈,因为所有的请求和响应都需要经过调度器进行地址转换,当请求量很大时,调度器的性能可能会受到影响。

DR模式(Direct Routing,直接路由)集群

  1. 工作原理
    • 调度器和后端服务器都连接在同一个物理网络中,客户端的请求到达调度器后,调度器通过修改数据包的 MAC 地址,将请求直接发送到后端服务器。
    • 后端服务器处理完请求后,直接将响应返回给客户端,而不需要经过调度器。
  2. 特点
    • 优点:性能较高,因为响应数据不需要经过调度器,直接由后端服务器返回给客户端。它可以支持大规模的并发请求。
    • 缺点:要求调度器和后端服务器必须在同一个局域网内,且后端服务器需要配置相同的 VIP(虚拟 IP 地址),配置相对复杂一些。

TUN模式(IP Tunneling,IP 隧道)集群

  1. 工作原理
    • 调度器将客户端的请求封装在一个新的 IP 数据包中,然后发送给后端服务器。
    • 后端服务器接收到数据包后,解封装并处理请求,然后将响应直接返回给客户端。
  2. 特点
    • 优点:可以跨越不同的网络区域进行负载均衡,后端服务器可以分布在不同的地理位置。它适用于分布式的服务器架构。
    • 缺点:需要额外的 IP 隧道配置,对网络环境有一定要求,并且会增加一些网络开销。

四、LVS调度算法

轮询(Round Robin,RR)调度算法

  1. 算法原理
    • 轮询调度算法是将客户端的请求依次轮流分配到后端的真实服务器。它按照服务器的顺序,将请求轮流分配到每台服务器,不考虑服务器的实际负载情况和性能差异。
    • 例如,假设有3台真实服务器A、B、C,第一个请求分配给服务器A,第二个请求分配给服务器B,第三个请求分配给服务器C,第四个请求又重新分配给服务器A,如此循环。
  2. 适用场景
    • 适用于后端服务器性能相近,且没有明显的性能差异和特殊负载情况的场景。比如一些简单的静态网页服务,各个服务器的处理能力相对均衡,轮询算法可以平均分配请求,保证每台服务器都有机会处理请求。

加权轮询(Weighted Round Robin,WRR)调度算法

  1. 算法原理
    • 根据服务器的性能不同为每台服务器分配不同的权重。性能好的服务器权重高,会分配到更多的请求;性能差的服务器权重低,分配到的请求相对较少。
    • 例如,服务器A权重为3,服务器B权重为2,服务器C权重为1。那么在一轮分配中,服务器A会分配到3个请求,服务器B会分配到2个请求,服务器C会分配到1个请求,然后再按照这个比例循环分配。
  2. 适用场景
    • 当后端服务器的性能存在差异时,加权轮询算法可以更合理地分配请求。比如在一个电商网站中,有一些性能较强的服务器专门处理图片资源的请求,这些服务器可以被赋予较高的权重;而一些性能稍弱的服务器处理普通文本内容的请求,权重相对较低。这样可以根据服务器的实际处理能力来分配负载,提高整个系统的效率。

源地址哈希(Source Hashing)调度算法 

  1. 算法原理
    • 源地址哈希调度算法根据请求的源IP地址,通过哈希函数计算出一个数值,然后用该数值对服务器列表的大小取模,得到的结果就是要分配的服务器编号。
    • 例如,假设有3台服务器,源IP地址为192.168.1.10的客户端发起请求,通过哈希函数计算出哈希值为123,服务器列表大小为3,那么 123 % 3 = 0,就将该请求分配到编号为0的服务器(假设服务器从0开始编号)。
  2. 适用场景
    • 此算法适用于需要保证相同源IP地址的请求始终被分配到同一台服务器的场景。比如在一些需要进行会话保持的应用中,用户的会话相关数据可能存储在特定的服务器上,如果请求不被分配到同一台服务器,可能会导致会话数据无法正确获取。例如在一个在线购物网站中,用户在购物过程中的一系列操作(如将商品加入购物车、结算等),如果采用源地址哈希算法,就能确保这些操作都由同一台服务器处理,保证购物车数据等会话信息的正确使用。

目标地址哈希(Destination Hashing)调度算法

  1. 算法原理
    • 目标地址哈希调度算法根据请求的目标IP地址(在一些情况下也可能是目标URL等其他与请求目标相关的信息),通过哈希函数计算出一个数值,然后用该数值对服务器列表的大小取模,以此来决定将请求分配到哪台服务器。
    • 例如,有一组服务器处理对不同域名的请求,当请求的目标域名是www.example.com时,通过哈希函数计算出哈希值为234,假设有4台服务器,服务器列表大小为4,那么 234 % 4 = 2,就将该请求分配到编号为2的服务器。
  2. 适用场景
    • 目标地址哈希算法适用于与请求目标相关的场景。比如在一个内容分发网络(CDN)中,不同的目标地址(可能是不同地区的用户请求访问相同的内容资源),通过目标地址哈希算法可以将请求分配到合适的服务器,该服务器可能存储了最适合该地区用户访问的内容副本,从而提高内容的分发效率和用户的访问速度。另外,在一些对特定目标资源有特殊处理需求的系统中,也可以使用该算法确保相关请求都能分配到合适的服务器进行处理。

最少连接(Least Connections,LC)调度算法

  1. 算法原理
    • 将新的请求分配给当前连接数最少的服务器。调度器会实时监测每台真实服务器的连接数,当有新的请求到来时,选择连接数最少的服务器进行分配。
    • 假设服务器A当前连接数为10,服务器B当前连接数为8,服务器C当前连接数为12。当有一个新请求时,调度器会将请求分配给服务器B。
  2. 适用场景
    • 适用于请求处理时间差异较大的场景。在这种情况下,通过关注服务器的连接数而不是简单的轮流分配,可以更好地平衡服务器的负载。例如在一个在线视频平台,某些视频的处理可能需要较长时间,导致服务器连接数较长时间占用,最少连接算法可以动态地将新的视频播放请求分配到当前连接数较少的服务器上,提高系统的响应速度和整体性能。

加权最少连接(Weighted Least Connections,WLC)调度算法

  1. 算法原理
    • 是最少连接算法的改进版本,它在考虑服务器当前连接数的基础上,还结合了服务器的权重。服务器的权重表示其处理能力的相对大小。
    • 例如,服务器A权重为3,当前连接数为10;服务器B权重为2,当前连接数为8;服务器C权重为1,当前连接数为6。首先计算每台服务器的加权连接数,服务器A的加权连接数为10/3≈3.33,服务器B的加权连接数为8/2 = 4,服务器C的加权连接数为6/1 = 6。那么新的请求会分配给服务器A,因为它的加权连接数最小。
  2. 适用场景
    • 适用于后端服务器性能和处理能力有差异,同时又需要考虑服务器当前负载情况的场景。比如在一个企业的内部办公系统中,有不同配置和性能的服务器来处理各种办公应用的请求,通过加权最少连接算法,可以根据服务器的权重和当前连接数来合理分配负载,既保证高性能服务器能承担更多任务,又能让低性能服务器在其能力范围内处理请求,提高整个系统的稳定性和效率。

基于局部性的最少连接(Locality-Based Least Connections,LBLC)调度算法

  1. 算法原理
    • 该算法主要是根据“请求的目标IP地址的相似性”来进行调度。它会将来自同一目标IP地址的请求分配到同一台服务器上,当该服务器不可用时,才会分配到其他服务器。
    • 例如,有多个来自相同IP地址的连续请求,在初始阶段都会分配到服务器A上,如果服务器A出现故障,后续这些请求会尝试分配到其他服务器。但只要服务器A恢复正常,又会将来自该IP地址的新请求分配回服务器A。
  2. 适用场景
    • 适用于具有“局部性”特点的应用场景,例如一些企业的业务系统,用户通常会在一段时间内频繁访问相同的业务模块或数据,基于局部性的最少连接算法可以提高缓存命中率,减少服务器之间的数据传输,从而提高系统的性能。

带复制的基于局部性最少连接(Locality-Based Least Connections with Replication,LBLCR)调度算法

  1. 算法原理
    • 在基于局部性的最少连接算法基础上,增加了复制功能。它除了将请求分配到“合适”的服务器外,还会将请求复制到其他服务器上。
    • 例如,当一个请求分配到服务器A时,同时也会将该请求复制到服务器B和服务器C(假设集群中有这三台服务器)。这样,当服务器A出现故障时,其他服务器(如B或C)可以直接处理后续来自相同目标IP地址的请求,而不需要重新从故障的服务器A获取数据。
  2. 适用场景
    • 适用于对数据可用性和系统可靠性要求更高的场景。比如在一些金融交易系统中,数据的准确性和及时性至关重要,通过复制请求到多个服务器,可以在某台服务器出现故障时,其他服务器能够快速接管服务,减少数据丢失和服务中断的风险,保证交易的正常进行。

 五、LVS相关命令

1.lvs软件相关信息

  • 程序包:ipvsadm
  • Unit File: ipvsadm.service
  • 主程序:/usr/sbin/ipvsadm
  • 规则保存工具:/usr/sbin/ipvsadm-save
  • 规则重载工具:/usr/sbin/ipvsadm-restore
  • 配置文件:/etc/sysconfig/ipvsadm-config
  • ipvs调度规则文件:/etc/sysconfig/ipvsadm

2.ipvsadm命令

核心功能 :
  • 集群服务管理:增、删、改
  • 集群服务的RS管理:增、删、改
  • 查看 
命令参数
管理集群服务
ipvsadm -A|E -t tcp |u udp |f (防护墙标签) \
service-address( 集群地址 ) \
[-s scheduler( 调度算法 )] \
[-p [timeout]] \
[-M netmask] \
[--pepersistence_engine] \
[-b sched-flags]
ipvsadm -D -t|u|f service-address 删除
ipvsadm –C 清空
ipvsadm –R 重载
ipvsadm -S [-n] 保存
管理集群中的 real server
ipvsadm -a|e -t|u|f service-address -r server-address [-g | -i| -m]( 工作模式 ) [-w
weight]( 权重 )
ipvsadm -d -t|u|f service-address -r server-address 删除 RS
ipvsadm -L|l [options] 查看 rs

3.lvs集群中的增删改

管理集群服务中的增删改

ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]
-A # 添加
-E # 修改
-t
#tcp 服务
-u #udp 服务
-s # 指定调度算法,默认为 WLC
-p # 设置持久连接超时,持久连接可以理解为在同一个时间段同一个来源的请求调度到同一 Realserver
-f #firewall mask 火墙标记,是一个数字

管理集群中RealServer的曾增删改

ipvsadm -a|e -t|u|f service-address -r realserver-address [-g|i|m] [-w weight]

-a # 添加 realserver
-e # 更改 realserver
-t #tcp 协议
-u #udp 协议
-f # 火墙 标签
-r #realserver 地址
-g # 直连路由模式
-i #ipip 隧道模式
-m #nat 模式
-w # 设定权重
-Z # 清空计数器
-C # 清空 lvs 策略
-L # 查看 lvs 策略
-n # 不做解析
--rate :输出速率信息

六、部署NAT模式集群

四台虚拟机

测试:172.25.254.129

lvs:需要两块网卡(用于划分vlan)

172.25.254.130        192.168.0.128

web服务器:两台web服务器的网卡都是仅主机模式

webserver1:192.168.0.129       webserver2:192.168.0.130

lvs打开内核路由功能

两台路由器修改网关

webserver1

webserver2

在lvs中检测

lvs中安装lvs软件

编写策略

测试

七、部署DR模式集群

我们在NAT模式上加入一个路由器router,router也是两块网卡,第一块网卡为NAT模式,第二块网卡为仅主机模式

第一块网卡:172.25.254.150        第二块网卡192.168.0.150

删除lvs上的一块网卡

LVS端修改网关

两台web服务器也要修改网关

客户端也修改网关

路由器打开内核路由功能

两台web服务器使VIP不对外响应

在lvs主机和两台web服务器添加VIP

在lvs上编写策略

测试

八、防火墙标记解决轮询错误

http https 为例,当我们在web服务器 中同时开放 80 443 端口,那么默认控制是分开轮询的,这样我们就出 现了一个轮询错乱的问题
当第一次访问 80 被轮询到webserver 1 后下次访问 443 仍然可能会被轮询到webserver 1

在webserver1和webserver2中安装mod_ssl并重启http服务

[root@localhost ~]# systemctl restart httpd
编写策略

测试

当访问vip时两次调度都到了

防火墙标记解决轮询调度问题
vs 调度器中设定端口标签,认为 80 443 是一个整体
测试一下
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

田驰02

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值