HAProxy

博文參考

http://ju.outofmemory.cn/entry/218244
http://www.cnblogs.com/gtms/p/6790939.html
http://www.92to.com/bangong/2016/08-24/9737822.html
http://blog.sina.com.cn/s/blog_704836f40102vrt0.html
http://blog.csdn.net/jinshiyill/article/details/50824352

架構圖

HAProxy概述

HAProxy簡介

HAProxy主要提供兩個功能：http協議反向代理(不提供緩存功能)、基於tcp層的負載均衡(如https、MySQL協議)。適用於須要會話保持或七層處理的且負載特別大的站點。可支持數以萬計的併發鏈接。
  代理做用：web緩存（加速）、反向代理、內容路由（根據流量及內容類型等將請求轉發至特定服務器）、轉碼器；
  HAProxy基於一種事件驅動(event-driven)、單一進程模型和ebtree彈性二叉樹機制。
  多進程或多線程模型受內存限制、系統調度器限制以及無處不在的鎖限制，不多能處理數千併發鏈接。事件驅動模型有更好的資源和時間管理的用戶端(User-Space) 實現全部這些任務，因此併發響應能特別大。但在多核系統上此模型一般擴展性較差

性能優點

HAProxy藉助於OS上幾種常見的技術來實現性能的最大化。
      單進程、事件驅動模型顯著下降了上下文切換的開銷及內存佔用。
      O(1)事件檢查器(eventchecker)容許其在高併發鏈接中對任何鏈接的任何事件實現即時探測。
      在任何可用的狀況下，單緩衝(singlebuffering)機制能以不復制任何數據的方式完成讀寫操做，這會節約大量的CPU時鐘週期及內存帶寬；
      藉助於Linux 2.6 (>=2.6.27.19)上的splice()系統調用，HAProxy能夠實現零複製轉發(Zero-copy forwarding)，在Linux3.5及以上的OS中還能夠實現零複製啓動(zero-starting)；
       內存分配器在固定大小的內存池中可實現即時內存分配，這可以顯著減小建立一個會話的時長；
       樹型存儲：側重於使用做者多年前開發的彈性二叉樹，實現了以O(log(N))的低開銷來保持計時器命令、保持運行隊列命令及管理輪詢及最少鏈接隊列；
      優化的HTTP首部分析：優化的首部分析功能避免了在HTTP首部分析過程當中重讀任何內存區域；
      精心地下降了昂貴的系統調用，大部分工做都在用戶空間完成，如時間讀取、緩衝聚合及文件描述符的啓用和禁用等；

HAProxy目前主要版本

1.4版本——提供較好的彈性：衍生於1.2版本，並提供了額外的新特性，其中大多數是期待已久的。
客戶端側的長鏈接(client-side keep-alive)
TCP加速(TCP speedups)
響應池(response buffering)
RDP協議
基於源的粘性(source-based stickiness)
更好的統計數據接口(a much better stats interfaces)
更詳細的健康狀態檢測機制(more verbose health checks)
基於流量的健康評估機制(traffic-based health)
支持HTTP認證
服務器管理命令行接口(server management from the CLI)
基於ACL的持久性(ACL-based persistence)
日誌分析器

1.3版本——內容交換和超強負載：衍生於1.2版本，並提供了額外的新特性。

內容交換(content switching)：基於任何請求標準挑選服務器池；
ACL：編寫內容交換規則；
負載均衡算法(load-balancing algorithms)：更多的算法支持；
內容探測(content inspection)：阻止非受權協議；
透明代理(transparentproxy)：在linux系統上容許使用客戶端IP直接連入服務器；
內核TCP拼接(kernel TCPsplicing)：無copy方式在客戶端和服務端之間轉發數據以實現數G級別的數據速率；
分層設計(layereddesign)：分別實現套接字、TCP、HTTP處理以提供更好的健壯性、更快的處理機制及便捷的演進能力；
快速、公平調度器(fast and fairscheduler)：爲某些任務指定優先級可實現理好的QoS；
會話速率限制(session rate limiting)：適用於託管環境；
注意：

1)1.一、1.二、1.3的poll和epoll機制對性能影響
      1.1l版本默認使用的polling系統爲select()，其處理的文件數達數千個時性能便會急劇降低。
      1.2和1.3版本默認的爲poll()，在有些操做系統上可會也會有性能方面的問題，但在Solaris上表現至關不錯。
      HAProxy1.3在Linux 2.6及打了epoll補丁的Linux2.4上默認使用epoll，在FreeBSD上使用kqueue，這兩種機制在任何負載上都能提供恆定的性能表現。
 2) 高性能選型方案

Linux 2.6.32及以後版本上運行HAProxy 1.4；
打了epoll補丁的Linux2.4上運行HAProxy 1.4；
FreeBSD上運行HAProxy1.4；
Solaris10上運行HAProxy 1.4；

3)splice()調用機制
        在較新版本的Linux2.6(>=2.6.27.19)上，HAProxy還可以使用splice()系統調用在接口間無複製地轉發任何數據，甚至能夠達到10Gbps的性能。

HAProxy安裝配置

程序包安裝

[root@localhost~]# yum install -y haproxy
主配置文件：/etc/haproxy/haproxy.cfg
主程序：/usr/sbin/haproxy

配置文件格式

實例一：

frontend  main *:5000
   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             app
backendstatic
   balance    roundrobin
   server     static 127.0.0.1:4331 check
backendapp
   balance    roundrobin
   server app1 127.0.0.1:5001 check
   server app2 127.0.0.1:5002 check
   server app3 127.0.0.1:5003 check
   server app4 127.0.0.1:5004 check

實例二：

frontendmain
bind  *:80
default_backendwebsrvs
backendwebsrvs
balanceroundrobin
server web1 172.16.49.102:80 check
server web2 172.16.49.103:80 check

HAProxy代理相關配置

balance

定義負載均衡算法，可用於"defaults"、"listen"和"backend"配置段

① roundrobin，表示簡單的輪詢，這個是負載均衡基本都具有的；
    ② static-rr，表示根據權重，選擇 server 的邏輯最爲簡單
    ③ leastconn，表示最少鏈接者先處理
    ④ source，表示根據請求源IP，這個跟Nginx的IP_hash機制相似，用其做爲解決session問題的一種方法
    ⑤ ri，表示根據請求的URI；
    ⑥ rl_param，表示根據請求的URl參數’balance url_param’ requires an URL parameter name；
    ⑦ hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求；

    ⑧ rdp-cookie(name)，表示根據據cookie(name)來鎖定並哈希每一次TCP請求。

注意

(1)當使用uri算法時，第一次請求一個URL分發到一個主機，則以後再次請求相同URL則使用一臺主機響應。當第一次請求以後，若響應該請求的主機服務出現故障，則haproxy或將其調度到其餘主機，此主機修復後再次調度回來
      (2)URI：統一資源標識符；格式以下：
    <SCHEME>://<USER>:<PASSWORD>@<HOST>:<PORT>/<PATH>;<PARAMS>?<QUERY>#<FRAG>
    方案://用戶:密碼@主機:端口/路徑;參數(鍵值數據、能夠多個參數字段)?查詢語句#片斷顯示

hash-type

格式：hash-type <method>
     定義用於將hash碼映射至後端服務器的方法；不能用於frontend區段；可用方法有map-based和consistent
  說明：

bind

定義一個或者幾個監聽的套接字、只能用於frontend， listen;
    bind[<address>]:<port_range> [, ...]
    bind[<address>]:<port_range> [, ...] interface <interface>

default_backend

爲frontend指明使用的默認後端；default_backend<backend>
實例：
use_backend dynamic if url_dyn
use_backend static if url_css url_img extension_img
default_backend dynamic

注意：use_backend: 條件式後端調用；

server

server <name> <addr>:port；用於爲後端聲明一個server
<name>：名稱，標識符
<addr>[:port]：設定後端真實服務器監聽的端口和地址
[param*]：參數
backup: 設定爲備用服務器，僅在負載均衡場景中的其它server均不可用於啓用此server；
check:健康狀態檢測；
inter<delay>：檢測時間間隔；單位爲ms, 默認爲2000;
rise<count>：設定健康狀態檢查中，某離線的server從離線狀態轉換至正常狀態須要成功檢查的次數；
fall<count>：確認server從正常狀態轉換爲不可用狀態須要檢查的次數；
cookie <value>：爲指定server設定cookie值，用於實現持久鏈接的功能；
maxconn:此服務接受的併發鏈接的最大數量；
maxqueue:請求隊列的最大長度；
observe:根據流量判斷後端server的健康狀態；
weight #: 指定權重，#默認爲1，最大爲256；0表示不被調度；
redir<prefix>: 重定向；全部發往此服務器的請求均以302響應；

注意：

健康監測的方式有多種，具體服務可能檢測方法的配置指令不一樣；此處爲後端http服務時的健康狀態的檢測方法，在defaults配置段定義了" option httpchk "。

"httpchk"、"smtpchk"、"mysql-check"、"pgsql-check"、"ssl-hello-chk"

實例：基於瀏覽器cookie實現sessionsticky(會話綁定)

backendwebsrvs

balance    roundrobin
  cookie SERVERID insert    # 報文首部插入標識
  server web1 172.16.49.102:80 check weight 1 cookie websrv1     # cookie綁定名稱參數標識
  server web2 172.16.49.103:80 check weight 3 cookie websrv2

註釋：每一個server有本身唯一的cookie標識、在backend中定義爲用戶請求調度完成後操縱其cookie

日誌記錄信息

(1) capture requestheader

格式：capture request header <name> len <length>
      捕獲並記錄指定的請求首部最近一次出現時的第一個值，僅能用於「frontend」和「listen」區段
    <name>：要捕獲的首部的名稱，此名稱不區分字符大小寫，但建議與它們出如今首部中的格式相同，好比大寫首字母。須要注意的是，記錄在日誌中的是首部對應的值，而非首部名稱。
    <length>：指定記錄首部值時所記錄的精確長度，超出的部分將會被忽略。

注意：

能夠捕獲的請求首部的個數沒有限制，但每一個捕獲最多隻能記錄64個字符。爲了保證同一個frontend中日誌格式的統一性，首部捕獲僅能在frontend中定義。

(2)captureresponse header；捕獲並記錄響應首部，其格式和要點同請求首部。

格式：capture response header <name> len <length>

HAProxy狀態監控頁配置

配置監控頁信息

1.配置監控頁信息
(1)stats enable

啓用基於程序編譯時默認設置的統計報告，不能用於「frontend」區段。

(2)stats hide-version

啓用統計報告並隱藏HAProxy版本報告，不能用於「frontend」區段。

(3)stats realm

格式：stats realm <realm>
        <realm>：實現HTTP基本認證時顯示在瀏覽器中的領域名稱，用於提示用戶輸入一個用戶名和密碼。
  啓用統計報告並高精認證領域，不能用於「frontend」區段。haproxy在讀取realm時會將其視做一個單詞，所以，中間的任何空白字符都必須使用反斜線進行轉義。此參數僅在與「statsauth」配置使用時有意義。

(4)stats scope

stats scope {<name> | "." }
       <name>：能夠是「listen」、「frontend」或「backend」區段的名稱，而「.」則表示statsscope語句所定義的當前區段。
     啓用統計報告並限定報告的區段，不能用於「frontend」區段。當指定此語句時，統計報告將僅顯示其列舉出區段的報告信息，全部其它區段的信息將被隱藏。若是須要顯示多個區段的統計報告，此語句能夠定義屢次。須要注意的是，區段名稱檢測僅僅是以字符串比較的方式進行，它不會真檢測指定的區段是否真正存在。

(5)stats auth

格式：stats auth <user>:<passwd>
<user>：受權進行訪問的用戶名；
<passwd>：此用戶的訪問密碼，明文格式；
      啓用帶認證的統計報告功能並受權一個用戶賬號，其不能用於「frontend」區段。

(6)stats admin

格式：stats admin {if | unless } <cond>
     在指定的條件知足時啓用統計報告頁面的管理級別功能，它容許經過web接口啓用或禁用服務器。

配置案例：stats狀態監控頁

(1)在配置文件/etc/haproxy/haproxy.cfg中配置代理和監控配置信息
listenstatistics

bind  *:9090
stats  enable
stats  hide-version
stats uri /haproxyadmin?stats 
stats realm  "HAPorxy\Statistics"
stats auth admin:xuding
stats admin if TRUE

(2)訪問URL：http://172.16.49.101:9090/hap...

(3)此時便可進入管理頁面進行對後端服務器的管理和頁面監控數據監控

說明：

錯誤頁面

errorfile:使用haproxy主機本地文件進行響應；
errorloc,errorloc302: 使用指定的url進行響應，響應狀態碼爲302；不適用於GET之外的其它請求方法；
errorloc303：返回303狀態碼；

errorfile

格式：errorfile <code> <file>

：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有200、400、40三、40八、500、50二、503和504；
<file>：指定用於響應的頁面文件

在用戶請求不存在的頁面時，返回一個頁面文件給客戶端而非由haproxy生成的錯誤代碼；可用於全部段中。

實例：
errorfile400 /etc/haproxy/errorpages/400badreq.http
errorfile403 /etc/haproxy/errorpages/403forbid.http
errorfile503 /etc/haproxy/errorpages/503sorry.http

errorloc和errorloc302

請求錯誤時，返回一個HTTP重定向至某URL的信息；可用於全部配置段中。
    errorloc<code> <url>
    errorloc302<code> <url>
       <code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有200、400、40三、40八、500、50二、503和504；
       <url>：Location首部中指定的頁面位置的具體路徑，能夠是在當前服務器上的頁面的相對路徑，也可使用絕對路徑；須要注意的是，若是URI自身錯誤時產生某特定狀態碼信息的話，有可能會致使循環定向；

注意：

這兩個關鍵字都會返回302狀態嗎，這將使得客戶端使用一樣的HTTP方法獲取指定的URL，對於非GET廣場法的場景(如POST)來講會產生問題，由於返回客戶的URL是不容許使用GET之外的其它方法的。若是的確有這種問題，可使用errorloc303來返回303狀態碼給客戶端。

errorloc303

errorloc303 <code> <url>；請求錯誤時，返回一個HTTP重定向至某URL的信息給客戶端；可用於全部配置段中。
     <code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有400、40三、40八、500、50二、503和504；
     <url>：Location首部中指定的頁面位置的具體路徑，能夠是在當前服務器上的頁面的相對路徑，也可使用絕對路徑；須要注意的是，若是URI自身錯誤時產生某特定狀態碼信息的話，有可能會致使循環定向；

實例：backendwebserver server 172.16.100.6 172.16.100.6:80 checkmaxconn 3000 cookie srv01 server 172.16.100.7 172.16.100.7:80 checkmaxconn 3000 cookie srv02 errorfile 403/etc/haproxy/errorpages/sorry.htm errorfile 503/etc/haproxy/errorpages/sorry.htm