HAproxy 安裝配置

HAproxy 安裝配置

yum -y install haproxy

mv /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak

cat << EOF > /etc/haproxy/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

defaults
    mode                    tcp
    log                     global
    retries                 3
    timeout connect         10s
    timeout client          1m
    timeout server          1m

frontend kube-apiserver
    bind *:4443 # 指定前端端口
    mode tcp
    default_backend master

backend master # 指定後端機器及端口,負載方式爲輪詢
    balance roundrobin
    server master-1  192.168.6.184:6443 check maxconn 2000
    server master-2  192.168.6.185:6443 check maxconn 2000
    server master-3  192.168.6.186:6443 check maxconn 2000
EOF

systemctl start haproxy
systemctl enable haproxy
systemctl status haproxy

參數詳解

global      #全局設置
        maxconn         10000   #最大連接數
        stats socket    /var/run/haproxy.stat mode 600 level admin
        log             127.0.0.1 local0   #日誌輸出配置,所有日誌都記錄在本機,通過local0輸出
        uid             200   #所屬運行的用戶uid
        gid             200   #所屬運行的用戶組
        chroot          /var/empty
        daemon   #以後臺形式運行haproxy
maxconn conns
設定一個前端的最大併發連接數,因此其不能用於backend區段。對於大型站點來說,可以儘可能提高此值以便 讓haproxy管理連接隊列,從而避免無法應答用戶請求。當然,此最大值不能超出“global”段中的定義。此外,需要留心的是,haproxy會爲 每個連接維持兩個緩衝,每個緩衝的大小爲8KB,再加上其它的數據,每個連接將大約佔用17KB的RAM空間。這意味着經過適當優化後,有着1GB的可用 RAM空間時將能維護40000-50000併發連接。
如果爲conns指定了一個過大值,極端場景下,其最終佔據的空間可能會超出當前主機的可用內存,這可能會帶來意想不到的結果;因此,將其設定了一個可接受值方爲明智決定。其默認爲2000。

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:定義日誌級別,即輸出信息過濾器,默認爲所有信息;指定級別時,所有等於或高於此級別的日誌信息將會被髮送;
defaults      #默認設置
        mode            http   #工作模式,支持TCP、http、health
        log             global   #使用global的日誌
        option          httplog    #啓用HTTP請求,會話狀態和計時器的日誌記錄
        option          dontlognull   #啓用空連接不記錄日誌
        monitor-uri     /monitoruri   
        maxconn         8000   #設置最大套接字連接數
        timeout client  30s   #設置客戶端的最長不活動時間
        retries         2   #2次連接失敗就認爲服務器不可用,主要通過後面的check檢查
        option redispatch   #當serverid對應的服務器掛掉後,強制定向到其他健康服務器
        timeout connect 5s   #設置等待連接嘗試到服務器成功的最長時間。
        timeout server  30s   #設置服務器端的最長不活動時間。
        timeout queue   30s    #設置隊列中等待連接池空閒的最長時間
        stats uri       /admin/stats   #haproxy 監控頁面的訪問地址
        stats auth      admin:westos   #設置監控頁面的用戶和密碼
        stats refresh   5s   
mode { tcp|http|health } 設定實例的運行模式或協議。當實現內容交換時,前端和後端必須工作於同一種模式(一般說來都是HTTP模式),否則將無法啓動實例。

tcp:實例運行於純TCP模式,在客戶端和服務器端之間將建立一個全雙工的連接,且不會對7層報文做任何類型的檢查;此爲默認模式,通常用於SSL、SSH、SMTP等應用;

http:實例運行於HTTP模式,客戶端請求在轉發至後端服務器之前將被深度分析,所有不與RFC格式兼容的請求都會被拒絕;

health:實例工作於health模式,其對入站請求僅響應“OK”信息並關閉連接,且不會記錄任何日誌信息;此模式將用於響應外部組件的健康狀態檢查請求;目前業講,此模式已經廢棄,因爲tcp或http模式中的monitor關鍵字可完成類似功能;
frontend public       #前臺
        bind            *:80 name clear
        default_backend dynamic
use_backend: 調用指定的後端主機(定義在frontend和listen中);
語法: use_backend backend [{if | unless} condition]

condition 條件多爲acl的名稱

default_backend: 默認調用的後端主機;
語法:default_backend backend
backend dynamic      #後臺
        balance         roundrobin   #負載均衡算法(輪循)
        server          web2 172.25.83.3:80  check inter 1000
        server          web2 172.25.83.3:80  check inter 1000
 
#check inter 1500 是檢測心跳頻率
balance 定義負載均衡算法(可用於“defaults”和“backend”)。
語法:balance algorithm [ arguments ]
algorithm用於在負載均衡場景中挑選一個server,其僅應用於持久信息不可用的條件下或需要將一個連接重新派發至另一個服務器時。
支持的算法有:

roundrobin:基於權重進行輪叫,在服務器的處理時間保持均勻分佈時,這是最平衡、最公平的算法。此算法是動態的,這表示其權重可以在運行時進行調整,不過,在設計上,每個後端服務器僅能最多接受4128個連接;

static-rr:基於權重進行輪叫,與roundrobin類似,但是爲靜態方法,在運行時調整其服務器權重不會生效;不過,其在後端服務器連接數上沒有限制;

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

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

name:爲此服務器指定的內部名稱,其將出現在日誌及警告信息中;如果設定了"http-send-server-name",它還將被添加至發往此服務器的請求首部中;

address:此服務器的的IPv4地址,也支持使用可解析的主機名,只不過在啓動時需要解析主機名至相應的IPv4地
址;

param:爲此服務器設定的一系參數;其可用的參數非常多,具體請參考官方文檔中的說明,下面僅說明幾個常用的參數:
disabled:此服務器禁用;

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:設定請求隊列的最大長度;0表示無上限;

weight weight:權重,默認爲1,最大值爲256,0表示不參與負載均衡;
發佈了115 篇原創文章 · 獲贊 5 · 訪問量 1萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章