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

下圖描述了使用keepalived+Haproxy主從配置來達到可以針對前段流量進行負載均衡到多臺後端web一、web二、web三、img一、img2.

可是因爲haproxy會存在單點故障問題，所以使用keepalived來實現對Haproxy單點問題的高可用處理。

 

三大主流軟件負載均衡器對比(LVS VS Nginx VS Haproxy)

LVS： 一、抗負載能力強。抗負載能力強、性能高，能達到F5硬件的60%；對內存和cpu資源消耗比較低 二、工做在網絡4層，經過vrrp協議轉發（僅做分發之用），具體的流量由linux內核處理，所以沒有流量的產生。 二、穩定性、可靠性好，自身有完美的熱備方案；（如：LVS+Keepalived） 三、應用範圍比較廣，能夠對全部應用作負載均衡； 四、不支持正則處理，不能作動靜分離。 五、支持負載均衡算法：rr（輪循）、wrr（帶權輪循）、lc（最小鏈接）、wlc（權重最小鏈接） 六、配置 複雜，對網絡依賴比較大，穩定性很高。

Ngnix： 一、工做在網絡的7層之上，能夠針對http應用作一些分流的策略，好比針對域名、目錄結構； 二、Nginx對網絡的依賴比較小，理論上能ping通就就能進行負載功能； 三、Nginx安裝和配置比較簡單，測試起來比較方便； 四、也能夠承擔高的負載壓力且穩定，通常能支撐超過1萬次的併發； 五、對後端服務器的健康檢查，只支持經過端口來檢測，不支持經過url來檢測。 六、Nginx對請求的異步處理能夠幫助節點服務器減輕負載； 七、Nginx僅能支持http、https和Email協議，這樣就在適用範圍較小。 八、不支持Session的直接保持，但能經過ip_hash來解決。、對Big request header的支持不是很好， 九、支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、Ip-hash（Ip哈希） 十、Nginx還能作Web服務器即Cache功能。

 

HAProxy的特色是： 一、支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機； 二、可以補充Nginx的一些缺點好比Session的保持，Cookie的引導等工做 三、支持url檢測後端的服務器出問題的檢測會有很好的幫助。 四、更多的負載均衡策略好比：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現 五、單純從效率上來說HAProxy更會比Nginx有更出色的負載均衡速度。 六、HAProxy能夠對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。 九、支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie） 十、不能作Web服務器即Cache。

 

  三大主流軟件負載均衡器適用業務場景：

 

一、網站建設初期，能夠選用Nigix/HAproxy做爲反向代理負載均衡（或者流量不大均可以不選用負載均衡），由於其配置簡單，性能也能知足通常的業務場景。若是考慮到負載均衡器是有單點問題，能夠採用Nginx+Keepalived/HAproxy+Keepalived避免負載均衡器自身的單點問題。 二、網站併發達到必定程度以後，爲了提升穩定性和轉發效率，可使用LVS、畢竟LVS比Nginx/HAproxy要更穩定，轉發效率也更高。不過維護LVS對維護人員的要求也會更高，投入成本也更大。 注：Niginx與Haproxy比較：Niginx支持七層、用戶量最大，穩定性比較可靠。Haproxy支持四層和七層，支持更多的負載均衡算法，支持session保存等。具體選型看使用場景，目前來講Haproxy因爲彌補了一些Niginx的缺點用戶量也不斷在提高。

 

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

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

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

三、數據率：處理數據能力  

通過官方測試統計，haproxy  單位時間處理的最大請求數爲20000個，能夠同時維護40000-50000個併發鏈接，最大數據處理能力爲10Gbps。綜合上述，haproxy是性能優越的負載均衡、反向代理服務器。

 

總結HAProxy主要優勢：

1、免費開源，穩定性也是很是好，這個可經過我作的一些小項目能夠看出來，單Haproxy也跑得不錯，穩定性能夠與LVS相媲美；

2、根據官方文檔，HAProxy能夠跑滿10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom's 10GbE NICs (Myri-10G PCI-Express)，這個做爲軟件級負載均衡，也是比較驚人的；

3、HAProxy能夠做爲MySQL、郵件或其它的非web的負載均衡，咱們經常使用於它做爲MySQL(讀)負載均衡；

4、自帶強大的監控服務器狀態的頁面，實際環境中咱們結合Nagios進行郵件或短信報警，這個也是我很是喜歡它的緣由之一；

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

 

配置完成則重啓服務：

systemctl restart haproxy

 

倘若想訪問監控界面：配置stats uri  /haproxy項，重啓服務：

 

systemctl reload haproxy

注意：倘若頁面範圍不了，是否selinux關閉了，iptables開啓此端口了（iptables -F）

 

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

 

 

 

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

 

 

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

首先配置三臺web服務器：172.31.2.3三、172.31.2.3四、172.31.2.35

三臺都是一樣操做：

一、實驗環境

centos 7.1 X64 mini版 

 

二、配置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）：

vim /etc/haproxy/haproxy.cfg

 

瀏覽器請求172.31.2.31：

 

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

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

 

 

keepalived+Haproxy參考：http://blog.csdn.net/tantexian/article/details/50056229