摘要: 集群和出錯恢復(fù)服務(wù) 在一臺server上提供J2EE服務(wù)相比在整個集群中提供來說是微不足道的.鑒于集群技術(shù)的復(fù)雜性,每個application server有自己獨(dú)到的實(shí)現(xiàn)方式.你應(yīng)該向供應(yīng)商了解他們...
集群和出錯恢復(fù)服務(wù)
在一臺server上提供J2EE服務(wù)相比在整個集群中提供來說是微不足道的.鑒于集群技術(shù)的復(fù)雜性,每個application server有自己獨(dú)到的實(shí)現(xiàn)方式.你應(yīng)該向供應(yīng)商了解他們怎么實(shí)現(xiàn)集群和entity bean, stateless session bean, stateful session bean以及JMS的出錯恢復(fù).許多供應(yīng)商宣稱自己支持集群化組件,但他們對此的定義經(jīng)常牽涉到集群中的組件.例如,BEA WebLogic Server 5.1支持集群化的stateful session bean,但如果server本身崩潰了,其上所有狀態(tài)也丟失了.客戶只得重新創(chuàng)建stateful session bean,使得原來的在集群中就不可用了. 直到BEA WebLogic 6.0發(fā)布,stateful session bean才實(shí)現(xiàn)內(nèi)存復(fù)制來集群化和出錯恢復(fù).
所有application servers支持EJB clustering,但對可以配置的自動出錯恢復(fù)的支持有很大的不同. 事實(shí)上.有些application servers并不支持EJB client的自動出錯恢復(fù).例如,Sybase Enterprise Application Server支持stateful session bean出錯恢復(fù), 前提是你從數(shù)據(jù)庫或通過序列化load bean的狀態(tài).如前面所提到的,BEA WebLogic 6.0通過內(nèi)存復(fù)制bean的狀態(tài)來支持stateful session bean的差錯恢復(fù).大多數(shù)application server可以在集群中運(yùn)行JMS,但對個人命名的Topics和Queues不提供負(fù)載均衡和出錯恢復(fù).這樣,你可能就需要購買可集群的JMS產(chǎn)品,如SonicMQ,來獲得Topics和Queues的負(fù)載均衡.
另一個很重要的考慮因素,我們現(xiàn)在要提到的是:HttpSession出錯恢復(fù).
HttpSession出錯恢復(fù)
當(dāng)原先為用戶創(chuàng)建session的服務(wù)器崩潰了,HttpSession出錯恢復(fù)允許用戶無縫地從另一臺server上獲得session信息.BEA WebLogic Server實(shí)現(xiàn)了session信息內(nèi)存復(fù)制,而HP Bluestone Total-e-Server采用集中式session server,它帶有HA的備份. SilverStream Application Server和Sybase Enterprise Application Server采用集中式數(shù)據(jù)庫或文件系統(tǒng),每個application servers都從中讀寫.
用數(shù)據(jù)庫/文件系統(tǒng)實(shí)現(xiàn)的session持久性的主要缺點(diǎn)在于:當(dāng)存儲大的或很多對象在session中時有限的伸縮性.用戶每次向HttpSession增加一個對象,session中所有的對象都要序列化并寫入數(shù)據(jù)庫或共享的文件系統(tǒng).大多數(shù)用數(shù)據(jù)庫實(shí)現(xiàn)session持久化的application server都主張盡量少用session存儲object, 但這會限制Web application的結(jié)構(gòu)和設(shè)計,特別是用HttpSession存儲用戶數(shù)據(jù)時.
基于內(nèi)存的session持久性把內(nèi)存中的session信息寫到一個備份服務(wù)器上,有兩種做法.第一種把HttpSession信息寫到一個集中式狀態(tài)服務(wù)器(centralized state server). 集群中的所有機(jī)器都把HttpSession objects寫到這臺server上. 第二種方法,集群中每個節(jié)點(diǎn)任意地選擇一個節(jié)點(diǎn)存儲內(nèi)存中的session信息.每個用戶向HttpSession增加object,該object被單獨(dú)序列化在寫入那臺backup server.
上面兩種方法中,如果集群中的機(jī)器數(shù)較少,用專門的state server比任意指定backup server要好,這樣可以節(jié)省CPU來處理transaction和動態(tài)網(wǎng)頁的生成.
另一方面,當(dāng)集群的機(jī)器數(shù)很大時,專門的state server就成為瓶頸,而向任意指定的backup server復(fù)制內(nèi)存的消耗將隨著機(jī)器數(shù)的增長而線性增長.當(dāng)增加機(jī)器時,用專門的state server,你需要為它加上更多的RAM和CPU.用任意指定的backup server, 你僅僅增加機(jī)器而已,session會平均地分布在所有機(jī)器之間.基于內(nèi)存的持久化提供了靈活的Web application設(shè)計,規(guī)模和高可靠性.
現(xiàn)在我們將檢查一下單一點(diǎn)失敗.
單一點(diǎn)失敗
未提供備份的集群服務(wù)會造成單一點(diǎn)失敗,他們會造成整個集群或部分應(yīng)用崩潰.例如,WebLogic JMS在集群中僅能有一個Topic運(yùn)行在一臺機(jī)器上.如果那臺機(jī)器碰巧崩潰了,那應(yīng)用中依賴JMS Topics的部分就不能工作,直到另一個WebLogic instance啟動起來(注意只有durable message才能在新的server instance啟動時被發(fā)送.)
檢查一下你的集群是否存在單一點(diǎn)失敗.如果有,你得估計一下這樣是否能滿足應(yīng)用需求.
下面提及伸縮拓?fù)?
靈活的伸縮拓?fù)?br>集群還需要靈活的拓?fù)洳季?大多數(shù)application server還可以充當(dāng)HTTP server,見圖1.
圖1. 多合一拓?fù)?br>
當(dāng)你的website大多數(shù)是動態(tài)網(wǎng)頁時,這種結(jié)構(gòu)不錯.然而,當(dāng)大多數(shù)是靜態(tài)頁面時,要擴(kuò)展網(wǎng)站的代價就非常昂貴了,因?yàn)槟阋黾觓pplication server用于靜態(tài)HTML頁面請求.所以,適當(dāng)?shù)淖龇ㄊ?要擴(kuò)展靜態(tài)部分,增加Web server, 要擴(kuò)展動態(tài)部分,增加application server,如圖2.
圖2. 分隔的拓?fù)?br>
上圖的結(jié)構(gòu)主要的缺陷在于:增加了動態(tài)頁面請求延遲.但是相比靈活的獨(dú)立擴(kuò)展而言,微不足道.
最后,對application server的討論終止于維護(hù)性.
維護(hù)性
集群中大量機(jī)器總避免不了維護(hù)問題:維持集群運(yùn)行,通知應(yīng)用的改變.Application servers應(yīng)該提供agent來感知主要服務(wù)的崩潰,然后重新啟動它們.或者激活backup server. 更進(jìn)一步,application server應(yīng)該提供一個簡便的方法來更新和同步集群中所有的server.
Sybase Enterprise Application Server和HP Bluestone Total-e-Server提供文件和配置同步服務(wù). Sybase Enterprise Application Server在主機(jī), 組和集群level上提供這些服務(wù).Bluestone則僅提供主機(jī)level的. 如果要deploy大的application或很多application, 就要花很長的時間. BEA WebLogic Server 僅提供配置同步. 這兩者中,配置同步加上storage area network更能較好地工作,因?yàn)榭梢园炎兓瘜懭胍粋€邏輯存儲介質(zhì), 這樣所有的機(jī)器就能接收到application file的變化. 每臺機(jī)器只需要從一臺集中式configuration server上接收配置變化就可以了. SilverStream Application server用dynamic class loader從數(shù)據(jù)庫中載入application files和configuration. dynamic class loader使得運(yùn)行中的application server接收變化更方便.
我們已經(jīng)討論了application server需要考慮的重要特征.下面就根據(jù)我們的準(zhǔn)則比較一下4個流行的application server.
Application Server比較
既然我們學(xué)習(xí)了關(guān)于集群的一般知識,讓我們把注意力集中在各個application server上,把所學(xué)的和現(xiàn)實(shí)世界聯(lián)系起來.我們要比較的是:
HP Bluestone Total-e-Server 7.2.1
Sybase Enterprise Application Server 3.6
SilverStream Application Server 3.7
BEA WebLogic Server 6.0
每個application server的討論都包含一張HA結(jié)構(gòu)圖,接著是它的重要特征的小結(jié).
HP Bluestone Total-e-Server 7.2.1
圖3. HP Bluestone 7.2.1拓?fù)?br>
集群一般特性小結(jié):
Bluestone實(shí)現(xiàn)的是獨(dú)立的JNDI tree集群.作為plug-in運(yùn)行在Web server中的LBB,提供HTTP請求的負(fù)載平衡和出錯恢復(fù)服務(wù).LBB知道哪臺UBS(universal business server)上運(yùn)行著什么application,可以正確地定向流量.通過EJB Proxy Service和Proxy LBB支持對stateful,stateless session bean和entity bean的方法間出錯恢復(fù). EJB Proxy Service的主要缺點(diǎn)在于增加了每個EJB請求的延遲,而且它同UBS運(yùn)行在同一機(jī)器上.EJB Proxy Service和UBS stub支持UBS崩潰的情況下的出錯恢復(fù),但是不支持硬件崩潰的出錯恢復(fù).后者出現(xiàn)的情況下,出錯恢復(fù)是通過客戶端配置apserver.txt或Proxy LBB對apserver.txt配置.客戶端的apserver.txt里面列出了集群中所有的組件.當(dāng)有新的組件加入時,所有客戶需要用BAM (Bluestone Application Manager)更新該文件或手工逐個主機(jī)地更新.在Proxy LBB處配置apserver.txt將用戶和集群中的變化隔離,但為EJB請求引入了新的延遲.HP Bluestone是唯一的一個提供集群化和負(fù)載均衡JMS的application server.
集群集中時間:
相對集中式和全局共享式JNDI tree而言,最少.
HttpSession出錯恢復(fù):
集中式state server和backup state server或數(shù)據(jù)庫,內(nèi)存復(fù)制.
單一點(diǎn)失敗:
無
靈活的集群拓?fù)?
支持所有集群拓?fù)?
維護(hù):
Bluestone在維護(hù)方面勝過其它server.Bluestone提供一個動態(tài)應(yīng)用加載器(dynamic application launcher DAL), 供LBB在應(yīng)用程序或機(jī)器崩潰時調(diào)用. DAL能夠在主機(jī)或備份機(jī)上重啟應(yīng)用程序.另外,Bluestone還提供一個配置和發(fā)布工具,叫Bluestone Application Manager (BAM), 用來deploy application package和它們的相關(guān)文件.這個工具唯一的缺點(diǎn)是一次只能配置一臺機(jī)器--對大型集群用起來就不方便了.
Sybase Enterprise Application Server 3.6
圖4 Sybase Enterprise Application Server 3.6 拓?fù)?br>
集群一般特性小結(jié):
Enterprise Application Server實(shí)現(xiàn)的是集中式JNDI tree集群,用硬件負(fù)載平衡器來完成HTTP請求的負(fù)載均衡和出錯恢復(fù).一個集群中的兩臺name servers各自可以單獨(dú)處理HTTP request,但是為性能考慮,最好還是專門處理JNDI request.
Enterprise Application Server 3.6沒有Web server plug-in,但到二月的3.6.1 EBF (Error and Bug Fixes)版就會有了.它支持stateful, stateless session bean和entity bean的方法間出錯恢復(fù).記住Enterprise Application Server病危提供任何監(jiān)視代理或動態(tài)應(yīng)用程序加載器,你需要為單一點(diǎn)失敗或自動server重啟購買第三方產(chǎn)品,如Veritas Cluster Server.Enterprise Application Server不支持JMS.
集群集中時間:
集中時間取決于name server的數(shù)量和成員server的數(shù)量.在三種集群實(shí)現(xiàn)方式中,集中式JNDI tree集群的集中度是最差的.盡管集中時間指標(biāo)很重要,server可以在把對象bind到name server的同時就開始接收請求(當(dāng)然,推薦最好不要這樣做).
HttpSession出錯恢復(fù):
HttpSession出錯恢復(fù)用集中式數(shù)據(jù)庫實(shí)現(xiàn),不支持內(nèi)存復(fù)制.
單一點(diǎn)失敗
如果運(yùn)行多臺name server，則沒有單一點(diǎn)失敗.
靈活的集群拓?fù)?
拓?fù)浣Y(jié)構(gòu)受限于沒有Web server plug-in.
維護(hù)：
Sybase使用文件和配置同步,為application deployment提供了最好的選擇.它可以在component,package, servlet,application,甚至Web application level上同步.你還可以選擇同步整個集群,一組機(jī)器或單個主機(jī). 很棒的功能!但是如果集群中的機(jī)器太多,同步就要持續(xù)相當(dāng)長一段時間.它的一個弱點(diǎn)是沒有動態(tài)應(yīng)用程序加載服務(wù), 這意味著你必須購買第三方產(chǎn)品,如Veritas Cluster Server.
SilverStream Application Server 3.7
圖5. SilverStream Application Server
dispatcher 拓?fù)?
圖6. SilverStream Application Server
WSI拓?fù)?
集群一般特性小結(jié):
當(dāng)設(shè)置SilverStream集群時,有兩種配置方案:基于dispatcher的和基于Web server集成模塊(Web server integration-module WSI)的.在基于dispatcher的集群中,用戶連接dispatcher或基于硬件的dispatcher -- 例如Alteon 180e,然后dispatcher將HTTP重定向到及群眾的一臺機(jī)器上.從那個時刻起,用戶與那臺server就在物理上綁定了.故這種方式下,一個集群和一臺server沒有區(qū)別.主要的缺點(diǎn)在于:靜態(tài)部分和動態(tài)部分不能獨(dú)立地擴(kuò)展.
在基于WSI的集群中,用戶先連接dispatcher,后者控制web server的負(fù)載平衡和HTTP請求差錯恢復(fù). 每個Web server有一個plug-in指向一個位于集群前端的負(fù)載平衡器.WSI集群不使用重定向,每個HTTP請求可以在任何一臺機(jī)器上被平衡負(fù)載.副負(fù)載平衡器僅當(dāng)application server層崩潰時用. A WSI結(jié)構(gòu)優(yōu)于dispatcher結(jié)構(gòu):能獨(dú)立擴(kuò)展靜態(tài)和動態(tài)部分.但是,主要缺點(diǎn)是需要ArgoPersistenceManager作HttpSession出錯恢復(fù).在任何一種方式中,用戶都不能得到方法間的差錯恢復(fù).EJB出錯恢復(fù)完全成為程序員的責(zé)任.最后,SilverStream不支持集群化JMS.
HttpSession出錯恢復(fù):
SilverStream用集中式的數(shù)據(jù)庫和ArgoPersistenceManager提供HTTPSession出錯恢復(fù).不幸的是,這個解決方案具有所有權(quán)問題.不使用常規(guī)的把session信息存入數(shù)據(jù)庫的方法,而使用一個產(chǎn)品的 ArgoPersistenceManager class -- 一大缺憾.
集群集中時間:
相對集中式和全局共享式JNDI tree集群,最少.
單一點(diǎn)失敗:
以上結(jié)構(gòu)皆沒有.
靈活的集群拓?fù)?
支持所有集群拓?fù)?
維護(hù):
緩存管理器和動態(tài)class-loader為deploy和更新運(yùn)行著的應(yīng)用程序提供了方便的途徑,基本不打擾當(dāng)前活動的client. 當(dāng)集群中的一臺server上的應(yīng)用更新時,更新的部分寫入數(shù)據(jù)庫,然后緩存管理器把所有機(jī)器上的緩存設(shè)為無效,強(qiáng)迫它們下次重新獲取新的application.只有一個缺點(diǎn),就是要花時間把應(yīng)用從數(shù)據(jù)庫中取出,調(diào)入內(nèi)存中.
BEA WebLogic Server 6.0
圖7. BEA WebLogic Server 6.0
集群一般特性小結(jié):
WebLogic Server實(shí)現(xiàn)的是全局共享式的JNDI tree集群.這種工作方式下，當(dāng)一臺server啟動時，把自己的JNDI
tree寫入全局共享的JNDI tree.然后server用這個全局的tree的備份來提供服務(wù),使用戶能感知集群中的所有對象.用戶用的stub能感知整個集群,意味著它們向原定的server請求,但同時擁有其它application server上復(fù)制品的信息. 正是由于這點(diǎn),stub可以透明地進(jìn)行差錯恢復(fù).WebLogic Server的一個獨(dú)一無二的特性就是stateful session bean的內(nèi)存復(fù)制和可配置的EJB remote objects自動出錯恢復(fù). WebLogic把clusterable定義為一個在集群中的服務(wù).JMS就是這樣一個服務(wù),但是每個Topic or Queue僅在一臺server上運(yùn)行,所以不能負(fù)載均衡和出錯恢復(fù)-- WebLogic JMS實(shí)現(xiàn)的一大缺點(diǎn).
HttpSession出錯恢復(fù):
WebLogic Server通過向任意指定的backup server或database server復(fù)制內(nèi)存中狀態(tài)來實(shí)現(xiàn)HttpSession出錯恢復(fù).集群中地每臺機(jī)器挑選一臺不同的機(jī)器.如果主server崩潰了,backup server變成主server,再重新挑選一臺backup server. WebLogic有一個唯一的特性：cookie的獨(dú)立性. HP Bluestone和Enterprise Application Server都需要cookie 才能進(jìn)行HttpSession出錯恢復(fù),但是WebLogic可以使用URL中加密的信息,把用戶定向到backup server上.
單一點(diǎn)失敗:
JMS和Administration server.
靈活的集群拓?fù)?
支持所有集群拓?fù)?
維護(hù):
WebLogic的弱勢在于維護(hù).盡管BEA已經(jīng)在配置同步方面采取了積極的措施,WebLogic Server還是沒有任何監(jiān)視代理,動態(tài)應(yīng)用加載器,或文件同步服務(wù).所以你需要為單一點(diǎn)失敗或HA購買第三方方案.如果你采用了SAN,你就不必文件同步服務(wù)了,但大多數(shù)開發(fā)者才剛剛開始認(rèn)識到SAN的好處.
分析
總體來說BEA WebLogic Server 6.0最為強(qiáng)壯,集群實(shí)現(xiàn)得最徹底.HP Bluestone Total-e-Server 2.7.1, Sybase Enterprise Application Server 3.6, SilverStream Application Server 3.7 依次排列.
選擇正確的application server需要權(quán)衡折衷.如果你的應(yīng)用中有EJB clients (applet和applications), Web clients, 對HttpSession大量使用(為了caching), 要求擴(kuò)展簡易和出錯恢復(fù),你需要BEA WebLogic 6.0.如果你的application需要大量使用JMS,絕大多數(shù)client是Web client, Bluestone可能更好一些.從集群地角度說,Sybase Enterprise Application Server 3.7缺少重要的集群特性,例如JMS,HttpSession內(nèi)存復(fù)制,Web server plug-in等. 但是,Sybase Enterprise Application Server 3.7的確帶來了文件和配置同步服務(wù).如果你使用SAN,這些有點(diǎn)就微不足道了.SilverStream Application Server的集群實(shí)現(xiàn)得最不徹底, 缺少集群化的 JMS,HttpSession內(nèi)存復(fù)制和出錯恢復(fù)等.
結(jié)論
在本文中你獲得了集群的一般認(rèn)識,集群的方法和重要的集群服務(wù).我們審視了每個application server的優(yōu)缺點(diǎn),討論了和集群有關(guān)的特性.有了這些知識以后,你就懂得如何建立高可靠性和伸縮性的集群.但這僅僅是學(xué)習(xí)的開始,到外面找一些evaluation clustering license, 和application server,驗(yàn)證一下.
第二部分中,我們要開始寫代碼,驗(yàn)證application server供應(yīng)商的承諾.我們還將用J2EE Java Pet Store例程做負(fù)載和集群集中度測試.
↑返回目錄 前一篇:
J2EE clustering 1 后一篇:
J2EE － 如何在JBoss中解決自動增長鍵值問題 
