|
Author : 岑文初 Email: wenchu.cenwc@alibaba-inc.com Blog: http://blog.csdn.net/cenwenchu79 Date: 2009-5-26
目錄 HA-ProxyHA-Proxy相比LVS的使用要簡單很多，功能方面也很豐富。HA-Proxy可以在4，7兩層作負載均衡，4層大多用于郵件服務器、內部協(xié)議通信服務器等作負載均衡，7層用于Http分析負載轉發(fā)。 在HA-Proxy官方網(wǎng)站可以下載配置說明文檔(configuration.txt)和架構文件(architecture.txt)作為參考。具體的使用細節(jié)不做太多介紹，這里主要通過具體的配置來大致說一下HA-Proxy的結構。
HA-Proxy 組件圖 HA-Proxy配置中分成四部分內容，當然這些組件不是必選的，可以根據(jù)需要選擇部分作為配置。Defaults組件是配置默認參數(shù)的，這些參數(shù)可以被利用配置到frontend，backend，listen組件中（當這些組件某些參數(shù)沒有被配置而在Defaults中配置了）。Frontend組件是接收請求的前端虛擬節(jié)點，就類似于LVS中配置了VIP的Load Balancer，Frontend可以直接指定后端指向那一個backend(可動態(tài)選擇)。Backend是后端服務集群的配置，類似于LVS中的那些Real Server，一個Backend對應一個或者多個實體服務器。Listen是Frontend和Backend的組合體，可以直接定義一個類似于JBoss的 Server Farm。還有一些默認的配置可以通過在配置文件中配置或者在命令行中作為參數(shù)輸入。 安裝HA-Proxy： 1． 下載HA-Proxy安裝包。 2． 解壓執(zhí)行make TARGET=linux26（注意，TARGET后面根據(jù)本機操作系統(tǒng)內核版本來填寫） 3． Make install 4． 目錄下執(zhí)行haproxy，如果有使用說明出現(xiàn)表示已經安裝正常。 5． 使用方式haproxy –f 配置文件地址。（例如 haproxy –f haproxy.cfg） HA-Proxy日志配置說明： HA-Proxy可以收集本機及其他后端服務器日志，但是需要在Load Balancer上作一些配置。 首先修改/etc/sysconfig/syslog文件，將SYSLOGD_OPTIONS="-m 0” 修改為SYSLOGD_OPTIONS="-m 0 -r -x"，支持收集遠程服務器日志。 然后修改/etc/syslog.conf，增加如下語句： #add by haproxy local0.* /home/admin/tools/haproxy-1.3.17/haproxy.log // haproxy.log地址代表了需要存儲日志的地址 執(zhí)行service syslog restart，重新啟動系統(tǒng)日志器 最后就是在HA-Proxy的配置中增加日志輸出（具體可以參考后面的配置文件說明） HA-Proxy配置文件說明： 下面的配置文件簡單來說就是配置了根據(jù)請求參數(shù)的不同，將請求分別定向到后端的淘寶集群和阿里軟件集群。具體配置文件(haproxy.cfg)如下： log 127.0.0.1 local0 info //日志輸出配置，所有的日志都記錄在本機，通過local0的系統(tǒng)日志器輸出，這關系到前面我們做的配置 daemon //以后臺進程方式啟動Ha-proxy nbproc 2 //啟動兩個ha-proxy進程實例 pidfile /home/admin/tools/haproxy-1.3.17/haproxy.pid // pid記錄的文件 defaults //默認配置 mode http //默認采用http模式，可以配置tcp來做4層消息轉發(fā) option httplog //采用http日志格式 retries 3 //三次連接失敗就認為是服務器不可用，主要是通過后面的check配置來實現(xiàn)服務器狀態(tài)檢查 maxconn 2000 //最大連接數(shù) contimeout 5000 //連接超時時間 clitimeout 50000 //客戶端連接超時時間 srvtimeout 50000 //服務端連接超時時間 stats uri /admin?stats //服務器狀態(tài)統(tǒng)計查看頁面 stats auth wenchu:wenchu //服務器狀態(tài)查看授權的用戶名和密碼設置，可以不設置 option httpchk HEAD /welcome.html HTTP/1.0 //服務器狀態(tài)檢查設置，這里是向每一個后端服務器請求/welcome.html頁面來檢查服務端健康狀況。 frontend http-in //前端節(jié)點定義 bind :8181 //虛擬服務節(jié)點監(jiān)聽本地的8181端口 mode http log global option httplog option httpclose //每次請求完畢后主動關閉http通道，HA-Proxy不支持keep-alive模式，只能夠模擬這種模式的實現(xiàn) option forwardfor //如果后端服務器需要獲得客戶端的真實IP需要配置次參數(shù)，將可以從Http Header中獲得客戶端IP capture request header Host len 20 //此配置和一下的類似配置都是抓取Http請求中的參數(shù)記錄到日志中。 capture request header User-Agent len 16 capture request header Content-Length len 10 capture request header Referer len 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中必需有參數(shù)sip_apiname，除非是查看服務器狀態(tài)的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 //后端節(jié)點定義 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表示需要狀態(tài)檢查，fall 5表示失敗五次就認為服務器狀態(tài)不可用（不在接受請求），weight 1表示權重 server app2 10.2.225.136:80 cookie 2 check fall 5 weight 2 backend taobao_server //后端節(jié)點定義 mode http server app3 10.2.226.41:80 check fall 5 完成配置后，執(zhí)行haproxy –f haproxy.cfg，后臺進程就可以啟動了，然后在瀏覽器中輸入剛才定義的狀態(tài)檢查地址可以看到如下內容：
可以看到定義的前端和后端節(jié)點的狀態(tài)。對于Ha-proxy很多配置這里面都沒有使用，也沒有詳細講解，使用者可以通過查看官方的配置文檔了解細節(jié)。下面三個圖片分別說明了對于sip_apiname不同的訪問產生最后的結果。
上圖的sip_apiname為alisoft.get.user，因此被定向到Alisoft集群，也就是136或者139上（這里是136處理了服務）。
上圖的sip_apiname為taobao.get.user，因此被定向到Alisoft集群，也就是41上。
上圖的sip_apiname沒有傳遞，因此被拒絕訪問，返回403錯誤。
HA-Proxy的壓力測試結果簡單的壓力測試采用Apache ab，500并發(fā)用戶，10w的請求總數(shù)。
HA-2Node為配置了兩個節(jié)點作為后段的服務節(jié)點，HA-5Node為配置了5個節(jié)點作為后端的服務處理節(jié)點。上面結果看到2個節(jié)點的HA反而比5個節(jié)點的速度來的快，同時HA在7層的轉發(fā)和LVS-NAT性能相近。
HA-Proxy使用下來，總體上感覺比較簡單，但功能卻十分強大，但是性能方面來說需要關注在多節(jié)點和高壓力的情況下的表現(xiàn)。
“軟”負載均衡學習心得從LVS三種模式中也看到了類似于分布式文件系統(tǒng)的一些設計經驗，就是避免在管理資源過程中，讓Manager成為了系統(tǒng)瓶頸。就好比LVS-NAT中的Load Balancer既負責請求分配同時也負責消息回復，成為了系統(tǒng)的關鍵節(jié)點，自身性能損耗比較大，加上算法對于數(shù)據(jù)采集的要求，自身穩(wěn)定性和可用性下降，最后影響了整個架構。在HDFS中，Master的責任就和明晰，就是負責節(jié)點管理，不參與數(shù)據(jù)傳輸和通道建立，因此就可以很大程度上提升自身的效率。資源管理（申請，歸還，狀態(tài)檢查等）和資源使用應該清晰的劃分開來，這樣可以讓各個角色可以更好的獨立的滿足需求，防止由于其他功能影響到了“本職工作”。 就負載均衡效率來說，硬件實現(xiàn)負載均衡應該優(yōu)于用軟件實現(xiàn)負載均衡，就好比SSL硬件加速器要遠優(yōu)于SSL軟件解析模塊。但從另一個角度來看，分布式計算，分布式存儲，分布式DB都采用橫向擴展結合低成本資源的方式滿足需求。而軟件實現(xiàn)負載在很多情況下可以盡可能的降低成本，同時在性能損失較小的情況下實現(xiàn)硬件負載所支持的所有功能。因此在一定的環(huán)境下，部分采用軟件來實現(xiàn)負載均衡能夠增加可擴展性，提升配置靈活度，降低配置成本。 從LVS到HA-Proxy，可以發(fā)現(xiàn)不論從4層做轉發(fā)還是7層做轉發(fā)都會存在損失，而且LVS-NAT模式和HA-Proxy都會受到解析負載度和內容大小的影響。因此完全采用軟件負載或者采用某一種配置的軟件負載都不可行，通過將硬件負載和軟件負載相結合，或者多種軟件負載混合使用，可以更好的發(fā)揮軟件負載靈活的優(yōu)勢，同時也不會因為轉發(fā)損失影響性能。
附帶： 為了投稿這篇文章壓了很久，同時和軟負載相對應的還有服務隔離機制的文章，后續(xù)會發(fā)，同時對于軟負載的運行期動態(tài)配置也做了嘗試，在HA上效果不錯。當前sip已經采用了軟負載+服務隔離的策略，提高平臺服務質量。
|
|
|
