J2EE應用服務器提供商給集羣下了定義, 一個集羣就是一組在一起工作,顯式提供企業服務(支持JNDI,EJB,JSP, HttpSession和組件失敗轉移等等)的機器羣.下面是小編整理的J2EE應用服務器集羣簡介，希望大家認真閱讀!
負載均衡器(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樹的其他優點:伸縮僅僅需要需要增加額外的服務器.
