HAProxy原理和基本概念


一、基礎介紹

https://www.haproxy.org/ (官方網站)

https://www.haproxy.org/download/1.8/src/haproxy-1.8.14.tar.gz (下載地址)

http://cbonte.github.io/haproxy-dconv/1.8/configuration.html (文檔Haproxy 1.8 文檔)

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

HAProxy實現了一種事件驅動, 單一進程模型,此模型支持非常大的並發連接數。多進程或多線程模型受內存限制 、系統調度器限制以及無處不在的鎖限制,很少能處理數千並發連接。事件驅動模型因為在有更好的資源和時間管理的用戶空間(User-Space) 實現所有這

二、負載平衡的類型

(1)無負載平衡:沒有負載平衡的簡單Web應用程序環境可能如下所示

 

在此示例中,用戶直接連接到您的Web服務器,在yourdomain.com上,並且沒有負載平衡。如果您的單個Web服務器出現故障,用戶將無法再訪問您的Web服務器。此外,如果許多用戶試圖同時訪問您的服務器並且無法處理負載,他們可能會遇到緩慢的體驗,或者可能根本無法連接。

(2)4層負載平衡:

將網絡流量負載平衡到多個服務器的最簡單方法是使用第4層(傳輸層)負載平衡。以這種方式進行負載均衡將根據IP范圍和端口轉發用戶流量(即,如果請求進入http://yourdomain.com/anything,則流量將轉發到處理yourdomain.com的所有請求的后端。端口80)。

用戶訪問負載均衡器,負載均衡器將用戶的請求轉發給后端服務器的Web后端組。無論選擇哪個后端服務器,都將直接響應用戶的請求。通常,Web后端中的所有服務器應該提供相同的內容 - 否則用戶可能會收到不一致的內容。

(3)7層負載平衡:

7層負載平衡是更復雜的負載均衡網絡流量的方法是使用第7層(應用層)負載均衡。使用第7層允許負載均衡器根據用戶請求的內容將請求轉發到不同的后端服務器。這種負載平衡模式允許您在同一域和端口下運行多個Web應用程序服務器。

示例中,如果用戶請求yourdomain.com/blog,則會將其轉發到博客后端,后端是一組運行博客應用程序的服務器。其他請求被轉發到web-backend,后端可能正在運行另一個應用程序。

三、HAProxy基礎配置文件詳解:

haproxy 配置中分成五部分內容,分別如下:

global: 設置全局配置參數,屬於進程的配置,通常是和操作系統相關。
defaults:配置默認參數,這些參數可以被用到frontend,backend,Listen組件;
frontend:接收請求的前端虛擬節點,Frontend可以更加規則直接指定具體使用后端的backend;
backend:后端服務集群的配置,是真實服務器,一個Backend對應一個或者多個實體服務器;
Listen :frontend和backend的組合體。
HAProxy配置文件詳解global # 全局參數的設置    log 127.0.0.1 local0 info

 # log語法:log <address_1>[max_level_1] # 全局的日志配置,使用log關鍵字,指定使用127.0.0.1上的syslog服務中的local0日志設備,記錄日志等級為info的日志 user haproxy group haproxy # 設置運行haproxy的用戶和組,也可使用uid,gid關鍵字替代之 daemon # 以守護進程的方式運行 nbproc 16 # 設置haproxy啟動時的進程數,根據官方文檔的解釋,可理解為:該值的設置應該和服務器的CPU核心數一致,即常見的2顆8核心CPU的服務器,即共有16核心,則可以將其值設置為:<=16 ,創建多個進程數,
   可以減少每個進程的任務隊列,但是過多的進程數也可能會導致進程的崩潰。這里我設置為16 maxconn
4096 # 定義每個haproxy進程的最大連接數 ,由於每個連接包括一個客戶端和一個服務器端,所以單個進程的TCP會話最大數目將是該值的兩倍。 #ulimit -n 65536 # 設置最大打開的文件描述符數,在1.4的官方文檔中提示,該值會自動計算,所以不建議進行設置 pidfile /var/run/haproxy.pid # 定義haproxy的pid   defaults # 默認部分的定義 mode http # mode語法:mode {http|tcp|health} 。http是七層模式,tcp是四層模式,health是健康檢測,返回OK log 127.0.0.1 local3 err # 使用127.0.0.1上的syslog服務的local3設備記錄錯誤信息 retries 3 # 定義連接后端服務器的失敗重連次數,連接失敗次數超過此值后將會將對應后端服務器標記為不可用 option httplog # 啟用日志記錄HTTP請求,默認haproxy日志記錄是不記錄HTTP請求的,只記錄“時間[Jan 5 13:23:46] 日志服務器[127.0.0.1] 實例名已經pid[haproxy[25218]] 信息[Proxy http_80_in stopped.]”,
    日志格式很簡單。 option redispatch # 當使用了cookie時,haproxy將會將其請求的后端服務器的serverID插入到cookie中,以保證會話的SESSION持久性;而此時,如果后端的服務器宕掉了,但是客戶端的cookie是不會刷新的,
    如果設置此參數,將會將客戶的請求強制定向到另外一個后端server上,以保證服務的正常。 option abortonclose # 當服務器負載很高的時候,自動結束掉當前隊列處理比較久的鏈接 option dontlognull # 啟用該項,日志中將不會記錄空連接。所謂空連接就是在上游的負載均衡器或者監控系統為了探測該服務是否存活可用時,需要定期的連接或者獲取某一固定的組件或頁面,
   或者探測掃描端口是否在監聽或開放等動作被稱為空連接;官方文檔中標注,如果該服務上游沒有其他的負載均衡器的話,建議不要使用該參數,因為互聯網上的惡意掃描或其他動作就不會被記錄下來 option httpclose # 這個參數可這樣理解的:使用該參數,每處理完一個request時,haproxy都會去檢查http頭中的Connection的值,如果該值不是close,haproxy將會將其刪除,
    如果該值為空將會添加為:Connection: close。使每個客戶端和服務器端在完成一次傳輸后都會主動關閉TCP連接。與該參數類似的另外一個參數是“option forceclose”,
    該參數的作用是強制關閉對外的服務通道,因為有的服務器端收到Connection: close時,也不會自動關閉TCP連接,如果客戶端也不關閉,連接就會一直處於打開,直到超時。 contimeout
5000 # 設置成功連接到一台服務器的最長等待時間,默認單位是毫秒,新版本的haproxy使用timeout connect替代,該參數向后兼容 clitimeout 3000 # 設置連接客戶端發送數據時的成功連接最長等待時間,默認單位是毫秒,新版本haproxy使用timeout client替代。該參數向后兼容 srvtimeout 3000 # 設置服務器端回應客戶度數據發送的最長等待時間,默認單位是毫秒,新版本haproxy使用timeout server替代。該參數向后兼容 listen status # 定義一個名為status的部分 bind 0.0.0.0:1080 # 定義監聽的套接字 mode http # 定義為HTTP模式 log global # 繼承global中log的定義 stats refresh 30s # stats是haproxy的一個統計頁面的套接字,該參數設置統計頁面的刷新間隔為30s stats uri /admin?stats # 設置統計頁面的uri為/admin?stats stats realm Private lands # 設置統計頁面認證時的提示內容 stats auth admin:password # 設置統計頁面認證的用戶和密碼,如果要設置多個,另起一行寫入即可 stats hide-version # 隱藏統計頁面上的haproxy版本信息 frontend http_80_in # 定義一個名為http_80_in的前端部分 bind 0.0.0.0:80 # http_80_in定義前端部分監聽的套接字 mode http # 定義為HTTP模式 log global # 繼承global中log的定義 option forwardfor # 啟用X-Forwarded-For,在requests頭部插入客戶端IP發送給后端的server,使后端server獲取到客戶端的真實IP acl static_down nbsrv(static_server) lt 1 # 定義一個名叫static_down的acl,當backend static_sever中存活機器數小於1時會被匹配到 acl php_web url_reg /*.php$ #acl php_web path_end .php # 定義一個名叫php_web的acl,當請求的url末尾是以.php結尾的,將會被匹配到,上面兩種寫法任選其一 acl static_web url_reg /*.(css|jpg|png|jpeg|js|gif)$ #acl static_web path_end .gif .png .jpg .css .js .jpeg # 定義一個名叫static_web的acl,當請求的url末尾是以.css、.jpg、.png、.jpeg、.js、.gif結尾的,將會被匹配到,上面兩種寫法任選其一 use_backend php_server if static_down # 如果滿足策略static_down時,就將請求交予backend php_server use_backend php_server if php_web # 如果滿足策略php_web時,就將請求交予backend php_server use_backend static_server if static_web # 如果滿足策略static_web時,就將請求交予backend static_server backend php_server #定義一個名為php_server的后端部分 mode http # 設置為http模式 balance source # 設置haproxy的調度算法為源地址hash cookie SERVERID # 允許向cookie插入SERVERID,每台服務器的SERVERID可在下面使用cookie關鍵字定義 option httpchk GET /test/index.php # 開啟對后端服務器的健康檢測,通過GET /test/index.php來判斷后端服務器的健康情況 server php_server_1 10.12.25.68:80 cookie 1 check inter 2000 rise 3 fall 3 weight 2 server php_server_2 10.12.25.72:80 cookie 2 check inter 2000 rise 3 fall 3 weight 1 server php_server_bak 10.12.25.79:80 cookie 3 check inter 1500 rise 3 fall 3 backup # server語法:server [:port] [param*] # 使用server關鍵字來設置后端服務器;為后端服務器所設置的內部名稱[php_server_1],該名稱將會呈現在日志或警報中、后端服務器的IP地址,支持端口映射[10.12.25.68:80]、指定該服務器的SERVERID為1[cookie 1]、接受健康監測[check]、監測的間隔時長,單位毫秒[inter 2000]、監測正常多少次后被認為后端服務器是可用的[rise 3]、監測失敗多少次后被認為后端服務器是不可用的[fall 3]、分發的權重[weight 2]、最后為備份用的后端服務器,當正常的服務器全部都宕機后,才會啟用備份服務器[backup] backend static_server mode http option httpchk GET /test/index.html server static_server_1 10.12.25.83:80 cookie 3 check inter 2000 rise 3 fall 3 ---------------------

轉載:(20條消息) HAProxy原理和基本概念_石頭-CSDN博客_haproxy

各種負載均衡軟件區分:(總結)Nginx/LVS/HAProxy負載均衡軟件的優缺點詳解 (ha97.com)


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM