Transaction & Messaging Congress 96

Distributed Queuing - How to Set up an MQSeries Network

Torsdag 7/11 8.45
Dr Harry Halliwell, IBM Hursley

Summering

Harry Halliwell hade på Torsdag morgon ytterligare ett mycket tekniskt föredrag. Han förutsatte en ganska hög kunskapsnivå på sina åhörare, och återigen var det svårt att hänga med i alla svängar. Han beskrev mycket snabbt och grovt hur MQSeries är uppbyggt med lokala köer, remoteköer, transmissionsköer och kanaler. Det förutsatte han dock att alla kände till, så det gick snabbt.

Transmissionsköer
Därefter beskrev han hur transmissionsköerna fungerade. Han visade ett enkelt exempel på kommunikation mellan två queue managers. På sändande sida fanns en remotekö definierad. Till den fanns också en transmissionskö skapad, som i sin tur servades av en kanal. Det enklaste är att ge transmissionskön samma namn som den mottagande queue managern. I Halliwells exempel var den sändande queue managern 'Hursley' och den mottagande 'Berlin'. MQSeries använder default en transmissionskö med det namn som remotekön angivit som mottagande queue manager. Han visade också på hur man definierade detta i MQ, med hjälp av MQSC-kommandon.

Kanaler
Intressant blev det vid beskrivningen av kanaler. Dessa kan vara av två grundtyper, sändande eller mottagande. De kan dessutom delas upp i server eller requester, vilka har mer möjligheter att starta kanaler på remotesidans queue manager. Han gick inte in på det här speciellt djupt, men de beskrivningar han gav var så pass intressanta att det går att läsa in sig i manualerna. Summan av det hela var att det går att förenkla kanalstarterna genom att låta tex sändande kanal starta upp den mottagande. Det gäller att ha en kompatibel kombination av kanalerna på båda sidor för att kunna köra!

Han visade hur man definierade kanalerna på båda sidor via MQSC, och det som var vikitigt att tänka på (som i alla andra fall i MQSeries) var att namnen på kanalerna måste stå inom citationstecken för att de ska behålla sitt namn orört. Utan citationstecken gör MQSeries om namnen till upper-case.
Halliwell beskrev sedan hur MQSeries skall definieras för att fungera i en tcp/ip-värld. MQSeries måste läggas upp i etc/services (det har jag testat men det har fungerat utan). Han gick lite snabbt igenom hur kanalerna kan startas. Det går att göra på flera sätt, det ena bättre än det andra. Ett av sätten är att definiera MQ i inetd och få tcp-lyssningen utförd därifrån. Halliwell rekommenderade dock att använda MQSeries eget system för detta. Det som är den största fördelen med att starta kanalerna inne i MQSeries i NT och OS/2 är att kanalerna (eller rättare sagt programmet som servar kanalen, dvs en sk Message Channel Agent) startas som threads! Det ger en mycket bätre lösning än att köra genom inetd, då MCAerna startas som processer. Detta gäller för sändande kanaler.
Med en channel initiator som kollar sändande transmissionsköer och startar rätt kanaler, samt mottagande kanaler som kan startas av en sändande kanal får man ett system som är ganska enkelt i uppbyggnad utan att behöva köra en massa program för de olika kanalerna.
Halliwell beskrev lite om den nya MQSeries för Windows 3.11/95 som agerar lite annorlunda, tex channel groups som kan användas till att hantera grupper av kanaler vid dial-up.

Avancerad nätrouting
Att definiera en kanal för varje koppling som en queue manager ska ha till alla andra queue managers är ofta inte effektivt. Det blir en enorm mängd av kanaldefinitioner om alla queue managers definierar kanaler till alla andra queue managers. Därför finns det stöd för routing i MQSeries. Halliwell beskrev det här lite snabbt (det också) men fick fram det viktigaste. Det som var grunden i det här var att ha transmissionsköer definierade på routande queue managers baserat på den väg meddelandet ska ta till mottagande queue manager. När den routande queue managern mottar meddelanden som ska till en annan queue manager kollar den upp en remotekö med samma namn som mottagande queue manager, och lägger dem där istället för att skickas till nästa queue manager (som ju kan vara ytterligare en routande qm i och med att remotekön kan ha en transmissionskö som skickar meddelandena till den routande queue managern). Genom det här kan man bygga vägar genom nätverket utan att definiera ett enormt spindelnät av kanaler.

Class of service
Lite snabbt gick han sedan igenom möjligheten att ha flera kanaler mellan två queue managers. Det kan användas till att skicka meddelanden med olika 'class of service', och med det menade Halliwell tex meddelanden som måste komma fram snabbt utan att ligga i en transmissionskö och vänta på service. Det kan vara en speciell lina som krypteras och som endast används till en del av meddelandena då det är tyngre behandling och långsammare kommunikation genom en sån kanal. Att kryptera, eller på annat sätt, modifiera meddelanden före och efter sändning över kanalen kan ske genom att skriva sk exits (se MQSeries Exits).

Exceptions
Svarsmeddelanden skickas tillbaka till sändaren i en sk 'reply to queue'. Halliwell pratade lite om hur man kan få exceptions som hänt i MQ att skickas tillbaka i denna svarskö. Det är ingen funktion som är påslagen normalt, men den kan enkelt slås på med en konstant vid anropet till MQ.
Ett annat sätt att upptäcka fel är att kontrollera 'event messages' som skickas till en eventkö. Ett triggerprogram kan automatiskt reagera på event i denna kö för att hantera felet och eventuellt meddela annat system eller administratör.
I MQ finns det loggar på olika nivåer. MQ har en generell loggfil, och sen har varje queue manager som är upplagd på den servern en egen loggfil.

Meddelanden som av någon anledning inte kunde levereras hamnar på den viktiga 'Dead Letter Queue'. Nyligen lanserat av IBM är en trigger monitor (runmqdlq) för DLQs som kan hantera logiska fel i meddelanden och sända om dem till den kö dom skulle ha lagt sig på, eller på en specificerad kö, om det är önskvärt. DLQs används på både sändande och mottagande sida, men på mottagande sida är det normalt endast vid meddelandekonvertering som det kan uppstå lägen där ett meddelande läggs på DLQn. Att ha en DLQ i sin queue manager är mycket viktigt. Utan den kommer kanalprocessen (MCAn) som fått problem med ett meddelande att stoppas då meddelandet inte kunde behandlas tillräckligt säkert. Med en DLQ kan kanalen lägga meddelandet dit och fortsätta att processa de övriga medddelanden som kommer genom kanalen.
En möjlighet med en DLQ för hela systemet är att låta MQs triggermonitor hantera dessa, och om alla försök misslyckas läggs de felaktiga meddelandena på en DLQ specificerad för den applikationen/kön som skulle ha tagit emot meddelandet egentligen. Det gör att det logisk går att kontrollera de applikationsunika DLQerna för att se vad de innehåller. Applikationen kan själv göra kontroller då den vet hur meddelandena ser ut internt. Det är ju inte fallet i en systemgemensam DLQ.

Channel Exits
Halliwell beskrev kort, mycket kort, hur channel exits fungerar.
Det var dock ämnet för ett helt seminarium: MQSeries Exits.

Performance
Tyvärr missade jag det seminarium som behandlade MQ Performane, och det lilla som Halliwell tog upp under det ämnet var inte mycket till hjälp. Han beskrev olika delar som kan hjälpa kanalkapaciteten, så som att öka batchstorleken på kanalerna. Detta skall som allt annat göras på båda sidor annars kommer MQ att använda det lägsta värdet, och då är ju vinsten förlorad.

Upprepade MQCONN och MQOPEN skall undvikas, vilket ju borde vara ganska fundamentalt, då upprepad öppning av kön ger en overhead.
Istället för att ligga och polla efter meddelanden i en kö, kan MQ konfigureras att trigga igång ett program så fort ett visst villkor uppstått i en kö. Det kan vara när första meddelandet kommit in, eller vid en viss nivå.
I OS/2 och Windows NT kan kanalerna startas på olika sätt, och det bästa och mest effektiva är att starta dem som threads. Det görs automatiskt när de startas från MQs channel initiator (runmqchi), men inte om de startas från tcp/ip (via amqcrsta) eller från en command line.
Det viktigaste kanske är applikationsdesignen, som enligt IBM skall vara asynkron! Halliwell tog upp det pliktskyldigt, men beskrev det inte närmre. Det fanns betydligt fler seminarium som hade visioner om detta, tex Advanced Messaging Solutions och MQSeries Three Tier is Enterprise Client/Server.

En av de frågor som jag fick svar på av Halliwell under frågestunden efter seminariet var hur MQ reagerar om servern, som kör queue managern, går sönder och byts ut. Utan att ställa om sändande queue managers till en ny aueue manager på en ny ip-adress, ställs den nya maskinen in med samma ip-adress och queue manager-namen som den föregånde pajade servern. Enligt Halliwell skulle det här inte ställa till några problem, men det finns en del grejer att tänka på. Det är främst de sk message sequence numbers, som kanalerna håller sig med för att synkronisera meddelanden mellan varann. De hjälper till att garantera att meddelanden kommit fram. En ny queue manager med nydefinierade kanaler har en resettad message sequence och båda kanalerna måste då resettas för att kunna starta kommunikation. Det viktiga är att se till att de meddelanden som finns i den trasiga servern behandlas på rätt sätt, och att det inte hamnat några meddelanden på drift. Det blir en bristfällig kontroll på det då den sändande kanalen resettas.