天天看點

負載均衡會話保持技術、原理、産品(以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将會将新來的連接配接認為是新的會話然後進行負載平衡。

基于原位址的會話保持實作起來簡單,隻需要根據資料包三、四層的資訊就可以實作,效率也比較高。存在的問題就在于當多個客戶是通過代理或位址轉換的方式來通路伺服器時,由于都配置設定到同一台伺服器上,會導緻伺服器之間的負載嚴重失衡。另外一種情況上客戶機數量很少,但每個客戶機都會産生多個并發通路,對這些必發通路也要求通過負均均衡器配置設定到多個服器上,這時基于用戶端源位址的會話保持方法也會導緻負載均衡失效。

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的會話保持實際應用範圍大大縮小。