haproxy 安裝與配置
http://www.cnblogs.com/moss_tan_jun/p/6616472.htmlphp
http://www.linuxidc.com/Linux/2015-06/118968.htmcss
一. Haproxy 介紹
HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，它是免費、快速而且可靠的一種解決方案。根據官方數據，其最高極限支持10G的併發。HAProxy特別適用於那些負載特大的web站點，這些站點一般又須要會話保持或七層處理。HAProxy運行在當前的硬件上，徹底能夠支持數以萬計的併發鏈接。而且它的運行模式使得它能夠很簡單安全的整合進您當前的架構中， 同時能夠保護你的web服務器不被暴露到網絡上。html
其支持從4層至7層的網絡交換，即覆蓋全部的TCP協議。就是說，Haproxy 甚至還支持 Mysql 的均衡負載。若是說在功能上，能以proxy反向代理方式實現 WEB均衡負載，這樣的產品有不少。包括 Nginx，ApacheProxy，lighttpd，Cheroke 等。 前端
但要明確一點的，Haproxy並非Http服務器。以上提到全部帶反向代理均衡負載的產品，都清一色是WEB服務器。簡單說，就是他們能自個兒提供靜態(html,jpg,gif..)或動態(php,cgi..)文件的傳輸以及處理。而Haproxy僅僅，並且專門是一款的用於均衡負載的應用代理。其自身並不能提供http服務。 node
HAProxy的算法有以下8種：mysql
1. roundrobin，表示簡單的輪詢linux
2. static-rr，表示根據權重， nginx
3. leastconn，表示最少鏈接者先處理， 程序員
4. source，表示根據請求源IP， web
5. uri，表示根據請求的URI；
6. url_param，表示根據請求的URl參數'balance url_param' requires an URL parameter name
7. hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求；
8. rdp-cookie(name)，表示根據據cookie(name)來鎖定並哈希每一次TCP請求。
二. Haproxy 編譯安裝
1. 編譯安裝
tar zxf haproxy-1.4.22.tar.gz
tar zxf keepalived-1.2.7.tar.gz
uname -r
make TARGET=linux26 PREFIX=/usr/local/haproxy
make install PREFIX=/usr/local/haproxy
2. cp模板文件
cp -ar examples /usr/local/haproxy/
rsync -arvz /usr/local/haproxy/share/man /usr/share/
cp -ar tests /usr/local/haproxy/
cp doc/configuration.txt /usr/local/haproxy/
rsync -arvz soft/haproxy-1.4.22/examples/errorfiles /usr/local/haproxy/
cp examples/haproxy.cfg /usr/local/haproxy/etc/
cp examples/haproxy.init /etc/init.d/haproxy
3. Init 腳本的配置,須要修改,在後面介紹
chmod a+x /etc/init.d/haproxy
chkconfig --add haproxy
4. selinux 的配置
#yum install selinux-policy-devel
#cd contrib/selinux/
#make -f /usr/share/selinux/devel/Makefile
#sudo semodule -i haproxy.pp
#restorecon /usr/sbin/haproxy /etc/haproxy/haproxy.cfg /var/run/haproxy.pid /var/run/haproxy.sock*
#mkdir /usr/local/haproxy/etc
4. 日誌支持，接口和你本身定義的有關係
#vim /etc/syslog.conf
local3.* /var/log/haproxy.log
local0.* /var/log/haproxy.log
#vim /etc/sysconfig/syslog
SYSLOGD_OPTIONS="-r -m 0"
#service syslog restart
5. Haproxy的相關啓動參數
# /usr/local/haproxy/sbin/haproxy –help
haproxy -f < 配置文件>
[-n 最大併發鏈接總數] [-N 每一個偵聽的最大併發數] [-d] [-D] [-q] [-V] [-c] [-p ] [-s] [-l] [-dk]
[-ds] [-de] [-dp] [-db] [-m < 內存限制M>] [{-sf|-st} pidlist...]
-d 前臺，debug模式
-D daemon模式啓動
-q 安靜模式,不輸出信息
-V 詳細模式
-c 對配置文件進行語法檢查
-s 顯示統計數據
-l 顯示詳細統計數據
-dk 不使用kqueue
-ds 不使用speculative epoll
-de 不使用epoll
-dp 不使用poll
-db 禁用後臺模式，程序跑在前臺
-sf 程序啓動後向pidlist裏的進程發送FINISH信號，這個參數放在命令行的最後
-st 程序啓動後向pidlist裏的進程發送TERMINATE信號，這個參數放在命令行的最後
列:
# /usr/local/haproxy/sbin/haproxy -c -f /usr/local/haproxy/etc/haproxy.cfg # 對haproxy 語法作檢查
# /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/etc/haproxy.cfg -sf `cat /var/run/haproxy.pid` # reload
# killall haproxy 或者 kill -9 `pidof haproxy`
三. Haproxy 配置文件解說
# cat /usr/local/haproxy/etc/haproxy.cfg
####################全局配置信息#############參數是進程級的，一般和操做系統（OS）相關#########
global
maxconn 20480 #默認最大鏈接數
log 127.0.0.1 local3 #[err warning info debug]
chroot /usr/local/haproxy #chroot運行的路徑
uid 99 #所屬運行的用戶uid
gid 99 #所屬運行的用戶組
daemon #之後臺形式運行haproxy
nbproc 1 #進程數量(能夠設置多個進程提升性能)
pidfile /var/run/haproxy.pid #haproxy的pid存放路徑,啓動進程的用戶必須有權限訪問此文件
ulimit-n 65535 #ulimit的數量限制
#####################默認的全局設置##############這些參數能夠被利用配置到frontend，backend，listen組件##
defaults
log global
mode http #所處理的類別 (#7層 http;4層tcp )
maxconn 20480 #最大鏈接數
option httplog #日誌類別http日誌格式
option httpclose #每次請求完畢後主動關閉http通道
option dontlognull #不記錄健康檢查的日誌信息
option forwardfor #若是後端服務器須要得到客戶端真實ip須要配置的參數，能夠從Http Header中得到客戶端ip
option redispatch #serverId對應的服務器掛掉後,強制定向到其餘健康的服務器
option abortonclose #當服務器負載很高的時候，自動結束掉當前隊列處理比較久的鏈接
stats refresh 30 #統計頁面刷新間隔
retries 3 #3次鏈接失敗就認爲服務不可用，也能夠經過後面設置
balance roundrobin #默認的負載均衡的方式,輪詢方式
#balance source #默認的負載均衡的方式,相似nginx的ip_hash,能夠固定session
#balance leastconn #默認的負載均衡的方式,最小鏈接
contimeout 5000 #鏈接超時5s , 單位是ms
clitimeout 50000 #客戶端超時
srvtimeout 50000 #服務器超時
timeout check 2000 #心跳檢測超時
#注: 時間的設置,單位爲毫秒ms
1ms = 1/1000 second
1m = 60s = 60000 ms
1h = 60m = 3600s
1d = 24h = 1440m = 86400s = 864000000ms
####################監控頁面的設置#######################
listen admin_status #Frontend和Backend的組合體,監控組的名稱，按需自定義名稱
bind :65532 #監聽端口
mode http #http的7層模式
log 127.0.0.1 local3 err #錯誤日誌記錄
stats refresh 5s #每隔5秒自動刷新監控頁面
stats uri /admin?stats #監控頁面的url
stats realm Haproxy\ Statistics #監控頁面的提示信息
stats auth yangcan:yangcan #監控頁面的用戶和密碼yangcan,能夠設置多個用戶名
#stats auth admin:admin #監控頁面的用戶和密碼admin
stats hide-version #隱藏統計頁面上的HAproxy版本信息
stats admin if TRUE #手工啓用/禁用,後端服務器(haproxy-1.4.9之後版本)
#######################網站監測listen配置#####################
###########此用法主要是監控haproxy後端服務器的監控狀態############
listen site_status
bind :1081 #監聽端口
mode http #http的7層模式
log 127.0.0.1 local3 err #[err warning info debug]
monitor-uri /site_status #網站健康檢測URL，用來檢測HAProxy管理的網站是否能夠用，正常返回200，不正常返回503
acl site_dead nbsrv(server_web) lt 2 #定義網站down時的策略當掛在負載均衡上的指定backend的中有效機器數小於2臺時返回true
acl site_dead nbsrv(server_blog) lt 2
acl site_dead nbsrv(server_bbs) lt 2
monitor fail if site_dead #當知足策略的時候返回503，網上文檔說的是500，實際測試爲503
monitor-net 10.0.0.103/24 #來自10.0.0.103的日誌信息不會被記錄和轉發
monitor-net 10.0.0.25/24
########frontend配置############
#####注意，frontend配置裏面能夠定義多個acl進行匹配操做########
frontend http_80_in
bind :80 #監聽端口，即haproxy提供web服務的端口，和lvs的vip端口相似
mode http #http的7層模式
log global #應用全局的日誌配置
option httplog #啓用http的log
option httpclose #每次請求完畢後主動關閉http通道，HA-Proxy不支持keep-alive模式
option forwardfor #若是後端服務器須要得到客戶端的真實IP須要配置次參數，將能夠從Http Header中得到客戶端IP
errorfile 403 /etc/haproxy/errorfiles/403.http
errorfile 500 /etc/haproxy/errorfiles/500.http
errorfile 502 /etc/haproxy/errorfiles/502.http
errorfile 503 /etc/haproxy/errorfiles/503.http
errorfile 504 /etc/haproxy/errorfiles/504.http
################# HAProxy的日誌記錄內容設置 ###################
capture request header Host len 40
capture request header Content-Length len 10
capture request header Referer len 200
capture response header Server len 40
capture response header Content-Length len 10
capture response header Cache-Control len 8
########acl策略配置#############
acl baby_web hdr_reg(host) -i ^(blog80.baby.local |station80.baby.local)$
#若是請求的域名知足正則表達式中的2個域名返回true -i是忽略大小寫,主要用於redirect到www80.baby.local上;
acl baby_blog hdr_dom(host) -i www80.baby.local
#若是請求的域名知足www80.baby.local 返回true -i是忽略大小寫
#acl baby hdr(host) -i baby.local
#若是請求的域名知足baby.local 返回true -i是忽略大小寫
#acl file_req url_sub -i killall=
#在請求url中包含killall=，則此控制策略返回true,不然爲false
#acl dir_req url_dir -i allow
#在請求url中存在allow做爲部分地址路徑，則此控制策略返回true,不然返回false
#acl missing_cl hdr_cnt(Content-length) eq 0
#當請求的header中Content-length等於0時返回true
########acl策略匹配相應#############
#block if missing_cl
#當請求中header中Content-length等於0阻止請求返回403
#block if !file_req || dir_req
#block表示阻止請求，返回403錯誤，當前表示若是不知足策略file_req，或者知足策略dir_req，則阻止請求
redirect prefix http://www80.baby.local code 301 if baby
#當訪問itnihao.cn的時候，用http的301挑轉到http://10.0.0.103
reqisetbe ^[^\]*\/(img|css)/ server_web
reqisetbe ^[^\]*\/bbs/ server_blog
# reqisetbe 關鍵字定義,根據定義的關鍵字選擇backend
use_backend server_web if baby_web
#當知足baby_web的策略時使用server_web的backend
use_backend server_blog if baby_log
#當知足baby_log的策略時使用server_blog的backend
default_backend server_bbs
#以上都不知足的時候使用默認server_bbs的backend
# 注: redirect 和 reqisetbe 須要放置在 use_backend 以前
##########backend的設置##############
#下面我將設置三組服務器 server_web，server_blog，server_bbs
###########################backend server_web#############################
backend server_web
mode http #http的7層模式
balance roundrobin #負載均衡的方式，roundrobin平均方式
cookie SERVERID #容許插入serverid到cookie中，serverid後面能夠定義
option httpchk GET /index.html #心跳檢測的文件
server web1 10.0.0.25:80 cookie web1 check inter 1500 rise 3 fall 3 weight 1
#服務器定義，cookie 1表示serverid爲web1，check inter 1500是檢測心跳頻率rise 3是3次正確認爲服務器可用，
#fall 3是3次失敗認爲服務器不可用，weight表明權重
server web2 10.0.0.103:80 cookie web2 check inter 1500 rise 3 fall 3 weight 2
#服務器定義，cookie 1表示serverid爲web2，check inter 1500是檢測心跳頻率rise 3是3次正確認爲服務器可用，
#fall 3是3次失敗認爲服務器不可用，weight表明權重
###################################backend server_blog###############################################
backend server_blog
mode http
balance roundrobin
cookie SERVERID
option httpchk GET /index.html
server blog1 10.0.0.25:80 cookie blog1 check inter 1500 rise 3 fall 3 weight 1
server blog2 10.0.0.103:80 cookie blog2 check inter 1500 rise 3 fall 3 weight 2
###################################backend server_bbs###############################################
backend server_bbs
mode http
balance roundrobin
cookie SERVERID
option httpchk GET /index.html
server bbs1 10.0.0.25:80 cookie bbs1 check inter 1500 rise 3 fall 3 weight 1
server bbs2 10.0.0.103:80 cookie bbs2 check inter 1500 rise 3 fall 3 weight 2
################################### 虛擬主機的配置支持###############################################
listen blog80.baby.local 0.0.0.0:80
mode http
balance roundrobin
cookie SERVERID
option httpchk GET /index.html
server bbs1 10.0.0.25:80 cookie bbs1 check inter 1500 rise 3 fall 3 weight 1
server bbs2 10.0.0.103:80 cookie bbs2 check inter 1500 rise 3 fall 3 weight 2
listen bbs.baby.local 0.0.0.0:80
mode http
balance roundrobin
cookie SERVERID
option httpchk GET /index.html
server bbs1 10.0.0.25:80 cookie bbs1 check inter 1500 rise 3 fall 3 weight 1
server bbs2 10.0.0.103:80 cookie bbs2 check inter 1500 rise 3 fall 3 weight 2
四. Haproxy init 啓動腳本
[root@www80 ~]# cat /etc/init.d/haproxy
#!/bin/sh
#
# chkconfig: - 85 15
# description: HA-Proxy is a TCP/HTTP reverse proxy which is particularly suited \
# for high availability environments.
# processname: haproxy
# config: /etc/haproxy/haproxy.cfg
# pidfile: /var/run/haproxy.pid
# Script Author: Simon Matter <simon.matter@invoca.ch>
# Version: 2004060600
# Source function library.
if [ -f /etc/init.d/functions ]; then
. /etc/init.d/functions
elif [ -f /etc/rc.d/init.d/functions ] ; then
. /etc/rc.d/init.d/functions
else
exit 0
fi
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
HAPROXYDIR=/usr/local/haproxy
BASENAME=haproxy
# This is our service name
#BASENAME=`basename $0`
#if [ -L $0 ]; then
# BASENAME=`find $0 -name $BASENAME -printf %l`
# BASENAME=`basename $BASENAME`
#fi
[ -f $HAPROXYDIR/etc/$BASENAME.cfg ] || exit 1
RETVAL=0
start() {
$HAPROXYDIR/sbin/$BASENAME -c -q -f $HAPROXYDIR/etc/$BASENAME.cfg
if [ $? -ne 0 ]; then
echo "Errors found in configuration file, check it with '$BASENAME check'."
return 1
fi
echo -n "Starting $BASENAME: "
daemon $HAPROXYDIR/sbin/$BASENAME -D -f $HAPROXYDIR/etc/$BASENAME.cfg -p /var/run/$BASENAME.pid
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/$BASENAME
return $RETVAL
}
stop() {
echo -n "Shutting down $BASENAME: "
killproc $BASENAME -USR1
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$BASENAME
[ $RETVAL -eq 0 ] && rm -f /var/run/$BASENAME.pid
return $RETVAL
}
restart() {
$HAPROXYDIR/sbin/$BASENAME -c -q -f $HAPROXYDIR/etc/$BASENAME.cfg
if [ $? -ne 0 ]; then
echo "Errors found in configuration file, check it with '$BASENAME check'."
return 1
fi
stop
start
}
reload() {
$HAPROXYDIR/sbin/$BASENAME -c -q -f $HAPROXYDIR/etc/$BASENAME.cfg
if [ $? -ne 0 ]; then
echo "Errors found in configuration file, check it with '$BASENAME check'."
return 1
fi
$HAPROXYDIR/sbin/$BASENAME -D -f $HAPROXYDIR/etc/$BASENAME.cfg -p /var/run/$BASENAME.pid -sf $(cat /var/run/$BASENAME.pid)
}
check() {
$HAPROXYDIR/sbin/$BASENAME -c -q -V -f $HAPROXYDIR/etc/$BASENAME.cfg
}
rhstatus() {
status $BASENAME
}
condrestart() {
[ -e /var/lock/subsys/$BASENAME ] && restart || :
}
# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
reload)
reload
;;
condrestart)
condrestart
;;
status)
rhstatus
;;
check)
check
;;
*)
echo $"Usage: $BASENAME {start|stop|restart|reload|condrestart|status|check}"
exit 1
esac
exit $?
五. Haproxy 測試
///////////////////////// 測試 roundrobin 算法 ///////////////////////////////
# for i in $(seq 10)
do
curl http://www80.baby.local/index.html
done
++++++++++++++++++++++++++
nameserver 10.0.0.25
node 103
nameserver 10.0.0.25
node 103
nameserver 10.0.0.25
node 103
nameserver 10.0.0.25
node 103
nameserver 10.0.0.25
node 103
六. Haproxy 維持session 的三種方法
1. session知識儲備
Session是由應用服務器維持的一個服務器端的存儲空間，用戶在鏈接服務器時，會由服務器生成一個惟一的SessionID,用該SessionID 爲標識符來存取服務器端的Session存儲空間。
而SessionID這一數據則是保存到客戶端，用Cookie保存的，用戶提交頁面時，會將這一 SessionID提交到服務器端，來存取Session數據。服務器也經過URL重寫的方式來傳遞SessionID的值，所以不是徹底依賴Cookie。若是客戶端Cookie禁用，則服務器能夠自動經過重寫URL的方式來保存Session的值，而且這個過程對程序員透明。
2. Php.ini 設置
php.ini 裏幾個session相關值的 其它的值請參考《PHP與Mysql5程序設計》
session.use_cookies = 1 #表示 服務端和客戶端交互session是經過cookie的方式 默認值
session.name = PHPSESSID #默認值是PHPSESSID
session.cache_limiter = nocache #此設置確保對每一個請求，在可能提供緩存的版本前，先請求發送到最初的服務器。這個值聯繫到下文中 cookie識別中的相關參數
3. haproxy三種方法保持客戶端session一致
3.1 用戶IP 識別
haroxy 將用戶IP通過hash計算後 指定到固定的真實服務器上（相似於nginx 的IP hash 指令）
balance source
3.2 cookie 識別
haproxy 將WEB服務端發送給客戶端的cookie中插入(或添加加前綴)haproxy定義的後端的服務器COOKIE ID。
cookie SESSION_COOKIE insert indirect nocache
用firebug能夠觀察到用戶的請求頭的cookie裏 有相似" Cookie PHPSESSID=0bc588656ca05ecf7588c65f9be214f5; SESSION_COOKIE=12" SESSION_COOKIE=12就是haproxy添加的內容
3.3 session 識別
haproxy 將後端服務器產生的session和後端服務器標識存在haproxy中的一張表裏。客戶端請求時先查詢這張表。
appsession PHPSESSID len 64 timeout 5h request-learn
4. 測試seesion 固定, 這是一個php腳本,
<?php
session_start();
$_SESSION['time'] =date("Y:m:d:H:s",time());
echo "本次訪問時間"."<font color=red>".$_SESSION['time']."</font>"."<br>";
echo "訪問的服務器地址是"."<font color=red>".$_SERVER['SERVER_ADDR']."</font>"."<br>";
echo "訪問的服務器域名是"."<font color=red>".$_SERVER['SERVER_NAME']."</font>"."<br>";
echo "SESSIONNAME是"."<font color=red>".session_name()."</font>"."<br>";
echo "SESSIONID是"."<font color=red>".session_id()."</font>"."<br>";
?>
七. Haproxy + keepalived 的高可用
1. Keepalived 的編譯安裝
tar zxf keepalived-1.2.7.tar.gz
cd keepalived-1.2.7
./configure --sysconfdir=/etc
make && make install
2. 配置文件
# vi /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@www80.baby.local
}
notification_email_from root@www80.baby.local
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id LVS_DEVEL
}
vrrp_script chk_haproxy {
script "killall -0 haproxy"
interval 2
weight 2
}
vrrp_instance VI_1 {
state MASTER # 在備份機器上改爲BACKUP
interface eth0
virtual_router_id 51
priority 100 # 備份機器優先級比100要低
advert_int 2
grap_master_delay 1
authentication {
auth_type PASS
auth_pass yangcan
}
track_interface {
eth0
}
virtual_ipaddress {
10.0.0.144
}
track_script {
chk_haproxy
}
# notify_master "/etc/keepalived/Mailnotify.py master"
# notify_backup "/etc/keepalived/Mailnotify.py backup"
# notify_fault "/etc/keepalived/Mailnotify.py fault"
}
haproxy是一款功能強大、靈活好用反向代理軟件，提供了高可用、負載均衡、後端服務器代理的功能，它在7層負載均衡方面的功能很強大(支持cookie track, header rewrite等等)，支持雙機熱備，支持虛擬主機，擁有很是不錯的服務器健康檢查功能，當其代理的後端服務器出現故障, HAProxy會自動將該服務器摘除，故障恢復後再自動將該服務器加入;同時還提供直觀的監控頁面，能夠清晰實時的監控服務集羣的運行情況。
--------------------------------------------------------------------------------
在四層（tcp）實現負載均衡的軟件：
lvs------>重量級
nginx------>輕量級，帶緩存功能，正則表達式較靈活
haproxy------>模擬四層轉發，較靈活
在七層（http）實現反向代理的軟件：
haproxy------>天生技能，全面支持七層代理，會話保持，標記，路徑轉移；
nginx------>只在http協議和mail協議上功能比較好，性能與haproxy差很少；
apache------>功能較差
--------------------------------------------------------------------------------
haproxy的工做模型圖
當用戶併發請求達到必定的數量時，使用haproxy進行負載均衡有明顯的優點；並且haproxy還能夠根據用戶的cookies，根據調度算法，將用戶一直定向分配到之前訪問過的後端服務器上；爲了提升網站訪問速度，通常在haproxy的後端都要配置緩存服務器，能夠是靜態頁面內容的緩存，也能夠是動態網頁內容的緩存，生產環境中有必要添加mysql的緩存。
用戶訪問網站域名時，DNS解析到外網接口haproxy服務器上，haproxy將請求直接轉發（tcp）至後方服務器，或者先分析用戶請求，而後以客戶端身份向後端服務器發出一樣的請求（http），得到後方服務器返回的內容後從新封裝，響應給客戶端，此時haproxy實現一手端兩家，中間翻譯官的角色。
Haproxy+Keepalived搭建Weblogic高可用負載均衡集羣 http://www.linuxidc.com/Linux/2013-09/89732.htm
Keepalived+HAProxy配置高可用負載均衡 http://www.linuxidc.com/Linux/2012-03/56748.htm
CentOS 6.3下Haproxy+Keepalived+Apache配置筆記 http://www.linuxidc.com/Linux/2013-06/85598.htm
Haproxy + KeepAlived 實現WEB羣集 on CentOS 6 http://www.linuxidc.com/Linux/2012-03/55672.htm
Haproxy+Keepalived構建高可用負載均衡 http://www.linuxidc.com/Linux/2012-03/55880.htm
使用 HAProxy 配置 HTTP 負載均衡器 http://www.linuxidc.com/Linux/2015-01/112487.htm
--------------------------------------------------------------------------------
haproxy目前同時更新三個版本
1.5系列
1.4系列
1.3系列
官方站點：www.haproxy.com
咱們能夠到官方下載源碼包，編譯安裝；若是系統安裝包內提供了rpm包，能夠直接yum安裝，這就要看你使用的操做系統版本了。
--------------------------------------------------------------------------------
配置文件安裝目錄：/etc/haproxy/haproxy.conf
haproxy的配置文件分爲四個部分：
全局配置：
global： 全局配置段
代理配置：
default： 默認配置----->全部在backend、frontend、linsten中相同內容能夠在此定義；
frontend：前段配置----->定義前端套接字，接受客戶端請求；
backend： 後端配置----->定義後端分配規則，與後端服務器交互；
listen： 綁定配置----->直接將指定的客戶端與後端特定服務器綁定到一塊兒；
一般沒有特別需求，不須要手動調試配置文件裏面的選項，大部分默認值就能夠知足咱們的需求；並且官方文檔介紹說不少選項都建議使用默認。可是有些選項咱們常常要打交道的，必須對其有必定了解和調試的能力，下面介紹一些經常使用選項的配置。
--------------------------------------------------------------------------------
giobal
--------------------------------------------------------------------------------
* 進程管理及安全相關的參數
- 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，但使用的是用戶名；
- stats：
- node：定義當前節點的名稱，用於HA場景中多haproxy進程共享同一個IP地址時；
- description：當前實例的描述信息；
* 性能調整相關的參數
- maxconn <number>：設定每一個haproxy進程所接受的最大併發鏈接數，其等同於命令行選項「-n」；「ulimit -n」自動計算的結果正是參照此參數設定的；
- maxpipes <number>：haproxy使用pipe完成基於內核的tcp報文重組，此選項則用於設定每進程所容許使用的最大pipe個數；每一個pipe會打開兩個文件描述符，所以，「ulimit -n」自動計算時會根據須要調大此值；默認爲maxconn/4，其一般會顯得過大；
- noepoll：在Linux系統上禁用epoll機制；
- nokqueue：在BSD系統上禁用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相關的參數
- debug
- quiet
------------------------------------------------------------------------------------
--------------------------------------------------------------------------------
balance 算法
balance <algorithm> [ <arguments> ]
balance url_param <param> [check_post [<max_wait>]]
定義負載均衡算法，可用於「defaults」、「listen」和「backend」。<algorithm>用於在負載均衡場景中挑選一個server，其僅應用於持久信息不可用的條件下或須要將一個鏈接從新派發至另外一個服務器時。支持的算法有：
roundrobin：基於權重進行輪叫，在服務器的處理時間保持均勻分佈時，這是最平衡、最公平的算法。此算法是動態的，這表示其權重能夠在運行時進行調整，不過，在設計上，每一個後端服務器僅能最多接受4128個鏈接；
static-rr：基於權重進行輪叫，與roundrobin相似，可是爲靜態方法，在運行時調整其服務器權重不會生效；不過，其在後端服務器鏈接數上沒有限制；
leastconn：新的鏈接請求被派發至具備最少鏈接數目的後端服務器；在有着較長時間會話的場景中推薦使用此算法，如LDAP、SQL等，其並不太適用於較短會話的應用層協議，如HTTP；此算法是動態的，能夠在運行時調整其權重；
source：將請求的源地址進行hash運算，並由後端服務器的權重總數相除後派發至某匹配的服務器；這可使得同一個客戶端IP的請求始終被派發至某特定的服務器；不過，當服務器權重總數發生變化時，如某服務器宕機或添加了新的服務器，許多客戶端的請求可能會被派發至與此前請求不一樣的服務器；經常使用於負載均衡無cookie功能的基於TCP的協議；其默認爲靜態，不過也可使用hash-type修改此特性；
hash-type：
map-based：靜態；哈希算法
consistent：動態；一致性哈希算法
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.linuxidc.com來講，僅計算linuxidc字符串的hash值)以下降hash算法的運算量；此算法默認爲靜態的，不過其也可使用hash-type修改此特性；
--------------------------------------------------------------------------------
hash-type
hash-type <method>
定義用於將hash碼映射至後端服務器的方法；其不能用於frontend區段；可用方法有map-based和consistent，在大多數場景下推薦使用默認的map-based方法。
map-based：hash表是一個包含了全部在線服務器的靜態數組。其hash值將會很是平滑，會將權重考慮在列，但其爲靜態方法，對在線服務器的權重進行調整將不會生效，這意味着其不支持慢速啓動。此外，挑選服務器是根據其在數組中的位置進行的，所以，當一臺服務器宕機或添加了一臺新的服務器時，大多數鏈接將會被從新派發至一個與此前不一樣的服務器上，對於緩存服務器的工做場景來講，此方法不甚適用。
consistent：hash表是一個由各服務器填充而成的樹狀結構；基於hash鍵在hash樹中查找相應的服務器時，最近的服務器將被選中。此方法是動態的，支持在運行時修改服務器權重，所以兼容慢速啓動的特性。添加一個新的服務器時，僅會對一小部分請求產生影響，所以，尤爲適用於後端服務器爲cache的場景。不過，此算法不甚平滑，派發至各服務器的請求未必能達到理想的均衡效果，所以，可能須要不時的調整服務器的權重以得到更好的均衡性。
--------------------------------------------------------------------------------
bind
bind [<address>]:<port_range> [, ...]
bind [<address>]:<port_range> [, ...] interface <interface>
此指令僅能用於frontend和listen區段，用於定義一個或幾個監聽的套接字。
<address>：可選選項，其能夠爲主機名、IPv4地址、IPv6地址或*；省略此選項、將其指定爲*或0.0.0.0時，將監聽當前系統的全部IPv4地址；
<port_range>：能夠是一個特定的TCP端口，也但是一個端口範圍(如5005-5010)，代理服務器將經過指定的端口來接收客戶端請求；須要注意的是，每組監聽的套接字<address:port>在同一個實例上只能使用一次，並且小於1024的端口須要有特定權限的用戶才能使用，這可能須要經過uid參數來定義；
<interface>：指定物理接口的名稱，僅能在Linux系統上使用；其不能使用接口別名，而僅能使用物理接口名稱，並且只有管理有權限指定綁定的物理接口；
例如：
forntend main
bind *:80
bind *:8080
--------------------------------------------------------------------------------
mode
mode { tcp|http|health }
設定實例的運行模式或協議。當實現內容交換時，前端和後端必須工做於同一種模式(通常說來都是HTTP模式)，不然將沒法啓動實例。
tcp：實例運行於純TCP模式，在客戶端和服務器端之間將創建一個全雙工的鏈接，且不會對7層報文作任何類型的檢查；此爲默認模式，一般用於SSL、SSH、SMTP等應用；
http：實例運行於HTTP模式，客戶端請求在轉發至後端服務器以前將被深度分析，全部不與RFC格式兼容的請求都會被拒絕；
health：實例工做於health模式，其對入站請求僅響應「OK」信息並關閉鏈接，且不會記錄任何日誌信息；此模式將用於響應外部組件的健康狀態檢查請求；目前業講，此模式已經廢棄，由於tcp或http模式中的monitor關鍵字可完成相似功能；
--------------------------------------------------------------------------------
log
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>：定義日誌級別，即輸出信息過濾器，默認爲全部信息；指定級別時，全部等於或高於此級別的日誌信息將會被髮送；
--------------------------------------------------------------------------------
maxconn
maxconn <conns>
設定一個前端的最大併發鏈接數，所以，其不能用於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>：指定使用的後端的名稱；
使用案例：
use_backend dynamic if url_dyn
use_backend static if url_css url_img extension_img
default_backend dynamic
--------------------------------------------------------------------------------
server 定義後端服務器
------------------------------------------------------------------------------------
server <name> <address>[:port] [param*]
爲後端聲明一個server，所以，不能用於defaults和frontend區段。
<name>：爲此服務器指定的內部名稱，其將出如今日誌及警告信息中；若是設定了"http-send-server-name"，它還將被添加至發往此服務器的請求首部中；
<address>：此服務器的的IPv4地址，也支持使用可解析的主機名，只不過在啓動時須要解析主機名至相應的IPv4地址；
[:port]：指定將鏈接請求所發往的此服務器時的目標端口，其爲可選項；未設定時，將使用客戶端請求時的同一相端口；
[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表示無上限；
observe <mode>：經過觀察服務器的通訊情況來斷定其健康狀態，默認爲禁用，其支持的類型有 「layer4」 和 「layer7」， 「layer7」僅能用於http代理場景；
redir <prefix>：啓用重定向功能，將發往此服務器的GET和HEAD請求均以302狀態碼響應；須要注意的是，在prefix後面不能使用/，且不能使用相對地址，以避免形成循環；例如：
server srv1 172.16.100.6:80 redir http://imageserver.linuxidc.com check
weight <weight>：權重，默認爲1，最大值爲256，0表示不參與負載均衡；
檢查方法：
option httpchk
option httpchk <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.linuxidc.com
server apache1 192.168.1.1:443 check port 80
使用案例：
server first 172.16.13.13:1080 cookie first check inter 1000
server second 172.16.13.14:1080 cookie second check inter 1000
-------------------------------------------------------------------------------------
--------------------------------------------------------------------------------
capture request header
capture request header <name> len <length>
捕獲並記錄指定的請求首部最近一次出現時的第一個值，僅能用於「frontend」和「listen」區段。捕獲的首部值使用花括號{}括起來後添加進日誌中。若是須要捕獲多個首部值，它們將以指定的次序出如今日誌文件中，並以豎線「|」做爲分隔符。不存在的首部記錄爲空字符串，最常須要捕獲的首部包括在虛擬主機環境中使用的「Host」、上傳請求首部中的「Content-length」、快速區別真實用戶和網絡機器人的「User-agent」，以及代理環境中記錄真實請求來源的「X-Forward-For」。
<name>：要捕獲的首部的名稱，此名稱不區分字符大小寫，但建議與它們出如今首部中的格式相同，好比大寫首字母。須要注意的是，記錄在日誌中的是首部對應的值，而非首部名稱。
<length>：指定記錄首部值時所記錄的精確長度，超出的部分將會被忽略。
能夠捕獲的請求首部的個數沒有限制，但每一個捕獲最多隻能記錄64個字符。爲了保證同一個frontend中日誌格式的統一性，首部捕獲僅能在frontend中定義。
capture response header
capture response header <name> len <length>
捕獲並記錄響應首部，其格式和要點同請求首部。
--------------------------------------------------------------------------------
stats enable
啓用基於程序編譯時默認設置的統計報告，不能用於「frontend」區段。只要沒有另外的其它設定，它們就會使用以下的配置：
- stats uri : /haproxy?stats //url
- stats realm : "HAProxy Statistics" //作認證是提供的信息
- stats auth : no authentication
- stats scope : no restriction //無限制
儘管「stats enable」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非期後果。下面是一個配置案例。
123456789 backend public_www
server websrv1 172.16.100.11:80
stats enable
stats hide-version
stats scope .
stats uri /haproxyadmin?stats
stats realm Haproxy\ Statistics
stats auth statsadmin:password
stats auth statsmaster:password
-------------------------------------------------------------------------------------
stats hide-version
啓用統計報告並隱藏HAProxy版本報告，不能用於「frontend」區段。默認狀況下，統計頁面會顯示一些有用信息，包括HAProxy的版本號，然而，向全部人公開HAProxy的精確版本號是很是有風險的，由於它能幫助惡意用戶快速定位版本的缺陷和漏洞。儘管「stats hide-version」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非期後果。具體請參照「stats enable」一節的說明。
-------------------------------------------------------------------------------------
stats realm
stats realm <realm>
啓用統計報告並高精認證領域，不能用於「frontend」區段。haproxy在讀取realm時會將其視做一個單詞，所以，中間的任何空白字符都必須使用反斜線進行轉義。此參數僅在與「stats auth」配置使用時有意義。
<realm>：實現HTTP基本認證時顯示在瀏覽器中的領域名稱，用於提示用戶輸入一個用戶名和密碼。
儘管「stats realm」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非期後果。具體請參照「stats enable」一節的說明。
-------------------------------------------------------------------------------------
stats scope
stats scope { <name> | "." }
啓用統計報告並限定報告的區段，不能用於「frontend」區段。當指定此語句時，統計報告將僅顯示其列舉出區段的報告信息，全部其它區段的信息將被隱藏。若是須要顯示多個區段的統計報告，此語句能夠定義屢次。須要注意的是，區段名稱檢測僅僅是以字符串比較的方式進行，它不會真檢測指定的區段是否真正存在。
<name>：能夠是一個「listen」、「frontend」或「backend」區段的名稱，而「.」則表示stats scope語句所定義的當前區段。
儘管「stats scope」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非期後果。下面是一個配置案例。
backend private_monitoring
stats enable
stats uri /haproxyadmin?stats
stats refresh 10s
----------------------------------------------------------------------------------------
stats auth
stats auth <user>:<passwd>
啓用帶認證的統計報告功能並受權一個用戶賬號，其不能用於「frontend」區段。
<user>：受權進行訪問的用戶名；
<passwd>：此用戶的訪問密碼，明文格式；
此語句將基於默認設定啓用統計報告功能，並僅容許其定義的用戶訪問，其也能夠定義屢次以受權多個用戶賬號。能夠結合「stats realm」參數在提示用戶認證時給出一個領域說明信息。在使用非法用戶訪問統計功能時，其將會響應一個「401 Forbidden」頁面。其認證方式爲HTTP Basic認證，密碼傳輸會以明文方式進行，所以，配置文件中也使用明文方式存儲以說明其非保密信息故此不能相同於其它關鍵性賬號的密碼。
儘管「stats auth」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非期後果。
---------------------------------------------------------------------------------------
stats admin
stats admin { if | unless } <cond>
在指定的條件知足時啓用統計報告頁面的管理級別功能，它容許經過web接口啓用或禁用服務器，不過，基於安全的角度考慮，統計報告頁面應該儘量爲只讀的。此外，若是啓用了HAProxy的多進程模式，啓用此管理級別將有可能致使異常行爲。
目前來講，POST請求方法被限制於僅能使用緩衝區減去保留部分以外的空間，所以，服務器列表不能過長，不然，此請求將沒法正常工做。所以，建議一次僅調整少數幾個服務器。下面是兩個案例，第一個限制了僅能在本機打開報告頁面時啓用管理級別功能，第二個定義了僅容許經過認證的用戶使用管理級別功能。
backend stats_localhost
stats enable
stats admin if LOCALHOST
backend stats_auth
stats enable
stats auth haproxyadmin:password
stats admin if TRUE
--------------------------------------------------------------------------------
option logasap
no option logasap
啓用或禁用提早將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.13.9 local2
-------------------------------------------------------------------------------- option forwardforoption forwardfor [ except <network> ] [ header <name> ] [ if-none ]容許在發往服務器的請求首部中插入「X-Forwarded-For」首部。 <network>：可選參數，當指定時，源地址爲匹配至此網絡中的請求都禁用此功能。 <name>：可選參數，可以使用一個自定義的首部，如「X-Client」來替代「X-Forwarded-For」。有些獨特的web服務器的確須要用於一個獨特的首部。 if-none：僅在此首部不存在時纔將其添加至請求報文問道中。
- 1. haproxy 安裝與配置
- 2. Haproxy安裝與配置
- 3. Haproxy 安裝與配置
- 4. haproxy 安裝與配置文件詳解
- 5. Haproxy介紹、安裝與配置
- 6. Haproxy安裝及配置
- 7. haproxy安裝配置介紹
- 8. HAProxy安裝配置詳解
- 9. HAProxy安裝及配置
- 10. Haproxy 安裝配置(一)
- 更多相關文章...
- • Git 安裝配置 - Git 教程
- • MySQL免安裝版配置教程 - MySQL教程
- • Composer 安裝與使用
- • IntelliJ IDEA安裝代碼格式化插件
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. haproxy 安裝與配置
- 2. Haproxy安裝與配置
- 3. Haproxy 安裝與配置
- 4. haproxy 安裝與配置文件詳解
- 5. Haproxy介紹、安裝與配置
- 6. Haproxy安裝及配置
- 7. haproxy安裝配置介紹
- 8. HAProxy安裝配置詳解
- 9. HAProxy安裝及配置
- 10. Haproxy 安裝配置(一)