Day 42 LVS四层负载均衡

一：负载均衡简介

1.集群是什么

​ 集群（cluster）技术是一种较新的技术，通过集群技术，可以在付出较低成本的情况下获得在性能、可靠性、灵活性方面的相对较高的收益，其任务调度则是集群系统中的核心技术

​ 集群组成后，可以利用多个计算机和组合进行海量请求处理（负载均衡），从而获得很高的处理效率，也可以用多个计算机做备份（高可用），使得任何一个机器坏了整个系统还是能正常运行

2.负载均衡集群技术

​ 负载均衡（Load Balance）：负载均衡集群为企业需求提供了可解决容量问题的有效方案。负载均衡集群使负载可以在计算机集群中尽可能平均地分摊处理

​ 负载通常包括应用程序处理负载和网络流量负载,每个节点都可以承担一定的处理负载，并且可以实现处理负载在节点之间的动态分配，以实现负载均衡

3.负载均衡技术类型

​ 四层负载均衡技术

​ 七层负载均衡技术

4.负载均衡实现方式

​ 硬件负载均衡：F5、深信服 、Radware

​ 软件负载均衡：LVS、Nginx、Haproxy

​ 云负载均衡

5.负载均衡分类

四层：

​ F5（BIGIP）：硬件负载均衡器，功能很好，但是成本很高

​ lvs：重量级的四层负载软件

​ nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活

​ haproxy：模拟四层转发，较灵活

七层：

​ haproxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移

​ nginx：只在http协议和mail协议上功能比较好，性能与haproxy差不多

6.四七层的区别

	四层负载均衡	七层负载均衡
基于	基于IP+Port的	基于虚拟的URL或主机IP等
类似于	路由器	代理服务器
复杂度	低	高
性能	高；无需解析内容	中；需要算法识别 URL，Cookie 和 HTTP head 等信息
安全性	低	高
额外功能	无	会话保持，图片压缩，等

总结：

​ 从上面的对比看来四层负载与七层负载最大的区别就是效率与功能的区别。四层负载架构设计比较简单，无需解析具体的消息内容，在网络吞吐量及处理能力上会相对比较高，而七层负载均衡的优势则体现在功能多，控制灵活强大。在具体业务架构设计时，使用七层负载或者四层负载还得根据具体的情况综合考虑

二：LVS简介

1.LVS 介绍

​ LVS 是Linux Virtual Server的简称，也就是 Linux 虚拟服务器, 是一个由章文嵩博士发起的自由软件项目，它的官方站点是www.linuxvirtualserver.org。现在LVS已经是 Linux标准内核的一部分，因此性能较高。

​ LVS软件作用：通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能、高可用的服务器群集，它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。

2.LVS 优势与不足

优势：

​ 高并发连接：LVS基于内核网络层面工作，有超强的承载能力和并发处理能力。单台LVS负载均衡器，可支持上万并发连接

​ 稳定性强：是工作在网络4层之上仅作分发之用，决定了它在负载均衡软件里的性能最强，稳定性最好，对内存和cpu资源消耗极低

​ 成本低廉：硬件负载均衡器少则十几万，多则几十万上百万，LVS只需一台服务器和就能免费部署使用，性价比极高

​ 配置简单：LVS配置非常简单，仅需几行命令即可完成配置，也可写成脚本进行管理

​ 支持多种算法：支持多种论调算法，可根据业务场景灵活调配进行使用

​ 支持多种工作模型：可根据业务场景，使用不同的工作模式来解决生产环境请求处理问题

不足：

​ 工作在4层，不支持7层规则修改，机制过于庞大，不适合小规模应用

3.LVS核心组件

​ LVS的管理工具和内核模块 ipvsadm/ipvs

​ ipvsadm：用户空间的命令行工具，用于管理集群服务及集群服务上的RS等

​ ipvs：工作于内核上的程序，可根据用户定义的集群实现请求转发

4.专业术语

VS：Virtual Server              #虚拟服务
DR：Director, Balancer          #负载均衡器、分发器
RS：Real Server                 #后端请求处理服务器 
CIP: Client IP                  #用户端IP
VIP：Director Virtual IP        #负载均衡器虚拟IP
DIP：Director IP                #负载均衡器IP
RIP：Real Server IP             #后端请求处理服务器IP

三：负载均衡工作原理

1.四种模式

​ LVS/NAT：网络地址转换模式，进站/出站的数据流量经过分发器(IP负载均衡，他修改的是IP地址)

​ LVS/DR ：直接路由模式，只有进站的数据流量经过分发器(数据链路层负载均衡，修改的是目的mac地址)利用二层功能mac地址

​ LVS/TUN： 隧道模式，只有进站的数据流量经过分发器

​ LVS/full-nat:双向转换:通过请求报文的源地址为DIP，目标为RIP来实现转发：响应报文，修改源地址为VIP，目标地址为CIP实现转发

2.四种原理

NAT模式：

原理：

就是把客户端发来的数据包的IP头的目的地址，在负载均衡器上换成其中一台RS的IP地址，并发至此RS来处理,RS处理完成后把数据交给经过负载均衡器,负载均衡器再把数据包的原IP地址改为自己的IP，将目的地址改为客户端IP地址即可｡期间,无论是进来的流量,还是出去的流量,都必须经过负载均衡器｡

注意：

• 后端服务器支持数量10-20台

• RS应该使用私有地址，RS的网关必须指向DIP

• DIP和RIP必须在同一个网段内

​优点：

集群中的物理服务器可以使用任何支持TCP/IP操作系统，只有负载均衡器需要一个合法的IP地址。

​缺点：

扩展性有限。当服务器节点（普通PC服务器）增长过多时,负载均衡器将成为整个系统的瓶颈 ，因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇在负载均衡器那，速度就会变慢！

1. 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP，目标IP为VIP

2. PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链

3. IPVS比对数据包请求的服务是否为集群服务，若是，修改数据包的目标IP地址为后端服务器IP， 然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP，目标IP为RIP

4. POSTROUTING链通过选路，将数据包发送给Real Server

5. Real Server比对发现目标为自己的IP，开始构建响应报文发回给Director Server。 此时报文的源IP为RIP，目标IP为CIP

6. Director Server在响应客户端前，此时会将源IP地址修改为自己的VIP地址，然后响应给客户端。 此时报文的源IP为VIP，目标IP为CIP

直接路由(Direct routing)模式：

原理：

负载均衡器和RS都使用同一个IP对外服务｡但只有DR对ARP请求进行响应,所有RS对本身这个IP的ARP请求保持静默｡也就是说,网关会把对这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC（因为IP一致）并将请求分发给这台RS｡这时RS收到这个数据包,处理完成之后，由于IP一致，可以直接将数据返给客户，则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端｡

注意：

• 后端服务器支持数量100+台

• 保证前端路由将目标地址为VIP报文统统发给Director Server，而不是RS

• RS可以使用私有地址；也可以是公网地址，如果使用公网地址，此时可以通过互联网对RIP进行直接访问

• RS跟Director Server必须在同一个物理网络中

• 所有的请求报文经由Director Server，但响应报文必须不能进过Director Server

• 不支持地址转换，也不支持端口映射

• RS可以是大多数常见的操作系统

• RS的网关绝不允许指向DIP(因为我们不允许他经过director)

• RS上的lo接口配置VIP的IP地址

优点：

和TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与VS-TUN相比，VS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器。

缺点：

要求负载均衡器的网卡必须与物理网卡在一个物理段上（RS和DS必须在同一机房中 ）

1. 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP

2. PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链

3. IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址

4. 由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。

5. RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP，目标IP为CIP

6. 响应报文最终送达至客户端

IP隧道(Tunnel)模式：

原理：

互联网上的大多Internet服务的请求包很短小，而应答包通常很大。那么隧道模式就是，把客户端发来的数据包，封装一个新的IP头标记(仅目的IP)发给RS,RS收到后,先把数据包的头解开,还原数据包,处理后,直接返回给客户端,不需要再经过负载均衡器｡注意,由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持IPTUNNEL协议｡所以,在RS的内核中,必须编译支持IPTUNNEL这个选项

注意：

• 后端服务器支持数量100台左右

• 异地负载均衡 realserver必须使用公网Ip，还得需要服务器支持ip隧道协议

优点：

负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。

缺点：

隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持"IP Tunneling"(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上。

FULL-NAT模式：

​原理：

客户端对VIP发起请求，Director接过请求发现是请求后端服务。Direcrot对请求报文做full-nat，把源ip改为Dip，把目标ip转换为任意后端RS的rip，然后发往后端，rs接到请求后，进行响应，相应源ip为Rip目标ip还是DIP，由内部路由路由到Director,Director接到响应报文，进行full-nat。将源地址为VIP，目标地址改为CIP；请求使用DNAT，响应使用SNAT

3.四者区别

​ lvs-nat与lvs-fullnat：请求和响应报文都经由Director

lvs-nat：RIP的网关要指向DIP

lvs-fullnat：RIP和DIP未必在同一IP网络，但要能通信

​ lvs-dr与lvs-tun：请求报文要经由Director，但响应报文由RS直接发往Client

lvs-dr：通过封装新的MAC首部实现，通过MAC网络转发

lvs-tun：通过在原IP报文外封装新IP头实现转发，支持远距离通信

三种负载均衡： nat，tunneling，dr

类目	NAT	TUN	DR
操作系统	任意	支持隧道	多数（支持non-arp）
服务器网络	私有网络	局域网/广域网	局域网
服务器数目	10-20	100	大于100
服务器网关	负载均衡器	自己的路由	自己的路由
效率	一般	高	最高

四：LVS集群部署

dr模式实验

环境：3台机器

10.0.0.20  
10.0.0.30  dr1     负载均衡器
配置两个IP，一个VIP，一个DIP

10.0.0.21  rs1     web1

10.0.0.22  rs2     web2

1、两个rs上部署web服务，并在dr1上查看VIP和DIP

两台rs的操作

# yum install nginx  -y
注意把两台服务器的主页内容修改为不同的内容
# systemctl start nginx

在dr1上使用 route -n 命令查看路由表，确定谁是VIP
第一个网卡是DIP，第二个网卡是VIP

此实验

DIP：10.0.0.20

VIP：10.0.0.30

2、给两个web服务器的lo网卡设置子网掩码为32位vip (在这之前先确定一下谁是VIP)

rs1:
    # ifconfig lo:0 10.0.0.30/32  
    或者
    # ip a a  10.0.0.30/32 dev lo:0
rs2:
    # ifconfig lo:0 10.0.0.30/32 

3、为了让vip发包出去且忽略arp响应 ，给两个web服务器设置内核参数

# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

4、保证dr这台机器数据包是从dip发出去的

如何判断：谁的路由条目在上面，谁就是dip，另一个就是vip

5、在dr上设置lvs路由条目(临时生效)

# yum install ipvsadm  -y
# ipvsadm -A -t 10.0.0.30:80 -s rr
# ipvsadm -a -t 10.0.0.30:80 -r 10.0.0.21:80 -g
# ipvsadm -a -t 10.0.0.30:80 -r 10.0.0.22:80 -g

-A 添加virtual server
-t  指定使用tcp协议
-s 指定调度策略为rr 轮询 round robin
-a 添加realserver
-r 指定realserver是谁


# ipvsadm -C
清除策略

让配置永久生效

# ipvsadm-save > /etc/sysconfig/ipvsadm
# systemctl enable ipvsadm

特别注意：

1. 不要在dr上访问vip,可能访问不成功

2. 新版本lvs的持久连接默认生效且修改太短时间不生效。也就是只要是同一个客户端ip，在一定时间内，他总会被分配到同一个后端服务器。

dr模式问题详解

1. 客户端要找vip访问80端口，因为是在同一个网段，所以发arp广播(255.255.255.255)找vip的mac地址通信

2. 因为有rs上也有vip，不能直接让rs上的vip回应客户端的广播，所以设置文件arp_ignore的内容为1，1的意思是如果发来的广播包里面目标地址不是我的"进口地址"-->也就是"eth0"(对应的是非进口地址本地回环接口lo)，那我就不回应这个arp广播。

   因为在同一个局域网内的同一个网段，解决IP地址冲突：

   # echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

3. 当dr的vip收到这个广播之后，回应mac地址，然后得到客户端发来的80端口请求，再通过lvs分发到一个rs

4. 那么dr如何分发到一个rs？

   dip发出arp广播询问rs的ip地址所对应的mac地址，然后发出一个目标ip为rs_vip，目标mac为rs_eth0_mac的包到rs

   过程中lvs会修改数据包mac地址 :

   dr的dip发数据包给realserver，数据头里面需要目标IP为vip，MAC地址为rip所在网卡的MAC

   我们必须保证dr是从dip发包给rip：

   查看dr机器的路由条目，哪块网卡的路由在上面，哪块网卡的IP地址就当DIP

5. 这个rs必须要使用他lo设置的vip把回应包发出去(这样client收到之后一看源地址是vip，他就会相信这是正确的地址发来的包

6. 那么怎样让rs使用lo的vip而不使用eth0?

   设置arp_announce文件的内容为2, 2的意思是使用本机最好的本地IP地址把回应包发出去

   dr模式里需要realserver直接返回数据给客户端，但是客户端默认情况下不接收realserver返回的数据，因为client发出的数据包是给vip的，所以在realserver上也设置vip，想办法让vip返回数据给客户端

   #echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce   

7. 最后怎么算是最好的本地IP地址？

   同一个网段下，使用可变长度子网掩码最长的IP地址被认为是好IP，因为他更精确

五：ipvsadm

1、LVS-server安装lvs管理软件

yum -y install ipvsadm

程序包：ipvsadm（LVS管理工具）

主程序：/usr/sbin/ipvsadm

规则保存工具：/usr/sbin/ipvsadm --save > /etc/sysconfig/ipvsadm

配置文件：/etc/sysconfig/ipvsadm-config

2、命令选项

* -A --add-service 在内核的虚拟服务器表中添加一条新的虚拟服务器记录。也就是增加一台新的虚拟服务器。
-E --edit-service 编辑内核虚拟服务器表中的一条虚拟服务器记录。
-D --delete-service 删除内核虚拟服务器表中的一条虚拟服务器记录。
* -C --clear 清除内核虚拟服务器表中的所有记录。
-R --restore 恢复虚拟服务器规则
* -S --save 保存虚拟服务器规则，输出为-R 选项可读的格式
* -a --add-server 在内核虚拟服务器表的一条记录里添加一条新的真实服务器记录。也就是在一个虚拟服务器中增加一台新的真实服务器
-e --edit-server 编辑一条虚拟服务器记录中的某条真实服务器记录
-d --delete-server 删除一条虚拟服务器记录中的某条真实服务器记录
* -L|-l --list 显示内核虚拟服务器表
* -Z --zero 虚拟服务表计数器清零（清空当前的连接数量等）
--set tcp tcpfin udp 设置连接超时值
--start-daemon 启动同步守护进程。他后面可以是master 或backup，用来说明LVS Router 是master 或是backup。在这个功能上也可以采用keepalived 的VRRP 功能。
--stop-daemon 停止同步守护进程
* -h --help 显示帮助信息
* -p --persistent [timeout] 持久稳固的服务(持久性连接)。这个选项的意思是来自同一个客户的多次请求，将被同一台真实的服务器处理。timeout 的默认值为300 秒。
* -t --tcp-service service-address 说明虚拟服务器提供的是tcp 的服务[vip:port] or [real-server-ip:port]
-f --fwmark-service fwmark 说明是经过iptables 标记过的服务类型。
-u --udp-service service-address 说明虚拟服务器提供的是udp 的服务[vip:port] or [real-server-ip:port]

* -s --scheduler scheduler 使用的调度算法，有这样几个选项 rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq,默认的调度算法是： wlc.

-M --netmask netmask persistent granularity mask
* -r --real-server server-address 真实的服务器[Real-Server:port]
* -g --gatewaying 指定LVS 的工作模式为直接路由模式（也是LVS 默认的模式）
-i --ipip 指定LVS 的工作模式为隧道模式
-m --masquerading 指定LVS 的工作模式为NAT 模式
* -w --weight weight 真实服务器的权值
--mcast-interface interface 指定组播的同步接口
* -c --connection 显示LVS 目前的连接 如：ipvsadm -L -c
--timeout 显示tcp tcpfin udp 的timeout 值 如：ipvsadm -L --timeout
--daemotcpdump -i ens33 tcp and port 80 -v -nnn 显示同步守护进程状态
* --stats 显示统计信息
--rate 显示速率信息
--sort 对虚拟服务器和真实服务器排序输出
* -n --numeric  输出IP地址和端口的数字形式

六：LVS算法

1.静态算法

只根据算法进行调度 而不考虑后端服务器的实际连接情况和负载情况

RR：轮叫调度

Round Robin

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

ipvsadm -A -t 192.168.122.10:80 -s  rr
ipvsadm -a -t 192.168.122.10 -r 192.168.122.100 -g

WRR：加权轮叫

Weight RR

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

ipvsadm -A -t 192.168.122.10:80 -s wrr
ipvsadm -a -t 192.168.122.10 -r 192.168.122.100 -g -w 2

2.动态算法

前端的调度器会根据后端真实服务器的实际连接情况来分配请求

LC：最少链接

Least Connections

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

ipvsadm -A -t 192.168.122.10:80 -s lc

WLC：加权最少连接

Weighted Least Connections，默认采用的就是这种

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

ipvsadm -A -t 192.168.122.10:80 -s wlc

基于局部性的最少链接

Locality-Based Least Connections(LBLC)

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

带复制的基于局部性最少链接

Locality-Based Least Connections with Replication(LBLCR)

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

最短期望的延迟

Shortest Expected Delay Scheduling(SED)

基于wlc算法。这个必须举例来说了

 A  B  C
 1  2  3
 1  2  3

​ ABC三台机器分别权重123 ，连接数也分别是123。那么如果使用WLC算法的话一个新请求进入时它可能会分给 ABC中的任意一个。使用sed算法后会进行这样一个运算

​ A(1+1)/1

​ B(1+2)/2

​ C(1+3)/3

​ 根据运算结果，把连接交给C。

​ 注:前面的1是给所有连接数加1，后面的除数是权重

​ 我本来负载就小，所以才连接数少，假如我这点负载再添加一个连接，我可能就挂了，但是你负载高的再添加1 个连接，挂的可能小就比较小

NQ：永不排队/最少队列调度

Never Queue Scheduling （NQ）

​ 无需队列。如果有台 realserver的连接数＝0就直接分配过去，不需要再进行sed运算，保证不会有一个主机很空闲。

ipvsadm -A -t 192.168.122.10:80 -s  nq

目标地址散列

Destination Hashing (DH) 特点是查找速度快

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

目标地址散列调度（Destination Hashing Scheduling）算法

是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。

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

目标地址散列调度算法流程

假设有一组服务器S = {S0, S1, ..., Sn-1}，W(Si)表示服务器Si的权值，

C(Si)表示服务器Si的当前连接数。ServerNode[]是一个有256个桶（Bucket）的

Hash表，一般来说服务器的数目会小于256，当然表的大小也是可以调整的。

算法的初始化是将所有服务器顺序、循环地放置到ServerNode表中。若服务器的

连接数目大于2倍的权值，则表示服务器已超载。

n = ServerNode[hashkey(dest_ip)];

if ((n is dead) OR

(W(n) == 0) OR

(C(n) > 2*W(n))) then

return NULL;

return n;

在实现时，我们采用素数乘法Hash函数，通过乘以素数使得散列键值尽可能地达到较均匀的分布。所采用的素数乘法Hash函数如下：

素数乘法Hash函数

static inline unsigned hashkey(unsigned int dest_ip)

{

return (dest_ip* 2654435761UL) & HASH_TAB_MASK;

}

其中，2654435761UL是2到2^32 (4294967296)间接近于黄金分割的素数，

(sqrt(5) - 1) / 2 = 0.618033989

2654435761 / 4294967296 = 0.618033987

源地址散列

Source Hashing(SH)

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

源地址散列调度（Source Hashing Scheduling）算法

正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法 的相同。它的算法流程与目标地址散列调度算法的基本相似，除了将请求的目标IP地址换成请求的源IP地址，所以这里不一一叙述。

在实际应用中，源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中，它们可以保证整个系统的唯一出入口。

====================================
散列表（Hash table，也叫哈希表），是根据关键码值(Key value)而直接进行访问的数据结构。也就是说，它通过把关键码值映射到表中一个位置来访问记录，以加快查找的速度。这个映射函数叫做散列函数，存放记录的数组叫做散列表。给定表M，存在函数f(key)，对任意给定的关键字值key，代入函数后若能得到包含该关键字的记录在表中的地址，则称表M为哈希(Hash）表，函数f(key)为哈希(Hash) 函数。

七：思考题

​ lvs默认情况下没有健康检测，当有real-server服务挂掉后，lvs不能及时判断，就可能导致用户访问失败，那么如何通过脚本的方式进行健康检测呢？