Java-Android-jwebee
          Java-Android-jwebee
          對IT人來說,要成為一個優秀的技術型管理者,除了需要具備扎實的技術基礎之外,還應該培養良好的人際關系能力、談判與溝通技能、客戶關系與咨詢技能、商業頭腦和財務技能以及創新意識,此外還要有巧妙的激勵技巧和化解沖突與解決突發問題的能力.
                WebLogic Server 群集由多個 WebLogic Server 服務器實例組成,這些服務器實例同時運行并一起工作以提高可縮放性和可靠性。對于客戶端而言,群集是一個 WebLogic Server 實例。構成群集的服務器實例可以在同一臺計算機上運行,也可以位于不同的計算機上??梢酝ㄟ^向現有計算機上的群集中添加更多的服務器實例來增加群集的容量,也可以向群集中添加計算機以承載遞增的服務器實例。群集中的每個服務器實例必須運行同一版本的 WebLogic Server。

          群集與域

          群集是特定 WebLogic Server 域的一部分。

          域是作為單元進行管理的一組相關的 WebLogic Server 資源。一個域包含一個或多個 WebLogic Server 實例,這些實例可以是群集實例、非群集實例,或者是群集與非群集實例的組合。一個域可以包含多個群集。域還包含部署在域中的應用程序組件、此域中的這些應用程序組件和服務器實例所需的資源和服務。應用程序和服務器實例使用的資源和服務示例包括計算機定義、可選網絡通道、連接器和啟動類。

          可以使用各種條件將 WebLogic Server 實例組織到域中。例如,可以選擇根據承載的應用程序的邏輯分區、地理方面的考慮或管理的資源的數目或復雜性將資源分配到多個域中。

          在每個域中,一個 WebLogic Server 實例可充當管理服務器 - 此服務器實例可配置、管理和監視域中所有其他服務器實例和資源。每個管理服務器只管理一個域。如果一個域中包含多個群集,則域中的每個群集都具有相同的管理服務器。

          群集中的所有的服務器實例必須駐留在同一域中;不能將群集“拆分”到多個域中。同樣,不能在域之間共享配置的資源或子系統。例如,如果在一個域中創建了 JDBC 連接緩沖池,則不能將其用于另一個域中的服務器實例或群集。(而是必須在另一個域中創建類似的連接緩沖池。)

          群集的 WebLogic Server 實例除提供故障轉移和負載平衡外,其他行為與非群集的實例相似。配置群集的 WebLogic Server 實例所使用的過程和工具與配置非群集的 WebLogic Server 實例所使用的過程和工具相同。但是,為了獲得群集啟用的負載平衡和故障轉移優點,必須符合群集配置的某些準則。

           

          群集的優點

          WebLogic Server 群集提供了以下這些優點:

          • 可伸縮性

            可以動態增加部署在 WebLogic Server 群集中的應用程序的容量以滿足需要。可以將服務器實例添加到群集中而不會中斷服務 - 應用程序將繼續運行而不會影響客戶端和最終用戶。

          • 高可用性

            在 WebLogic Server 群集中,當服務器實例失敗時應用程序可繼續進行處理??赏ㄟ^將應用程序組件部署到群集中的多個服務器實例“群集”這些組件 - 這樣,如果在其上運行某個組件的服務器實例失敗,則將此組件部署到的其他服務器實例可以繼續進行應用程序處理。

          群集 WebLogic Server 實例的選擇對于應用程序開發人員和客戶端是透明的。但是,了解啟用群集的技術基礎結構將有助于編程人員和管理員最大化其應用程序的可伸縮性和可用性。

          群集的關鍵功能

          本部分采用非技術術語定義了啟用可伸縮性和高可用性的關鍵群集功能。

          • 應用程序故障轉移

            簡單的說,故障轉移是當應用程序組件(在下列部分中通常稱作“對象”)正在處理某個特定作業時 - 某些處理任務部分由于任何原因而變得不可用,已失敗對象的副本將結束此作業。

            對于能夠接管失敗對象的新對象:

            • 必須存在可接管作業的已失敗對象的副本。
            • 必須存在對于其他對象和管理故障轉移的程序可用的信息,從而定義所有對象的位置和操作狀態,以便在完成其作業之前確定第一個失敗的對象。
            • 必須存在對于其他對象和管理故障轉移的程序可用的信息(關于正在進行中的作業的進度),以便接管中斷作業的對象了解在第一個對象失敗之前完成的作業量,例如,已更改的數據以及過程中已完成的步驟。

              WebLogic Server 使用基于標準的通信技術和工具 - 多播、IP 套接口、以及 Java 命名和目錄接口 (JNDI) 來共享和維護群集中有關對象可用性的信息。這些技術允許 WebLogic Server 確定某個對象在結束其作業之前已停止,以及用于完成已中斷作業的對象副本的位置。

              有關已對作業所進行的操作的信息被稱作狀態。WebLogic Server 可使用稱為“會話復制”和“可識別副本的存根控件”的技術來維護有關狀態方面的信息。如果某個特定對象意外地停止進行其作業,復制技術將啟用此對象的副本將拾取失敗對象停止的位置,并完成作業。

          • WebLogic Server 支持自動或手動將群集服務器實例從一臺計算機遷移到另一臺計算機??蛇w移的受管服務器被稱作“可遷移服務器”。本功能適用于要求高可用性的環境。服務器遷移功能對于以下方面非常有用
            • 確保“單元集服務”的不中斷可用性 - 當承載服務器實例失敗時,在任何給定的時間,單元集服務必須僅在單個服務器實例上運行,例如 JMS 和 JTA 事務恢復系統。為自動遷移配置的受管服務器在失敗時將被自動遷移到另一臺計算機。
            • 簡化重新定位受管服務器的過程以及其承載的所有服務是規劃系統管理進程的一部分。管理員可以從管理控制臺或命令行中啟動受管服務器的遷移。

              服務器遷移過程會將整個受管服務器(包括 IP 地址和承載的應用程序)重新定位到預先定義的可用主機集中的一個。

          • 負載平衡

            負載平衡是在環境中跨計算資源與網絡資源平均分發作業和關聯的通信。對于即將發生的負載平衡:

            • 必須存在可以執行特定作業的對象的多個副本。
            • 有關所有對象的位置和操作狀態的信息必須可用。

              WebLogic Server 允許群集對象 - 部署在多個服務器實例中,以便具有執行同一作業的備用對象。WebLogic Server 會使用多播、IP 套接口和 JNDI 共享和維護已部署對象的可用性和位置。





          可以群集對象的類型



          群集的應用程序或應用程序組件在群集中的多個 WebLogic Server 實例上可用。如果已群集某個對象,則此對象的故障轉移和負載平衡是可用的。將對象均勻部署到群集中的每個服務器實例,可以簡化群集管理、維護和故障排除。

          Web 應用程序可由不同類型的對象組成,包括企業 Java Bean (EJB),servlet 和 Java Server Pages (JSP)。每種對象類型都具有唯一的一組與控制、調用以及它如何在應用程序內起作用相關的行為。由于此原因,WebLogic Server 用于支持群集的方法,以及用于提供負載平衡和故障轉移的方法,會因不同的類型對象而異??稍?WebLogic Server 部署對下列類型的對象進行群集:

          • Servlet
          • JSP
          • EJB
          • 遠程方法調用(Remote Method Invocation,簡稱 RMI)對象
          • Java 消息服務 (JMS) 目標
          • Java 數據庫連接 (JDBC) 連接

          不同對象類型可以具有某些共同的行為。如果是這樣的話,則這些類似對象類型的群集支持和實現注意事項可能是相同的。在以下部分中,以下對象類型的解釋和說明通常組合為:

          • Servlet 和 JSP
          • EJB 和 RMI 對象

          下列部分簡述了 WebLogic Server 為不同類型的對象提供的群集、故障轉移和負載平衡支持。

          Servlet 和 JSP

          WebLogic Server 通過復制訪問群集 servlet 和 JSP 的客戶端的 HTTP 會話狀態,為 servlet 和 JSP 提供了群集支持。WebLogic Server 可在內存、文件系統或數據庫中維護 HTTP 會話狀態。

          要啟用 servlet 和 JSP 的自動故障轉移,會話狀態必須持久保存在內存中。有關 servlet 和 JSP 的故障轉移的工作方式信息,以及相關要求和編程注意事項。

          可使用 WebLogic Server 代理插件或外部負載平衡硬件在群集中平衡 servlet 和 JSP 的負載。WebLogic Server 代理插件可執行循環法負載平衡。外部負載平衡器通常支持各種會話負載平衡機制。

          EJB 和 RMI 對象

          可使用“可識別副本的存根控件”(可在群集中定位對象實例)處理 EJB 和 RMI 對象的負載平衡和故障轉移。為 EJB 和 RMI 對象創建可識別副本的存根控件是對象編譯過程所產生的結果。會將 EJB 和 RMI 對象均勻部署到群集中的所有服務器實例。

          可使用對象的可識別副本的存根控件完成 EJB 和 RMI 對象的故障轉移。當客戶端通過可識別副本的存根控件向失敗的服務做出調用時,該存根控件可檢測故障并在另一副本上重試此調用。

          WebLogic Server 群集支持多種負載平衡群集 EJB 和 RMI 對象的算法:round-robin、weight-based、random、round-robin-affinity、weight-based-affinity 和 random-affinity。默認情況下,WebLogic Server 群集將使用 round-robin 方法??墒褂霉芾砜刂婆_配置群集以使用其他方法之一。選擇的方法將保留在為群集對象獲取的可識別副本的存根控件中。有關詳細信息。

          JDBC 連接

          WebLogic Server 允許您群集 JDBC 對象(包括數據源和多數據源),以提高群集承載應用程序的可用性。為群集配置的每個 JDBC 對象必須存在于群集中的每個受管服務器上 - 當配置 JDBC 對象時,會將其定位到群集。

          • 數據源 - 在群集中,外部客戶端必須通過 JNDI 樹上的 JDBC 數據源獲得連接。數據源使用 WebLogic Server RMI 驅動程序來獲取連接。如果承載先前連接的服務器實例失敗,那么外部客戶端應用程序中的 WebLogic 數據源的群集識別特性將請求另一個連接。盡管不是嚴格要求,BEA 還是建議服務器端的客戶也應通過 JNDI 樹中的數據源獲得連接。
          • 多數據源 - 多數據源是一組數據源的提取,可提供與此多數據源相關聯的各數據源之間的負載平衡或故障轉移處理。就像數據源會綁定到 JNDI 樹一樣,多數據源會綁定到 JNDI 樹或本地應用程序上下文。就像在 JNDI 樹上查找數據源一樣,應用程序將在 JNDI 樹上查找多數據源,然后請求數據庫連接。多數據源會根據在多數據源配置中選擇的算法(負載平衡或故障轉移)確定要使用哪一個數據源來滿足該請求。

          使用群集的 JDBC 獲取連接

          要確保任何 JDBC 請求可由任何群集成員等同處理,群集中的每個受管服務器必須具有相似命名/定義的數據源或多數據源(如果適用)。要達到此效果,應將數據源和多數據源定位到群集中,以便它們可識別群集,如果將其用于外部客戶端,它們將可連接到任何群集成員。

          • 外部客戶端連接 - 要求數據庫連接執行 JNDI 查找,并獲取數據源的可識別副本的存根控件的外部客戶端。數據源存根控件包括承載數據源的服務器實例列表 - 服務器實例應該是群集中的所有受管服務器??勺R別副本的存根控件包括負載平衡邏輯,用于在主機服務器實例中分發負載。
          • 服務器端客戶端連接 - 對于服務器端使用,將由數據源或多數據源的本地實例處理連接請求。服務器端數據源不會由于其 JDBC 連接而轉至其他群集成員。在數據庫事務的持續時間內,并且只要應用程序代碼保留連接(除非連接關閉),連接將被固定到本地服務器實例。

          JDBC 連接的故障轉移和負載平衡

          群集 JDBC 對象不會啟用連接的故障轉移,但在連接失敗時,它將簡化重新連接的過程。在復制的數據庫環境中,可以群集多數據源以支持數據庫故障轉移和連接的負載平衡(可選)。有關詳細信息,請參閱下列主題:

           

          JMS和群集

          通過支持在群集范圍內透明訪問群集中任何 WebLogic Server 服務器實例中目標,WebLogic Java 消息傳遞服務 (JMS) 體系結構可實現多個 JMS 服務器的群集。盡管 WebLogic Server 支持通過群集分發 JMS 目標和連接工廠,但是同一 JMS 主題和隊列仍由群集中的每個 WebLogic Server 實例獨立管理。

          JMS 支持負載平衡。要啟用負載平衡,必須為 JMS 服務器配置目標。

           

           

           

          不可群集類型的對象

          以下 API 和外部服務不可在 WebLogic Server 內群集:

          • 包含文件共享的文件服務
          • 時間服務

          在群集的各個 WebLogic Server 實例中仍可使用這些服務。但是,這些服務不能使用負載平衡或故障轉移功能。

           

           



          jwebee

          我的個人網站
          posted on 2007-06-11 11:39 周行 閱讀(6174) 評論(1)  編輯  收藏 所屬分類: IT技術 、weblogic

          FeedBack:
          # re: weblogic集群
          2007-08-14 10:52 | gong1
          實現應用程序文件同步

          在企業應用程序的生命周期中,通常可以通過應用修復程序、添加新的 Web 內容或更新應用程序行為來對已部署的應用程序進行更新。一般來說,應用程序提供了允許用戶上傳在服務器端更改或創建的文件的用戶界面。

          將下面的場景作為一個示例:用戶希望更新 Web 站點徽標圖像文件,并且將原始文件作為 .war 文件應用程序的一部分進行存檔。該應用程序提供了相關的功能和用戶界面,以便用戶完成這項任務。然后,用戶選擇一個新的圖像作為 Web 站點的新徽標,并且上傳該文件。系統使用新的文件替換原始的文件,并且當用戶再次訪問他的 Web 站點時,可以看到相應的更改。在單節點環境的應用服務器中,所有這些工作都可以順利進行。然而,在集群環境中卻存在一些問題。
          這意味著,當應用程序運行于 WebSphere Application Server 時,需要在集群成員之間同步配置文件、二進制文件和資源文件。有一種機制可以處理上述問題。解決方案是使用共享的文件系統(例如,NFS)或共享的數據庫。在這個解決方案中,所有經過更改或更新的文件都位于同一個共享文件系統或同一數據庫中。對于共享的文件系統,所有應用程序都使用相同的位置,因此對于這些應用程序來說,任何文件更改都是可見的。對于共享的數據庫,應用程序可以從數據庫中獲得相應的更改。

          上述解決方案的缺點包括:

          共享的文件系統和數據庫導致一個新的單點故障。
          它增加了編程和配置工作的復雜性。
          它引入了一個新的性能瓶頸。


          另一個解決方案是使用細粒度 WebSphere Application Server 應用程序管理 API,在集群的各個成員之間實現文件同步。WebSphere 6.0 中提供了這一特性。WebSphere 6.0 中包含許多改進,從而使得應用程序的部署更加容易并且更加高效。有關詳細信息,請參見 WebSphere Application Server 信息中心。其中一個重要的改進是允許向系統提供部分經過更改的應用程序代碼。不需要停止當前正在運行的應用程序。

          WebSphere 6.0 還提供了靈活的應用程序文件管理。它允許應用程序通過以下方式進行更新:

          替換整個應用程序(例如,整個 .ear 文件)。
          替換、添加或刪除應用程序中的單個模塊(例如,.war、EJB.jar 或 .rar 文件)。
          替換、添加或刪除單個文件。
          替換、添加或刪除多個文件。


          在對集群中的某個成員上的應用程序文件進行更新之后,將使用另一個新的特性 Rollout Update 對集群中各個成員的文件進行同步。它通過以下方式對應用程序進行更新:

          保存更新的應用程序配置。
          停止給定節點上所有的集群成員。
          通過同步配置和重新啟動該節點上停止的集群成員來更新該節點上的應用程序。


          讓我們回到前面關于 Web 站點徽標更新的示例。在這個場景中,徽標的更新和同步對于用戶來說應該是透明的,無需 WebSphere 管理員進行人工干預。這就意味著,應用程序必須控制應用程序的更新,如替換存檔于 ear 文件中的原始文件,并在集群的成員之間執行文件同步。您可以通過調用 WebSphere 提供的 Java Management Extensions (JMX) 接口來完成這項任務。JMX 是一項 Java 應用程序資源管理標準。有關 JMX 的詳細信息,請參見 JMX Web 站點。圖 3 顯示了使用細粒度更新特性進行文件更新和同步的流程。


          圖 3. 使用細粒度特性更新和同步文件



          應用程序在接收到用戶上傳的文件之后,它將調用 File Updater 以構造增量 EAR 文件。這個增量 EAR 文件是一個存檔文件,它具有與完整的應用程序 ear 文件相同的結構。增量 EAR 文件和完整的應用程序 EAR 文件之間的區別在于,該增量 EAR 文件僅包含要進行更新的文件。File Updater 將構建這個增量 EAR。它可以是封裝了增量 EAR 生成邏輯的簡單 Java 類,或者是添加了驗證邏輯和生成文件的相關復雜組件。
          在集群環境中,如圖 2 所示,WebSphere Application Network Deployment 服務器中的 Deployment Manager 將接收到用戶的上傳請求,然后該請求被發送到 Node A。Node A 將執行相應的業務邏輯并使用本地文件系統中的新圖像文件替換原始圖像文件。然而該集群中其他的成員并不清楚這項更改,其本地副本并沒有得到更新。因此,該集群中各個成員之間的這個圖像文件就出現了不一致的情況。如果 Node A 因為致命錯誤而停機,而 Node B 接收到了該請求,那么仍將使用原始的 Web 站點徽標??瓷先タ蛻羲坪鮼G失了他所做的更改。

          兄臺,websphere怎么可以呢?  回復  更多評論
            
          Java-Android-jwebee
          主站蜘蛛池模板: 永昌县| 广灵县| 五指山市| 凤凰县| 西青区| 通州市| 西充县| 江川县| 六枝特区| 靖西县| 宁津县| 石狮市| 尚志市| 托克逊县| 武胜县| 丹东市| 华安县| 龙陵县| 岳阳市| 陵水| 宝兴县| 承德市| 雷山县| 天气| 义马市| 甘肃省| 稷山县| 赤峰市| 缙云县| 利川市| 宁晋县| 景谷| 丹凤县| 承德市| 元朗区| 雅安市| 蒲江县| 武夷山市| 建宁县| 湘西| 洪雅县|