構建一個高可用 WebSphere Business Events 事件基礎設施

簡介： 在本文中，您將學習如何使用 WebSphere Application Server 中的 WebSphere Business Events 和 WebSphere MQ 部署一個高可用架構。

簡介

IBM WebSphere Business Events（以下稱為 Business Events）幫助您基於可操作事件模式的發現來檢測、評估和響應事件影響。它允許您定義和管理事件，使您能夠及時採取行動。結果是憑藉無程式碼實現減少了總體擁有成本。為了確保 Business Events 部署是高可用的，在您的實現過程中可以利用現有的 WebSphere Application Server Network Deployment（以下稱為 Application Server ND）高可用性特性。

目前，利用 WebSphere Business Events 中的 Application Server 功能需要額外配置。在本文中，您將學習如何部署一個高可用架構，使用 Application Server ND 內部功能及 WebSphere Business Events 和 WebSphere MQ（以下稱為 MQ） 中的特定應用程式設定，來提供高可用性。

“高可用性” 這一術語有很多定義，但是通常是指一個系統在絕大多數時間內是可用的，例如，一個系統有最小停機時間 —— 諸如升級或維修等必須的計劃停機時間。可用性是以正常執行時間除以總時間的百分比來測量的。當數字大於 99. x 就是高可用性，其中 x 代表 1 到 3 位精度（例如，99.999% 可用性稱為 “5 個 9 可用性”）。

術語可用性 和 高可用性 的含義有很大的不同，根據使用者而定。這兩個術語經常用來描述各種業務目標和技術需求，從純硬體可用目標到任務關鍵型目標。

一個可用系統是由一組系統級共享資源組成的系統，共同合作提供重要服務。高可用性系統將軟體和工業標準硬體相結合，在系統、元件或應用程式發生故障時快速恢復來使停機時間最小化。儘管不是即時的，但服務也是很快恢復的 —— 通常小於一分鐘。

萬一軟體或硬體發生故障，一個高可用性解決方案保證系統自動恢復。實現高可用性的目的是減少計劃停機時間和最小化非計劃停機時間。通常，組織機構對高可用性目標有不恰當的預期，他們想要比他們實際願意支付的更高階別的可用性。在瞭解實現的總成本之後，許多組織機構需要修改他們的需求。實現一個高可用性解決方案包括、但不限於以下成本：

• 硬體
• 軟體
• 網路基礎設施
• 培訓
• 可服務性
• 操作

如果停機時間接近 0 ，那麼高可用性接近 100%。停機時間包括計劃內和計劃外停機時間。

表 1. 停機時間平均值

百分比	每週停機時間（小時）	每週停機時間（分鐘）	每年平均停機時間
90.000%	10	600	28080 分鐘
99.000%	1	60	3089 分鐘
99.900%	0.1	6	526 分鐘
99.990%	0.01	0.6	53 分鐘
99.999%	0	0.06	5 分鐘

根據 Gartner Research Note, ID Number: AV-13-9472，停機的原因及其發生概率，列舉如下：

表 2. 停機原因和概率

停機原因	概率
軟體故障（非計劃的）	40%
硬體故障（非計劃的）	10%
人為錯誤（非計劃的）	15%
環境問題（非計劃的）	5%
計劃停機時間	30%

從表 2 可以看出，停機原因有兩類：計劃停機和非計劃停機。與環境相關的硬體故障發生的機率最小，而軟體故障和計劃停機佔整個系統停機時間的70%。

基於上述表格以及期望的 99.99% 的高可用性，各個原因的可允許停機時間如表 3 所示：

表 3. 各個原因的可允許停機時間

停機原因	一年內的停機時間
軟體故障（非計劃的）	21 分鐘
硬體故障（非計劃的）	5 分鐘
人為錯誤（非計劃的）	8 分鐘
環境問題（非計劃的）	3 分鐘
計劃停機	16 分鐘

您可以通過以下步驟最小化硬體故障恢復時間：

• 硬體冗餘定址：硬體冗餘包括冗餘路由器、伺服器、磁碟和電源供應。冗餘硬體不僅限於上面正在執行架構的物理裝置，還有相關的基礎設施，比如電源和冷卻裝置。
• 提供故障自動檢測：為了提供真正的硬體恢復，您需要某種形式的故障自動檢測。這通常可以由諸如高可用性 Cluster Multi-Processing (HACMP)、Application Server ND 以及其他高可用性解決方案等軟體提供，具體取決於實現平臺和解決方案的複雜程度。
• 使用熱插拔硬體裝置：硬體恢復時間可通過使用磁碟、網路卡之類的熱插拔硬體裝置來達到最小化。
• 為系統物理位置提供一個穩定安全的環境：使用一個穩定安全的系統物理位置可以最小化環境相關問題。例如，伺服器是在某人的桌子下發生故障的機率大於在一個安全的位置。

您可以通過以下操作最小化人為錯誤：

• 提供一個整潔的系統管理介面：對於高可用性的人為錯誤，一個最大的障礙是缺少整潔的系統管理介面。如果您的支援人員需要通過多個控制檯來管理一個流程或檢測一個錯誤條件，人為錯誤例項將會增多。
• 提供一個整潔的系統操作過程：因發生故障而導致額外停機時間的第二個問題就是缺少一個整潔的系統操作過程，這可能和企業級災難一樣複雜，也可以像為特定應用程式定義一個流程那樣簡單。無論哪種情況，您需要將這些計劃儲存在一個便於恢復的地方，這些檔案也被稱為操作過程檔案，通過使用一個定義良好的、整潔的操作過程，您可以最小化計劃和非計劃停機時間。

提高可用性的其他的一些方法，包括：

• 軟體冗餘定址
• 提供軟體故障自動檢測
• 提供軟體服務自動恢復
• 提供特定軟體配置
• 特定應用程式設計定址

對於 Business Events V6.2 和 V7.0，相比最初版本，提供一個高可用性環境的能力已經有了極大的提高。對於 Business Events，IBM 通過開拓本地 Application Server ND 功能提供了一個完整的可審計且可用的解決方案。然而，技術聯結器（technology connectors）不能利用這個功能，因此它們不得不依賴另一個方法提供高可用性。

Service Integration Bus（以下稱為 SiBus）是一個邏輯實體，是在 WebSphere Application Server 安裝之後，通過管理控制檯或 wsadmin 指令碼語言配置和建立的。您可以使用這兩種模式在 Application Server 叢集上配置 SiBus，具體取決於部署需求。由於 SiBus 是一個基於訊息驅動 bean（message-driven bean，MDB）的物理實現的邏輯實體，所以沒有固有的高可用性和工作負載功能。您需要在建立之前單獨配置底層物理實現。

本文其餘部分將向您展示一個使用 WebSphere MQ 作為外部訊息傳遞匯流排的高可用 Business Events 基礎設施。再一次記住，技術介面卡從本質上來說是不能被構建成高可用的。然而它們以一種主動/被動模式執行來為 feeder 應用程式提供更高階別的可用性。Business Events 本質上是不持續的，通常在一段時間以後就是無效的。因此，預設情況下，所有事件本質上都是非持續的，那些經過了故障倖存的事件狀態應該被設定為持續的，並在 Business Events 中定義為持久（durable）事件。

當一組應用程式伺服器在一個單元中建立時，高可用性叢集配置是預設建立的配置。當 SiBus 被建立之後，僅僅在叢集伺服器其中一個上有一個活動的訊息傳遞引擎，叢集成員的所有服務請求都通過這個惟一的訊息傳遞引擎選擇路徑傳送。因此，對於一個有 n 個伺服器的叢集，只有一個本地訊息 put 操作可以使用活動訊息傳遞引擎來指定路線傳送服務請求 ，而其他伺服器上的（n-1 個）遠端訊息 put 操作只能使用非活動訊息傳遞引擎。

這種配置的優勢是，當一個訊息傳遞引擎發生故障時，另一個伺服器變成活動的，所有遠端 put 活動通過最新活動的訊息傳遞引擎選擇路線傳送。也就是說，因為只有一個伺服器可以指定路線傳送訊息到目標伺服器，訊息序列堅持通過匯流排。

這種配置的不足之處與效能有關，實際上叢集配置中有一個訊息傳遞瓶頸，就是所有服務請求（n-1）是遠端 puts 到活動訊息傳遞引擎的。

通過使用 MQ 附帶的高可用性服務應用程式，例如 HACMP、Microsoft™ Cluster Service 或者 Veritas Cluster Server，您可以進一步增強饋送 Business Events 引擎 的 MQ 佇列管理器以及技術聯結器的可用性。

一個服務設定必須包含需要傳遞高可用服務的所有流程和資源，理想狀況下應該是隻包含這些流程和資源。推薦您使用佇列管理器和 JMS 介面卡作為 MQ 故障轉移單元。因為 Application Server ND 將使用 Application Server 高可用性來處理應用程式故障轉移。因此為了達到最優配置，您應該將每個佇列管理器放在一個單獨的包中，包括佇列管理器使用的共享磁碟，它應該放在專為包預留的卷組中，IP 地址用來連線佇列管理器（IP 地址包）和代表佇列管理器的應用程式伺服器。

用於高可用性叢集的佇列管理器在共享磁碟上應該有自己的日誌和資料，以便在節點故障時可通過一個倖存節點對其進行訪問。執行佇列管理器的節點必須在內部磁碟上保持一定數量的檔案。這些檔案包括如 /var/mqm/mqs.ini 這類與所有佇列管理器相關的檔案以及用於生成內部控制資訊的特定管理器檔案。因此，與佇列管理器相關的檔案被分為內部的和共享磁碟的。使用一個共享磁碟即可恢復所有和佇列管理器相關的資料（日誌和資料）。

圖 1 描述了一個典型的 active/passive 配置。在每個訊息傳遞伺服器上有一組應用程式程式碼，由 MQ server、Business Events 的 JMS 介面卡和 Application Server 的客戶端連線包組成。當出現一個高可用性事件時，這個資源組將故障轉移到輔助計算機上，從停止的地方繼續進行處理。

圖 1. 典型 active/passive 配置

圖 2 描述了高階業務事件解決方案，由一個 MQ 叢集和一個 Business Events 叢集組成。Business Events 叢集通過利用 JMS 操作和事件點（event points）或者操作佇列和事件佇列與 MQ 叢集通訊。這些佇列型別的定義都不相同，每個都有限制。圖 2 展示了用於事件流的配置。

圖 2. 事件流配置

Business Events 伺服器預設的配置是使用訂閱點。這些配置有一個本質問題，同越過訂閱者向複製事件主題使用訂閱的解決方案一樣。您可以用一個閘道器事件引擎來處理這個問題，但這將會導致單點故障或複雜的額外層，這在任何情況下都是不需要的。

連通的第二個方法是使用技術聯結器，技術聯結器使用在工具中為接觸點定義的引數。 通過利用點對點佇列，以及通過 MQ 使是事件流負荷從入站邊保持平衡，可以確保沒有複製事件被 Business Events 接受。

配置 Business Events 的第 3 個方法是使用一個靜態佇列，該方法的侷限之處是在事件伺服器上沒有分離事件。所有事件都在這一個序列中處理，然後轉入一個操作序列，這種配置需要一個外部代理來將操作路由到最終目的地。

此時，您應該意識到任何動態的（in-flight）、非持續的（non-persistent）且非持久的（non-durable ）事件在發生故障時將會丟失。至於上下文資料，應該被持久化到步驟表（steps table），在其失敗時可用於 Business Events 節點。這個配置有一個眾所周知的侷限：就 JMS 技術聯結器而言，不允許開啟安全性。由於 Technology Connector Framework 中的限制，其他技術聯結器在此時也不能提供高可用性。這個問題我們稍後解決。如果某種情況下，您需要使用其他技術聯結器的高可用性。建議您使用其他形式的整合匯流排，例如 WebSphere Message Broker 或 WebSphere Process Server 代替相關的技術聯結器。

MQ 叢集將為所有入站事件提供負載平衡，JMS 介面卡和佇列管理器將故障成對轉移到可用叢集的被動節點。然而使用 MQ 叢集將導致上下文事件在 Business Events 伺服器叢集中多次跳轉，因為這些事件是與一個 Business Events 節點關聯的。所以您需要預計這類物件的額外延遲。

當您需要一個更加健壯的高可用性環境時，您應該在每個 Application Server 例項中配置一個輔助的閒置容器來過渡故障。當事件被接入 Business Events 引擎時，將出現額外負載平衡，因為這是 Business Events 叢集基本功能的一部分。建立步驟表來使用 ObjectGrid 進行復制；這個表應該由 DB2® 或 Oracle® 等資料庫備份。對於這種配置，資料將複製到叢集中的所有節點。當持久事件被用於失敗事件時，上下文資料將被用來從故障點恢復。這些副本在叢集中是處於非活動狀態，直至事件的上下文相關的節點不再可用，此時，ObjectGrid 為事件分配一個新的上下文控制程式碼，處理工作繼續進行，在特定事件叢集中任一時刻僅有一個上下文控制程式碼是可用的，這就是導致前面提到的多次跳轉的原因。

圖 3. 健壯的高可用性架構

在您計劃高可用性事件基礎設施時，要記住只有持久事件在經過故障裝轉移後才能被保留下來。一旦事件耗盡佇列資源時，這些事件將不能回滾。

以下配置為執行在 Application Server ND 叢集之下的每個 Business Event 節點建立了一個例項，附帶為叢集的每個節點建立一對被動機（passive machine）。這種分離允許一個節點接受標準維護，而其他節點繼續處理。此外，成對的故障轉移節點允許節點和所有的資源（包括 MQ）作為一個單元轉移到被動機上。用於傳出和傳入訊息的 MQ 佇列被儲存在一個通用儲存陣列網路中，標準高可用過程可用於故障轉移。圖 4 顯示了一個常用的生產區域平臺佈局。

注意： 由於事件聯結器不能用於此配置中，入站 JMS 流量僅限於一個持久或非持久事件佇列。

圖 4. 使用非 Tech Connectors 架構

注意： MQ 安全性不可用，因為技術聯結器目前在某種程度上不支援提供高可用性，如果 MQ 和 技術聯結器不能將儲存在儲存陣列網路啟動器中的日誌和佇列成對轉移，解決方案訊息可能無法傳遞。下述圖表展示了此架構是如何工作的。

以下配置為執行在 Application Server ND 叢集之下的每個 Business Event 節點建立了一個例項，附帶為叢集的每個節點建立一對被動機。這種分離允許一個節點接受標準維護，而其他節點繼續處理。當事件出現時，被動機將被啟動，處理節點加入 MQ 叢集，開始接受事件。這使額外處理過程被執行，根據需要開始或停止例項，允許它加入叢集。

上述設計的另一個變體是將 MQ 和技術聯結器放在一個高可用性伺服器組中，讓它們成對故障轉移到被動盒（passive box）中。這需要技術聯結器配置釋出到一個 Business Events 主題上而不是在同一機器上，這也需要 MQ 將其佇列和日誌放到一個儲存陣列網路中，很像產品中展示的首要解決方案。

注意： MQ 安全性不可用，因為目前技術聯結器在某種程度上不支援提供高可用性，如果 MQ 和技術聯結器不能將儲存在儲存陣列網路驅動器中的日誌和佇列成對轉移，解決方案訊息可能無法傳遞。

圖 5. 技術聯結器高可用性

表 4. Business Events 的 WebSphere ND JMS 設定。

主題	名稱	變成靜態佇列
操作主題	jms/actionTopic	可以轉變成靜態佇列
持久操作主題	jms/durableActionTopic	可以轉變成靜態佇列
持久事件主題	jms/durableEventTopic	可以轉變成靜態佇列
事件主題	jms/eventTopic	可以轉變成靜態佇列

在 Business Events 管理控制檯 JMS 配置對話方塊中，您可以找到以下佇列設定。如表 4 所示，所有這些 JMS 實體既可以是釋出-訂閱（pub-sub），也可以是靜態佇列。預設情況下是釋出-訂閱。如果技術聯結器不可用，您將需要手動配置這些 JMS 實體來使用靜態佇列代替。也要注意，所有訊息必須在 Business Events V6.2 模式中，如 WebSphere Business Events V6.2 Information Center 中所描述的。您還被侷限於兩個輸入和兩個輸出佇列，一個是持久的，一個不是持久的。如果想要直接使用這些佇列，建議您將 WebSphere Message Broker 或 WebSphere Process Server 放入您的架構中，以便於處理傳輸和為事件從 Business Events 伺服器中傳出傳入選擇路線。

本文講述了在一個高可用環境中如何通過使用 Application Server 內建的功能利用 Business Events，以及額外設定和配置選項來啟動高可用企業事件基礎設施。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-672123/，如需轉載，請註明出處，否則將追究法律責任。