J2EE clustering 1 (轉(zhuǎn))[@more@]w3c//DTD HTML 4.0 Transitional//EN">

公司主營業(yè)務(wù)：網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站建設(shè)、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出吐魯番免費(fèi)做網(wǎng)站回饋大家。

J2EE clustering 1

概述
如果想要建立一個(gè)可伸縮的高可靠性的網(wǎng)站,就需要了解集群技術(shù)(clustering).本文中,Abraham Kang介紹了J2EE集群,怎樣實(shí)現(xiàn)集群, 并列出Bluestone Total-e-server, Sybase Enterprise Application Server, SilverStream Application Server 和webLOGIC Application Server在集群技術(shù)上有什么區(qū)別.基于這些知識,你就能夠設(shè)計(jì)自己有效且高效的J2EE applications.
Abraham Kang

企業(yè)越來越多地選擇Java 2, Enterprise Edition (J2EE)來開發(fā)它們基于任務(wù)的網(wǎng)上應(yīng)用.在J2EE framework中, 集群技術(shù)能保證最少的downtime,大的伸縮性.一個(gè)集群就是一組application servers透明地運(yùn)行J2EE應(yīng)用服務(wù),就好像它們是一個(gè)整體. 在集群中必須提供額外的機(jī)器.若要將服務(wù)是健降至最短,其中的每個(gè)組件都必須是冗余的.

在本文中,我們將獲得關(guān)于集群的基本知識和集群的方法,以及重要的集群服務(wù).由于業(yè)內(nèi)集群技術(shù)差別很大,我們將比較每種技術(shù)的優(yōu)劣.更進(jìn)一步的,我們將討論與集群有關(guān)的application server將要實(shí)現(xiàn)的特性.

為聯(lián)系實(shí)際應(yīng)用,我們將看一看HP Bluestone Total-e-Server 7.2.1, Sybase Enterprise Application Server 3.6, SilverStream Application Server 3.7, 和BEA WebLogic Server 6.0 各是怎樣實(shí)現(xiàn)集群的.

本文的第二部分中,我們的討論將涉及集群的編程和差錯(cuò)恢復(fù)策略,并測試我們所提到的4種application server產(chǎn)品是怎樣伸縮規(guī)模和進(jìn)行差錯(cuò)恢復(fù)的.

集群的定義

J2EE application server的供應(yīng)商把集群定義為一組計(jì)算機(jī)一起工作，提供透明的企業(yè)級服務(wù)(支持JNDI, EJB, JSP, HttpSession,組件差錯(cuò)恢復(fù)等).他們故意定義得很模糊,因?yàn)樗麄儗λ膶?shí)現(xiàn)各不相同.一部分開發(fā)商在一組互相獨(dú)立的機(jī)器前端放置一個(gè)dispatcher,dispatcher接受用戶的請求,然后用HTTP redirect header將請求轉(zhuǎn)到集群中一臺特定的server上.另一部分開發(fā)商則實(shí)現(xiàn)了一個(gè)緊密集成在一起的機(jī)器聯(lián)合,每臺機(jī)器能完全感知它周圍其它機(jī)器的存在,連同駐在它們之上的對象.

除了機(jī)器方面的集成,集群還包含冗余和出錯(cuò)恢復(fù):

• 負(fù)載平衡器:進(jìn)入集群的單一的入口點(diǎn),站點(diǎn)或application server的流量指示器
• 網(wǎng)關(guān)路由器:內(nèi)部網(wǎng)絡(luò)的出口點(diǎn)
• 多層交換器:包過濾或幀過濾,確保每臺機(jī)器僅收到和自己相關(guān)的信息
• 防火墻:端口級別過濾,防止hacker進(jìn)入集群或內(nèi)部網(wǎng)絡(luò)
• SAN (Storage Area.NETworking)控制器:把a(bǔ)pplication servers, Web servers和databases連接到后端存儲介質(zhì),管理數(shù)據(jù)該寫到哪個(gè)硬盤;以及出錯(cuò)備份
• 數(shù)據(jù)庫

無論怎樣實(shí)現(xiàn),集群都提供兩大主要功能:可伸縮性和高可靠性(HA).

可伸縮性

可伸縮性是指一個(gè)應(yīng)用程序能支持不斷增長的用戶數(shù)量的能力.集群通過增加server來提供額外的工作能力,從而保證了可伸縮性.

高可靠性

HA可用一個(gè)詞概括:冗余(redundancy).一個(gè)集群用很多機(jī)器服務(wù)請求, 因此,即使一臺機(jī)器崩潰了,其它機(jī)器也可透明地接過任務(wù).

集群僅在application server層提供高可靠性. 對一個(gè)網(wǎng)絡(luò)系統(tǒng)來說,要表現(xiàn)真正的HA,必須像諾亞方舟(Noah's ark)一樣每種東西提供兩件,包括Web servers,網(wǎng)關(guān)路由器,交換結(jié)構(gòu)等.

集群種類

J2EE集群通常采取兩種方法: 不共享集群(shared-nothing cluster),和共享存儲集群.在不共享集群中,每個(gè)application server有自己的文件系統(tǒng)和在集群中運(yùn)行的應(yīng)用的copy.應(yīng)用程序的升級需要更新集群中的每個(gè)節(jié)點(diǎn).這種設(shè)置對大的集群而言,維護(hù)就像一場噩夢,尤其是當(dāng)代碼需要更新時(shí).

相反,共享存儲集群公用一個(gè)存儲設(shè)備,每個(gè)application servers從那里獲得運(yùn)行的application.更新只在一個(gè)文件系統(tǒng)中進(jìn)行,所有機(jī)器能訪問到這些變化.直到現(xiàn)在,單點(diǎn)失敗(single-point of failure)仍是它的弱點(diǎn).然而,SAN提供一個(gè)到冗余存儲介質(zhì)的單一的邏輯接口,以便進(jìn)行出錯(cuò)恢復(fù), 出錯(cuò)回退和可伸縮性.(欲詳細(xì)了解SAN, 參見Storage Infrastructure.)

比較J2EE application server的集群技術(shù)實(shí)現(xiàn),最重要的是考慮一下因素:

• 集群的實(shí)現(xiàn)
• 集群和組件的出錯(cuò)恢復(fù)
• HttpSession的出錯(cuò)恢復(fù)
• 集群拓?fù)涞膯吸c(diǎn)失敗
• 可變的拓?fù)浣Y(jié)構(gòu)
• 維護(hù)

以后我們將在不同的方面比較四個(gè)流行的application server的集群技術(shù),但首先,我們先仔細(xì)探討一下各要素.

集群的實(shí)現(xiàn)

J2EE application server在實(shí)現(xiàn)JNDI(Java Naming and Directory Interface)的基礎(chǔ)上實(shí)現(xiàn)集群.盡管JNDI是J2EE應(yīng)用程序依賴的核心,在集群中卻很難實(shí)現(xiàn),因?yàn)椴荒馨讯鄠€(gè)對象bind到一個(gè)JNDI名字上.依據(jù)不同application server JNDI的實(shí)現(xiàn),有三種集群的方法:

• 獨(dú)立的(Independent)
• 集中的(Centralized)
• 全局共享(Shared global)

獨(dú)立的JNDI tree

HP Bluestone Total-e-Server和SilverStream Application Server在每個(gè)application server中使用獨(dú)立的JNDI tree.JNDI tree的server成員并不知道和關(guān)心集群中其它server的存在.因此,差錯(cuò)恢復(fù)要么不支持,要么通過一個(gè)重定向HTTP或EJB request的中間服務(wù)支持.這些中間服務(wù)經(jīng)過配置可知道每個(gè)組件在集群中的位置,并知道萬一出現(xiàn)錯(cuò)誤哪里有替代品.

獨(dú)立JNDI tree集群的一個(gè)優(yōu)點(diǎn)是: 集群集中度(convergence)更短,伸縮簡便.集群集中度衡量的是集群完全感知所有成員和其上的對象的時(shí)間指標(biāo).然而,集中度在獨(dú)立JNDI tree集群并不是問題,一旦兩臺機(jī)器啟動起來,集群就能獲知集中度. 另一個(gè)優(yōu)點(diǎn)是: 可伸縮性只要額外的機(jī)器參與就行.

但是,也存在著缺點(diǎn).首先,出錯(cuò)恢復(fù)通常是開發(fā)者的責(zé)任.故,由于每種application server的JNDI tree是獨(dú)立的,通過JNDI查詢得到的remote Proxy被綁定到查詢發(fā)生時(shí)的那臺server上,這樣,如果EJB的這次調(diào)用失敗了,開發(fā)者需要寫額外的代碼連接dispatcher,獲取另一臺有效的server的地址,再進(jìn)行一次JNDI查詢,重新調(diào)用剛才失敗的方法.Bluestone實(shí)現(xiàn)了一種更為復(fù)雜的形式,每個(gè)請求都通過一個(gè)EJB proxy服務(wù),稱作Proxy LBB (Load Balance Broker).EJB proxy服務(wù)保證每個(gè)請求都發(fā)往活動的UBS實(shí)例.這樣引入了額外的延遲,但是自動執(zhí)行了出錯(cuò)恢復(fù).

集中式JNDI tree

Sybase Enterprise Application Server實(shí)現(xiàn)的就是集中的JNDI tree集群.集中的JNDI tree集群對JNDI采用Corba的CosNaming服務(wù).Name server中駐有集中式JNDI tree,跟蹤哪個(gè)server啟動了.每個(gè)server在啟動時(shí),把object bind到自己的JNDI tree中,同時(shí)也bind到所有的name server中的JNDI tree.

這種模式下獲得EJB的引用分兩個(gè)步驟.首先,用戶從name server查詢home object, 前者返回一個(gè)可互作用的對象引用(interoperable object reference IOR). IOR指向幾個(gè)活動的含有該home object的server. 然后,用戶用第一個(gè)server獲得home和remote.如果EJB方法調(diào)用中出現(xiàn)錯(cuò)誤,CORBA stub負(fù)責(zé)實(shí)現(xiàn)獲得另一臺機(jī)器(列于IOR中)上的邏輯.

name server本身是這種方式下的一個(gè)弱點(diǎn).舉例來說,如果一個(gè)集群中有50臺機(jī)器,其中5臺為name server. 如果每個(gè)name server都不可用的話,集群就沒用了.實(shí)際上,另45臺機(jī)器都是好的,但整個(gè)集群將不處理任何EJB 請求.

當(dāng)集群中所有的name server都崩潰了,就需要另一臺機(jī)器馬上扮演name server的角色,由此產(chǎn)生了另一個(gè)問題.這種情況下,新的name server要求集群中所有活動的機(jī)器把自己的對象bind到其上的JNDI tree.盡管bind 過程中接受請求未嘗不可,但建議不要這樣.binding過程延長了集群的恢復(fù)時(shí)間.而且,每個(gè)JNDI查詢實(shí)際上代表兩個(gè)網(wǎng)絡(luò)調(diào)用,一個(gè)從name server獲取IOR,而第二個(gè)從IOR指定的server獲取object.

最后,當(dāng)集中式JNDI tree集群擴(kuò)大規(guī)模時(shí),它的集中度時(shí)間也越來越長.擴(kuò)大規(guī)模時(shí),必須增加越來越多的name server. 記住name server和整個(gè)集群機(jī)器的一般可接受比例是1:10, 且至少有兩臺name server.因此,如果你的集群有10臺機(jī)器,兩臺為name server,總共就有20個(gè)bind. 40臺機(jī)器的集群,有4臺name server, 就有160個(gè)bind. 每個(gè)bind代表一臺成員server把它上面所有對象bind到name server的JNDI tree上的一個(gè)過程.這樣,集中式JNDI tree集群的集中度在所有實(shí)現(xiàn)中是最差的.

全局共享式JNDI tree

最后, BEA WebLogic實(shí)現(xiàn)的是全局共享式JNDI tree. 這種方式下,當(dāng)集群中的一臺機(jī)器啟動時(shí),它通過IP組播宣布它的存在和它的JNDI tree.每臺server把對象bind到自己本地的JNDI tree的同時(shí),還bind到一個(gè)共享的全局JNDI tree.

把JNDI tree分為全局的和本地的,生成的home和remote stub就能出錯(cuò)恢復(fù),并提供快捷的過程中(in-process)JNDI查詢.全局JNDI tree在每個(gè)成員中共享,每個(gè)成員都能知道集群中每個(gè)對象的確切地址.如果哪個(gè)對象在兩臺以上的機(jī)器上,一個(gè)特殊的home object被bind到全局JNDI tree上.這個(gè)home知道它關(guān)聯(lián)的所有 EJB object的位置,生成的remote object也同樣知道所有的位置.

全局共享的主要缺陷在于:網(wǎng)絡(luò)流量在server啟動初始化時(shí)非常大,集群集中度也很大.相反,在獨(dú)立的JNDI tree集群中,這并不是問題,因?yàn)闆]有JNDI信息共享.而全局共享式或集中式集群在簡歷共享或集中式JNDI tree時(shí)要花費(fèi)時(shí)間.實(shí)際上,由于全局共享集群采用組播傳遞JNDI信息,建立全局JNDI tree的時(shí)間是隨server線性增長的.

全局共享式較集中式JNDI tree而言,主要的優(yōu)勢在于:集群實(shí)現(xiàn)主要致力于伸縮的易實(shí)現(xiàn)性和更高的可靠性. 通過全局共享,你不必改動name server的cpu和RAM,或者調(diào)節(jié)集群中的name server數(shù)量.想擴(kuò)展應(yīng)用規(guī)模,增加server就行.而且,如果哪臺崩潰了,集群仍能很好地工作.最后,每個(gè)遠(yuǎn)程查詢只要一個(gè)網(wǎng)絡(luò)調(diào)用就完成了,相比集中式的兩個(gè)而言就省多了.

由于JSP,servlet,EJB和JavaBean最好能同時(shí)駐扎在一臺application server上, 它們總是使用進(jìn)程中JNDI查詢.記住如果你僅僅運(yùn)行服務(wù)器端的應(yīng)用,三種方式?jīng)]什么區(qū)別. 事實(shí)上,每個(gè)HTTP請求在application server中做進(jìn)程中JNDI查詢,返回應(yīng)用中調(diào)用的對象.

接著,我們將注意力集中到J2EE application server的第二大考慮因素:集群和出錯(cuò)恢復(fù)服務(wù).

分享文章：J2EEclustering1(轉(zhuǎn))-創(chuàng)新互聯(lián)
新聞來源：http://weahome.cn/article/dijojp.html