負載均衡設備會話保持機制介紹
會話持久性連接簡介：
會話保持是負載均衡器設備的一種機制，用於識別客戶端與服務器之間交互過程的關連性，在進行負載均衡的同時還保證一系列相關連的訪問請求會保持分配到同一臺服務器上?針對不同的業務場景需要不同的會話保持配置，並且並不是所有業務系統都需要會話保持配置。以最典型的 HTTP 應用為例，在大多數電子商務的應用系統或者需要進行用戶身份認證的在線系統中，一個客戶與服務器經常經過好幾次的交互過程才能完成一筆交易或者是一個請求的完成。由於這幾次交互過程是密切相關的，服務器在進行這些交互過程的某一個交互步驟時，往往需要了解上一次交互過程的處理結果，或者上幾步的交互過程結果，服務器進行下一步操作時需要這就要求所有這些相關的交互過程都由一臺服務器完成，而不能被負載均衡器分散到不同的服務器上
常用會話保持技術介紹：
1.源地址會話持久性 (Source Address Affinity)：
源地址會話持久性（也稱為簡單持久性）僅基於源IP地址跟蹤會話。當客戶端請求連接發送到配置源地址持久性的虛擬服務器時，負載均衡會檢查該客戶端之前是否已連接，如果負載均衡設備已存在當前客戶端的會話保持連接條目，負載均衡設備會將請求發送至後端相同服務器。源地址會話保持裏另外一個很重要的參數就是連接超時值，會為每一個進行會話保持的會話設定一個超時時間，當一個會話上一次完成到這個會話下次再來之前的間隔如果小於這個超時值，
基於源地址的會話保持實現起來簡單，只需要根據數據包三、四層的信息就可以實現，效率也比較高。存在的問題就在於當多個客戶是通過代理或地址轉換的方式來訪問服務器時，由於都分配到同一臺服務器上，會導致服務器之間的負載嚴重失衡。另外一種情況上客戶機數量很少，但每個客戶機都會產生多個並發訪問，對這些並發訪問也要求通過負載均衡器分配到多個服器上，這時基於客戶端源地址的會話保持方法也會導致負載均衡失效。
- Cookie 會話保持 ：
Cookie會話持久性是
針對不同的場景有四種cookie持久性方法可供使用：
HTTP Cookie插入方法 (HTTP Cookie Insert)
HTTP Cookie重寫方法 (HTTP Cookie Passive)
HTTP Cookie被動方法 (HTTP Cookie Rewrite)
Cookie哈希方法 (Cookie Hash)
HTTP Cookie插入方法:
客戶端請求負載均衡設備，在負載均衡將請求返回客戶端時，在HTTP 響應
標頭的cookie 字插入負載均衡自定義的cookie 信息。在客戶端再次訪問時負載均衡設備通過HTTP 請求報文頭部的cookie 信息將客戶端請求始終發送至後端相同服務器。
HTTP Cookie重寫方法：
HTTP Cookie重寫方法，是指負載均衡器會截取從服務器發送到客戶端的名為的 Cookie標頭，並覆蓋cookie的名稱和值。新cookie名為負載均衡設備自定義的cookie 名稱，一般包含處理連接的服務器的地址和端口。
HTTP Cookie被動方法 ：
負載均衡將請求發送至該服務器，後端服務器進行HTTP響應一個cookie並發回負載均衡設備，然後負載均衡設備將帶有服務器寫的cookie值的HTTP回復返回到客戶端。當客戶請求再次發生時，客戶HTTP請求（帶有上次服務器寫的cookie）進入負載，然後負載根據cookie頭裏的cookie 信息，將HTTP請求發送至指定服務器，簡單理解就是負載均衡設備通過服務器的定義的cookie 數據來定義會話保持條目。
Cookie哈希方法：
Cookie hash 方法是指負載均衡設備將服務器響應的客戶端的cookie 信息與後端服務器IP地址和端口進行hash 。在客戶端再次請求時根據包頭裏包含的cookie信息進行hash 將請求發送至後端指定服務器。
- 哈希會話保持(Hash persistence)：
哈希會話保持的一個基本概念就是將一個連接中的源 IP 和目的 IP 地址進行 Hash 計算，根據計算得到的結果並根據後臺存在多少臺服務器來選擇將請求分配到某臺服務器。哈希會話保持的特點是在後臺服務器的健康狀態不發生改變的時候，每個特定的源 IP地址被分配到的服務器是固定的。並且，哈希會話保持可以沒有會話保持表，而僅僅是根據計算的結果來確定一個源 IP 被分配到那臺服務器。哈希會話保持通常被用於一些特定場合，如要求客戶端按照IP地址被固定分配的場合，或者在一些會話保持表查詢的開銷已經遠遠大於 Hash 計算開銷的情況下，采用 hash 會話保持可以提高系統的處理能力和響應速度。在實際的應用場景中，針對後臺采用 Cache 服務器的情況，還有對 URL 進行 Hash 的處理方式，將同一個 URL 的請求分配到同一臺 Cache 服務器，這樣，對後臺的 Cache 服務器群組來說，每臺 Cache 服務器上存放的內容都是不一樣的，提高 Cache 服務器的利用率。
- 可編程控制的會話保持
在實際的使用過程中，我們往往可能遇到更加復雜的一些情況，一個最典型的情況就是會話的特征並不在一些通常的位置，或者通用的名稱。而是一個自定義的名稱在一個特定的位置，例如 weblogic，AAA 協議的應用......因此在支持編程自定義的負載均衡設備中，可以采用可編程控制方式來實現靈活的會話保持策略。
在可編程控制的會話保持中，會話保持主要由兩個部分組成：
1. 會話保持的特征的獲取
2. 將特征與後臺服務器相對應
如下所示：
|
rule WeblogicJSessionPersist { when HTTP_RESPONSE { //在服務器返回的時候觸發事件 if { [HTTP::cookie exists "JSESSIONID"] } { //在返回內容的 Cookie 中查找 JESSIONID persist add uie [HTTP::cookie "JSESSIONID"] //將服務器與找到的 Cookie 內 容進行對應 } } when HTTP_REQUEST { //在客戶端發起請求的時候觸發事件 set jsess [findstr [HTTP::uri] "jsessionid" 11 ";"] //在請求的 URI 中查找 jessionid 字符串，方法是獲取從 URI 中找到 jsessionid 字符串，在該字符串之後開始獲取內容直 到遇到分號結束（具體語法請參考 BIG-IP LTM-LTM 配置手冊） if { $jsess != "" } { persist uie $jsess //如果找到，則查詢會話保持表，根據匹配結果將請求發送到 對應的服務器上 } } }
|
- 目的地址會話保持(Destination Address Affinity)：
顧名思義目的地址會話保持通過目的地址進行會話保持的技術，通常在負載均衡設備作為正向代理服務器時，將客戶端發送的請求始終發送到相同網關時會選擇目的地址會話保持，此功能不常用。
總結：
在大多數後臺應用系統的設計中，沒有實際考慮到將被應用於負載均衡的環境中，為了保持在用戶訪問時與單機運行環境的一致，因此，在負載均衡設備上必須采用會話保持功能。在基於http 協議訪問的應用系統中，強烈建議采用 HTTP Cookie插入方法的會話保持，不需要後端服務器進行任何修改，真正基於會話的會話保持技術。還有大部分應用是基於接口的業務，其中並不是所有業務系統都需要會話保持，在需要會話保持的系統中，建議采用源地址會話保持，其中的超時時間的設置需要業務部門根據實際的業務需求評估出一個合理的值，長時間維護無效的會話保持條目會對負載均衡設備造成較大壓力。針對其他的應用場景需要和業務部門進行詳細溝通提出針對的會話保持方式才能夠合理的進行配置。
負載均衡設備會話保持機制介紹