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