HAproxy的簡單應用和基礎知識

HAProxy（負載均衡器），能夠實現正向代理和反向代理

能夠基於http協議反向代理，和tcp層的負載均衡（相似lvs的功能）

 代理的做用：web緩存、反向代理、內容路由（根據流量及內容類型等將請求轉發至特定服務器）、轉碼器

 緩存的做用：

    減小冗餘內容傳輸

    節省帶寬、緩解網絡瓶頸

    下降了對原始服務器的請求壓力

    下降了傳輸延遲

 

配置文件：/etc/haproxy/haproxy.cfg

    /usr/sbin/haproxy程序文件

配置分爲兩段：

   global：配置全局參數，如log，maxconn，…

   proxies

     default，frontend，backend，listen

     frontend，定義前端；backend：定義後端；listen是定義前端和後端，但只能是一對；default默認的，若是沒有明確指明就使用默認

   default_backend:爲frontend指明使用的默認後端；

      use_backend:條件式後端調用

  balance: 指明調度算法；

  示例：這就是一個簡單的haproxy的配置

    frontend main *:80

    default_backend websrvs

    backend websrvs

     balance roundrobin

        serverweb1 172.16.249.115 check

        serverweb2 172.16.249.159 check

 

配置文件中全局中字段的意思：

    log：定義日誌信息的

    nbproc <number>：指定啓動的haproxy進程的個數，只能用於守護進程模式的haproxy；默認只啓動一個進程，鑑於調試困難等多方面的緣由，通常只在單進程僅能打開少數文件描述符的場景中才使用多進程模式；

  maxconn     4000：設定每一個haproxy進程所能接受的最大併發鏈接數，這個根據本身需求盡心修改，最大爲3萬個左右

  daemon ： 表示啓動爲守護進程，若是不加將運行在前臺

   ulimit-n：設定每一個進程可以打開的最大文件描述符數目，默認狀況下會自動計算，不用修改和添加

  spread-checks <0..50,in percent>：作健康狀態檢查時報文發送的時間間隔，能夠爲本身定義的時間的先後N% （0-50）表示0%到50%

  tune.bufsize： 定義緩衝區的大小，默認就能夠

  tune.maxaccept<number>：設定haproxy進程內核調度運行時一次性能夠接受的鏈接的個數，較大的值能夠帶來較大的吞吐率，默認在單進程模式下爲100，多進程模式下爲8，設定爲-1能夠禁止此限制；通常不建議修改；

    tune.maxpollevents  <number>：設定一次系統調用能夠處理的事件最大數，默認值取決於操做系統；其值小於200時可節約帶寬，但會略微增大網絡延遲，而大於200時會下降延遲，但會稍稍增長網絡帶寬的佔用量

   tune.maxrewrite<number>：設定爲首部重寫或追加而預留的緩衝空間，建議使用1024左右的大小；在須要使用更大的空間時，haproxy會自動增長其值；

其餘的默認就好了

 

下面以實例來解釋參數

172.16.249.195作haproxy，172.16.249.115  172.16.249.159 爲後端web服務器

修改配置文件（/etc/haproxy/haproxy.cfg）以下

server中的check是作健康檢測的，

而後啓動systemctl  start  haproxy.service，要保證80端口沒有被佔用

使用systemctl  status  haproxy.service，能夠查看狀態

而後訪問測試下

能夠看到最簡單的負載均衡就實現了，而後你能夠停掉後端的一臺web看可否作健康檢測

 

而後編輯日誌配置文件（/etc/rsyslog.conf）,讓haproxy的日誌能生效，由於默認local2是不記錄的

修改以下：

而後重啓日誌服務systemctl restart rsyslog.service

而後使用ss  -unl 看下udp的514端口是否開啓了

而後訪問幾下，去查看下日誌

能夠看到能記錄日誌了

 

HAProxy代理相關的參數：

代理相關的參數配置在以下段中：

 - defaults <name>

 - frontend <name>

 - backend <name>

 - listen  <name>

 「defaults」段用於爲全部其它配置段提供默認參數，這配置默認配置參數可由下一個「defaults」所從新設定。

 「frontend」段用於定義一系列監聽的套接字，這些套接字可接受客戶端請求並與之創建鏈接。

 「backend」段用於定義一系列「後端」服務器，代理將會將對應客戶端的請求轉發至這些服務器。

 「listen」段經過關聯「前端」和「後端」定義了一個完整的代理，一般只對TCP流量有用。

 

 全部代理的名稱只能使用大寫字母、小寫字母、數字、-(中線)、_(下劃線)、.(點號)和:(冒號)。此外，ACL名稱會區分字母大小寫

 

1、balance: 指明調度算法；

    動態：權重可動態調整，實時生效

    靜態：調整權重不會實時生效

    roundrobin:輪詢，動態算法，每一個後端主機最多支持4128個鏈接；

    static-rr:輪詢，靜態算法，每一個後端主機支持的數量無上限；

    leastconn:根據後端主機的負載數量進行調度；僅適用長鏈接的會話；動態；

    source:將請求的源地址進行hash運算，並由後端服務器的權重總數相除後派發至某匹配的服務器，之後來自這個IP地址的全部請求都會轉發給這一個後端服務器

        hash-type:

            map-based：取模法；靜態；

            consistent：一致性哈希法；動態；

    uri:對URI的左半部分(「問號」標記以前的部分)或整個URI進行hash運算，並由服務器的總權重相除後派發至某匹配的服務器；這可使得對同一個URI的請求老是被派發至某特定的服務器，除非服務器的權重總數發生了變化；此算法經常使用於代理緩存或反病毒代理以提升緩存的命中率；須要注意的是，此算法僅應用於HTTP後端服務器場景

  URI的組成爲：

    <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

    uri爲‘/’後面的全部內容；uri的左半部分是‘/’‘?’之間的內容

  例：http://www.baidu.com/inventory-check.cgi?item=123

    uri爲：inventory-check.cgi?item=123；uri的左半部分爲：inventory-check.cgi

        hash-type

            map-based:取模法；靜態

            consistent: 取模法；靜態

    url_param:根據url中的指定的參數的值進行調度；把值作hash計算，併除以總權重；此算法能夠經過追蹤請求中的用戶標識進而確保同一個用戶ID的請求將被送往同一個特定的服務器，除非服務器的總權重發生了變化，能夠實現相似會話保持的效果

        hash-type

            map-based:取模算法

            consistent:一致性hash算法

    hdr(<name>)：根據請求報文中指定的header(如use-agent,referer, hostname)進行調度；把指定的header的值作hash計算；若是相應的首部沒有出現或其沒有有效值，則使用輪詢算法對相應請求進行調度

        hash-type

            map-based:取模算法

            consistent:一致性hash算法

示例：基於uri算法，進行集羣調度

修改haproxy的配置文件，修改算法爲uri

而後重載服務systemctlreload haproxy.service

而後測試下，爲了演示效果，咱們多設置幾個頁面

在後端主機上執行

for i in{1..10};do echo "<h1>Page $i on web1</h1>" >/var/www/html/test$i.html;done

生成10個測試頁

另外一臺主機上執行

for i in {1..10};doecho "<h1>Page $i on web2</h1>" >/var/www/html/test$i.html;done 

而後訪問測試下

在用其餘的主機請求test1.html顯示的都是這個頁面不會變化了

而後換個測試頁試下，看能不能實現負載均衡，

 

能夠看到調度到第二個後端服務器上了

基於uri的調度算法的實現就作好了

若是是基於URI的算法調度，但後端的一個主機宕機了，那麼之前分發給這個主機的會自動調度給其餘主機

把一個後端的web主機的httpd服務停掉，在請求測試

會發現之前調度給web2的，由於如今web2宕機了，如今調度給web1了

 

示例：基於hdr實現調度

修改haproxy的配置文件

而後重載，進行測試

使用 curl  -A ‘hello’ http://172.16.249.195/test2.html 模擬不一樣的瀏覽器來測試

能夠看到能夠能基於瀏覽器進行調度

 

2、bind：此指令僅能用於frontend和listen區段，用於定義一個或幾個監聽的套接字

    bind [<address>]:<port_range>[, ...]

    bind [<address>]:<port_range>[, ...] interface <interface>

    <address>：可選選項，其能夠爲主機名、IPv4地址、IPv6地址或*；省略此選項、將其指定爲*或0.0.0.0時，將監聽當前系統的全部IPv4地址；

    <port_range>：能夠是一個特定的TCP端口，也但是一個端口範圍(如5005-5010)，代理服務器將經過指定的端口來接收客戶端請求；須要注意的是，每組監聽的套接字<address:port>在同一個實例上只能使用一次，並且小於1024的端口須要有特定權限的用戶才能使用，這可能須要經過uid參數來定義；

    <interface>：指定物理接口的名稱，僅能在Linux系統上使用；其不能使用接口別名，而僅能使用物理接口名稱，並且只有管理有權限指定綁定的物理接口

示例：修改端口

修改配置文件

而後重啓服務，看下端口

 

3、mode {tcp|http|health }：設定實例的運行模式或協議。當實現內容交換時，前端和後端必須工做於同一種模式(通常說來都是HTTP模式)，不然將沒法啓動實例。

    tcp：實例運行於純TCP模式，在客戶端和服務器端之間將創建一個全雙工的鏈接，且不會對7層報文作任何類型的檢查；此爲默認模式，一般用於SSL、SSH、SMTP等應用；

    http：實例運行於HTTP模式，客戶端請求在轉發至後端服務器以前將被深度分析，全部不與RFC格式兼容的請求都會被拒絕；

    health：實例工做於health模式，其對入站請求僅響應「OK」信息並關閉鏈接，且不會記錄任何日誌信息；此模式將用於響應外部組件的健康狀態檢查請求；目前業講，此模式已經廢棄，由於tcp或http模式中的monitor關鍵字可完成相似功能；

 

4、log global

    log <address> <facility>[<level> [<minlevel>]]

  爲每一個實例啓用事件和流量日誌，所以可用於全部區段。每一個實例最多能夠指定兩個log參數，不過，若是使用了「log global」且"global"段已經定了兩個log參數時，多餘了log參數將被忽略。

 

    global：當前實例的日誌系統參數同"global"段中的定義時，將使用此格式；每一個實例僅能定義一次「log global」語句，且其沒有任何額外參數；

    <address>：定義日誌發往的位置，其格式之一能夠爲<IPv4_address:PORT>，其中的port爲UDP協議端口，默認爲514；格式之二爲Unix套接字文件路徑，但須要留心chroot應用及用戶的讀寫權限；

    <facility>：能夠爲syslog系統的標準facility之一；

    <level>：定義日誌級別，即輸出信息過濾器，默認爲全部信息；指定級別時，全部等於或高於此級別的日誌信息將會被髮送；

 

5、maxconn<conns>：前端的最大併發鏈接數

 

  設定一個前端的最大併發鏈接數，所以，其不能用於backend區段。對於大型站點來講，能夠儘量提升此值以便讓haproxy管理鏈接隊列，從而避免沒法應答用戶請求。固然，此最大值不能超出「global」段中的定義。此外，須要留心的是，haproxy會爲每一個鏈接維持兩個緩衝，每一個緩衝的大小爲8KB，再加上其它的數據，每一個鏈接將大約佔用17KB的RAM空間。這意味着通過適當優化後，有着1GB的可用RAM空間時將能維護40000-50000併發鏈接。

 

  若是爲<conns>指定了一個過大值，極端場景下，其最終佔據的空間可能會超出當前主機的可用內存，這可能會帶來意想不到的結果；所以，將其設定了一個可接受值爲明智決定。其默認爲2000。

 

6、default_backend: 爲frontend指明使用的默認後端；

use_backend: 條件式後端調用；

在沒有匹配的"use_backend"規則時爲實例指定使用的默認後端，所以，其不可應用於backend區段。在"frontend"和"backend"之間進行內容交換時，一般使用"use-backend"定義其匹配規則；而沒有被規則匹配到的請求將由此參數指定的後端接收。

 

使用案例：

    use_backend     dynamic if  url_dyn

    use_backend     static  if  url_css url_img extension_img

    default_backend dynamic

 

7、server

  server <name> <address>[:port][param*]：爲後端聲明一個server，所以，不能用於defaults和frontend區段。

 

    <name>：爲此服務器指定的內部名稱，其將出如今日誌及警告信息中；若是設定了"http-send-server-name"，它還將被添加至發往此服務器的請求首部中；

    <address>：此服務器的的IPv4地址，也支持使用可解析的主機名，只不過在啓動時須要解析主機名至相應的IPv4地址；

    [:port]：指定將鏈接請求所發往的此服務器時的目標端口，其爲可選項；未設定時，將使用客戶端請求時的同一相端口；

    [param*]：爲此服務器設定的一系參數；其可用的參數很是多，具體請參考官方文檔中的說明，下面僅說明幾個經常使用的參數；

 

  服務器或默認服務器參數：

    backup：設定爲備用服務器，僅在負載均衡場景中的其它server均不可用於啓用此server；

    check：啓動對此server執行健康狀態檢查，其能夠藉助於額外的其它參數完成更精細的設定，

  如：

     inter <delay>：設定健康狀態檢查的時間間隔，單位爲毫秒，默認爲2000；也可使用fastinter和downinter來根據服務器端狀態優化此時間延遲；

     rise <count>：設定健康狀態檢查中，某離線的server從離線狀態轉換至正常狀態須要成功檢查的次數；

     fall <count>：確認server從正常狀態轉換爲不可用狀態須要檢查的次數；

    cookie <value>：爲指定server設定cookie值，此處指定的值將在請求入站時被檢查，第一次爲此值挑選的server將在後續的請求中被選中，其目的在於實現持久鏈接的功能；

    maxconn <maxconn>：指定此服務器接受的最大併發鏈接數；若是發往此服務器的鏈接數目高於此處指定的值，其將被放置於請求隊列，以等待其它鏈接被釋放；

    maxqueue <maxqueue>：設定請求隊列的最大長度；

    observe <mode>：經過觀察服務器的通訊情況來斷定其健康狀態，默認爲禁用，其支持的類型有「layer4」和「layer7」，「layer7」僅能用於http代理場景；

    redir <prefix>：啓用重定向功能，將發往此服務器的GET和HEAD請求均以302狀態碼響應；須要注意的是，在prefix後面不能使用/，且不能使用相對地址，以避免形成循環；例如：

 server srv1 172.16.100.6:80  redir http://p_w_picpathserver.magedu.com check

    weight <weight>：權重，默認爲1，最大值爲256，0表示不參與負載均衡；

 

  後端http服務作健康檢測時的檢查方法：

    option httpchk   請求主頁的

    option httpchk <uri>  指明請求的uri

    option httpchk <method> <uri>

    option httpchk <method> <uri><version>：

    不能用於frontend段，

  例如：

    backend https_relay

       mode tcp

       option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www.magedu.com

       server apache1 192.168.1.1:443 check port 80

     

  基於瀏覽器cookie實現session sticky的使用案例：

       backend websrvs

             balance     roundrobin

             cookieSERVERID insert nocache indirect

             serverweb1 172.16.100.68:80 check weight 1 cookie websrv1

             serverweb2 172.16.100.69:80 check weight 3 cookie websrv2

   要點：

    (1) 每一個server有本身唯一的cookie標識；

    (2) 在backend中定義爲用戶請求調度完成後操縱其cookie

   cookie的語法格式：cookie<name> [rewrite | insert | prefix ] [indirect] [nocache] [...]

    name爲cookie本身的名稱，rewrite是把本身定義的cookiename替換原來的；insert追加到後面；prefix添加到前面

實例：基於cookie實現會話綁定

修改haproxy的配置文件

重載，測試

能夠看到有cookie了，而後在請求其餘的資源都不會在基於輪詢進行調度，會基於cookie進行調度

 

8、stats：狀態監控頁的功能

stats enable：啓用

啓用基於程序編譯時默認設置的統計報告，不能用於「frontend」區段。只要沒有另外的其它設定，它們就會使用以下的默認配置：

 

  -stats uri   : /haproxy?stats

  -stats realm : "HAProxy Statistics"

  -stats auth  : no authentication

  -stats scope : no restriction

 

儘管「stats enable」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非指望的後果。

    下面是一個配置案例：

         backend  public_www

           server  websrv1 172.16.100.11:80

           stats  enable

           stats  hide-version

           stats  uri     /haproxyadmin?stats

           stats  realm   Haproxy\ Statistics

           stats  auth    statsadmin:password

           stats  auth    statsmaster:password

     

示例：實現stats

編輯haproxy的配置文件

加入下面這些

而後重啓服務，由於添加端口了

而後訪問下，由於沒有修改路徑，就是默認的路徑，也不須要認證就能夠看到了

 

而後修改配置文件

重載，訪問測試

輸入用戶名和密碼就能夠了

 

能夠看到在websrvs中的那一欄，有複選框能夠實現管理功能，這是由於加入了stats  admin if  TRUE  這一句，若是把這一句去掉，顯示的頁面爲

沒有複選框就不能實現管理功能了

 

9、capture requestheader：向日志中記錄額外信息，捕獲請求報文首部信息

capture request header <name> len<length>

 

捕獲並記錄指定的請求首部最近一次出現時的第一個值，僅能用於「frontend」和「listen」區段。捕獲的首部值使用花括號{}括起來後添加進日誌中。若是須要捕獲多個首部值，它們將以指定的次序出如今日誌文件中，並以豎線「|」做爲分隔符。不存在的首部記錄爲空字符串，最常須要捕獲的首部包括在虛擬主機環境中使用的「Host」、上傳請求首部中的「Content-length」、快速區別真實用戶和網絡機器人的「User-agent」，以及代理環境中記錄真實請求來源的「X-Forward-For」。

 

<name>：要捕獲的首部的名稱，此名稱不區分字符大小寫，但建議與它們出如今首部中的格式相同，好比大寫首字母。須要注意的是，記錄在日誌中的是首部對應的值，而非首部名稱。

<length>：指定記錄首部值時所記錄的精確長度，超出的部分將會被忽略。

 

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

 

10、capture responseheader：捕獲響應報文首部信息

 

capture response header <name> len<length>

 

捕獲並記錄響應首部，其格式和要點同請求首部。

 

11、option httplog：當mode爲http時，記錄豐富的日誌信息

 

option httplog [ clf ]

啓用記錄HTTP請求、會話狀態和計時器的功能。

clf：使用CLF格式來代替HAProxy默認的HTTP格式，一般在使用僅支持CLF格式的特定日誌分析器時才須要使用此格式。

默認狀況下，日誌輸入格式很是簡陋，由於其僅包括源地址、目標地址和實例名稱，而「option httplog」參數將會使得日誌格式變得豐富許多，其一般包括但不限於HTTP請求、鏈接計時器、會話狀態、鏈接數、捕獲的首部及cookie、「frontend」、「backend」及服務器名稱，固然也包括源地址和端口號等。

 

12、option logasap；no optionlogasap：啓用或禁用提早將HTTP請求記入日誌，不能用於「backend」區段。

默認狀況下，HTTP請求是在請求結束時進行記錄以便能將其總體傳輸時長和字節數記入日誌，由此，傳較大的對象時，其記入日誌的時長可能會略有延遲。「option logasap」參數可以在服務器發送complete首部時即時記錄日誌，只不過，此時將不記錄總體傳輸時長和字節數。此情形下，捕獲「Content-Length」響應首部來記錄傳輸的字節數是一個較好選擇。

通常在defaults段中默認定義

 

13、option forwardfor ：容許在發往服務器的請求首部中插入「X-Forwarded-For」首部

option forwardfor [ except <network>] [ header <name> ] [ if-none ]

<network>：可選參數，當指定時，源地址爲匹配至此網絡中的請求都禁用此功能。

<name>：可選參數，可以使用一個自定義的首部，如「X-Client」來替代「X-Forwarded-For」。有些獨特的web服務器的確須要用於一個獨特的首部。

if-none：僅在此首部不存在時纔將其添加至請求報文首部中。

 

HAProxy工做於反向代理模式，其發往服務器的請求中的客戶端IP均爲HAProxy主機的地址而非真正客戶端的地址，這會使得服務器端的日誌信息記錄不了真正的請求來源，「X-Forwarded-For」首部則可用於解決此問題。HAProxy能夠向每一個發往服務器的請求上添加此首部，並以客戶端IP爲其value。

 

須要注意的是，HAProxy工做於隧道模式，其僅檢查每個鏈接的第一個請求，所以，僅第一個請求報文被附加此首部。若是想爲每個請求都附加此首部，請確保同時使用了「option httpclose」、「option forceclose」和「option http-server-close」幾個option。

 

下面是一個例子：

frontend www

   mode http

   option forwardfor except 127.0.0.1

在haproxy配置文件中的defaults段中已經默認加入這一項了，

爲了看到效果，咱們編輯後端的web服務器，修改日誌記錄的內容，而後查看日誌

修改/etc/httpd/conf/httpd.conf 在LogFormat這一段中修改以下

而後重載httpd服務，而後訪問幾回，查看日誌

能夠看到記錄的是真實的客戶端地址了

 

14、errorfile：定義當用戶請求不存在的頁面時，使用haproxy主機本地文件進行響應

errorfile <code> <file>

 

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

<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有200、400、403、408、500、502、503和504；

<file>：指定用於響應的頁面文件；

例如：

errorfile 400/etc/haproxy/errorpages/400badreq.http

errorfile 403/etc/haproxy/errorpages/403forbid.http

errorfile 503/etc/haproxy/errorpages/503sorry.http

 

15、errorloc 和 errorloc302使用指定的url進行響應，響應狀態碼爲302；只適用於GET請求方法；

errorloc <code> <url>

errorloc302 <code> <url>

 

請求錯誤時，返回一個HTTP重定向至某URL的信息；可用於全部配置段中。

<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有200、400、403、408、500、502、503和504；

<url>：Location首部中指定的頁面位置的具體路徑，能夠是在當前服務器上的頁面的相對路徑，也可使用絕對路徑；須要注意的是，若是URI自身錯誤時產生某特定狀態碼信息的話，有可能會致使循環定向；

 

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

 

16、 errorloc303

errorloc303 <code> <url>

 

請求錯誤時，返回一個HTTP重定向至某URL的信息給客戶端；可用於全部配置段中。

<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有400、403、408、500、502、503和504；

<url>：Location首部中指定的頁面位置的具體路徑，能夠是在當前服務器上的頁面的相對路徑，也可使用絕對路徑；須要注意的是，若是URI自身錯誤時產生某特定狀態碼信息的話，有可能會致使循環定向；

 

 例如：

    backend webserver

     server 172.16.100.6 172.16.100.6:80 check maxconn 3000 cookie srv1

     server 172.16.100.7 172.16.100.7:80 check maxconn 3000 cookie srv2

     errorloc 403 /etc/haproxy/errorpages/sorry.html

     errorloc 503 /etc/haproxy/errorpages/sorry.html

 

1七、實現訪問控制

 http-request：基於http的訪問控制即7層的訪問控制

 語法格式：http-request{allow | deny | auth [realm <realm>]} [{ if | unless } <condition>]

    例：acl nagio***c 192.168.1.2

acl local_net src 192.168.0.0/16

acl auth_ok http_auth(L1)

http-request allow if nagios

http-request allow if local_net auth-_ok

http-request auth realm Gimme if local_net auth_ok

http-request deny

    tcp-request：基於tcp的訪問控制即4層的訪問控制

  

ACL的相關參數

haproxy的ACL用於實現基於請求報文的首部、響應報文的內容或其它的環境狀態信息來作出轉發決策，這大大加強了其配置彈性。其配置法則一般分爲兩步，首先去定義ACL，即定義一個測試條件，然後在條件獲得知足時執行某特定的動做，如阻止請求或轉發至某特定的後端。

ACL的語法格式以下：

    acl <aclname> <criterion> [flags][operator] <value> ...

    <aclname>：ACL名稱，區分字符大小寫，且其只能包含大小寫字母、數字、-(鏈接線)、_(下劃線)、.(點號)和:(冒號)；haproxy中，acl能夠重名，這能夠把多個測試條件定義爲一個共同的acl；

    <criterion>：測試標準，即對什麼信息發起測試；測試方式能夠由[flags]指定的標誌進行調整；而有些測試標準也能夠須要爲其在<value>以前指定一個操做符[operator]；

    [flags]：目前haproxy的acl支持的標誌位有3個：

       -i：不區分<value>中模式字符的大小寫；

       -f：從指定的文件中加載模式；

       --：標誌符的強制結束標記，在模式中的字符串像標記符時使用；

 <value>：acl測試條件支持的值有如下四類：

    a）整數或整數範圍：如1024:65535表示從1024至65535；僅支持使用正整數(若是出現相似小數的標識，其爲一般爲版本測試)，且支持使用的操做符有5個，分別爲eq、ge、gt、le和lt；  

   b）字符串：支持使用「-i」以忽略字符大小寫，支持使用「\」進行轉義；若是在模式首部出現了-i，能夠在其以前使用「--」標誌位；

    c）正則表達式：其機制類同字符串匹配；

    d）IP地址及網絡地址

 

同一個acl中能夠指定多個測試條件，這些測試條件須要由邏輯操做符指定其關係。條件間的組合測試關係有三種：「與」(默認即爲與操做)、「或」(使用「||」操做符)以及「非」(使用「!」操做符)。

1 、be_sess_rate<integer>

  be_sess_rate<integer>

 be表明backen

    用於測試指定的backend上會話建立的速率(即每秒建立的會話數)是否知足指定的條件；經常使用於在指定backend上的會話速率太高時將用戶請求轉發至另外的backend，或用於阻止***行爲。

例如：

    backend dynamic

        mode http

        acl being_scanned be_sess_rate gt 50

        redirect location/error_pages/denied.html if being_scanned

二、fe_sess_rate<integer>

  fe_sess_rate<integer>

fe表明frontend

用於測試指定的frontend(或當前frontend)上的會話建立速率是否知足指定的條件；經常使用於爲frontend指定一個合理的會話建立速率的上限以防止服務被濫用。例以下面的例子限定入站郵件速率不能大於50封/秒，全部在此指定範圍以外的請求都將被延時50毫秒。

例如：

    frontend mail

        bind :25

        mode tcp

        maxconn 500

        acl too_fast fe_sess_rate gt 50

        tcp-request inspect-delay 50ms

        tcp-request content accept if !too_fast

        tcp-request content accept if WAIT_END

3 、hdr <string>

hdr(header)<string>

用於測試請求報文中的全部首部或指定首部是否知足指定的條件；指定首部時，其名稱不區分大小寫，且在括號「()」中不能有任何多餘的空白字符。測試服務器端的響應報文時可使用hdr()。

例以下面的例子用於測試首部Connection的值是否爲close：

    hdr(Connection) -i close

4 、method<string>

method<string>

測試HTTP請求報文中使用的方法。

5 、path_beg<string>

用於測試請求的URL是否以<string>指定的模式開頭。下面的例子用於測試URL是否以/static、/p_w_picpaths、/javascript或/stylesheets頭。

    acl url_static       path_beg       -i /static /p_w_picpaths /javascript/stylesheets

六、 path_end<string>

用於測試請求的URL是否以<string>指定的模式結尾。例如，下面的例子用戶測試URL是否以jpg、gif、png、css或js結尾。

    acl url_static       path_end       -i .jpg .gif .png .css .js

7 、hdr_beg<string>

用於測試請求報文的指定首部的開頭部分是否符合<string>指定的模式。例如，下面的例子用記測試請求是否爲提供靜態內容的主機img、video、download或ftp。

    acl host_static hdr_beg(host) -i img.video. download. ftp.

8 、hdr_end<string>

用於測試請求報文的指定首部的結尾部分是否符合<string>指定的模式。例如，下面的例子用記測試請求是否爲

還經常使用到：

url_beg<string>：url以<string>開頭的

url_end<string>：url以<string>結尾的

path_reg：支持正則表達式

url_reg：支持正則表達式

 

示例：動靜分離；基於lamp部署discuz，而動靜分離；CentOS7上實現

 

首前後端的web服務器，要搭建好lamp，安裝httpd  php  php-mysql mariadb-server

而後啓動httpd

而後使用httpd  –M查看php模塊是否啓動只要有這一句php5_module(shared)就能夠了，而後在httpd配置文件中這個詞DirectoryIndex後面加上  index.php

而後在一個web服務器上打開mariadb服務，而後建立數據庫（dcdb）配置受權

在/etc/my.cnf中要加入skip_name_resolve = no，是爲了防止反解的

grant all on dcdb.* to 'dcuser'@'172.16.%.%'identified by 'passwd';

而後在其餘主機上遠程鏈接測試下，能連上就好了

而後在web服務器上設置測試夜，看php和mysql鏈接是否是正常，要肯定selinx 和iptables是關閉的

而後解壓Discuz，而後複製upload到/var/www/html中，而後修改屬組屬主爲apache，權限766，而後外面打開，而後配置數據庫，安裝，再把後端的一個web服務器的upload複製給另外一臺，而後作動靜分離

在haproxy配置文件中配置以下：

    frontend http-in

       bind *:80

       mode http

       log global

       option httpclose

       option logasap

       option dontlognull

       capture request  header Host len20

       capture request  header Refererlen 60

       acl url_static   path_beg    -i /static /p_w_picpaths /javascript/stylesheets

       acl url_static    path_end   -i .jpg .jpeg .gif .png .css .js

     

       use_backend static_servers      if url_static

       default_backend dynamic_servers

     

    backend static_servers

       balance roundrobin

    server imgsrv1 172.16.249.115:80check maxconn 6000

    server imgsrv1172.16.249.116:80 check maxconn 6000

     

    backend dynamic_servers

           cookie srv insert nocache

       balance roundrobin

    server websrv1172.16.249.159:80 check maxconn 1000 cookie websrv1

    server websrv1172.16.249.160:80 check maxconn 1000 cookie websrv1

 

這樣重載服務，而後訪問，就沒問題了

而後查看後端主機的日誌，會發現動靜分離了

示例：實現keepalived+haproxy

    haproxy的配置如上，要用兩臺主機作haproxy，而後在兩臺haproxy主機上安裝keepalived程序，而後修改配置文件以下：

 一臺haproxy主機上的keepalived配置以下：    

    global_defs {

      notification_email {

             root@localhost

       }

      notification_email_from kaadmin@localhost

      smtp_server 127.0.0.1

      smtp_connect_timeout 30

      router_id centos7

    }

    vrrp_script chk_nginx {

       script "killall -0 haproxy &> /dev/null"

       interval 1

       weight -10

        }

     

    vrrp_instance VI_1 {

       state MASTER

       interface eth0

       virtual_router_id 51

       priority 100

        advert_int 1

       authentication {

           auth_type PASS

           auth_pass 6b03429a7cf5

        }

       virtual_ipaddress {

             172.16.249.18/16 dev eth0 label eth0:0

        }

       track_script {

              chk_nginx

        }

       notify_master "/etc/keepalived/notify.sh master"

       notify_backup "/etc/keepalived/notify.sh backup"

       notify_fault "/etc/keepalived/notify.sh fault

    }

 

 另外一臺haproxy主機上的keepalived配置文件爲

    global_defs {

      notification_email {

             root@localhost

       }

      notification_email_from kaadmin@localhost

      smtp_server 127.0.0.1

      smtp_connect_timeout 30

      router_id centos71

    }

     

    vrrp_script chk_nginx {

       script "killall -0 haproxy &> /dev/null"

       interval 1

       weight -10

        }

     

    vrrp_instance VI_1 {

       state BACKUP

       interface eth0

       virtual_router_id 51

       priority 99

       advert_int 1

       authentication {

           auth_type PASS

           auth_pass 6b03429a7cf5

        }

       virtual_ipaddress {

             172.16.249.18/16 dev eth0 label eth0:0

        }

      track_script {

             chk_nginx

        }

       notify_master "/etc/keepalived/notify.sh master"

       notify_backup "/etc/keepalived/notify.sh backup"

       notify_fault "/etc/keepalived/notify.sh fault"

     

    }

而後啓動測試就好了