負載均衡器的問題值得我們學(xué)習(xí)地方有很多，現(xiàn)在，作為補充，我們再來為大家總結(jié)一下。通過前面一些文章的介紹，相信大家已經(jīng)對這部分內(nèi)容有了一定的了解，現(xiàn)在我們要說的問題是關(guān)于算法，會話保持等方面的知識，望能幫助到大家。
Q:F5 Bigip 負載均衡器支持哪些負載均衡算法?
A: F5 Bigip 負載均衡器支持的負載均衡算法包括:
◆輪詢(RoundRobin):順序循環(huán)將請求一次順序循環(huán)地連接每個服務(wù)器?當其中某個服務(wù)器發(fā)生第二到第7 層的故障,BIG/IP 就把其從順序循環(huán)隊列中拿出,不參加下一次的輪詢,直到其恢復(fù)正常?
◆比率(Ratio):給每個服務(wù)器分配一個加權(quán)值為比例,根椐這個比例,把用戶的請求分配到每個服務(wù)器?當其中某個服務(wù)器發(fā)生第二到第7 層的故障,BIG/IP 就把其從服務(wù)器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復(fù)正常?
◆優(yōu)先權(quán)(Priority):給所有服務(wù)器分組,給每個組定義優(yōu)先權(quán),BIG/IP 用戶的請求,分配給優(yōu)先級最高的服務(wù)器組(在同一組內(nèi),采用輪詢或比率算法,分配用戶的請求);當最高優(yōu)先級中所有服務(wù)器出現(xiàn)故障,BIG/IP 才將請求送給次優(yōu)先級的服務(wù)器組?這種方式,實際為用戶提供一種熱備份的方式?
◆最小的連接數(shù)(LeastConnection):傳遞新的連接給那些進行最少連接處理的服務(wù)器?當其中某個服務(wù)器發(fā)生第二到第7 層的故障,BIG/IP 就把其從服務(wù)器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復(fù)正常?
◆最快模式(Fastest):傳遞連接給那些響應(yīng)最快的服務(wù)器?當其中某個服務(wù)器發(fā)生第二到第7層的故障,BIG/IP 就把其從服務(wù)器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復(fù)正常?
◆觀察模式(Observed):連接數(shù)目和響應(yīng)時間以這兩項的最佳平衡為依據(jù)為新的請求選擇服務(wù)器?當其中某個服務(wù)器發(fā)生第二到第7 層的故障,BIG/IP 就把其從服務(wù)器隊列中拿出,不參加下一次的用戶請求的分配,直到其恢復(fù)正常?
◆預(yù)測模式(Predictive):BIG/IP 利用收集到的服務(wù)器當前的性能指標,進行預(yù)測分析,選擇一臺服務(wù)器在下一個時間片內(nèi),其性能將達到最佳的服務(wù)器相應(yīng)用戶的請求?(被big/ip 進行檢測)
◆規(guī)則模式(iRule):針對不同的數(shù)據(jù)流設(shè)置導(dǎo)向規(guī)則,用戶可自行編輯流量分配規(guī)則,BIG/IP利用這些規(guī)則對通過的數(shù)據(jù)流實施導(dǎo)向控制?
Q:F5 Bigip 負載均衡器支持哪些服務(wù)器健康檢查方法?
A:F5 Bigip 負載均衡器支持以下的服務(wù)器健康檢查方法:
服務(wù)器 (Node) - Ping (ICMP)
服務(wù) (Port) - Connect
可擴展的應(yīng)用驗證 (EAV) :不僅僅檢查服務(wù)器上指定服務(wù)的端口是否處于監(jiān)聽狀態(tài),還要檢查該服務(wù)端口能否對應(yīng)用訪問請求作出回應(yīng),例如可以檢查對http 請求或?qū)?shù)據(jù)庫的查詢能否作出回應(yīng)?可擴展的內(nèi)容驗證 (ECV):Bigip 除了可以通過EAV 對服務(wù)進行檢查,還可以通過ECV 對服務(wù)器的響應(yīng)作進一步分析,通過分析讀取服務(wù)器回應(yīng)中的指定內(nèi)容來判斷服務(wù)器上服務(wù)的運行情況?上述檢查方法的檢查頻度(e.g. 10 seconds)與檢查響應(yīng)Timeout 時間( e.g. 5 seconds)都可以根據(jù)應(yīng)用情況進行靈活定制?對于ECV?EAV,在Bigip 中已經(jīng)包含了一些常見應(yīng)用的檢查與內(nèi)容驗證的方法,例如http 的檢查?Ldap?SQL Server 等?如果碰到一些應(yīng)用?Bigip 上沒有提供相應(yīng)的檢查方法,Bigip 還提供了一個擴展的接口,用戶只需要編寫相應(yīng)的應(yīng)用檢查腳本或程序并加載到Bigip 就可實現(xiàn)對該應(yīng)用的檢查或內(nèi)容驗證?
Q:F5 Bigip 支持哪些會話保持方法?
A:
◆簡單會話保持
根據(jù)客戶端源IP 地址保持客戶會話的技術(shù)
◆HTTP Header
根據(jù)HTTP 包頭信息保持會話的技術(shù)
◆SSL ID 會話保持
根據(jù)SSL ID 保持客戶/服務(wù)器連接的技術(shù)
◆HTTP Cookie 會話保持
插入模式,改寫模式, 被動模式, 散列模式(Cookie Hash)
◆SIP ID 會話保持
◆Cache 設(shè)備的專用會話保持
◆i-Mode 移動應(yīng)用的會話保持技術(shù)
◆i-Rules 客戶定制的會話保持方法
Q:請問基于客戶端源地址的會話保持(Persistence)方法有什么優(yōu)缺點?
A:所謂基于源地址的會話保持(在Bigip 應(yīng)用交換機中,又叫作simple persistence 方法)是指負載均衡器在作負載均衡時是根據(jù)訪問請求的源地址作為判斷關(guān)連會話的依據(jù)?對來自同一IP 地址的所有訪問請求在作負載均衡時都會被保持到一臺服務(wù)器上去?基于原地址的會話保持實現(xiàn)起來簡單,只需要根據(jù)數(shù)據(jù)包三?四層的信息就可以實現(xiàn),效率也比較高?存在的問題就在于當多個客戶是通過代理或地址轉(zhuǎn)換的方式來訪問服務(wù)器時,由于都分配到同一臺服務(wù)器上,會導(dǎo)致服務(wù)器之間的負載嚴重失衡?另外一種情況上客戶機數(shù)量很少,但每個客戶機都會產(chǎn)生多個并發(fā)訪問,對這些必發(fā)訪問也要求通過負均均衡器分配到多個服器上,這時基于客戶端源地址的會話保持方法也會導(dǎo)致負載均衡失效?在上述情況只能采用應(yīng)用層的會話保持技術(shù),例如基于http 的cookie, URI, SSLID 或TCP?UDP 包內(nèi)某一指定字段?