HAProxy反向代理相關配置

時間 2020-07-29

原文原文鏈接

何謂代理？html

所謂的代理通常分爲兩種，即正向代理和反向代理。正向代理能夠實現讓不一樣的主機經過代理服務器使用同一個地址和Internet上的其餘主機通訊，一般在一個局域網內只有一個公網IP時都須要用到正向代理，而反向代理則實現的是未來自不一樣主機的請求發送給後端的其餘服務器就行處理，而本身不負責具體如何去處理。前端

HAProxy介紹git

HAProxy是一款基於Linux平臺且開源的反向代理實現軟件，同時支持虛擬主機，能夠提供高可用性、負載均衡以及基於TCP和HTTP應用的代理。HAProxy特別適用於負載特別大的web站點，這些站點一般又須要回話保持或七層處理。HAProxy運行在當前的硬件上，徹底能夠支持數萬計的併發鏈接。github

而且它的運行模式使得它能夠很簡單安全的整合進您當前的架構中，同時能夠保護你的web服務器不被暴露到網絡上。web

HAProxy實現了一種事件驅動, 單一進程模型，此模型支持很是大的併發鏈接數。多進程或多線程模型受內存限制、系統調度器限制以及無處不在的鎖限制，不多能處理數千併發鏈接。事件驅動模型由於在有更好的資源和時間管理的用戶空間(User-Space) 實現全部這些任務，因此沒有這些問題。此模型的弊端是，在多核系統上，這些程序一般擴展性較差。這就是爲何他們必須進行優化以使每一個CPU時間片(Cycle)作更多的工做。算法

HAProxy實現反向代理的一些配置實例數據庫

接下來將經過配置HAProxy的形式介紹HAProxy的配置。後端

實驗地址規劃安全

主機服務器	IP	用途
A	192.168.2.240/24	安裝HAProxy
B	192.168.2.241/24	安裝HTTPD
B	192.168.2.242/24	安裝HTTPD

準備工做：

在主機A上安裝好HAProxy，主機B上安裝好HTTPD，

配置好yum源後可直接使用yum安裝，併爲主機B配置兩個地址，在此就再也不贅述

例1：未來自客戶端的請求反向代理至後端兩個不一樣的web-server

（1）配置虛擬主機

註釋主配置文件/etc/http/conf/httpd.conf中的DocumentRoot項，而後在/etc/http/conf.d/中新建文件virtual.conf文件，並添加以下內容

DocumentRoot /var/www/test1

ServerName www.test1.com

</VirtualHost>

DocumentRoot /var/www/test2

ServerName www.test2.com

</VirtualHost>

新建虛擬主機目錄，並提供虛擬主機主頁面文件

[root@localhost ~]# mkdir /var/www/test1

[root@localhost ~]# mkdir /var/www/test2

[root@localhost ~]# echo "this is test1" >/var/www/test1/index.html

[root@localhost ~]# echo "this is test2" >/var/www/test2/index.html

（2）配置主機A，編輯HAProxy主配置文件以下

frontend testservers *:80

use_backend web1

backend web1

balance roundrobin

server web1 192.168.2.241:80

server web2 192.168.2.242:80

註釋：配置項說明

frontend ：用於定義前端監聽的套接字，用戶訪問服務器時就是經過這些套接字與服務器通訊

use_backend：指定使用哪一個後端做爲響應，一般後端會經過backend來配置一個或者一組服務器，用來響應前端代理過來的請求

backend：定義後端一系列服務器，一般能夠經過名字引用，當前端的frontend接收進請求後就會把客戶端的請求發給響應的backend

balance：指定調度算法，調度算法有如下幾類

roundrobin：和lvs中的rr相似，不過該調度算法可在server後面加上相應的權重，加上權重後則成爲基於權重的輪詢調度算法，相似於wrr

static-rr：該算法和roundrobin同樣，可基於權重作輪詢，可是roundrobin是動態調度算法，可動態更新服務器的權重，並實時應用，而static-rr則是靜態的，不會實時應用服務器權重。

leastconn：最少鏈接調度算法，該算法會把客戶端的請求發給後端負載最小的服務器，該算法是動態算法，會實時根據每臺服務器權重進行計算，而後動態判斷請求的去向。

source:該算法根會據請求的源地址進行hash計算的結果，把請求轉發給後端服務器，基於該調度算法，來自同一客戶端IP的請求會始終被髮日後端的同一臺服務器。不過，當後端服務器宕機或添加了新的服務器時，許多的請求可能會被髮往與之間請求不一樣的服務器，經常使用語負載均衡無cookie功能的基於TCP的協議，默認爲動態，可經過hash-type修改

hash-type：指定hash算法的類型，後可跟以下兩個選項

map-based：取模算法（靜態）

constraint：一致性hash算法（動態）

uri：對uri的左半部分（「？」標記以前的部分）進行hash運算。並由服務器的總權重相除後派發至某匹配的服務器。

params：參數，

query：如何向數據庫發起查詢請求

frag：片斷

url_param：經過<argument>爲URL指定的參數在每一個HTTP GET請求中將會被索引，經過找到了指定的參數且其經過等於號「=」被賦予一個值。那麼此值將被執行hash運算並被服務器的總權重相除後派發至某匹配的服務器，可使用hash_type指定hash算法類型

her（<name>）：對於每一個HTTP請求，經過<name>指定的HTTP首部將會被檢索，若是對於那個的首部沒有出現或其沒有有效值，則使用輪詢算法對其想用請求進行調度。此算法默認爲靜態，可使用hash_type修改此特性。

例2：開啓haproxy狀態頁，並要求基於用戶認證後才能訪問

編輯配置文件/etc/haproxy/haproxy.cfg，在backend段內添加以下配置項：

stats enable