MQ體系結(jié)構(gòu)和故障診斷V1

1、MQ體系結(jié)構(gòu)和故障診斷體系結(jié)構(gòu)和故障診斷張曉靜張曉靜神州數(shù)碼教育學(xué)院神州數(shù)碼教育學(xué)院課程目標(biāo) 企業(yè)需求 MQ的基本概念 MQ的工作原理 MQ的定義 MQ的家族產(chǎn)品 MQ的故障診斷 MQ Trace MQ FFDC WebSphere 軟件家族WMQ background IBM WebSphere MQ is a family of network communication software products launched by IBM in March 1992. It was previously known as MQSeries, a trademark that IBM reb

2、randed in 2002 to join the suite of WebSphere products. WebSphere MQ is IBMs Message Oriented MiddleWare offering. It allows independent and potentially non-concurrent applications on a distributed system to communicate with each other. MQ is available on a large number of platforms (both IBM and no

3、n-IBM), including z/OS (mainframe), OS/400(IBM System i or AS/400), Transaction Processing Facility, UNIX(AIX, HP-UX, Solaris), HP NonStop, OpenVMS, Linux, and Microsoft Windows.MQ基本概念 消息：MQ中最小的概念，本質(zhì)是一段數(shù)據(jù)，可以被多個應(yīng)用程序所理解，是應(yīng)用程序之間傳遞的信息載體。消息大致分為兩部分：應(yīng)用數(shù)據(jù)體和消息數(shù)據(jù)頭。 隊列：簡單的把隊列堪稱一個容器，用于存放消息。分為：本地隊列、遠(yuǎn)程隊列、別名隊列和模型隊

4、列。MQ基本概念 本地隊列按功能可分成初始化隊列、傳輸隊列、目標(biāo)隊列和死信隊列。 初始化隊列用做消息觸發(fā)。 傳輸隊列只是暫存待傳的消息，在條件許可的情況下，通過管道將消息傳送其他的隊列管理器。 目標(biāo)隊列是消息的目的是，可以長期存放消息。如果消息不能送達(dá)目標(biāo)隊列，也不能路由出去，則被自動放入死信隊列保存。MQ基本概念 隊列管理器構(gòu)造了對立的WebSphere MQ的運行環(huán)境，它是消息隊列的管理者，用來維護和管理消息隊列。一臺機器上可以創(chuàng)建一個或多個隊列管理器，每個隊列管理器有各自的名字，通常情況下，它不能與網(wǎng)絡(luò)中的其他隊列管理器重名。 如果我們把隊列管理器比作數(shù)據(jù)庫，那么隊列就是其中的一張表，消

5、息就是表中的一條記錄。MQ基本概念 隊列管理器負(fù)責(zé)向應(yīng)用程序提供消息服務(wù)的機構(gòu)。在WebSphere MQ中，隊列管理器集對象的定義、配置、管理、調(diào)度以及提供各種服務(wù)于一身。應(yīng)用程序必須首先連接到隊列管理器，然后在隊列管理器的控制下對各種對象進(jìn)行操作。 WebSphere MQ中的隊列管理器可以包含很多個隊列，但一個隊列只能屬于一個隊列管理器。MQ基本概念 通道是兩個隊列管理器之間的一種單向的點對點的通信連接，消息在通道中只能單向流動。如果需要雙向交流，可以建立一對通道，一來一去。站在隊列管理器的角度，這一對通道可以按消息的流向分成輸入通道和輸出通道。通過配置，對于放入本地傳輸隊列中的消息，隊

6、列管理器會自動將其通過輸出通道發(fā)出，送入對方的遠(yuǎn)程目標(biāo)隊列。消息通道協(xié)議（MCP） 消息通道協(xié)議是WebSphere MQ用來傳遞消息時使用的通信協(xié)議。MCP（Message Channel Protocol）可用于確保傳遞消息的完整性。消息通道代理（MCA） MCA是一個控制消息發(fā)送和接收的程序。在通道的每一端都有一個MCA。一個MCA是把消息從傳輸隊列取出來，然后放到通訊鏈路上。另一個MCA接收消息，并把消息放到遠(yuǎn)程隊列管理器的隊列中 。MQ的工作原理本地通信 本地通訊：應(yīng)用程序A和應(yīng)用程序B運行于同一系統(tǒng)1，它們之間可以借助消息隊列技消息隊列技術(shù)術(shù)進(jìn)行彼此的通訊：應(yīng)用程序A向隊列1發(fā)送一

7、條信息，而當(dāng)應(yīng)用程序B需要時就可以得到該信息。 遠(yuǎn)程通信 如果信息傳輸?shù)哪繕?biāo)為在系統(tǒng)2上的應(yīng)用程序C，這種變化不會對應(yīng)用程序A產(chǎn)生影響，應(yīng)用程序A向隊列2發(fā)送一條信息，系統(tǒng)A的MQ 發(fā)現(xiàn)Q2的定義所指向的目的隊列實際上位于系統(tǒng)2，它將信息放到本地的一個特殊隊列傳輸隊列(Transmission Queue)。我們建立一條從系統(tǒng)1到系統(tǒng)2的消息通道，消息通道代理將從傳輸隊列中讀取消息，并傳遞這條信息到系統(tǒng)B，然后等待確認(rèn)。只有MQ接到系統(tǒng) B成功收到信息的確認(rèn)之后，它才從傳輸隊列中真正將該信息刪除。如果通訊線路不通，或系統(tǒng)2不在運行，信息會留在傳輸隊列中，直到被成功地傳送到目的地。這是MQ最基本

8、而最重要的技術(shù)-確保信息傳輸，并且是一次且僅一次(once-and-only-once)的傳遞。遠(yuǎn)程通信 另外一種情況是到了系統(tǒng)2的MCA，但沒有到達(dá)Q2，此時將被放入死信隊列、送回到發(fā)送端、丟棄，采用那一種依賴于發(fā)送信息中消息描述符的定義。MQ的定義 MQ提供了用于應(yīng)用集成的松耦合的連接方集成的松耦合的連接方法法，因為共享信息的應(yīng)用不需要知道彼此物理位置（網(wǎng)絡(luò)位置）；不需要知道彼此間怎樣建立通信；不需要同時處于運行狀態(tài)；不需要在同樣的操作系統(tǒng)或網(wǎng)絡(luò)環(huán)境下運行。 不斷流動的消息將松耦合關(guān)系的應(yīng)用系統(tǒng)串聯(lián)起來，使它們之間的關(guān)系變成了功能疊加。 MQ的核心價值：異構(gòu)系統(tǒng)間異步通信異構(gòu)系統(tǒng)間異步通信

9、MQ家族產(chǎn)品 IBM WebSPhere MQ家族是基于消息驅(qū)動和消息觸發(fā)原理設(shè)計的。底層是面向消息的中間件WebSphere MQ，上層有面向消息整合的WebSphere MQ Integrator和面向消息流程的WebSphere MQ Workflow兩個產(chǎn)品。WebSphere MQ 問題診斷 初步分析 深入分析MQ日志 系統(tǒng)的數(shù)據(jù)日志 錯誤日志MQ數(shù)據(jù)日志 數(shù)據(jù)日志包含“data”和“action”，位置：C:Program FilesIBMWebSphere MQlog。MQ的消息數(shù)據(jù)以及用戶對MQ的操作的紀(jì)錄，是用于數(shù)據(jù)備份和系統(tǒng)恢復(fù)時使用的，也是數(shù)據(jù)不丟失、不重復(fù)的保障。 錯誤

10、日志 錯誤日志記錄MQ系統(tǒng)運行過程中出現(xiàn)錯誤 錯誤日志捕捉WebSphere MQ自身的操作、任何隊列管理器的啟動和正在使用的通道的錯誤信息 。 錯誤日志位置取決于隊列管理器名，以及錯誤是否與客戶機相關(guān)。在 WebSphere MQ Windows 版中，假設(shè) WebSphere MQ 已經(jīng)安裝在缺省位置： c:Program FilesIBMWebSphere MQ錯誤日志 若隊列管理器名稱已知并且處于運行狀態(tài)，則錯誤日志位于：c:Program FilesIBMWebSphere MQqmgrsqmnameerrors 若隊列管理器不處于運行狀態(tài)，則錯誤日志位于：c:Program Fil

11、esIBMWebSphere MQqmgrsSYSTEMerrors 若錯誤與系統(tǒng)有關(guān)，則錯誤日志位于 c:Program FilesIBMWebSphere MQerrors 若錯誤與MQ客戶端程序有關(guān)，則錯誤日志位于客戶機的根目錄：c:Program FilesIBMWebSphere MQ Clienterrors 錯誤日志 在 WebSphere MQ Windows 版中，錯誤信息也被添加到應(yīng)用程序日志中，通過查看Windows系統(tǒng)的事件查看器也可檢查WebSphere MQ的錯誤日志。錯誤日志在 WebSphere MQ UNIX 系統(tǒng)版中：若隊列管理器名稱是已知的并且隊列管理器是

12、可用的，則錯誤日志位于：/var/mqm/qmgrs/qmname/errors若隊列管理器不是可用的，則錯誤日志位于：/var/mqm/qmgrs/SYSTEM/errors若錯誤與系統(tǒng)有關(guān)，則錯誤日志位于: /var/mqm/errors若錯誤發(fā)生于客戶機應(yīng)用程序，則錯誤日志位于客戶機的根目錄中：/var/mqm/errors錯誤日志 在產(chǎn)品安裝時，在qmgrs 目錄下將創(chuàng)建SYSTEM errors子目錄。errors子目錄最多可以包含 3 個錯誤日志文件，分別是：AMQERR01.LOGAMQERR02.LOGAMQERR03.LOG在創(chuàng)建隊列管理器后，在需要時將創(chuàng)建了 3 個錯誤日志

13、文件。這些文件名是，AMQERR01、AMQERR02 和 AMQERR03 并且每一個文件的大小都為256 KB。這些文件被放置在您創(chuàng)建的隊列管理器的errors子目錄中。當(dāng)產(chǎn)生錯誤消息時，它們被放置在 AMQERR01 中。當(dāng) AMQERR01文件比 256 KB 大時，將其復(fù)制成AMQERR02。在復(fù)制前，將 AMQERR02 復(fù)制到 AMQERR03.LOG。這樣將刪除了AMQERR03的以前內(nèi)容。因此最新的錯誤消息總是放在 AMQERR01 中的，其它文件用來保存錯誤消息的歷史記錄。所有與通道相關(guān)的信息也被放在相應(yīng)的隊列管理器的錯誤文件中，除非隊列管理器不可用或隊列管理器的名稱未知，

14、則通道相關(guān)的消息是放在 SYSTEM 錯誤子目錄。使用通常的系統(tǒng)編輯器就可以查看錯誤日志文件的內(nèi)容。有些錯誤是在錯誤日志還沒有創(chuàng)建時發(fā)生的，WebSphere MQ 也會嘗試記錄這樣的錯誤日志。日志的位置取決于創(chuàng)建隊列管理器的過程進(jìn)展情況。 如果配置文件被損壞，WebSphere MQ不能讀取目錄信息，則將錯誤記錄到在安裝時創(chuàng)建的根（/var/mqm 或 C:Program FilesIBMWebSphere MQ）的errors目錄中。如果 WebSphere MQ 可以讀取配置信息，并且可以訪問 Default Prefix 的值，則錯誤記錄在由 Default Prefix 屬性標(biāo)識的目

15、錄的errors子目錄中。例如，如果缺省前綴為 C:Program FilesIBMWebSphere MQ，則錯誤在 C:Program FilesIBMWebSphere MQerrors 中記錄。常見問題分析 在開始詳細(xì)分析問題的原因之前，我們應(yīng)該首要考慮一下可能導(dǎo)致問題的一些較明顯的因素，或?qū)е聠栴}發(fā)生的最大可能性因素，這樣便于把分析問題的范圍限制到最小 。 有關(guān)的MQ的異常情況的發(fā)生，通常主要與三方面的因素有關(guān)，即： MQSeries本身 網(wǎng)絡(luò) 客戶的應(yīng)用 初步分析 當(dāng)出現(xiàn)問題時，可從這三方面著手分析原因，這里，列舉了一些基本問題，您可以按照此順序來查找問題的原因。 1、在此之前MQ

16、是否運行正常？ 2、從最近一次成功運行以來，是否在某些地方作過改動？ 3、在此之前，應(yīng)用是否運行成功？ 4、問題是否總在每天的某一固定時刻發(fā)生？ 初步分析（續(xù)） 如果您的系統(tǒng)曾經(jīng)運行正常，那么在出現(xiàn)問題之前，您對哪些部分做了改動，如：有的用戶可能由于網(wǎng)絡(luò)重新規(guī)劃而更改了某個主機的IP地址，則可能導(dǎo)致通道無法連通；有的用戶新設(shè)置了防火墻，則需要進(jìn)行相應(yīng)的配置，才能使MQ的通道運行正常。如果您沒有對系統(tǒng)配置做過更改，您可以分析是否運行環(huán)境發(fā)生了變化，如：是否由于業(yè)務(wù)量的加大導(dǎo)致應(yīng)用程序隊列滿了，您需要加大隊列的最大深度；是否由于連接數(shù)量的增加，導(dǎo)致無法建立新的連接，這時，您需要察看在隊列管理器配置

17、文件中，與通道相關(guān)的MaxChannels和MaxActiveChannels的配置是否足夠大。 初步分析（續(xù)） 有無錯誤信息？ 可以察看錯誤日志，得到錯誤信息 是否與MQI應(yīng)用有關(guān)，利用返回碼能否解釋原因？ 對于每一個函數(shù)調(diào)用，MQ都會返回一個Completion Code和Reason Code，通過MQI返回碼Reason Code，可以在API一層，確定錯誤原因，Reason Code代表的含義可以參考編程手冊，或者從cmqc.h頭文件中獲得。如：RC2035，代表沒有操作權(quán)限；RC2085，表示沒有該對象；RC2080，表示應(yīng)用程序給出的buffer小于消息的實際大小等 深入分析 如

18、果初步分析無法解決問題，您必須更進(jìn)一步查找原因，您可以近一步考慮如下問題： 與隊列相關(guān)的問題與隊列相關(guān)的問題 與通道相關(guān)的問題與通道相關(guān)的問題 死信隊列 配置文件與隊列相關(guān)的問題與隊列相關(guān)的問題 1) 隊列狀態(tài)是否正常？ 2）消息是否成功地放入隊列? 3) 你是否可以從隊列取出任何消息? 4）問題是否與遠(yuǎn)程隊列有關(guān)？ 1）隊列狀態(tài)是否正常 ？ 用DISPLAY QUEUE命令查看隊列的各項狀態(tài)用得到的隊列信息進(jìn)一步查看： a) 如果CURDEPTH達(dá)到MAXDEPTH，表明隊列深度已滿，新消息已不能再進(jìn)入隊列，要及時處理隊列中積存的消息；或者增大隊列的MAXDEPTH屬性。 b) 如果CURD

19、EPTH還沒有達(dá)到MAXDEPTH，再考慮以下兩種情況： 如果隊列被設(shè)置為可觸發(fā)類型的，要檢查觸發(fā)條件有沒有滿足？相關(guān)觸發(fā)進(jìn)程的定義是否正確？如果隊列不是觸發(fā)類型的，要檢查隊列是否為可共享的，是否允許PUT或GET的操作等。 2）消息是否成功地放入隊列? 如果消息沒有成功地放入隊列，您可以檢查： 隊列是否被正確定義?例如，隊列的MaxMsgLength屬性是否足夠大以容納所需大小的消息? 隊列是否被允許放入? 隊列是否已滿?這可能意味著應(yīng)用程序無法將要求的消息放入隊列。 有沒有另一個應(yīng)用程序取得了獨占隊列的權(quán)力? 3）你是否可以從隊列取出任何消息? 如果你無法從隊列中取出任何消息，檢查： 其他

20、應(yīng)用程序能否從隊列中取出消息? 有沒有另一個應(yīng)用程序取得了獨占隊列的權(quán)力? 如果你正在開發(fā)應(yīng)用程序，檢查： 你是否需要使用一個同步點? 如果使用同步點控制來放入或檢出消息，它們直到工作單元被提交前不能用于其它任務(wù)。 是否等待了足夠長的時間? 作為MQGET調(diào)用的一個選項，你可以設(shè)置等待間隔。你應(yīng)該確保等待響應(yīng)足夠長的時間。 你是否在等待一條由消息或相關(guān)標(biāo)識符（MsgId或CorrelId）標(biāo)識的特定消息? 檢查你在等待的消息的MsgId或CorrelId是否正確。成功的MQGET調(diào)用會把這些值設(shè)置為檢索到的消息的值，所以你可能要重設(shè)這些值以便成功地取出另一條消息。 您對消息是否進(jìn)行了分段處理，

21、您是否在利用MQGET讀取消息時，采用了正確的選項(MQGMO)，從而獲取消息的整體。 還要檢查一下你是否能夠從隊列中取出另一條消息。 你期望的消息有沒有被定義為持久的? 如果沒有，并且MQ重新啟動后，消息將已丟失。 4）問題是否與遠(yuǎn)程隊列有關(guān)？ 如果問題是否與遠(yuǎn)程隊列有關(guān)，則要考慮以下幾個方面： 遠(yuǎn)程隊列的定義是否正確； 檢查通道是否啟動，如果通道是可被觸發(fā)的，要檢查觸發(fā)監(jiān)視器是否運行正常； 檢查往遠(yuǎn)程隊列里發(fā)送消息的應(yīng)用程序是否運行正常； 從錯誤日志中查找信息； 與通道相關(guān)的問題與通道相關(guān)的問題 MQSeries的通道是MQ的重要組成部分，是MQ的難點和精華，它運行正常與否對MQ系統(tǒng)的正常

22、運行起著致關(guān)重要的作用，并且，在MQ的網(wǎng)絡(luò)環(huán)境中，相當(dāng)數(shù)量的異常問題與通道有關(guān)，因此，相比而言，對MQ通道的維護工作是MQ系統(tǒng)管理員系統(tǒng)管理工作的重點。下面，我們給出當(dāng)通道出現(xiàn)異常時，判斷通道狀態(tài)、分析問題原因、以及解決通道問題的途徑和基本手段。 這里先給出有關(guān)通道的幾個基本概念： 1) 通道狀態(tài) 2) 消息序列號(Message Sequence Number) 1) 通道狀態(tài) 通道狀態(tài)有binding、running、stopping、stoped、retrying等幾種類型，當(dāng)我們發(fā)出啟動通道的命令之后，通道進(jìn)入binding的狀態(tài)，若網(wǎng)絡(luò)連接暢通并且通道定義正確，它進(jìn)入正常runnin

23、g狀態(tài)；而在異常情況下，比如網(wǎng)絡(luò)連接有問題、通道定義不正確或通道兩端的消息序列號(Message Sequence Number)不匹配等，通道即進(jìn)入retrying的狀態(tài)，它會根據(jù)通道定義中short retry和long retry的次數(shù)和時間間隔依次進(jìn)行short retry和long retry，若不成功，則通道無法正常啟動。 2) 消息序列號(Message Sequence Number) 消息序列號是保證MQ消息傳輸不丟失、不復(fù)傳的一個重要機制。消息序列號由發(fā)送通道分配，是通道的一個永久屬性，每當(dāng)發(fā)送一條消息，消息序列號就加一，正常情況下，通道兩端的消息序列號或者相等或者相差為一

24、，通道才能正常啟動 。通道狀態(tài)異常時應(yīng)采取的措施： 查看網(wǎng)絡(luò)連接是否暢通，MQ的通訊是建立在系統(tǒng)網(wǎng)絡(luò)運行正常的基礎(chǔ)之上的，當(dāng)通道不通時，要首先檢查網(wǎng)絡(luò)連接是否正常?？梢允褂貌僮飨到y(tǒng)ping命令，也可以采用ftp方式，在兩個主機之間嘗試進(jìn)行數(shù)據(jù)傳輸，以判斷網(wǎng)絡(luò)是否正常。 查看通道定義是否正確通道所使用的傳輸隊列定義是否正確，通道兩端的定義是否匹配，如兩條通道最大傳輸?shù)南㈤L度，Message sequence number wrap是否一致。若不一致，要重新定義通道，可使用MQSC命令DEFINE CHANNEL命令 。 查看通道的狀態(tài) 查看操作系統(tǒng)、MQ的TCP/IP參數(shù)是否設(shè)置成功以及run

25、mqchi進(jìn)程是否處于運行狀態(tài) 查看通道的當(dāng)前消息序列號 3）查看通道狀態(tài)用以下命令來判斷通道狀態(tài)： dis chstatus(ChannelName)或dis chs(ChannelName) 其中，ChannelName代表通道的名稱，該命令支持通配符，可用dis chs(*)來查看所有通道的狀態(tài)， 當(dāng)通道無法正常啟動時，必須重新啟動通道，可使用MQ的控制命令runmqchl命令，或MQSC命令START CHANNEL來啟動通道。 注意：如果通道的接收方狀態(tài)處于STOPPED狀態(tài)，必須用start chl(ReceiverChl)來重置它的狀態(tài)，注意，這并不意味著啟動了通道，欲啟動通道，

26、必須從發(fā)送端來啟動。 如果通道處于可疑(in-doubt)狀態(tài)，則通道啟動階段的互相同步工作無法完成，也會導(dǎo)致通道無法啟動。解決方案是：用Resolve Channel命令來確定通道狀態(tài)；Resolve Channel命令帶有兩個參數(shù)：COMMIT和BACKOUT，用COMMIT參數(shù)將傳輸隊列中的消息刪除，用BACKOUT參數(shù)將傳輸隊列中的消息重新恢復(fù)。 4）查看操作系統(tǒng) 如果您的通道在網(wǎng)絡(luò)出現(xiàn)異?；?qū)Ψ疥犃泄芾砥髦貑⒑?，MQ通訊不能正?；謴?fù)，則您要檢查您的操作系統(tǒng)的keepidle的TCP/IP相關(guān)參數(shù)是否設(shè)置成功并且生效，同時您要檢查隊列管理器的屬性TCP: KeepAlive是否設(shè)置為Y

27、es，另外，您的runmqchi進(jìn)程是否處于運行狀態(tài)。 注意：上述三者共同作用，才能保證MQ通道的正?；謴?fù)，缺一不可。 5）查看通道的當(dāng)前消息序列號 用dis chstatus(ChannelName)或dis chs(ChannelName)查看通道的當(dāng)前一些屬性值，在通道的屬性值中，current sequence number代表通道當(dāng)前的消息序列號值，若消息序列號不一致，則可用MQSC命令RESET CHANNEL命令來將消息序列號重新置1。 注意：一般情況下，只有當(dāng)某一方MQ系統(tǒng)重新安裝，隊列管理器重建，或人為操作時，才會使通道的消息序列號變?yōu)? 。6）查看錯誤日志 關(guān)于MQ提供的錯

28、誤日志之前已經(jīng)作過較為詳細(xì)的介紹，錯誤日志是出現(xiàn)異常情況時，系統(tǒng)管理員查找原因時要最先考慮也最為簡潔奏效的辦法。通道錯誤日志中的錯誤信息，往往能很快解決問題。 通常從以上幾方面考慮，通道問題都能迎刃而解。 死信隊列死信隊列 如果由于某種原因，消息不能被正常發(fā)送，它會被送到死信隊列中。你可以用MQSC目錄DISPLAY QUEUE來查看死信隊列的深度，若隊列中有消息，可利用應(yīng)用程序瀏覽消息的內(nèi)容，來確定消息被放入死信隊列的原因，從而確定如何處理死信中的消息。消息有可能出現(xiàn)在本地的隊列中，也有可能出現(xiàn)在目的地的死信隊列中。若發(fā)生前一種情況，說明本地某有正確的路由途徑，可以使消息繼續(xù)下傳；若發(fā)生后一種情況，說明目的地一端所指定的目的隊列不存在。 配置文件配置文件 對于每一個隊列管理器而言，都有一個名為qm.ini的配置文件，如果該配置文件被誤刪除，會導(dǎo)致queue manager unavailable類型的錯誤。在Windows NT/2000平臺上，該配置文件以注冊表方式存在，可以使用MQ提供的圖形界面進(jìn)行修改。注意：對qm.ini和隊列管理器屬性的修改，必須在隊列管理器重新啟動之后才能生效。 數(shù)據(jù)日志數(shù)據(jù)日志 前面曾經(jīng)提到MQ的數(shù)據(jù)日志，一般情況下，中國用戶大多采用循環(huán)日志，我們建議您在估算消息容量之后，確定適當(dāng)?shù)娜罩敬笮『蛡€數(shù)。如果，在運行過程中，出現(xiàn)了日志寫滿的情