haproxy配置文件解釋html
####################全局配置信息######################## 前端 #######參數是進程級的,一般和操做系統(OS)相關######### mysql global nginx log 127.0.0.1 local0 info #日誌格式web chroot /var/haproxy #chroot運行的路徑 redis group haproxy #所屬運行的用戶算法 user haproxy #所屬運行的用戶 sql daemon #之後臺進程形式運行haproxyapache nbproc 8 #進程數量(能夠設置多個進程提升性能) 後端 pidfile /var/run/haproxy #PID文件所在位置
#####################默認的全局設置###################### ##這些參數能夠被利用配置到frontend,backend,listen組件## defaults log global #應用全局日誌格式 maxconn 20480 #默認最大鏈接數 option httplog #日誌類別http日誌格式 option httpclose #每次請求完畢後主動關閉http通道 option dontlognull #不記錄健康檢查的日誌信息 option forwardfor #若是後端服務器須要得到客戶端真實ip須要配置的參數,能夠從Http Header中得到客戶端ip option redispatch #serverId對應的服務器掛掉後,強制定向到其餘健康的服務器 option abortonclose #當服務器負載很高的時候,自動結束掉當前隊列處理比較久的鏈接
retries 3 #3次鏈接失敗就認爲服務不可用,也能夠經過後面設置 balance roundrobin #默認的負載均衡的方式,輪詢方式 #balance source #默認的負載均衡的方式,相似nginx的ip_hash #balance leastconn #默認的負載均衡的方式,最小鏈接 contimeout 5000 #鏈接超時 clitimeout 50000 #客戶端超時 srvtimeout 50000 #服務器超時 timeout check 2000 #心跳檢測超時
####################監控頁面的設置####################### listen admin_status #Frontend和Backend的組合體,監控組的名稱,按需自定義名稱 bind * mode http #http的7層模式 stats refresh 5s #每隔5秒自動刷新監控頁面 stats uri /admin?status #監控頁面的url stats realm haproxty\ haproxy #監控頁面的提示信息 stats auth admin:admin #監控頁面的用戶和密碼admin,能夠設置多個用戶名 stats auth admin1:admin1 #監控頁面的用戶和密碼admin1 stats hide-version #隱藏統計頁面上的HAproxy版本信息 stats admin if TRUE #手工啓用/禁用,後端服務器(haproxy-1 listen webserver bind 172.16.254.30:80 #客戶端訪問的外網IP,若和heartbeat結合使用的話即VIP mode http #模式爲http option httpchk HEAD /checkstatus.html HTTP/1.0 #url健康檢查 balance roundrobin #調度算法爲輪訓 server web1 192.168.254.10:80 check server web2 192.168.254.20:80 check |
「global」配置中的參數爲進程級別的參數,且一般與其運行的OS相關。
- chroot <jail dir>:修改haproxy的工做目錄至指定的目錄並在放棄權限以前執行chroot()操做,能夠提高haproxy的安全級別,不過須要注意的是要確保指定的目錄爲空目錄且任何用戶均不能有寫權限;
- daemon:讓haproxy以守護進程的方式工做於後臺,其等同於「-D」選項的功能,固然,也能夠在命令行中以「-db」選項將其禁用;
- gid <number>:以指定的GID運行haproxy,建議使用專用於運行haproxy的GID,以避免因權限問題帶來風險;
- group <group name>:同gid,不過指定的組名;
- log <address> <facility> [max level[min level]]:定義全局的syslog服務器,最多能夠定義兩個;
- log-send-hostname[<string>]:在syslog信息的首部添加當前主機名,能夠爲「string」指定的名稱,也能夠缺省使用當前主機名;
- nbproc <number>:指定啓動的haproxy進程個數,只能用於守護進程模式的haproxy;默認只啓動一個進程,鑑於調試困難等多方面的緣由,通常只在單進程僅能打開少數文件描述符的場景中才使用多進程模式;
- pidfile:指定進程號文件的位置
- uid:以指定的UID身份運行haproxy進程;
- ulimit-n:設定每進程所可以打開的最大文件描述符數目,默認狀況下其會自動進行計算,所以不推薦修改此選項;
- user:同uid,但使用的是用戶名;
- description:當前實例的描述信息;
- maxconn<number>:設定每一個haproxy進程所接受的最大併發鏈接數,其等同於命令行選項「-n」;「ulimit -n」自動計算的結果正是參照此參數設定的;
- maxpipes<number>:haproxy使用pipe完成基於內核的tcp報文重組,此選項則用於設定每進程所容許使用的最大pipe個數;每一個pipe會打開兩個文件描述符,所以,「ulimit -n」自動計算時會根據須要調大此值;默認爲maxconn/4,其一般會顯得過大;
- noepoll:在Linux系統上禁用epoll機制;
- nokqueue:在BSE系統上禁用kqueue機制;
- nopoll:禁用poll機制;
- nosepoll:在Linux禁用啓發式epoll機制;
- nosplice:禁止在Linux套接字上使用內核tcp重組,這會致使更多的recv/send系統調用;不過,在Linux 2.6.25-28系列的內核上,tcp重組功能有bug存在;
- spread-checks<0..50, in percent>:在haproxy後端有着衆多服務器的場景中,在精確的時間間隔後統一對衆服務器進行健康情況檢查可能會帶來意外問題;此選項用於將其檢查的時間間隔長度上增長或減少必定的隨機時長;
- tune.bufsize<number>:設定buffer的大小,一樣的內存條件小,較小的值可讓haproxy有能力接受更多的併發鏈接,較大的值可讓某些應用程序使用較大的cookie信息;默認爲16384,其能夠在編譯時修改,不過強烈建議使用默認值;
- tune.chksize<number>:設定檢查緩衝區的大小,單位爲字節;更大的值有助於在較大的頁面中完成基於字符串或模式的文本查找,但也會佔用更多的系統資源;不建議修改;
- tune.maxaccept<number>:設定haproxy進程內核調度運行時一次性能夠接受的鏈接的個數,較大的值能夠帶來較大的吞吐率,默認在單進程模式下爲100,多進程模式下爲8,設定爲-1能夠禁止此限制;通常不建議修改;
-tune.maxpollevents <number>:設定一次系統調用能夠處理的事件最大數,默認值取決於OS;其值小於200時可節約帶寬,但會略微增大網絡延遲,而大於200時會下降延遲,但會稍稍增長網絡帶寬的佔用量;
- tune.maxrewrite<number>:設定爲首部重寫或追加而預留的緩衝空間,建議使用1024左右的大小;在須要使用更大的空間時,haproxy會自動增長其值;
- tune.rcvbuf.client<number>:
- tune.rcvbuf.server<number>:設定內核套接字中服務端或客戶端接收緩衝的大小,單位爲字節;強烈推薦使用默認值;
- tune.sndbuf.client:
- tune.sndbuf.server:
- debug
- quiet
代理相關的配置能夠以下配置段中
- defaults <name>
- frontend <name>
- backend <name>
- listen <name>
「defaults」段用於爲全部其它配置段提供默認參數,這配置默認配置參數可由下一個「defaults」所從新設定。
「frontend」段用於定義一系列監聽的套接字,這些套接字可接受客戶端請求並與之創建鏈接。
「backend」段用於定義一系列「後端」服務器,代理將會將對應客戶端的請求轉發至這些服務器。
「listen」段經過關聯「前端」和「後端」定義了一個完整的代理,一般只對TCP流量有用。
全部代理的名稱只能使用大寫字母、小寫字母、數字、-(中線)、_(下劃線)、.(點號)和:(冒號)。此外,ACL名稱會區分字母大小寫。
balance:定義負載均衡算法。可用於「defaults」、「listen」和「backend」
支持的算法有:
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修改此特性;
rdp-cookie主要對rdp協議作負載均衡
rdp-cookie(name):主要對rdp協議作負載均衡
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系統上使用;其不能使用接口別名,而僅能使用物理接口名稱,並且只有管理有權限指定綁定的物理接口;
mode:設定實例的運行模式或協議。當實現內容交換時,前端和後端必須工做於同一種模式(通常說來都是HTTP模式),不然將沒法啓動實例。
mode { tcp|http|health }
tcp:實例運行於純TCP模式,在客戶端和服務器端之間將創建一個全雙工的鏈接,且不會對7層報文作任何類型的檢查;此爲默認模式,一般用於SSL、SSH、SMTP等應用;
http:實例運行於HTTP模式,客戶端請求在轉發至後端服務器以前將被深度分析,全部不與RFC格式兼容的請求都會被拒絕;
health:實例工做於health模式,其對入站請求僅響應「OK」信息並關閉鏈接,且不會記錄任何日誌信息;此模式將用於響應外部組件的健康狀態檢查請求;目前業講,此模式已經廢棄,由於tcp或http模式中的monitor關鍵字可完成相似功能;
log:定義haproxy日誌
log global
log <address> <facility>[<level> [<minlevel>]]
爲每一個實例啓用事件和流量日誌,所以可用於全部區段。每一個實例最多能夠指定兩個log參數,不過,若是使用了「log global」且"global"段已經定了兩個log參數時,多餘了log參數將被忽略。
global:當前實例的日誌系統參數同"global"段中的定義時,將使用此格式;每一個實例僅能定義一次「logglobal」語句,且其沒有任何額外參數;
<address>:定義日誌發往的位置,其格式之一能夠爲<IPv4_address:PORT>,其中的port爲UDP協議端口,默認爲514;格式之二爲Unix套接字文件路徑,但須要留心chroot應用及用戶的讀寫權限;
<facility>:能夠爲syslog系統的標準facility之一;
<level>:定義日誌級別,即輸出信息過濾器,默認爲全部信息;指定級別時,全部等於或高於此級別的日誌信息將會被髮送;
maxconn:設定最大併發鏈接數
其不能用於backend區段。對於大型站點來講,能夠儘量提升此值以便讓haproxy管理鏈接隊列,從而避免沒法應答用戶請求。固然,此最大值不能超出「global」段中的定義。此外,須要留心的是,haproxy會爲每一個鏈接維持兩個緩衝,每一個緩衝的大小爲8KB,再加上其它的數據,每一個鏈接將大約佔用17KB的RAM空間。這意味着通過適當優化後,有着1GB的可用RAM空間時將能維護40000-50000併發鏈接。
若是爲<conns>指定了一個過大值,極端場景下,其最終佔據的空間可能會超出當前主機的可用內存,這可能會帶來意想不到的結果;所以,將其設定了一個可接受值方爲明智決定。其默認爲2000。
default_backend:默認的響應請求的後端
default_backend<backend>
在沒有匹配的"use_backend"規則時爲實例指定使用的默認後端,所以,其不可應用於backend區段。在"frontend"和"backend"之間進行內容交換時,一般使用"use-backend"定義其匹配規則;而沒有被規則匹配到的請求將由此參數指定的後端接收。
<backend>:指定使用的後端的名稱;
server指定後端RS,不能用於defaults和frontend區段
server<name> <address>[:port] [param*]
<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 srv1172.16.100.6:80 redir http://p_w_picpathserver.magedu.com check
weight <weight>:權重,默認爲1,最大值爲256,0表示不參與負載均衡;
檢查方法:
optionhttpchk
optionhttpchk <uri>
optionhttpchk <method> <uri>
optionhttpchk <method> <uri> <version>:不能用於frontend段,例如:
backendwebserver
mode http
option httpchk GET /checkstatus.htmlHTTP/1.1\r\nHost:www.beyondjie.com
optionhttpchk HEAD /checkstatus.html HTTP/1.1\r\nHost:www.zsms.com
server apache1 192.168.1.1:443 check port80
使用案例:
option httpchk HEAD /checkstatus.htmlHTTP/1.0
server s_d_1 192.168.254.254 cookie s_d_1maxconn 1000 check port 80 inter 2000 fall 3
server s_d_2 192.168.254.252 cookie s_d_2maxconn 1000 check port 80 inter 2000 fall 3
optionhttplog:啓用記錄HTTP請求、會話狀態和計時器的功能。
optionhttplog [ clf ]
clf:使用CLF格式來代替HAProxy默認的HTTP格式,一般在使用僅支持CLF格式的特定日誌分析器時才須要使用此格式。
默認狀況下,日誌輸入格式很是簡陋,由於其僅包括源地址、目標地址和實例名稱,而「option httplog」參數將會使得日誌格式變得豐富許多,其一般包括但不限於HTTP請求、鏈接計時器、會話狀態、鏈接數、捕獲的首部及cookie、「frontend」、「backend」及服務器名稱,固然也包括源地址和端口號等。
optionlogasap 啓用提早將HTTP請求記入日誌,不能用於「backend」區段。
默認狀況下,HTTP請求是在請求結束時進行記錄以便能將其總體傳輸時長和字節數記入日誌,由此,傳較大的對象時,其記入日誌的時長可能會略有延遲。「option logasap」參數可以在服務器發送complete首部時即時記錄日誌,只不過,此時將不記錄總體傳輸時長和字節數。此情形下,捕獲「Content-Length」響應首部來記錄傳輸的字節數是一個較好選擇。下面是一個例子。
listen http_proxy 0.0.0.0:80
mode http
option httplog
option logasap
log 172.16.100.9 local2
option forwardfor:容許在發往服務器的請求首部中插入「X-Forwarded-For」首部。
optionforwardfor [ 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。
下面是一個例子。
frontendwww
mode http
option forwardfor except 127.0.0.1
hash-type:定義用於將hash碼映射至後端服務器的方法
hash-type<method>
其不能用於frontend區段;可用方法有map-based和consistent,在大多數場景下推薦使用默認的map-based方法。
map-based:hash表是一個包含了全部在線服務器的靜態數組。其hash值將會很是平滑,會將權重考慮在列,但其爲靜態方法,對在線服務器的權重進行調整將不會生效,這意味着其不支持慢速啓動。此外,挑選服務器是根據其在數組中的位置進行的,所以,當一臺服務器宕機或添加了一臺新的服務器時,大多數鏈接將會被從新派發至一個與此前不一樣的服務器上,對於緩存服務器的工做場景來講,此方法不甚適用。
consistent:hash表是一個由各服務器填充而成的樹狀結構;基於hash鍵在hash樹中查找相應的服務器時,最近的服務器將被選中。此方法是動態的,支持在運行時修改服務器權重,所以兼容慢速啓動的特性。添加一個新的服務器時,僅會對一小部分請求產生影響,所以,尤爲適用於後端服務器爲cache的場景。不過,此算法不甚平滑,派發至各服務器的請求未必能達到理想的均衡效果,所以,可能須要不時的調整服務器的權重以得到更好的均衡性。
capturerequest header
capturerequest header <name> len <length>
捕獲並記錄指定的請求首部最近一次出現時的第一個值,僅能用於「frontend」和「listen」區段。捕獲的首部值使用花括號{}括起來後添加進日誌中。若是須要捕獲多個首部值,它們將以指定的次序出如今日誌文件中,並以豎線「|」做爲分隔符。不存在的首部記錄爲空字符串,最常須要捕獲的首部包括在虛擬主機環境中使用的「Host」、上傳請求首部中的「Content-length」、快速區別真實用戶和網絡機器人的「User-agent」,以及代理環境中記錄真實請求來源的「X-Forward-For」。
<name>:要捕獲的首部的名稱,此名稱不區分字符大小寫,但建議與它們出如今首部中的格式相同,好比大寫首字母。須要注意的是,記錄在日誌中的是首部對應的值,而非首部名稱。
<length>:指定記錄首部值時所記錄的精確長度,超出的部分將會被忽略。
能夠捕獲的請求首部的個數沒有限制,但每一個捕獲最多隻能記錄64個字符。爲了保證同一個frontend中日誌格式的統一性,首部捕獲僅能在frontend中定義。
captureresponse header
captureresponse header <name> len <length>
捕獲並記錄響應首部,其格式和要點同請求首部。
errorfile
errorfile<code> <file>
在用戶請求不存在的頁面時,返回一個頁面文件給客戶端而非由haproxy生成的錯誤代碼;可用於全部段中。
<code>:指定對HTTP的哪些狀態碼返回指定的頁面;這裏可用的狀態碼有200、400、40三、40八、500、50二、503和504;
<file>:指定用於響應的頁面文件;
例如:
errorfile400 /etc/haproxy/errorpages/400badreq.http
errorfile403 /etc/haproxy/errorpages/403forbid.http
errorfile503 /etc/haproxy/errorpages/503sorry.http
errorloc和errorloc302
errorloc<code> <url>
errorloc302<code> <url>
請求錯誤時,返回一個HTTP重定向至某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
errorloc 403/etc/haproxy/errorpages/sorry.htm
errorloc 503/etc/haproxy/errorpages/sorry.htm
一個配置示例
#--------------------------------------------------------------------- # Global settings #--------------------------------------------------------------------- global # to have these messages end up in /var/log/haproxy.log you will # need to: # # 1) configure syslog to accept network log events. This is done # by adding the '-r' option to the SYSLOGD_OPTIONS in # /etc/sysconfig/syslog # # 2) configure local2 events to go to the /var/log/haproxy.log # file. A line like the following can be added to # /etc/sysconfig/syslog # # local2.* /var/log/haproxy.log # log 127.0.0.1 local2
chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 4000 user haproxy group haproxy daemon
defaults mode http log global option httplog option dontlognull option http-server-close option forwardfor except 127.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 30000
listen stats mode http bind 0.0.0.0:1080 stats enable stats hide-version stats uri /haproxyadmin?stats stats realm Haproxy\ Statistics stats auth admin:admin stats admin if TRUE
frontend http-in bind *:80 mode http log global option httpclose option logasap option dontlognull capture request header Host len 20 capture request header Referer len 60 default_backend servers
frontend healthcheck bind :1099 mode http option httpclose option forwardfor default_backend servers
backend servers balance roundrobin server websrv1 192.168.10.11:80 check maxconn 2000 server websrv2 192.168.10.12:80 check maxconn 2000
|
負載均衡MySQL服務的配置示例
#--------------------------------------------------------------------- # Global settings #--------------------------------------------------------------------- global # to have these messages end up in /var/log/haproxy.log you will # need to: # # 1) configure syslog to accept network log events. This is done # by adding the '-r' option to the SYSLOGD_OPTIONS in # /etc/sysconfig/syslog # # 2) configure local2 events to go to the /var/log/haproxy.log # file. A line like the following can be added to # /etc/sysconfig/syslog # # local2.* /var/log/haproxy.log # 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 option httplog option dontlognull 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 600
listen stats mode http bind 0.0.0.0:1080 stats enable stats hide-version stats uri /haproxyadmin?stats stats realm Haproxy\ Statistics stats auth admin:admin stats admin if TRUE
frontend mysql bind *:3306 mode tcp log global default_backend mysqlservers
backend mysqlservers balance leastconn server dbsrv1 192.168.10.11:3306 check port 3306 intval 2 rise 1 fall 2 maxconn 300 server dbsrv2 192.168.10.12:3306 check port 3306 intval 2 rise 1 fall 2 maxconn 300 |