bromon原創(chuàng) 請(qǐng)尊重版權(quán)
本文主要講解JBoss cluster的基本知識(shí)以及簡(jiǎn)單的配置方法,其間涉及了一些jboss的補(bǔ)充知識(shí)。
一、材料準(zhǔn)備:
1、 JBoss 4.0.2
JBoss各個(gè)版本之間差異比較大,即使同為jboss 4.x的版本,內(nèi)部組件的版本也不一致,所以請(qǐng)盡量使用同一版本的server。目前已經(jīng)證明可以配置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的安裝請(qǐng)自行搞定。假設(shè)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實(shí)際上可以劃分為兩個(gè)話題:負(fù)載均衡 (load balance) 和狀態(tài)同步。它們是互相獨(dú)立的,單獨(dú)配置。
負(fù)載均衡的概念比較簡(jiǎn)單,重要的是負(fù)載均衡的粒度??梢赃x擇針對(duì)每個(gè)request的均衡,或者是針對(duì)每個(gè)用戶的均衡。選擇不同的粒度,需要不同的狀態(tài)同步方式。
1、基于request的負(fù)載均衡
該種方式下,負(fù)載均衡器 (load balancer)會(huì)根據(jù)各個(gè)node的狀況,把每個(gè)http request進(jìn)行分發(fā)。使用這樣的均衡策略,就必須在多個(gè)node之間復(fù)制用戶的session,實(shí)時(shí)保持整個(gè)cluster的用戶狀態(tài)同步,這種操作被稱為session復(fù)制(session replication)。Jboss的實(shí)現(xiàn)原理是使用攔截器(interceptor),根據(jù)用戶的同步策略攔截request,做同步處理后再交給server產(chǎn)生響應(yīng)。
該方法的優(yōu)點(diǎn)是客戶不會(huì)被綁定都具體的node,只要還有一個(gè)node存活,用戶狀態(tài)都不會(huì)丟失,cluster都能夠繼續(xù)工作。缺點(diǎn)是node之間通信頻繁,響應(yīng)速度有影響,多并發(fā)、高頻操作的情況下性能下降比較厲害。
2、 基于用戶的負(fù)載均衡
該種方式下,當(dāng)用戶發(fā)出第一個(gè)request后,負(fù)載均衡器動(dòng)態(tài)的把該用戶分配到某個(gè)節(jié)點(diǎn),并記錄該節(jié)點(diǎn)的jvm路由,以后該用戶的所有request都會(huì)被綁定這個(gè)jvm路由,用戶只會(huì)與該server發(fā)生交互,這種策略被稱為粘性session(session sticky)。
該方法的優(yōu)點(diǎn)是響應(yīng)速度快,多個(gè)節(jié)點(diǎn)之間無須通信。缺點(diǎn)也很明顯,某個(gè)node死掉以后,它負(fù)責(zé)的所有用戶都會(huì)丟失session。
四、實(shí)戰(zhàn)
1、負(fù)載均衡
Jboss的負(fù)載均衡目前有兩種方案,一是使用apache的mod_jk,二是使用jboss自帶的負(fù)載均衡模塊。下面分別講解這兩種配置。
mod_jk的配置
1、 請(qǐng)確認(rèn)%apache%\modules下已經(jīng)有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 文件內(nèi)容如下:
# 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的意思是,把所有的請(qǐng)求都發(fā)給loadbalancer處理??梢酝ㄟ^修改url來控制發(fā)送某些request。
4、在%apache%\conf下新建文件 workers2.properties 其內(nèi)容為:
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
其中對(duì)于node的命名規(guī)則是worker.節(jié)點(diǎn)名.xxxx。所以上述文件定義了兩個(gè)節(jié)點(diǎn):server1和server2。8009端口是jboss默認(rèn)的ajp端口,另外需要注意的是worker.server2.lbfactor參數(shù),它是節(jié)點(diǎn)的負(fù)載加權(quán),它的值越大,獲得負(fù)載的機(jī)會(huì)就越大。可以根據(jù)node的硬件性能進(jìn)行調(diào)整。worker.loadbalancer.sticky_session參數(shù)是指定是否使用粘性session。
所有需要負(fù)載均衡的節(jié)點(diǎn),都必須在worker.loadbalancer.balanced_workers參數(shù)中列舉出來。
請(qǐng)記住所有node的名稱和它對(duì)應(yīng)著哪臺(tái)機(jī)器,后面的配置中會(huì)使用。
嘗試啟動(dòng)apache:%apache\bin\apache.exe,正常情況下沒有任何提示。如果你使用的jk是2.0的,那么配置文件的寫法完全不同,由于mod_jk2已經(jīng)停止開發(fā),所以apache并沒有提供任何講解,對(duì)于配置文件的編寫也沒有任何指導(dǎo)。
Jboss自帶均衡器的配置
將文件夾%jboss%\docs\examples\varia\loadbalancer\loadbalancer.sar拷貝到%jboss%\server\all\deploy下,并且修改loadbalancer.sar\loadbalancer.sar\META-INF\jboss-service.xml,在<host>標(biāo)簽中類出所有節(jié)點(diǎn),在<sticky-session>標(biāo)簽中指定是否使用粘性session。配置完成。
該均衡器的缺點(diǎn)是負(fù)載能力相對(duì)不高,配置參數(shù)太少,比如無法指定不同節(jié)點(diǎn)的負(fù)載加權(quán),所以后面都以mod_jk為例,不再講解jboss自帶的負(fù)載均衡器的內(nèi)容。
負(fù)載均衡的配置基本完成,啟動(dòng)jboss,其中過程中會(huì)列出DefaultPatition中所有的節(jié)點(diǎn):
run.bat -c all
任何節(jié)點(diǎn)的關(guān)閉與啟動(dòng)都會(huì)在cluster中廣播,比如加如一個(gè)新節(jié)點(diǎn)后,其他節(jié)點(diǎn)會(huì)得到以下提示:
2、session sticky配置
apache應(yīng)該會(huì)以粘性session的方式分發(fā)請(qǐng)求。部署一個(gè)應(yīng)用測(cè)試一下,你會(huì)發(fā)現(xiàn)粘性session沒有起作用。因?yàn)槲覀冞€沒有給jboss配置jvm路由( jvmRoute),apache就無法知道究竟哪些session是屬于哪個(gè)節(jié)點(diǎn)的。我們繼續(xù)往下:
修改server1機(jī)器上的jboss的配置文件:%jboss%\server\all\deploy\jbossweb-tomcat55.sar\ META-INF\ jboss-service.xml
在110行有:<attribute name="UseJK">false</attribute>,將它改為true。值得注意的是在這行標(biāo)簽上面有一段注釋,要求你在server.xml中必須有:
Engine name="jboss.web" jmvRoute="Node1" defaultHost="localhost"
請(qǐng)注意這里有一個(gè)氣死人不償命的小bug,jboss的官方文檔把 jvmRoute寫成了jmvRoute,就是v和m兩個(gè)字母的顛倒讓我郁悶了三天,翻遍了jboss.com和theserverside.com。都是直接拷貝的錯(cuò),吐血吐到脫水啊。
下面需要修改server1上的%jboss%\server\all\deploy\jbossweb-tomcat55.sar\ server.xml,在32行左右有:
<Engine name="jboss.web" defaultHost="localhost">
給它增加一個(gè)jvmRoute屬性:
<Engine jvmRoute="server1" name="jboss.web" defaultHost="localhost">
請(qǐng)注意,jvmRoute的值必須和mod_jk中的節(jié)點(diǎn)名字正確對(duì)應(yīng),否則無法正確路由。Cluster中的所有節(jié)點(diǎn)都應(yīng)該做相應(yīng)的配置。
Jboss的配置完成了,下面需要在你的web應(yīng)用中修改配置文件,讓它支持集群。
在WEB-INF\web.xml中加入屬性: <distributable/>
Ok,基于用戶的cluster完成了,每個(gè)用戶會(huì)綁定都某個(gè)節(jié)點(diǎn)上進(jìn)行交互。這種綁定是如何完成的呢?原來apache把客戶分發(fā)到節(jié)點(diǎn)后,該節(jié)點(diǎn)會(huì)在用戶的session id后面加上此節(jié)點(diǎn)的路由名稱,變成這個(gè)樣子:
Efdfxxd98daja87daj76da2dka**,server1
有了這個(gè)標(biāo)志,就能分辨該session屬于哪個(gè)節(jié)點(diǎn)。
3、session replication配置
下面要做的是基于request的cluster,也就讓各個(gè)節(jié)點(diǎn)之間互相復(fù)制session狀態(tài)。有兩種復(fù)制模式,同步與異步。使用同步的方式,jboss會(huì)把session復(fù)制的操作和對(duì)request的響應(yīng)放到一個(gè)應(yīng)用事務(wù)(application transaction),session復(fù)制完成后才去處理request。異步復(fù)制則發(fā)送session復(fù)制的消息后馬上處理request,session復(fù)制則會(huì)稍有延遲。但是在多框架的web頁(yè)面中,這樣的集群方式會(huì)有問題。由于frame在同一時(shí)間發(fā)出多個(gè)request,會(huì)造成一些混亂,這也是采用基于用戶的集群方式的原因之一。
JBoss 4.0.2中采用了Jboss cache來實(shí)現(xiàn)session復(fù)制,實(shí)際上就是一個(gè)分布式緩存,由于session id中包含了jvm route,所以能夠分辨session屬于哪個(gè)節(jié)點(diǎn)。Session的更新類似于hibernate中的樂觀鎖,有了更新之后就讓session的版本號(hào)增加,其他節(jié)點(diǎn)通過對(duì)比版本號(hào)來決定是否同步session狀態(tài)。
配置session replication首先需要編輯
%jboss% server\all\deploy\jbossweb-tomcat55.sar\META-INF\ jboss-service.xml,88行左右有:
<attribute name="SnapshotMode">instant</attribute>
這就是剛才提到的復(fù)制模式,instant為立即復(fù)制,如果設(shè)為interval 那么系統(tǒng)會(huì)在延遲一段時(shí)間再進(jìn)行復(fù)制,時(shí)間長(zhǎng)度在<attribute name="SnapshotInterval">2000</attribute>中指定,單位是毫秒。
單獨(dú)配置這一個(gè)地方還不夠,在%jboss% server\all\deploy\ tc5-cluster-service.xml中有:
<attribute name="CacheMode">REPL_ASYNC</attribute>
這里才真正決定復(fù)制是同步的還是異步的,可以指定為REPL_ASYNC(異步)或者REPL_SYNC(同步)。
在這個(gè)文件下面一點(diǎn),還有一個(gè)config標(biāo)簽,里面指定了各個(gè)節(jié)點(diǎn)在進(jìn)行session復(fù)制的時(shí)候如何通信,有udp和tcp兩種可選,如果使用udp方式,那么應(yīng)該將udp的lookback屬性指定為true,因?yàn)閣indows上有一個(gè)叫做media sense的東西會(huì)影響udp multicast。注意如果你不了解multi address的ip規(guī)則,請(qǐng)不要隨便修改mcast_addr的值。如果采用tcp方式的話,應(yīng)該指定bind_addr的值為本機(jī)ip,并且在TCPPING標(biāo)簽的initial_hosts屬性中列出所有節(jié)點(diǎn),格式是”機(jī)器名[端口號(hào)]”,比如在我們的例子中,就應(yīng)該這樣配置tcp(以其中一個(gè)節(jié)點(diǎn)為例):
<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內(nèi)部,建議使用tcp方式,經(jīng)測(cè)試可能有不明物體在影響udp通信,導(dǎo)致Timeout異常。
在%jboss%\ server\all\deploy\ cluster-service.xml中也有關(guān)于udp和tcp的配置信息,在4.0以前版本的jboss中,會(huì)以這個(gè)文件為主配置,4.0以后都以tc5-cluster-service.xml為主配置。
Jboss的配置完成了,最后需要在web應(yīng)用中增加配置信息,控制session復(fù)制的粒度。在WEB-INF\ jboss-web.xml中增加以下內(nèi)容:
<replication-config>
<replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger>
<replication-granularity>SESSION</replication-granularity>
</replication-config>
其中replication-trigger是指定哪些操作引發(fā)session的版本更新,它的取值有:
SET_AND_GET
SET_AND_NON_PRIMITIVE_GET
SET
replication-granularity是復(fù)制粒度,可以取session或attribute。如果取為attribute有可能導(dǎo)致復(fù)制失敗,這是目前版本的jboss cache的一個(gè)bug,等待修正。
部署項(xiàng)目,測(cè)試,如果配置沒有問題,可以在%jboss%\0server\all\log\server.log中發(fā)現(xiàn)類似于這樣的信息:
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配置的成功率比較低,情況也很復(fù)雜,請(qǐng)仔細(xì)操作。
五、分布式熱部署(distributable hot deploy)
在一個(gè)節(jié)點(diǎn)很多的cluster中,如果部署應(yīng)用的時(shí)候必須把程序文件拷貝到每個(gè)機(jī)器上的話,那實(shí)在太愚蠢了,幸好通過all啟動(dòng)的jboss自動(dòng)支持分布式熱部署。把支持cluster的應(yīng)用(通常需要打包成war文件),放到%jboss%\server\all\farm下,那么處于同一cluster中的其他節(jié)點(diǎn)會(huì)自動(dòng)下載并且部署,jboss把這個(gè)稱為Farm deploy。如下圖:
End 2005-7-11 Released by bromon
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=455581