集羣安裝
爲了在TOMCAT5容器中SESSION複製可用，必須完成以下步驟：
● 爲了集羣能夠工作，你必須使用你係統上的多點傳送可使用
● 爲了有些使用SESSION複製，所有TOMCAT例程必須同樣配置。這意味着WEB應用程序必須統一的部署在集羣中的每臺服務器上。這些配置同樣簡化了集羣管理，維護和發現維修故障的任務。
● 在server.xml未註釋的Cluster 和Valve (ReplicationValve) 元素。起用server.xm中的CLUSTER元素意味着所有WEB CONTEXT的SESSION管理器將會改變。因此 當運行一個集羣的時候，你應該確保只有一個需要被集成WEB應用程序並且移除其他的。
● 如果服務器例程運行在同樣的機器上，應該確保每個例程的tcpListenPort屬性是一致的。
● 確保web.xml有distributable屬性
● 所有的SESSION屬性必須實現java.io.Serializable接口
範例集羣安裝有兩個TOMCAT例程和一個負載平衡用於分配服務器間的請求。所有三個服務器都運行在一個單獨的機器上，以下表格列出了集羣和負載平衡上的配置參數。
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
編輯註解：以上Web App Directory中的值爲了適應排版而換行了。在你的部署中，每個值應該是單一而完整的一行
注意：不要設置tcpListenAddress爲127.0.0.1，因爲127用於迴環地址，在SESSION複製期間可能會出現問題。
負載平衡器安裝
TOMCAT服務器不提供失效轉移能力用於當一個集羣接點失效的時候重定向任何引入的請求到下一個可用的服務器上。所以我使用一個分開的負載平衡器去管理WEB請求的負載平衡。有一些流行的負載平衡器例如Apache/mod_jk, Balance, 和 Pen。我在範例集羣安裝中使用Pen作爲負載平衡器。
Pen是一個簡單的，基於TCP協議，例如HTTP或者SMTP的負載平衡器。他允許多個服務器對外表現爲一個服務器，並且自動檢測關閉的服務器，在可用的服務器間分配客戶斷。他提供了負載平衡和失效轉移能力。Pen易於安裝以及配置，非常容易使用和運行在Windows和UNIX操做系統上。範例配置使用round-robin負載平衡算法用於在集羣節點間分配負載平衡
運行負載平衡器的命令如下：
pen -r -a -f -d localhost:8080 192.168.0.10:9080 192.168.0.20:10080
以下是用於啓動負載平衡器的每個命令行參數的解釋
-r: 使用round robin負載平衡
-a: 打印來回發送的ASCII格式的數據
-f: 保持在前臺
-d: 起用DEBUG模式
想要知道更多用於啓動PEN的參數細節，請訪問PEN網站
圖表1展示了兩個集羣節點，一個負載平衡器，儀器層，以及測試客戶端的拓撲圖
Figure 1. Cluster setup diagram
測試安裝
我創建了一個叫做clusterapp的WEB應用程序來驗證集羣安裝以及SESSION複製原理。爲了測試真實的SESSION複製，我寫了一個叫做SessionReplicationClient的簡單JAVA客戶端用語測試從一個服務器拷貝SESSION數據到另外一個服務器的需要的時間。這個客戶端使用Jakarta Commons HttpClient況架去創建和操作HTTP SESSION並且調用TOMCAT服務器上的一個SERVLET。用於測試SESSION複製的機器軟硬件配置如下：
● CPU: HP Pavilion Pentium III 800MHz
● Memory: 512MB RAM
● Hard disk: 40GB
● Operating system: Windows 2000 server
● JDK version: 1.4.2_05 (Note: JDK 1.4 or later version is required to use clustering and session replication)
● Tomcat version: 5.0.28
● Tools: Pen, Log4J, Eclipse, Commons HttpClient
當一個複製客戶端程序運行的時候，他首先設置一個作用指令用於這樣操縱SESSION（例如，添加一個新的屬性到SESSION，從SESSION中移除一個已存在的屬性，或則讓一個SESSION失效）。然後客戶端通過在Commons HttpClient框架使用HttpClient和PostMethod類調用ReplicationServlet。基於這些SESSION命令，servlet生成一個新的SEESION或者修改一個已經存在的SESSION並且轉到一個WEB頁面中瞻示SESSION細節。如果在管理SESSION中有任何錯誤，則轉到一個錯誤頁面。我寫了一個定製的SESSION監聽類（ClusterAppSessionListener）用於跟蹤SESSION管理的細節，例如新SESSION的創建，修改或則終止已經存在的SEESION。
圖表2展現了SESSION複製流程
Figure 2. Session replication sequence diagram
服務器上的SESSION狀態通過每個WEB請求的COOKIE跟蹤，所以爲了保持使用同樣的SESSION，從客戶端發出的請求URL必須一樣。另外，在每次請求都創建一個新的HTTP SESSION。我使用了兩種類型的，基於添加到SESSION中的屬性類別的測試方法去測試複製。
第一個類別有100個輕量對象（每個1K）添加到SESSION。第2個類別中，我添加了一個單一的大對象（100K）去比較基於SESSION屬性大小的SESSION複製所花費的時間
以下列出了SessionReplicationClient的測試規格：
● 客戶端線程數：2
● 旋環次數：1000
● 請求延遲：1000 milliseconds
● 測試範例數：1000
● SESSION屬性：小（100個1K大小的對象）或則大（一個100K大小的對象）
使用指定參數運行測試客戶端的命令如下：
java -Dlog4j.configuration=log4j.xml com.clusterapp.test.SessionReplicationClient 2 192.168.0.10 9080 1000 1000 lite
測試環境包括使用不同的SESSION管理器（SimpleTcpReplicationManager 或則 DeltaManager）和SESSION複製模式（同步，異步，池），以下表格列出了在TOMCAT集羣中的一系列測試環境：
想要把複製模式從池該到同步或異步，只要在server.xml文件中的SENDER標誌中修改replicationMode屬性值就可以了。同樣，要改變SESSION管理器的類型，只要改變Cluster元素的managerClassName屬性。
以下參數用於比較反應時間和SESSION複製的效率：
● 平均反映時間（ms）
● 平均請求時間（ms）
● 集羣開銷時間（ms）
● 複製時間（ms）
● 比率(bytes/ms)
● 比率(bytes/request)
測試結果
delta管理器和池複製模式相結合使用對與SESSION複製效率是最好的標準。同樣，保持SESSION大小較小可以比複製大SESSION快2到3倍。
複製管理器
DeltaManager在SESSION複製方面更有效，因爲他僅僅處理SESSION deltas而不是全部的SESSION數據。使用DeltaManager，與使用簡單複製管理器比較，SESSION複製效率會提高30%（大SESSION）到50%（小SESSION）。
複製模式
與其他兩個選項（同步和異步）比較，池複製模式複製SESSION花費更好的時間。在一個複製時間內，池選項幾乎是同意選項的 4倍快。但是在反應時間和集羣開銷時間方面，池和同步模式幾乎一樣，因爲在同步模式裏，集羣在返回前不用等待SESSIONG完成複製
綜述
基於SESSION複製測試的結果，我們得出結論：應該在任何可能時候使用DeltaManager。因爲複製SESSION數據的開銷是意義重大的，必須確保沒有在SESSION中存儲太多的數據同樣，添加到SESSION中的屬性大小也是影響到SESSION複製時間的另一個因素。當我運行測試在SESSION存儲大對象（100K）的時候，與在SESSION中存儲小對象（1K）相比較，複製時間非常高。想要最小化SESSION複製開銷最好的方法是避免調用session.setAttribute()以及把數據存儲在請求對象中而不是SESSION中。這樣相對更好因爲當WEB請求完成的時候請求屬性會被重置。同樣，如果沒有商業方面的原因要在服務器存儲數據，我們可以以COOKIES的形式在客戶端存儲數據。這種方法完全避免了使用任何SESSIOIN的需要。
一種最小化SESSION複製時間開銷的方法是限制集羣中到兩個或則三個服務器上的服務器例程數目。這樣當第一個服務器失敗的時候第一個服務器上的SESSION數據已經被拷貝到第二個服務器上。爲了保持網絡暢通，集羣可以分割成小塊的組，每個組包括兩個或則三個服務器例程。記住，集羣中的服務器越多，SESSION複製花費的時間也越多。目前TOMCAT5不支持首要/次要複製的概念。在以後發佈的版本中將會有，這樣我們將可以在一個或則兩個備份服務器上存儲SESSION。擁有這個特性的話，TOMCAT將會爲在集羣環境中運行WEB服務器提供更全面的SESSION複製方法。
在未來TOMCAT將會支持的一些屬性：
● 擁有在SESSION中存在非序列化的屬性的能力，集羣將會忽略該屬性
● 擁有複製context屬性以及非序列化的相關數據的能力，例如JDBC連接池和對象CACHES。
這些特性將會使在TOMCAT集羣中的SESSION複製更強壯和靈活。