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