不同應用環境下會話保持方式的選擇

會話保持是ADC（應用傳遞控制器）的基本特性，絕大多數的應用環境下都涉及到該功能的配置，如果選擇的會話保持方式不恰當，可能帶來業務處理的不均衡甚至異常，是以能否根據不同的應用環境選擇合适的會話保持方式，就涉及到工程師對應用環境的了解，進而還涉及到客戶對ADC産品運作效果的評價。

絕大多數的負載均衡産品都支援兩類基本的會話保持方式：源/目的位址會話保持和cookie會話保持，另外像hash，URL Persist等也是比較常用的方式，但不是所有裝置都支援。

在應用傳遞環境中我們面臨的常見應用主要有如下幾大類： 基于C/S結構的應用，基于B/S結構（包括三層架構中間件平台）的應用，基于UDP協定的應用，鍊路負載均衡，以及某些特殊的應用等，下面我們具體分析在不同的環境下怎樣選擇合适的會話保持。

<b>基于C/S結構的應用：</b>

該類應用一般選擇（對于某些負載均衡産品來說也是唯一選擇）源位址會話保持。在絕大多數情況下，源位址會話保持工作應該是正常的，但是源位址會話保持有如下弱點：

1) 如果用戶端位址是做了NAT,可能會引起伺服器分發的不均衡。

2) 如果用戶端出口有多條鍊路輪詢分發并做了NAT的，一方面會引起伺服器分發的不均衡，另一方面可能因為源位址的改變導緻會話不能保持，進而引起通路的不正常。

為了保證伺服器分發的均衡性和處理的正确性，必須通過别的方式來實作會話保持， A10公司的AX産品支援基于TCL語言的aFlex腳本，可以靈活地分析四七層的資料包，比如說針對做了NAT的用戶端，aFlex腳本可以不根據源位址做會話保持，而是提取用戶端資料包的某個獨一的字段，用這個字段來為每個用戶端實作會話保持。

<b>基于B/S結構的應用：</b>

對于普通B/S結構的應用内容，例如網站的靜态頁面，可以不用配置任何的會話保持，但是對于一個基于B/S結構尤其是中間件平台的業務系統來說，必須配置會話保持，一般情況下，我們配置源位址會話保持可以滿足需求，但是考慮到用戶端可能有上述不利于源位址會話保持的環境，采用Cookie會話保持是一個更好的方式。Cookie會話保持會把負載均衡裝置選擇的Server資訊儲存在Cookie中發送到用戶端，用戶端持續通路時，會把該Cookie帶來，負載均衡器通過分析Cookie把會話保持到之前標明的伺服器。Cookie分為檔案Cookie和記憶體cookie，檔案cookie儲存在用戶端計算機硬碟上，隻要該cookie檔案不過期，則無論是否重複關閉開放浏覽器都能保持到同一台伺服器。記憶體Cookie則是把Cookie資訊儲存在記憶體中，Cookie的生存時間從打開浏覽器通路開始，關閉浏覽器結束。另外該Cookie的會話保持還跟不同版本的浏覽器有關，IE6之前的浏覽器如果在打開一個浏覽器執行個體的同時再打開一個新的執行個體通路相關的内容，新的浏覽器不會傳遞該Cookie，是以新浏覽器的請求會被當作新的會話來分發。IE6以後的浏覽器如果打開新的執行個體通路相關的内容，則Cookie會話保持會被延續。由于現在的浏覽器對Cookie都有一定預設的安全設定，有些用戶端可能規定不準使用檔案Cookie，是以現在的應用程式開發多使用記憶體Cookie。

然而，記憶體Cookie也不是萬能的，第一，基于它分發的顆粒度仍然不夠細，第二，浏覽器為了安全可能會完全禁用Cookie，這樣Cookie會話保持就失去了作用。怎麼辦？對于普通的隻簡單支援Cookie會話保持的負載均衡裝置确實是束手無策。但是如果結合應用程式的開發我們有别的辦法，大家都知道，某些應用平台特别是中間件平台的開發中常用到Session-id來保持和同步會話，針對禁用Cookie的環境，我們可以通過Session-id來實作會話保持，很不幸，這要求分析處理HTTP包中的Url才能實作，這是讓很多廠家的負載均衡器為難的原因，而這對A10公司的aFlex腳本沒有任何障礙，該腳本可以獲得用戶端Url中的Session-id資訊，并以該Session-id作為判斷會話是否應該保持的依據。如下是aFlex腳本的實作（該腳本同時支援Cookie和Url兩種方式的分析）：

rule sessionid_persist

when HTTP_REQUEST {

set session_id [findstr [HTTP::uri] “JSESSIONID=” 11 “;”]

if { ( $session_id eq “” ) and ( [HTTP::cookie exists JSESSIONID] ) } {

set session_id [HTTP::cookie JSESSIONID]

}

if { $session_id ne “” } {

persist uie $session_id

when HTTP_RESPONSE {

persist add uie $session_id

<b>基于UDP協定的應用：</b>

基于UDP協定的應用最常見的是DNS和Radius負載均衡。DNS應用基本上不涉及到會話保持，Radius應用稍微有點複雜，由于Bras裝置和Radius伺服器會形成長連接配接，一種需求是要求負載均衡裝置能夠随着每個請求關閉之前會話并重新選擇會話，A10裝置針對Radius負載均衡專門支援Stateless Per-Packet Round Robin的負載均衡政策，可以讓非常均衡地把不同資料包分發到不同的伺服器。實作以上需求要求每台Radius Server都可以處理任意的請求包，例如認證請求到達Server1, 計費請求到達Server2這種處理是沒問題的，另外是多台Radius Server之間能夠共享同步Bras傳遞過來的使用者狀态。由于以上要求可能原來的Radius系統無法實作，那麼可能客戶會要求基于單個使用者的請求和計費來實作會話保持，這就必須在資料包中分離每個使用者并實作會話保持，A10裝置同樣是通過aFlex來實作的。

<b>鍊路負載均衡中的會話保持:</b>

鍊路負載均衡的會話保持常用的是基于源位址和目的位址的會話保持，基于源位址選擇鍊路來分發資料包時常采用源位址會話保持，而基于目的位址選擇鍊路來分發資料包時可以選擇源位址會話保持也可以選擇目的位址會話保持，采用何種會話保持方式還需要考慮使用者内部網絡的結構，例如使用者内網不同的部門分别做了NAT，選擇會話保持方式的不同，可能導緻NAT位址和鍊路的壓力大不相同。保證鍊路負載均衡會話保持正常工作的一個非常重要的因素是NAT位址的保持，假設使用者是在通路網銀，不同的連結通路出去的時候雖然走的是同一條鍊路，但用的不是同一個NAT位址，那麼網銀系統會拒絕處理該使用者的請求。這跟做伺服器負載均衡時，由于用戶端NAT位址變化引起的通路異常是一樣的，當然不排除網銀還有一些安全性方面的措施。A10裝置通常是通過Hash的方式來實作NAT位址的保持和唯一性：

when CLIENT_ACCEPTED {

set remote_addr [IP::local_addr]

set bwfile_group_id [ POLICY::bwlist id $remote_addr chinall ]

scan $remote_addr "%d.%d.%d.%d" a b c d

#set number of CNC/CTC NATs

set ctc_nat_num 5

set cnc_nat_num 5

set ctc_hash [ expr { 1+$d%$ctc_nat_num} ]

set cnc_hash [ expr { 1+$d%$cnc_nat_num} ]

set cnc_nat "cnc_nats_$cnc_hash"

set ctc_nat "ctc_nats_$ctc_hash"

if { ($bwfile_group_id equals 2) and ( [LB::status node 1.1.1.1 ] == "up") } {

         snatpool $cnc_nat

         pool netcom_gw

 } else {

         snatpool $ctc_nat

         pool telecom_gw

    }

<b>其他應用中的會話保持：</b>

A10裝置對于某些專門的應用還提供專門的會話保持方法，比如對于SSL協定的應用，支援基于SSL Session-ID的會話保持，對于SIP協定的應用支援基于SIP的會話保持等，由于需求不夠廣泛，這裡不做一一讨論。

（wyl）

本文轉自 virtualadc 51CTO部落格，原文連結:http://blog.51cto.com/virtualadc/592454