負載均衡集羣解決方案（三）haproxy

時間 2020-08-29

原文原文鏈接

1、haproxy簡介php

HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications. It is particularly suited for web sites crawling under very high loads while needing persistence or Layer7 processing. Supporting tens of thousands of connections is clearly realistic with todays hardware. Its mode of operation makes its integration into existing architectures very easy and riskless, while still offering the possibility not to expose fragile web servers to the Net。
摘自：http://haproxy.1wt.eucss

2、haproxy集羣工做流程html

3、haproxy安裝前端

# tar -xzvf haproxy-1.3.20.tar.gz
# make TARGET=linux26 PREFIX=/usr/local/haproxy install
注：TARGET後面根據本機操做系統內核版原本填寫
建立配置文件目錄，日誌目錄，並根據需求編寫配置文件
# mkdir /usr/local/haproxy/{conf,logs}
# vim /usr/local/haproxy/conf/haproxy.cfg
配置haproxy的日誌環境
# vim /etc/syslog.conf
添加：
local0.* /usr/local/logs/haproxy.log
local3.* /usr/local/logs/haproxy_err.log
#vim /etc/sysconfig/syslog
修改：
SYSLOGD_OPTIONS="-r -m 0"
service syslog restart
注： -r enables logging from remote machineslinux

4、haproxy配置詳解nginx

HAProxy配置中分五大部分：
global：全局配置參數，進程級的，用來控制Haproxy啓動前的一些進程及系統設置
defaults：配置一些默認的參數，能夠被frontend，backend，listen段繼承使用
frontend：用來匹配接收客戶所請求的域名，uri等，並針對不一樣的匹配，作不一樣的請求處理
backend：定義後端服務器集羣，以及對後端服務器的一些權重、隊列、鏈接數等選項的設置，我將其理解爲Nginx中的upstream塊
listen：我將其理解爲frontend和backend的組合體web

配置一例：redis

global # 全局參數的設置
     log 127.0.0.1 local0 info
# log語法：log [max_level_1]
     # 全局的日誌配置，使用log關鍵字，指定使用127.0.0.1上的syslog服務中的local0日誌設備，記錄日誌等級爲info的日誌
     user haproxy
     group haproxy
# 設置運行haproxy的用戶和組，也可以使用uid，gid關鍵字替代之
     daemon
# 以守護進程的方式運行
     nbproc 16
# 設置haproxy啓動時的進程數，根據官方文檔的解釋，我將其理解爲：該值的設置應該和服務器的CPU核心數一致，即常見的2顆8核心CPU的服務器，即共有16核心，則能夠將其值設置爲：<=16 ，建立多個進程數，能夠減小每一個進程的任務隊列，可是過多的進程數也可能會致使進程的崩潰。這裏我設置爲16
     maxconn 4096
# 定義每一個haproxy進程的最大鏈接數，因爲每一個鏈接包括一個客戶端和一個服務器端，因此單個進程的TCP會話最大數目將是該值的兩倍。
     #ulimit -n 65536
# 設置最大打開的文件描述符數，在1.4的官方文檔中提示，該值會自動計算，因此不建議進行設置
     pidfile /var/run/haproxy.pid
# 定義haproxy的pid
defaults # 默認部分的定義
     mode http
# mode語法：mode {http|tcp|health} 。http是七層模式，tcp是四層模式，health是健康檢測，返回OK
     log 127.0.0.1 local3 err
# 使用127.0.0.1上的syslog服務的local3設備記錄錯誤信息
     retries 3
# 定義鏈接後端服務器的失敗重連次數，鏈接失敗次數超過此值後將會將對應後端服務器標記爲不可用
     option httplog
# 啓用日誌記錄HTTP請求，默認haproxy日誌記錄是不記錄HTTP請求的，只記錄「時間[Jan 5 13:23:46] 日誌服務器[127.0.0.1] 實例名已經pid[haproxy[25218]] 信息[Proxy http_80_in stopped.]」，日誌格式很簡單。
     option redispatch
# 當使用了cookie時，haproxy將會將其請求的後端服務器的serverID插入到cookie中，以保證會話的SESSION持久性；而此時，若是後端的服務器宕掉了，可是客戶端的cookie是不會刷新的，若是設置此參數，將會將客戶的請求強制定向到另一個後端server上，以保證服務的正常。
     option abortonclose
# 當服務器負載很高的時候，自動結束掉當前隊列處理比較久的連接
     option dontlognull
# 啓用該項，日誌中將不會記錄空鏈接。所謂空鏈接就是在上游的負載均衡器或者監控系統爲了探測該服務是否存活可用時，須要按期的鏈接或者獲取某一固定的組件或頁面，或者探測掃描端口是否在監聽或開放等動做被稱爲空鏈接；官方文檔中標註，若是該服務上游沒有其餘的負載均衡器的話，建議不要使用該參數，由於互聯網上的惡意掃描或其餘動做就不會被記錄下來
     option httpclose
# 這個參數我是這樣理解的：使用該參數，每處理完一個request時，haproxy都會去檢查http頭中的Connection的值，若是該值不是close，haproxy將會將其刪除，若是該值爲空將會添加爲：Connection: close。使每一個客戶端和服務器端在完成一次傳輸後都會主動關閉TCP鏈接。與該參數相似的另一個參數是「option forceclose」，該參數的做用是強制關閉對外的服務通道，由於有的服務器端收到Connection: close時，也不會自動關閉TCP鏈接，若是客戶端也不關閉，鏈接就會一直處於打開，直到超時。
     contimeout 5000
# 設置成功鏈接到一臺服務器的最長等待時間，默認單位是毫秒，新版本的haproxy使用timeout connect替代，該參數向後兼容
     clitimeout 3000
# 設置鏈接客戶端發送數據時的成功鏈接最長等待時間，默認單位是毫秒，新版本haproxy使用timeout client替代。該參數向後兼容
     srvtimeout 3000
# 設置服務器端迴應客戶度數據發送的最長等待時間，默認單位是毫秒，新版本haproxy使用timeout server替代。該參數向後兼容
listen status # 定義一個名爲status的部分
     bind 0.0.0.0:1080
# 定義監聽的套接字
     mode http
# 定義爲HTTP模式
     log global
# 繼承global中log的定義
     stats refresh 30s
# stats是haproxy的一個統計頁面的套接字，該參數設置統計頁面的刷新間隔爲30s
     stats uri /admin?stats
# 設置統計頁面的uri爲/admin?stats
     stats realm Private lands
# 設置統計頁面認證時的提示內容
     stats auth admin:password
# 設置統計頁面認證的用戶和密碼，若是要設置多個，另起一行寫入便可
     stats hide-version
# 隱藏統計頁面上的haproxy版本信息
frontend http_80_in # 定義一個名爲http_80_in的前端部分
     bind 0.0.0.0:80
# http_80_in定義前端部分監聽的套接字
     mode http
# 定義爲HTTP模式
     log global
# 繼承global中log的定義
     option forwardfor
# 啓用X-Forwarded-For，在requests頭部插入客戶端IP發送給後端的server，使後端server獲取到客戶端的真實IP
     acl static_down nbsrv(static_server) lt 1
# 定義一個名叫static_down的acl，當backend static_sever中存活機器數小於1時會被匹配到
     acl php_web url_reg /*.php$
     #acl php_web path_end .php
# 定義一個名叫php_web的acl，當請求的url末尾是以.php結尾的，將會被匹配到，上面兩種寫法任選其一
     acl static_web url_reg /*.(css|jpg|png|jpeg|js|gif)$
     #acl static_web path_end .gif .png .jpg .css .js .jpeg
# 定義一個名叫static_web的acl，當請求的url末尾是以.css、.jpg、.png、.jpeg、.js、.gif結尾的，將會被匹配到，上面兩種寫法任選其一
     use_backend php_server if static_down
# 若是知足策略static_down時，就將請求交予backend php_server
     use_backend php_server if php_web
# 若是知足策略php_web時，就將請求交予backend php_server
     use_backend static_server if static_web
# 若是知足策略static_web時，就將請求交予backend static_server
backend php_server #定義一個名爲php_server的後端部分
     mode http
# 設置爲http模式
     balance source
# 設置haproxy的調度算法爲源地址hash
     cookie SERVERID
# 容許向cookie插入SERVERID，每臺服務器的SERVERID可在下面使用cookie關鍵字定義
     option httpchk GET /test/index.php
# 開啓對後端服務器的健康檢測，經過GET /test/index.php來判斷後端服務器的健康狀況
     server php_server_1 10.12.25.68:80 cookie 1 check inter 2000 rise 3 fall 3 weight 2
     server php_server_2 10.12.25.72:80 cookie 2 check inter 2000 rise 3 fall 3 weight 1
     server php_server_bak 10.12.25.79:80 cookie 3 check inter 1500 rise 3 fall 3 backup
# server語法：server [:port] [param*]
     # 使用server關鍵字來設置後端服務器；爲後端服務器所設置的內部名稱[php_server_1]，該名稱將會呈如今日誌或警報中、後端服務器的IP地址，支持端口映射[10.12.25.68:80]、指定該服務器的SERVERID爲1[cookie 1]、接受健康監測[check]、監測的間隔時長，單位毫秒[inter 2000]、監測正常多少次後被認爲後端服務器是可用的[rise 3]、監測失敗多少次後被認爲後端服務器是不可用的[fall 3]、分發的權重[weight 2]、最爲備份用的後端服務器，當正常的服務器所有都宕機後，纔會啓用備份服務器[backup]
backend static_server
     mode http
     option httpchk GET /test/index.html
     server static_server_1 10.12.25.83:80 cookie 3 check inter 2000 rise 3 fall 3算法

5、健康監測vim

一、經過監聽端口進行健康檢測
這種檢測方式，haproxy只會去檢查後端server的端口，並不能保證服務的真正可用。

  
  
  
  
   
   
   
   listen http_proxy 0.0.0.0:80 
   
   
   
           mode http 
   
   
   
           cookie SERVERID 
   
   
   
           balance roundrobin 
   
   
   
           option httpchk 
   
   
   
           server web1 192.168.1.1:80 cookie server01 check 
   
   
   
           server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2

二、經過URI獲取進行健康檢測
這種檢測方式，是用過去GET後端server的的web頁面，基本上能夠表明後端服務的可用性。

  
  
  
  
   
   
   
   listen http_proxy 0.0.0.0:80 
   
   
   
           mode http 
   
   
   
           cookie SERVERID 
   
   
   
           balance roundrobin 
   
   
   
           option httpchk GET /index.html 
   
   
   
           server web1 192.168.1.1:80 cookie server01 check 
   
   
   
           server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2

三、經過request獲取的頭部信息進行匹配進行健康檢測
這種檢測方式，則是基於高級，精細的一些監測需求。經過對後端服務訪問的頭部信息進行匹配檢測。

  
  
  
  
   
   
   
   listen http_proxy 0.0.0.0:80 
   
   
   
           mode http 
   
   
   
           cookie SERVERID 
   
   
   
           balance roundrobin 
   
   
   
           option httpchk HEAD /index.jsp HTTP/1.1\r\nHost:\ www.xxx.com 
   
   
   
           server web1 192.168.1.1:80 cookie server01 check 
   
   
   
           server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2

6、haproxy實現持久鏈接

1 調度算法source
haroxy 將用戶IP通過hash計算後指定到固定的真實服務器上（相似於nginx 的IP hash 指令）
配置指令 balance source

2 cookie 識別
haproxy 將WEB服務端發送給客戶端的cookie中插入(或添加加前綴)haproxy定義的後端的服務器COOKIE ID。
配置指令例舉 cookie SESSION_COOKIE insert indirect nocache

3 session 識別
haproxy 將後端服務器產生的session和後端服務器標識存在haproxy中的一張表裏。客戶端請求時先查詢這張表。而後根據session分配後端server。
配置指令：appsession <cookie> len <length> timeout <holdtime>

7、統計頁面效果圖

參考文獻：
http://haproxy.1wt.eu/download/1.4/doc/configuration.txt

本文出自「My---Dream.*」博客，請務必保留此出處http://grass51.blog.51cto.com/4356355/1109825