【文章內容簡介】 。 這 12 種局域負載均衡算法包括： 1．靜態(tài)負載均衡算法 輪詢（ Round Robin）：順序循環(huán)將請求一次順序循環(huán)地連接每 個服務器。當其中某個服務器發(fā)生第二到第 7 層的故障， BIGIP 就把其從順序循環(huán)隊列中拿出，不參加下一次的輪詢，直到其恢復正常。 比率（ Ratio）：給每個服務器分配一個加權值為比例，根椐這個比例，把用戶的請求分配到每個服務器。當其中某個服務器發(fā)生第二到第 7 層的故障， BIGIP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。 優(yōu)先權（ Priority）：給所有服務器分組，給每個組定義優(yōu)先權， BIGIP 用戶的請求，分配給優(yōu)先級最高的服務器組（在同一組內，采用輪詢或比率算法，分配用戶的 請求）；當最高優(yōu)先級中所有服務器出現(xiàn)故障， BIGIP 才將請求送給次優(yōu)先級的服務器組。這種方式，實際為用戶提供一種熱備份的方式。 2．動態(tài)負載均衡算法 最少的連接方式（ Least Connection）：傳遞新的連接給那些進行最少連接處理的服務器。當其中某個服務器發(fā)生第二到第 7 層的故障， BIGIP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。 最快模式（ Fastest）：傳遞連接給那些響應最快的服務器。當其中某個服務器發(fā)生第二到第 7 層的故障， BIGIP 就把其從服務器隊列中拿出， 不參加下一次的用戶請求的分配，直到其恢復正常。 觀察模式（ Observed）：連接數(shù)目和響應時間以這兩項的最佳平衡為依據(jù)為新的請求選擇服務器。當其中某個服務器發(fā)生第二到第 7 層的故障， BIGIP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。 預測模式（ Predictive）： BIGIP 利用收集到的服務器當前的性能指標，進行預測分析，選擇一臺服務器在下一個時間片內，其性能將達到最佳的服務器相應用戶的請求。(被 BIGIP 進行檢測 ) 動態(tài)性能分配（ Dynamic RatioAPM):BIGIP 收集到的應用程序和應用服務器的各項性能參數(shù)，動態(tài)調整流量分配。 動態(tài)服務器補充（ Dynamic Server Act.):當主服務器群中因故障導致數(shù)量減少時，動態(tài)地將備份服務器補充至主服務器群。 服務質量 (QoS)：按不同的優(yōu)先級對數(shù)據(jù)流進行分配。 服務類型 (ToS)：按不同的服務類型（在 Type of Field 中標識）對數(shù)據(jù)流進行分配。 規(guī)則模式：針對不同的數(shù)據(jù)流設置導向規(guī)則，用戶可自行編輯流量分配規(guī)則， BIGIP利用這些規(guī)則對通過的數(shù)據(jù)流實施導向控制。 本地服務器 /防火墻健康 檢查機制 BIGIP 除了能夠進行不同 OSI 層面的健康檢查之外，還具有擴展內容驗證 (ECV)和擴展應用查證 (EAV)兩種健康檢查方法。 基本的健康檢查方法有以下幾種： 在 Layer 2 健康檢查涉及到用來對給定的 IP 地址尋找 MAC 地址的地址分辨協(xié)議 (ARP) 請求。因為 BIGIP 設置了真實服務器的 IP 地址，它會發(fā)送針對每一個真實服務器的 IP 地址的 ARP 請求以找到相應的 MAC 地址，服務器會響應這個 ARP 請求，除非它已經停機。 在 Layer 3 健康檢查涉及到對真實服務器發(fā)送 ”ping” 命令。 “ping” 是常用的程序來確認一個 IP 地址是否在網(wǎng)絡中存在，或者用來確認主機是否正常工作。 在 Layer 4， BIGIP 會試圖聯(lián)接到一個特定應用在運行的 TCP 或 UDP 端口。舉例來說，如果 VIP 是被綁定在端口 80 做 Web 應用的話， BIGIP 試圖建立一個聯(lián)接到真實服務器的 80 端口。 BIGIP 發(fā)送一個 TCP SYN 請求包到每個真實服務器的 80 端口，并檢查回應的 TCP SYN ACK 數(shù)據(jù)包是否收到，如果哪一個沒有收到， BIGIP 就確認那臺服務器不能正常提供服務， BIGIP 單獨針對服務器的每個應用端口做健康檢查并單獨 做關于其服務器的診斷結果是非常重要的。這樣一來真實服務器的 80 服務可能停機，但是端口 21 可能正常工作， BIGIP 可以繼續(xù)利用這個服務器的 21 端口提供 FTP 服務，同時確認這個服務器的 Web應用已經停機，這樣一來就提供了一個高效率的負載均衡解決方案，細分健康檢查的做法有效地提高了服務器的處理能力。 擴展內容查證 (ECV： Extended Content Verification)： ECV 是一種非常復雜的服務檢查，主要用于確認應用程序能否對請求返回對應的數(shù)據(jù)。如果一個應用對該服務檢查做出響應并返回對應的數(shù)據(jù)， 則 BIGIP 控制器將該服務器標識為工作良好。如果服務器不能返回相應的數(shù)據(jù)，則將該服務器標識為宕機。宕機一旦修復， BIGIP 就會自動查證應用已能對客戶請求做出正確響應并恢復向該服務器傳送。該功能使 BIGIP可以將保護延伸到后端應用如 Web 內容及數(shù)據(jù)庫。 BIGIP的 ECV功能允許您向 Web 服務器、防火墻、緩存服務器、代理服務器和其它透明設備發(fā)送查詢，然后檢查返回的響應。這將有助于確認您為客戶提供的內容正是其所需要的。 用戶可以定義發(fā)送和接收的字串，發(fā)送字串是指發(fā)送到一個服務器的請求命令，例如： “GET /” 字串發(fā)送到一個 HTTP 服務器。 服務器回應得字串必須與接收到的字串相匹配，例如 “” 。 ECV 可以工作在正常和透明節(jié)點模式。 擴展應用查證 (EAV: Extended Application Verification)： EAV 是另一種服務檢查，用于確認運行在某個服務器上的應用能否對客戶請求做出響應。為完成這種檢查， BIGIP 控制器使用一個被稱作外部服務檢查者的客戶程序，該程序為BIGIP 提供完全客戶化的服務檢查功能，但它位于 BIGIP 控制器的外部。例如，該外部服務檢查者可以查證一個 從后臺數(shù)據(jù)庫中取出數(shù)據(jù)的應用能否正常工作。 EAV 是BIGIP 提供的非常獨特的功能，它提供管理者將 BIGIP 客戶化后訪問各種各樣應用的能力，該功能使 BIGIP 在提供標準的可用性查證之外能獲得服務器、應用及內容可用性等最重要的反饋。該功能對于提高系統(tǒng)可靠性至關重要，它用于從客戶的角度測試您的站點。例如，您可以模擬客戶完成交易所需的所有步驟－連接到前置服務器或中間件服務器、從目錄中選擇項目以及驗證交易使用的信用卡。一旦 BIGIP 掌握了該“可用性”信息，即可利用負載平衡使資源達到最高的可用性。 BIGIP 已 經為測試多種服務的健康情況和狀態(tài)，預定義了擴展應用驗證 (EAV)，如： FTP、 NNTP、 SMTP、 POP3 和 MSSQL等，用戶還可依據(jù)實際應用，自行編輯 EAV 腳本。 F5 產品健康檢查的頻度和間隔是可以根據(jù)用戶的要求而設置。 通過 F5 靈活自定義方式的 ECV 健康檢查方式，用戶可以檢查常見的應用如 HTTP、SMTP、 POP3 等。而通過 EAV 健康檢查方式，更可自行編寫腳本，實現(xiàn)更加復雜的健康檢查方式，全面的檢測后臺服務器的運行狀態(tài)，保證系統(tǒng)運行的高效，可靠。 會話保持技術 當使用 BIGIP 對服務器進行負載均 衡時，就需要會話保持。如果某位用戶連接到了一臺服務器上，那么我們肯定希望該用戶在將來再次連接時將仍可連接到該臺服務器上。當該服務器存有用戶相關數(shù)據(jù)，并且這些數(shù)據(jù)并不與其它服務器動態(tài)共享時，持續(xù)性就顯得十分有必要了。例如，假設一位用戶在某網(wǎng)站采購了一“購物車”的商品，然后還未結帳就離開了該網(wǎng)站。如果在其重新登錄網(wǎng)站后， BIGIP 應用交換機 將客戶請求路由至不同的服務器，那么新的服務器對該用戶的數(shù)據(jù)和其所購買的商品將一無所知。當然，如果所有服務器都在同一個后臺數(shù)據(jù)庫服務器中存儲用戶信息及其選購商品的話，那么一切 就不成問題了。但是如果網(wǎng)站不是這樣設計的，那么具體的購物車數(shù)據(jù)就只能存儲在特定的服務器上。這樣， BIGIP 應用交換機 就必需選擇用戶曾連接上的那臺服務器，以無縫地處理用戶請求。 BIGIP 提供以下幾種會話保持方法： Simple Persistence， SSL Session ID Persistence，SIP Persistence， Cookie Persistence， iMode Persistence，目的地址歸類。 Simple Persistence：根據(jù)源地址做會話保持，即相同源地址的訪問請求 定位在同一臺服務器上面。 SSL Session ID Persistence：根據(jù) SSL 會話 ID 做會話保持。 SIP Persistence： SIP 協(xié)議會話保持技術。 HTTP Cookie Persistence： BIGIP 支持四種 Cookie 會話保持技術，即：改寫模式，插入模式，被動的 cookie， Cookie 散列。 1．在 Cookie 改 寫模式下，服務器將插入一個 cookie， 然后 BIGIP 應用交換機 將對其進行重寫，訪問流程如下： 首次命中， HTTP 請求（不帶有 cookie）進入 BIGIP 應用交 換機 ， BIGIP 應用交換機 任選一臺服務器，將請求發(fā)送至該服務器，來自該服務器的 HTTP 回復此時包括一個空白的 cookie， BIGIP 應用交換機 重寫 cookie，并在粘貼一個特殊的 cookie 后將 HTTP回復發(fā)送回去。 再次命中 ， HTTP 請求（帶有與上面同樣的 cookie）進入 BIGIP 應用交換機 ， BIGIP應用交換機 借助 cookie 信息確定合適的服務器， HTTP 請求（帶有與上面同樣的 cookie）進入服務器， HTTP 回復（帶有空白 cookie）返回 BIGIP 應用交換機 ，后者將向客戶機提供更新后的 cookie。如圖 所示： 圖 Cookie 會話保持改寫模式 2． 在 Cookie 插入 模式下， BIGIP 插入一個 cookie， 服務器無需作出任何修改 ， 訪問流程如下 ： 首次命中， HTTP 請求（不帶 cookie）進入 BIGIP 應用交換機 ， BIGIP 應用交換機任選一臺服務器，將請求發(fā)送至該服 務器， HTTP 回復（不帶 cookie）被發(fā)回 BIGIP 應用交換機 BIGIP 應用交換機 插入 cookie，將 HTTP 回復返回到客戶機