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