HAProxy的調度算法

時間  2020-04-26
標籤 haproxy 調度 算法 欄目 負載均衡 简体版
原文   原文鏈接

HAProxy的調度算法

HAProxy調度算法分爲靜態調度算法和動態調度算法。
靜態算法是按照事先定義好的調度規則輪詢公平調度，不關心後端服務器的當前負載、鏈接數和響應速度等，而且沒法實時修改權重，只能重啓後生效。
靜態調度算法有：static-rr，first
動態算法是根據後端服務器狀態進行調度適當調整，好比優先調度至當前負載較低的服務器，而且權重能夠在haproxy運行時調整，無需重啓服務
動態調度算法有：roundrobin，leastconn，source，uri，url_param，hdr，rdp-cookie
定義方法：php

balance <調度算法>

靜態調度算法

static-rr

靜態輪詢，基於權重輪詢調度，不支持HAProxy在運行時進行權重調整和後端服務器的慢啓動，後端的主機數量沒有限制html

listen web_http
        mode http
        balance static-rr       #設定靜態輪詢
        bind 192.168.27.21:80
        server web1 192.168.27.31:80 weight 2  check  inter 3s fall 3 rise 5
        server web2 192.168.27.32:80 weight 1  check  inter 3s fall 3 rise 5

測試：linux

[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 2

first

HAProxy會根據服務器在列表中的位置，自上而下進行調度，只有當第一臺服務器的鏈接數達到上限時，新的請求才會被分配到下一臺服務器，此設置會忽略服務器的權重
示例：web

listen web_http
        mode http
        balance first
        bind 192.168.27.21:80
        server web1 192.168.27.31:80 maxconn 10  check  inter 3s fall 3 rise 5          #配置鏈接上線位爲10，不設置權重
        server web2 192.168.27.32:80 weight 2  check  inter 3s fall 3 rise 5

測試：算法

[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 1

全部的請求依舊會發往server1，server2的權重設置無效，只有當server1的鏈接數佔滿時纔將請求發送給server2windows

動態調度算法

roundrobin

基於權重的輪詢動態調度算法，支持權重的運行時調整，支持慢啓動，每一個後端backend中最多支持4095個server，此爲默認調度算法。
示例：
1.修改配置文件後端

stats socket /var/lib/haproxy/haproxy.sock mode 600 level admin    #將socket文件開啓，在進行動態調節權重時，是經過socket進行的
listen web_http
        mode http
        balance roundrobin      #調度算法設置爲roundrobin
        bind 192.168.27.21:80
        server web1 192.168.27.31:80 weight 1  check  inter 3s fall 3 rise 5
        server web2 192.168.27.32:80 weight 1  check  inter 3s fall 3 rise 5

2.建立socket文件的目錄緩存

[root@localhost ~]# mkdir /var/lib/haproxy

3.重啓服務器，查看socket文件是否啓用bash

[root@localhost ~]# ls /var/lib/haproxy/
haproxy.sock                #已經存在

測試：
動態調節服務器狀態時須要使用到socat命令，先安裝此命令服務器

[root@localhost ~]# yum install socat -y

socat的簡單使用，能夠經過echo+指令而後使用管道傳送給socket文件

[root@localhost ~]# echo "help" | socat stdio /var/lib/haproxy/haproxy.sock
#此命令能夠用來查看socat一些簡單的使用幫助

1.獲取服務器權重

[root@localhost ~]# echo "get weight web_http/web1" | socat stdio /var/lib/haproxy/haproxy.sock      #獲取權重時，指定後端服務器組和服務器名稱
1 (initial 1)       權重爲1

2.動態修改權重，而後再次查看

[root@localhost ~]# echo "set weight web_http/web1 2" | socat stdio /var/lib/haproxy/haproxy.sock       #使用set來修改權重，

[root@localhost ~]# echo "get weight web_http/web1" | socat stdio /var/lib/haproxy/haproxy.sock 
2 (initial 1)

測試訪問

[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 2
#權重已經被調整，須要注意動態設置的方法臨時有效，重啓服務將失效

將服務器動態下線

[root@localhost ~]# echo "disable server web_http/web1" | socat stdio /var/lib/haproxy/haproxy.sock

測試訪問

[root@localhost ~]# curl 192.168.27.21
server 2
[root@localhost ~]# curl 192.168.27.21
server 2
#server1被下線，訪問只能被調度到server2

將服務器動態上線

[root@localhost ~]# echo "enable server web_http/web1" | socat stdio /var/lib/haproxy/haproxy.sock

測試訪問

[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 2
#server1又能正常訪問，而且以前設置的權重依舊有效

source

source調度算法是基於用戶的源地址hash並將請求轉發到後端服務器，默認爲靜態即取模方式(能夠經過hash-type支持的選項進行更改)，後續同一個地址發來的請求將都被轉發爲後端的同一個web服務器，比較適合用於session保持/緩存業務等場景
示例：

listen web_http
        mode http
        balance source
        bind 192.168.27.21:80
        server web1 192.168.27.31:80  check  inter 3s fall 3 rise 5
        server web2 192.168.27.32:80  check  inter 3s fall 3 rise 5

測試

[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 1
[root@localhost ~]# curl 192.168.27.21
server 1
#當第一次訪問被調度到後天的server1後以後的全部請求都被調度到server1

調度算法爲源地址哈希是是沒法進行權重的修改的，默認爲靜態

[root@localhost ~]# echo "set weight web_http/web1 2" | socat stdio /var/lib/haproxy/haproxy.sock 
Backend is using a static LB algorithm and only accepts weights '0%' and '100%'.
#沒法進行對權重進行設置，只能開啓或關閉

source 一致性hash算法

源地址哈希因爲是靜態的，若是後端的服務器發生改變，取模後的值也將發生改變，以致於整張表上的記錄做廢，從而從新進行計算。
一致性哈希是動態的，支持在線的權重調整，當服務器的總權重發生變化時，影響的只是一部分，不會引發大的變更
示例：

listen web_http
        mode http
        balance source
        hash-type consistent        #使用hash-type指定一致性哈希
        bind 192.168.27.21:80
        server web1 192.168.27.31:80  check  inter 3s fall 3 rise 5
        server web2 192.168.27.32:80  check  inter 3s fall 3 rise 5

uri

uri哈希算法，能夠經過用戶訪問的uri來進行調度，經常使用於緩存服務器。當用戶第一訪問某uri是，haproxy會從後臺選出一臺服務進行調度並記錄，當再其餘用戶也訪問此uri時，haproxy會固定的將其調度到後臺上次所請求此uri的那臺服務器上。
示例：
將配置文件改成基於uri哈希的算法

listen web_http
        mode http
        balance uri         #設置爲uri算法
        bind 192.168.27.21:80
        server web1 192.168.27.31:80 weight 1 check  inter 3s fall 3 rise 5
        server web2 192.168.27.32:80 weight 3 check  inter 3s fall 3 rise 5

測試
分別使用不一樣的客戶端對相同的資源進行訪問
使用client1進行訪問

[root@client1 ~]# curl 192.168.27.21/index.html
server 1

使用client2進行訪問

[root@client2 ~]# curl 192.168.27.21/index.html
server 1

使用client3進行訪問

[root@client3 ~]# curl 192.168.27.21/index.html
server 1

結論：不一樣用戶訪問同一個資源將會調度到後臺的統一個服務器上

url_param

url_param的調度算法是對用戶請求的url中{params}部分中的參數的值作哈希計算，並由服務器總權重相除後派發至選中的後端服務器；經常使用於追蹤用戶確保同一個用戶的請求永遠發向同一臺後端服務器。
假設url爲http://www.mylinuxops.com/index.php?name=wang
其中url_param爲？以後的內容即name=wang，而其中name爲參數，wang爲值
示例：

listen web_http
        mode http
        balance url_param name      #設定調度算法爲 url_param，參數爲name
        bind 192.168.27.21:80
        server web1 192.168.27.31:80 weight 2 check  inter 3s fall 3 rise 5
        server web2 192.168.27.32:80 weight 1 check  inter 3s fall 3 rise 5

測試
當用戶所帶的參數的值相同時則請求後臺相同的服務器

[root@localhost ~]# curl 192.168.27.21/index.html?name=123
server 2
[root@localhost ~]# curl 192.168.27.21/index.html?name=123
server 2

當用戶使用未設定的參數時，將輪詢

[root@localhost ~]# curl 192.168.27.21/index.html?aaa=123
server 1
[root@localhost ~]# curl 192.168.27.21/index.html?aaa=123
server 1
[root@localhost ~]# curl 192.168.27.21/index.html?aaa=123
server 2

hdr(NAME)

hdr調度算法是針對用戶每一個http請求頭部中指定的信息作hash，而後由服務器的總權重相除取模後派發至後端的服務器，若是沒有有效的值則將進行輪詢調度。hdr可使用的name有(cookie、User-agent、host)
示例：

listen web_http
        mode http                       #此算法是針對http的因此模式須要使用http
        balance hdr(user-agent)         #使用hdr算法，以用戶的客戶端做調度
        bind 192.168.27.21:80
        server web1 192.168.27.31:80 weight 2 check  inter 3s fall 3 rise 5
        server web2 192.168.27.32:80 weight 1 check  inter 3s fall 3 rise 5

示例：
使用curl訪問時

[root@localhost ~]# curl 192.168.27.21
server 2
[root@localhost ~]# curl 192.168.27.21
server 2
[root@localhost ~]# curl 192.168.27.21
server 2
[root@localhost ~]# curl 192.168.27.21
server 2

使用curl模擬其餘客戶端訪問

[root@localhost ~]# curl -A "12" 192.168.27.21
server 1
[root@localhost ~]# curl -A "12" 192.168.27.21
server 1
[root@localhost ~]# curl -A "12" 192.168.27.21

rdp-cookie

rdp-cookie調度算法是針對遠程桌面的負載，使用cookie保持會話，用在遠程爲windows的狀況下。
示例：

listen RDP
        bind 192.168.27.21:3389
        balance rdp-cookie      #修改調度算法爲rdp-cookie
        mod tcp                 #因爲後端爲windows因此此處必須爲tcp
        server rdp1 192.168.27.40:3389 check  inter 3s fall 3 rise 5
        server rdp1 192.168.27.40:3389 check  inter 3s fall 3 rise 5
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程