【轉】haproxy詳解

 軟件負載均衡通常經過兩種方式來實現：基於操做系統的軟負載實現和基於第三方應用的軟負載實現。LVS就是基於Linux操做系統實現的一種軟負載，HAProxy就是開源的而且基於第三應用實現的軟負載。HAProxy相比LVS的使用要簡單不少，功能方面也很豐富。當前，HAProxy支持兩種主要的代理模式:"tcp"也即4層（大多用於郵件服務器、內部協議通訊服務器等），和7層（HTTP）。在4層模式 下，HAProxy僅在客戶端和服務器之間轉發雙向流量。7層模式下，HAProxy會分析協議，而且能經過容許、拒絕、交換、增長、修改或者***請求 (request)或者回應(response)裏指定內容來控制協議，這種操做要基於特定規則。（新的1.3以後的版本引入了frontend,backend指令；frontend根據任意 HTTP請求頭內容作規則匹配,而後把請求定向到相關的backend.）
我如今用HAProxy主要在於它有如下優勢，這裏我總結下：
一、HAProxy是支持虛擬主機的，經過frontend指令來實現
二、可以補充Nginx的一些缺點好比Session的保持，Cookie的引導等工做
三、支持url檢測後端的服務器出問題的檢測會有很好的幫助。
四、它跟LVS同樣，自己僅僅就只是一款負載均衡軟件；單純從效率上來說HAProxy更會比Nginx有更出色的負載均衡速度，在併發處理上也是優於Nginx的。
五、HAProxy能夠對Mysql讀進行負載均衡，對後端的MySQL節點進行檢測和負載均衡，不過在後端的MySQL slaves數量超過10臺時性能不如LVS，因此我向你們推薦LVS+Keepalived。
六、能對請求的url和header中的信息作匹配，有比lvs有更好的7層實現
七、HAProxy的負載均衡算法如今也愈來愈多了，具體有以下8種：
①roundrobin，表示簡單的輪詢，這個很少說，這個是負載均衡基本都具有的；
②static-rr，表示根據權重，建議關注；
③leastconn，表示最少鏈接者先處理，建議關注；
④source，表示根據請求源IP，這個跟Nginx的IP_hash機制相似，咱們用其做爲解決session問題的一種方法
⑤ri，表示根據請求的URI；
⑥rl_param，表示根據請求的URl參數'balance url_param' requires an URL parameter name；
⑦hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求；
⑧rdp-cookie(name)，表示根據據cookie(name)來鎖定並哈希每一次TCP請求。

一，安裝
# wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.25.tar.gz
# tar xf haproxy-1.4.25.tar.gz 
# cd haproxy-1.4.25

# 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

啓動：
# /usr/local/haproxy/sbin/haproxy -c /usr/local/haproxy/conf/haproxy.cfg

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

配置案例：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145

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 s      #topped.]」，日誌格式很簡單。      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的部分，能夠在listen指令指定的區域中定義匹配規則和後端服務器ip，      #至關於須要在其中配置frontend，backend的功能。通常作tcp轉發比較合適，不用太多的規則      #匹配。      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的前端部分，haproxy會監聽bind的端口      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的後端部分，frontend定義的請求會到到這裏處理      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               官方配置： http://haproxy.1wt.eu/download/1.4/doc/configuration.txt

三，虛擬主機核心配置 

以下配置中忽略了global，defaults等配置，案例以下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

frontend lvs2-lvs3     bind *:8080     acl is_lvs2 hdr_end(host) -i lvs2.test.net:8080     #使用hdr_end指令取request header中的host，若是host是lvs2.test.net:8080，則匹配請求，     #而後把請求打到對應use_backend指定的後端server上     acl is_lvs3 hdr_end(host) -i lvs3.test.net:8080     use_backend lvs2 if is_lvs2     #若是規則if指定的acl匹配，則打到use_backend指定的後端server上     use_backend lvs3 if is_lvs3       backend lvs2 #定義後端server     balance roundrobin     #採用輪詢的負載均衡方法，網後端server轉發請求     server  free172 10.253.3.14:80 weight 10     server  free173 10.253.3.15:80 weight 10           backend lvs3     balance roundrobin     server  free174 10.253.3.16:80 weight 10     server  free173 10.253.3.15:80 weight 10          官方配置： http://haproxy.1wt.eu/download/1.4/doc/configuration.txt

4、健康監測
一、經過監聽端口進行健康檢測
這種檢測方式，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 

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

六，haproxy高可用方案
haproxy是自己是一個負載均衡器，能夠經過haproxy+keepalived的方案來時現實負載均衡