一:负载平衡简介
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服务器)增长过多时,负载平衡器将成为整个系统的瓶颈,因为全部的请求包和应答包的流向都经过负载平衡器。当服务器节点过多时,大量的数据包都交汇在负载平衡器那,速度就会变慢!
- 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP,目标IP为VIP
- PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
- IPVS比对数据包请求的服务是否为集群服务,如果,修改数据包的目标IP地点为后端服务器IP, 然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP
- POSTROUTING链通过选路,将数据包发送给Real Server
- Real Server比对发现目标为自己的IP,开始构建响应报文发回给Director Server。 此时报文的源IP为RIP,目标IP为CIP
- 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必须在同一机房中)
- 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP
- PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
- IPVS比对数据包请求的服务是否为集群服务,如果,将请求报文中的源MAC地点修改为DIP的MAC地点,将目标MAC地点修改RIP的MAC地点,然后将数据包发至POSTROUTING链。 此时的源IP和目标IP均未修改,仅修改了源MAC地点为DIP的MAC地点,目标MAC地点为RIP的MAC地点
- 由于DS和RS在同一个网络中,以是是通过二层来传输。POSTROUTING链检查目标MAC地点为RIP的MAC地点,那么此时数据包将会发至Real Server。
- RS发现请求报文的MAC地点是自己的MAC地点,就吸取此报文。处置处罚完成之后,将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地点为VIP,目标IP为CIP
- 响应报文最终送达至客户端
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
类目NATTUNDR操作系统恣意支持隧道多数(支持non-arp)服务器网络私有网络局域网/广域网局域网服务器数目10-20100大于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
复制代码 特别留意:
- 不要在dr上访问vip,可能访问不乐成
- 新版本lvs的长期连接默认生效且修改太短时间不生效。也就是只要是同一个客户端ip,在一定时间内,他总会被分配到同一个后端服务器。
dr模式标题详解
- 客户端要找vip访问80端口,因为是在同一个网段,以是发arp广播(255.255.255.255)找vip的mac地点通讯
- 因为有rs上也有vip,不能直接让rs上的vip回应客户端的广播,以是设置文件arp_ignore的内容为1,1的意思是如果发来的广播包内里目标地点不是我的"入口地点"–>也就是"eth0"(对应的是非入口地点当地回环接口lo),那我就不回应这个arp广播。
因为在同一个局域网内的同一个网段,解决IP地点辩论:
- # echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
复制代码 - 当dr的vip收到这个广播之后,回应mac地点,然后得到客户端发来的80端口请求,再通过lvs分发到一个rs
- 那么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
- 这个rs必须要使用他lo设置的vip把回应包发出去(这样client收到之后一看源地点是vip,他就会相信这是正确的地点发来的包
- 那么怎样让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
复制代码 - 最后怎么算是最好的当地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算法。这个必须举例来说了
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不能实时判定,就可能导致用户访问失败,那么如何通过脚本的方式举行康健检测呢?
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |