簡介
隨著組織開始了解如何最佳地利用流程來幫助運行和改善其業務，業務流程管 理應用程序不斷變得越來越任務關鍵型。這意味著這些應用程序的可用性需求常 常會達到 24/7。BPM 還鼓勵持續流程改進，這意味著對應用程序的更改會更快地 以各種不同的形式完成。需要采用一些機制和技術來最大程度地減少宕機時間， 從而實現連續可用性。這些技術需要盡可能自動化，以便提高一致性和速度，並 減少指紋檢查或人為錯誤。
本文提供了在 WebSphere Process Server V7.0 中實現連續可用性的背景知 識、見解和一些實用技術。
首先讓我們來回顧一下 WebSphere Process Server 的拓撲結構。本文將重點 詳細介紹准備和設置本文所建議方法的應用階段的特殊考慮因素。因為在 WebSphere Process Server 上運行的 IBM BPM 解決方案中涉及到許多不同類型 的工件，所以需要使用不同的技術來實現想要的結果。還需要在解決方案和應用 程序級別上執行一些限制和特殊設置。每個場景都提供了詳細的解釋，包括執行 這些場景所涉及的步驟。本文將對所執行的場景和應用的基本技術進行重點描述 ，並以此為基准探索與 store-and-forward 和替代的拓撲結構配置相關的 變化。本文還將枚舉對所執行場景和一些影響的更多見解。最後，將會總結如何 對產品修復程序包應用某種類似方法。
在生產環境中嘗試這裡列出的任何過程之前，強烈建議您先全面測試它們。除 了拓撲結構之外，應用程序必須以有助於實現連續可用性的方式來創建。本文提 供了一些具體的信息，但假設應用程序會適當地處理界面變化、數據庫中需要的 表和其他資源需求。換一種說法，要認識到一些應用程序更改可能破壞兼容性， 進而導致宕機。本文關注的重點是兼容的更改。例如，我們會執行添加操作，而 不是刪除或更改操作。特定於應用程序的數據庫不會發射更改。刪除操作和更改 數據庫等操作不屬於本文的討論范圍。
Process Server 拓撲結構的背景
圖 1 給出了一個典型的 WebSphere Process Server 配置的可能形式。為了 簡單起見，本文通篇都會假設采用了一種與此類似的單細胞拓撲結構。我們不可 能介紹每一個配置場景，但我們希望提供一些可應用於絕大多數配置的通用實踐 。
圖 1. 一個包含 IBM HTTP Server 的由兩節點和 4 個集群組成的拓撲結構
所有 WebSphere Process Server 拓撲結構都會利用 4 個關鍵功能：應用程 序部署目標、消息基礎架構、支持基礎架構和 Web 基礎架構。集群 是一組執行 這 4 個功能中的一個或多個功能的服務器。可以讓一個集群執行所有 4 個關鍵 功能。但是，如果將這些功能分散在多個集群上來提高恢復能力，則有機會獲得 更高的連續可用性。
在圖 1 中所示的拓撲結構中，4 個功能中的每一個功能都有一個專門的集群 。應用程序部署目標集群 (AppTarget) 由安裝了您的應用程序的服務器組成。這 些應用程序可能包括業務流程、服務、人工任務和中介。遠程消息集群 (Messaging) 為您應用程序的異步消息和內部 Process Server 組件的需求提供 支持。支持基礎架構集群 (Support) 提供的功能為部署目標提供補充，作為一個 獨立集群，它實現了隔離，並從部署目標解除了一些特定的工作負載。最後，Web 組件集群 (WebApp) 托管了基於 Web 的客戶端應用程序，比如 Business Space 、Business Process Choreographer 工具和 REST API 服務。
此拓撲結構包含一個部署管理器和 2 個 Process Server 節點。部署管理器 的職責是管理該單元，提供一個界面來配置該單元中的各種組件。部署管理器還 負責安裝和更新應用程序，因此它對我們實現連續可用性至關重要。
一個節點 托管著一個或多個應用服務器；在此拓撲結構中，每個節點托管了 每個集群的一個成員。每個節點由部署管理器通過節點代理 遠程管理。部署管理 器與一個節點的節點代理進行通信，該節點代理進而與該節點的應用服務器進行 通信。
在 WebSphere Process Server 中，應用程序通過部署管理器使用 Integrated Solutions Console 或 wsadmin 命令行腳本工具來安裝。在安裝或 更新一個應用程序時，新應用程序的工件首先被存儲在該單元主存儲庫 中。然後 部署管理器將新應用程序的工件傳遞到每個節點的節點代理。隨後，每個節點代 理更新該節點的應用服務器上的應用程序。
IBM HTTP Server 通常用於處理 IBM BPM 環境中的 HTTP 流量。IBM HTTP Server 支持使用一個名為 plugin-cfg.xml 的文件配置路由到應用服務器的流量 。一個客戶端連接到 HTTP 服務器，並依據每個應用服務器配置來處理的負載， 這個 HTTP 服務器將客戶端的請求路由到該單元的應用服務器。在討論更新異步 應用程序時，我們將更詳細地介紹 IBM HTTP Server 配置。
在對 WebSphere Process Server 拓撲結構的基本概述中，我們大體介紹了理 解和成功使用後面介紹的過程所需的知識。
連續可用性場景中的拓撲結構角色
在 WebSphere Process Server 中實現連續可用性的關鍵是最大程度地減少應 用程序更新期間的宕機時間。我們的目標是在更新應用程序時，讓客戶端不會體 驗到任何宕機時間，最好完全注意不到任何變化。對於某些類型的應用程序，這 很簡單，無需特殊的准備。但對於大多數 Process Server 應用程序，一次零宕 機時間的更新需要精心規劃，還需要采用一個涉及到在各個節點間路由傳入應用 程序流量的特殊過程。稍後我們會詳細介紹此過程，但我們首先會概述使此目標 變為可能的 Process Server 拓撲結構。
實現連續可用性的一個前提條件是我們實現所謂的 “高可用性” 。要實現連續可用性，建議采用某種與圖 1 類似的拓撲結構：由一個 2 節點和 4 個集群組成的拓撲結構，每個節點上擁有每個集群的一個節點。在最低限度下 ，您必須有一個與消息集群分開的應用程序目標集群。這可以確保消息引擎可與 應用程序目標服務器獨立地進行故障轉移。還必須有至少兩個獨立的節點，用於 托管應用程序目標和消息集群的成員。這使您能夠停止一個節點上的服務器並更 新一個應用程序，同時讓另一個節點處理所有應用程序流量。這些建議不僅為實 現連續可用性提供了基礎，還為高可用性奠定了牢固的基礎。
Process Server 應用程序的背景
WebSphere Process Server v7.0 應用程序通常被組織為模塊單元，這些單元 以服務組件架構 (SCA) 模塊的形式進行開發和部署。一個模塊可包含各種不同的 SCA 組件，以及封裝業務邏輯的基本構建塊，這些構建塊通過一個接口向其他組 件公開。WebSphere Process Server 中的常用組件類型包括業務流程執行語言 (BPEL) 流程、中介流組件 (MFC) 和服務組件。
WebSphere Process Server 應用程序模塊通常在 WebSphere Integration Developer 中開發。開發一個模塊後，會將它導出為一個企業歸檔 (EAR) 文件。 該 EAR 通常首先部署到 WebSphere Process Server 測試環境，在該環境中，在 進行隔離測試以及與應用程序一起的整體測試。在通過全面測試後，就會將該模 塊部署到生產環境。盡管本文關注的重點是這個部署階段，但必須理解一些應用 程序開發級別上的概念，才能成功實現連續可用性。
SCA 調用風格
SCA 組件可同步或異步調用。同步調用意味著，在從被調用的組件收到響應之 前，調用方會被阻塞。因為服務請求方和服務提供方在同一個線程中運行，所以 在從提供方收到響應之前，請求方的所有處理都會暫停。
圖 2. 同步 SCA 調用
如果只在從提供方收到響應後請求方才會繼續進行相應的處理，那麼同步 SCA 調用將會很有用。
在異步調用中，調用方無需等待立即生成響應就可以調用服務。服務請求方和 服務提供方在不同的線程中運行，所以在提供方准備響應期間，請求方可繼續處 理。
圖 3. 圖 3. 異步 SCA 調用
如果 (1) 提供方可能花很長時間才能響應（幾分鐘、幾小時或幾天）或 (2) 請求方可執行不依賴於提供方返回的信息的進一步處理工作，異步調用會很有用 。WebSphere Process Server 應用程序中可使用 3 種形式的 CSA 異步調用：單 向調用、回調調用和延遲響應調用。
BPEL 流程調用中的早期綁定和延遲綁定
討論調用時要考慮的一種特殊情況是調用 BPEL 業務流程。BPEL 流程的客戶 端（調用方）可配置為對調用使用早期綁定或延遲綁定。早期綁定 意味著客戶端 被硬連接到流程的某個特定版本，而且它將僅調用該版本。更新一個通過早期綁 定調用的流程時，還必須將客戶端更新為使用新的流程版本。在延遲綁定 中，客 戶端將始終調用最新的流程版本。在運行時動態地決定客戶端調用哪個流程版本 。
根據客戶端調用 BPEL 流程的方式，早期綁定和延遲綁定可通過多種方式進行 配置。調用 BPEL 流程的一種方法是使用 Business Process Choreographer API 。在這種情況下，控制調用綁定的類型非常簡單，只需調用合適的調用方法即可 。在 Business Process Choreographer API 中，調用方法一般有兩個具有不同 簽名的版本：一個接受流程模板名稱，另一個接受模板 ID。接受模板名稱作為參 數的方法使用了延遲綁定，而接受模板 ID 的方法使用了早期綁定。
本欄目
BPEL 流程也可通過 SCA 連接從某個調用組件調用到流程組件。在默認情況下 ，從 SCA 組件對 BPEL 流程的調用是早期綁定的，因為 SCA 連接捆綁到了流程 組件的某個特定版本。可以通過 SCA 使用一個 “代理流程” 來調用 延遲綁定。此技術的詳細信息可在 WebSphere Integration Developer 信息中心 中的 創建要用於 SCA 組件和導出的流程版本 中找到。一般不建議這麼做，因為 它會創建可能影響性能的不必要的流程實例。
第三種情況是從一個 BPEL 流程調用另一個 BPEL 流程。這通過添加一個調用 活動作為調用流程的一部分來完成。要將調用設置為早期版定形式，可使用一個 SCA 連接來連接兩個流程組件。要使用延遲綁定，則不要使用靜態 SCA 連接；應 指定目標流程的模板名稱作為調用活動的引用伙伴屬性的一部分。
更新一個 BPEL 業務流程
如果僅需要更新一個 Process Server 應用程序中的一個 BPEL 業務流程，那 麼您應該閱讀本小節。如果需要更改 SCA 模塊中其他類型的組件，請參閱後面介 紹 SCA 模塊更新的兩節內容。
得益於 BPEL 版本控制，更新一個 BPEL 流程並維護應用程序的連續可用性非 常簡單。惟一的需求是，(1) 流程的調用方被配置為使用延遲綁定，(2) 流程的 舊和新版本擁有匹配的組件名稱和目標命名空間。這些需求是正常的，也是最佳 實踐，所以這裡沒有重大的限制或不便。如果這些需求得到了滿足，只要新流程 版本被設置為有效的，就會無縫地拾取該版本。
在更新一個 BPEL 流程時，您還需要考慮已運行的流程實例是否應該遷移到新 流程版本中。盡管這通常不會影響可用性，但我們仍然建議以增量方式執行實例 遷移，避免您的系統過載。
如果決定遷移正在運行的實例，可參照指南 創建流程的新版本 - 遷移正在運 行的實例 創建新的流程版本。否則，可執行 創建流程的新版本 - 正在運行的實 例使用舊版本 中的步驟。我們建議設置 “valid-from” 時間，以便 在生效前安裝新流程版本。
創建新流程版本後，可像其他任何模塊一樣部署惟一命名的 SCA 模塊，使用 Integrated Solutions Console 或 wsadmin 腳本。一定要將新流程模塊安裝為 一個新應用程序，而不是將它安裝為對現有應用程序的更新。如果執行這些步驟 ，新流程版本在變得有效時會順利地被拾取。如果您確定因為沒有其他客戶端被 早期綁定到該流程版本，所以沒有正在運行的實例，也沒有遺忘的舊的失敗事件 或消息，那麼您可以安全地刪除舊流程模塊。
在同步 Process Server 應用程序中更新一個 SCA 模塊
在一個嚴格同步的應用程序中更新一個 SCA 模塊，同時保持連續可用性，這 也非常簡單。談到 “嚴格同步”，我們的意思是應用程序中的所有調 用都保持同步。大多數 Process Server 應用程序都不屬於這個類別。對於包含 任何異步調用的應用程序，我們建議使用本文下一節中介紹的過程。
我們對同步應用程序更新的測試表明，連續可用性可在就地更新期間實現，無 需使用任何復雜的過程或特殊配置。但是我們強烈建議您在自己的測試環境中使 用您自己的應用程序進行測試，然後嘗試在生產環境中使用它。
這種就地模塊更新的步驟與其他任何 Process Server 應用程序更新大體相同 。首先，像平常一樣對 SCA 模塊進行修改。然後使用 Integrated Solutions Console 或 wsadmin 腳本部署更新的模塊。
您可能習慣性地在應用更新之前停止應用程序或服務器，但在這裡不用這麼做 。要部署更新的模塊，只需使用 WebSphere 的 Update 特性，然後保存並在節點 之間同步更改。這會將更新的模塊同時安裝到您服務器上，不會導致任何宕機時 間。在本例中，我們不建議使用 Rollout Update 特性。Rollout Update 會自動 暫停或停止每個應用服務器，以便按順序地應用更新，但在本例中，我們不希望 暫停或停止任何服務器，因為這會產生一個不可用階段。
只要您應用程序中的所有調用都是同步的，那麼使用此方法的失敗風險就非常 低。如果在測試過程中遇到困難，請參閱下一節，了解一種可以安全地用於所有 應用程序類型的技術。
更新一個使用異步或混合調用風格的 Process Server 應用程序中的 SCA 模 塊
在需要更新一個使用異步調用的應用程序中的 SCA 模塊時，實現連續可用性 會稍微復雜一些。本節將討論的過程適合所有包含異步調用或同時包含同步和異 步調用的 Process Server 應用程序。這包括使用本文之前提及的 3 種異步調用 的任一種的應用程序。
在這種情況下，實現連續可用性更復雜的原因在於，異步調用需要消息支持。 任何異步模型天生包含多個事務。隊列也是該模型的一部分。這些架構元素相結 合，使得該場景成為了比直觀的同步調用更復雜的場景。在更新期間，異步調用 的 SCA 模塊的目標隊列可能被標記為用於刪除，這些隊列中包含的任何消息都可 能會丟失。這意味著如果應用程序在繁忙地處理工作，直接就地更新可能存在風 險。因此，對於這種類型的更新，我們必須能夠控制流量流，僅在工作結束後才 更新某個特定節點上的應用程序。我們的方法將是，一次在一個節點上執行應用 程序更新，以始終保持可用性。
首先，我們將提供各種專門適用於此更新過程的 WebSphere 和 WebSphere Process Server 概念的一些背景。在嘗試該過程之前，請確保您完全理解這些概 念。因為自動化該過程有助於避免不一致性，並最大限度地減少所需的時間，所 以我們將提供一些示例腳本。本節末尾將會詳細介紹更新過程本身。
節點同步
我們可通過禁用或啟用節點同步，控制一個節點何時將收到一個應用程序的新 版本。如果禁用一個節點上的節點同步，該節點將無法知道應用程序工件主存儲 庫中的變化，因此該節點上的任何應用程序都不會更新。希望執行一次應用程序 更新時，我們重新啟用節點同步，當觸發同步後，新工件會拉入到節點的服務器 中。
我們發現在禁用或啟用節點同步後，有必要重新啟動節點代理，這樣才會讓更 改生效；因此，本文的 下載 部分中還提供了禁用、啟用和重新啟動一個節點的 示例代碼。
路由傳入的 HTTP 流量
傳入 WebSphere Process Server 的流量可能具有不同的形式，比如 HTTP、 JMS 和 MQ 流量。在本節中，我們將討論 HTTP 流量。我們需要能夠將傳入的 HTTP 流量路由到某些節點上的服務器，臨時阻止流量到達其他節點上的服務器。 我們將演示如何使用該 IBM HTTP Server 實現此操作，因為 IBM HTTP Server 不但簡單，而且在 BPM 環境中得到了廣泛應用。
IBM HTTP Server 依據它的 HTTP 插件配置文件 plugin-cfg.xml 在應用服務 器中散播 Web 請求。有關這一工作原理的詳細解釋，請參閱技術說明 理解集群 環境中的 IBM HTTP Server 插件負載平衡。
對我們而言，重要的是 <Server> 元素的 LoadBalanceWeight 屬性。 通過將服務器的 LoadBalanceWeight 設置為 0，服務器不會再從新會話接收請求 。來自現有會話的有關聯的請求可繼續路由到該服務器，只要未配置會話復制。 但是，來自新會話的所有請求將路由到 LoadBalanceWeight 大於 0 的服務器。
實現此目標的一種方法是在 IBM HTTP Server 上提供多個 plugin-cfg.xml 文件，並在必要時將它們換出。例如，假設我們有兩個應用服務器請求在正常情 況下會路由到：A.App 和 B.App。在這種情況下，我們需要使用 3 個 XML 配置 文件：一個文件允許發出針對兩個服務器的請求 (both.xml)，一個文件僅將請求 路由到 A.App (a.xml)，另一個文件僅將請求路由到 B.App (b.xml)。
在正常操作模式中，IBM HTTP Server plugin-cfg.xml 將包含 both.xml 的 內容。當在一個服務器上執行應用程序更新時，我們會簡單地將 plugin-cfg.xml 的內容換為其他的配置文件。例如，如果希望所有請求都路由到 A.App，則應將 plugin-cfg.xml 替換為 a.xml。IBM HTTP Server 無縫地挑選配置更改，並停止 將請求路由到 B.App。正常情況下，在 IHS 檢測到配置更改之前會有一個延遲， 但我們可使用以下命令適當地立即重新加載該配置：
IBM/HTTPServer/bin/apachectl -k graceful
（請參閱 下載 部分中提供的 ihs_route_to_node_a.sh。）
路由其他流量
重新路由傳入的 HTTP 流量後，集群成員仍然可以通過 JMS 或 MQ 流量收到 新工作。集群成員只有在完成處理工作之後才能關閉；因此我們還需要一種方式 來組織新的 JMS 和 MQ 流量流入。為此，我們取消激活一個集群成員的 J2CMessageEndpoints。我們會在 下載 部分提供的 quiesce_traffic_jms_mq.jacl 腳本中演示此過程。
如果 BPEL 流程已安裝並運行，我們還需要阻止 BPEL 調度程序生成的流量。 這可以通過阻止 BPEScheduler 來實現，如 下載 部分中提供的 quiesce_traffic_bpel.jacl 腳本所示。
如果創建了其他任何調度程序，那麼應該停止它們。您可以通過腳本完成此過 程，如上面的 BPEScheduler 腳本所示。
適當地停止和啟動服務器
所有傳入流量都阻止後，就可以安全地停止一個節點上的集群成員。我們建議 按以下順序停止節點的集群成員：應用程序目標集群，Web 集群，支持集群，然 後是消息集群。這可以通過 wsadmin 編寫腳本來完成，也可以通過 Integrated Solutions Console 來完成，但我們同樣推薦盡可能多地編寫腳本，以實現更高 的一致性。可以使用 下載 部分中提供的 stop_cluster_members.jacl 腳本。
更新一個節點上的應用程序之後，需要再次啟動它的集群成員。我們建議按與 停止順序相反的順序啟動集群成員；也就是啟動消息集群、支持集群、Web 集群 和應用程序目標集群。重新啟動一個集群成員後，無需重新激活 J2CMessageEndpoints 或重新啟動 BPEScheduler，因為這將在服務器啟動時自動 完成。（參見 下載 部分中提供的 start_cluster_members.jacl。）
失敗事件
在 WebSphere Process Server V7.0.0.3 中測試此過程期間，偶爾也會看到 在消息引擎故障轉移期間會發生 SCA 失敗事件。但是，根據我們的經驗，失敗事 件可在更新完成後重新提交。失敗事件管理器可在 Integrated Solutions Console 中進行訪問，也可以使用 wsadmin 腳本重新提交失敗事件。（參見 下 載 部分中提供的 resubmit_failed_events.jython。）
store-and-forward
如果希望最大限度地減少生成的失敗事件，可以使用 WebSphere Process Server V7.0 中新增的 store-and-forward 特性。如果使用此特性，在出現運行 時錯誤時，只會生成一個失敗事件。發生一個運行時錯誤後，將觸發一個存儲 操 作，一個服務的所有後續請求都會存儲在一個隊列中，而不是被提交。您隨後可 使用 Business Space 中的 Store and Forward 小部件將這些請求轉發到它們的 目的地。目前還沒有公開的 store-and-forward API 支持更改存儲/轉發狀態， 所以我們不建議通過腳本完成此步驟，但我們已驗證可以這麼做。
應用程序級設置
在 WebSphere Process Server V7.0.0.3 中測試此過程期間，我們發現了一 些最適合具有某些屬性的異步應用程序的應用程序級設置。我們遇到的大多數故 障都發生在消息引擎在集群成員之間執行故障轉移期間。要使更新過程獲得成功 ，讓您的應用程序適當地處理消息引擎故障轉移就很重要。遵循我們這裡提供的 建議會是一個不錯的開始，但考慮到 IBM BPM 應用程序和環境的易變性，可能您 的場景需要采用稍微不同的設置。因此，我們明確建議在消息引擎故障轉移期間 在負載下測試您的應用程序，以確保它得到適當的處理並且沒有丟失重要消息。
首先，如果您的模塊包含任何中介流組件，請確保失敗的終端被連接到某個失 敗錯誤處理組件。這可以確保失敗事件會被保存，失敗的事務會在必要時回滾。 如果您的模塊使用 store-and-forward，那麼我們建議您設置 store-and- forward 限定符，以便捕獲所有 ServiceRuntimeExceptions。在更新過程中，可 能發生許多類型的運行時異常，您需要確保捕獲了所有這些異常。如果您的模塊 包含任何單向異步調用，那麼我們建議將引用的異步調用限定符設置為 call，而 不是將它設置為 commit（call 是默認設置）。最後，對於任何類型的異步調用 ，我們建議將引用的異步可靠性限定符設置為 assured (persistent)。最後兩條 建議有助於確保在更新過程期間發生故障時不會丟失任何消息。
如果您的異步模塊擁有上面描述的任何屬性，我們極力建議使用這些設置。再 次申明，我們強烈要求您進行全面測試，因為一個應用程序和環境的需求可能與 另一個應用程序和環境不同。
異步應用程序中的 SCA 模塊的更新過程
我們已單獨討論了更新過程的重要元素，下面將詳細介紹該過程本身。在對包 含異步調用或混合風格調用的應用程序執行模塊更新期間，可按照以下步驟來實 現連續可用性。每一步之後是一張圖，反映了完成該步驟後該單元的組件狀態。
在開始更新之前，Process Server 調用出於其正常操作狀態。
所有 JVM 都在運行，包括部署管理器、所有集群成員和所有節點代理。為兩 個節點都啟用了自動節點同步，這用節點代理與部署管理器之間的藍線表示。節 點 A 的消息集群成員上的消息引擎 (ME) 是活動的。HTTP 流量路由到 AppTarget 集群的所有成員，如橙色的虛線所示。BPEScheduler 調度程序正在運 行。appX 的 v1 版目前部署到兩個節點的應用程序目標，也可在主存儲庫中看到 。我們將把 appX 的 v2 版部署到應用程序目標集群，一次部署一個節點。 Support 和 WebApp 集群未在這裡顯示，因為我們假設應用程序僅安裝在 AppTarget 集群上。在逐步執行的過程中，我們將用紅色突出顯示更改。
圖 4. 開始狀態
在安裝該應用程序的所有節點上禁用節點同步並重新啟動節點代理。
我們禁用了節點同步，以便在使用部署管理器更新應用程序後，節點不會立即 收到應用程序的新版本。我們僅在每個節點的集群成員適當地關閉之後，才更新 該節點上的應用程序。
這在圖 5 中表示為沒有藍線連接節點代理和部署管理器。
圖 5. 對所有節點禁用節點同步
使用部署管理器更新應用程序模塊。不要在節點之間同步更改。
使用 wsadmin 腳本或 Integrated Solutions Console 安裝更新。使用 Update 特性更新現有模塊，而不是將更新安裝為新模塊。將更改保存到主存儲庫 ，但不要與節點同步更改。
執行這一步之後，模塊的 v2 版將位於主存儲庫中，但不在每個節點的本地配 置中。在這裡，我們只演示了如何更新一個模塊，但您也可以一次更新多個模塊 ，只要更改是向後兼容的（參見第 3d 步）。
圖 6. 將更新安裝到主存儲庫
對於安裝了該應用程序的每個節點，執行以下步驟，一次處理一個節點。我們 僅演示對節點 A 的處理，但可以在節點 B 上重復這些步驟來完成更新。
停止所有傳入到節點上的集群成員的流量。這包括 HTTP、JMS、MQ 和 BPEL 流量。除非配置了會話復制，否則仍有活動的 HTTP 會話被綁定到集群成員，而 且它們可能包含任何關鍵數據，您應該等待它們關閉。
我們阻止了傳到節點上的集群成員的流量，因為我們需要在下一步中適當地停 止集群成員。在完成所有工作之前，集群成員將不會關閉；因此假設存在持續的 傳入流量，我們必須重定向該流量，以便為服務器留出充足的關閉空間。本節前 面已經介紹了如何對 HTTP、JMS、MQ 和 BPEL 流量這樣做。
這一步將在下面通過 plugin-cfg.xml 中的更改來演示。完成更改之後，所有 HTTP 請求都會路由到節點 B 上的集群成員。
圖 7. 阻止傳入到節點上的集群成員的流量
停止該節點上被應用程序利用的集群成員。
一定要按本節前面給定的順序停止集群成員：應用程序目標、Web、支持和消 息。例如，如果應用程序被部署到應用程序目標集群，那麼首先應該停止應用程 序目標集群成員，然後，因為這是一個使用異步調用的應用程序，所以應該停止 消息集群成員。如果消息引擎目前在節點上的一個集群成員上是活動的，那麼會 將故障轉移到不同的集群成員。這可能會花費幾秒或幾分鐘的時間，具體時間取 決於您的環境，但您需要在故障轉移完成之後才能繼續操作。
我們停止了集群成員，因為我們不希望在節點上的模塊更新期間執行工作。
圖 8 中的黑框顯示了已停止的集群成員。請注意，消息引擎目前在節點 B 的 消息集群成員上是活動的。
圖 8. 停止節點上的集群成員
啟用節點同步並重新啟動節點代理。如果節點未配置為在啟動時同步，則觸發 同步。等待節點同步完成，然後再進入下一步。
由於執行了節點同步，所以節點代理會收到來自主配置的更改並更新節點的本 地配置。
這一步如圖 9 中將節點代理連接到部署管理器的紅線所示。模塊的 v2 版現 在位於節點的應用程序目標集群成員之上。
圖 9. 對節點啟用節點同步
啟動您在第 3b 步中停止的所有集群成員。
現在節點已包含更新的應用程序，我們可啟動它的集群成員了。請記住，按照 正確的順序進行啟動：消息、支持、Web 和應用程序目標。
當集群成員啟動時，MDB 和調度程序會自動啟動。因為我們將在下一步中重新 啟用 HTTP 流量，所以除了集群成員本身之外，現在無需手動重新啟動任何東西 。
如圖 10 所示，可能在較短的時間內節點會同時運行應用程序的兩個不同版本 。在本例中，Module_4 的 v1 和 v2 會同時向 Module_5 的目標隊列中放入消息 。如前面所述，只要更改是兼容的，就不會出現問題。例如，如果 Module_5 需 要按與 Module_4 v2 兼容的順序更新，那麼它的新版本也必須與 Module_4 v1 兼容。
圖 10. 過渡期間的混合模塊版本
要讓這個時間段盡可能短，您應該在此節點的集群成員啟動後，立即停止下一 個節點上的集群成員。如果通過編寫腳本來完成此任務，過渡可在幾秒的時間內 完成，前提是您只有 2 個節點。如果應用程序需要在超過 2 個節點上進行更新 ，那麼您可選擇在等待啟動運行性版本的節點之後，所有運行舊版本的節點才會 停止。在任何情況下，都應在嘗試這麼做之前測試同時運行的不同版本。如果發 現任何兼容性問題，則不應使用此更新過程。
這一步在圖 11 中通過綠色集群成員來表示，這表明它們現在已經再次運行。 請注意，消息引擎仍在節點 B 的消息集群成員上運行。如果節點 A 上的集群成 員被配置為首選服務器，那麼消息引擎現在將變為在節點 A 上運行。
圖 11. 啟動節點上的集群成員
如果在第 3a 步中禁用了傳入 HTTP 流量，則啟用向節點上的集群成員的傳入 HTTP 流量。
如果有另一個節點需要更新，可通過恰當編寫 plugin-cfg.xml，將這一步與 下一個節點的第 3a 步相結合。這樣做有助於最大限度地縮短模塊的不同版本同 時運行的時間段。
圖 12. 啟用傳入的 HTTP 流量
對尚未更新該應用程序的所有剩余節點重復步驟 a 到 e。
重新提交在該過程中發生的任何失敗事件。如果您的應用程序利用了 store- and-forward，則轉發可能尚未存儲的所有事件。
更新完成！
圖 13. 最終狀態
變體：Process Server 修復程序包安裝
通過擴展上一節中描述的應用程序更新過程，我們可以在 WebSphere Process Server 修復程序包安裝期間實現連續可用性。一般方法仍然相同：一次對一個節 點應用更新，在安裝修復程序包期間將流量路由到該節點以外。
請注意，在升級期間，整個單元的健康狀況都存在風險，而不只是一個應用程 序的健康狀況存在風險。因此，在這種情況下，強烈建議在類似的測試環境中對 此過程進行全面測試之前，不要在生產環境中嘗試它。
另請注意，我們僅測試了從 V7.0.0.4 升級到 V7.0.0.5 的過程，無法保證相 同的方法會在其他情況下奏效。我們的一個假設是，修復程序包不需要任何數據 庫更新。這是因為我們在此過程的某個時刻將有一個 “混合單元”； 也就是說，集群將擁有同時運行不同 Process Server 版本的成員。如果存在數 據庫不兼容性，這可能導致嚴重問題。
我們將概述在從 V7.0.0.4 升級到 V7.0.0.5 期間，我們用於實現連續可用性 的過程。首先請閱讀 WebSphere Process Server 和 WebSphere Enterprise Service Bus V7.0.0 Fix Pack 5 (V7.0.0.5) 特殊說明，了解以最少宕機時間執 行更新的官方說明。我們這裡提供的方法對這些說明進行了修改，大致實現了相 同的最終結果（一個升級的單元），但在某種程度上實現了近連續的可用性。對 於每一步驟，請參閱官方說明中的相應步驟，以了解有關的更多信息。
Process Server 修復程序包安裝過程
在開始升級之前，Process Server 單元處於正常操作狀態。
為了演示此過程，我們將使用圖 14 中所示的部署環境，其中包含一個部署管 理器和 2 個自定義節點，二者都運行了 WebSphere Process Server V7.0.0.4。 因為這些節點托管在不同的機器上，所以每個節點可單獨升級。此刻，所有 JVM 都在運行，包括部署管理器、所有集群節點和所有節點代理。對兩個節點都啟用 了自動節點同步，這用節點代理與部署管理器之間的藍線表示。消息引擎 (ME) 在節點 A 的消息集群節點上運行。HTTP 流量路由到 AppTarget 集群的所有成員 ，如橙色的虛線所示。為了簡單起見，我們僅顯示了應用程序目標和消息集群， 事實上可能有更多的集群。我們將在執行該過程期間定期顯示此圖，以紅色突出 顯示更改。
圖 14. 開始狀態
禁用節點同步並重新啟動所有節點的節點代理。
停止部署管理器。
將修復程序包安裝到部署管理器的安裝根目錄。
啟動部署管理器。
圖 15. 安裝到部署管理器的修復程序包
對於您希望升級的每個節點，完成以下步驟，一次處理一個節點：
阻止所有傳入到節點上的集群成員的流量，包括 HTTP、JMS、MQ 和 BPEL 流 量。如果仍然有活動的 HTTP 會話被綁定到集群成員，請等待它們關閉。
停止節點上的所有集群成員。
停止節點的節點代理。
圖 16. 節點上已停止的集群成員和節點代理
將修復程序包安裝到節點的安裝根目錄中。
圖 17. 安裝到節點的修復程序包
從部署管理器，對其成員包含在此節點中的每個節點運行配置文件升級腳本。 此腳本只應對每個單元的每個集群運行一次，所以如果所有集群已升級，請跳過 此步驟。
如果配置了 Business Space 且模板/空間托管在此節點上的一個集群成員上 ，則執行 安裝或更新小部件之後更新 Business Space 模板和空間 中的第 1a 和 1b 步。這篇文章還有助於確定這些模板和空間托管在哪個集群成員上。我們 建議首先升級托管模板和空間的節點。
啟用節點同步並重新啟動節點代理。如果節點未配置為在啟動時同步，則會觸 發同步。等待節點同步完成，然後再進入下一步。
啟動您在第 5b 步中停止的所有集群成員。
如果在第 5a 步中禁用了傳入的 HTTP 流量，則啟用傳入到節點上的集群成員 的 HTTP 流量。
圖 18. 啟動集群成員，對節點啟用節點同步
對尚未應用修復程序包的剩余所有節點重復步驟 a 到 i。
重新提交在該過程中發生的任何失敗事件。如果您的模塊利用了 store-and- forward，則轉發所有可能已存儲的事件。
修復程序包安裝已完成！
圖 19. 最終狀態
結束語
通過仔細規劃拓撲結構和恰當地編寫更新業務流程解決方案組件的腳本，可顯 著改善可用性。這使得您能夠在需要近連續的可用性的環境中利用 BPM 應用程序 。除了拓撲結構之外，我們還概述了一組應用程序設計准則，提供了更新 Process Server 應用程序的各個組件的過程。盡管應用於實現連續可用性的技術 需要修改之後才適合特定組織中的具體安裝和配置，但總體思路應該是簡單明了 的。
在未來，我們預計會提供如何使用 IBM BPM V8 或其更高版本實現類似可用性 水平的更多信息。在基於 EAR 的 “僅 Process Server” 模式中使 用 IBM BPM V8 時，本文中提供的方法和細節應該同樣適用。但在該環境中，由 於存在 Process Center，而且在流程應用程序和工具包中增加了所創作的不同類 型的工件，所以您將面臨著新的挑戰和機遇。
下載
