J2EE應用服務器集群

J2EE應用服務器集群

　　在J2EE應用服務器領域，Jboss是發展最為迅速的應用服務器。由于Jboss遵循商業友好的LGPL授權分發，并且由開源社區開發，這使得Jboss廣為流行。下面是小編整理的關于J2EE應用服務器集群，希望大家認真閱讀!

　　摘要

　　如果你計劃建立一個可伸縮的,可用的網站,那么你就需要理解群集.在這篇文章里, Abraham Kang介紹了J2EE群集,說明如何實現群集, 調查了Bluestone Total-e-server, Sybase Enterprise Application Server, SilverStream Application Server, 和 WebLogic Application Server在方法上如何不同.掌握了群集知識,你將能夠設計和實現有成效的J2EE應用.

　　在Web上企業正在選擇Java 2, Enterprise Edition (J2EE)產生他們關鍵性任務的應用.在J2EE框架里, 集群提供了保證最少下載時間和最大伸縮性的關鍵性任務服務.集群是在一組應用服務器顯式運行你的J2EE應用,就象一個實體一樣, 對于伸縮來說,你以后會在集群里引入額外的機器.確定集群的每個組件都是冗余的,來保證最少的下載時間.

　　在這篇文章里,我們將對群集,群集方式和重要的集群服務有個基本的理解.由于群集方式在行業應用里是多樣的,所以我們將調查每種方式的好處和缺點.另外,我們也將尋找集群在應用服務器里重要的相關特點,并進行討論.

　　為了把我們新獲得的群集知識應用到現實世界,我們將了解HP Bluestone Total-e-Server 7.2.1, Sybase Enterprise Application Server 3.6, SilverStream Application Server 3.7和 BEA WebLogic Server 6.0它們每一個是如何實現集群的.

　　在后續的第二部分里,包括群集的編程和失敗轉移策略.也測試了四個應用服務器產品,了解他們如何伸縮和失敗轉移的.

　　集群定義

　　J2EE應用服務器提供商給集群下了定義, 一個集群就是一組在一起工作,顯式提供企業服務(支持JNDI,EJB,JSP, HttpSession和組件失敗轉移等等)的機器群.他們特意給出了含糊不清的定義,因為每個提供商實現群集是有差異的.有些提供商把一個分發器放到一組獨立的機器前面, 在集群里這些機器彼此之間互不了解.在這個方案里,分發器從用戶那里收到一個初始的請求,然后由集群里具體的成員服務器通過HTTP把頭重定向到客戶端應答. 另一些提供商實現了一個緊密的,完整的機器聯盟,每個機器都隨著那些機器上的對象知道它周圍的其他機器.

　　除了機器外,集群可以包括冗余和失敗轉移的能力.

　　· ·負載均衡器(Load balancers):

　　進入集群和通行指示器到單個Web或應用服務器的唯一入口點

　　·Web servers

　　·網關路由器(Gateway routers) 在內網外的的出口點.

　　·多層交換器(Multilayer switches)

　　包和幀過濾確保在集群里的每個機器僅僅收到相關機器的信息.

　　·防火墻(Firewalls)

　　集群保護器通過端口過濾防止Hackers訪問集群和內網

　　·存儲區域網絡交換器(SAN---Storage Area Networking switches)

　　連接應用服務器,web服務器,和數據庫到一個后端存儲媒介;

　　管理寫數據到物理硬盤;還有失敗轉移.

　　·數據庫(Databases)

　　不管他們是如何實現的,所有的集群都提供兩個好處:可伸縮性(scalability)和高可用性(high availability---HA)

　　可伸縮性(scalability)

　　伸縮性支持用戶增長時保證應用服務質量的能力.集群允許你依靠增加額外的服務器提供額外的容量,因而保證伸縮性.

　　高可用性(high availability---HA)

　　HA能被一個詞概括:冗余.集群使用許多的機器處理服務請求.因此,如果在集群里的任何機器失敗,另外一臺機器會直接接管.

　　集群僅僅在應用服務器層提供HA.對于一個要展示真正HA的Web系統,一定象諾亞方舟一樣至少包括Web服務器,網關路由器, 交換基礎設施,等等中的兩種.(關于HA的更多內容,看這個HA Checklist.)

　　集群類型

　　J2EE集群通常流行兩種風格:非共享和共享磁盤.在非共享集群里, 每個應用服務器都有的它自己的文件系統, 和這個集群里運行的應用程序自己的拷貝相一致.應用的更新和增加需要更新集群里的每個節點.當代碼增加和更新發布時進行配置,大的集群有惡夢般的維護.

　　相反,磁盤共享集群使用一個所有的應用服務器都用的存儲設備來獲取在集群里運行的應用.更新和增加出現在一個文件系統里,集群里的所有的機器可以訪問這些變化.直到最近才發現, 單點失敗是這種方法的不利方面.然而,SAN給出了一個單獨的邏輯接口,通過這個接口可以進入到一個提供失敗轉移,反饋,和伸縮性的冗余存儲中介

　　當比較J2EE應用服務器的集群實現時,重要考慮:

　　·集群實現

　　·集群和組件失敗轉移服務

　　·HttpSession失敗轉移

　　·集群拓撲里的單點失敗

　　·柔性拓撲規劃

　　·維護

　　以后我們將看到四種流行的應用服務器在不同領域如何比較,但是,首先還是讓我們更詳細的檢查所要考慮的每一項.

　　集群實現

　　J2EE應用服務器在他們的JNDI(java命名和目錄接口)實現周圍實現了群集.雖然JNDI是J2EE應用依賴的核心服務,但是它很難在集群里實現,因為它不能把多個對象綁定在單個名字上.關于每個應用服務器的JNDI實現有三個普遍的群集方法.

　　·獨立的

　　·中央集中的

　　·全局共享的

　　獨立JNDI樹

　　HP Bluestone Total-e-Server 和SilverStream Application Server利用了一個適合于每個應用服務器的獨立JNDI樹.在一個獨立JNDI樹的集群里成員服務器不知道或不關心集群里其他服務的存在.因此,不支持失敗轉移或者通過重定向HTTP或EJB請求的媒介服務提供支持.配置媒介服務,使他們知道集群里每個組件都駐留在哪里和萬一失敗發生如何得到一個替代的組件.

　　獨立JNDI樹的集群它的一個優點:更短的集群收斂時間和靈活的伸縮.集群收斂衡量了集群完全知道集群里所有的機器和相關對象的時間.然而, 在一個獨立JNDI樹的集群里收斂(Convergence)并不是一個要關心的問題,因為集群在兩臺機器一啟動就完成了收斂(Convergence).獨立的JNDI樹的其他優點:伸縮僅僅需要需要增加額外的服務器.

　　然而,也存在幾個弱點.首先,失敗轉移通常是開發者的責任. 也就是說,因為每個應用服務器的JNDI樹都是獨立的,所以通過JNDI重新找到的遠程代理被固定到已出現的lookup服務器上.在這種情況下,如果調用EJB的一個方法失敗了,開發者必須寫額外的代碼連接到分發器來獲得另外一個活動服務器的地址,做另外一次JNDI查找,再一次調用已失敗的方法. Bluestone實現了一個更復雜的獨立JNDI樹的形式,就是每個請求都經過EJB代理服務或者代理LBB (Load Balance Broker).EJB代理服務保證每個EJB請求都進入一個活動的UBS實例.這種方案對每個請求都添加了額外的反應時間,但是在方法調用之間允許自動的失敗轉移.

　　中央集中JNDI樹

　　Sybase企業應用服務器實現了一個中央集中JNDI樹的集群.根據這種設置,中央集中的JNDI樹利用了CORBA的CosNaming服務.命名服務器收容了集群的中央集中的JDNI樹,清楚哪個服務器出事了.剛一啟動,集群里的每個服務器就綁定它的對象到它的JNDI樹和所有的命名服務器.

　　在一個中央集中JNDI樹的集群里獲得一個EJB的引用需要兩個步驟.首先,客戶端從命名服務器查找一個home對象,返回一個互操作對象引用(IOR).一個IOR指向集群里活動的具有home對象的幾臺機器.第二,客戶端挑選出定位在IOR里的第一個服務器,得到home和remote.如果在EJB方法調用之間出現失敗,CORBA stub實現了重新獲得另外一個home或者remote的邏輯.這個home或者remote來自從命名服務器返回的IOR里列出的一個替代服務器.

　　命名服務器本身就證實了中央集中JNDI樹集群的一個弱點.如果你有特定的50臺機器的集群,之中有5臺是命名服務器,如果5臺命名服務器都down掉了,那么這個集群就變的沒什么用了.當然,另外45臺機器能運行,但是當命名服務器down了,這個集群將不能為一個EJB客戶端服務.

　　如果集群原先的命名服務器全部發生了失敗, 在線引進一個額外的命名服務器就會出現另一個問題. 假如這樣做的話,一個新的中央集中命名服務器就需要集群里每個活動機器綁定它的對象到新的命名服務器的JNDI樹.雖然當綁定過程發生時開始收到請求是可能的,但不推薦這樣做,因為綁定過程延長了集群的恢復時間.此外,來自一個application或者applet的JNDI lookup,事實上出現了兩次網絡調用.第一個調用從命名服務器重新獲得一個對象的IOR,第二的調用從IOR里指定的一個服務器那重新獲得客戶端想要的對象.

　　最后,當集群數量增長時中央集中JNDI樹的集群承擔收斂(Convergence)所帶來的增加時間.就是說當你伸縮你的集群時,你必須增加更多的命名服務器. 緊記命名服務器所在的機器和全部的集群機器通常公認的比率是1:10,兩個命名服務器是最小數目.因此,如果你有一個10臺機器的集群和兩臺命名服務器,在服務器和命名服務器之間綁定的總數能達到20,在一個40臺機器的集群和四臺命名服務器里,會有160個綁定關系.每個綁定都表示其中一個成員服務器綁定所有的對象到一個命名服務器的JNDI樹的過程.記住,中央集中JDNI樹的集群在所有的JNDI集群實現之間具有更糟糕的收斂時間(Convergence time).

　　全局共享JNDI樹

　　最后,BEA Weblogic實現了一個全局共享的JNDI樹.用這種方式,當集群里的一個服務器啟動時,通過IP廣播宣布它的存在并且把JNDI樹通知給集群里的其它服務器.群集里的每個機器既綁定它的對象到全局共享JNDI樹,又綁定到它自己的本地JNDI樹.

　　在每個成員服務器里都擁有一個全局的和本地的JNDI樹,允許生成的home和remote stubs失敗轉移,并且提供很快的進程里的JNDI lookups. 全局共享JNDI樹在集群里的所有機器之間都是共享的,允許任何成員機器知道集群里所有對象的精確位置.如果在集群里的多個機器上對象是可用的,一個特殊的home對象被綁定到全局共享JNDI樹.這個特殊的home知道所有EJB對象和與它相關聯對象的位置, 也生成知道所有EJB對象和與它相關聯對象的位置的remote對象.

　　全局共享方式的主要不利方面：當服務器啟動時所產生的大量網絡初始化傳輸和集群的過分收斂時間(Convergence time).相反,在一個獨立JNDI樹的集群里, 由于沒有JNDI共享信息出現,所以收斂并不被看做是個問題.然而,對集群里所有機器來說, 一個全局共享或者中央集中的集群,建立全局共享或者中央集中JNDI樹都需要花費時間. 實際上,因為全局共享集群使用廣播傳輸JNDI信息,建立全局共享JNDI樹所需的時間與以后增加的服務器數相比是線性相關的.

　　全局共享與中央集中JNDI樹的集群相比主要的好處集中在自由伸縮和高可用性.使用全局共享,你就不必在專門的命名服務器上亂動CPU和RAM,不必在集群里調整命名服務器的數目.當然,為了伸縮應用程序,僅僅增加更多的機器就可以.此外,如果集群里的一些機器down掉了,集群將完全繼續起作用.最后,和在中央集中JNDI樹的集群里每個remote lookup都需要兩個網絡調用相比, 每個remote lookup都只需要一個單一的網絡調用.

　　所有這些都應該打個折扣,不可全信.因為運行在應用服務器上的JSPs,servlets,EJBs,和JavaBeans可以共處在EJB服務器里.他們總是使用一個進程里的JNDI lookup.緊記,如果你只運行服務器端(server-side)應用,那么在獨立的,中央集中的,或者全局共享的集群實現幾乎沒有什么差別. 實際上,每個HTTP請求在應用服務器上都將結束,因為應用服務器將使用進程里的JNDI lookup返回你server-side服務器里使用的一些對象.

【J2EE應用服務器集群】相關文章：

關于J2EE應用服務器集群簡介02-27

J2EE應用服務器03-29

J2EE應用服務器介紹03-20

J2EE應用服務器基本特色03-20

什么是J2EE03-16

j2ee介紹03-20

J2EE的概念03-19

J2EE發展狀況03-19

J2EE的基本術語03-16