HAProxy簡介
HAProxy是免費、極速且可靠的用于為TCP和基于HTTP應用程序提供高可用、負載均衡和代理服務的解決方案，尤其適用于高負載且需要持久連接或7層處理機制的web站點。HAProxy還可以將后端的服務器與網絡隔離，起到保護后端服務器的作用。HAProxy的負載均衡能力雖不如LVS，但也是相當不錯，而且由于其工作在7層，可以對http請求報文做深入分析，按照自己的需要將報文轉發至后端不同的服務器（例如動靜分離），這一點工作在4層的LVS無法完成。
HAProxy目前主要有版本： 1.3 ， 1.4 ，1.5，1.6，1.7
CentOS6.6 自帶的RPM包為 1.5 的
安裝配置HAproxy
HAProxy已經集成在base源中，可直接通過yum下載。
可以去官網直接下載源碼編譯安裝。
配置文件HAproxy
/etc/haproxy/haproxy.cfg為haproxy的主配置文件，里面包括全局配置段（global
settings）和代理配置段（proxies）。
haproxy 的配置文件由兩部分組成：全局設定（global
settings）和對代理的設定（proxies），共分為五段：global，defaults，frontend，backend，listen。
global settings：主要用于定義haproxy進程管理安全及性能相關的參數
proxies：代理相關的配置可以有如下幾個配置端組成。
– defaults <name>：為其它配置段提供默認參數，默認配置參數可由下一個“defaults”重新設定。
– frontend <name>：定義一系列監聽的套接字，這些套接字可接受客戶端請求并與之建立連接。
– backend <name>：定義“后端”服務器，前端代理服務器將會把客戶端的請求調度至這些服務器。
– listen
<name>：定義監聽的套接字和后端的服務器。類似于將frontend和backend段放在一起
HAproxy的工作模式：
HAProxy的工作模式一般有兩種：tcp模式和http模式。
tcp模式：實例運行于TCP模式，在客戶端和服務器端之間將建立一個全雙工的連接，且不會對7層報文做任何類型的檢查，只能以簡單模式工作。此為默認模式，通常用于SSL、SSH、SMTP等應用。
http模式：實例運行于HTTP模式，客戶端請求在轉發至后端服務器之前將被深度分析，所有不與RFC格式兼容的請求都會被拒絕。
當實現內容交換時，前端和后端必須工作于同一種模式(一般都是HTTP模式)，否則將無法啟動實例。工作模式可通過mo
mode參數在default，frontend，listen，backend中實現定義。
下面介紹一些HAproxy的常見用法。
應用實例
基于HAProxy實現負載均衡
在backend段或listen段中通過server定義后端節點。
格式：server <name> <address>[:port] [param*]
<name>：為此服務器指定的內部名稱
[param*]：為此服務器設定的一系參數。其可用的參數很多，以下為常用參數。
服務器參數：
backup：設定為備用服務器，僅在負載均衡場景中的其它server均不可用于啟用此server；
maxconn <maxconn>：指定此服務器接受的最大并發連接數；如果發往此服務器的連接數目高于此處指定的值，其將被放置于請求隊列，以等待其它連接被釋放；
maxqueue <maxqueue>：設定請求隊列的最大長度；
observe <mode>：通過觀察服務器的通信狀況來判定其健康狀態，默認為禁用，其支持的類型有“layer4”和“layer7”，“layer7”僅能用于http代理場景；
redir <prefix>：啟用重定向功能，將發往此服務器的GET和HEAD請求均以302狀態碼響應；
weight <weight>：服務器權重，默認為1，最大值為256，0表示不參與負載均衡；
定義負載均衡的算法，算法的定義除了listen段和backend段中也可以放在defaults段中，定義格式如下：
balance <algorithm> [ <arguments> ] balance url_param <param> [check_post [<max_wait>]]
常見的調度算法有：
roundrobin：基于權重進行輪詢，此算法是動態的，其權重可以在運行時進行調整。
static-rr：基于權重進行輪詢，與roundrobin類似，但是為靜態方法，在運行時調整其服務器權重不會生效。
leastconn：新的連接請求被派發至具有最少連接數目的后端服務器，動態算法，適用于較長時間會話的場景。
source：將請求的源地址進行hash運算，并與后端服務器的總權重作取模運算后調度至某臺服務器；同一IP地址的請求將始終被調度至某特定的服務器，靜態算法，可以使用hash-type修改此特性；
uri：對URI的左半部分(“？”之前的部分)或整個URI進行hash運算，并與后端服務器的總權重作取模運算后調度至某臺服務器；同一URI的請求將始終被調度至某特定的服務器，靜態算法，可以使用hash-type修改此特性；
hdr(<name>)：根據用戶請求報文中指定的http首部的值進行調度，常用于實現將對同一個虛擬主機的請求始終發往同個backend
server。
前端代理服務器上配置示例（其余為默認配置）：
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend service *:80
default_backend app
#---------------------------------------------------------------------
# static backend for serving up images, stylesheets and such
#---------------------------------------------------------------------
backend app
balance roundrobin
server app1 192.168.2.7:80 maxconn 3000 weight 2
server app2 192.168.2.18:80 maxconn 3000 weight 1
server app3 127.0.0.1:8080 backup
在app1（192.168.2.7）上配置測試頁面：
[root@node1 ~]# vim /web/index.html <h1>server node1</h1>
在app1（192.168.2.18）上：
[root@node2 ~]# vim /web/index.html <h1>server node2</h1>
在代理服務器上有兩個接口：192.168.1.116（面向客戶端），192.168.2.11。配置完成后啟動haproxy服務。后端節點上啟動nginx服務
已實現輪詢訪問。
在上述的算法中涉及到hash運算，hash-type參數可定義hash的運算方式。格式如下：
格式：hash-type <map-based|consistent>
map-based：靜態方法，在線調整服務器權重不能立即生效。hash表是一個包含了所有在線服務器的靜態數組。簡而言之，通過這種運算方式將請求調度至后端的某臺服務器，當后端的服務器放生變動時（如某臺服務器宕機或新添加了一臺服務器），大部分的連接將會被重新調度至一個與之前不同的服務器上。
consistent：動態發放，支持在線調整服務器權重。hash表是一個由各服務器填充而成的樹狀結構，使用此算法調度，當后端的服務器發生變動時，大分布的連接將依舊被調度至原本的服務器上。
默認方式為map-based，可應用于大部分場景。但是若后端的服務器為緩存服務器，使用默認方式，當后端的服務器調整時，將導致緩存無法命中，從而影響系統的性能。推薦的配置方式：
backend <name>
balance uri
hash-type consistent
server ....
server ...
對后端服務器健康狀況的檢測
check為server的參數，可啟動對此server執行健康狀態的檢測。check借助其額外的參數可實現更精細的監測機制。
inter <delay>：健康狀態檢測的時間間隔，單位為毫秒，默認為2000，可以使用fastinter和downinter來根據服務器端狀態優化此時間延遲；
rise <count>：健康狀態檢測中，某離線的server從離線狀態轉換至正常狀態需要成功檢查的次數；
fall <count>：確認server從正常狀態轉換為不可用狀態需要檢查的次數；
配置示例：
backend app
balance roundrobin
server app1 192.168.2.7:80 maxconn 3000 weight 2 check inter 1 rise 1 fall 2
server app2 192.168.2.18:80 maxconn 3000 weight 1 check inter 1 rise 1 fall 2
server app3 127.0.0.1:8080 backup
state頁面
啟用統計報告，通過state頁面可查看到各服務器的狀態及其相關信息。關于state的配置建議單獨定義一個listen。
listen stats
mode http
bind 192.168.1.116:1080 #監聽端口
stats enable #啟用state功能
stats scope app #統計報告的報告區段，不啟動這項則報告所有區段
stats hide-version #隱藏HAProxy版本號
stats uri /haproxyadmin?stats #state頁面的訪問路徑
stats realm Haproxy\ Statistics #認證時提示信息
stats auth baby:baby #認證的賬號密碼
stats admin if TRUE #啟用管理功能
配置完成后重啟haproxy服務。然后訪問定義的路徑：http://192.168.1.116:1080/haproxyadmin?stats。首先完成認證。
基于前面配置完成的健康狀態檢測，現在停止其中一臺后端服務器的nginx服務。
[root@node1 web]# service nginx stop
Stopping nginx: [ OK ]
紅色表示服務不在線，若停止所有后端服務器的服務，則會訪問定義為backup的server（127.0.0.1上的sorry頁面）。
基于cookie的session綁定
在響應報文中添加cookie信息，下一次的客戶請求會帶上這個cookie信息，服務器端根據cookie將請求始終定向至后端的某一臺服務器。可用于保持session會話。
cookie配置格式：
cookie <name> [ rewrite | insert | prefix ] [ indirect ] [ nocache ][ postonly ] [ preserve ] [ httponly ] [ secure ][ domain <domain> ]* [ maxidle <idle> ] [ maxlife <life> ]
配置示例：
backend app
balance roundrobin
cookie babyserver insert nocache indirect
server app1 192.168.2.17:80 check port 80 cookie app1
server app2 192.168.2.16:80 check port 80 cookie app2
重啟服務，客戶端進行訪問。
客戶端查看響應報文：
Set-Cookie首部已經添加信息，接下來該客戶端的訪問（只要cookie信息還在）將始終被定向至app2。
option forwardfor
客戶端的請求經前端的代理服務器轉發至后端的web服務器，代理服務器在轉發時將目標地址改為后端的某臺web服務器地址，將源地址由client
ip（客戶端地址）改為自己面向后端服務器的地址。后端的web服務器若使用默認格式記錄日志，則記錄的客戶端IP地址都為前端的代理服務器地址。這時需要在發往后端的請求報文中添加內容為客戶端IP地址的首部，以便后端的web服務器能夠正確獲取客戶端地址。
使用option forwardfor 在發往服務器的請求首部中插入“X-Forwarded-For”首部。
格式：option forwardfor [ except <network> ] [ header
<name> ] [ if-none ]
<network>：源地址被該參數匹配到時，禁用此功能；
<name>：可自定義首部名稱代替“X-Forwarded-For”；
if-none：僅在此首部不存在時才允許添加至請求報文中。
backend app
.......
option forwardfor header X-Client
在后端的web服務器上修改日志格式。
這里后端的web服務器為nginx，若為httpd，%{headname}i獲取指定首部信息。重新加載配置文件后，即可獲取客戶端IP。需要注意的是，HAProxy工作于隧道模式，其僅檢查每一個連接的第一個請求，因此，僅第一個請求報文被附加此首部。如果想為每一個請求都附加此首部，需要確保同時使用了“option
httpclose”,“option forceclose”和“option http-server-close”幾個option。
原創文章，作者：一如既往天天蕩漾，如若轉載，請注明出處：http://www.www58058.com/76060
