您好,登錄后才能下訂單哦!
今天小編給大家分享的是Haproxy搭建Web群集圖文概述,相信大部分人都不太了解,為了讓大家更加了解,所以給大家總結了以下內容,話不多說,一起往下看吧。
博文目錄
一、Haproxy概述
1、HTTP請求
2、負載均衡常用調度算法
3、常見的Web群集調度器
二、Haproxy配置項介紹
1、global配置項通常有下面配置參數:
2、defaults配置項配置默認參數,一般會被應用組件繼承,如果在應用組件中沒有特別的聲明,將安裝默認配置參數:
3、listen配置項一般配置應用模塊參數:
三、Haproxy的參數優化
Haproxy是目前比較流行的一種群集調度工具,同類群集調度工具有很多,如LVS和Nginx。相比較而言,LVS性能最好,但是搭建相對復雜;Nginx的upstream模塊支持群集功能,但是對群集節點健康檢查功能不強,性能沒有Haproxy好。Haproxy官方網站是http://www.haproxy.org/ 。
通過URL訪問網站使用的協議是HTTP協議,此類請求一般稱為HTTP請求。HTTP請求的方式分為GET方式和POST方式。
當使用瀏覽器訪問某一個URL,會根據請求URL返回狀態碼,通常正常的狀態碼為2 X X、3 X X(如200、301),如果出現異常會返回4 X X、5 X X(如400、500)。例如:訪問http://www.test.com/a.php?ld=123 ,就是一個GET請求,如果訪問正常,會從服務器的日志中獲取200狀態碼。假如此請求使用POST方式,那么傳遞給a.php的ld參數依舊是123,但是瀏覽器的URL將不會顯示后面的ld=123字樣,因此表單類或者有用戶名、密碼等內容提交時建議使用POST方式。不管使用哪種方式,最終a.php獲取的值是一樣的。
LVS、Haproxy、Nginx最常用的調度算法有三種,如下所述:
RR(Round Robin):動態加權輪詢算法,支持權重的運行時調整及慢啟動機制;最大支持4095個后端主機;在服務器的處理時間平均分配的情況下這是最流暢和公平的算法。該算法是動態的,對于實例啟動慢的服務器權重會在運行中調整。
LC(Least Connections): 最小連接數算法,連接數最少的服務器優先接收連接。建議用于長會話場景中使用,例如LDAP、SQL等協議,而不適合短會話協議。如HTTP.該算法是動態的,對于實例啟動慢的服務器權重會在運行中調整。
- SH(Source Hashing):源地址哈希算法,對請求源IP地址進行哈希;取模法:將源地址hash計算后除以服務器總權重,服務器變動會影響全局調度效果;根據結果進行分配。只要服務器正常,同一個客戶端IP地址總是訪問同一個服務器。如果哈希的結果隨可用服務器數量而變化,那么客戶端會定向到不同的服務器;該算法默認是靜態的,所以運行時修改服務器的權重是無效的,但是算法會根據“hash-type”的變化做調整。
該算法一般用于不能插入cookie的Tcp模式。它還可以用于廣域網上為拒絕使用會話cookie的客戶端提供最有效的粘連;一致性hash:服務器變動僅影響局部調度;動態調度。
目前常見的Web群集調度器分為軟件和硬件,軟件通常使用開源的LVS、Haproxy、Nginx;硬件一般使用比較多的是F5,也有很多人使用國內的一些產品,如梭子魚、綠盟等。
Haproxy的配置文件通常分為三個部分:
- global;
- defaults;
- listen;
global為全局配置,defaults為默認配置,listen為應用組件配置。
global
log 127.0.0.1 local <!--配置日志記錄,local0為日志設備,默認存放到系統日志-->
log 127.0.0.1 local1 notice <!--notice為日志級別,通常有24個級別-->
#log loghost local0 info
maxconn 4096 <!--最大連接數-->
chroot /usr/share/haproxy <!--該服務自設置的根目錄,一般需將此行注釋掉-->
uid 99 <!--用戶UID-->
gid 99 <!--用戶GID-->
daemon <!--守護進程模式-->
defaults
log global <!--定義日志為global配置中的日志定義-->
mode http <!--模式為http-->
option httplog <!--采用http日志格式記錄日志-->
option dontlognull
retries 3 <!--檢查節點服務器失敗次數,連續達到三次失敗,則認為節點不可用-->
redispatch <!--當服務器負載很高時,自動結束當前隊列處理比較久的連接-->
maxconn 2000 <!--最大連接數-->
contimeout 5000 <!--連接超時時間-->
clitimeout 50000 <!--客戶端超時時間-->
srvtimeout 50000 <!--服務器超時時間-->
listen appli4-backup 0.0.0.0:10004 <!--定義一個名為appli4-backup的應用-->
option httpchk /index.html <!--檢查服務器的index.html文件-->
option persist <!--強制將請求發送到已經down掉的服務器,一般禁用此選項-->
balance roundrobin <!--負載均衡調度算法使用輪詢算法-->
server inst1 192.168.114.56:80 check inter 2000 fall 3 <!--定義在線節點-->
server inst2 192.168.114.56:81 check inter 2000 fall 3 backup <!--定義備份節點-->
<!--注意:在以上定義備份節點的參數中,
“check inter 2000”表示haproxy服務器和節點之間的一個心跳率,
“fall 3”表示連續三次檢測不到心跳頻率則認為該節點失效。
節點配置后帶有“ backup”表示該節點只是個備份節點,
只有主節點失效該節點才會上。去除backup,表示為主節點,
和其他主節點共同提供服務-->
關于Haproxy的參數優化,以下列舉了幾個關鍵的參數,并對各參數的生產環境的優化建議做了說明:
關于Haproxy搭建Web群集就分享到這里了,希望以上內容可以對大家有一定的參考價值,可以學以致用。如果喜歡本篇文章,不妨把它分享出去讓更多的人看到
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。