haproxy反向代理功能配置

使用場景

假如要實現這樣的環境：haproxy反向代理4個nginx節點，nginx1和nginx2結合php提供動態web服務，nginx3和nginx4提供靜態web服務。如下圖：

由于默認配置文件中和超時時間相關的設置比較不合理，所以建議修改這些時間。另外還有些建議開啟或關閉的的項也盡量開啟或關閉。

haproxy配置說明

關于 haproxy 安裝與配置，可詳見HaProxy安裝和常用命令

haproxy 默認配置說明

#查看默認 haproxy.cfg 配置文件
cat /usr/local/haproxy/conf/haproxy.cfg

global
    log         127.0.0.1 local2      # 需要設置/etc/rsyslog.conf加上local2設備的日志記錄級別和日志路徑
    chroot      /usr/local/haproxy    #這里通過編譯安裝到/usr/local/haproxy，yum安裝默認在/var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000                  # 這是前端對外的最大連接數。代理http時，1G空閑內存承載20000以上沒大問題
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats  # 開啟動態查看、管理haproxy的狀態文件
                                         # 另外建議設置spread-checks全局項，且百分比建議為2-5之間
defaults
    mode                    http         # 7層http代理，另有4層tcp代理
    log                     global
    option                  httplog      # 在日志中記錄http請求、session信息等
    option                  dontlognull  # 不要在日志中記錄空連接
    option http-server-close             # 后端為動態應用程序建議使用http-server-close，后端為靜態建議使用http-keep-alive
    option forwardfor       except 127.0.0.0/8  # haproxy將在發往后端的請求中加上"X-Forwarded-For"首部字段
    option                  redispatch   # 當某后端down掉使得haproxy無法轉發攜帶cookie的請求到該后端時，將其轉發到別的后端上
    timeout http-request    10s     # 此為等待客戶端發送完整請求的最大時長，應該設置較短些防止洪水***，如設置為2-3秒
                                    # haproxy總是要求一次請求或響應全部發送完成后才會處理、轉發，
    timeout queue           1m      # 請求在隊列中的最大時長，1分鐘太長了。設置為10秒都有點長，10秒請求不到資源客戶端會失去耐心
    timeout connect         10s     # haproxy和服務端建立連接的最大時長，設置為1秒就足夠了。局域網內建立連接一般都是瞬間的
    timeout client          1m      # 和客戶端保持空閑連接的超時時長，在高并發下可稍微短一點，可設置為10秒以盡快釋放連接
    timeout server          1m      # 和服務端保持空閑連接的超時時長，局域網內建立連接很快，所以盡量設置短一些，特別是并發時，如設置為1-3秒
    timeout http-keep-alive 10s     # 和客戶端保持長連接的最大時長。優先級高于timeout http-request高于timeout client
    timeout check           10s     # 和后端服務器成功建立連接后到最終完成檢查的時長(不包括建立連接的時間，只是讀取到檢查結果的時長)，
                                    # 可設置短一點，如1-2秒
    maxconn                 3000    # 默認和前段的最大連接數，但不能超過global中的maxconn硬限制數

說明??：

（1）haproxy是單進程、事件驅動模型的軟件，單進程下工作效率已經非常好，不建議開啟的多進程/多實例。

（2）maxconn指令控制最大并發連接數，可以在多處設置，設置位置不同，代表意義不同：

  <1> 設置在global段或frontend/listen/defaults段的maxconn代表的是和客戶端(即frontend)的最大連接并發數；其中global段的值是硬限制，frontend/listen/defaults段的maxconn值不能超過global段的值。

  <2> 設置在server指令中時，代表的是haproxy和某臺后端服務器維持的最大并發連接數。

  <3> 前端的最大并發數(即global段的maxconn)可以根據內存來估算，haproxy為每個連接維持兩個緩存區，每個大致16K左右，加上一些額外數據，共約33-34K左右，因此理論上1G的空閑內存能維持2W-2.5W個純HTTP的并發連接(只是理論上)，如果代理的是https，則允許的最大并發數量要小的多。前端maxconn默認值為2000，非常有必要將其增加幾倍。一般代理純http服務時，如果后端能處理及時，這里設置20000以上都不會有什么問題。以上只是大致估算代理能力，實際設置時必須根據后端處理能力以及haproxy自身能力設置前端maxconn，否則將前端接進來后端也無法立即處理。

  <4> 后端所有服務器的maxconn值之和應接近前端的maxconn值，計算兩者差距時，還需要考慮后端的等待隊列長度maxqueue。其中和靜態web服務器的maxconn可以設置大一些。

haproxy按需修改后配置說明

global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     20000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats
    spread-checks 2
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    timeout http-request    2s
    timeout queue           3s
    timeout connect         1s
    timeout client          10s
    timeout server          2s
    timeout http-keep-alive 10s
    timeout check           2s
    maxconn                 18000 

frontend http-in
    bind             0.0.0.0:80                 # 表示haproxy監聽所有地址，監聽的端口為80
    mode             http
    log              global
    capture request  header Host len 20
    capture request  header Referer len 60
    ####### 定義訪問控制，表示url以.css .js .html .php結尾的分別調度到哪臺服務器上訪問 #########
    #ACL本意是access control list(訪問控制列表)，用來定義一組黑名單或白名單。
    acl url_static   path_beg  -i /static /images /stylesheets     
    acl url_static   path_end  -i .jpg .jpeg .gif .png .ico .bmp .css .js
    acl url_static   path_end  -i .html .htm .shtml .shtm .pdf .mp3 .mp4 .rm .rmvb .txt
    acl url_static   path_end  -i .zip .rar .gz .tgz .bz2 .tgz
    ####### usr_backend表示使用backend服務，if表示如果滿足url_static這個條件就調度到這臺服務器上 ########
    use_backend      static_group   if url_static
    #不滿足則響應backend的默認動態頁面
    default_backend  dynamic_group

backend static_group
    balance            roundrobin        #haproxy反向代理調度算法。如果后端是靜態web，建議使用roundrobin算法。
    option             http-keep-alive   #分析并處理所有的request和response（默認），當后端為靜態web或靜態緩存服務器時，使用http-keep-alive模型。由于響應速度快，頻繁建立tcp連接的代價比較大；
    http-reuse         safe              #開啟 haproxy 連接重用功能，safe：這是建議使用的策略。
    option httpchk     GET /index.html   #開啟 haproxy 健康檢查，本例是基于http協議檢查。默認會使用tcp協議進行檢查，如果要基于其它協議檢查，需要使用協議對應的option指令顯式指定要檢查的對象。且前提是server中必須指定check，這是控制檢查與否的開關。
    http-check expect  status 200        #使用http-check expect指定要檢查到狀態碼200才認為健康。如果不指定http-check expect指令，那么基于http協議檢查的時候，只要狀態碼為2xx或3xx都認為是健康的。
    server staticsrv1  192.168.100.62:80 check rise 1 maxconn 5000  #check設置的是是否開啟健康檢查功能，以及檢查的時間間隔、判斷多少次不健康后就認為后端下線了以及成功多少次后認為后端重新上線了。
    server staticsrv2  192.168.100.63:80 check rise 1 maxconn 5000  #rise <count>：設定健康狀態檢查中，某離線的server從離線狀態轉換至正常狀態需要成功檢查的次數；
                                                                    #maxconn <maxconn>：指定此服務器接受的最大并發連接數；如果發往此服務器的連接數目高于此處指定的值，其將被放置于請求隊列，以等待其它連接被釋放；
backend dynamic_group
    cookie appsrv insert nocache      #向響應報文中插入了一個cookie，保證被調度過的服務端和客戶端能保持會話。
    balance roundrobin                #如果后端需要保持會話信息，但又不使用cookie時，可以使用源地址hash算法source，保證將同一客戶端引導到同一后端服務器上。如果使用cookie，則可以使用roundrobin或leastconn算法。源地址hash算法，一般只在沒有辦法的時候但又要調度到同一后端服務器時，才作為最后手段。
    option http-server-close          #處理完第一個response后關閉和server端的連接，但和客戶端的連接仍然保持，后端為動態應用程序服務器組建議使用此模式。
    option httpchk     GET /index.php #設置通過獲取index.php來做健康狀況檢查
    http-check expect  status 200     #使用http-check expect指定要檢查到狀態碼200才認為健康。
    server appsrv1 192.168.100.60:80  check rise 1 maxconn 3000 cookie appsrv1  #cookie <value>：為指定server設定cookie值，此處指定的值將在請求入站時被檢查，第一次為此值挑選的server將在后續的請求中被選中，其目的在于實現持久連接的功能；
    server appsrv2 192.168.100.61:80  check rise 1 maxconn 3000 cookie appsrv2

listen report_stats
        bind 0.0.0.0:8081                        #監聽端口
        stats refresh 30s                  #統計頁面自動刷新時間 
        stats enable                       #啟用管理界面
        stats hide-version                 #隱藏統計頁面上HAProxy的版本信息
        stats uri    /hastats              #統計頁面url 
        stats realm  "pls enter your name" #統計頁面密碼框上提示文本 
        stats auth   admin:admin           #統計頁面用戶名和密碼設置 
        stats admin  if TRUE               #如果登錄成功就可以管理在線服務器

##### 定義錯誤頁面 #####
errorfile 403 /etc/haproxy/errorfiles/403.http
errorfile 500 /etc/haproxy/errorfiles/500.http
errorfile 502 /etc/haproxy/errorfiles/502.http
errorfile 503 /etc/haproxy/errorfiles/503.http

上面的配置中：

• （1）靜態請求將分配給static_group并進行roundrobin調度，同時通過獲取index.html來做健康狀況檢查，此外還設置了haproxy和后端連接重用的功能。

• （2）動態請求將分配給dynamic_group并進行roundrobin調度，但是向響應報文中插入了一個cookie，保證被調度過的服務端和客戶端能保持會話。此外還設置了通過獲取index.php來做健康狀況檢查。

配置nginx和php+php-fpm

yum -y install nginx php php-fpm

為了區分，分別為nginx1/nginx2的index.php、nginx3/nginx4的index.html文件中加入響應的主機來源提示，并在php文件中設置cookie項。其中index.php的內容參考如下：

<h2>response from webapp 192.168.100.60</h2>
<?php
    session_start();
    echo "Server IP: "."<font color=red>".$_SERVER['SERVER_ADDR']."</font>"."<br>";
    echo "Server Name: "."<font color=red>".$_SERVER['SERVER_NAME']."</font>"."<br>";
    echo "SESSIONNAME: "."<font color=red>".session_name()."</font>"."<br>";
    echo "SESSIONID: "."<font color=red>".session_id()."</font>"."<br>";
?>

測試。其中php頁面返回內容大致如此：

參考文檔

• haproxy配置示例和需要考慮的問題

• HAProxy用法詳解 全網最詳細中文文檔

• HAproxy（二）動靜分離