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

HaProxy系列文章：http://www.cnblogs.com/f-ck-need-u/p/7576137.html

---

haproxy是一個非常優秀的負載均衡工具，它的特性非常豐富，功能也非常非常強大，要想好好使用它，將它的功能和性能挖掘出來，多多閱讀官方手冊是必不可少的。

本文提供一個簡單的配置示例，后面將分別開文章詳細解釋它的配置文件、cookie會話保持、stick table的功能、haproxy主主模型的復制(replication)、抵御攻擊等等。

1. 配置haproxy需要考慮的事情

盡管haproxy大多數配置選項都可以采用默認配置，但有些選項，特別是關於實際需求、連接數和超時時間相關的選項必須獨立配置。

大致總結了下以下幾點需要考慮的問題：

1. haproxy支持5種http事務模型。一般只會選擇其中兩種：
   • (1).當后端為靜態web或靜態緩存服務器時，使用http-keep-alive模型，由於響應速度快，頻繁建立tcp連接的代價比較大；
   • (2).當后端為動態應用程序服務器或者靜態但傳輸的資源對象體積較大時，使用http-server-close模型，因為響應速度相對較慢，占用空閑連接的資源比建立tcp連接的代價更大。
2. haproxy反向代理的調度算法優先級是低於cookie的，因此當一個連接已經保持了會話，調度算法對該連接就無效。只有新的連接請求或者長連接已經失效時，才會使用調度算法進行調度。在調度算法的選擇上，如果不考慮服務器性能差距的話：
   • (1).如果后端會話時間比較長(mysql)，建議使用leastconn，因為調度過程中，后端釋放連接時動盪不大，比較穩定。
   • (2).如果后端是靜態web，建議使用roundrobin算法。
   • (3).如果后端需要保持會話信息，但又不使用cookie時，可以使用源地址hash算法source，保證將同一客戶端引導到同一后端服務器上。如果使用cookie，則可以使用roundrobin或leastconn算法。源地址hash算法，一般只在沒有辦法的時候但又要調度到同一后端服務器時，才作為最后手段。
   • (4).如果配置了session共享，則對於haproxy來說，動態資源的請求是"無狀態"的，可以使用roundrobin算法或leastconn。
   • (5).如果后端是緩存服務器，為了保證命中率，建議使用uri算法，同時將hash-type設置為consistent方法(一致性hash)，保證后端緩存服務器down掉后對客戶端的影響足夠小。
3. haproxy是單進程、事件驅動模型的軟件，單進程下工作效率已經非常好，不建議開啟的多進程/多實例。
4. 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可以設置大一些。
5. 開啟haproxy和后端的連接重用功能。當某客戶端的請求到來后，haproxy和后端某服務器建立一個TCP連接，並將請求調度到該服務器上，該客戶端后續的請求也會通過該TCP連接轉發給后端(假設沒有采用關閉后端連接的http事務模型)。但在響應后和該客戶端的下一個請求到來前，這個連接是空閑的。和后端建立的TCP連接只是為了調度轉發，免去后續再次建立tcp連接的消耗。它完全可以為其它客戶端的請求調度也使用這個TCP連接，保證TCP連接資源不浪費。可以使用http-reuse strategy_name指令設置連接重用的策略，而默認策略禁用連接重用。
   • (1).never：這是默認設置。表示禁用連接重用，因為老版本的haproxy認為來源不同的請求不應該共享同一個后端連接。
   • (2).safe：這是建議使用的策略。"安全"策略下，haproxy為客戶端的每個第一個請求都單獨建立一個和后端的TCP連接，但是后續的請求則會重用和該后端的空閑TCP連接。這樣的轉發不僅提高了資源使用率，還保持了keep-alive的功能。因此，safe策略配合http-keep-alive事務模式比http-server-close事務模式更高效，無論后端是靜態、緩存還是動態應用服務器。
   • (3).aggressive：一種激進的策略，該策略的haproxy會重用空閑TCP連接來轉發大多數客戶端的第一次請求。之所以是大多數而不是所有，是因為haproxy會挑選那些已經被重用過至少一次的連接(即從建立開始轉發過至少兩次，不管源是否是同一客戶端)進行重用，因為haproxy認為只有這樣的連接才具有重用能力。
   • (4).always：它將總是為第一個請求重用空閑連接。當后端是緩存服務器時，這種策略比safe策略的性能要高許多，因為這樣的請求行為都是一樣的，且可以共享同一連接來獲取資源。不過不建議使用這種策略，因為大多數情況下，它和aggressive的性能是一樣的，但是卻帶來了很多風險。
     　
     因此，為了性能的提升，將它設置為safe或aggressive吧，同時再將http事務模型設置為http-keep-alive。
6. 對於haproxy是否開啟cookie以及stick table相關功能的設置必須嚴加考慮，它直接影響調度算法的選擇和負載均衡的性能。不過如果后端應用程序服務器共享了session，haproxy可以不用設置會話粘性相關的選項。
7. haproxy的默認配置文件中關於超時時間的設置應該修改，不少項設置都很不合理。
8. 建議開啟haproxy的X-Forwarded-For選項，使得后端服務器能夠記錄客戶端的真實源IP地址。
9. 建議開啟haproxy的狀態頁面，並設置訪問權限。

為了實現Haproxy完善的功能，上面幾個問題是遠遠不夠的，但可以在邊使用haproxy過程中邊增加功能使其不斷完美。

2. 配置haproxy提供反向代理功能

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

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

默認配置如下：

global
    log         127.0.0.1 local2      # 需要設置/etc/rsyslog.conf加上local2設備的日志記錄級別和日志路徑
    chroot      /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硬限制數

所以修改后建議配置為如下：

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 *:80 mode http log global capture request header Host len 20 capture request header Referer len 60 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 use_backend static_group if url_static default_backend dynamic_group backend static_group balance roundrobin option http-keep-alive http-reuse safe option httpchk GET /index.html http-check expect status 200 server staticsrv1 192.168.100.62:80 check rise 1 maxconn 5000 server staticsrv2 192.168.100.63:80 check rise 1 maxconn 5000 backend dynamic_group cookie appsrv insert nocache balance roundrobin option http-server-close option httpchk GET /index.php http-check expect status 200 server appsrv1 192.168.100.60:80 check rise 1 maxconn 3000 cookie appsrv1 server appsrv2 192.168.100.61:80 check rise 1 maxconn 3000 cookie appsrv2 listen report_stats bind *:8081 stats enable stats hide-version stats uri /hastats stats realm "pls enter your name" stats auth admin:admin stats admin if TRUE

上面的配置中：

• (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的內容參考如下：

<h1>response from webapp 192.168.100.60</h1>
<?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頁面返回內容大致如此：