Lvs常用术语说明
术语 |
解释 |
Load balancer或director |
负载调度器 |
RS或Real Server |
真实服务器，提供服务的服务器 |
VIP |
虚拟IP地址，客户端访问集群的地址 |
RIP |
集群所提供应用程序的地址（HTTP，FTP） |
DIP |
调度器的真实地址 |
Lvs的类型
Lvs-nat
他通过修改请求报文的目标地址为根据调度算法所挑选出的某RS的RIP来进行转发。
架构特性：
（1） Rs应该使用私有地址，即RIP应该为私有地址，各RS的网关必须执行DIP
（2） 请求报文和响应报文都经由Directory转发；调度器作为所有服务器节点网关，即作为客户端的访问入口，也是各节点回应客户端的访问出口。
（3） 支持端口映射
（4） RS可以使用任意类型的OS
（5） RS的RIP必须与Directory的DIP在同一网络，中间不需要路由器
NAT模型优缺点：
优点：节点服务器使用私有IP地址，与负载调度器位于同一个物理网络，安全性比DR模式和TUN模式要高。
缺点：调度器位于客户端和集群节点之间，并负责处理进出的所有通信；（压力大的根本原因）大规模应用场景中，调度器容易成为系统瓶颈。
请求和响应图解说明：
（1） 客户端访问集群的VIP地址，请求web服务。（请求报文：源地址为CIP，目标地址为VIP）
（2） 调度器收到客户端的请求报文，会修改请求报文中的目标地址（VIP）为RIP，并且将请求根据相应的调度算法送往后端web服务器。（请求报文：源地址CIP，目标地址为RIP）
（3） Web服务器收到请求，检查报文是访问自己的，并且自己也提供web服务，就会响应这个请求报文；并且发送给调度器（响应报文，源地址RIP，目标地址CIP）
（4） 调度器收到web服务器的响应报文，会根据自己内部的追踪机制，判断出用户访问的是VIP，这个时候会修改源地址为VIP地址响应客户端请求。（响应报文：源地址VIP，目标地址CIP）
LVS-DR
Diectory在实现转发时不修改请求的IP首部，而是通过直接封装MAC首部完成转发；目标MAC是Directory根据调度方法挑选出某RS的MAC地址。
架构特性：
（1） 保证前端路由器将目标地址为VIP的请求报文通过ARP地址解析后送往Directory
解决方法：
静态绑定：在前端路由器直接将VIP对应的目标MAC静态配置为Directory的MAC地址
缺点：1、如果路由是运营商提供则没有路由器管理权限，则无法配置
2、如果调度器做了高可用，当主备切换的时候，MAC地址会发生改变。
Arptables：在各RS上，通过arptables规则拒绝其响应对应的ARP广播请求
内核参数：在RS上修改内核参数，并结合地址的配置方式实现拒绝响应对VIP的ARP广播请求；
（2） RS的RIP可以使用私有地址；但也可以使用公网地址，此时可通过互联网上的主机直接对此RS发起管理操作
（3） 请求报文必须经由Directory调度，但响应报文必须不能经由Directory
（4） 各RIP必须与DIP在同一物理网络中
（5） 不支持端口映射
（6） RS可以使用大多数的OS
（7） RS的网关一定不能指向Directory
优点：负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端，大大提高了服务器并发能力。
不足：1、LVS-RS间必须在同一个VLAN。
2、RS上绑定VIP，风险大。
请求和响应图解说明：
（1）首先，客户端CIP的请求发送给LVS调度器的VIP。
（2）LVS调度器收到客户端的请求包后，将数据包的MAC地址改成LVS调度器选择的某一台RS的MAC地址，并通过交换机（数据链路层）发送给RS服务器（因为MAC地址是rs服务器，所以，rs可以接收到该数据报。）注意：此时数据包的目的及源ip地址没有发生任何改变。
（3）1、RS的数据链路层收到发送来的数据报文请求后，会从链路层往上传给IP层，此时IP层需要验证请求的目标IP地址。因为包的目标IP（即VIP）并不是像常规数据报那样为RS的本地IP，而仅仅目的MAC地址是RS的。所以，在RS上需要配置一个VIP的loopbackdevice，是因为loopback device是服务器本地使用的网络接口，对外是不可见的，不会跟LVS的ip冲突。
2、RS处理数据包完成后，将应答直接返回给客户端（源ip为VIP，目标ip为CIP）。回复数据报不在经过调度器。因此，如果对外提供LVS负载均衡服务，则RS需要连上互联网才能将应答包返回给客户端。不过，RS最好为带公网IP的服务器，这样可以不经过网关直接回应客户，如果多个RS使用了同一网关出口，网关会成为LVS架构的瓶颈，会大大降低LVS的性能。
Lvs-tun
不修改请求报文IP首部，而是通过IP隧道机制在原有的IP报文之外在封闭IP首部，经由互联网把请求报文交给选定的RS，主要实现异地容灾
架构特性：
（1） RIP，DIP，VIP都是公网地址
（2） RS的网关不能，也不可能指向DIP
（3） 请求报文由Directory分发，但响应报文直接由RS响应给client
（4） 不支持端口映射
（5） RS的OS必须得支持IP隧道
优点：实现了异地容灾，避免了一个机房故障导致网站无法访问。
缺点：RS配置复杂（IPIP模块等）
请求和响应图解说明：
（1）用户发送请求到director的VIP请求服务。注意：此VIP地址在互联网上是唯一可达地址。
（2）当用户请求到达director的时候，根据调度算法选择一台RS进行转发，但是这个时候发送的报文，目标地址不能是RIP，如果是RIP接收请求，那么就是DIP响应CIP的请求，而不是VIP这个时候就需要使用隧道（tun）了，使用隧道封装两个IP首部，转发的报文为源CIP目标VIP，但是在IP首部外还会添加一个IP首部，目标地址是RIP。
（3）当RS接收到数据报后，看到外层的IP首部，目标地址是自己，就会拆开封装，这个时候就会发现，还有一个IP首部，首部内容为CIP请求自己的VIP，这个时候由于自己有VIP地址，所以就会响应这个请求给CIP。（响应报文：源地址VIP，目标地址CIP）
Lvs-fullnat
为什么使用fullnat&传统NAT在多路由网络调度缺点
（1）客户端将请求发送给Director请求服务。
（2）Director将请求报文转发给RS，源地址是CIP，目标地址是RIP。
问题来了：响应报文不经由Director
RS收到数据报查看目标地址是自己的就会响应请求，但是源地址为CIP，这个时候由于和Director中间使用了路由器连接，所以网关不是指向Director，如果响应报文不经过Director那么响应客户端请求的就是RS的RIP，而不是VIP。客户端收到响应报文，看到是RIP响应的，但是自己压根没有请求过RIP，所以会直接丢弃数据报。
什么是fullnat
通过请求报文的源地址为DIP，目标为RIP来实现转发；对于响应报文而言，修改源地址为VIP，目标地址为CIP来实现转发；
架构特性：
(1)RIP,DIP可以使用私有地址；
(2)RIP和DIP可以不在同一个网络中，且RIP的网关未必需要指向DIP；
(3)支持端口映射；
(4)RS的OS可以使用任意类型；
(5)请求报文经由Director，响应报文经由Director；
请求和响应图解：
（1） 客户端将请求发送给Director的VIP请求服务。
（2） Vip通过调度算法，将请求发送给后端的RS，这个时候源地址该为了DIP，目标地址改为了RIP。
（3） RS接收到请求后，由于源地址是DIP，则一定会对DIP进行回应。
（4） Director收到RS的响应后，会修改数据报的源地址为VIP，目标地址为CIP进行响应。
说明：此调度方式还没有正式被Linux官方录入系统标准库，所以如果向使用此模式，需要去lvs官网下载源码，并且需要重新编译系统内核才可使用。
Lvs调度算法
查看当前系统支持的调度方法
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
[root@localhost~]
# grep -i 'IPVS SCHEDULER' -A 12 /boot/config-2.6.32-504.el6.x86_64
# IPVSscheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
|
LVS的调度算法
LVS的调度方法分为两种，一种是静态方法，一种是动态方法：
静态方法：仅根据算法本身实现调度；实现起点公平，不管服务器当前处理多少请求，分配的数量一致
动态方法：根据算法及后端RS当前的负载状况实现调度；不管以前分了多少，只看分配的结果是不是公平
静态调度算法（4种）:
(1)rr : round robin :轮叫,轮询
说明：轮询调度算法的原理是每一次把来自用户的请求轮流分配给内部中的服务器，从1开始，直到N(内部服务器个数)，然后重新开始循环。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。缺点：是不考虑每台服务器的处理能力。
(2)wrr: weight round robin :加权轮询(以权重之间的比例实现在各主机之间进行调度)
说明：由于每台服务器的配置、安装的业务应用等不同，其处理能力会不一样。所以，我们根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。
(3)sh : source hashing : 源地址hash实现会话绑定sessionaffinity
说明：简单的说就是有将同一客户端的请求发给同一个real server,源地址散列调度算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的并且没有超负荷，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同。它的算法流程与目标地址散列调度算法的基本相似，除了将请求的目标IP地址换成请求的源IP地址。
(4)dh : destination hashing : 目标地址hash
说明：将同样的请求发送给同一个server,一般用于缓存服务器，简单的说，LB集群后面又加了一层，在LB与realserver之间加了一层缓存服务器，当一个客户端请求一个页面时,LB发给cache1,当第二个客户端请求同样的页面时，LB还是发给cache1,这就是我们所说的，将同样的请求发给同一个server,来提高缓存的命中率。目标地址散列调度算法也是针对目标IP地址的负载均衡，它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
动态调度算法（6种）:
(1)lc :leash-connection 最少连接
说明：最少连接调度算法是把新的连接请求分配到当前连接数最小的服务器，最小连接调度是一种动态调度短算法，它通过服务器当前所活跃的连接数来估计服务器的负载均衡，调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1，当连接中止或超时，其连接数减一，在系统实现时，我们也引入当服务器的权值为0时，表示该服务器不可用而不被调度。此算法忽略了服务器的性能问题，有的服务器性能好，有的服务器性能差，通过加权重来区分性能，所以有了下面算法wlc。
简单算法：active*256+inactive (谁的小，挑谁)
(2)wlc :加权最少连接
加权最小连接调度算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权限，加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。由于服务器的性能不同，我们给性能相对好的服务器，加大权重，即会接收到更多的请求。
简单算法：（active*256+inactive）/weight（谁的小，挑谁）
(3)sed :最少期望延迟
说明：不考虑非活动连接，谁的权重大，我们优先选择权重大的服务器来接收请求，但会出现问题，就是权重比较大的服务器会很忙，但权重相对较小的服务器很闲，甚至会接收不到请求，所以便有了下面的算法nq。
基于wlc算法，简单算法：（active+1)*256/weight （谁的小选谁）
(4).nq :never queue 永不排队
说明：在上面我们说明了，由于某台服务器的权重较小，比较空闲，甚至接收不到请求，而权重大的服务器会很忙，所此算法是sed改进，就是说不管你的权重多大都会被分配到请求。简单说，无需队列，如果有台real server的连接数为0就直接分配过去，不需要在进行sed运算。
(5).LBLC :基于局部性的最少连接
说明：基于局部性的最少连接算法是针对请求报文的目标IP地址的负载均衡调度，主要用于Cache集群系统，因为Cache集群中客户请求报文的目标IP地址是变化的，这里假设任何后端服务器都可以处理任何请求，算法的设计目标在服务器的负载基本平衡的情况下，将相同的目标IP地址的请求调度到同一个台服务器，来提高服务器的访问局部性和主存Cache命中率，从而调整整个集群系统的处理能力。
(6).LBLCR :基于局部性的带复制功能的最少连接
说明：基于局部性的带复制功能的最少连接调度算法也是针对目标IP地址的负载均衡，该算法根据请求的目标IP地址找出该目标IP地 址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除， 以降低复制的程度。
注：LVS默认调度算法是 wlc 。