Linux集羣之haproxy簡介及應用

時間  2020-09-14
標籤 linux 集羣 haproxy 簡介 應用 欄目 Linux 简体版
原文   原文鏈接


1、haproyx簡介javascript

  HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，它是免費、快速而且可靠的一種解決方案。HAProxy特別適用於那些負載特大的web站點，這些站點一般又須要會話保持或七層處理。HAProxy運行在時下的硬件上，徹底能夠支持數以萬計的併發鏈接。而且它的運行模式使得它能夠很簡單安全的整合進您當前的架構中，同時能夠保護你的web服務器不被暴露到網絡上。php

 

  HAProxy實現了一種事件驅動、單一進程模型，此模型支持很是大的併發鏈接數。多進程或多線程模型受內存限制、系統調度器限制以及無處不在的鎖限制，不多能處理數千併發鏈接。事件驅動模型由於在有更好的資源和時間管理的用戶端(User-Space)實現全部這些任務，因此沒有這些問題。此模型的弊端是，在多核系統上，這些程序一般擴展性較差。這就是爲何他們必須進行優化以 使每一個CPU時間片(Cycle)作更多的工做。css

 

  HAProxy是免費、極速且可靠的用於爲TCP和基於HTTP應用程序提供高可用、負載均衡和代理服務的解決方案，尤爲適用於高負載且須要持久鏈接或7層處理機制的web站點。html

 

2、haproxy工做位置前端

wKiom1V8_HnQ4xBpAANJONWYLCo097.bmp

 

3、haproxy安裝及配置文件詳解java

3.1 安裝haproxynode

  在CentOS 6.6 系統中HAProxy已經被收錄在安裝樹中了，在配置好yum源以後直接使用yum install haproxy就能實現安裝。web

yum install haproxy  -yredis

3.2 haproxy配置文件詳解算法

  在安裝完haproxy程序以後使用rpm-ql haproxy查看安裝完所生成的文件，生成的文件比較的少，haproxy的配置文件在/etc/haproxy/haproxy.cfg。

[root@node-04 haproxy]# egrep -v"#|^$" haproxy.cfg 
global      #全局配置
   log         127.0.0.1 local2    #日誌文件存放路徑，指明爲syslog服務器，最多能夠定義兩個
   chroot      /var/lib/haproxy    #haproxy的工做目錄
   pidfile     /var/run/haproxy.pid    #pid文件存放位置
   maxconn     4000                #設定每一個haproxy進程所接受的最大併發鏈接數，其等同於命令行選項「-n」；「ulimit -n」自動計算的結果正是參照此參數設定的；
   user        haproxy     #指定haproxy身份運行haproxy程序
   group       haproxy     #指定haproxy組身份運行haproxy程序
   daemon          #讓haproxy以守護進程的方式工做於後臺，其等同於「-D」選項的功能，固然，也能夠在命令行中以「-db」選項將其禁用；
   stats socket /var/lib/haproxy/stats #指明haproxy運行時socket文件存放位置
defaults    #提供frontend、backend、listen的公共配置信息段
   mode                    http    #haproxy的工做模式，有tcp和http
   log                     global  #日誌文件從global承繼
   option                  httplog #啓動記錄http請求、會話狀態和計時器的功能
   option                  dontlognull #不記錄空日誌
   option http-server-close        #啓動和禁用服務器端關閉HTTP鏈接的功能，服務器鏈接關閉功能主要是在長鏈接上使用；
   option forwardfor       except127.0.0.0/8  #容許在發往服務器的請求首部中插入「X-Forwarded-For」首部
   option                  redispatch      #開啓或禁用若是某一個鏈接發生了錯誤是否是須要重啓調度；
   retries                 3       #重次次數
   timeout http-request    10s     #等待客戶端發送報文超時時長
   timeout queue           1m      #鏈接隊列等待的超時時長
   timeout connect         10s     #等待上游服務器響應haproxy發送報文過程的超時時間
   timeout client          1m      
   timeout server          1m
   timeout http-keep-alive 10s     #設置保護鏈接的超時時間
   timeout check           10s     #設置健康狀態額外的超時時間
   maxconn                 3000    #設定一個前端的最大併發鏈接數，所以，其不能用於backend區段。
frontend main *:5000   #用於定義一系列監聽的套接字，這些套接字可接受客戶端請求並與之創建鏈接。
   acl url_static       path_beg       -i /static /p_w_picpaths /javascript/stylesheets #定義一個ACL規則
   acl url_static       path_end       -i .jpg .gif .png .css .js
   use_backend static          ifurl_static   #匹配ACL規則的將會使用「static」的後端服務器
   default_backend             app         #在沒有匹配的"use_backend"規則時爲實例指定使用的默認後端
backend static  #用於定義一系列「後端」服務器，代理將會將對應客戶端的請求轉發至這些服務器。
   balance     roundrobin      #定義負載均衡調度算法
   server      static 127.0.0.1:4331check #爲後端聲明一個server，所以，不能用於defaults和frontend區段。「check」表示作健康狀態檢查
backend app
   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


3.3 負載均衡調度算法

類型 說明
roundrobin 基於權重進行輪叫，在服務器的處理時間保持均勻分佈時，這是最平衡、最公平的算法。此算法是動態的，這表示其權重能夠在運行時進行調整，不過，在設計上，每一個後端服務器僅能最多接受4128個鏈接；

static-rr

 基於權重進行輪叫，與roundrobin相似，可是爲靜態方法，在運行時調整其服務器權重不會生效；不過，其在後端服務器鏈接數上沒有限制；

leastconn

 新的鏈接請求被派發至具備最少鏈接數目的後端服務器；在有着較長時間會話的場景中推薦使用此算法，如LDAP、SQL等，其並不太適用於較短會話的應用層協議，如HTTP；此算法是動態的，能夠在運行時調整其權重；

source

 將請求的源地址進行hash運算，並由後端服務器的權重總數相除後派發至某匹配的服務器；這可使得同一個客戶端IP的請求始終被派發至某特定的服務器；不過，當服務器權重總數發生變化時，如某服務器宕機或添加了新的服務器，許多客戶端的請求可能會被派發至與此前請求不一樣的服務器；經常使用於負載均衡無cookie功能的基於TCP的協議；其默認爲靜態，不過也可使用hash-type修改此特性；

uri

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

url_param

 經過<argument>爲URL指定的參數在每一個HTTP GET請求中將會被檢索；若是找到了指定的參數且其經過等於號「=」被賦予了一個值，那麼此值將被執行hash運算並被服務器的總權重相除後派發至某匹配的服務器；此算法能夠經過追蹤請求中的用戶標識進而確保同一個用戶ID的請求將被送往同一個特定的服務器，除非服務器的總權重發生了變化；若是某請求中沒有出現指定的參數或其沒有有效值，則使用輪叫算法對相應請求進行調度；此算法默認爲靜態的，不過其也可使用hash-type修改此特性；
hdr(<name>) 對於每一個HTTP請求，經過<name>指定的HTTP首部將會被檢索；若是相應的首部沒有出現或其沒有有效值，則使用輪叫算法對相應請求進行調度；其有一個可選選項「use_domain_only」，可在指定檢索相似Host類的首部時僅計算域名部分(好比經過www.magedu.com來講，僅計算magedu字符串的hash值)以下降hash算法的運算量；此算法默認爲靜態的，不過其也可使用hash-type修改此特性；


4、haproxy配置實踐之啓動haproxy狀態統計報告頁面

4.1 啓動haproxy狀態統計報告

  haproxy的狀態統計報告的功能很是的強大，能夠標記後端服務器不可用，所以應該監聽在一個內網地址的特定端口上，在訪問此頁面時要進行認證，認證成功才能訪問。

在haproxy.cfg配置文件中添加以下內容：

listen stats
    mode http
    bind 172.16.9.84:7009
    stats enable
    stats hide-version
    stats uri   /haproxyadmin?stats
    stats realm HAProxy\Statistics
    stats auth  admin:admin
    stats admin if  TRUE


4.2 解釋狀態統計報告段配置信息

listen stats   

    modehttp

    bind172.16.9.84:7009   #監聽在指定的套接字上

    statsenable         #開啓狀態統計報告

    statshide-version     #隱藏狀態統計報告中的haproxy版本信息

    statsuri   /haproxyadmin?stats #指定狀態統計報告的訪問URI地址

    statsrealm HAProxy\ Statistics #認證時的提示信息，空格要使用「\」進行轉意

    statsauth  admin:admin     #認證時的用戶名：密碼

    statsadmin if  TRUE        #在指定的條件知足時啓用統計報告頁面的管理級別功能，它容許經過web接口啓用或禁用服務器，不過，基於安全的角度考慮，統計報告頁面應該儘量爲只讀的。


4.3 啓動haproxy

[root@node-04 ~]# service haproxy start
Starting haproxy:                               [  OK  ]


4.4 檢查監聽端口

[root@node-04 ~]# ss -tanp|grep 7009
LISTEN    0      128           172.16.9.84:7009             *:*      users:(("haproxy",1465,7))


4.5 訪問測試

  在瀏覽器中輸入http://172.16.9.84:7009/haproxyadmin?stats進行訪問，在認證成功後的頁面以下

wKiom1V8_byDsiXVAAwH4M_jCY8906.bmp

 

5、haproxy配置實踐之負載均衡Web服務

  用戶請求haproxy反向代理服務器，實現負載均衡的效果，你也能夠根據上面的調度算法根據業務的需求進行調整，實驗拓撲；

wKioL1V8_4ChWkiKAAML2ON1uYc013.bmp

5.1 haproxy節點的配置內容

[root@node-04 haproxy]# egrep -v"#|^$" haproxy.cfg 
global
   log         127.0.0.1 local2
   chroot      /var/lib/haproxy
   pidfile     /var/run/haproxy.pid
   maxconn     4000
   user        haproxy
   group       haproxy
   daemon
   stats socket /var/lib/haproxy/stats
defaults
   mode                    http
   log                     global
   option                  httplog
   option                 dontlognull
   option http-server-close
   option forwardfor       except127.0.0.0/8
   option                  redispatch
   retries                 3
   timeout http-request    10s
   timeout queue           1m
   timeout connect         10s
   timeout client          1m
   timeout server          1m
   timeout http-keep-alive 10s
   timeout check           10s
   maxconn                 3000
frontend main *:80
   default_backend            websrvs
listen stats
    modehttp
    bind172.16.9.84:7009
    statsenable
    statshide-version
    statsuri   /haproxyadmin?stats
    statsrealm HAProxy\ Statistics
    statsauth  admin:admin
    statsadmin if  TRUE
backend websrvs
   balance     roundrobin
   server  web1 172.16.9.81:8080check 
   server  web2 172.16.9.83:8080check


5.2 各Web節點的測試頁面的內容

Web節點監聽在8080的端口上，如節點的測試頁面以下:

Web-01節點測試頁面：

<h1>Real Server node-01</h1>


Web-02節點測試頁面：

<h1>Real Server node-02</h1>


5.3 從新加載haproxy的配置信息

service haproxy reload


5.4 訪問測試

在瀏覽器http://172.16.9.84中訪問或使用curl命令進行測試，將會出現輪詢的效果

[root@node-04 haproxy]# curlhttp://172.16.9.84
<h1>Real Server node-01</h1>
[root@node-04 haproxy]# curlhttp://172.16.9.84
<h1>Real Server node-02</h1>


 

6、haproxy配置實踐之基本Cookie綁定會話

  在上面的配置中實現的在訪問Web服務器時能輪詢的訪問後端服務器，但在特定的場景中有時須要將用戶的會話保持至同一臺後端服務器時，就可使用基本Cookie的會話綁定。

  cookie爲當客戶端第一次訪問服務器時，服務器生成一個隨機的cookie，爲此用戶會話使用，用戶瀏覽器收到cookie信息之後，將會保存在本身瀏覽器緩存中，然後在向同一個站點請求任何資源時都會附加會話標識信息。

  haproxy的cookie參數，是用於客戶端在後端的upstream服務器端之間通訊時，若是upstream 設置了cookie給客戶端的話，haproxy是將會修改、添加在原有cookie的基礎上附加一些信息上去，以實現基本haproxy來追蹤客戶端的通訊信息

6.1 修改haproxy.cfg文件中backned段的代碼

backend websrvs
   balance     roundrobin
   cookie WEBID insert indirect nocache
   server  web1 172.16.9.81:8080check cookie web1
   server  web2 172.16.9.83:8080check cookie web2


6.2 配置信息解釋

cookie WEBID insert indirect nocache

  啓用基於cookie後端服務器黏性的功能，insert表示內插方式去將當前haproxy調度出來的WEBID信息插入到客戶端的cookie信息中去，並通知不要緩存用戶的敏感信息。

  若是用戶請求時第一次被調度至web1服務器，web1會回一個cookie信息給客戶端，haproxy會把web1這個服務器本身的WEBID附加在cookie上，當客戶端第二次請求發出web資源請求時，haproxy經過分析就知道此前就是由web1這臺服務器響應的，因此haproxy就把此請求定向至web1。這樣haproxy就能追蹤此前每個server做出的響應。

6.3 訪問測試

  在瀏覽器中按F12打開開發人員工具，進行查看Cookie的信息，在瀏覽器輸入http://172.16.9.84/，當再次刷新時就被定位至同一臺RealServer了，查看Cookie信息中包含了在HAProxy插入的WEBID=XX的HTTP首部請求信息。

Cookie:pma_lang=zh_CN;pma_collation_connection=utf8_general_ci; pma_mcrypt_iv=fmN5yE3kUyc%3D;WEBID=web1


 

7、haproxy配置實踐之動靜分離

  當客戶端請求靜態資源時haproxy將輪詢的把用戶的請求調度至後端服務器，請求的動態資源將調度至Web-02服務器上。

7.1 實驗拓撲

wKioL1V8_6SDkHGIAAML2Gk7W6U098.bmp

7.2 haproxy的配置信息

[root@node-04 haproxy]# egrep -v"#|^$" haproxy.cfg 
global
   log         127.0.0.1 local2
   chroot      /var/lib/haproxy
   pidfile     /var/run/haproxy.pid
   maxconn     4000
   user        haproxy
   group       haproxy
   daemon
   stats socket /var/lib/haproxy/stats
defaults
   mode                    http
   log                     global
   option                  httplog
   option                 dontlognull
   option http-server-close
   option forwardfor       except127.0.0.0/8
   option                  redispatch
   retries                 3
   timeout http-request    10s
   timeout queue           1m
   timeout connect         10s
   timeout client          1m
   timeout server          1m
   timeout http-keep-alive 10s
   timeout check           10s
   maxconn                 3000
frontend main *:80
   acl url_dy       path_end       -i .php     #ACL規則，以.php結尾的URL將會被匹配
   use_backend dy          if url_dy       #匹配成功的將會調用「dy」後端服務器組
   default_backend            websrvs
listen stats
    modehttp
    bind172.16.9.84:7009
    statsenable
    statshide-version
    statsuri   /haproxyadmin?stats
    statsrealm HAProxy\ Statistics
    statsauth  admin:admin
    statsadmin if  TRUE
backend dy
   balance     roundrobin
   server      static172.16.9.83:8080 check
backend websrvs
   balance     roundrobin
   server  web1 172.16.9.81:8080check
   server  web2 172.16.9.83:8080check


7.3 後端服務器節點http頁面內容

web-01節點的內容

[root@node-01 html]# cat index.htmlindex.php
<h1>Html Static Web-01</h1>
<h1>Real Server node-01</h1>


web-02節點的內容

[root@node-03 html]# cat index.htmlindex.php
<h1>Html Static Web-02</h1>
<h1>Real Server node-02</h1>


7.4 從新加載haproxy配置文件

service haproxy reload


7.5 訪問測試

使用curl命令訪問測試，靜態資源的訪問，將會出現輪詢的效果：

[root@node-04 ~]# curl http://172.16.9.84/index.html
<h1>Html Static Web-01</h1>
[root@node-04 ~]# curlhttp://172.16.9.84/index.html
<h1>Html Static Web-02</h1>


使用curl命令訪問測試，動態資源的訪問，將會始終調度至同一臺後端服務器的效果：

[root@node-04 ~]# curlhttp://172.16.9.84/index.php
<h1>Real Server node-02</h1>
[root@node-04 ~]# curl http://172.16.9.84/index.php
<h1>Real Server node-02</h1>


 

小結：

  haproxy的功能還遠遠不至上面列出的這些，更詳細的內容請參考官方文檔。

  haproxy的鏈接數是受套接字數量的限制，因此併發數量有限，在haproxy的前端能夠加一個LVS，在LVS後一個haproxy的集羣，經過LVS調度至不一樣的haproxy服務器上，以實現高併發的場景。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程