LVS集群基础概念

　　当服务器遇到性能瓶颈需要进行扩展时，一般来说有两种解决思路：Scale-up 和 Scale out，也称作垂直扩展和水平扩展。
常见的负载均衡器
　　根据工作在的协议层划分可划分为：

• 　　四层负载均衡：根据请求报文中的目标地址和端口进行调度
  
• 　　七层负载均衡：根据请求报文的内容进行调度，这种调度属于「代理」的方式
  

　　根据软硬件划分：

• 　　硬件负载均衡：
  
  
  
  • 　　F5 的 BIG-IP
    
  • 　　Citrix 的 NetScaler
    
  
  

　　这类硬件负载均衡器通常能同时提供四层和七层负载均衡，但同时也价格不菲。

• 　　软件负载均衡：
  
  
  
  • 　　TCP 层：LVS，HaProxy，Nginx
    
  • 　　基于 HTTP 协议：Haproxy，Nginx，ATS（Apache Traffic Server），squid，varnish
    
  • 　　基于 MySQL 协议：mysql-proxy
    
  
  

LVS 简介
　　LVS是Linux Virtual Server的简写，即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。
　　LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。
LVS 体系结构

• 　　A、负载调度器（load balancer）
  

　　调度器是服务器集群系统的唯一入口点（Single Entry Point），它可以采用IP负载均衡技术、基于内容请求分发技术或者两者相结合。
　　在IP负载均衡技术中，需要服务器池拥有相同的内容提供相同的服务。当客户请求到达时，调度器只根据服务器负载情况和设定的调度算法从服务器池中选出一个服务器，将该请求转发到选出的服务器，并记录这个调度；当这个请求的其他报文到达，也会被转发到前面选出的服务器。
　　在基于内容请求分发技术中，服务器可以提供不同的服务，当客户请求到达时，调度器可根据请求的内容选择服务器执行请求。
　　因为所有的操作都是在Linux操作系统核心空间中完成的，它的调度开销很小，所以它具有很高的吞吐率。服务器池的结点数目是可变的。当整个系统收到的负载超过目前所有结点的处理能力时，可以在服务器池中增加服务器来满足不断增长的请求负载。
　　对大多数网络服务来说，请求间不存在很强的相关性，请求可以在不同的结点上并行执行，所以整个系统的性能基本上可以随着服务器池的结点数目增加而线性增长。

• 　　B、服务器池（server array）
  
• 　　C、共享存储（shared storage）
  

　　共享存储通常是数据库、网络文件系统或者分布式文件系统。
　　服务器结点需要动态更新的数据一般存储在数据库系统中，同时数据库会保证并发访问时数据的一致性。
　　静态的数据可以存储在网络文件系统（如NFS/CIFS）中，但网络文件系统的伸缩能力有限，一般来说，NFS/CIFS服务器只能支持3~6个繁忙的服务器结点。对于规模较大的集群系统，可以考虑用分布式文件系统，如AFS、GFS、Coda和Intermezzo等。分布式文件系统可为各服务器提供共享的存储区，它们访问分布式文件系统就像访问本地文件系统一样，同时分布式文件系统可提供良好的伸缩性和可用性。
工作模型

• 　　VS/NAT技术。Virtual Server via Network Address Translation
  
• 　　VS/TUN技术。Virtual Server via IP Tunneling
  
• 　　VS/DR技术。Virtual Server via Direct Routing
  
• 　　VS/DNAT技术。Virtual Server via Destination Network Address Translation
  

　　LVS 集群的设备地址命名
　　VIP：Virtual IP，LVS 面向用户请求的 IP 地址
　　RIP：Real server IP，后端服务器用于和 LVS 通信的 IP 地址
　　DIP：Director IP，LVS 用户和后端服务器通信的 IP 地址
　　CIP：Client IP，客户端 IP 地址
LVS-NAT

　　LVS-NAT 的特性：
　　* 集群节点跟 Director 必须在同一个 IP 网络中
　　* RIP 通常是私有地址，仅用于各集群节点间的通信
　　* Director 位于 client 和 Realserver 之间，负责处理进出的所有报文
　　* Realserver 必须将网关指向 DIP
　　* 支持端口映射
　　* 较大规模应用场景中，Director 易成为系统瓶颈（bottleneck）
LVS-DR

　　DR 值 Direct Routing，直接路由，DR 模型中，Director 和 Realserver 处在同一网络中，对于 Director，VIP 用于接受客户端请求，DIP 用于和 Realserver 通信。对于 Realserver，每个 Realserver 都配有和 Director 相同的 VIP（此 VIP 隐藏，关闭对 ARP 请求的响应），仅用户响应客户端的请求，RIP 用于和 Director 通信。
　　当客户端请求集群服务时，请求报文发送至 Director 的 VIP（Realserver的 VIP 不会响应 ARP 请求），Director 将客户端报文的源和目标 MAC 地址进行重新封装，将报文转发至 Realserver，Realserver 接收转发的报文。此时报文的源 IP 和目标 IP 都没有被修改，因此 Realserver 接受到的请求报文的目标 IP 地址为本机配置的 VIP，它将使用自己的 VIP 直接响应客户端。
　　LVS-DR 模型中，客户端的响应报文不会经过 Director，因此 Director 的并发能力有很大提升。
　　LVS-DR 模型的特性：

• 　　保证前端路由器将目标地址为 VIP 的报文通过 ARP 解析后送往 Director。
  
  
  
  • 　　静态绑定：在前端路由将 VIP 对应的目标 MAC 地址静态配置为Director VIP 接口的 MAC 地址。
    
  • 　　arptables：在各 Realserver 上，通过 arptables 规则拒绝其响应对 VIP 的 ARP 广播请求
    
  • 　　修改内核参数：在 Realserver 上修改内核参数，并结合地址的配置方式实现拒绝响应对 VIP 的 ARP 广播请求
    
  
  
• 　　各RIP 必须与 DIP 在同一个物理网络中
  
• 　　RS 的 RIP 可以使用私有地址，也可以使用公网地址，以方便配置
  
• 　　Director 仅负责处理入站请求，响应报文由 Realserver 直接发往客户端
  
• 　　Realserver 不能将网关指向 DIP，而直接使用前端网关
  
• 　　不支持端口映射
  

LVS-TUN

　　和 DR 模型类似，Realserver 都配有不可见的 VIP，Realserver 的 RIP 是公网地址，且可能和 DIP 不再同一网络中。当请求到达 Director 后，Director 不修改请求报文的源 IP 和目标 IP 地址，而是使用 IP 隧道技术，使用 DIP 作为源 IP，RIP 作为目标 IP 再次封装此请求报文，转发至 RIP 的 Realserver 上，Realserver 解析报文后仍然使用 VIP 作为源地址响应客户端。
　　LVS-TUN 的特性：

• 　　集群节点和可以跨越 Internet
  
• 　　RIP，DIP，VIP 都是公网地址
  
• 　　Director 仅负责处理入站请求，响应报文由 Realserver 直接发往客户端
  
• 　　Realserver 使用自己的网关而不是 Director
  
• 　　Realserver 只能使用支持隧道功能的操作系统
  
• 　　不支持端口映射
  

LVS-FULLNAT
　　FULLNAT 由淘宝研发，目前还没有加入至 CentOS 可用的内核中，使用时需要向内核打补丁。
　　类似于DNAT，它修改请求报文的源地址为 DIP，目标地址为 RIP 来实现转发。对于响应报文，源地址修改为 VIP，目标地址修改为 CIP 来实现转发。
　　特点：

• 　　RIP，DIP 可以使用私有地址
  
• 　　RIP 和 DIP 可以不在同一网络中，且RIP的网关不需要指向DIP
  
• 　　支持端口映射
  
• 　　请求和响应报文都经由Director
  

LVS 的调度算法
　　当 LVS 接受到一个客户端对集群服务的请求后，它需要进行决策将请求调度至某一台后端主机进行响应。LVS 的调度算法共有 10 种，按类别可以分为动态和静态两种类型。
静态调度算法

• 　　RR：round robin，轮询，即简单在各主机间轮流调度
  
• 　　WRR：weighted round robin，加权轮询，根据各主机的权重进行轮询
  
• 　　SH：source hash，源地址哈希，对客户端地址进行哈希计算，保存在 Director 的哈希表中，在一段时间内，同一个客户端 IP 地址的请求会被调度至相同的 Realserver。sh 算法的目的是实现 session affinity（会话绑定），但是它也在一定程度上损害了负载均衡的效果。如果集群本身有 session sharing 机制或者没有 session 信息，那么不需要使用 sh 算法
  
• 　　DH：destination hash，和 sh 类似，dh 将请求的目标地址进行哈希，将相同 IP 的请求发送至同一主机，dh 机制的目的是，当 Realserver 为透明代理缓存服务器时，提高缓存的命中率。
  

动态调度算法
　　动态调度算法在调度时，会根据后端 Realserver 的负载状态来决定调度选择，Realserver 的负载状态通常由活动链接（active），非活动链接（inactive）和权重来计算。
　　LC：least connected，最少连接，LVS 根据 overhead = active*256 + inactive 计算服务器的负载状态，每次选择 overhead 最小的服务器
　　WLC：weighted lc，加权最少连接，LVS 根据 overhead = (active*256+inactive)/weight 来计算服务器负载，每次选择 overhead 最小的服务器，它是 LVS 的默认调度算法
　　SED：shortest expected delay，最短期望延迟，它不对 inactive 状态的连接进行计算，根据 overhead = (active+1)*256/weight 计算服务器负载，选择 overhead 最小的服务器进行调度
　　NQ：never queue，当有空闲服务器时，直接调度至空闲服务器，当没有空闲服务器时，使用 SED 算法进行调度
　　LBLC：locality based least connection，基于本地的最少连接，相当于 dh + wlc，正常请求下使用 dh 算法进行调度，如果服务器超载，则使用 wlc 算法调度至其他服务器
　　LBLCR：locality based least connection with replication，基于本地的带复制功能的最少连接，与 LBLC 不同的是 LVS 将请求 IP 映射至一个服务池中，使用 dh 算法调度请求至对应的服务池中，使用 lc 算法选择服务池中的节点，当服务池中的所有节点超载，使用 lc 算法从所有后端 Realserver 中选择一个添加至服务池中。
　　作者：程序员写文章
　　链接：https://zhuanlan.zhihu.com/p/34220208