J2EE application server的供應商把集群定義為一組計算機一起工作，提供透明的企業級服務(支持JNDI, EJB, JSP, HttpSession,組件差錯恢復等).他們故意定義得很模糊,因為他們對它的實現各不相同.一部分開發商在一組互相獨立的機器前端放置一個dispatcher,dispatcher接受用戶的請求,然后用HTTP redirect header將請求轉到集群中一臺特定的server上.另一部分開發商則實現了一個緊密集成在一起的機器聯合,每臺機器能完全感知它周圍其它機器的存在,連同駐在它們之上的對象.

除了機器方面的集成,集群還包含冗余和出錯恢復:

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

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

可伸縮性

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

高可靠性

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

集群僅在application server層提供高可靠性. 對一個網絡系統來說,要表現真正的HA,必須像諾亞方舟(Noah's ark)一樣每種東西提供兩件,包括Web servers,網關路由器,交換結構等.

集群種類

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

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

比較J2EE application server的集群技術實現,最重要的是考慮一下因素:

• 集群的實現
• 集群和組件的出錯恢復
• HttpSession的出錯恢復
• 集群拓撲的單點失敗
• 可變的拓撲結構
• 維護

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

集群的實現

J2EE application server在實現JNDI(Java Naming and Directory Interface)的基礎上實現集群.盡管JNDI是J2EE應用程序依賴的核心,在集群中卻很難實現,因為不能把多個對象bind到一個JNDI名字上.依據不同application server JNDI的實現,有三種集群的方法:

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

獨立的JNDI tree

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

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

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

集中式JNDI tree

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

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

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

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

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

全局共享式JNDI tree

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

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

全局共享的主要缺陷在于:網絡流量在server啟動初始化時非常大,集群集中度也很大.相反,在獨立的JNDI tree集群中,這并不是問題,因為沒有JNDI信息共享.而全局共享式或集中式集群在簡歷共享或集中式JNDI tree時要花費時間.實際上,由于全局共享集群采用組播傳遞JNDI信息,建立全局JNDI tree的時間是隨server線性增長的.

全局共享式較集中式JNDI tree而言,主要的優勢在于:集群實現主要致力于伸縮的易實現性和更高的可靠性. 通過全局共享,你不必改動name server的cpu和RAM,或者調節集群中的name server數量.想擴展應用規模,增加server就行.而且,如果哪臺崩潰了,集群仍能很好地工作.最后,每個遠程查詢只要一個網絡調用就完成了,相比集中式的兩個而言就省多了.

由于JSP,servlet,EJB和JavaBean最好能同時駐扎在一臺application server上, 它們總是使用進程中JNDI查詢.記住如果你僅僅運行服務器端的應用,三種方式沒什么區別. 事實上,每個HTTP請求在application server中做進程中JNDI查詢,返回應用中調用的對象.

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