F5負載均衡算法以及會話保持
1．什么是會話保持？
在大多數(shù)電子商務(wù)的應(yīng)用系統(tǒng)或者需要進行用戶身份認證的在線系統(tǒng)中，一個客戶與服務(wù)器經(jīng)常經(jīng)過好幾次的交互過程才能完成一筆交易或者是一個請求的完成。由于這幾次交互過程是密切相關(guān)的，服務(wù)器在進行這些交互過程的某一個交互步驟時，往往需要了解上一次交互過程的處理結(jié)果，或者上幾步的交互過程結(jié)果，服務(wù)器進行下一步操作時需要這就要求所有這些相關(guān)的交互過程都由一臺服務(wù)器完成，而不能被負載均衡器分散到不同的服務(wù)器上。 而這一系列的相關(guān)的交互過程可能是由客戶到服務(wù)器的一個連接的多次會話完成，也可能是在客戶與服務(wù)器之間的多個不同連接里的多次會話完成。不同連接的多次會話，最典型的例子就是基于http的訪問，一個客戶完成一筆交易可能需多次點擊，而一個新的點擊產(chǎn)生的請求，可能會重用上一次點擊建立起來的連接，也可能是一個新建的連接。 會話保持就是指在負載均衡器上有這么一種機制，可以識別做客戶與服務(wù)器之間交互過程的關(guān)連性，在作負載均衡的同時，還保證一系列相關(guān)連的訪問請求會保持分配到一臺服務(wù)器上。
2． F5支持什么樣的會話保持方法？
F5 BigIP支持多種的會話保持方法，其中包括：簡單會話保持（源地址會話保持）、HTTP Header的會話保持，基于SSL Session ID的會話保持，I-Rules會話保持以及基于 HTTP Cookie的會話保持，此外還有基于SIP ID以及Cache設(shè)備的會話保持等，但常用的是簡單會話保持，HTTP Header的會話保持以及 HTTP Cookie會話保持以及基于I-Rules的會話保持。
2.1 簡單會話保持
簡單會話保持也被稱為基于源地址的會話保持，是指負載均衡器在作負載均衡時是根據(jù)訪問請求的源地址作為判斷關(guān)連會話的依據(jù)。對來自同一IP地址的所有訪問請求在作負載均時都會被保持到一臺服務(wù)器上去。在BIGIP設(shè)備上可以為“同一IP地址”通過網(wǎng)絡(luò)掩碼進行區(qū)分，比如可以通過對IP地址192.168.1.1進行255.255.255.0的網(wǎng)絡(luò)掩碼，這樣只要是來自于192.168.1.0/24這個網(wǎng)段的流量BIGIP都可以認為他們是來自于同一個用戶，這樣就將把來自于192.168.1.0/24網(wǎng)段的流量會話保持到特定的一臺服務(wù)器上。 簡單會話保持里另外一個很重要的參數(shù)就是連接超時值，BIGIP會為每一個進行會話保持的會話設(shè)定一個時間值，當一個會話上一次完成到這個會話下次再來之前的間隔如果小于這個超時值，BIGIP將會將新的連接進行會話保持，但如果這個間隔大于該超時值，BIGIP將會將新來的連接認為是新的會話然后進行負載平衡。 基于原地址的會話保持實現(xiàn)起來簡單，只需要根據(jù)數(shù)據(jù)包三、四層的信息就可以實現(xiàn)，效率也比較高。存在的問題就在于當多個客戶是通過代理或地址轉(zhuǎn)換的方式來訪問服務(wù)器時，由于都分配到同一臺服務(wù)器上，會導(dǎo)致服務(wù)器之間的負載嚴重失衡。另外一種情況上客戶機數(shù)量很少，但每個客戶機都會產(chǎn)生多個并發(fā)訪問，對這些必發(fā)訪問也要求通過負均均衡器分配到多個服器上，這時基于客戶端源地址的會話保持方法也會導(dǎo)致負載均衡失效。
2.2 基于Cookie的會話保持
2.2.1 cookie插入模式： 在Cookie插入模式下，BigIP將負責(zé)插入cookie，后端服務(wù)器無需作出任何修改.當客戶進行第一次請求時，客戶HTTP請求（不帶cookie）進入BIGIP， BIGIP根據(jù)負載平衡算法策略選擇后端一臺服務(wù)器，并將請求發(fā)送至該服務(wù)器，后端服務(wù)器進行HTTP回復(fù)（不帶cookie）被發(fā)回BIGIP，然后BIGIP插入cookie，將HTTP回復(fù)返回到客戶端。當客戶請求再次發(fā)生時，客戶HTTP請求（帶有上次BIGIP插入的cookie）進入BIGIP，然后BIGIP讀出cookie里的會話保持數(shù)值，將HTTP請求（帶有與上面同樣的cookie）發(fā)到指定的服務(wù)器，然后后端服務(wù)器進行請求回復(fù)，由于服務(wù)器并不寫入cookie，HTTP回復(fù)將不帶有cookie，恢復(fù)流量再次經(jīng)過進入BIGIP時，BIGIP再次寫入更新后的會話保持cookie。
2.2.2 Cookie 重寫模式 當客戶進行第一次請求時，客戶HTTP請求（不帶cookie）進入BIGIP， BIGIP根據(jù)負載平衡算法策略選擇后端一臺服務(wù)器，并將請求發(fā)送至該服務(wù)器，后端服務(wù)器進行HTTP回復(fù)一個空白的cookie并發(fā)回BIGIP，然后BIGIP重新在cookie里寫入會話保持數(shù)值，將HTTP回復(fù)返回到客戶端。當客戶請求再次發(fā)生時，客戶HTTP請求（帶有上次BIGIP重寫的cookie）進入BIGIP，然后BIGIP讀出cookie里的會話保持數(shù)值，將HTTP請求（帶有與上面同樣的cookie）發(fā)到指定的服務(wù)器，然后后端服務(wù)器進行請求回復(fù)，HTTP回復(fù)里又將帶有空的cookie，恢復(fù)流量再次經(jīng)過進入BIGIP時，BIGIP再次寫入更新后會話保持數(shù)值到該cookie。
2.2.3 Passive Cookie 模式，服務(wù)器使用特定信息來設(shè)置cookie。 當客戶進行第一次請求時，客戶HTTP請求（不帶cookie）進入BIGIP， BIGIP根據(jù)負載平衡算法策略選擇后端一臺服務(wù)器，并將請求發(fā)送至該服務(wù)器，后端服務(wù)器進行HTTP回復(fù)一個cookie并發(fā)回BIGIP，然后BIGIP將帶有服務(wù)器寫的cookie值的HTTP回復(fù)返回到客戶端。當客戶請求再次發(fā)生時，客戶HTTP請求（帶有上次服務(wù)器寫的cookie）進入BIGIP，然后BIGIP根據(jù)cookie里的會話保持數(shù)值，將HTTP請求（帶有與上面同樣的cookie）發(fā)到指定的服務(wù)器，然后后端服務(wù)器進行請求回復(fù)，HTTP回復(fù)里又將帶有更新的會話保持cookie，恢復(fù)流量再次經(jīng)過進入BIGIP時，BIGIP將帶有該cookie的請求回復(fù)給客戶端。
2.2.4 Cookie Hash模式： 當客戶進行第一次請求時，客戶HTTP請求（不帶cookie）進入BIGIP， BIGIP根據(jù)負載平衡算法策略選擇后端一臺服務(wù)器，并將請求發(fā)送至該服務(wù)器，后端服務(wù)器進行HTTP回復(fù)一個cookie并發(fā)回BIGIP，然后BIGIP將帶有服務(wù)器寫的cookie值的HTTP回復(fù)返回到客戶端。當客戶請求再次發(fā)生時，客戶HTTP請求（帶有上次服務(wù)器寫的cookie）進入BIGIP，然后BIGIP根據(jù)cookie里的一定的某個字節(jié)的字節(jié)數(shù)來決定后臺服務(wù)器接受請求，將HTTP請求（帶有與上面同樣的cookie）發(fā)到指定的服務(wù)器，然后后端服務(wù)器進行請求回復(fù)，HTTP回復(fù)里又將帶有更新后的cookie，恢復(fù)流量再次經(jīng)過進入BIGIP時，BIGIP將帶有該cookie的請求回復(fù)給客戶端。
2.3 SSL Session ID會話保持
在用戶的SSL訪問系統(tǒng)的環(huán)境里，當SSL對話首次建立時，用戶與服務(wù)器進行首次信息交換以：1}交換安全證書，2）商議加密和壓縮方法，3）為每條對話建立Session ID。由于該Session ID在系統(tǒng)中是一個唯一數(shù)值，由此，BIGIP可以應(yīng)用該數(shù)值來進行會話保持。當用戶想與該服務(wù)器再次建立連接時，BIGIP可以通過會話中的 SSL Session ID識別該用戶并進行會話保持。
基于SSL Session ID的會話保持就需要客戶瀏覽器在進行會話的過程中始終保持其SSL Session ID不變，但實際上，微軟Internet Explorer被發(fā)現(xiàn)在經(jīng)過特定一段時間后將主動改變SSL Session ID，這就使基于SSL Session ID的會話保持實際應(yīng)用范圍大大縮小。
靜態(tài)負載均衡算法
◆輪詢（Round Robin）：順序循環(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ù)器組。這種方式，實際為用戶提供一種熱備份的方式。
◆最少的連接方式（Least Connection）：傳遞新的連接給那些進行最少連接處理的服務(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 進行檢測)
◆動態(tài)性能分配(Dynamic Ratio-APM):BIG-IP 收集到的應(yīng)用程序和應(yīng)用服務(wù)器的各項性能參數(shù)，動態(tài)調(diào)整流量分配。
◆動態(tài)服務(wù)器補充(Dynamic Server Act.):當主服務(wù)器群中因故障導(dǎo)致數(shù)量減少時，動態(tài)地將備份服務(wù)器補充至主服務(wù)器群。
◆服務(wù)質(zhì)量(QoS）:按不同的優(yōu)先級對數(shù)據(jù)流進行分配。
◆服務(wù)類型(ToS): 按不同的服務(wù)類型（在Type of Field中標識）負載均衡對數(shù)據(jù)流進行分配。
◆規(guī)則模式：針對不同的數(shù)據(jù)流設(shè)置導(dǎo)向規(guī)則，用戶可自行。