HAProxy

時間 2019-11-11

標籤 haproxy 欄目負載均衡简体版

原文原文鏈接

1、HAProxy概述mysql

1.haproxy簡介web

HAProxy主要提供兩個功能：http協議反向代理(不提供緩存功能)、基於tcp層的負載均衡(如https、mysql協議)。適用於須要會話保持或七層處理的且負載特別大的站點。可支持數以萬計的併發鏈接。算法

代理做用：web緩存（加速）、反向代理、內容路由（根據流量及內容類型等將請求轉發至特定服務器）、轉碼器；sql

HAProxy基於一種事件驅動(event-driven)、單一進程模型和ebtree彈性二叉樹機制。後端

多進程或多線程模型受內存限制、系統調度器限制以及無處不在的鎖限制，不多能處理數千併發鏈接。事件驅動模型有更好的資源和時間管理的用戶端(User-Space) 實現全部這些任務，因此併發響應能特別大。但在多核系統上此模型一般擴展性較差數組

2.性能優點緩存

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

單進程、事件驅動模型顯著下降了上下文切換的開銷及內存佔用。session

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

在任何可用的狀況下，單緩衝(singlebuffering)機制能以不復制任何數據的方式完成讀寫操做，這會節約大量的CPU時鐘週期及內存帶寬；

藉助於Linux 2.6 (>=2.6.27.19)上的splice()系統調用，HAProxy能夠實現零複製轉發(Zero-copy forwarding)，在Linux3.5及以上的OS中還能夠實現零複製啓動(zero-starting)；

內存分配器在固定大小的內存池中可實現即時內存分配，這可以顯著減小建立一個會話的時長；

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

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

精心地下降了昂貴的系統調用，大部分工做都在用戶空間完成，如時間讀取、緩衝聚合及文件描述符的啓用和禁用等；

3.HAProxy目前主要版本

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

客戶端側的長鏈接(client-side keep-alive)

TCP加速(TCP speedups)

響應池(response buffering)

RDP協議

基於源的粘性(source-based stickiness)

更好的統計數據接口(a much better stats interfaces)

更詳細的健康狀態檢測機制(more verbose health checks)

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

支持HTTP認證

服務器管理命令行接口(server management from the CLI)

基於ACL的持久性(ACL-based persistence)

日誌分析器

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

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

ACL：編寫內容交換規則；

負載均衡算法(load-balancing algorithms)：更多的算法支持；

內容探測(content inspection)：阻止非受權協議；

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

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

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

快速、公平調度器(fast and fairscheduler)：爲某些任務指定優先級可實現理好的QoS；

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

注意：

1)1.1、1.2、1.3的poll和epoll機制對性能影響

1.1l版本默認使用的polling系統爲select()，其處理的文件數達數千個時性能便會急劇降低。

1.2和1.3版本默認的爲poll()，在有些操做系統上可會也會有性能方面的問題，但在Solaris上表現至關不錯。

HAProxy1.3在Linux 2.6及打了epoll補丁的Linux2.4上默認使用epoll，在FreeBSD上使用kqueue，這兩種機制在任何負載上都能提供恆定的性能表現。

2) 高性能選型方案

Linux 2.6.32及以後版本上運行HAProxy 1.4；

打了epoll補丁的Linux2.4上運行HAProxy 1.4；

FreeBSD上運行HAProxy1.4；

Solaris10上運行HAProxy 1.4；

3)splice()調用機制

在較新版本的Linux2.6(>=2.6.27.19)上，HAProxy還可以使用splice()系統調用在接口間無複製地轉發任何數據，甚至能夠達到10Gbps的性能。

4.HAProxy 安裝配置詳解

代理服務器程序包的安裝 yum install haproxy -y

配置文件的所在位置 /etc/haproxy/haproxy.cfg

4-1配置文件的格式

"global"配置段，用於設定全局配置參數

該配置段中的參數爲進程級別的參數，且一般與其運行的os相關

5 HAProxy代理相關的參數

5-1 balance

定義負載均衡算法，可用於「defaults"、"listen" 和"backend"配置段

可用算法以下

注意：

(1)當使用uri算法時，第一次請求一個URL分發到一個主機，則以後再次請求相同URL則使用一臺主機響應。當第一次請求以後，若響應該請求的主機服務出現故障，則haproxy或將其調度到其餘主機，此主機修復後再次調度回來

(2)URI：統一資源標識符；格式以下：

方案://用戶:密碼@主機:端口/路徑;參數(鍵值數據、能夠多個參數字段)?查詢語句#片斷顯示

2.hash-type

格式：hash-type <method>

定義用於將hash碼映射至後端服務器的方法；不能用於frontend區段；可用方法有map-based和consistent

說明：

(1) map-based：hash表是一個包含了全部在線服務器的靜態數組。其hash值將會很是平滑，會將權重考慮在列，但其爲靜態方法，對在線服務器的權重進行調整將不會生效，這意味着其不支持慢速啓動。此外，挑選服務器是根據其在數組中的位置進行的，所以，當一臺服務器宕機或添加了一臺新的服務器時，大多數鏈接將會被從新派發至一個與此前不一樣的服務器上，對於緩存服務器的工做場景來講，此方法不甚適用。

(2) consistent：hash表是一個由各服務器填充而成的樹狀結構；基於hash鍵在hash樹中查找相應的服務器時，最近的服務器將被選中。此方法是動態的，支持在運行時修改服務器權重，所以兼容慢速啓動的特性。添加一個新的服務器時，僅會對一小部分請求產生影響，所以，尤爲適用於後端服務器爲cache的場景。不過，此算法不甚平滑，派發至各服務器的請求未必能達到理想的均衡效果，所以，可能須要不時的調整服務器的權重以得到更好的均衡性。

5-2

HAProxy 統計接口啓用相關的參數；

stats enable

啓用統計頁；基於默認參數啓用統計頁；

stats url<prefix> 配置時候填寫 stats uri / 改變訪問地址

統計頁的訪問uri前綴，一般要加上？stats;

stats realm <realm>

設定認證時使用realm;

stats auth

認證的帳號和密碼；可使用屢次；

stats refresh 3s

定義測試頁面刷新時間