Meny Meny Framåt

Transaction & Messaging Congress 96

Problem Determination for Distributed MQSeries

Onsdag 6/11 16.45
Mark Taylor, IBM Hursley

Då problem kan uppstå av så många olika anledningar kan det vara svårt att beskriva hur man ska göra för att avhjälpa dem. Mark Taylor beskrev dock en del metoder och hjälpmedel för att kunna leta sig fram i systemet.

Error Logs
MQSeries använder sig av errorloggar för att lagra information om de fel som uppstår i MQSeries. Problemet med dessa är att det inte enbart är fel, utan ibland också information om normala händelser, tex startad/stoppad kanal!
MQSeries snurrar runt på tre errorfiler; AMQERR0[1,2,3].LOG. De ligger på lite olika ställen och vilken man ska titta i är beroende på vilken typ av fel man letar efter. De ställen där det kan finnas errorloggar är: mqm/errors, mqm/qmgrs/<QMGR>/errors samt mqm/qmgrs/@SYSTEM/errors. Dessa filer som alla existerar på MQ-servern är i vanligt textformat och kan enkelt tittas på. Även en MQ-klient skriver i errorloggar, men formatet i en sådan kan vara i binärt format på en del plattformar, och då behövs en läsare som följer med installationen.

I OS/2-serverinstallationen skapas errorfiler i FFST-format, och för att läsa dem krävs en FFST-läsare. Läsaren skickas bla med MQ-installationen, men finns också med vid installation av andra produkter.
I NT och Unix skrivs information om händelser också in i de systemunika loggarna (NT event logs och Unix syslog).

Unix Kernel Tuning
En hel del av felhanteringen i Unixmiljöerna handlar om tuning av systemparametrar. En del av dessa kan man pröva sig fram till genom att titta i errorloggarna för att se vilken typ av fel som rapporterats, och därefter modifiera systemparametrarna.
De exempel på parametrar som ges i de olika MQ-handböckerna är ibland inte tillräckliga, så IBM siktar på att publicera fler, och bättre inställningar i framtiden.

NT Security
Access till MQ-resurser i NT kontrolleras av OAM (Object Authority Manager), och det är samma modell som används i Unix. Access av MQ-kommandon kontrolleras av Windows NT, och användare måste vara medlemmar i mqm-gruppen. UserID får inte innehålla SPACE eller '#', och får inte vara mer än 12 tecken. Det gör att 'administrator' som är 13 tecken får problem! Det är något som IBM skyller på Microsofts inkompatibla delsystem!
När det gäller NT likaväl som Unix så är det att användarnamn konverteras till lowercase för att kunna användas från stordatorsystem eller AS/400. Om man inte vill att det ska vara default kan man skapa en channel message exit som inte gör någonting. Med den närvarande kommer inga UserIDs att konverteras vid ankomst till queue managern.
Det finns mer om NT Security som kan vara intressant (services mm) än vad som är beskrivet här. Det finns på extra OH-bilder hos mig, som inte Taylor pratade så mycket om.

Trace
Det finns lite olika möjligheter att tracea MQSeries verksamhet, och den som Mark Taylor gillade bäst var definitivt AIXs system, som var mycket homogent inkorporerat med det egna trace-systemet. Alla MQSeries-plattformar kan utföra trace på ett eller annat sätt. Ett råd som Taylor gav var att alltid ha så mycket tracedata påslaget som möjligt.
Tracearna skapar traceloggar på lite olika sätt, men det viktiga är egentligen att de är mycket svåra att läsa för alla utom stor kunskap om MQSeries interna struktur, så de kan ses som en möjlighet att hjälpa IBM att leta efter fel som uppstått.

Communications Problems
Det första som måste göras när man misstänker att det trasslar med kommunikationen mellan queue managers är att konfirmera att nätet är uppe och att det finns kontakt mellan de två queue managerna. Det kan gå till på lite olika sätt; tcp/ip har ping och SNA LU6.2 kan använda "aping". Om nätet fungerar går det att pinga i MQSeries också. En kanal mellan två queue managers kan pingas från den sändande änden. Det skall dock göras INNAN kanalen startats!
Namn som delas på de båda ändarna, tex kanaler, måste vara exakt likadana. Det är också viktigt att både stora och små bokstäver är samma; AChannel är inte samma som Achannel!
Om konverteringen av meddelanden inte fungerar kan det också ge problem. .
Om en kanal stod i retry-läge när en queue manager stoppades kan channel-initiatorn ha fått problem vid starten. Man måste resetta transmitkön (TRIGGER) innan en channel-initiator startas.

TCP/IP
Utöver alla de speciella fall som kunde inträffa beskrev Taylor en användbar funktion som finns i MQSeries. Om man är osäker på om en tcp/ip-port fungerade korrekt, kunde man göra en telnet på localhost och rätt port (oftast 1414). Om man fick connect fungerade porten, annars var det något problem med MQSeries och inställningen av tcp/ip. Detta fungerar dock bara om man har konfigurerat INTED att starta MQ eller startat en listener själv. Enligt Halliwell skulle kanalerna i MQSeries startas med hjälp av runmqchi, dvs en channel initiator som startar kanalerna när det behövs.
Taylor pratade om att sätta upp sk 'heart beats' som kollade om klienter gått ner, men det var överkurs, så det blev inte mycket beskrivet om just det.

SNA
SNA konfigureras olika för varje plattform så det finns support pacs som visar konfigurationer för detta (tex http://www.hursley.ibm.com/mqseries/txppacs/mc71.html.

What IBM Service might need
Vid problemrapportering