Author : 岑文初

Date: 2009-5-26

目錄

HA-Proxy相比LVS的使用要簡單很多，功能方面也很豐富。HA-Proxy可以在4，7兩層作負載均衡，4層大多用於郵件伺服器、內部協議通訊伺服器等作負載均衡，7層用於Http分析負載轉發。

在HA-Proxy官方網站可以下載配置說明文件(configuration.txt)和架構檔案(architecture.txt)作為參考。具體的使用細節不做太多介紹，這裡主要通過具體的配置來大致說一下HA-Proxy的結構。

HA-Proxy 元件圖

HA-Proxy配置中分成四部分內容，當然這些元件不是必選的，可以根據需要選擇部分作為配置。

安裝HA-Proxy：

1．下載HA-Proxy安裝包。

2．解壓執行make TARGET=linux26（注意，TARGET後面根據本機作業系統核心版本來填寫）

3．Make install

4．目錄下執行haproxy，如果有使用說明出現表示已經安裝正常。

5．使用方式haproxy –f 配置檔案地址。（例如 haproxy –f haproxy.cfg）

HA-Proxy日誌配置說明：

HA-Proxy可以收集本機及其他後端伺服器日誌，但是需要在Load Balancer上作一些配置。

首先修改/etc/sysconfig/syslog檔案，將SYSLOGD_OPTIONS="-m 0”

然後修改/etc/syslog.conf，增加如下語句：

#add by haproxy

local0.* /home/admin/tools/haproxy-1.3.17/haproxy.log// haproxy.log地址代表了需要儲存日誌的地址

執行service syslog restart，重新啟動系統日誌器

最後就是在HA-Proxy的配置中增加日誌輸出（具體可以參考後面的配置檔案說明）

HA-Proxy配置檔案說明：

下面的配置檔案簡單來說就是配置了根據請求引數的不同，將請求分別定向到後端的淘寶叢集和阿里軟體叢集。具體配置檔案(haproxy.cfg)如下：

log 127.0.0.1local0 info//日誌輸出配置，所有的日誌都記錄在本機，通過local0的系統日誌器輸出，這關係到前面我們做的配置

daemon//以後臺程序方式啟動Ha-proxy

nbproc 2 //啟動兩個ha-proxy程序例項

pidfile /home/admin/tools/haproxy-1.3.17/haproxy.pid// pid記錄的檔案

defaults//預設配置

mode http //預設採用http模式，可以配置tcp來做4層訊息轉發

option httplog //採用http日誌格式

retries 3 //三次連線失敗就認為是伺服器不可用，主要是通過後面的check配置來實現伺服器狀態檢查

maxconn 2000 //最大連線數

contimeout 5000 //連線超時時間

clitimeout 50000 //客戶端連線超時時間

srvtimeout 50000 //服務端連線超時時間

stats uri /admin?stats //伺服器狀態統計檢視頁面

stats auth wenchu:wenchu//伺服器狀態檢視授權的使用者名稱和密碼設定，可以不設定

option httpchk HEAD /welcome.html HTTP/1.0//伺服器狀態檢查設定，這裡是向每一個後端伺服器請求/welcome.html頁面來檢查服務端健康狀況。

frontend http-in //前端節點定義

bind :8181 //虛擬服務節點監聽本地的8181埠

mode http

log global

option httplog

option httpclose //每次請求完畢後主動關閉http通道，HA-Proxy不支援keep-alive模式，只能夠模擬這種模式的實現

option forwardfor//如果後端伺服器需要獲得客戶端的真實IP需要配置次引數，將可以從Http Header中獲得客戶端IP

capture request header Host len 20 //此配置和一下的類似配置都是抓取Http請求中的引數記錄到日誌中。

capture request header User-Agent len 16

capture requestheader Content-Length len 10

capture requestheader Refererlen 20

capture response header Content-Length len 10

//控制策略的配置

acl api_taobao url_sub -i sip_apiname=taobao.//在請求url中包含sip_apiname=taobao，則此控制策略返回true,否則為false

acl api_alisoft url_sub -i sip_apiname=alisoft. //在請求url中包含sip_apiname=alisoft，則此控制策略返回true,否則為false

acl invalid_req url_sub -i sip_apiname= //在請求url中包含sip_apiname=，則此控制策略返回true,否則為false

acl stat_req url_dir -i admin //在請求url中存在admin作為部分地址路徑，則此控制策略返回true,否則返回false

block if !invalid_req !stat_req//block表示阻止請求，返回403錯誤，當前表示如果不滿足策略invalid_req，同時也不滿足策略stat_req，則阻止請求。（就是要求URL中必需有引數sip_apiname，除非是檢視伺服器狀態的URL）。

use_backend alisoft_server if api_alisoft//如果是滿足策略api_alisoft的情況，則使用alisoft_server作為後端服務叢集。

use_backend taobao_server if api_taobao //如果是滿足策略api_taobao的情況，則使用taobao_server作為後端服務叢集。

default_backend alisoft_server //使用alisoft_server作為預設後端服務叢集。

backend alisoft_server //後端節點定義

mode http

balance roundrobin//負載均衡策略配置

cookie SERVERID//允許插入serverid到cookie中，serverid後面可以定義

server app1 10.2.225.139:80 cookie 1 check fall 5 weight 1//真實伺服器配置定義cookie 1表示serverid為1，check表示需要狀態檢查，fall 5表示失敗五次就認為伺服器狀態不可用（不在接受請求），weight 1表示權重

server app2 10.2.225.136:80 cookie 2 check fall 5 weight 2

backend taobao_server //後端節點定義

mode http

server app3 10.2.226.41:80 check fall 5

完成配置後，執行haproxy –f haproxy.cfg，後臺程序就可以啟動了，然後在瀏覽器中輸入剛才定義的狀態檢查地址可以看到如下內容：

可以看到定義的前端和後端節點的狀態。對於Ha-proxy很多配置這裡面都沒有使用，也沒有詳細講解，使用者可以通過檢視官方的配置文件瞭解細節。下面三個圖片分別說明了對於sip_apiname不同的訪問產生最後的結果。

上圖的sip_apiname為alisoft.get.user，因此被定向到Alisoft叢集，也就是136或者139上（這裡是136處理了服務）。

上圖的sip_apiname為taobao.get.user，因此被定向到Alisoft叢集，也就是41上。

上圖的sip_apiname沒有傳遞，因此被拒絕訪問，返回403錯誤。

簡單的壓力測試採用Apache ab，500併發使用者，10w的請求總數。

HA-2Node為配置了兩個節點作為後段的服務節點，HA-5Node為配置了5個節點作為後端的服務處理節點。上面結果看到2個節點的HA反而比5個節點的速度來的快，同時HA在7層的轉發和LVS-NAT效能相近。

HA-Proxy使用下來，總體上感覺比較簡單，但功能卻十分強大，但是效能方面來說需要關注在多節點和高壓力的情況下的表現。

從LVS三種模式中也看到了類似於分散式檔案系統的一些設計經驗，就是避免在管理資源過程中，讓Manager成為了系統瓶頸。就好比LVS-NAT中的Load Balancer既負責請求分配同時也負責訊息回覆，成為了系統的關鍵節點，自身效能損耗比較大，加上演算法對於資料採集的要求，自身穩定性和可用性下降，最後影響了整個架構。在HDFS中，Master的責任就和明晰，就是負責節點管理，不參與資料傳輸和通道建立，因此就可以很大程度上提升自身的效率。資源管理（申請，歸還，狀態檢查等）和資源使用應該清晰的劃分開來，這樣可以讓各個角色可以更好的獨立的滿足需求，防止由於其他功能影響到了“本職工作”。

就負載均衡效率來說，硬體實現負載均衡應該優於用軟體實現負載均衡，就好比SSL硬體加速器要遠優於SSL軟體解析模組。但從另一個角度來看，分散式計算，分散式儲存，分散式DB都採用橫向擴充套件結合低成本資源的方式滿足需求。而軟體實現負載在很多情況下可以儘可能的降低成本，同時在效能損失較小的情況下實現硬體負載所支援的所有功能。因此在一定的環境下，部分採用軟體來實現負載均衡能夠增加可擴充套件性，提升配置靈活度，降低配置成本。

從LVS到HA-Proxy，可以發現不論從4層做轉發還是7層做轉發都會存在損失，而且LVS-NAT模式和HA-Proxy都會受到解析負載度和內容大小的影響。因此完全採用軟體負載或者採用某一種配置的軟體負載都不可行，通過將硬體負載和軟體負載相結合，或者多種軟體負載混合使用，可以更好的發揮軟體負載靈活的優勢，同時也不會因為轉發損失影響效能。

附帶：

為了投稿這篇文章壓了很久，同時和軟負載相對應的還有服務隔離機制的文章，後續會發，同時對於軟負載的執行期動態配置也做了嘗試，在HA上效果不錯。當前sip已經採用了軟負載+服務隔離的策略，提高平臺服務質量。