為 WebSphere Application Server Community Edition V2.1 構建 WADI 叢集環境

轉自：http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0912_chirh_wascewadi/index.html

從 WebSphere Application Server Community Edition ( 以下簡稱 WAS CE) 版本 2.1 以來，WAS CE 在 Tomcat native 叢集之外，新增了對 WADI 叢集的支援。相比於 Tomcat native 叢集，WADI 叢集同樣提供了叢集成員間 Session 複製來避免單點失效並實現災難恢復，同時利用負載平衡來提高應用程式的可用性。另外在一個部署了 Farming 的 WAS CE 叢集環境中，如果您在某個節點上進行應用程式部署或者生命週期管理，叢集內的所有節點都會同步響應這些請求。 Farming 這個特性使得應用程式的管理 ( 如部署、啟動、停止、以及解除安裝 ) 更加的邏輯化和透明化：通過一次部署 , 便可以將應用部署到 WAS CE 伺服器叢集中的每個節點；同樣，只需一次操作，便可以管理叢集內所有節點上該應用程式的生命週期。這篇文章將從實現機制和示例配置兩方面對 WAS CE WADI 叢集和 Farming 外掛進行介紹

引言

WebSphere Application Server Community Edition（以下簡稱 WAS CE）是一個完全符合 Java Platform, Enterprise Edition 5（Java EE 5）規範、經認證的應用伺服器。也就是說 WAS CE 包含所有支援 Java EE 5 實現的元件：Web 容器、EJB 容器、訊息服務、命令列管理等開發和執行 Java EE 應用程式所需的環境。儘管 Java EE 5 的規範中並沒有提供對叢集實現的規範要求，但在實際的應用環境中，叢集做為提供應用程式的擴充套件性以及保證其高可用性的常見解決方案，得到了非常廣泛的使用。要實現叢集，常見的做法是通過擴充套件多個伺服器節點，使得會話以及節點資訊在叢集內複製傳遞，以此來保證應用程式的高可靠性。但隨著叢集內節點的增多，怎樣保證叢集的效率以及應用程式的可用性呢？尤其是在異構的應用伺服器環境中，有什麼較理想的解決辦法嗎？另外，為了實現叢集中各個節點能夠協調統一，每個節點上面都需要配置相同的應用程式，有什麼比較好的辦法能夠進行批量部署，從而提高叢集管理的效率？本文依次通過介紹 WAS CE 伺服器中整合的 WADI 模組和 Farming 模組，向讀者解答前面提到的問題，並將在文末通過具體例項演示在 WAS CE 伺服器環境中如何使用 WADI 和 Farming 模組搭建 WAS CE 叢集。文中所提及的內容為作者的學習總結，僅供讀者參考，以幫助讀者瞭解相關概念並熟悉部署過程，所述觀點並不代表 IBM 。

WADI 叢集的實現機制

WADI 的全稱是 Web Application Distribution Infrastructure, 即 Web 應用程式分散式架構，從它的名字我們可以看出，WADI 這個專案設立的初衷是為了解決叢集環境中 Web 層應用程式狀態的管理。隨著專案的逐漸成熟，再加上 WADI 自己獨有的特性和解決方案，它已經演變成一個更加通用的分散式狀態和服務管理框架。由於 WADI 是一個獨立的開源專案，不依賴於任何現有的應用程式容器，因此在一個異構的環境中，WADI 的作用和意義就更為突出。

WAS CE 從版本 V2.1 開始，便將 WADI 整合到了自己的伺服器分發包中，這樣，WAS CE 的使用者除了選用原有的 Tomcat 叢集以外，還可以考慮選用 WADI 的叢集方案。

WADI 簡介及其特性

WADI 的設計目標簡要概括為如下幾點：

• 為分散式環境中提供可插拔的、棧式的頁面排程（paging）和持久化（persistence）機制；
• 提供一個伸縮性強、可用性高、自分割（self-partitioning）和自癒合 (self-healing) 的叢集基礎；
• 提供狀態到請求（State to Invocation）或者請求到狀態（Invocation to State）的透明遷移（migration）；
• 提供可插拔的狀態複製機制。

具體到 Web 層則為：保證在應用程式以及容器空間 HTTP 會話的一致性問題；提供 HTTP 請求和 會話遷移、HTTP 會話複製、以及 HTTP 會話序列化策略等。

WADI 的分散式會話查詢機制使得無論叢集中節點的數量是多少，會話的定位（location）、遷移（migration）以及插入（insertion）等操作所消耗的系統資源都保持為常量。另外，WADI 的會話複製機制只為每個會話複製指定數量的會話副本，這也保證了 WADI 叢集在會話複製上的開銷只和複製數量成比例，而不受叢集節點的影響。WADI 的上述特點使得 WADI 叢集具有很強的可擴充套件性，當業務需要的時候可以增加 WADI 叢集的節點而不會為叢集管理帶來額外的開銷。

下面我們來簡單瞭解一下 WADI 在具體實現過程時所涉及到的幾個關鍵概念。

分割槽（Partition）：用來記錄會話的位置。在每個叢集的服務空間（Service Space）中，分割槽的數量在叢集的配置期間被指定，在執行時由分割槽管理器進行動態的管理，被平均地分配到每個節點。當叢集的節點數量發生變化（新節點加入叢集、或者現有節點退出叢集）的時候，分割槽管理器會重新分配分割槽在節點上的分佈，以確保分割槽數在叢集的各個節點間上是平均的。WADI 中的分散式會話查詢機制所利用的正是這一概念。

會話定位：WADI 叢集的每個節點可以通過對會話 ID 進行一個簡單的演算法運算，從而得到該會話屬於哪個分割槽；同時每個節點也知道每個分割槽具體由哪個節點負責管理（關於分割槽的資訊，在每次分割槽重新分配的時候都通過叢集中散發給每個節點）。所以，對於任何會話，任何節點都可以通過它的 ID 很快的找到這個會話的位置資訊被儲存在叢集的哪個節點上。

會話複製：WADI 的會話複製策略決定會話副本的數量，以及由哪些節點來儲存這些副本。當每次請求處理完成以後，會話就被更新到它的副本所在節點。另外，當某個節點離開叢集的時候，複製策略將重新選擇節點來儲存會話副本。因此，它的會話複製策略更像一種“會話冗餘”策略，因為會話複製通常是指在叢集中的所有節點間複製會話的資訊

會話遷移：當節點接收到請求的時候，如果節點擁有該請求所對應的會話，那麼請求立即可以就在當前節點被處理；如果該節點上沒有請求所對應的會話，那麼節點就會請求分割槽管理器將會話遷移到當前節點，同時更新分割槽管理器中關於該會話的位置記錄，然後請求在當前節點被處理。

WADI 叢集在 WAS CE 中的實現

WAS CE 中整合了 Tomcat 作為 Java EE 應用伺服器中的 Web 容器， 在 為 WAS CE 構建叢集環境一文中，作者介紹了 WAS CE V1.0.1 中利用整合的 Tomcat V5.0 實現上下文級別 (Context level) 的叢集功能。而從 V2.0 開始， WAS CE 所整合的 Tomcat V6.0 本身就提供了一個進行節點管理的模組 modules/groupcom，叫做 Tribes，以此來實現節點之間的通訊；同時還有一個模組 module/ha 用於提供會話之間的複製，但是隨著節點或者會話數量的增加，用於維護會話或者節點狀態的記憶體開銷也會越來越大，最終有可能導致整個叢集停止工作。

從版本 2.1 開始， WAS CE 將 WADI 做為一個外掛整合到伺服器中，從而為使用者提供了另一種叢集方式。與先前版本中完全利用 Web 容器 Tomcat 所提供的叢集功能相比，WADI 叢集通過自己的會話管理機制協調 Web 層各個會話的狀態，並同樣可以利用 mod_proxy/mod_jk 的負載平衡功能來提高應用程式的災難恢復能力。

在 WAS CE V2.1 中的 WADI+Tomcat 模式中， Tomcat 僅作為 Web 容器用於 Web 應用程式解析，節點和會話的管理則通過 WADI 自己的機制來實現，通過在固定數目的節點之間維護指定數量的 HTTP 會話副本，系統的開銷不會因為節點或者會話數目的變化而出現較大的起伏，從而可以保證叢集的效能能夠穩定持久；由於 WADI 是一個獨立的叢集實現框架，它可以完全獨立於 Java EE 容器，實現分散式 Java EE 環境的叢集，同時配合使用相應的 EJB 容器，如 WAS CE 中已經整合的 OpenEJB，使用者也可以實現有狀態會話 Bean 的叢集。本文中我們將僅介紹 Web 層面的 WADI 叢集實現。另外 WAS CE 中特有的 Farming 特性將會使得應用程式的管理變得更加輕鬆，使用者只需要在叢集內的任一節點上使用部署命令，WAS CE 就會在叢集中的其他節點上批量部署並啟動應用程式。

在 WAS CE 中，WADI 和 Tomcat 都是以外掛的形式存在的，因此我們來認識一下相關的外掛：

表 1. WADI 在 WAS CE 中的對應外掛

在上文我們提到 WADI 提供各種引數使得使用者可以根據自己的業務需求靈活配置，在 WAS CE 中，這些可配置的引數直接作為 GBean 的屬性值提供給使用者。

由於 GBean 是 WAS CE 所使用的 Geronimo 架構中的最小可管理單元，伺服器中的每個模組或者系統服務都對應到一組 GBean；為了向伺服器中加入新的功能或者服務，需要相應的實現一組 GBean，並部署到 WAS CE 執行環境中。因此，要配置這些屬性，需要知道相應的 GBean 名稱和其含義：

表 2. WADI 在 WAS CE 中的 GBean 實現

從 WAS CE 所提供的 GBean 資訊可以看出，WADI 在 WAS CE 中的叢集實現同樣可以採用廣播或者靜態指定叢集成員的方式，通常在單個節點的 WAS CE 環境中，使用者只需要啟動相應的模組就可以啟動 WADI 叢集功能，預設的廣播模式和會話管理策略即可滿足使用者的需求。 節點（clusterNodeName）以及叢集名稱 (clusterName) 會由 WADI 外掛自動從 WAS CE 安裝目錄下的 var\config\config-substitions.properties 配置檔案中讀取。同樣，如果使用者需要更改 WAS CE 節點上的 WADI 配置，只需要找到這個檔案，然後更改以下引數即可：

 DefaultWadiSweepInterval=36000 
 WebConnectorConTimeout=20000 
 DefaultWadiNumPartitions=24 
 ReplicaCount=2 

Farming 的實現機制

Farming 也可以叫做“資料中心”或者“伺服器農場”，用於批量化管理伺服器上的資源或者應用程式。在 WAS CE 中，實現批量化管理的 Farming 模組也是以外掛的形式整合到 WAS CE 伺服器中。在同一個“農場”中的各個 WAS CE 伺服器之間通過 JMX 聯結器進行通訊，整個“農場”中所有的應用程式或者資源的部署和生命週期管理操作只需要在其中一臺 WAS CE 伺服器上進行。

在 WAS CE 中提供 Farming 功能的外掛如下：

同樣，使用者也可以通過 Gbean 配置單個節點的屬性：

為實現當前節點能夠響應叢集中其他節點所發起的部署命令，使用者必須用當前節點的主機名或者 IP 地址指定在 config-substitions.properties 檔案中的 RemoteDeployHostname引數。

WAS CE 中 WADI 叢集和 Farming 的示例配置

示例說明

本文章下載區提供了示例程式包（wadi-webapp.zip）可供使用者下載，在這個示例程式包中有一個用於演示叢集環境的 wadi-cluster 的示例。通過此示例應用程式，我們將對 WAS CE WADI 叢集的實現機制有更加清晰的理解，對配置過程有更加具體的掌握。在這個示例中，我們將構建執行在兩臺不同機器上的 WAS CE 伺服器組成的叢集。

示例程式包含以下幾個檔案：

wadi-webapp-2.0.war

plan.xml( 支援 wadi cluster)

應用程式如果支援 WADI 叢集，必須更新標準部署檔案和 WAS CE 部署檔案。

1. 配置標準部署檔案，比如 web.xml, Web 應用程式必須標記為 ，表示在分散式環境中，當前節點上所有的會話資訊，無論是新加入的還是對已有會話資訊的更改，都將依照會話複製管理器的安排，複製到叢集中的其他節點上。

   ..... .....

   
   
2. WAS CE 部署檔案，比如 geronimo-web.xml, 在本文章的例項中該檔案為 plan.mxl, 必須使用 屬性值，它是由 geronimo-tomcat-clustering-wadi-X.xsd 定義的，在 WAS CE 安裝目錄的 schema 目錄下，表示使用 WAS CE 中整合的 WADI+Tomcat 會話管理器。如下例所示：
   
   清單 1 . 部署計劃檔案配置示例
   

   yourGroupId yourArtifactId YourVersion war /yourPath

   
   

實驗環境說明

1）所有機器必須處於同一子網（subnet）中，並且支援廣播（multicast）。

2）所有叢集成員必須儘可能保證系統時間一致，較大的系統時間差異可能會出現問題。

3）本示例程式已在以下作業系統上進行了驗證：

Linux IA32 – RHEL5.2, Suse10Sp2
Linux PPC64 – SuSe10Sp2
Windows IA32 - Windows 2003 Server SP1, Windows XP SP2

各節點配置說明

1）在 server 1 上更新 WAS CE 伺服器配置，啟動 farming 部署功能以及 WADI 叢集功能

需要在 WAS CE 伺服器停止的狀態下，修改成員伺服器 server1 安裝目錄下。

如下修改 server1 配置檔案 var\config\config-substitutions.properties：

 clusterNodeName=NODE1 
 RemoteDeployHostname=NODE1_IP 

如下修改 server1 的配置檔案 var\config\config.xml，啟動並新增 Gbean 至 farming 模組：

				 
  
  
 NODE2 
  
  
 system 
 manager 
 rmi 
 Node2_IP 
 1099 
 JMXConnector 
 false 
  
  

  
  ${clusterNodeName} 
         
         
            ${clusterName} 
         
     
 ..... 
  
  

其中

• org.apache.geronimo.configs/farming/2.1.4/car模組實現了 farm 部署功能，使用者可以批量將應用程式部署到各個節點，而不需要逐節點部署；
• org.apache.geronimo.configs/tomcat6-clustering-wadi/2.1.4/car和 org.apache.geronimo.configs/wadi-clustering/2.1.4/car模組實現了 WADI 叢集功能，啟動模組後，server1 將會自動檢測網路上的其他節點，將他們加到該叢集中，如果其中一個節點出現意外情況關閉，那麼其他組員也會檢測到該節點退出叢集。

2）在 server 2 上更新 WAS CE 伺服器配置，啟動 farming 部署功能以及 WADI 叢集功能

需要在 WAS CE 伺服器停止的狀態下，修改成員伺服器 server2 安裝目錄下

如下修改 server2 配置檔案 var\config\config-substitutions.properties：

clusterNodeName=NODE2

RemoteDeployHostname=NODE2_IP

如下修改 server2 的配置檔案 var\config\config.xml，同 server 1 配置檔案比較，注意以下區別：

  NODE1_IP 

3）啟動各節點：

在 GShell 中啟動 server1, 該命令將從後臺執行 WAS CE 伺服器 r，並設定系統屬性 node.name 為黃色，代表當前節點為節點 1，這個屬性將被示例程式讀取，用黃色方塊標示在應用程式執行過程中節點 1 所響應的 HTTP 會話請求。

 geronimo/start-server -D node.name=yellow – b 

在 GShell 中啟動 server2，即節點 2，並設定系統屬性 node.name 為紅色，所相應的會話請求標示為紅色方塊

 geronimo/start-server -D node.name=red  -b 

使用 Farming 部署應用程式

在 server1 上通過如下命令列使用 farming 部署應用程式至 server1 和 server2

				 
 deploy.bat/sh --user system --password manager \ 
 deploy --targets 
 org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=\ 
 org.apache.geronimo.configs/farming/2.1.4/car, 
 j2eeType=ConfigurationStore,name=MasterConfigurationStore 
 SAMPLE_HOME\wadi-webapp-2.0.war $SAMPLE_HOME\plan.xml 

注：通過 farming 模組統一部署、啟動，解除安裝應用程式必須使用命令列方式，如下所示：

 deploy.bat/sh --user system --password manager stop 
   org.codehaus.wadi/wadi-webapp//war 
 deploy.bat/sh --user system --password manager start 
   org.codehaus.wadi/wadi-webapp//war 
 deploy.bat/sh --user system --password manager undeploy 
   org.codehaus.wadi/wadi-webapp//war 

訪問 server1：http://:8080/wadi-webapp/

圖 2 中黃色計數值 1 表明當前會話由黃色節點上的 WAS CE 伺服器程式響應 .

訪問 server2: http://:8080/wadi-webapp/

圖 3 中紅色計數值 1 表明當前會話由紅色節點上的 WAS CE 伺服器程式響應。

下面我們將兩個叢集節點放至 Apache Web 伺服器後進行負載均衡配置。

使用 mod_jk 配置 Apache http server

與上一系列中的應用示例相似，我們通過配置 Apache HTTP Server 作為我們的 LoadBalancer，實現 HTTP 請求的分發。略微不同的是，我們在這裡使用 mod_jk 模組。下載 mod_jk.so放置 http 安裝目錄下的 modules 目錄中，在安裝路徑下的 cofig 目錄中 新增如下內容至檔案 httpd.conf：

				 
 LoadModule jk_module modules/mod_jk.so 
 # Loads the Jakarta Tomcat Connector module 

 JkWorkersFile Install_Dir/conf/workers.properties 
 # Tells the module the location of the workers.properties file 

 JkLogFile     Install_Dir/logs/mod_jk.log 
 # Specifies the location for this module's specific log file 

 JkLogLevel    debug 
 # Sets the module's log level to info 

 JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
 # Sets the module's log time stamp format 

 JkAutoAlias Install_Dir/config-store 
 # Automatically Alias webapp context directories into the Apache document space. 

 JkMount /wadi-webapp/* loadbalancer 

在 config 目錄下建立檔案 workers.properties，檔案內容如下：

				 
 worker.list=loadbalancer 
 worker.node1.port=8009 
 worker.node1.host= 
 worker.node1.type=ajp13 
 worker.node1.lbfactor=1 

 worker.node2.port=8009 
 worker.node2.host= 
 worker.node2.type=ajp13 
 worker.node2.lbfactor=1 

 worker.loadbalancer.type=lb 
 worker.loadbalancer.balance_workers=node1,node2 
 worker.loadbalancer.sticky_session=1 
 worker.status.type=status 

訪問應用程式 http://your_http_server_host/wadi-webapp/

首次開啟頁面，初始計數加一

對頁面重新整理四次，計數為 4。幀背景顏色紅黃混合表明會話在紅色和黃色節點間遷移，這個取決於 Apache mod_jk 對每個幀執行的目標伺服器的選擇。

在頁面上有 9 個幀，9 個幀均指向 session.jsp 頁面，每重新整理頁面一次，歷史紀錄將保留，計數同步增加 1，每個數字單元背景顏色表示當前會話所在的節點。黃色代表節點 1，紅色代表節點 2。數字顏色變換表示當前會話內容在不同節點間轉移。

驗證會話複製功能

在 Tomcat 叢集中，通過 shutdown 命令關閉一個叢集成員時，會話複製就會被啟用並啟用，然而在 WADI 叢集中，要啟用會話複製功能，必須使 WADI 叢集中的某個節點非正常關閉，因此不能使用 shutdown 命令關閉叢集成員，使用者可以使用 Ctrl+C 或者 Kill 命令模擬 WAS CE 伺服器程式的非正常關閉。

使用 Ctrl+C 停止 server1, 即黃色節點上執行的 WAS CE 程式 , 重新整理頁面後，會發現歷史資料依然保留，並且計數仍然持續增加，背景顏色全部為紅，表明當前會話被複制至紅色節點。如果叢集中有 3 個以上成員，可以通過

var/config/config-substitutions.properties 檔案中的 ReplicaCount 引數設定複製會話的份數，預設值為 2。

總結語

本文介紹了利用 WAS CE 中的 WADI 和 Tomcat 構建 Web 叢集環境，使用 WAS CE 獨有的 Farming 外掛實現 Web 應用程式批量部署的原理、方法和步驟，並通過具體示例演示瞭如何配置應用程式和實際的生產環境。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-623483/，如需轉載，請註明出處，否則將追究法律責任。