1.   多實例隊列管理器高可用架構

實例隊列管理器能夠在備用伺服器上自動地重新啟動。如下圖所示，WebSphere MQ 安裝在兩個伺服器上，其中一個伺服器處於空閑狀態。QM1 的一個實例處於活動狀態，並且正在一個伺服器上運行。QM1 的另一個實例以備用方式在另一個伺服器上運行，它不執行任何活動處理，但已準備好在 QM1 的活動實例發生故障時接管活動實例。

QM1 的活動實例在運行期間對共享的隊列管理器數據文件夾和日誌文件夾進行互斥訪問。活動實例發生故障時，QM1 的備用實例將檢測到這種情況並變為活動實例。它將以先前活動實例所遺留的狀態來接管 QM1 數據和日誌，並接受來自客戶機和通道的重新連接請求。

多實例隊列管理器是高可用性解決方案的組成部分。需要其他一些組件才能構建實用的高可用性解決方案。

• 客戶機和通道重新連接功能，用於將 WebSphere MQ連接轉移到接管活動隊列管理器實例的計算機。
• 高性能共享網路文件系統，此系統正確地管理鎖定並防範介質和文件伺服器故障。

2.   多實例隊列管理器與HA比較

傳統HA 集群是包含兩台或更多台計算機和資源（如磁碟和網路）的組，這些計算機和資源互相連接在一起並配置為當其中一個發生故障時，高可用性管理器，如 HACMP (UNIX) 或 MSCS (Windows)，將執行故障轉移。多實例隊列管理器與 HA 集群項比較，有以下差別：

	多實例隊列管理器方式	HA集群方式
實現功能	•    集成到 WebSphere MQ 中的基本故障轉移支持 •    故障轉移速度快於 HA 集群 •    配置和操作簡單 •    與 WebSphere MQ 資源管理器集成	•    能夠協調多個資源，如應用程序伺服器或資料庫 •    配置選項更靈活，包括可以包含兩個以上節點的集群 •    可以故障轉移多次，而不需要操作員干預 •    將隊列管理器的 IP 地址接管為故障轉移的一部分
局限性	•    需要高可用性且高性能的已聯網的存儲器 •    網路配置更複雜，因為隊列管理器在故障轉移時將更改服務 IP 地址 •    出現故障轉移時，必須手動重新啟動備用實例	•    需要購買附加產品和技能 •    需要可在集群的節點間切換的磁碟 •    HA 集群的配置相對複雜 •    故障轉移以往都相當慢 •    如果用於監視資源（如隊列管理器）的腳本中存在缺陷，那麼可能會發生不需要的故障轉移

3.   多實例隊列管理器創建和維護

3.1 多實例隊列管理器創建

• 在伺服器1和伺服器2上安裝WebSphere MQ、創建mqm 用戶和組以及定義/var/mqm；
• 檢查並確保兩伺服器上/etc/passwd 中mqm的uid和gid一致；
• 在伺服器1上，將要共享的公共文件夾 /MQHA中創建日誌和數據目錄。例如：

mkdir /MQHA

mkdir /MQHA/logs

mkdir /MQHA/qmgrs

• 在伺服器2上創建文件夾/MQHA，以便安裝共享的文件系統。使路徑與伺服器 1 上的路徑相同；例如：

mkdir /MQHA

• 確保 MQHA 目錄由用戶和組 mqm 擁有並且將該用戶或組擁有的訪問權設置為rwx；
• 在伺服器1上創建隊列管理器：

crtmqm -ld /MQHA/logs -md /MQHA/qmgrs -q QM1

• 在伺服器1上啟動 NFS 守護程序：

/etc/init.d/nfs start

• 在伺服器2上安裝所導出的文件系統 /MQHA：

mount -t nfs4 -o hard,intr 192.168.217.130:/ /MQHA

• 從伺服器 1 複製隊列管理器配置詳細信息：

dspmqinf -o command QM1

該命令將輸出類似以下內容，複製到伺服器2：

addmqinf -s QueueManager -v Name=QM1 -v Directory=QM1 \

-v Prefix=/var/mqm  -v DataPath=/MQHA/qmgrs/QM1

• 在伺服器2上增加隊列管理器配置信息：

addmqinf -s QueueManager -v Name=QM1 -v Directory=QM1 \

-v Prefix=/var/mqm  -v DataPath=/MQHA/qmgrs/QM1

• 使用 -x 參數以任意順序啟動隊列管理器實例：strmqm -x QM1，先啟動的成為活動隊列管理器，後啟動的成為備份隊列管理器；

3.2 多實例隊列管理器維護

• dspmq –x

顯示關於隊列管理器實例的信息，例如

dspmq -x

QMNAME(QM1) STATUS(作為備用實例運行)

INSTANCE(machine1) MODE(活動)

INSTANCE(machine2) MODE(備用)

• strmqm -x <QM>

在其中一個伺服器上使用該命令啟動該隊列管理器，-x選項允許實例故障轉移，本伺服器上的隊列管理器變為活動實例；然後在其他伺服器上使用相同的命令啟動備用實例，-x 選項允許實例作為備用實例啟動。

• strmqm <QM>

也可以將被配置為在不同伺服器上具有多個實例的隊列管理器作為單實例隊列管理器啟動和停止。如果使用不帶 -x 選項的 strmqm 命令來啟動隊列管理器，那麼在其他機器上配置的隊列管理器的實例會被阻止作為備用實例啟動。如果嘗試啟動另一實例，那麼會接收到不允許隊列管理器實例作為備用實例運行的響應。無法對備用實例發出不帶 -x 選項的 endmqm 命令。

• endmqm -s <QM>

通過對活動實例發出 endmqm -s 命令，還可以將控制權手動切換到備用實例。endmqm -s 命令在不關閉備用實例的情況下將活動實例關閉。隊列管理器數據和日誌上的互斥訪問鎖定被釋放，並且備用實例接管工作。

• endmqm -x <QM>

如果使用帶有 -x 選項的 endmqm 命令來停止備用實例，那麼該實例將停止作為備用實例，並且活動實例繼續運行。

• endmqm <QM>

如果使用不帶 -s 選項的 endmqm 命令來停止多實例隊列管理器的活動實例，那麼活動實例和備用實例均會停止。

4.   多實例隊列管理器架構考慮

通道和客戶機重新連接是備用隊列管理器實例進入活動狀態後進行的消息恢復處理的關鍵部分。

多實例隊列管理器實例安裝在具有不同網路地址的伺服器上。需要對 WebSphere MQ 通道和客戶機（具有所有隊列管理器實例的連接信息）進行配置。備用隊列管理器實例進行接管時，客戶機和通道將自動地重新連接到新網路地址處的新進入活動狀態的隊列管理器實例。用於 Java 的 WebSphere MQ 類不支持客戶機自動重新連接。

多實例隊列管理器架構與高可用性環境（如 HACMP）為集群提供虛擬 IP 地址以及將該地址傳遞到活動伺服器的方式不同。WebSphere MQ 重新連接功能不會更改或重新路由 IP 地址。它的工作方式是，使用通道定義和客戶機連接中定義的網路地址進行重新連接。

4.1 集群通道

通常，不需要進行附加的配置即可使多實例隊列管理器在集群中工作。

如果隊列管理器連接至倉儲庫隊列管理器，該倉儲庫將從該隊列管理器上 CLUSRCVR 通道的 CONNAME 中發現該隊列管理器的網路地址。對於 TCPIP 而言，如果省略 CONNAME 或者將其配置為空，那麼隊列管理器將自動設置此參數。備用實例進行接管時，它的 IP 地址將作為 CONNAME 而替換先前活動實例的 IP 地址。

4.2 非集群通道

通道的 CONNAME 屬性是逗號分隔的連接名稱列表；例如 CONNAME(‘92.46.1.1(1415), 85.42.3.8(2423)’)。系統會按照連接列表中指定的順序來嘗試那些連接，直到成功地建立一個連接為止。如果未能成功建立連接，那麼通道將嘗試重新連接。

4.3 客戶端應用程序

客戶機連接可以使用連接列表或隊列管理器組來選擇備用連接。需要強調，用於 Java 的 WebSphere MQ 類不支持客戶機自動重新連接。

隊列管理器組是在客戶機通道定義表（CCDT）中定義的連接集合。客戶機連接通道定義存儲在與伺服器上運行的隊列管理器相關聯的客戶機通道定義表中。 包含表的文件稱為 AMQCLCHL.TAB，並且是一個無法直接編輯的二進位文件。可以使用 DEFINE CHANNEL 命令在表中添加客戶機連接通道，使用 ALTER CHANNEL 命令改變表中已有條目的通道的屬性。

連接列表是指通道定義中CONNAME以逗號分隔的機器名稱列表，按照連接列表中指定的順序嘗試建立連接，直到成功建立為止。如果未成功建立連接，那麼通道將啟動重試處理過程。

通過配置多個組件，可以使客戶機應用程序自動進行重新連接，而不必編寫任何其他代碼。自動重新連接可以在客戶機應用程序中的任意位置自動恢復連接，並且恢復所有用於打開對象的句柄。相反，手動重新連接要求客戶機應用程序使用 MQCONN 或 MQCONNX 來重新創建連接並重新打開對象。

自動重新連接具有下列配置要求：

組件	要求	對不符合要求的返回
WebSphere MQ 客戶機安裝	級別 7.0.1	MQRC_OPTIONS_ERROR
WebSphere MQ 伺服器安裝	級別 7.0.1	MQRC_OPTIONS_ERROR
通道	SHARECNV > 0	MQRC_ENVIRONMENT_ERROR
應用程序環境	必須線程化	MQRC_ENVIRONMENT_ERROR
MQI	將 MQCONNX 的 MQCNO Option 設置為 MQCNO_RECONNECT 或 MQCNO_RECONNECT_Q_MGR	MQCC_FAILED（在連接中斷或者隊列管理器結束）

需要注意的是，MQCNO Option 參數僅MQCONNX需要設置，MQCONN不需要設置。另外，MQCNO Option 參數與mqclient.ini 配置文件的 Channels 節中設置 DefRecon 屬性配合使用。DefRecon 選項的解釋決於 MQCNO_RECONNECT_* 值是否仍在客戶機程序中設置以及設置為何值。如果客戶機程序使用 MQCONN 進行連接，或使用 MQCONNX 設置 MQCNO_RECONNECT_AS_DEF 選項，那麼 DefRecon 設置的重新連接值將會生效。如果程序中沒有設置重新連接值，或 DefRecon 選項沒有設置重新連接值，那麼客戶機程序不會自動重新連接。具體情況如下：

DefRecon=NO|YES|QMGR|DISABLED

• NO

除非 MQCONNX 覆蓋此選項，否則客戶機不會自動重新連接。

• YES

除非 MQCONNX 覆蓋此選項，否則客戶機將自動重新連接。

• QMGR

除非 MQCONNX 覆蓋此選項，否則客戶機將自動重新連接，但僅至同一隊列管理器。QMGR 選項與 MQCNO_RECONNECT_Q_MGR 的作用相同。

• DISABLED

禁用重新連接，即使客戶機程序使用 MQCONNX MQI 調用進行請求。

 

4.4 客戶機自動重新連接後

WebSphere MQ 客戶機環境會注意故障轉移本身，並在重新連接之後通過在客戶機中存儲某些狀態信息以及代表客戶機應用程序發出其他 MQI 調用以恢復它的 WebSphere MQ 狀態，來恢復儘可能多的上下文。例如，將恢複發生故障時已打開的對象的句柄，並且將打開同名的臨時動態隊列。但是，有一些更改不可避免，您需要進行設計以處理這些更改。這些更改可以分為 5 類：

• MQI 調用將返回新的或者先前未診斷的錯誤，直到應用程序恢復一致的新上下文狀態為止。
• 非持續性消息可能會丟失。
• 事務將被回滾。
• 在同步點外部使用的 MQGET 或 MQPUT 調用可能被中斷，且有可能丟失消息。
• 計時引起的錯誤（由於在 MQI 調用中長時間等待所致）。

關於丟失的上下文的一些詳細信息列示在下列部分中。

• 除非通過 NPMCLASS(HIGH) 選項將非持久消息放入一個隊列，並且隊列管理器故障未中斷「關閉時存儲非持久消息」這一選項，否則將廢棄那些消息。
• 連接中斷時，非持久預訂將丟失。在重新連接時，將重新建立非持久預訂。考慮使用持久預訂。
• 將重新計算獲取等待時間間隔；如果超出其限制，那麼將返回 MQRC_NO_MSG_AVAILABLE。同樣，將重新計算預訂到期時間，以給出相同的整體到期時間。
• 瀏覽游標在隊列中的位置將丟失；此位置通常在第一條消息前重新確定。

指定了 MQGMO_BROWSE_MSG_UNDER_CURSOR 或 MQGMO_MSG_UNDER_CURSOR 的 MQGET 調用失敗，原因碼為 MQRC_NO_MSG_AVAILABLE。

供瀏覽的已鎖定消息將被解鎖。

瀏覽所標記的具有句柄作用域的消息將被取消標記，並可以被再次瀏覽。

在大多數情況下，將取消標記協同瀏覽所標記的消息。

• 安全上下文丟失。嘗試使用保存的消息上下文（例如，在指定了 MQPMO_PASS_ALL_CONTEXT 的情況下放置消息）失敗，原因碼為 MQRC_CONTEXT_NOT_AVAILABLE。
• 消息標記丟失。使用消息標記執行的 MQGET 返回原因碼 MQRC_NO_MSG_AVAILABLE。

註： 作為消息組成部分的 MsgId 和 CorrelId 在故障轉移期間將與消息一起保留下來，因此，使用 MsgId 或 CorrelId 執行的 MQGET 將以預期方式工作。

• 在未落實事務中同步點下的隊列上所放置的消息不再可用。
• 以邏輯順序處理消息或者處理消息組中的消息將導致重新連接後發出返回碼 MQRC_RECONNECT_INCOMPATIBLE。
• MQI 調用可能會返回 MQRC_RECONNECT_FAILED，而不是返回目前客戶機通常接收的更一般的 MQRC_CONNECTION_BROKEN。
• 如果 WebSphere MQ 客戶機收不到隊列管理器的響應，那麼重新連接成功後將返回 MQRC_CALL_INTERRUPTED，以指示下列操作的成功或失敗：

在同步點外部使用 MQPUT 調用來傳遞持久消息。

在同步點外部使用 MQPUT1 調用來傳遞持久消息或具有預設持久性的消息。

使用 MQCMIT 調用落實事務。

• 通道作為新實例重新啟動（它們也可能是不同的通道），因此不保留通道出口狀態。
• 恢復臨時動態隊列，以作為恢復可重新連接的客戶機（已打開臨時動態隊列）這一進程的一部分。未在臨時動態隊列上恢復任何消息，但已打開隊列或已記住隊列名稱的應用程序能夠繼續進行處理。這存在一種可能性，如果該隊列正被應用程序使用而不是創建該隊列的應用程序使用，那麼它在下一次引用時可能不能快速地恢復。例如，如果客戶機會創建作為應答隊列的臨時動態隊列，並通過通道將應答消息放到該隊列，那麼該隊列不可能及時進行恢復。在這種情況下，通道通常可以將應答消息放到死信隊列。

以下文章點擊率最高