HAproxy簡單入門

時間 2019-11-08

標籤 haproxy 簡單入門欄目負載均衡简体版

原文原文鏈接

Haproxycss

1、簡介
html

Haproxy是一個開源的、高性能的基於TCP（四層）和HTTP（七層）應用的負載均衡軟件。藉助Haproxy能夠更加快速的可靠的提供基於TCP和HTTP應用的負載均衡解決方案。node

優勢：linux

一、可靠性、穩定性高nginx

二、最高可同時維護40000~50000 個併發鏈接，單位時間內處理最大請求數量爲2000 個，最大數據處理web

能力可達10Gbps。正則表達式

三、支持多於8中負載均衡算法，同時也支持session保持。redis

四、支持虛擬主機功能，這樣實現web負載均衡更加靈活算法

五、從Haproxy1.3後開始支持鏈接拒絕、全透明代理等功能數據庫

六、 Haproxy自身具備強大的服務器狀態監控頁面，實時鏈接系統運行狀態。

七、 Haproxy擁有功能強大的ACL支持

2、四層和七層負載均衡區別

四層就是ISO參考模型的第四層。四層負載均衡也稱爲四層交換機，它主要經過分析IP層及TCP/UDP層的流量實現基於「IP+端口」的負載均衡。常見的四層負載均衡有LVS、F5等。

以TCP應用爲例：負載均衡器在接收到第一個來自客戶端的SYN請求時，會經過設定的負載均衡算法選擇一臺最佳的後端服務器，同時將報文中的目標ip地址修改成後端服務器的ip地址，而後直接轉發給該後端服務器，這樣一個負載均衡請求就完成了。從這個過程當中能夠看出，一個TCP鏈接是客戶端和服務器直接創建的，而負載均衡器只不過完成了一個相似路由器的轉發工做，在某些負載均衡策略中，爲保證後端服務器返回的報文能夠正確傳遞給負載均衡器，在轉發報文的同時可能還會對報文原來的原地址進行修改。

七層負載均衡:也稱爲七層交換機，位於ISO最高層，即應用層。支持多種協議由HTTP、FTP、SMTP等。七層負載均衡器能夠根據報文內容，再配合算法來選擇後端服務器，所以也稱爲「內容交換器」。好比，對於web服務器的負載均衡，七層負載均衡器不但能夠根據」IP+端口」的方式進行負載分流，還能夠根據網站URL、訪問域名、瀏覽器類別、語言等決定負載均衡策略。例如兩臺web服務器A、B分別對應中文、英文網站，要實現訪問A域名進入中文網站、訪問B域名進入英文網站，這在四層負載均衡器中幾乎沒法實現，而七層負載均衡能夠根據客戶端端訪問域名的不一樣選擇對應的網頁進行負載均衡處理，常見的七層負載均衡器有Haproxy、nginx等

此處仍以TCP爲例：因爲負載均衡器要獲取到報文的內容，所以只能先代替後端和客戶端創建鏈接，接着，才能收到客戶端發送過來的報文的報文內容，而後再根據該報文中特定字段加上負載均衡中設置的負載均衡器算法來決定最終選擇的後端服務器。根據描述及下圖描述可看出，七層負載均衡器在這種狀況下相似一個代理服務器。

老是所述：在七層負載均衡模式下，負載均衡與客戶端及後端服務器分別創建一次TCP鏈接，而在四層負載模式下，僅創建一次TCP鏈接。因而可知，七層負載均衡對負載均衡設備的要求更高，而七層負載均衡處理能力必然低於四層負載均衡。

3、Haproxy與LVS的異同點

一、二者都是如軟件負載均衡。但lVS是基於linux操做系統實現的一種軟負載均衡，Haproxy是根據第三

方應用實現的軟負載均衡。

二、 LVS是基於四層的IP負載均衡技術，而Haproxy是基於四層和七層技術、可提供TCP和HTTP應用的綜

合負載均衡技術

三、 LVS工做在ISO模型的第四層，所以其狀態檢測功能單一，而Haproxy狀態檢測功能強大，可支持端

口、URL、腳本等多種狀態檢測方式

四、 Haproxy功能強大，但整理處理性能低於四層負載均衡模式的LVS。

3、Haproxy 基礎配置

一、Harpoxy的安裝

yum install haproxy

也可經過編譯方式安裝，此處不作詳細描述

二、Haproxy 基礎配置文件詳解

配置文件

/etc/haproxy/haproxt.cfg

Haproxy配置文件主要由5部分組成

一、 global部分：全局配置參數，進程級的，用來控制Haproxy啓動前的一些進程及系統設置；

二、 default：配置一些默認的參數，能夠被frontend、backend、listen段繼承使用

三、 frontend：用來匹配接收客戶所請求的域名、URL等，並針對不一樣的匹配，不不一樣的請求處理

四、 backend：用來定義後端服務器集羣，以及後端服務器的一些權重、隊列、鏈接數等選項的設置，我將其理解爲Nginx中的upstream塊

listen：能夠理解爲frontend及backend的結合體，haproxy1.3版本以前全部配置選項都在這裏配置。

配置文件詳解

一、global部分

maxconn 20480 #默認最大鏈接數

log 127.0.0.1 local3 #[err warning info debug] 日誌設備

chroot /var/haproxy #chroot運行的路徑

uid 99 #所屬運行的用戶uid

gid 99 #所屬運行的用戶組

daemon #之後臺形式運行haproxy

nbproc 1 #進程數量(能夠設置多個進程提升性能)

pidfile /var/run/haproxy.pid #haproxy的pid存放路徑,啓動進程的用戶必須有權限訪問此文件

ulimit-n65535 #ulimit的數量限制

二、default部分

mode http

retries 3

timeout connect 10s

timeout client 20s

timeout server 30s

timeout check 5s

maxconn 4096

mode:設置Haproxy實例默認的運行模式，有tcp、http、health三選項；

tcp模式：此模式，客戶端和服務器端之間將創建一個全雙工的鏈接，不會對七層報文作出任何類型的檢查，默認爲tcp模式，常常用於ssl、ssh、smtp等應用；

http模式：此模式，客戶端請求在轉發到後端服務器以前會被深度分析，全部不一樣於RFC格式兼容的請求都會被拒絕；

health模式: 已經廢棄；

retries：設置鏈接後端服務器的失敗重試次數，若是鏈接失敗的次數超過設置值，Haproxy則將對應後端服務器標記爲不可用。此參數也可在後面部分進行設置了；

timeout connect：設置成功鏈接到一臺服務器的最長等待時間，默認單位是毫秒，但也可使用其餘的時間單位後綴。

timeout client：設置鏈接客戶端發送數據時最長等待時間，默認單位毫秒。同上可以使用其餘時間單位

timeout server：設置服務器端迴應客戶端數據發送的最長等待時間，默認單位毫秒，同上；

timeout check：設置後端服務器的檢測超時時間，默認單位毫秒，同上；

maxconn ：最大鏈接數；

三、frontend部分

frontend www

bind*:80

mode http

option httplog

option forwardfor

option httpclose

option abortonclose

log global

default_backend webser

www:虛擬節點名稱

bind：監聽套接字（僅可在frontend、listen部分設置）

格式：bind [<address>:<port_range>] interface<interface>

option httplog ：啓用日誌記錄htt請求，默認不記錄http請求；

option forwardfor：將客戶端請求ip傳遞到後端服務器。（設置後端服務器獲取真實客戶端ip）；

option httpclose：客戶端和服務器完成一次鏈接請求後，Haproxy將主動關閉TCP鏈接。

option abortonclose ：當服務器負載很高的時候，自動結束掉當前隊列處理比較久的連接

log global：使用全局日誌配置，表示引用global部分log選項配置日誌格式；

default_backend: 指定默認後端服務器池，webser即真實後端服務器組；

四、backend部分

backend webser #後端服務器池（組）名

mode http

option redispatch

option abortonclose

balance roundrobin

cookie SERVERID

option httpchk GET /index.html

server web1 172.16.76.30:80 cookie server1 weight 6 check inter 2000 rise 2 fall 3

server web2 172.16.76.40:80 cookie server2weight 6 check inter 2000 rise 2 fall 3

option redispatch:此參數用於cookie保持的環境中。默認狀況下，Haproxy會將請求的後端服務器的Serverid

插入cookie中，以保證回話的session持久性。而若是後端服務器出現故障，客戶端的cookie是不會刷新的，這就是

會出現問題。此時，若是設置此參數，就會將客戶的請求強制定向到另外一臺健康的後端服務器上，以保證後端服務器

正常。

option abortonclose：設置此參數，能夠在服務器負載很高的狀況下，自動結束當前隊列中處理時間比較長的

鏈接；

balance 定義負載調度算法

roundrobin：基於權重進行輪叫調度的算法。

static-rr：基於權重進行輪叫調度的算法,此算法爲靜態算法，運行時調整其服務器權重不會生效；

source：基於源ip算法。此算法先對請求的源ip進行hash算法，而後將結果與後端服務器的權重總數相除後

轉發至某臺匹配的後端服務器。這種方式可使同一客戶端的ip的請求始終被轉發到某特定的後端服務器。

lestconn：此算法會將新的鏈接請求轉發到具備最少鏈接數目的後端服務器。在會話時間較長的場景中推薦使

用此算法。例如數據庫負載均衡等。此算法不適合會話較短場景中，例如基於HTTP的應用。

uri：此算法會對部分或整個URL進行hash運算，在通過與服務器的總權重相除，最後轉發到某臺匹配的後端

服務器上。

uri_param:此算法根據URL路徑中的參數進行轉發，這樣可保證在後端真實服務器數量不變時，同一個用戶的請求始終分發到同一臺機器上；

hdr(<name>)：此算法根據http頭進行轉發，若是指定http名稱不存在，則使用roundrobin算法進行策略轉

發；

cookie:表示容許向cookie插入SERVERID,每臺服務器SERVERID可在下面的server關鍵字中表示cookie關鍵

字定義；

option httpchk：此選項表示啓用HTTP的服務狀態檢測功能，Haproxy做爲一個專業的負載均衡服務器，它

支持對backend部分指定的後端服務器節點作健康檢查，以保證在後端backend中某個節點不能服務時，把從

frontend端進行客戶端請求分配至backend中其餘健康節點上，從而保證總體服務的可用性。用法以下

option httpchk <method><uri> <version>

method：http請求方式。

uri ：要檢測的URL地址，經過執行此URL，能夠獲取後端服務器的運行狀態。

version：指定心跳檢測時的HTTP版本號；

server: 定義後端真實服務器。不能用於defaults和frontend部分：使用格式：

server <name><address>[:port] [param*]

<name>:指定後端服務器內部名稱；隨意指定；

<address>:後端服務器的ip地址或主機名；

<port>:指定鏈接請求發往真實服務器的目標端口，在未設定時，將使用客戶端請求時的同一端口；

<param*> :爲後端服務器設定一系列參數，經常使用可用參數：

check:啓用對此後端服務器執行健康狀態檢測

inter:設置健康檢測時間間隔；單位毫秒

rise：設置從故障狀態轉換至正常狀態須要成功檢查的次數。

fall：設置後端服務器從正常狀態轉換爲不能夠狀態須要檢查的次數；

cookie：爲指定後端服務器設定cookie值，此處指定的值將在請求入站時被檢查，第一次爲此值挑選的後端服務器將在後續的請求中一直被選中，其目的在於實現持久鏈接的功能。上面的cookie server1表示web1的serverid 爲server1；

weight：設置後端真實服務器的權重，默認爲1，最大值爲256.設置爲0表示不參與負載均衡；

backup：設置後端真實服務器的備份服務器，僅在後端全部真實服務器均不可用狀況下才啓用即一般所說的sorry server

五、listen部分

listen admin——stats

bind 0.0.0.0:9188

mode http

log127.0.0.1 local0 err #[err warning info debug]

statsrefresh 30s

stats uri/haproxy-status

stats realm welcomelogin\ Haproxy

stats auth admin:adminpass

stats hide-version

stats admin if TRUE

admin-stats listen 實例名即定義一個Haproxy監控頁面

statsrefresh:設置Haproxy 監控統計頁面自動刷新的時間；

statsuri:設置Haproxy 監控統計頁面的URL路徑，可任意指定，如上指定uri/haproxy-status 便可經過訪問http://IP:9188/haproxy-status 查看監控頁面；

stats realm：設置登陸Haproxy統計頁面時密碼框上的文本提示信息；

stats auth：設置登陸Haproxy統計頁面的用戶名和密碼。用戶名密碼冒號分隔，可定義多個；

stats hide-version：用來隱藏統計頁面上Haproxy的版本信息；

stats afmin if TRUE:經過設置此選項，能夠在監控頁面上手工啓用或禁用後端真實服務器，僅在haproxy1.4.9之後版本有效；

4、Haproxy 日誌配置

默認狀況下，Haproxy爲節省寫I/O 所消耗的性能，沒有配置日子輸出。爲方便維護和調試可自行配置HAproxy日誌的輸出功能；

Haproxy的日誌輸出功能，可經過rsyslog實現，將日誌寫入文件將日誌寫入數據庫等功能。

實現方式：

一、配置rsyslog接收haproxy日誌

[root@node1 ~]# vim /etc/rsyslog.d/haprxoy.conf

$Modload imudp

$UDPServerRun 514

local2.* /var/log/haproxy/haproxy_info.log

二、配置rsyslog接收遠程日誌信息

[root@node1 ~]#vim /etc/sysconfig/rsyslog

SYSLOGD_OPTIONS="-c 2 -r -m 0"

[root@node1 ~]# systemctl restart haproxy #重啓rsyslog服務便可完成HAproxy日誌功能

5、Haproxy ACL規則的實現智能負載均衡

Haproxy的ACL規則是Haproxy強大功能的表現之一。它能夠基於實現Haproxy的智能負載均衡系統。

一、經過誰知的ACL規則檢查客戶端請求是否合法。若是符合ACL規則要求，那麼將放行，如不符合則中斷請求；

二、符合ACL規則要求的請求被提交到後端的backend服務器集羣，進而實現基於ACL規則的負載均衡。

Haproxy的ACL規則常常被設置到frontend中。

ACL 配置格式

使用訪問控制列表(ACL)提供了一個靈活的解決方案一般執行內容切換和做出決定的基礎上從請求中提取內容,響應或任何環境狀態

格式：

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

<aclname >:ACL名稱必須由大寫和小寫字母,數字,「——」(dash),「_」(下劃線)」。」(點)和「:」(冒號)。ACL的名稱是區分大小寫的。

<value>的類型

-boolean 布爾型

-integer or integer range 整數或整數範圍

-IP address / network ip地址/網絡

-string (exact, substring, suffix, prefix, subdir, domain)

字符串(精確、子字符串、後綴、前綴、子目錄、域名)

-regular expression 正則表達式

-hex block

<flags>

-i: 忽略大小寫

-m: 指定的模式匹配方法

-n: 禁止DNS解析

-u: 指定ACL惟一id

--: force end of flags. Useful when a string looACLks like one of the flags.

[operator]

匹配整數值：eq、ge、gt、le、lt

匹配字符串：

-exact match (-m str) : 精確匹配字符串 ;

-substringmatch (-m sub) :指定字符串匹配;

-prefix match (-m beg) :指定字符和字符串開頭部分比較.

-suffix match (-m end) : 同上比較字符串結尾.

-subdir match (-m dir) :子目錄匹配.

-domain match (-m dom) :域名匹配.

acl做爲條件時的邏輯關係：

-AND (implicit)

-OR (explicit with the "or"keyword or the "||" operator)

-Negation with the exclamation mark ("!")

ifinvalid_src invalid_port

ifinvalid_src || invalid_port

if! invalid_src invalid_port

<criterion>：

dst: ip

dst_port: integer

src: ip

src_port: integer

aclinvalid_src src 172.16.200.2

path: string

這個提取請求的URL路徑,匹配.

/path;<params>

path : exact string match 精確匹配

path_beg: prefix match 前綴匹配

path_dir: subdir match 子目錄匹配

path_dom: domain match 域名匹配

path_end: suffix match 後綴匹配

path_len: length match 長度匹配

path_reg: regex match 正則匹配

path_sub: substring match 字符串匹配

url : string

對請求的url地址匹配

url : exact string match

url_beg: prefix match

url_dir: subdir match

url_dom: domain match

url_end: suffix match

url_len: length match

url_reg : regex match

url_sub: substring match

req.hdr

req.hdr([<name>[,<occ>]]): string

對請求報文中的內容作檢查

hdr([<name>[,<occ>]]) : exact string match

hdr_beg([<name>[,<occ>]]): prefix match

hdr_dir([<name>[,<occ>]]): subdir match

hdr_dom([<name>[,<occ>]]): domain match

hdr_end([<name>[,<occ>]]): suffix match

hdr_len([<name>[,<occ>]]): length match

hdr_reg([<name>[,<occ>]]): regex match

hdr_sub([<name>[,<occ>]]): substring match

status : integer（整數）

HTTP響應狀態碼匹配.

Pre-defined ACLs（內建ACL）

與ACL規則一塊兒使用Haproxy參數還有use_Backend，use_backend後面須要跟上一個backend實例名，表示知足ACL規則後去請求那個backend實例，與use_backend對應的還有default_backend參數，它表示沒有知足ACL條件的時候默認使用那個後端backend。

示例1：

acl www_policy hdr_reg(host) -i ^(www.linuxinfo.top|linuxinfo.top)

acl bbs_policy hdr_dom(host) -i bbs.linuxinfo.top

acl url_policy url_sub -i buy_sid=

use_backend server_www if www_policy

use_backend server_bbs if bbs_policy

use_backend server_app if url_policy

default_backend server_cache

示例中定義www_policy、bbs_policy、url_policy三個ACL規則，www_policy表示若是客戶端以www.linuxinfo.top或linuxinfo.top開頭的域名發送請求時，則此規則返回true。bbs_policy：表示客戶端經過bbs.linuxinfo.top域名發送請求時，此規則返回true。

url_policy：表示若是客戶端請求的URL中包含「buy_sid= 「字符串時，此規則返回true；

其後規則則定義當符合ACL規則後要調度到那個後端backend。例：當用知足www_policy規則時，那麼將Haproxy會將用戶的請求直接發往server_www的後端backend。如用戶請求不知足全部規則時，Haproxy則將請求發往default_backend選項指定的server_cache服務器。