負載均衡會話保持技術、原理、產品(以F5爲例)

1．什麼是會話保持？ 在大多數電子商務的應用系統或者須要進行用戶身份認證的在線系統中，一個客戶與服務器常常通過好幾回的交互過程才能完成一筆交易或者是一個請求的完成。因爲這幾回交互過程是密切相關的，服務器在進行這些交互過程的某一個交互步驟時，每每須要瞭解上一次交互過程的處理結果，或者上幾步的交互過程結果，服務器進行下一步操做時須要這就要求全部這些相關的交互過程都由一臺服務器完成，而不能被負載均衡器分散到不一樣的服務器上。 而這一系列的相關的交互過程多是由客戶到服務器的一個鏈接的屢次會話完成，也多是在客戶與服務器之間的多個不一樣鏈接裏的屢次會話完成。不一樣鏈接的屢次會話，最典型的例子就是基於http的訪問，一個客戶完成一筆交易可能需屢次點擊，而一個新的點擊產生的請求，可能會重用上一次點擊創建起來的鏈接，也多是一個新建的鏈接。 會話保持就是指在負載均衡器上有這麼一種機制，能夠識別作客戶與服務器之間交互過程的關連性，在做負載均衡的同時，還保證一系列相關連的訪問請求會保持分配到一臺服務器上。 2． F5支持什麼樣的會話保持方法？ F5 BigIP支持多種的會話保持方法，其中包括：簡單會話保持（源地址會話保持）、HTTP Header的會話保持，基於SSL Session ID的會話保持，I-Rules會話保持以及基於 HTTP Cookie的會話保持，此外還有基於SIP ID以及Cache設備的會話保持等，但經常使用的是簡單會話保持，HTTP Header的會話保持以及 HTTP Cookie會話保持以及基於I-Rules的會話保持。 2.1 簡單會話保持 簡單會話保持也被稱爲基於源地址的會話保持，是指負載均衡器在做負載均衡時是根據訪問請求的源地址做爲判斷關連會話的依據。對來自同一IP地址的全部訪問請求在做負載均時都會被保持到一臺服務器上去。在BIGIP設備上能夠爲「同一IP地址」經過網絡掩碼進行區分，好比能夠經過對IP地址192.168.1.1進行255.255.255.0的網絡掩碼，這樣只要是來自於192.168.1.0/24這個網段的流量BIGIP均可以認爲他們是來自於同一個用戶，這樣就將把來自於192.168.1.0/24網段的流量會話保持到特定的一臺服務器上。 簡單會話保持裏另一個很重要的參數就是鏈接超時值，BIGIP會爲每個進行會話保持的會話設定一個時間值，當一個會話上一次完成到這個會話下次再來以前的間隔若是小於這個超時值，BIGIP將會將新的鏈接進行會話保持，但若是這個間隔大於該超時值，BIGIP將會將新來的鏈接認爲是新的會話而後進行負載平衡。 基於原地址的會話保持實現起來簡單，只須要根據數據包3、四層的信息就能夠實現，效率也比較高。存在的問題就在於當多個客戶是經過代理或地址轉換的方式來訪問服務器時，因爲都分配到同一臺服務器上，會致使服務器之間的負載嚴重失衡。另一種狀況上客戶機數量不多，但每一個客戶機都會產生多個併發訪問，對這些必發訪問也要求經過負均均衡器分配到多個服器上，這時基於客戶端源地址的會話保持方法也會致使負載均衡失效。 2.2 基於Cookie的會話保持 2.2.1 cookie插入模式： 在Cookie插入模式下，BigIP將負責插入cookie，後端服務器無需做出任何修改.當客戶進行第一次請求時，客戶HTTP請求（不帶cookie）進入BIGIP， BIGIP根據負載平衡算法策略選擇後端一臺服務器，並將請求發送至該服務器，後端服務器進行HTTP回覆（不帶cookie）被髮回BIGIP，而後BIGIP插入cookie，將HTTP回覆返回到客戶端。當客戶請求再次發生時，客戶HTTP請求（帶有上次BIGIP插入的cookie）進入BIGIP，而後BIGIP讀出cookie裏的會話保持數值，將HTTP請求（帶有與上面一樣的cookie）發到指定的服務器，而後後端服務器進行請求回覆，因爲服務器並不寫入cookie，HTTP回覆將不帶有cookie，恢復流量再次通過進入BIGIP時，BIGIP再次寫入更新後的會話保持cookie。 2.2.2 Cookie 重寫模式 當客戶進行第一次請求時，客戶HTTP請求（不帶cookie）進入BIGIP， BIGIP根據負載平衡算法策略選擇後端一臺服務器，並將請求發送至該服務器，後端服務器進行HTTP回覆一個空白的cookie併發回BIGIP，而後BIGIP從新在cookie裏寫入會話保持數值，將HTTP回覆返回到客戶端。當客戶請求再次發生時，客戶HTTP請求（帶有上次BIGIP重寫的cookie）進入BIGIP，而後BIGIP讀出cookie裏的會話保持數值，將HTTP請求（帶有與上面一樣的cookie）發到指定的服務器，而後後端服務器進行請求回覆，HTTP回覆裏又將帶有空的cookie，恢復流量再次通過進入BIGIP時，BIGIP再次寫入更新後會話保持數值到該cookie。 2.2.3 Passive Cookie 模式，服務器使用特定信息來設置cookie。 當客戶進行第一次請求時，客戶HTTP請求（不帶cookie）進入BIGIP， BIGIP根據負載平衡算法策略選擇後端一臺服務器，並將請求發送至該服務器，後端服務器進行HTTP回覆一個cookie併發回BIGIP，而後BIGIP將帶有服務器寫的cookie值的HTTP回覆返回到客戶端。當客戶請求再次發生時，客戶HTTP請求（帶有上次服務器寫的cookie）進入BIGIP，而後BIGIP根據cookie裏的會話保持數值，將HTTP請求（帶有與上面一樣的cookie）發到指定的服務器，而後後端服務器進行請求回覆，HTTP回覆裏又將帶有更新的會話保持cookie，恢復流量再次通過進入BIGIP時，BIGIP將帶有該cookie的請求回覆給客戶端。 2.2.4 Cookie Hash模式： 當客戶進行第一次請求時，客戶HTTP請求（不帶cookie）進入BIGIP， BIGIP根據負載平衡算法策略選擇後端一臺服務器，並將請求發送至該服務器，後端服務器進行HTTP回覆一個cookie併發回BIGIP，而後BIGIP將帶有服務器寫的cookie值的HTTP回覆返回到客戶端。當客戶請求再次發生時，客戶HTTP請求（帶有上次服務器寫的cookie）進入BIGIP，而後BIGIP根據cookie裏的必定的某個字節的字節數來決定後臺服務器接受請求，將HTTP請求（帶有與上面一樣的cookie）發到指定的服務器，而後後端服務器進行請求回覆，HTTP回覆裏又將帶有更新後的cookie，恢復流量再次通過進入BIGIP時，BIGIP將帶有該cookie的請求回覆給客戶端。 2.3 SSL Session ID會話保持 在用戶的SSL訪問系統的環境裏，當SSL對話首次創建時，用戶與服務器進行首次信息交換以：1}交換安全證書，2）商議加密和壓縮方法，3）爲每條對話創建Session ID。因爲該Session ID在系統中是一個惟一數值，由此，BIGIP能夠應用該數值來進行會話保持。當用戶想與該服務器再次創建鏈接時，BIGIP能夠經過會話中的 SSL Session ID識別該用戶並進行會話保持。 基於SSL Session ID的會話保持就須要客戶瀏覽器在進行會話的過程當中始終保持其SSL　Session ID不變，但實際上，微軟Internet Explorer被髮如今通過特定一段時間後將主動改變SSL Session ID，這就使基於SSL Session ID的會話保持實際應用範圍大大縮小。