WebSphere Process Server 移植最佳實踐

引言

從 WebSphere Process Server (WPS) 6.1 版本開始，WPS 支援執行時的版本移植，這意味著客戶可以通過圖形化嚮導工具（GUI）或命令列工具，對 WPS 進行版本的升級，而不需要重新搭建新版本環境。已部署的應用程式可以在更新後的系統上繼續執行，無需進行任何更改或重新配置操作，這一功能對客戶是十分關鍵的。

對於含有叢集的網路部署環境，有兩種方式進行移植：服務停止時間不敏感移植和服務停止時間敏感移植。服務停止時間不敏感移植是目前推薦的最安全的移植方案。在叢集停止服務時間不為主要考慮因素的前提下，我們推薦使用此方案對您的環境進行移植。本文以 WPS 6.1.2 移植到 WPS 6.2 為例，講述了通過服務停止時間不敏感的移植方式對 WPS 移植的主要步驟。

注意：本文只適用於在分散式平臺上的移植過程。

移植前 WPS 6.1.2 的拓撲結構

您可以通過閱讀 developerWorks 網站文章，瞭解更多關於 WebSphere Process Server 的遷移及移植策略： WebSphere Process Server 產品的執行時升級和移植策略及參考實現：本文將對 WebSphere Process Server 的執行時系統升級和移植策略進行全面系統的介紹，並結合一些典型的拓撲結構給出相應的參考實現。 要了解更多關於 WebSphere Process Server 的資訊，請檢視： WebSphere Process Server 產品專題，其中為您提供了關於 WebSphere Process Server 的最新技術資源。

本文中，我們進行的移植的拓撲結構如圖 1 所示：

圖 1. 遠端訊息和遠端支援叢集拓撲

這個叢集環境由三個叢集組成：

應用程式叢集——Application Target Cluster (App Target)；

遠端支援叢集——Support Cluster (Support)；

遠端訊息叢集——Messaging Cluster (Messaging)。

以上叢集成員分佈在三個自定義節點（custom node）：Node01，Node02 和 Node03 上。

注意：在以上拓撲結構中使用了兩個資料庫。除了為 Business Process Choreographer Observer 元件配置了單獨的資料庫 ----- OBSVRDB 以外， WPS 的其它元件都共用一個資料庫—— WPRCS612。

移植之前的注意事項

在系統移植之前，需要做好舊環境的確認和備份工作（其中包括對 WPS 概要配置檔案和資料庫的備份）。

移植前環境的確認

1. 重新啟動整個環境，檢查重啟後的日誌檔案，確保日誌中沒有錯誤和警告資訊。

2. 停止所有的應用伺服器，節點和部署管理器。

環境備份

1. WPS 6.1.2 環境備份。有兩種方式可以完成備份工作：

a. 備份整個 WPS 6.1.2 的安裝目錄。根據您的作業系統平臺，具體操作如下：

Windows 環境，把整個安裝目錄壓縮成 zip 檔案格式；

Unix 環境，應用 "tar -cvf" 命令備份整個安裝目錄

需要恢復環境的時候，只要刪除舊的 WPS 6.1.2 安裝目錄，然後把備份檔案解壓縮到相應目錄就可以了。

b. 執行 backupConfig 命令備份部署管理器和其它幾個節點的概要配置檔案。

具體命令語法如下：

backupConfig [options]

backup_file 為備份後儲存的檔名稱。如果不指定儲存檔名稱，backupConfig 命令會自動生成一個唯一檔名。恢復環境時，應用 restoreConfig 命令進行操作。

2. 備份資料庫：備份 WPRCS612，OBSVRDB 和其它所部署的應用所用到的資料庫。

移植步驟

在本章中我們將講述如何採用服務停止時間不敏感的移植方式對 WPS 進行移植。這裡，我們只列出了移植過程的主要步驟和需要注意的一些特殊事項，詳細步驟請參閱本文附件。

安裝 WPS 6.2 版本

1. 在每臺需要做移植的機器上安裝 WPS 6.2 版本。這裡先不要建立概要檔案。

2. 閱讀移植資訊即時更新站點，檢查 WPS 6.2 是否需要安裝補丁。

3. 在移植工作之前，對 WPS 6.2 的安裝目錄也做一個備份，以便在移植的過程中發生異常後可以迅速的回退到最初環境，重新進行移植。

移植部署管理器（dmgr）

1. 部署管理器（dmgr）移植。有兩種方式可以對部署管理器進行移植——圖形化使用者介面（GUI）方式和命令列方式。本例中我們用 GUI 方式對部署管理器進行移植。

2. 在部署管理器的安裝目錄執行以下命令，啟動圖形介面移植嚮導：

/bin/wbi_migration.[bat | sh].

3. 根據圖形介面移植嚮導的具體提示，選擇要被移植的源概要檔案，然後建立目標概要檔案。

注意：在移植前不要提前手動的在 WPS 6.2 安裝目錄中建立概要檔案，否則有可能會遇到異常錯誤。

4. 根據圖形介面移植嚮導的具體提示，填寫移植的備份目錄。

5. 如果在移植前的環境中啟動了管理安全設定，則需要在此步驟中輸入設定的使用者名稱和密碼，如圖 2。

圖 2. Additional migration options 視窗

6. 直至嚮導提示移植完成 --"The migration completed successfully"。

7. 檢查日誌檔案裡是否有錯誤資訊。如果發現有異常資訊，需要恢復一個乾淨的 WPS 6.2 環境，然後重新按照以上步驟再次進行移植工作。

以下是在移植完成後需要檢查的日誌檔案：

a. WBIPreUpgrade..log；此日誌檔案儲存在移植備份目錄中。

b. WBIPostUpgrade...log；此日誌檔案儲存在移植備份目錄中。

c. WBIProfileUpgrade.ant. ..log；此日誌檔案儲存在移植備份目錄中。

d. WBIMigration..log；此日誌檔案儲存在移植備份目錄中。

e. _create.log；此日誌檔案儲存在 /logs/manageprofiles 目錄中。

更新 CommonDB 的資料庫模式

將部署管理器所在機器中的 /dbscripts/CommonDB/DB2/ 目錄拷貝到資料庫伺服器，在資料庫伺服器上執行該目錄下的命令 upgradeSchema.bat。根據命令視窗中的提示逐一輸入要遷移的 WPS 版本、資料庫名稱以及資料庫使用者名稱等資訊，如圖 3。

圖 3. 更新 CommonDB 資料庫模式命令視窗

啟動部署管理器（dmgr）

啟動移植後的 WPS 6.2 部署管理器：在目錄 /profiles//bin 下，執行 startManager.sh/startManager.bat 命令。

移植自定義節點

完成部署管理器的移植後，同樣可以使用 GUI 和命令列兩種方式對單元中其它的自定義節點進行移植。

注意：

①在移植自定義節點前，必須保證已移植的部署管理器處於啟動狀態；

②要逐一遷移同一單元中的自定義節點，不能同時升級多個節點；

③自定義節點移植完成後，不要立即啟動節點和叢集伺服器，還有其它步驟需要完成；

④如果在自定義節點移植的日誌檔案中發現異常資訊，需要恢復環境重新對部署管理器和所有自定義節點進行再次移植，而不是簡單的只對移植失敗的節點進行重新移植。因為在第一次的移植過程中，新建立的節點已經聯合到了部署管理器概要中，不恢復整個環境而只對失敗節點進行移植，會導致移植工作的再次失敗。

自定義節點 GUI 方式移植的具體步驟與部署管理器的移植過程相似。本例採用 GUI 方式來移植單元中的第一個和第二個自定義節點。採用命令列的方式來對單元中的第三個自定義節點進行移植。需要執行兩個命令（WBIPreUpgrade 和 WBIPostUpgrade），具體語法如下：

WBIPreUpgrade.sh backupDirectory 
 currentWebSphereDirectory
 [-profileName profile_name]
 [-username userID]
 [-password password]
 [-traceString trace_spec [-traceFile file_name ]]

WBIPostUpgrade.sh backupDirectory
 [-username userID]
 [-password password]
 [-oldProfile profile_name]
 [-profileName profile_name]
   [--createTargetProfile]
 [-scriptCompatibility true | false]
 [-portBlock port_starting_number]
 [-backupConfig true | false]
 [-replacePorts true | false]
 [-keepAppDirectory true | false]
 [-keepDmgrEnabled true | false]
 [-appInstallDirectory user_specified_directory]
 [-traceString trace_spec [-traceFile file_name]]

注意：執行 WBIPostUpgrade 命令時的引數“-createTargetProfile”是用來在 WPS 6.2 版本上建立新的概要檔案，相當於圖形化移植工具中建立的目標概要。這兩個命令在自定義節點的 /bin 目錄下。

更新叢集

在遷移過的 WPS 6.2 部署管理器所在機器上，進入部署管理器概要的“bin”目錄，依據作業系統平臺，對單元中移植過的每一個叢集執行以下命令：

Windows 環境：

\bin\ws_ant –f \util\WBIProfileUpgrade.ant –DmigrationDir= -Dcluster=

UNIX and Linux 環境：

/bin/ws_ant.sh –f < WPS6.2_HOME >/util/WBIProfileUpgrade.ant –DmigrationDir= -Dcluster=

注意： 指的是部署管理器的移植備份目錄， 指的是 WBIProfileUpgrade 命令執行的目標叢集名稱。

更新業務流程編排器資料庫模式

1. 在啟動移植完成的自定義節點和叢集之前，需要將指令碼 \dbscripts\ProcessChoreographer\\upgradeTablespaces612.sql 和 upgradeSchema612.sql 拷貝到資料庫伺服器，手動的執行指令碼從而實現對資料庫（WPRCS612）模式的更新。如果在您的環境中為業務流程編排器（Business Process Choreographer ）功能配置了專門的 BPEDB，則對 BPEDB 執行指令碼進行模式更新。

2. 修改 upgradeTablespaces612.sql 指令碼，用 DB2 資料表空間容器所在目錄來替換指令碼中的‘@location@’字串（本文中替換為‘D:\DB2’）。 upgradeTablespaces612.sql 指令碼只是針對 DB2 資料庫，如果您應用的是其它型別的資料庫，可忽略此步驟。

3. 登入管理控制檯，檢查業務流程編排器資料來源的模式（schema），下圖可以看到本文中業務流程編排器資料來源的模式為‘WPRBE00’。

圖 4. 資料來源

4. 在 db2 命令列，連線資料庫，將模式（schema）設定為‘WPRBE00’，然後執行 upgradeSchema612.sql。

注意：

①指令碼名稱末尾的數字表示被移植 WPS 環境的版本號，例如本例中是從 WPS6.1.2 移植到 WPS6.2，則需要執行的指令碼名稱末尾數字應該為“612”。如果找不到相應名稱的指令碼檔案，就表示在進行移植的兩個版本之間，資料庫模式沒有變化。

②如果為業務流程編排器配置了單獨的資料庫（ BPEDB），就要對相應的業務流程編排器資料庫執行以上更新模式指令碼。

③如果資料庫是在預設使用者表空間中建立，則執行字尾為“nonp”的指令碼 upgradeSchemanonp.sql ；否則執行指令碼 upgradeSchema.sql 完成資料庫模式更新。

5. 更新資料庫模式後，還要選擇一個應用程式叢集成員所在的節點，在該節點上相對於本應用叢集所用到的資料庫手動執行指令碼—— migrateDB.py（注意：如果單元中有多個應用程式叢集，而且都已經完成移植，則需要針對每一個應用叢集執行該指令碼）。在 WPS 6.2 的移植過程中這一步驟是必須執行的。

用法：

wsadmin -conntype NONE -f migrateDB.py -dbUser -dbPassword

([-node ] -server ) | (-cluster )

[-dbUser ] -dbPassword [-dbSchema ]

注意：引數 -node，-server 和 -cluster 表示遷移完成的配置了業務流程編排器（Business Process Choreographer ）的節點、應用伺服器和叢集名稱；

引數 -dbUser 和 -dbPassword 指的是連線資料庫所用的使用者名稱和密碼；

引數 -dbSchema 為該應用程式叢集所用到的資料庫模式名稱。

移植後的其它工作

1. 在啟動移植完成的自定義節點和叢集之前，在資料庫伺服器上手動執行以下指令碼更新 Business Space 所用到的資料庫模式（注意：如果移植前的環境中未配置 Business Space，請忽略此步驟。）：

/dbscripts/BusinessSpace/DB2/ upgradeSchema612_BusinessSpace.sql

/dbscripts/BusinessSpace/DB2/ upgradeData612_BusinessSpace.sql

2. 在 WPS6.2 以前的版本中，BPC Observer 是做為一個單獨的應用。從 6.2 版本開始， BPC Observer 的功能可以在移植後整合到 BPC explorer。如果您想在移植後二者整合，需要在配置 BPC Explorer 的節點執行 migrate_BPCObserver__.jacl 指令碼。

移植後環境的確認

1. 在啟動移植後應用伺服器前，檢查各節點的移植日誌：

a. WBIPreUpgrade..log，此日誌檔案儲存在移植備份目錄中。

b. WBIPostUpgrade...log，此日誌檔案儲存在移植備份目錄中。

c. WBIProfileUpgrade.ant. ..log，此日誌檔案儲存在移植備份目錄中。

d. WBIMigration..log，此日誌檔案儲存在移植備份目錄中。

e. _create.log，此日誌檔案儲存在 /logs/manageprofiles 目錄。

2. 在啟動移植後應用伺服器後，檢查如下功能是否正常工作：

a. 進入管理控制檯，檢查資料來源連線是否正確

b. 確認所有的訊息引擎處於正常啟動狀態。本例中需要檢查以下匯流排的訊息引擎：

BPC.suse40Cell612.Bus

CommonEventInfrastructure_Bus

SCA.APPLICATION.suse40Cell612.Bus

SCA.SYSTEM.suse40Cell612.Bus

c. 檢查能否正常使用公共事件基礎設施（CEI）

d. 檢查能否正常使用錯誤事件處理器（Failed Event Manager ）

e. 檢查能否正常使用商業規則管理器（BRM）和 BPC Explorer

f. 檢查能否正常使用 Business Space

g. 檢查能否正常訪問 BPC observer

h. 檢查概要檔案下的 SystemOut.log 日誌檔案是否有異常資訊

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