调度算法

~~~sh

Haproxy调度算法概述 Haproxy根据后端服务器的负载，或其他的计算的标准，判断挑选哪台RS来进行请求处理。Haproxy调度算法语法: balance <algorithm|算法>[<arguments> ] balance url_param <param>[check_post [<max_wait>]] 负载均衡算法,可用于defaults、listen、backend 1.动态轮询调度算法 '状态表示：我们可以直接进行权重的添加，而不用重启才能生效' roundrobin:基于权重进行轮询，保持均匀分布，这是最平衡、最公平的算法。此算法是动态 每个后端服务器仅能最多接受的,这表示其权重可以在运行时进行调整，不过,在设计上,4128个连接; 1.1. roundrobin调度算法配置示例 [root@lb01 ~]# cat/etc/haproxy/haproxy.cfg frontend main bind* :80mode http use_backend webcluster backend webcluster balance roundrobin server web1172.16.1.7:80 checkserver web2 172.16.1.8:80 check 1.2. client测试 [root@client ~]# curl -HHost:Lvs.oldzhang.com http:/ /172.16.1.5:80web Page RS-Node1 [root@client ~]# curl -HHost:Lvs.oldzhang.com http://172.16.1.5:80Web Page RS-Node2 1.3. 通过socat命令动态调整权重,将web1节点的权重调整为3 #查看当前权重 [root@1b01 ~]# echo "get weight webeluster/web1" / soct stdio /varLib/haproxy/stats 1(initial 1) [root@lb01 ~]# echo "get weight webcLuster/web2" / socat stdio /varLib/haproxy/stats 1（initial 1) #调整web1权限为3,调整后测试,会发现立即生效 [root@lb01 ~]# echo "set weight webcluster/web1 3"/socat stdio /var/Lib/haproxy/stats 2.静态轮询调度算法 static-rr︰加权轮询调度算法，根据服务器的硬件情况、以及处理能力，为每台服务器分配不同的权值，使其能够接受相应权值的服务请求,此算法是静态的,这表示其权重不可以在运行时进行调整; 2.1.roundrobin调度算法配置示例 [root@1b01 ~]# cat /etc/haproxy/haproxy.cfgfrontend main bind *:80 mode http use_backend webcluster backend webcluster balance static-rr # 静态轮询 server web1 172.16.1.7;80 check weight 2 server web1 172.16.1.7;80 check weight 1 2.2. client测试 [root@ciient~]# curL-HHost: Lvs.oldzhang.com http:/172.16.1.5:80 web Page RS-Node1 [root@client ~]# curl-HHost:Lvs.oldzhang.com http:/172.16.1.5:80 web Page RS-Node1 [root@client ~]# curl -HHost:lvs.oldzhang.com http://172.16.1.5:80 web Page RS-Node2 3.最少连接数调度算法 leastconn:新的连接请求被派发至具有最少连接数目的后端服务器;此算法是动态的,可以在运行时调整其权重; 3.1 leastconn 调度算法配置示例 backend web_servers # balance static-rr balance leastconn '谁的连接数少，就调度给谁。 '但是这个算法有问题，因为连接数的这台服务，一旦配置不高的话，分配给它就会造成很多问题' '它的静态的算法，叫hash取模法。 balance leastconn hash-type map-based/consistent [hash取模/一致性的] map-based：（一台节点宕机，会影响全部） hash(ip) % node_counts = index # 使用的就是取模法，进行平均的分配，但是一旦出现了一台节点宕机，就会使得算法重新运算，如果台数高达很多，就不好了。 consistent（一台节点宕机，只影响局部） 一致性哈希，该hash是动态的，当节点下线，或新增。对调度的结果值影响局部。不会有太大波动 一致性哈希，也是采用取模方法，但不是对服务器节点数量进行取模，而是对2的32次方进行取模，这样其实是组成了一个大的圆环，hash 函数值空间为0-2^32-1 4. 会话绑定调度算法（哈希取模） source:源地址hash 调度算法，将请求的源地址进行hash 运算,得到一个具体的数值，同时对后端服务器进行编号，按照运算结果将请求分发到对应编号的服务器上。这可对不同源I的访问进行负载分发，对同一个客户端IP的请求始终被派发至某特定的服务器。 注意:如某服务器宕机或新添加了服务器,许多客户端的请求可能会被派发至与此前请求不同的服务器;不过也可以使用hash-type修改此特性; 1. source调度算法配置示例 balance source 5.基于uri路径调度算法 uri:基于对用户请求的uri做 hash并将请求转发到后端指定服务器。 理解:同一个节点访问不同的uri可能会被调度到不同的后端服务器处理，但是不同的节点访问相同的uri则会被调度到同一台服务器处理，因为基于uri调度是在服务端完成的而非客户端。这种调度算法多用在'缓存场景',能有效提高命中率。 注意，此算法仅应用于HTT后端服务器场景;其默认为静态算法,不过也可以使用hash-type修改此特性; 但是也有弊端，会出现一个节点压力很大，而一个节点的压力就很小，需要很多人都在调度一个资源。但是它haproxy是解决不了。。 '但是在lvs里有一个叫源目标算法，就可以做到。原理其实就是在第一次的时候，访问到一个节点，然后缓存一份到本地，然后又复制一份到另一个节点，那么当它的压力大的时候，就会调度到其他的节点 1.后端集群uri页面准备 #web1 [root@web01~]# mkdir /opt/iapp1, app2] -p [root@web01 ~]# echo "web1 app1" >/opt/app1/index.html [root@web01 ~]# echo "web1 app2" >/opt/app2/index.html #web2 [root@web02~]# mkdir /opt/iapp1, app2] -p [root@web02 ~]# echo "web2 app1" >/opt/app1/index.html [root@web02 ~]# echo "web2 app2" >/opt/app2/index.html 2.uri调度算法配置示例 [root@lb01 ~]# cat /etc/haproxy/haproxy.cfgfrontend main bind *:80mode http use_backend webcluster backend webcluster balance uri# hash-type{ map-based / consistent} server web1 172.16.1.7:80 check server web2 172.16.1.8;80 check `同一个url，不同的节点。调度的路径都是一样的。 `不同的URL，同一个节点，调度的路径也是不一样的。 6.url参数调度算法 url_param、对用户请求_url_中的 <params>参数中的name 作hash计算,并由服务器总权重相除以后派发至某挑出的服务器;通常用于追踪用户,以确保来自同一个用户的请求始终发往同一个 Backend Server。(使用较少) 6.1.url_params调度算法配置示例,(基于用户请求中携带的user做hash [root@lb01 ~]# cat/etc/haproxy/haproxy.cfg frontend main bind * :80 mode http use_backend webcluster backend webcluster balance url_param user #hash-type{ map-based/consistent } server web1 172.16.1.7:80 check server web2 172.16.1.8:80 check 6.2.Client测试,不带参数请求,默认为轮询调度 [root@client ~]# curl -HHost:Lvs.oldzhang.com http://10.0.0.200:80web Page RS-Node1 [root@client ~]# cu心-HHost:Lvs.oldzhang.com http://10.0.0.200:80web Page RS-Node2 6.3. client测试,携带相同的 User 参数请求，会发现始终定向到同一台后端节点 [root@client ~]# curl -HHost:Lvs.oldzhang.com http://10.0.0.200:80?user=oldzhang web user=oldzhangWeb Page RS-Node1 [root@client ~]# curL -HHost:Lvs.oldzhang.com http://10.0.0.200:80? user=oldzhang Web Page RS-Node1 200:80?user=oldzhang [root@client ~]# curL -HHost:Lvs.oldzhang.com http://10.0.0.200:80?user=oldzhang web Page RS-Node1 6.4.Client测试，携带不同的 User参数请求，发现可能会调度到不同的节点 [root@client ~]# curl -HHost:Lvs.oldzhang.com http://10.0.0.200:80?usgf-=jason web Page RS-Node2 [root@client ~]# curl -HHost;Lvs.oldzhang.com http://10.0.0.200:80?user=jack web Page RS-Node2 [root@client ~]# curl -HHost:Lvs.oldzhang.com http://10.0.0.200:80?user=lave Web Page RS-Node1 '特定的关键字，必须要能表示这个用户，这样才能做到会话的保持 7.基于header调度算法 hdr(<name>):针对用户发起HTTP请求中 Header 中的<name>关键字进行hash计算,然后 由服务器总权重相除以后派发至某挑出的服务器，假如无有效的值，则会被轮询调度;此算法默认为静的,不过其也可以使用 hash-type修改此特性;(使用较少) 1.hdr( <name>)调度算法配置示例(基于浏览器客户端来调度,同一浏览器，就只会调到同一节点) [root@1b01 ~]# cat /etc/haproxy/haproxy.cfg frontend main bind *:80 mode http use_backend webcluster backend webcluster balance hdr(User-AgentI #hash-type {map-based / consistent }server web1172.16.1.7:80 check server web2 172.16.1.7:80 check server web2 172.16.1.8:80 check

~~~