HAProxy代理

時間 2020-01-05

原文原文鏈接

HAProxy代理
javascript

---------------------------------------------------------------------------------------------------------------------------------------------css

1、介紹html

一、應對客戶端c10k以上同時鏈接的高性能的TCP和HTTP負載均衡器，其功能是用來提供基於cookie的持久性，基於內容的交換，過載保護的高級流浪管制，自動故障切換，以正則表達式爲基礎的控制運行時間，基於web的報表，高級日誌記錄以幫助排除故障的應用或網絡及其餘功能前端

二、LB Clusterjava

四層：lvs，nginx（stream），haproxy（mode tcp）mysql

七層：http:ngxin（http），haproxy（mode httpd），httpdnginx

三、git

官網：www.haproxy.org，www.haproxy.comgithub

文檔：https://cbonte.github.io/haproxy-dconv/web

2、功能

HAProxy是TCP/HTTP反向代理服務器，尤爲適合於高可用環境

能夠針對HTTP請求添加cookie，進行路由後端服務器

可平衡負載至後端服務器，並支持持久鏈接

支持基於cookie進行調度

支持全部主服務器故障切換至備用服務器

支持專用端口實現監控服務

支持不影響現有鏈接狀況下中止接受新鏈接請求

能夠在雙向添加，修改或刪除HTTP報文首部

支持基於pattern實現鏈接請求的訪問控制

經過特定的URI爲受權用戶提供詳細的狀態信息

支持http反向代理

支持動態程序的反向代理

支持基於數據庫的反向代理

3、haparoxy組成

一、光盤base源有安裝包，安裝好後服務名稱叫haproxy，systemctl start haproxy打開5000端口

二、程序環境：

主程序：/usr/sbin/haproxy

配置文件：/etc/haproxy/haproxy.cfg

Unit file：/usr/lib/systemd/system/haproxy.service

三、配置段：

（1）global：全局配置段

進程及安全配置相關的參數

性能調整相關參數

Debug參數

（2）proxies：代理配置段

defaults：爲frontend, backend, listen提供默認配置

frontend：前端，至關於nginx中的server {}

backend：後端，至關於nginx中的upstream {}

listen：同時擁有前端和後端,適用於一對一環境

配置文件 vim /etc/haproxy/haproxy

代理設置，一端面對客戶端，一面面對服務器端

四、配置示例

簡單的配置示例：

frontend web 發佈到外網的應用

bind *:80 請求到本機器的端口

default_backend websrvs 這個請求就會調度到後端的某個名叫websrvs的backend服務器上

backend websrvs

balance roundrobin 輪詢算法

server srv1 192.168.0.101:80 check 健康性檢查

server srv2 192.168.0.102:80 check 健康性檢查

此時已經簡單實現調度

當關閉一臺設備時，有現象

4、global配置

一、global配置參數：

進程及安全管理：chroot, deamon，user, group, uid, gid

nbproc <number> 要啓動的haproxy的進程數量，系統默認單進程，要求使用daemon模式，通常而言，幾個cpu就創建幾個進程

ulimit-n <number> 每一個haproxy進程可打開的最大文件數，系統自動會指定，不建議設置

daemon 後端方式運行，建議使用

log 定義全局的syslog服務器；最多能夠定義兩個

log <address> [len <length>] <facility> [max level [min level]]

address： rsyslog服務器地址

len：記錄日誌的長度，默認1024

二、log：

log global

log <address> [len <length>] <facility> [<level> [<minlevel>]]

length 日誌行的長度，默認1024

no log

注意：

默認發往本機的日誌服務器

(1) local2.* /var/log/local2.log

(2) $ModLoad imudp

$UDPServerRun 514

三、log-format：自定義log格式，https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#8.2.4

四、演示打開log方式

vim /etc/rsyslog.cfg

啓用514端口

並在此處

已打開進程

日誌已經生成

五、日誌管理

將特定信息記錄在日誌中

（1）capture cookie <name> len <length>

捕獲請求和響應報文中的 cookie並記錄日誌

（2）capture request header <name> len <length>

捕獲請求報文中指定的首部並記錄日誌

示例:

capture request header X-Forwarded-For len 15

（3）capture response header <name> len <length>

捕獲響應報文中指定的首部並記錄日誌

示例：

capture response header Content-length len 9

capture response header Location len 15

5、性能調整

maxconn <number>：設置每一個haproxy進程所能接受的最大併發鏈接數

maxconnrate <number>：設置每一個進程每秒種所能創建的最大鏈接數量

maxse***ate <number>：設置每一個進程每秒種所能創建的最大會話數量

maxsslconn <number>: 每進程支持SSL的最大鏈接數量

spread-checks <0..50, in percent> 健康檢測延遲時長百分比，建議2-5之間

6、配置段

一、代理配置段：

- defaults <name>

- frontend <name>

- backend <name>

- listen <name>

二、Frontend段：指定接收客戶端鏈接偵聽套接字設置

三、Backend段：指定將鏈接請求轉發至後端服務器的相關設置

四、Listen段：指定完整的先後端設置

五、proxy 名稱：使用字母數字 - _ . : 並區分字符大小寫

六、配置參數：

bind：指定一個或多個前端偵聽地址和端口，只能放在frontend和listen

bind [<address>]:<port_range> [, ...] [param*]

示例：

listen http_proxy

bind :80,:443

bind 10.0.0.1:10080,10.0.0.1:10443

bind /run/ssl-frontend.sock user root mode 600 accept-proxy ---->對本地的用戶root，用套接字提供服務，權限是600

注意：listen只能實現一對一的方式，一對多，多對多仍是用frontend和backend，但在一對一的方式中推薦仍是用frontend和backend方式，便於修改和拓展

7、調度算法

一、balance：後端服務器組內的服務器調度算法，不能放在frontend，可放在defaults、listen和 backend

balance <algorithm> [ <arguments> ]

balance url_param <param> [check_post]

二、調度算法：

（1）roundrobin：基於權重輪詢，動態算法，支持權重的運行時調整，支持慢啓動；每一個後端backend中最多支持4095個server

server options： weight #

（2）static-rr：基於權重輪詢，靜態算法，不支持權重的運行時調整及慢啓動；後端主機數量無上限

（3）leastconn：加權最少鏈接，動態算法，最少鏈接的後端服務器優先分配接收新鏈接，相同鏈接時輪詢，推薦在較長會話的場景使用，例如MySQL，LDAP等，不適合http

（4）first：根據服務器在列表中的位置，自上而下進行調度；前面服務器的鏈接數達到上限，新請求才會分配給下一臺服務，不支持權重

（5）source：源地址hash，新鏈接先按權重分配，後續鏈接按source分配請求，實現會話綁定

舉例：除權取餘法說明，對ip作哈希運算並對3進行取模，值只會出現0、一、2，當三臺設備權重同樣時，就能夠將取模值爲0的調入rs1，取模爲1時調入rs2，取模爲2時調入rs3

hash(ip1)%3 0 rs1 1

hash(ip2)%3 1 rs2 1

hash(ip3)%3 2 rs3 1

當權重不同時，對於取模的值進行權重的累加，計算後按比例分配，取模值爲0時調入rs1，取模爲一、2 時調入rs2，取模爲三、四、5時調入rs3

hash(ip1)%6 0 rs1 1

hash(ip2)%6 1,2 rs2 2

hash(ip3)%6 3,4,5 rs3 3

優勢：會話綁定，同一個ip調入同一個rs服務器

缺點：增長rs服務器後一切都須要從新計算；也有可能一個外網ip後面有不少私網ip設備，形成設備分配很粗糙

（6）uri：對URI的左半部分或整個uri作hash計算，併除以服務器總權重取模，之後派發至某挑出的服務器,適用於後端緩存服務器，通常配合varnish緩存服務器

左半部分：/<path>;<params>

整個uri：/<path>;<params>?<query>#<frag>

（7）url_param：對用戶請求的uri中的<params>部分中的參數的值做hash計算，並由服務器總權重相除之後派發至某挑出的服務器；一般用於追蹤用戶，以確保來自同一個用戶的請求始終發往同一個Backend Server

http://www.chenux.com/bbs/hello;type=title

（8）hdr(<name>)：根據主機頭調度，對於每一個http請求，此處由<name>指定的http首部將會被取出作hash計算；並由服務器總權重相除之後派發至某挑出的服務器；無有效值的會被輪詢調度

根據瀏覽器類型調度

curl -A，模仿哪一種瀏覽器進行訪問

（9）hdr(Cookie)，根據cookie調度

（10）rdp-cookie 遠程桌面相關

rdp-cookie(<name>)

8、哈希算法

一、hash-type：哈希算法

hash-type <method> <function> <modifier>

method：

map-based：除權取餘法，哈希數據結構是靜態數組，剛纔上述的舉例已說明

consistent：一致性哈希，哈希數據結構是一棵樹

function : 哈希函數，取值：sdbm，djb2，wt6

modifier：取值avalanche時，將修改哈希值，而非直接使用

二、default_backend <backend>

無use_backend 匹配時，使用默認的backend，用於frontend中

三、default-server [param*]

爲backend中的各server設定默認選項，爲後端服務器定義默認值

一致性哈希算法說明：在除權取餘法的例子中，若是3臺服務器忽然故障一臺變成2臺或者3臺服務器不夠用須要增長1臺，以前該服務器上的文件的緩存位置一定發生改變，之前緩存的圖片也失去緩存的做用和意義。若是是服務器故障，因爲大量緩存同一時間失效，形成了緩存的雪崩，此時前端緩存已經沒法起到承擔部分壓力的做用，後端服務器將會承受巨大壓力，整個系統也頗有可能崩潰。該種狀況是沒法避免，一致性哈希算法就是來解決這種問題的。

一致性哈希仍是取餘的作法，只不過是對ip進行hash後，再對2^32進行取餘，若是有3臺服務器，咱們將這3臺服務器映射到hash環上，當某個緩存服務器的緩存文件被訪問時，該文件也是通過了hash後對2^32取餘

被訪問的文件通過hash取餘運算後，從被緩存對象的位置出發，沿順時針方向遇到的第一個服務器，將會是該文件將要緩存與服務器，在服務器不變狀況下，一個文件一定會被緩存到固定的服務器上，當下次想要訪問這個文件時，再次使用相同的算法便可算出這個圖片被緩存在哪一個服務器上，圖中所示file將被緩存到B上

假如B和C之間也有個file2，file2將會緩存到C上，當B被移除，file2的緩存不變，file1緩存將會移動至C，服務器數量發生改變，並非全部緩存都失效，而是隻有部分會失效，前端仍然能分擔整個系統的壓力

因爲實際狀況不可能說三臺設備均勻分佈在環上，因此引入虛擬節點，虛擬節點越多緩存被均勻分佈的機率越大

9、配置

server <name> <address>[:[port]] [param*]

定義後端主機的各服務器及其選項

server <name> <address>[:port] [settings ...]

default-server [settings ...]

<name>：後端服務器在haproxy上的內部名稱；出如今日誌及警告信息

<address>：後端服務器地址，支持使用主機名

[:[port]]：端口映射；省略時，表示同bind中綁定的端口

[param*]：參數

weight <weight>：權重，默認爲1

maxconn <maxconn>：當先後端server的最大併發鏈接數

backlog <backlog>：當server的鏈接數達到上限後的後援隊列長度

backup：設定當前server爲備用服務器Sorry Server

示例：在haproxy中創建sorry server

一、安裝httpd或者nginx

在配置文件中更改監聽端口，80被haproxy監聽，須要更改不被監聽的端口

二、更改haproxy配置文件

三、測試

10、健康狀態監測

一、check：對當前server作健康狀態檢測，只用於四層檢測

注意：httpchk，「smtpchk」, 「mysql-check」, 「pgsql-check」 and 「ssl-hello-chk」用於定義應用層檢測方法

addr ：檢測時使用的IP地址

port ：針對此端口進行檢測

inter <delay>：檢測之間的時間間隔，默認爲2000ms

rise <count>：連續多少次檢測結果爲「成功」才標記爲可用；默認爲2

fall <count>：連續多少次檢測結果爲「失敗」才標記爲不可用；默認爲3

二、disabled：標記爲不可用，加入此項後將不往標記該臺的後端設備調度

三、redir <prefix>：將發往此server的全部GET和HEAD類的請求重定向至指定的URL，用戶發請求，發到其它服務器，後面的地址必須是外網ip地址

11、cookie配置

一、cookie <value>：爲當前server指定cookie值，實現基於cookie的會話黏性

cookie <name> [ rewrite | insert | prefix ] [ indirect ] [ nocache ] [ postonly ] [ preserve ] [ httponly ] [ secure ] [ domain <domain> ]* [ maxidle <idle> ] [ maxlife <life> ]

<name>：cookie名稱，用於實現持久鏈接

rewrite：重寫

insert：插入

prefix：前綴

nocache：當client和hapoxy之間有緩存時，不緩存cookie

二、基於cookie的session sticky的實現

backend websrvs

cookie WEBSRV insert nocache

server srv1 172.16.0.6:80 weight 2 check rise 1 fall 2 maxconn 3000 cookie srv1

server srv2 172.16.0.7:80 weight 1 check rise 1 fall 2 maxconn 3000 cookie srv2

12、統計接口啓用相關的參數

一、stats enable

啓用統計頁；基於默認的參數啓用stats page

以後訪問http://ip/haproxy?stats，即出現

二、stats hide-version 隱藏版本

三、stats refresh <delay>

設定自動刷新時間間隔

四、stats uri <prefix>

自定義stats page uri，默認值：/haproxy?stats

五、stats realm <realm>

認證時的realm，示例：stats realm : HAProxy\ Statistics

六、stats auth <user>:<passwd>

認證時的帳號和密碼，可以使用屢次，默認：no authentication

七、stats admin { if | unless } <cond>

啓用stats page中的管理功能

配置示例

listen stats

bind :9527

stats enable

stats hide-version

stats uri /hastats

stats realm HAPorxy\ Stats\ Page

stats auth admin1:password1

stats auth admin1:password2

stats refresh 3s

stats admin if TRUE

drain：排幹，將服務器上的用戶踢掉，以後逐漸下線

十3、工做模式

一、maxconn <conns>：爲指定的frontend定義其最大併發鏈接數；默認爲3000

二、mode { tcp|http|health }

定義haproxy的工做模式

tcp：基於layer4實現代理；可代理mysql, pgsql, ssh, ssl等協議,https時使用此模式，默認模式

http：僅當代理協議爲http時使用,CentOS中haproxy實際的默認模式

health：工做爲健康狀態檢查的響應模式，當鏈接請求到達時迴應「OK」後即斷開鏈接，較少使用

三、示例

listen ssh

bind :22022

balance leastconn

mode tcp

server sshsrv1 172.16.0.6:22 check

server sshsrv2 172.16.0.7:22 check

ssh IP -p 22022，便可ssh登陸

十4、健康狀態檢測，應用層檢查

對後端服務器作http協議健康狀態檢測：一般用於bendend

option httpchk 默認向後端服務器發請求：OPTIONS / HTTP/1.0

option httpchk <uri>

option httpchk <method> <uri>

option httpchk <method> <uri> <version>

定義基於http協議的7層健康狀態檢測機制

http-check expect [!] <match> <pattern>

http協議健康狀態檢測響應內容或指定響應碼

十5、forwardfor配置

一、option forwardfor [ except <network> ] [ header <name> ] [ if-none ]

在由haproxy發日後端主機的請求報文中添加「X-Forwarded-For」首部，其值爲前端客戶端的地址；用於向後端主發送真實的客戶端IP

在後端RS服務器上/etc/httpd/conf/httpd.conf中，添加X-Forwarded-For

[ except <network> ]：請求報請來自此處指定的網絡時不予添加此首部，

如haproxy自身所在網絡

[ header <name> ]：使用自定義的首部名稱，而非「X-Forwarded-For」

示例：在haproxy主機上

在RS服務器上改

[ if-none ] 若是沒有首部才添加首部，若是有使用默認值

二、爲指定的MIME類型啓用壓縮傳輸功能

compression algo <algorithm> ...：啓用http協議的壓縮機制，指明壓縮算法gzip, deflate

compression type <mime type> ...：指明壓縮的MIMI類型

十6、錯誤頁配置

一、errorfile <code> <file> 自定義錯誤頁

<code>：HTTP status code.

支持200, 400, 403, 408, 500, 502, 503, 504.

<file>：錯誤頁文件路徑

二、示例：

errorfile 400 /etc/haproxy/errorfiles/400badreq.http

errorfile 408 /dev/null # workaround Chrome pre-connect bug

errorfile 403 /etc/haproxy/errorfiles/403forbid.http

errorfile 503 /etc/haproxy/errorfiles/503sorry.http

三、errorloc <code> <url>

至關於errorloc302 <code> <url>，利用302重定向至指URL

示例：errorloc 503 http://www.chenux.com/error_pages/503.html

十7、修改報文首部

一、在請求報文尾部添加指定首部

reqadd <string> [{if | unless} <cond>]

二、在響應報文尾部添加指定首部

rspadd <string> [{if | unless} <cond>]

示例：rspadd X-Via:\ HAPorxy

三、從請求報文中刪除匹配正則表達式的首部

reqdel <search> [{if | unless} <cond>]

reqidel <search> [{if | unless} <cond>] 不分大小寫

四、從響應報文中刪除匹配正則表達式的首部

rspdel <search> [{if | unless} <cond>]

rspidel <search> [{if | unless} <cond>] 不分大小寫

示例： rspidel server.*

十8、鏈接超時

一、timeout client <timeout>

客戶端最長空閒鏈接超時時長默認單位是毫秒

二、timeout server <timeout>

後端服務器最長空閒鏈接超時時長

三、timeout http-keep-alive <timeout>

持久鏈接的持久時長

四、timeout http-request <timeout>

一次完整的HTTP請求的最大等待時長

五、timeout connect <timeout>

成功鏈接後端服務器的最大等待時長

六、timeout client-fin <timeout>

客戶端半鏈接的空閒時長

七、timeout server-fin <timeout>

後端服務器半鏈接的空閒時長

十9、ACL

一、acl：訪問控制列表（ACL）的使用提供了一個靈活的解決方案來執行內容交換，而且一般基於從請求中提取的內容、響應或任何環境狀態進行決策

二、acl <aclname> <criterion> [flags] [operator] [<value>] ...

acl acl名稱參數 [選項] 匹配 [值]

<aclname>：ACL名稱，可以使用字母數字 : . - _ ，區分字符大小寫

<criterion>：比較的標準和條件

（1）<value>的類型：

- boolean

- integer or integer range

- IP address / network

- string (exact, substring, suffix, prefix, subdir, domain)

- regular expression

- hex block

（2）<flags>

-i 不區分大小寫

-m 使用指定的pattern匹配方法

-n 不作DNS解析

-u 強制每一個ACL必須惟一ID，不然多個同名ACL或關係

-- 強制flag結束. 當字符串和某個flag類似時使用

（3）[operator]

匹配整數值：eq、ge、gt、le、lt

匹配字符串：

- exact match (-m str) :字符串必須徹底匹配模式

- substring match (-m sub) :在提取的字符串中查找模式，若是其中任何一個被發現，ACL將匹配

- prefix match (-m beg) :在提取的字符串首部中查找模式，若是其中任何一個被發現，ACL將匹配

- suffix match (-m end) :將模式與提取字符串的尾部進行比較，若是其中任何一個匹配，則ACL進行匹配

- subdir match (-m dir) :查看提取出來的用斜線分隔（「/」）的字符串，若是其中任何一個匹配，則ACL進行匹配

- domain match (-m dom) :查找提取的用點（「.」）分隔字符串，若是其中任何一個匹配，則ACL進行匹配

（4）acl做爲條件時的邏輯關係：

- 與：隱式（默認）使用

- 或：使用「or」或「||」表示

- 否認：使用「!「表示

示例：if invalid_src invalid_port 與關係

if invalid_src || invalid_port 或

if ! invalid_src 非

（5）<criterion> ：各類條件

dst 目標IP

dst_port 目標PORT

src 源IP

src_port 源PORT

示例：acl invalid_src src 172.16.100.200

演示1

演示2

結果

（6）base : string

返回第一個主機頭和請求的路徑部分的鏈接，該請求從第一個斜槓開始，並在問號以前結束,對虛擬主機有用

base : exact string match

base_beg : prefix match

base_dir : subdir match

base_dom : domain match

base_end : suffix match

base_len : length match

base_reg : regex match

base_sub : substring match

（7）path : string，官方建議最好用path，比url好用

提取請求的URL路徑，該路徑從第一個斜槓開始，並在問號以前結束（無主機部分） <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

path : exact string match

path_beg : prefix match

path_dir : subdir match

path_dom : domain match

path_end : suffix match

path_len : length match

path_reg : regex match

path_sub : substring match

示例：

path_beg /images/

path_end .jpg .jpeg .png .gif

path_reg ^/images.*\.jpeg$

path_sub image

path_dir jpegs

path_dom magedu

/images/jpegs/20180123/logo.jpg

（8）url : string

提取請求中的URL。一個典型的應用是具備預取能力的緩存，以及須要從數據庫聚合多個信息並將它們保存在緩存中的網頁門戶入口，推薦使用path

url ：exact string match

url_beg : prefix match

url_dir : subdir match

url_dom : domain match

url_end : suffix match

url_len : length match

url_reg : regex match

url_sub : substring match

（9）req.hdr([<name>[,<occ>]]) : string

提取在一個HTTP請求報文的首部

hdr([<name>[,<occ>]]) : exact string match

hdr_beg([<name>[,<occ>]]) : prefix match

hdr_dir([<name>[,<occ>]]) : subdir match

hdr_dom([<name>[,<occ>]]) : domain match

hdr_end([<name>[,<occ>]]) : suffix match

hdr_len([<name>[,<occ>]]) : length match

hdr_reg([<name>[,<occ>]]) : regex match

hdr_sub([<name>[,<occ>]]) : substring match

示例：

acl bad_agent hdr_sub(User-Agent) -i curl wegt

block if bad_agent

可引伸出：

（10）status : integer

返回在響應報文中的狀態碼

（11）預約義ACL

ACL名稱	等價於	說明
TRUE	always_true	老是匹配
FALSE	always_false	從不匹配
HTTP	req_proto_http	匹配HTTP協議
HTTP_1.0	req_ver 1.0	匹配HTTP協議1.0
HTTP_1.1	req_ver 1.1	匹配HTTP協議1.1
HTTP_CONTENT	hdr_val(content-length) gt 0	匹配已存在內容長度
HTTP_URL_ABS	url_reg ^[^/:]*://	匹配URL絕對路徑
HTTP_URL_SLASH	url_beg /	匹配URL相對路徑
HTTP_URL_STAR	url *	匹配URL等於*
LOCALHOST	src 127.0.0.1/8	匹配從localhost來的鏈接
METH_CONNECT	method CONNECT	匹配HTTP CONNECT方法
METH_GET	method GET HEAD	match HTTP GET or HEAD method
METH_HEAD	method HEAD	match HTTP GET HEAD method
METH_OPTIONS	method OPTIONS	match HTTP OPTIONS method
METH_POST	method POST	match HTTP POST method
METH_TRACE	method TRACE	match HTTP TRACE method
RDP_COOKIE	req_rdp_cookie_cnt gt 0	match presence of an RDP cookie
REQ_CONTENT	req_len gt 0	match data in the request buffer
WAIT_END	wait_end	wait for end of content analysis