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它們每一個是如何實作叢集的.

在後續的第二部分裡,包括群集的程式設計和失敗轉移政策.也測試了四個應用伺服器産品,了解他們如何伸縮和失敗轉移的.

摘要

如 果你計劃建立一個可伸縮的,可用的網站,那麼你就需要了解群集.在這篇文章裡, 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給出了一個單獨的邏輯接口,通過這個接口可以進入到一個提供失敗轉移,回報,和伸縮性的備援存儲中介.(關于 SAN更多的内容,看Storage Infrastructure)

當比較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服務與通過叢集提供相同的服務相比是微不足道,價值不高的.由于叢集的複雜性,每個應用伺服器都以統一的方法實作群集元件.你應當 了解提供商如何實作entity beans, stateless session beans, stateful session beans, 和JMS的群集和失敗轉移.許多提供商聲稱支援群集元件,但是他們所做的定義通常意味着涉及叢集裡運作的元件.例如,BEA WebLogic Server 5.1支援群集stateful session beans但是如果bean執行個體所在的伺服器失敗,bean的所有狀态都将丢失.用戶端然後将必須重新建立和重新駐留,在叢集裡這麼做是沒用的.直到 BEA WebLogic 6.0, stateful session beans才使用記憶體複制來處理失敗轉移和群集.

所有的應用服 務器都支援EJB群集,但是在可配置的自動失敗轉移方面存在着非常大的差别.實際上,一些應用伺服器依靠EJB用戶端的一些條件,不支援自動的失敗轉移. 例如, Sybase Enterprise Application Server通過你從資料庫或者系列化裝載bean的狀态來支援stateful session bean失敗轉移.就象上面提到的那樣, BEA WebLogic 6.0通過stateful session bean狀态的記憶體複制支援stateful session bean的失敗轉移.大多數應用伺服器可以在叢集裡運作JMS,但是不具有個别命名的主題(Topics)和隊列(Queues)負載均衡或失敗轉移,記 住,你可能需要購買一個JMS的可群集實作.比如說通過購買SonicMQ獲得Topics和Queues的負載均衡.

現在,我們轉到另外一個重要考慮的事情: HttpSession失敗轉移.

HttpSession失敗轉移

當 用戶端在原始的伺服器上建立的一個session失敗時,HttpSession失敗轉移允許用戶端從叢集裡的其他伺服器無縫的取得session資訊. BEA WebLogic Server實作了session資訊的記憶體複制,而HP Bluestone Total-e-Server有個為HA所做的備份,利用了一個中央集中session伺服器. SilverStream Application Server和Sybase Enterprise Application Server利用一個所有應用伺服器都要讀寫的中央集中資料庫或者檔案系統.

資料庫/檔案系統session持久性的主要缺點集中在當存 儲大的或者衆多的HttpSession對象時受限的伸縮性.一個使用者每次增加一個對象到HttpSession,在session裡的所有對象都被系列 化寫到一個資料庫或者共享檔案系統.大多數利用了資料庫session持久性的應用伺服器提倡最小限度的使用HttpSession存儲對象,但是這限制 了你web應用的架構和設計,尤其如果你正在使用HttpSession來存儲緩存的使用者資料.

基于記憶體的session持久性把記憶體裡 的session資訊存儲到備份伺服器.這種方法存在兩種變化.第一個方法把HttpSession資訊寫到一個中央集中的狀态伺服器.叢集裡的所有機器 把它們的HttpSession對象寫到這個伺服器.在第二種方法裡,每個叢集節點選擇一個任意備份節點來存儲記憶體裡的session資訊.使用者每次增加 一個對象到HttpSession,那個對象獨自被序列化,然後從記憶體裡添加到一個備份伺服器.

在這些方法中,如果叢集裡的伺服器數低的話,這個專門的狀态伺服器證明了比記憶體複制到一個任意的備份伺服器更好,因為為了事務處理和動态頁面生成,它釋放了CPU周期.

另 一方面,當叢集裡的機器數變大時,這個專門的狀态伺服器會成為瓶頸,當你增加更多的伺服器時,記憶體複制到一個任意的備份伺服器(相對于一個專門的狀态服務 器來說)将線形伸縮.此外,當你在叢集裡增加更多的機器時,也需要你增加更多的RAM和CPUs來持續的調整這個狀态伺服器.對于記憶體複制到一個任意的備 份伺服器來說,你隻需添加更多的機器,sessions可以均勻的把自己分布到叢集裡的所有機器上.

基于記憶體的持久性提供了柔性的web應用設計,伸縮性和高可用性.

我們已經解決了HttpSession的失敗轉移, 現在我們将研究單點失敗(single points of failure)

單點失敗(single points of failure)

沒 有備份的叢集服務以單點失敗而聞名.他們會引起整個叢集或你的部分應用失敗.例如, WebLogic JMS可以在叢集裡的單機上隻有一個運作的Topic. 你的應用依賴JMS Topics,如果那台機器發生當機,你的叢集将down掉直到另外一個WebLogic執行個體和那個JMS Topics一起啟動. (注意:當開始新的執行個體時, 隻有持久資訊将被發送.)

問問自己你的叢集是否具有單點失敗,如果有的話,你需要估計基于你應用的需求,是否可以忍受它們.

下面,開始說明柔性伸縮拓撲.