負載均衡集羣解決方案(三)haproxy

一、haproxy簡介

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.eu

二、haproxy集羣工作流程

三、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 machines

四、haproxy配置詳解

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

配置一例:

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

五、健康監測

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

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

2、通過URI獲取進行健康檢測
這種檢測方式,是用過去GET後端server的的web頁面,基本上可以代表後端服務的可用性。

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

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

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

六、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>

七、統計頁面效果圖

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

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章