將IBM WAS7隊列工廠配置到MQ羣集

Question

我試圖配置連接到羣集MQ的羣集Websphere應用程序服務器。

但是，我擁有的信息是具有不同主機名，服務器通道和屬於相同MQ集羣名稱的隊列管理器的MQ的兩個實例的詳細信息。

在websphere控制檯上，我可以看到主機名，隊列管理器和服務器通道的輸入字段，找不到可以指定多個MQ詳細信息的任何內容。

如果我選擇其中一個MQ細節，MQ羣集仍然可以工作嗎？如果不是的話，考慮到我的具體細節，我將如何啓用MQ集羣？

Answer 1

WebSphere MQ集羣影響隊列管理器如何在自己之間進行對話的行爲。它的確如此，而不是改變了應用程序連接或與隊列管理器對話的方式，因此所問的問題似乎假定WMQ中不存在某種聚類行爲。

要建立應用服務器與兩個地址，請參閱WAS V7知識中心Configuring multi-instance queue manager connections with WebSphere MQ messaging provider custom properties關於如何使用多實例CONNAME值配置連接工廠的說明。

如果您在連接工廠中指定了有效的QMgr名稱，並且應用程序連接到的QMgr沒有該特定名稱，則連接將被拒絕。通常使用多實例CONNAME來連接到多實例QMgr。這是一個高度可用的隊列管理器，它可以位於兩個不同的IP地址之一，因此在這種情況下使用真正的QMgr名稱。但是，如果您的應用連接的QMgrs是兩個截然不同且名稱不同的隊列管理器，則您應該在連接工廠中指定一個星號（*字符）作爲隊列管理器名稱，如here所述。這樣，應用程序在獲取連接時不會檢查QMgr的名稱。

如果我選擇其中一個MQ細節，MQ羣集仍然可以工作嗎？如果沒有， 考慮到我有的詳細信息，我將如何啓用MQ集羣？

取決於你的意思是「聚類」。如果您認爲該應用會看到由兩個隊列管理器託管的一個邏輯隊列，則不會。這不是WMQ集羣的工作方式。承載羣集隊列的每個隊列管理器都會獲取發送到該隊列的消息的子集。因此，從該隊列獲取的任何應用都將只能看到本地子集。

但是，如果通過「集羣」，您打算交替連接到兩個隊列管理器中的一個或另一個，並將消息傳輸到同一個集羣中但未託管在您連接的兩個QMgr中的任何一個上的隊列，那麼是的，它會正常工作。如果您的連接工廠只知道兩個QMgr中的一個，則只會連接到該QMgr，並且將消息發送到羣集仍然可以工作。但是按照我提供的鏈接中所述進行設置，並且您的應用將能夠連接到兩個QMgr中的任意一個，並且您可以通過停止連接到該連接的通道並觀察它連接到另一個通道來輕鬆測試該通道一。

祝你好運！

UPDATE：

爲了清楚詳細提供類似於hostname01，qmgr01， queueA，serverchannel01。另一個是hostname02，qmgr02，queueA， serverchannel02。

WMQ客戶端將使用多實例，只有當CONNAME連接到兩個不同的QMgrs ...

• 兩個QMgrs使用的頻道名稱是完全一樣的
• 應用程序使用星號（一個*字符）或連接請求時（即在連接工廠中）用於QMgr名稱的空間。

可以通過使用客戶端連接定義表（也稱爲CCDT）將WMQ連接到幾個不同隊列管理器中的一個，其中通道名稱各不相同。 CCDT是您使用MQSC命令創建的0​​通道創建的已編譯的工件。它包含客戶有資格連接到的每個QMgr的條目。每個可以有不同的QMgr名稱，主機，端口和通道。但是，在定義CCDT時，管理員定義了所有條目，以便QMgr名稱被替換爲應用程序高級限定符。例如，薪資應用程序想要連接到3個不同QMgrs中的任何一個。 WMQ管理員定義了具有三個條目的CCDT，但對於QMgr名稱使用PAY01，PAY02和PAY03。請注意，這不需要與實際的QMgr名稱匹配。然後，應用程序將QMgr名稱指定爲PAY*，它選擇CCDT中的所有三個QMgr。

有關CCDT的更多詳細信息，請參閱Using a client channel definition table with WebSphere MQ classes for JMS。

MQ集羣是否與應用程序服務器集羣不相似？

不，完全沒有。

其中兩個子節點連接到一個集羣。並且將使用F5 URL 將負載分配給每個節點。 WMQ是否帶有 羣集url/f5，我們只是發送消息，而 消息的分區是透明的？

否。WMQ羣集提供了一個名稱空間，應用程序和QMgrs可以在該名稱空間中解析非本地對象，如隊列和主題。連接到WebSphere MQ集羣的唯一一件事是隊列管理器。應用程序和人類用戶總是連接到特定的隊列管理器。可能有一組可互換的隊列管理器，例如CCDT，但每個都是獨立的。

隨着WAS的消息傳遞引擎可能在多個節點上運行，但它提供了一個單一的邏輯隊列，應用程序可以從中獲取消息。使用WMQ，託管該隊列的每個節點都會獲取消息的子集，並且任何使用這些消息的應用程序都只會看到該子集。

HTTP是無狀態的，因此F5 URL的效果很好。當它保持會話時，該會話主要用於優化連接開銷並且往往是短暫的。 WMQ客戶端通道是有狀態的，可協調單相和雙相工作單元。如果在UOW期間應用程序故障切換到另一個QMgr，則無法調和該UOW。

由於WMQ連接的性質，F5是從來沒有 QMgrs之間使用。它僅在客戶端和QMgr之間用於連接平衡，而不用於消息流量平衡。此外，MQ集羣的缺席或存在對於應用程序來說是完全透明的，在任何情況下，它都只是連接到QMgr以獲取和/或放置消息。使用多實例CONNAME或CCDT文件通過提供客戶端可以連接的多個等效QMgrs使該連接更加健壯，但與WMQ集羣無關。

這有幫助嗎？

請參閱：

• Clustering
• How Clusters Work
• Queue manager groups in the CCDT
• Connecting WebSphere MQ MQI client applications to queue managers