負載均衡之Haproxy配置詳解（及httpd配置）

下圖描述了使用keepalived+Haproxy主從配置來達到能夠針對前段流量進行負載均衡到多臺後端web1、web2、web3、img1、img2.但是由於haproxy會存在單點故障問題，因此使用keepalived來實現對Haproxy單點問題的高可用處理。

常用開源軟體負載均衡器有：Nginx、LVS、Haproxy。

三大主流軟體負載均衡器對比(LVS VS Nginx VS Haproxy) LVS： 1、抗負載能力強。抗負載能力強、效能高，能達到F5硬體的60%；對記憶體和cpu資源消耗比較低 2、工作在網路4層，通過vrrp協議轉發（僅作分發之用），具體的流量由linux核心處理，因此沒有流量的產生。 2、穩定性、可靠性好，自身有完美的熱備方案；（如：LVS+Keepalived） 3、應用範圍比較廣，可以對所有應用做負載均衡； 4、不支援正則處理，不能做動靜分離。 5、支援負載均衡演算法：rr（輪循）、wrr（帶權輪循）、lc（最小連線）、wlc（權重最小連線） 6、配置 複雜，對網路依賴比較大，穩定性很高。 Ngnix： 1、工作在網路的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構； 2、Nginx對網路的依賴比較小，理論上能ping通就就能進行負載功能； 3、Nginx安裝和配置比較簡單，測試起來比較方便； 4、也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的併發； 5、對後端伺服器的健康檢查，只支援通過埠來檢測，不支援通過url來檢測。 6、Nginx對請求的非同步處理可以幫助節點伺服器減輕負載； 7、Nginx僅能支援http、https和Email協議，這樣就在適用範圍較小。 8、不支援Session的直接保持，但能通過ip_hash來解決。、對Big request header的支援不是很好， 9、支援負載均衡演算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、Ip-hash（Ip雜湊） 10、Nginx還能做Web伺服器即Cache功能。 HAProxy的特點是： 1、支援兩種代理模式：TCP（四層）和HTTP（七層），支援虛擬主機； 2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作 3、支援url檢測後端的伺服器出問題的檢測會有很好的幫助。 4、更多的負載均衡策略比如：動態加權輪循(Dynamic Round Robin)，加權源地址雜湊(Weighted Source Hash)，加權URL雜湊和加權引數雜湊(Weighted Parameter Hash)已經實現 5、單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。 6、HAProxy可以對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。 9、支援負載均衡演算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie） 10、不能做Web伺服器即Cache。 三大主流軟體負載均衡器適用業務場景： 1、網站建設初期，可以選用Nigix/HAproxy作為反向代理負載均衡（或者流量不大都可以不選用負載均衡），因為其配置簡單，效能也能滿足一般的業務場景。如果考慮到負載均衡器是有單點問題，可以採用Nginx+Keepalived/HAproxy+Keepalived避免負載均衡器自身的單點問題。 2、網站併發達到一定程度之後，為了提高穩定性和轉發效率，可以使用LVS、畢竟LVS比Nginx/HAproxy要更穩定，轉發效率也更高。不過維護LVS對維護人員的要求也會更高，投入成本也更大。 注：Niginx與Haproxy比較：Niginx支援七層、使用者量最大，穩定性比較可靠。Haproxy支援四層和七層，支援更多的負載均衡演算法，支援session儲存等。具體選型看使用場景，目前來說Haproxy由於彌補了一些Niginx的缺點使用者量也不斷在提升。

衡量負載均衡器好壞的幾個重要因素： 

1、會話率 ：單位時間內的處理的請求數  

2、會話併發能力：併發處理能力  

3、資料率：處理資料能力  

經過官方測試統計，haproxy  單位時間處理的最大請求數為20000個，可以同時維護40000-50000個併發連線，最大資料處理能力為10Gbps。綜合上述，haproxy是效能優越的負載均衡、反向代理伺服器。

總結HAProxy主要優點：

一、免費開源，穩定性也是非常好，這個可通過我做的一些小專案可以看出來，單Haproxy也跑得不錯，穩定性可以與LVS相媲美；

二、根據官方文件，HAProxy可以跑滿10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom's 10GbE NICs (Myri-10G PCI-Express)，這個作為軟體級負載均衡，也是比較驚人的；

三、HAProxy可以作為MySQL、郵件或其它的非web的負載均衡，我們常用於它作為MySQL(讀)負載均衡；

四、自帶強大的監控伺服器狀態的頁面，實際環境中我們結合Nagios進行郵件或簡訊報警，這個也是我非常喜歡它的原因之一；

五、HAProxy支援虛擬主機。

下述將選擇Haproxy作為負載均衡器進行講解：

本次使用環境：

環境centos7.1

Haproxy 1.5.4

Haproxy+keeplived  172.31.2.31

Haproxy+keeplived  172.31.2.32

下述針對Haproxy的配置檔案進行詳解：

vim /etc/haproxy/haproxy.cfg

文字部分：

global                                                       # 全域性引數的設定     log         127.0.0.1 local2                      # log語法：log <address_1>[max_level_1] # 全域性的日誌配置，使用log關鍵字，                                                                      指定使用127.0.0.1                                                                      上的syslog服務中的local0日誌裝置，記錄日誌等級為info的日誌     chroot      /var/lib/haproxy                 #改變當前工作目錄     pidfile     /var/run/haproxy.pid          #當前程式id檔案     maxconn     4000                                #最大連線數     user        haproxy                                #所屬使用者     group     haproxy                                #所屬組     daemon                                               #以守護程式方式執行haproxy     stats socket /var/lib/haproxy/stats defaults     mode                    http                        #預設的模式mode { tcp|http|health }，tcp是4層，http是7層，health只會返回OK     log                        global                    #應用全域性的日誌配置     option                  httplog                  # 啟用日誌記錄HTTP請求，預設haproxy日誌記錄是不記錄HTTP請求日誌                                                                       option                  dontlognull          # 啟用該項，日誌中將不會記錄空連線。所謂空連線就是在上游的負載均衡器                                                                    或者監控系統為了探測該 服務是否存活可用時，需要定期的連線或者獲取某                                                                   一固定的元件或頁面，或者探測掃描埠是否在監聽或開放等動作被稱為空連線；                                                                   官方文件中標註，如果該服務上游沒有其他的負載均衡器的話，建議不要使用                                                                    該引數，因為網際網路上的惡意掃描或其他動作就不會被記錄下來     option http-server-close                   #每次請求完畢後主動關閉http通道     option forwardfor       except 127.0.0.0/8   #如果伺服器上的應用程式想記錄發起請求的客戶端的IP地址，需要在HAProxy                                                                             上 配置此選項， 這樣 HAProxy會把客戶端的IP資訊傳送給伺服器，在HTTP                                                                             請求中新增"X-Forwarded-For"字段。 啟用  X-Forwarded-For，在requests                                                                             頭部插入客戶端IP傳送給後端的server，使後端server獲取到客戶端的真實IP。      option                  redispatch                      # 當使用了cookie時，haproxy將會將其請求的後端伺服器的serverID插入到                                                                             cookie中，以保證會話的SESSION永續性；而此時，如果後端的伺服器宕掉                                                                             了， 但是客戶端的cookie是不會重新整理的，如果設定此引數，將會將客戶的請                                                                             求強制定向到另外一個後端server上，以保證服務的正常。     retries                 3                             # 定義連線後端伺服器的失敗重連次數，連線失敗次數超過此值後將會將對應後端                                                                   伺服器標記為不可用     timeout http-request    10s             #http請求超時時間     timeout queue           1m                 #一個請求在佇列裡的超時時間     timeout connect         10s                #連線超時     timeout client          1m                   #客戶端超時     timeout server          1m                   #伺服器端超時     timeout http-keep-alive 10s           #設定http-keep-alive的超時時間     timeout check           10s                 #檢測超時     maxconn                 3000                 #每個程式可用的最大連線數 frontend  main *:80                             #監聽地址為80     acl url_static       path_beg       -i /static /images /javascript /stylesheets     acl url_static       path_end       -i .jpg .gif .png .css .js     use_backend static          if url_static     default_backend             my_webserver     #定義一個名為my_app前端部分。此處將對於的請求轉發給後端 backend static                                                 #使用了靜態動態分離（如果url_path匹配 .jpg .gif .png .css .js靜態檔案則                                                                             訪問此後端）     balance     roundrobin                               #負載均衡演算法（#banlance roundrobin 輪詢，balance source 儲存session值，                                                                            支援static-rr，leastconn，first，uri等引數）     server      static 127.0.0.1:80 check             #靜態檔案部署在本機（也可以部署在其他機器或者squid快取伺服器） backend my_webserver                                  #定義一個名為my_webserver後端部分。PS：此處my_webserver只是一個                                                                             自定義名字而已，但是需要與frontend裡面配置項default_backend 值相一致     balance     roundrobin                               #負載均衡演算法     server  web01 172.31.2.33:80  check inter 2000 fall 3 weight 30              #定義的多個後端     server  web02 172.31.2.34:80  check inter 2000 fall 3 weight 30              #定義的多個後端     server  web03 172.31.2.35:80  check inter 2000 fall 3 weight 30              #定義的多個後端

更多關於Haproxyacl配置請參考博文：http://blog.csdn.net/tantexian/article/details/50015975

配置完成則重啟服務：

假若想訪問監控介面：配置stats uri  /haproxy項，重啟服務：

systemctl reload haproxy

注意：假若頁面範圍不了，是否selinux關閉了，iptables開啟此埠了（iptables -F）

同理在172.31.2.32上面安裝上述步驟安裝配置好haproxy：

上述對Haproxy的優缺點及配置進行了詳細講解。

接下來對Haproxy+web負載均衡使用進行實戰講解：

首先配置三臺web伺服器：172.31.2.33、172.31.2.34、172.31.2.35

三臺都是同樣操作：

1、實驗環境

centos 7.1 X64 mini版 

2、配置web伺服器(node33/34/35)：

測試方便，關閉selinux、關閉iptables

一下都採用預設，不做配置即可。

yum install httpd -y

# vim /etc/httpd/conf/httpd.conf 

httpd監聽埠：

DocumentRoot：網頁存放的路徑，文件的根目錄

重啟httpd

# systemctl restart httpd

頁面訪問httpd：

修改顯示內容：

# vim /var/www/html/index.html

I'm node33!!! My IP is 172.31.2.33...

再次訪問：

這樣三個web服務33/34/35搭建成功！！！！

接下來配置負載均衡（本次實驗只用一個Haproxy：172.31.2.31）：

瀏覽器請求172.31.2.31：

從上述結果可知，前端對172.31.2.31的請求，被Haproxy的負載均衡器，均衡請求到三個後端web172.31.2.33、172.31.2.34、172.31.2.35上面去了。

這樣當三個當中的一個出現故障，流量則能正常分發到剩餘兩個正常的web上，從來提高了系統可靠性。

跟多關於keepalived+Haproxy請參考文章：http://blog.csdn.net/tantexian/article/details/50056229