HA Proxy

kv key-value

取模法

一致性雜湊演算法：consistent hashing

偏斜：虛擬節點

LB：按工作方法分類

基於tcp排程：

lvs，haproxy(模擬實現，未突破套接字限制)，nginx

基於application layer排程：

http:haproxy，nginx，ats，apache

mysql：mysl-proxy

web arch：haproxy

mode：http，tcp在使用者空間模擬tcp服務進行排程（https，mysql）

HAProxy：不提供任何HA功能，只提供代理proxy

代理：（http）掮客(broker)

正向代理：

反向代理：

代理的作用：web快取（加速）、反向代理、內容路由（根據流量及內容型別等，將請求轉發至特定伺服器）、轉碼器(前段壓縮)

在代理伺服器上新增via首部

快取作用：

減少冗餘內容的傳輸：

節省頻寬、緩解網路瓶頸

降低對原始伺服器的請求壓力

降低傳輸延遲

HAProxy：只是http協議的反向代理，不提供反向代理，但額外支援對基於tcp通訊的應用做LB

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

HAProxy實現了一種事件驅動、單一程序模型，此模型支援非常大的併發連線數。多程序或多執行緒模型受記憶體限制、系統排程器限制以及無處不在的鎖限制，很少能處理數千併發連線。事件驅動模型因為在有更好的資源和時間管理的使用者端(User-Space)實現所有這些任務，所以沒有這些問題。此模型的弊端是，在多核系統上，這些程式通常擴充套件性較差。這就是為什麼他們必須進行優化以使每個CPU時間片(Cycle)做更多的工作。

BigO:評判資料結構複雜度

O(1):

O(logN):紅黑樹

O(n)

O(n^2)

O(2^n)

haproxy:彈性二叉樹

資料結構：

RemoteDesktopProtocol

Windows:3389

1.4版本——提供較好的彈性：衍生於1.2版本，並提供了額外的新特性，其中大多數是期待已久的。

客戶端側的長連線(client-sidekeep-alive)

TCP加速(TCPspeedups)

響應池(responsebuffering)

RDP協議

基於源的粘性(source-basedstickiness)

更好的統計資料介面(amuchbetterstatsinterfaces)

更詳細的健康狀態檢測機制(moreverbosehealthchecks)

基於流量的健康評估機制(traffic-basedhealth)

支援HTTP認證

伺服器管理命令列介面(servermanagementfromtheCLI)

基於ACL的永續性(ACL-basedpersistence)

日誌分析器

1.3版本——內容交換和超強負載：衍生於1.2版本，並提供了額外的新特性。

內容交換(contentswitching)：基於任何請求標準挑選伺服器池；

ACL：編寫內容交換規則；

負載均衡演算法(load-balancingalgorithms)：更多的演算法支援；

內容探測(contentinspection)：阻止非授權協議；

透明代理(transparentproxy)：在Linux系統上允許使用客戶端IP直接連入伺服器；

核心TCP拼接(kernelTCPsplicing)：無copy方式在客戶端和服務端之間轉發資料以實現數G級別的資料速率；

分層設計(layereddesign)：分別實現套接字、TCP、HTTP處理以提供更好的健壯性、更快的處理機制及便捷的演進能力；

快速、公平排程器(fastandfairscheduler)：為某些任務指定優先順序可實現理好的QoS；

會話速率限制(sessionratelimiting)：適用於託管環境；

效能:

HAProxy藉助於OS上幾種常見的技術來實現效能的最大化。

單程序、事件驅動模型顯著降低了上下文切換的開銷及記憶體佔用。

O(1)事件檢查器(eventchecker)允許其在高併發連線中對任何連線的任何事件實現即時探測。

在任何可用的情況下，單緩衝(singlebuffering)機制能以不復制任何資料的方式完成讀寫操作，這會節約大量的CPU時鐘週期及記憶體頻寬；

藉助於Linux2.6(>=2.6.27.19)上的splice()系統呼叫，HAProxy可以實現零複製轉發(Zero-copyforwarding)，在Linux3.5及以上的OS中還可以實現零複製啟動(zero-starting)；

記憶體分配器在固定大小的記憶體池中可實現即時記憶體分配，這能夠顯著減少建立一個會話的時長；

樹型儲存：側重於使用作者多年前開發的彈性二叉樹，實現了以O(log(N))的低開銷來保持計時器命令、保持執行佇列命令及管理輪詢及最少連線佇列；

優化的HTTP首部分析：優化的首部分析功能避免了在HTTP首部分析過程中重讀任何記憶體區域；

精心地降低了昂貴的系統呼叫，大部分工作都在使用者空間完成，如時間讀取、緩衝聚合及檔案描述符的啟用和禁用等；

所有的這些細微之處的優化實現了在中等規模負載之上依然有著相當低的CPU負載，甚至於在非常高的負載場景中，5%的使用者空間佔用率和95%的系統空間佔用率也是非常普遍的現象，這意味著HAProxy程序消耗比系統空間消耗低20倍以上。因此，對OS進行效能調優是非常重要的。即使使用者空間的佔用率提高一倍，其CPU佔用率也僅為10%，這也解釋了為何7層處理對效能影響有限這一現象。由此，在高端系統上HAProxy的7層效能可輕易超過硬體負載均衡裝置。

在生產環境中，在7層處理上使用HAProxy作為昂貴的高階硬體負載均衡裝置故障故障時的緊急解決方案也時長可見。硬體負載均衡裝置在“報文”級別處理請求，這在支援跨報文請求(requestacrossmultiplepackets)有著較高的難度，並且它們不緩衝任何資料，因此有著較長的響應時間。對應地，軟體負載均衡裝置使用TCP緩衝，可建立極長的請求，且有著較大的響應時間。

可以從三個因素來評估負載均衡器的效能：

會話率

會話併發能力

資料率

nginx：

server { 每個server相當一個前端

}

server {

location ~* \.php$ 定義條件

proxy_pass 代理

location / {

}

}

proxy_pass：

upstream { 代理的後端伺服器列表

leastconn 最少連線演算法

server 後端伺服器

server

}

upstream {

}

haproxy：

frontend 前端(監聽的埠等)

use_backend 與後端建立關聯（條件式請求）

default_backend 預設後端

backend

balancer 指明排程方法

server

server

若前後端不分離，通常用於定義單個後端的情況

listen： 監聽

server

default為以上三項提供預設引數

配置檔案：/etc/haproxy/haproxy.cfg

全域性配置：

代理配置

現有三臺機器（CentOS7）分別為www(IP192.168.2.16)，web1(IP192.168.2.18),localhost(IP192.168.2.60)

首先在www主機上安裝haproxy

[[email protected]~]#yuminstallhaproxy-y

[[email protected]~]#rpm-qlhaproxy #檢視生成的檔案

在web1和localhost上分別安裝httpd並提供主頁檔案

[[email protected]~]#yuminstallhttpd

[[email protected]~]#echo"<h1>web1</h1>">/var/www/html/index.html

[[email protected]~]#echo"<h1>web2</h1>">/var/www/html/index.html

[[email protected]~]#systemctlstarthttpd.service

[[email protected]~]#ss-tnlp

配置haproxy：

[[email protected]~]#cd/etc/haproxy/

[[email protected]haproxy]#vimhaproxy.cfg

目前下面的配置檔案沒用，刪除上圖以下的配置檔案

[[email protected]haproxy]#systemctlstarthaproxy.service

[[email protected]haproxy]#systemctlstatushaproxy.service-l #檢視執行狀態

嘗試訪問，效果為輪詢，因balance為roundrobin

看是否能實現健康狀態檢查：

[[email protected]~]#systemctlstophttpd.service

<<<<<<<<<<<<<<<<<部分解釋>>>>>>>>>>>>>>

global：

log127.0.0.1local2 記錄日誌，通過日誌server

chroot/var/lib/haproxy 將根目錄切換至此目錄安全執行

pidfile/var/run/haproxy.pid PID檔案位置

maxconn4000 最大連線數

userhaproxy 執行程序的使用者

grouphaproxy

daemon 啟動為守護程序

#turnonstatsunixsocket

statssocket/var/lib/haproxy/stats 本地訪問統計資料時可以基於共享記憶體方式

nbproc 啟動haproxy的程序個數，只能用於守護程序時

ulimit-n 設定每個程序開啟的的最大檔案數量，預設自行計算

spread-checks

<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>

常需要調整的值：log，nbproc，maxconn，spread-checks

下面來配置一下日誌：

[[email protected]haproxy]#systemctlrestartrsyslog.service #重啟日誌服務

[[email protected]~]#systemctlstatusrsyslog.service

[[email protected]~]#ss-unlp #檢視514埠是否監聽

[[email protected]~]#systemctlstarthttpd.service 啟動web1上的httpd

再次嘗試訪問檢視是否可輪詢

檢視後端伺服器的日誌：（實際生產中應記錄實際訪問的客戶端IP才有意義）

總結：

HAProxy：

http協議反向代理

tcp層的LB

特性：event-driven(事件驅動)，ebtree(彈性二叉樹)

配置：/etc/haproxy/haproxy.cfg(主配置檔案)

/usr/sbin/haproxy(主程式)

啟動方式：

CentOS 6: /etc/rc.d/init.d/haproxy (呼叫指令碼)

CentOS 7: haproxy.service (unit file)

配置分為兩段：

global：

log

maxconn 最大併發連線

...

proxies (代理相關)

defaults，frontednd，bakcend，listen

HAProxy（2）

代理引數：

balance：指明負載均衡的排程演算法

動態：權重可動態調整（伺服器自行調整）

靜態：調整權重不會實時生效

roundrobin：加權輪詢，動態演算法，每個後端主機最多支援4128個連線

static-rr：輪詢，靜態演算法，每個後端主機支援的數量無上限

leastconn：根據後端主機的負載數量(最少連線)進行排程，僅適用於長連線的會話，動態，不適於http

source：源地址hash，基於後端伺服器的權重總數，不過當後端伺服器數量或權重變化時，後果...

hash-type：hash型別

map-based：取模法，靜態

consistent：一致性雜湊法，動態

uri：

hash-type：

map-based：取模法，靜態

consistent：一致性雜湊法，動態

url_param：根據url中的param引數的值進行排程，把值進行hash計算，併除以總權重：(比如基於username)

hash-type：

map-based：取模法，靜態

consistent：一致性雜湊法，動態

hdr(<name>)根據請求報文中指定的header（如user-agent，referer，hostname）進行排程，把指定的header的值進行hash計算（如根據客戶端瀏覽器型別排程）

[[email protected]haproxy]#vimhaproxy.cfg

[[email protected]haproxy]#vimhaproxy.cfg

[[email protected]~]#systemctlreloadhaproxy.service

[[email protected]~]#systemctlstatushaproxy.service

[[email protected]~]#foriin{1..10};doecho"<h1>Page$iWeb1</h1>">/var/www/html/text$i.html;done

[[email protected]~]#ls/var/www/html/

[[email protected]~]#foriin{1..10};doecho"<h1>Page$iWeb2</h1>">/var/www/html/text$i.html;done

此時更換不同客戶端進行測試，對同一個uri的請求一定會排程到同一httpd伺服器響應，此時若其中一個伺服器宕機，則根據規定的演算法向後輪詢且剩下的服務訪問依然遵循uri排程，因本次環境不具備不演示

[[email protected]haproxy]#vimhaproxy.cfg

[[email protected]~]#systemctlreloadhaproxy.service

bind：

只能用於frontend，listen

[[email protected]haproxy]#vimhaproxy.cfg

[[email protected]~]#systemctlrestarthaproxy.service

[[email protected]~]#systemctlstatushaproxy.service

mode：

HAProxy的工作模式，預設為TCP,只有在服務端和客戶端都為http協議時才可使用http

tcp, http, health

log:

maxcoon：最大連線數

default_backend：

為frontend指明使用的預設後端

use_backend：條件式後端呼叫

K.I.S.S：Keep it simple,stupid

server:

server<name><addr>[:port][settings...]

settings：

backup:設定當前server為backupserver；

check:健康狀態檢測；

inter<delay>：健康狀態檢測時間間隔；單位為ms,預設為2000;

fall:up-->down,softstate,softstate,hardstate;

rise：down-->up,

cookie<value>：

maxconn:此伺服器接受的併發連線的最大數量；

maxqueue:請求佇列的最大長度；

observe:根據流量判斷後端server的健康狀態；

weight:指定權重，預設為1，最大為256；0表示不被排程；

redir<prefix>:重定向；所有發往此伺服器的GET和HEAD請求均以302響應；

後端為http伺服器做健康狀態檢測時的檢測方法：

optionhttpchk

[[email protected]haproxy]#vimhaproxy.cfg

[[email protected]~]#systemctlreloadhaproxy.service

基於瀏覽器cookie實現sessionsticky：

backendwebsrvs

balanceroundrobin

cookieSERVERIDinsertnocacheindirect

serverweb1172.16.100.68:80checkweight1cookiewebsrv1

serverweb2172.16.100.69:80checkweight3cookiewebsrv2

[[email protected]haproxy]#vimhaproxy.cfg

[[email protected]~]#systemctlreloadhaproxy.service

要點：

(1)每個server有自己惟一的cookie標識；

(2)在backend中定義為使用者請求排程完成後操縱其cookie

啟用stats：

listenstatistics

bind*:9090

statsenable

statshide-version

#statsscope.

statsuri/haproxyadmin?stats

statsrealm"HAPorxy\Statistics"

statsauthadmin:mageedu

statsadminifTRUE

[[email protected]haproxy]#vimhaproxy.cfg

[[email protected]~]#systemctlrestarthaproxy.service

[[email protected]~]#systemctlstatushaproxy.service

[[email protected]haproxy]#vimhaproxy.cfg

[[email protected]~]#systemctlreloadhaproxy.service

顯示的內容好像比剛才少了，這是因為我們沒有賦予當前賬戶管理許可權：

[[email protected]haproxy]#vimhaproxy.cfg

[[email protected]~]#systemctlreloadhaproxy.service

向日志中記錄額外資訊：

capture request header

capture response header

當mode為http時，記錄詳細的日誌資訊(預設已啟用)

啟用或禁用提前將HTTP請求記入日誌

[no] option logasap

[[email protected]~]#vim/etc/httpd/conf/httpd.conf

[[email protected]~]#systemctlreloadhttpd.service

錯誤頁面重定向

errorfile：使用haproxy主機本地檔案進行響應

errorloc，errorloc302：使用指定的url進行響應，響應狀態碼為302，不適用與GET以外的其他方法

訪問控制：

http_request

tcp_request

新增請求或響應報文首部：

reqadd

rspadd

[[email protected]haproxy]#vimhaproxy.cfg

[[email protected]~]#systemctlreloadhaproxy.service

option: http-server-close 長連線server端斷開

option http-pretend-keepalive 假裝haproxy向server請求為保持連線

ACL：

定義及呼叫

補充：動靜分離的示例：

frontendmain

bind*:80

bind*:8080

aclurl_staticpath_beg-i/static/p_w_picpaths/javascript/stylesheets

aclurl_staticpath_end-i.jpg.gif.png.css.js

use_backendstaticifurl_static

default_backendappsrvs

#---------------------------------------------------------------------

#staticbackendforservingupp_w_picpaths,stylesheetsandsuch

#---------------------------------------------------------------------

backendstatic

balanceroundrobin

serverstatic1172.16.100.11check

serverstatic2172.16.100.12check

backendappsrvs

balanceroundrobin

optionforwardforexcept127.0.0.1headerX-Client

optionhttpchk

cookieSERVERIDinsertindirectnocache

serverweb1172.16.100.7:80checkcookieweb1

serverweb2172.16.100.8:80checkcookieweb2

轉載於:https://blog.51cto.com/chaochao3/1710490