vista

回顧※展望潛心技術&&不再擱淺

BlogJava :: 首頁 :: 聯系 :: 聚合

:: 管理

12 Posts :: 1 Stories :: 13 Comments :: 0 Trackbacks

轉貼－－JBOSS集群

?Last Modified: 2006.02.23

JBoss 4.0.2集群指南

(來源：http://www.javaresearch.org )

bromon原創?請尊重版權

????本文主要講解JBoss?cluster的基本知識以及簡單的配置方法，其間涉及了一些jboss的補充知識。

一、材料準備：

1、????JBoss?4.0.2????

JBoss各個版本之間差異比較大，即使同為jboss?4.x的版本，內部組件的版本也不一致，所以請盡量使用同一版本的server。目前已經證明可以配置cluster的版本多為jboss?3.2.6和jboss?4.0.2。

2、????Apache?2.0.54

3、????Apache?mod_jk-1-2-13-apache-2-0-54

二、安裝：

1、????jboss4.0.2與apache?2.0.54的安裝請自行搞定。假設jboss的安裝目錄為%jboss%，apache安裝目錄為%apache%。

2、????mod_jk的安裝。

從apache.org獲得文件mod_jk-1-2-13-apache-2-0-54.so，將該文件拷貝到%apache%\?modules。

三、jboss?cluster入門

????Jboss?支持如下類型的cluster：EJB、web、JNDI、JMS，我們主要了解web?cluster。
Web?cluster實際上可以劃分為兩個話題：負載均衡?(load?balance)?和狀態同步。它們是互相獨立的，單獨配置。

負載均衡的概念比較簡單，重要的是負載均衡的粒度。可以選擇針對每個request的均衡，或者是針對每個用戶的均衡。選擇不同的粒度，需要不同的狀態同步方式。

1、基于request的負載均衡

????該種方式下，負載均衡器?(load?balancer)會根據各個node的狀況，把每個http?request進行分發。使用這樣的均衡策略，就必須在多個node之間復制用戶的session，實時保持整個cluster的用戶狀態同步，這種操作被稱為session復制(session?replication)。Jboss的實現原理是使用攔截器(interceptor)，根據用戶的同步策略攔截request，做同步處理后再交給server產生響應。

????該方法的優點是客戶不會被綁定都具體的node，只要還有一個node存活，用戶狀態都不會丟失，cluster都能夠繼續工作。缺點是node之間通信頻繁，響應速度有影響，多并發、高頻操作的情況下性能下降比較厲害。

2、????基于用戶的負載均衡

該種方式下，當用戶發出第一個request后，負載均衡器動態的把該用戶分配到某個節點，并記錄該節點的jvm路由，以后該用戶的所有request都會被綁定這個jvm路由，用戶只會與該server發生交互，這種策略被稱為粘性session(session?sticky)。

該方法的優點是響應速度快，多個節點之間無須通信。缺點也很明顯，某個node死掉以后，它負責的所有用戶都會丟失session。

四、實戰

1、負載均衡

????Jboss的負載均衡目前有兩種方案，一是使用apache的mod_jk，二是使用jboss自帶的負載均衡模塊。下面分別講解這兩種配置。

mod_jk的配置

1、????請確認%apache%\modules下已經有mod_jk-1-2-13-apache-2-0-54.so文件。
2、????修改%apache%\conf\httpd.conf????在文件末尾添加:????Include?conf/mod_jk2.conf
3、????在%apache%\conf下新建文件????mod_jk2.conf????????文件內容如下：

#?Load?mod_jk?module.?Specify?the?filename
#?of?the?mod_jk?lib?you’ve?downloaded?and
#?installed?in?the?previous?section
LoadModule?jk_module?modules/mod_jk-1-2-13-apache-2-0-54.so
#?Where?to?find?workers.properties
JkWorkersFile?conf/workers2.properties
#?Where?to?put?jk?logs
JkLogFile?logs/mod_jk.log
#?Set?the?jk?log?level?[debug/error/info]
JkLogLevel?info
#?Select?the?log?format
JkLogStampFormat?"[%a?%b?%d?%H:%M:%S?%Y]?"
#?JkOptions?indicate?to?send?SSL?KEY?SIZE,
JkOptions?+ForwardKeySize?+ForwardURICompat?-ForwardDirectories
#?JkRequestLogFormat?set?the?request?format
JkRequestLogFormat?"%w?%V?%T"
JkMount?/*?loadbalancer

其中JkMount?/*?loadbalancer的意思是，把所有的請求都發給loadbalancer處理。可以通過修改url來控制發送某些request。
4、在%apache%\conf下新建文件????workers2.properties????????其內容為：

worker.list=loadbalancer,server1,server2

#?Define?the?first?node...
worker.server1.port=8009
worker.server1.host=172.16.0.116
worker.server1.type=ajp13
worker.server1.lbfactor=1
worker.server1.local_worker=1
worker.server1.cachesize=10

#?Define?the?first?node...
worker.server2.port=8009
worker.server2.host=172.16.32.88
worker.server2.type=ajp13
worker.server2.lbfactor=1
worker.server2.local_worker=1
worker.server2.cachesize=10

#?Now?we?define?the?load-balancing?behaviour
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=server1,server2
worker.loadbalancer.sticky_session=1

其中對于node的命名規則是worker.節點名.xxxx。所以上述文件定義了兩個節點：server1和server2。8009端口是jboss默認的ajp端口，另外需要注意的是worker.server2.lbfactor參數，它是節點的負載加權，它的值越大，獲得負載的機會就越大。可以根據node的硬件性能進行調整。worker.loadbalancer.sticky_session參數是指定是否使用粘性session。

所有需要負載均衡的節點，都必須在worker.loadbalancer.balanced_workers參數中列舉出來。

請記住所有node的名稱和它對應著哪臺機器，后面的配置中會使用。

嘗試啟動apache：%apache\bin\apache.exe，正常情況下沒有任何提示。如果你使用的jk是2.0的，那么配置文件的寫法完全不同，由于mod_jk2已經停止開發，所以apache并沒有提供任何講解，對于配置文件的編寫也沒有任何指導。

Jboss自帶均衡器的配置

????將文件夾%jboss%\docs\examples\varia\loadbalancer\loadbalancer.sar拷貝到%jboss%\server\all\deploy下，并且修改loadbalancer.sar\loadbalancer.sar\META-INF\jboss-service.xml，在<host>標簽中類出所有節點，在<sticky-session>標簽中指定是否使用粘性session。配置完成。

????該均衡器的缺點是負載能力相對不高，配置參數太少，比如無法指定不同節點的負載加權，所以后面都以mod_jk為例，不再講解jboss自帶的負載均衡器的內容。
?

????負載均衡的配置基本完成，啟動jboss，其中過程中會列出DefaultPatition中所有的節點：
run.bat?-c?all

?

任何節點的關閉與啟動都會在cluster中廣播，比如加如一個新節點后，其他節點會得到以下提示：
?

2、session?sticky配置

????apache應該會以粘性session的方式分發請求。部署一個應用測試一下，你會發現粘性session沒有起作用。因為我們還沒有給jboss配置jvm路由(?jvmRoute)，apache就無法知道究竟哪些session是屬于哪個節點的。我們繼續往下：

????修改server1機器上的jboss的配置文件：%jboss%\server\all\deploy\jbossweb-tomcat55.sar\?META-INF\?jboss-service.xml

????在110行有：<attribute?name="UseJK">false</attribute>，將它改為true。值得注意的是在這行標簽上面有一段注釋，要求你在server.xml中必須有：
Engine?name="jboss.web"?jmvRoute="Node1"?defaultHost="localhost"

????請注意這里有一個氣死人不償命的小bug，jboss的官方文檔把?jvmRoute寫成了jmvRoute，就是v和m兩個字母的顛倒讓我郁悶了三天，翻遍了jboss.com和theserverside.com。都是直接拷貝的錯，吐血吐到脫水啊。

????下面需要修改server1上的%jboss%\server\all\deploy\jbossweb-tomcat55.sar\?server.xml，在32行左右有：

<Engine?name="jboss.web"?defaultHost="localhost">

給它增加一個jvmRoute屬性：

<Engine?jvmRoute="server1"?name="jboss.web"?defaultHost="localhost">

請注意，jvmRoute的值必須和mod_jk中的節點名字正確對應，否則無法正確路由。Cluster中的所有節點都應該做相應的配置。

Jboss的配置完成了，下面需要在你的web應用中修改配置文件，讓它支持集群。

在WEB-INF\web.xml中加入屬性：????<distributable/>

Ok，基于用戶的cluster完成了，每個用戶會綁定都某個節點上進行交互。這種綁定是如何完成的呢？原來apache把客戶分發到節點后，該節點會在用戶的session?id后面加上此節點的路由名稱，變成這個樣子：

Efdfxxd98daja87daj76da2dka**,server1

????有了這個標志，就能分辨該session屬于哪個節點。

3、session?replication配置

????下面要做的是基于request的cluster，也就讓各個節點之間互相復制session狀態。有兩種復制模式，同步與異步。使用同步的方式，jboss會把session復制的操作和對request的響應放到一個應用事務(application?transaction)，session復制完成后才去處理request。異步復制則發送session復制的消息后馬上處理request，session復制則會稍有延遲。但是在多框架的web頁面中，這樣的集群方式會有問題。由于frame在同一時間發出多個request，會造成一些混亂，這也是采用基于用戶的集群方式的原因之一。

????JBoss?4.0.2中采用了Jboss?cache來實現session復制，實際上就是一個分布式緩存，由于session?id中包含了jvm?route，所以能夠分辨session屬于哪個節點。Session的更新類似于hibernate中的樂觀鎖，有了更新之后就讓session的版本號增加，其他節點通過對比版本號來決定是否同步session狀態。

????配置session?replication首先需要編輯
%jboss%?server\all\deploy\jbossweb-tomcat55.sar\META-INF\?jboss-service.xml，88行左右有：
<attribute?name="SnapshotMode">instant</attribute>
這就是剛才提到的復制模式，instant為立即復制，如果設為interval?那么系統會在延遲一段時間再進行復制，時間長度在<attribute?name="SnapshotInterval">2000</attribute>中指定，單位是毫秒。

單獨配置這一個地方還不夠，在%jboss%?server\all\deploy\?tc5-cluster-service.xml中有：

<attribute?name="CacheMode">REPL_ASYNC</attribute>

這里才真正決定復制是同步的還是異步的，可以指定為REPL_ASYNC(異步)或者REPL_SYNC(同步)。

在這個文件下面一點，還有一個config標簽，里面指定了各個節點在進行session復制的時候如何通信，有udp和tcp兩種可選，如果使用udp方式，那么應該將udp的lookback屬性指定為true，因為windows上有一個叫做media?sense的東西會影響udp?multicast。注意如果你不了解multi?address的ip規則，請不要隨便修改mcast_addr的值。如果采用tcp方式的話，應該指定bind_addr的值為本機ip，并且在TCPPING標簽的initial_hosts屬性中列出所有節點，格式是”機器名[端口號]”，比如在我們的例子中，就應該這樣配置tcp(以其中一個節點為例)：

<config>
<TCP?bind_addr="172.16.0.116"?start_port="7810"?loopback="true"/>
<TCPPING?initial_hosts="172.16.0.116[7810],172.16.32.88[7810]"?port_range="3"?timeout="3500"
num_initial_members="3"?up_thread="true"?down_thread="true"/>
<MERGE2?min_interval="5000"?max_interval="10000"/>
<FD?shun="true"?timeout="2500"?max_tries="5"?up_thread="true"?down_thread="true"?/>
<VERIFY_SUSPECT?timeout="1500"?down_thread="false"?up_thread="false"?/>
????<pbcast.NAKACK?down_thread="true"?up_thread="true"?gc_lag="100"
?????????retransmit_timeout="3000"/>
????<pbcast.STABLE?desired_avg_gossip="20000"?down_thread="false"?up_thread="false"?/>
????<pbcast.GMS?join_timeout="5000"?join_retry_timeout="2000"?shun="false"
print_local_addr="true"?down_thread="true"?up_thread="true"/>
<pbcast.STATE_TRANSFER?up_thread="true"?down_thread="true"/>
</config>

????JBoss的clustering版主建議盡量使用udp。不過在Sobey內部，建議使用tcp方式，經測試可能有不明物體在影響udp通信，導致Timeout異常。

????在%jboss%\?server\all\deploy\?cluster-service.xml中也有關于udp和tcp的配置信息，在4.0以前版本的jboss中，會以這個文件為主配置，4.0以后都以tc5-cluster-service.xml為主配置。

????Jboss的配置完成了，最后需要在web應用中增加配置信息，控制session復制的粒度。在WEB-INF\????jboss-web.xml中增加以下內容：

<replication-config>
????<replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger>
????<replication-granularity>SESSION</replication-granularity>
??</replication-config>

其中replication-trigger是指定哪些操作引發session的版本更新，它的取值有：

SET_AND_GET????????
SET_AND_NON_PRIMITIVE_GET
SET

replication-granularity是復制粒度，可以取session或attribute。如果取為attribute有可能導致復制失敗，這是目前版本的jboss?cache的一個bug，等待修正。

部署項目，測試，如果配置沒有問題，可以在%jboss%\0server\all\log\server.log中發現類似于這樣的信息：

DEBUG?[org.jboss.web.tomcat.tc5.session.JBossCacheManager]?check?to?see?if?needs?to?store?and?replicate?session?with?id?Im9-qpuaXppMS+xXwE3M+Q**.server1?

DEBUG?[org.jboss.web.tomcat.tc5.session.ClusteredSession]?processSessionRepl():?session?is?dirty.?Will?increment?version?from:?20?and?replicate.

????Session?replication配置的成功率比較低，情況也很復雜，請仔細操作。

五、分布式熱部署(distributable?hot?deploy)

????在一個節點很多的cluster中，如果部署應用的時候必須把程序文件拷貝到每個機器上的話，那實在太愚蠢了，幸好通過all啟動的jboss自動支持分布式熱部署。把支持cluster的應用（通常需要打包成war文件），放到%jboss%\server\all\farm下，那么處于同一cluster中的其他節點會自動下載并且部署，jboss把這個稱為Farm?deploy。如下圖：

End?2005-7-11?Released?by?bromon

? 2006 Huihoo

posted on 2006-12-05 09:30 Vista 閱讀(1044) 評論(0) 編輯收藏所屬分類: 開源※類庫

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問
相關文章: 轉貼－－JBOSS集群 vista 精神之－類庫篇

vista

常用鏈接

留言簿(1)

隨筆分類

隨筆檔案

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜

JBoss 4.0.2集群指南