在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請求都進入一個活動的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伺服器裡使用的一些物件.