Ausarbeitung
Werbung
Blockseminar – Siegmundsburg GROßRECHNERASPEKTE Messaging Systems / MQSeries (Grundlagen) Steffen Goldau Email: [email protected] Inhaltsverzeichnis 1. Einführung 1.1. Motivation 1.2. Middleware 1.3. MQSeries-Grundlagen und Charakteristika 1.4. Anwendungsgebiete 1.5. Alternativen 3 3 5 6 7 7 2. Messaging und Queuing 2.1. Speicherkommunikation vs. Nachrichtenkommunikation 2.2. Nachrichtenkommunikation: Paketkommunikation vs. Kanalkommunikation 2.3. Grundlegende Prinzipien 9 9 3. Messages 3.1. Segmentierung 3.2. Gruppierung 3.3. Distribution Lists 3.4. Message Types 3.5. Persistenz von Messages 3.6. Message Descriptor 13 13 13 13 13 14 14 4. Queue-Manager 4.1. Queue-Manager-Cluster 4.2. Queue-Manager-Objekte 4.2.1. Queues 4.2.2. Channels 4.2.3. Prozess-Definitionen 15 16 17 17 17 18 5. Message-Queues 5.1. Local Queues 5.2. Cluster Queues 5.3. Remote Queues 5.4. Transmission Queues 5.5. Dynamic Queues 5.6. Alias Queues 19 19 19 19 20 20 20 6. Events 20 7. Zusammenfassung 21 8. Quellenverzeichnis 21 10 10 2 1. Einführung 1.1. Motivation Parallele Rechnerarchitekturen bleiben hinsichtlich der Hochverfügbarkeit und der Performance in vielen wichtigen industriellen Bereichen erste Wahl für Systemadminstratoren. Aber durch das Internet (Grid- Computing) oder durch die ständige Verbesserungen und Leistungssteigerungen der Computerhardware im Customerbereich (Cluster- Computing) werden parallele Architekturen auch in vielen Bereichen interessant, bei denen man auf Grund der geringeren finanziellen Potenz früher wohl kaum damit gerechnet hat, Parallelcomputing nutzen zu können. Allen parallelen Anwendungen, ob sie nun auf massivparallelen Architekturen, wie man sie in Großrechnern (zSeries von IBM) findet, oder auf weniger statisch verbundenen Systemen (Cluster oder gar Internet) laufen, ist das Problem gemeinsam, daß zeitgleich ablaufende Prozesse untereinander kommunizieren müssen (es wird im Folgenden nicht zwischen z.B. Prozessen und Threads unterschieden, da die Unterschiede in den Abstraktionen unerheblich für die Problematik sind). In der Praxis wird für diese Kommunikationsorganisation sogenannte Middleware eingesetzt. Man könnte argumentieren, daß es auf einer Single- CPU- Maschine aber ebenfalls verschiedene Prozesse gibt, welche ebenfalls miteinander kommunizieren möchten. Offensichtlich reichen hier Funktionen aus, die im Allgemeinen das Betriebssystem zu Verfügung stellt, um diese Organisation zu übernehemen. Mehrere Gründe sprechen aber dagegen, diese Kommunikationsfunktionen dem Betriebssystem zu überlassen. Zum einen gestaltet sich diese Kommunikation auf einer Single-CPU-Maschine weitaus einfacher als bei echt parallelen Strukturen, da sich aus der zeitlichen Reihung der Aktionen (Parallelität ist auf einer solchen Maschine ja höchstens vorgetäuscht oder die Interaktion ist vernachlässigbar – z.B. zu einem Graphikprozessor) eine Art natürliche Synchronisation ergibt. Zum anderen gibt es hier ein übergeordnetes Betriebssystem, welches es so natürlich z.B. für Cluster o.ä. nicht gibt. Großrechner dagegen haben auch ein solches Betriebssystem. Da es aber üblich ist, diese in ggf. heterogenen Umgebungen einzusetzten, hat es sich als wesentlich einfacherer herausgestellt, ein Middlewaresystem zu etablieren, welches unabhängig von der Lokalisation der Prozessoren (respektive der Prozesse) die Kommunikationsaufgabe übernehmen kann, als neue Betriebssystemfunktionen zu implementieren. Wie implizit schon vorrausgesetzt wollen wir zunächst unter „verteilt“ sowohl über ein Netzwerk verbundene Single-CPU-Maschinen (Cluster) als auch massivparallele Maschinen (Mainframes) verstehen. In der folgenden Graphik soll veranschaulicht werden, wie sich MQSeries als ein Beispiel für ein Middlewareprodukt von IBM in ein System einfügen kann. Dabei steht eine Applikation für einen Prozeß / Prozessor, der mit anderen über ein beliebiges Netzwerk verbunden sein kann. Dieses Netzwerk kann ein Ethernet, Myrinet,... (z.B. Cluster) o.ä., aber auch ein Bussystem (Mainframes) sein: 3 Applikation Applikation MQI MQI MQSeries MQSeries NETWORK Abb.1: MQSeries als Middleware Dasselbe etwas detailierter beschreibt folgende Graphik, wobei zuätzlich veranschaulicht wird, wie die Middleware aus dem verteilten System ein Single System Image simulieren kann, sodaß der Benutzer (ggf. auch der Programmierer) die Vorstellung haben kann, mit einem einzigen (relativ leistungsfähigen) Prozessor zu arbeiten. Dies kann Aufgaben, bei denen der parallele Lösungsansatz vor dem Benutzer versteckt werden soll, unter Umständen wesentlich vereinfachen. Z.B. könnte eine solche Aufgabe eine aufwendige Bildbearbeitungsfunktion sein, welche automatisch parallelisiert wird. Serial Applications Parallel Applications Serial Programming Parallel Programming Environment Environment Cluster Middleware (Single System Image) PC/Workstation PC/Workstation Comm. SW Comm. SW Net.Interface HW Net.Interface HW (HIGHSPEED) NETWORK Abb.2: Cluster 4 1.2. Middleware Als Middleware bezeichnet man also Softwarekomponenten, welche den Datenaustausch auf Applikationsebene ermöglichen. Ovum definiert Middleware als (Zitat): "Off-the-shelf connectivity software that supports distributed processing at runtime and it is used by developers to build distributed software." MQSeries ist eine solche (proprietäre) Middleware von IBM, welche auf verschiedenen Plattformen verfügbar ist, sodaß insbesondere heterogene Kommunikation ermöglicht wird. Insbesondere ermöglicht MQSeries also die Kommunikation sowohl von Prozessen / Prozessoren innerhalb eines Mainframes als auch zwischen Mainframes und anderen (heterogenen) Prozessen. Daher sollte MQSeries auch verschiedenste Plattformen unterstützen. Dies sind zum Beispiel: Host: IBM MVS/ESA- Server und Client Tandem NonStop Kernel- Server IBM VSE/ESA- Server Midrange Pyramid DC/Osx- Server und Client IBM OS/400- Server und Client Digital Open VMS VAX- Server Workstation IBM AIX- Server und Client NCR (AT&T GIS) UNIX- Server und Client Siemens Nixdorf SINIX- Server und Client Hewlett Packard HP-UX- Server und Client SunSolaris and SunOS- Server und Client Digital Unix- Client – verfügbar als SupportPac Linux Client – verfügbar als SupportPac Desktop IBM OS/2- Server und Client Microsoft Windows 2000- Server und Client Microsoft Windows (MQSeries V2.0 - 16 Bit) Microsoft Windows (MQSeries V2.1 - 32 Bit) Windows 95 (32- Bit)- Client SCO Unixware- Server SCO Unix- Server SCO Unix (L2)- Client DOS Client- verfügbar als SupportPac MacOS (OEM)- Client 5 MQSeries unterstützt zusätzlich die Kommunikation auf verschiedenen Abstraktionsebenen. Dies bedeutet, daß mittels MQSeries Programme unterschiedlicher Benutzernähe (user applications vs. system applications) miteinander kommunizieren können. Daher bezeichnet man MQSeries auch als Produktfamilie für "Cross- Network- Communication". WINTEL OS Subsystems KommunikationsProtokolle Prozessoren Sun/Solaris OS Subsystems KommunikationsProtokolle Prozessoren Abb.3: Abstraktionsebenen von MQSeries 1.3. MQSeries - Grundlagen und Charakteristika Message- Queuing ist eine Methode der Programm- zu- Programm- Kommunikation. Diese ermöglicht verbindungsloses Senden und Empfangen von Nachrichten. Das bedeutet, daß es keine dedizierten Nachrichtenkanäle gibt, welche zum Zwecke der Kommunikation offen gehalten werden müssen, sondern daß, ähnlich einem Bussystem, alle Nachrichten über einen (virtuellen) Kanal gesendet werden können. Natürlich bedürfen die Nachrichten daher gewisser Verwaltungsinformationen, die Art, Ziel oder Absender der Nachricht definieren. Diese Informationen werden im sogenannten Header der Nachricht gespeichert. Die Nachrichten werden in einer speziellen Datenstrukur (Queues) von den Programmen hinterlegt und abgefragt. Damit wird eine Art Postfachprinzip realisiert. Das Programm, welches eine Nachricht versenden will, schickt diese an das Postfach des Programms, welches die Nachricht empfangen soll. Dieses holt sich dann die Nachricht ab, sobald es Zeit dafür hat. Zum Versenden der Nachrichten verwenden die Programme MQSeries- API- Calls, welche das MQI (Message Queue Interface) implementieren, um z.B. mit einem Queue- Manager zu kommunizieren. Die Arbeit der Postboten übernimmt dabei der Queue- Manager, welcher als Run- TimeUmgebung von MQSeries zuständig für Verwaltungsaufgaben ist. Allerdings leistet der Queuemanager etwas mehr, als es gemeinhin Postboten tun. Jedes Postfach eines Empfängers hat nämlich, sofern es von einem nicht lokalen (remote) Prozeß genutzt werden soll, ein Pendant eben im Speicher des Prozesses, der dieses Postfach remote benutzen soll. Der Prozeß, der die Nachricht also senden will, sendet sie gar nicht an das Postfach des Empfängers, sondern nur an ein lokales Postfach, von dem bekannt ist, daß alle dort liegenden Nachrichten vom Queue- Manager zum eigentlichen Postfach des Empfängers übertragen werden sollen. In der Realität würde man sagen, daß alle Leute, denen man Briefe senden will, neben ihren eigenen Briefkästen in ihrem eigenen Haus noch zusätzlich einen Briefkasten im Haus des Absenders hängen haben, von dem wiederum der Postbote weiß, wohin die Briefe zu bringen sind. Analog hat der Absender natürlich neben seinem eigenen Breifkasten in seinem Haus noch einen Briefkasten im Haus derer, die ihm Briefe senden wollen. 6 Man sieht also, es gibt Empfangs- uns Sendebriefkästen. Allerdings hat ein Programm nicht nur einen einzigen Empfangsbriefkasten, sondern für jedes andere Programm, welches ihm Nachrichten senden will, einen. Sollten sich zwei miteinander kommunizierende Prozesse aber auf einem lokalen Prozessor befinden, können natürlich der Empfangsbriefkasten des einen mit dem Sendebriefkasten des anderen zusammenfallen. Dieses etwas aufwendigere Postfachprinzip kostet natürlich etwas Verwaltungsaufwand, der sich aber durch Sicherheit und Effizienz ggf. bezahlt machen kann. Insbesondere ermöglicht es asynchrone Komunikation. Dies bedeutet, daß performance-fressendes auf-einen-anderen-Prozeß-Warten soweit wie möglich vermieden wird. Außerdem ermöglicht MQSeries so relativ komplexe Kommunikationsstrukturen (one-to-one, oneto-many, many-to-many sowie Gruppenorganisation der Kommunikationsteilnehmer). 1.4. Anwendungsgebiete Die Anwendungsgebiete dieser Middleware kann man eigentlich nicht sinnvoll umreißen oder einschränken, da jegliche Aufgaben, bei denen verteilte Anwendungen miteinander kommunizieren wollen, prinzipiell für den Einsatz von z.B. MQSeries geeignet sind. Zum Beispiel im Bereich Workflowmanagement mit LotusNotes kann MQSeries seine Vorteile gut einbringen, was nicht zuletzt an der Tatsache liegt, daß sowohl LotusNotes als auch MQSeries von IBM entwickelt wurden. Das Workflowmanagement soll helfen, betriebliche Prozesse zu optimieren, indem man Aufgaben eben nicht als eigenständige Entities versteht, sondern sie als Prozesse, welche in einem größeren Kontext eingebettet sind, auffaßt. Dies kann natürlich nur gelingen, wenn sowohl die Kommunikation unter den beteiligten Mitarbeitern (egal an welchen Teilen der IT- Infrastruktur sie sitzen) als auch die Kommunikation unter den Programmen, die ggf. an der Aufgabe/Prozeß beteiligt sind, effizient und effektiv getstaltet werden können. Durch seine Vielfätigkeit bezüglich der möglichen Plattformen und durch seine Kontextunabhängigkeit resultierend aus den standartisierten API- Interfaces, kann MQSeries hier hilfreich die Kommunikationsorganisation erleichtern. IBM- Strategen haben sich für den Einsatz von MQSeries folgende Bereiche vorgestellt: - Finanzen - Herstellung - Handel & Vertrieb - Gesundheitsfürsorge - Reise- & Transportwesen Die Auflistung zeigt schon die Unmöglichkeit einer sinnvollen Abgrenzung. Aufgrund der Komplexität bzgl. z.B. der Adminstration und des finanziellen Aufwands eignen sich solche Middlewareprodukte aber nicht für den Heimanwenderbereich. 1.5.Alternativen Häufig stehen größere Unternehmen bei der Integration ihrer IT- Systeme vor der Frage, ob es für sie sinnvoller ist, eigene Middleware zu entwickeln, oder auf vorkonfektionierte Standardprodukte zurück zu greifen. Im Mainframebereich stellt sich diese Frage nicht, da IBM einerseits mit MQSeries ein universelles und ausgereiftes Produkt für seine Großrechner entwickelt hat, andererseits IBM den Großrechnermarkt absolut dominiert. 7 Daher soll an dieser Stelle kurz auf Alternativen zur Integration außerhalb des Mainframebereichs (z.B. Cluster,...) eingegangen werden. Als erstes wäre hier wohl das distributed component oriented model (DCOM) von Microsoft zu nennen, mit dem Microsoft ebenfalls den Anspruch auf Plattformunabhängigkeit erfüllen möchte, was in der Realität aber häufig scheitert. Hinter DCOM verbirgt sich ein ähnliches Prinzip wie hinter MQSeries, d.h. verschiedene Anwendungen (components) kommunizieren über deditierte Interfaces miteinander, allerdings realisiert DCOM nicht in dem Maße wie MQSeries das Postfachprinzip. Außerdem gibt es noch einige programmiersprachenspezifische Systeme, welche i.A. als Zusatzbibliotheken für die entsprechenden Compiler die Kommunikation über unterschiedliche Netzwerke erlauben. Zu nennen wäre hier z.B. die remote methode invocation (RMI) für Java, MPI (massage passing interface) für C/C++ oder high percormance fortran eben für Fortran. Im Folgenden möchte ich noch kurz auf alternative Modelle zum Message- Queuing eingehen: - RPC (remote procedure call): Dies war eine der ersten und einfachsten Lösungen für Middleware und für kleinere Systeme (nicht zu letzt weil auch finanziell atraktiver) geeignet. Typischer Vertreter ist z.B. RMI für Java. Der wichtigste Unterschied zu Messaging- Queueing ist eben das gegenseitige Aufrufen von Prozeduren und nicht das Hinterlegen von Nachrichten wie bei MQSeries. - MOM (message oriented Middleware): Bestes Beispiel ist hier auch MQSeries. Das liegt daran, daß man Messaging Queuing auch als message oriented middleware auffassen kann – Messaging Queuing also eine Teilmenge von MOM ist. Die markantesten Vorteile von MOM sind Sicherheit und Zuverlässigkeit, die aber durch Einbußen in Sachen Geschwindigkeit und Leistungsfähigkeit unter anderem durch einen erhöhten Verwaltungsaufwand erkauft werden müssen. - ORB (object request broker): Dieses Modell wurde von CORBA entwickelt. Der wichtigste Vertreter dieses Modells ist DCOM. Wie schon erwähnt, weist dieses Modell mehrere Analogien zum Messaging Queuing auf. 8 2. Messaging und Queuing 2.1. Speicherkommunikation vs. Nachrichtenkommunikation Global Memory CPU CPU Lok.Mem. Lok. Mem. Abb.4: Speicherkommunikation Das Prinzip der Speicherkommunikation basiert prinzipiell auf dem Ablegen von Daten, welche mehrere Prozessoren / Prozesse nutzen sollen, in einem gemeinsamen Speicherbereich. Die Prozesoren haben in der Regel natürlich noch eigene lokale Speicher. CPU CPU Lok.Mem. Lok.Mem. NETWORK Abb.5: Nachrichtenkommunikation Bei der Nachrichtenkommunikation nun werden Nachrichten als dedizierte Objekte über ein Netzwerk versendet. Allerdings ist hier der lokale Speicher optional, da es einen solchen z.B. in Mainframes nicht gibt. 9 2.2. Nachrichtenkommunikation: Paketkommunikation vs. Kanalkommunikation Die Paketkommunikation und Kanalkommunikation unterscheiden sich als Spezialisierungen der Nachrichtenkommunikation dahingehend, daß es bei der Kanalkommunikation einen speziellen physischen Kanal nur für die Kommunikation zweier Teilnehmer gibt (ähnlich zum Telefonnetz). Dagegen werden im Modell der Paketkommunikation Kanäle von mehreren Kommunikationsteilnehmern genutzt, d.h. auf diesen Kanälen werden Nachrichten, die dann natürlich mit bestimmten Verwaltungsinformationen versehen sein müssen, von mehreren Teilnehmenr transportiert (z.B. TCP/IP). In der Realität findet man auch Mischformen: z.B. wird für den Internetzugang einer konventionellen Anbindung zunächst eine kanalorientierte Verbindung (über die auch schon die Pakete gehen, aber eben nur die Pakete eines Nutzers) genutzt, um dann z.B. zwischen den Backbones paketorientiert vermittelt zu werden (natürlich kann die „1st Mile “ auch von mehreren Nutzern (routing) genutzt werden, die aber nach außen als ein einziger agieren). 2.3. Grundlegende Prinzipien Wie schon erwähnt ist MQSeries eine nachrichtenorientierte middleware. Man würde es als paketorientiert einordnen, obwohl es auch Kanäle für die Kommunikation zwischen QueueManager-Cluster gibt. Diese channels aber sind keine physischen Kanäle, welche nur für die Kommunikation zwischen zwei Queue- Manager- Clustern genutzt werden, sondern spezielle Objekte, welche die Kommunikation zwischen diesen beiden vereinfachen soll. Messaging bedeutet, daß Programme durch wechselseitiges Senden und Empfangen von Daten in Form von Nachrichten, insbesondere nicht durch gegenseitiges Aufrufen der Applikationen (RPC), kommunizieren (dies könnte man natürlich auch als nachrichtenorientiert bezeichnen, wir wollen aber unter Nachricht ein dediziertes Objekt mit Verwaltungsinformationen verstehen). Queuing dagegen bedeutet, daß Programme über Queues (Warteschlangen) miteinander kommunizieren, damit eine Synchronisation weitgehend überflüssig wird. Vor allem müssen Programme nicht zeitgleich ausgeführt werden. Dies ermöglicht das Senden einer Nachricht an eine Applikation, welche zu diesem Zeitpunkt noch nicht einmal aktiv sein muß. Sollte die Empfängerapplikation später gestartet werden, wird sie einfach in ihrer Empfangsqueue nachsehen, ob eine Nachricht eingegangen ist. Die Wahl geeigneter Reaktionsschemata auf bestimmte Situationen ist natürlich stark davon abhängig, in welcher Größenordnung das Granulat der Aufgabenteilung ausfällt. Nicht in jedem Fall kann man einfach darauf warten, daß ein Programm irgendwann mal wieder gestartet wird, sondern man braucht vielleicht sofort eine Antwort. Wie man das Verhalten bestimmter Akteure auf bestimmte Situationen steuern kann, wird weiter unten erläutert. Aufgrund dieses Queueing, das ja einen wesentlichen Beitrag zur Realisierung des Postfachprinzips leistet, bezeichnet IBM MQSeries auch als indirekte Programm- zu- Programm- Kommunikation. Eine Queue ist nun eine Datenstruktur, auf welcher Nachrichten gespeichert werden können. Sie realisieren die Postfächer, die schon weiter oben erwähnt wurden. Jede Queue hat einen QueueManager, der die Verwaltung der Queues übernimmt bzw. für die Nachrichten die Weiterleitung initiiert und somit quasi das Herz von MQSeries darstellt. 10 Der Queue- Manager verwaltet also die Queues und legt Nachrichten auf ihnen ab. Auf einer Queue können sowohl Applikationen als auch Queue- Manager Nachrichten ablegen. Dabei existieren Queues unabhängig von den Applikationen, die sie nutzen. Die Queues können sowohl temporär (RAM) oder persistent (Festplatte) abgespeichert werden. Man unterscheidet Queues hinsichtlich der Absicht, sie zu nutzen. Darauf wird allerdings noch weiter unten eingegangen, an dieser Stelle soll aber schon auf den Unterschied zwischen lokalen und remote Queues hingewiesen werden, da er für das weitere Verständnis essentiell ist. Queues können also lokalen oder entfernten (remote) Managern zugeordnet werden. Die lokale Queue ist dabei der Empfangbriefkasten einer Anwendung. Die remote Queue ist keine echte Queue, sondern enthält nur Eigenschaften der lokalen Queue. Sie wird im Allgemeinen von einem andern Manager verwaltet. Sie stellt, wie weiter oben schon beschrieben, den Sendebriefkasten der Applikation dar, die meiner Appliaktion etwas senden will. In diesen Sendebriefkästen / remote Queues wird die zu sendende Nachricht abgelegt und automatisch von MQSeries zu den lokalen Queues / Empfangsbriefkästen weiter geleitet. Eine Anwendung nutzt zum Senden und Empfangen einer Nachricht standardisierte MessageQueuing- Interface- Calls (MQI- Calls). Durch dieses MQI ist der Queuing- Mechanismus in vielen Programmiersprachen und Plattformen nutzbar, was eine Integration verschiedenster IT- Strukturen ermöglicht. MQSeries ermöglicht sowohl synchrones als auch asynchrones Messaging. Dabei meint man mit asynchron, daß der Sender nach Senden der Nachricht weiter arbeitet. Dies ist zwar schnell aber auch unsicherer und eignet sich nur bei recht grobgranularen Aufgabenteilungen (z.B. Primzahltetst). Mit synchron meint man dagegen, daß der Sender auf eine Antwort wartet, was langsamer aber auch sicherer ist. Diese Technik wird bei feinerem Granulat eingesetzt (z.B. sortieren). MQSeries verwirklicht eine Client-/Server- Struktur, d.h. ein Queuemanager bietet sowohl Funktionen an, welche Anfragen beantworten, als auch welche, die Anfragen stellen. Aber es gibt auch MQSeries- Applikationen, die keinen Queuemanager haben, also nur Anfragen an andere Queuemanager stellen (reine Clients). Diese sind wichtig z.B. für mobile Computing (explizit für Win95/98 realisiert, wobei MQSeries für WIN98 z.B. doch wieder einen eigenen Queuemanager hat, welcher aber nur im single user modus arbeiten kann). Ein Programmierer kann nicht die Zielanwendung sondern lediglich die Ziel- Queue bzw. den ZielQueue- Manager spezifizieren, die Ziel- Queue ist dann nat. mit einer Zielapplikation verbunden. Damit wird gewährleistet, daß die Kommunikation wirklich asynchron organisiert werden kann – ohne Queue- Manager also keine Kommunikation möglich ist (natürlich kann man die Kommunikation auch über andere Middleware bzw. Komunikationssysteme organisieren, aber dann gehen eben die Vorteile von MQSeries verloren). Eine Applikation kann nat. mit mehreren Queues verbunden sein. Die Struktur der Kommunikationswege bleibt weitestgehend dem Administrator überlassen. Insbesondere ist es für den Sender häufig belanglos, ob der Empfänger „online“ ist oder nicht, MQSeries startet ggf. die Zielapplikation (z.B. für synchrones Messaging). Wenn die Zielapplikation gerade nicht verfügbar ist, so bleibt i.A. die Message in der Queue und wird eben später bearbeitet. 11 AQ(A) EQ(B) QueueManager QueueManager EQ(A) AQ(B) Applikation A Applikation B MQI MQI Abb.6: Dedizierte Queuemanager AQ(A) =Ausgabequeue der Applikation A EQ(A) =Eingabequeue der Applikation A In dem Beispiel, welches die obige Abbildung verdeutlichen soll, hat jede Applikation ihre eigenen dedizierten Queues. Dabei ist AQ(B) die remote Queue zur lokalen Queue EQ(A). Eine Queue kann aber auch mehreren Applikationen zugeordnet sein, um die Struktur ein wenig zu vereinfachen: Abb.7: Zusammengefaßte Queuemanager AQ(A)=EQ(B) Applikation Applikation Queuemanager A B EQ(A)=AQ(B) MQI MQI Welcher Manager welche Queue verwaltet und wie die Struktur am Ende aussehen soll, ist dem Entwickler überlassen. 12 3. Messages Messages bestehen prinzipiell aus zwei Teilen, den Daten einerseits und dem Header andererseits. Ab Version MQSeries 5 kann eine Nachricht bis zu 100MB Nutzdaten enthalten. Der Header enthät z.B. die MessageID und andere Steuerattribute. 3.1. Segmentierung Messages können zerteilt werden, um Ressourcen (z.B. Puffergröße der Zielapplikation) besser nutzen zu können. Dies kann sowohl automatisch als auch nach Regeln des Programmierers geschehen. Der Empfänger kann dann entweder die ganze Nachricht oder bestimmte, ihn intressierende, Segmente abfragen, wobei die Segmente dann prinzipiell wieder eigenständige kleinere Nachrichten sind. 3.2. Gruppierung Um den Netzwerktraffic zu optimieren, können viele kleine Messages auch zu einer großen Message zusammengefaßt werden. Dabei sorgt MQSeries automatisch über Attribute im Descriptor (Erklärung siehe 3.4.) für das Beibehalten der richtigen Reihenfolge. 3.3. Distribution Lists Eine Message kann natürlich auch an mehrere Ziel- Queues gesendet werden. Wenn diese Queues vom selben Manager verwaltet werden, sendet MQSeries die Nachrichten nicht an die empfangenden Queues, sondern an den betreffenden Manager, der sie dann an die Queues verteilt, um den Netzwerktraffic zu verringern. Welche Queues zu welchen Managern gehören wird mit Hilfe einer dynamic distribution list herausgefunden, welche z.B. bei Applikationsstart neu gelesen wird. 3.4. Message Types Man unterscheidet vier wesentliche Typen von Messages hinsichtlich ihrer Funktion: - datagram message: Dies ist eine konventionelle Nachricht, welche ohne Rückmeldungsforderung einfach nur Daten transportiert. 13 - request message: Dieser Typ von messages transportiert zwar auch Daten, erfordert aber eine Rückmeldung. - reply message: Diese Nachrichten sind dann die Antwort auf request messages. - report messages: Mit Hilfe dieser Nachrichten werden Event- Information (z.B. bei Fehler oder als Bestätigung) weitergeleitet. 3.5. Persistenz von Messages Man unterscheidet Nachrichten außerdem hinsichtlich ihrer Persistenz, mit der sie übertragen werden. Persistant messages werden mit Hilfe eines besonderen Übertragungsprotokolls versendet, welches sicherstellt, daß auch im Falle eines Systemausfalls die Nachricht reproduziert und ggf. noch einmal gesendet werden kann. Dies kostet natürlich Performance, da der hier betriebene Verwaltungsaufwand nicht unerheblich ist. Für Nachrichten, die aber ihr Ziel erreichen müssen, nimmt man diesen Nachteil in Kauf. Dementsprechend gibt es auch non persistent messages, bei denen dieser erhöhte Aufwand nicht betrieben wird. Wenn solche Nachrichten ihr Ziel nach einer vorgegebenen Zeit nicht erreicht haben, werden sie einfach gelöscht. Deshalb können diese Nachrichten im Falle eines Systemabsturzes auch nicht wieder reproduziert werden (temporäre Speicherung). Solche Nachrichten verwendet man, wenn es sich einerseits nicht um sehr wichtige Übertragungsdaten handelt (z.B. unwichtige Statusmeldungen) oder wenn die Performance absoluten Vorrang hat. 3.6. Message Descriptor Jede Nachricht enthält (wie schon erwähnt) einen Verwaltungsteil (message descriptor), in dem folgende wichtige Verwaltungsinformationen gespeichert sind: - Version: - MessageID / CorrellationID: Die Versionsnummer des verwendeten MQI ist nicht unerheblich, da es durchaus vorstellbar ist, daß verschiedene Versionen eingesetzt werden und es doch zum Teil erhebliche Unterschiede gibt. Mit dem Wissen um die Verwendung verschiedner Versionen kann MQSeries dann ggf. Konvertierungsmaßnahmen durchführen. Diese ID's werden verwendet, um mögliche Antwortnachrichten zuordnen zu können. Bevor ein Programm, welches eine reply message sendet, diese Nachricht absendet, speichert es deren ID. Das empfangende Programm versieht die Antwortnachricht mit der ID der reply message. So kann der Sender nach der Antwortnachricht suchen lassen (mittels get- Fkt.) und die Antwort dann auch zuordnen. 14 - persistent / non persistent: siehe oben - Priorität: Mittels dieses Flags kann man die Reihenfolge der Bearbeitung der Nachrichten beeinflussen. - Date & Time: Zeitpunkt des Sendens - Lifetime of a message: Zusammen mit Date/Time kann nun das Verfallsdatum einer Nachricht errechnet werden. Da es keinen GarbageCollector gibt, wird der Speicher erst freigegeben, wenn nach dieser Nachricht gefragt wird (und dann die Überfälligkeit festgestellt wird). - Returnadress: MQSeries ist nach dem Client- Server- Prinzip aufgebaut, weshalb vielfältige Kombinationen der Kommunikationsstruktur (ono-to-many,...) möglich sind. Daher ist es nötig bei request messages die Adresse zu übergeben, wohin die Antwort gesendet werden soll. Nicht zu letzt ist es in diesem Feld möglich festzulegen, ob die Nachricht an eine Queue oder an einen Queuemanager gesendet werden soll. - Format: Diese Feld enthält Typinformationen der Daten (z.B. ob es noch weitere Header gibt). - Sender application and type: Hier werden Informationen über die sendende Applikation übermittelt. - report option: Dieses Flag beantwortet die Frage, ob eine Antwort erwartet wird oder nicht bzw. ob die Nachricht selber eine Antwort ist (Rückkehrcode). - Backout- Counter: Wenn eine Nachricht an mehrere Ziele gesendet wird und eine oder mehrere ihr Ziel nicht erreichen und zurückgesendet werden, kann in diesem Feld gezählt werden, wie oft eine Nachricht zurück kam (zur Fehleranalyse). - Segmentierung/ Gruppierung: siehe oben 4. Queue- Manager Der Message- Queue- Manager (MQM) ist der Kern von MQSeries und wird durch das MQSeriesRun- Time- Program implementiert. Seine Hauptaufgabe ist die Verwaltung der Queues bzw. die interne Organisation der Nachrichten. Zusätzlich stellt er einige Funktionen bereit, die den Traffic verringern bzw. die Arbeit des Programmierers vereinfachen, was nicht zuletzt durch die Bereitstellung des MQI durch den MQM geschieht. 15 Application Program A Application Program B PUT to Q1 GET from Q1 Queuemanager mit Queue Q1 Abb.8: Queuemanager Wenn eine Anwendung einer anderen eine Nachricht senden will, so muß sie lediglich "wissen" welche Queue und damit welcher MQM angesprochen werden soll. Für die Weiterleitung der Nachricht sorgen dann ggf. die MQMs; das Programm muß insbesondere nicht wissen, wo sich das Zielprogramm befindet. Die MQMs untereinander kommunizieren über sogenannte channels, wobei sie bestehende Netzwerkprotokolle (z.B. TCP/IP) nutzen können. MQSeries startet z.B. im Falle einer Nichtverfügbarkeit einer Zielapplikation selber geeignete Behandlungsroutinen. Solche Routinen können vom Adminstrator manipuliert werden. Die Aufgaben der MQM’s im Einzelnen sind: - verwalten der Message- Queues der Applikationen - liefern des MQI's - nutzen vorhandener Netzwerk- Facilities (MQM-to-MQM) - segmentiert und gruppiert ggf. - übernehmen von Aufgaben der Kommunikationskoordination (Distribution List) - liefern von Queue-Verwaltungs-Funktionen 4.1. Queue-Manager-Cluster MQMs können in Clustern zusammengeschlossen werden. Der wesentliche Unterschied zur konventionellen Verbindung zweier MQMs besteht in dem Wissen der einzelen MQM’s um Eigenschaften anderer MQM’s. Man spricht bei konventionellen Verbindungen zweier MQMs von der sogenannten partial repository, wobei jeder MQM nur Informationen über ihn interessierende Objekte kennt. 16 Dagegen spricht man bei Clusterverbindungen zweier MQMs von einer full repository. Hier enthält eine MQM Informationen über alle anderen Objekte im Cluster. Durch das Clustering werden also mehr Informationen über das MQM- System ermöglicht, welche andere MQMs mittels spezieller Clusterchannels nutzen können. Das Clustering gestattet außerdem auch mehrere Queue- Instanzen des gleichen Namens in verschiedenen MQMs zu verwenden. Dies ermöglicht eine bessere Workloadverteilung, indem spezielle Agenten die verschiedenen aber gleichnamigen Queues auf den gleichen Informationsstand bringen. Der Programmierer nutzt solche gleichnamigen Queues wie eine einzige, er braucht sich nicht um die Kommunikation zu kümmern. 4.2. Queue-Manager-Objekte Die Arbeit der MQM bezieht sich also auf Objekte, die der Administrator definiert. Es gibt folgende Objekte für den Queuemanager: - Queuemanager - Queues - Channels - Prozess- Definitionen Diese Objekte gelten für alle MQSeries- Plattformen. Dagegen gibt es auch Objekte, die nur für bestimmte Plattformen standardisiert sind und ggf. konvertiert werden müssen: - Buffer Pool - Storage Class 4.2.1. Queues Message Queues werden verwendet, um Nachrichten zu speichern und weiterzugeben. Es gibt lokale Queues, welche vom lokalen Queuemanager verwaltet werden und remote Queues, welche dagegen von Queuemanagern anderer Maschinen (Prozessoren) verwaltet werden. Den einzelnen Queuearten werde wir uns noch im Abschnitt 5. widmen. 4.2.2. Channels Ein MQSeries Channel ist kein realer, physischer Nachrichtenkanal, sondern er stellt ein virtuelles Objekt dar, welches Informationen über Kommunikationspfade enthält. Es werden zwei Arten dieser Channels unterschieden: - Message- Channel - Message- Queue- Interface (MQI)Channel 17 Ein Message Channel verbindet zwei Queue Manager über gesonderte Agenten. Dabei arbeitet er unidirektional und integriert so zwei Message Agenten und ein Kommunikationsprotokoll. Der Message Agent ist nun ein Programm, welches für die Weiterleitung der Nachrichten verantwortlich ist (mover). Ein MQI- Channel verbindet ein MQSeriesClient mit einem Message Queuemanager eines MQSeriesServers. Im Gegensatz zu Message- Channels ist ein MQI- Channel immer bidirektional. MQ Client MQI- Channels bidirektional MQ Client MQM MessageChannels unidirektional MQM Abb.9: Channel Channels können unter Umständen automatisch etabliert werden, i. A. aber werden sie vom Administrator eingerichtet. Ein Message Channel kann in zwei verschiedenen Geschwindigkeiten arbeiten, wobei die zweite Geschwindigkeit für nicht persistente Nachrichten im Falle eines Kanalfehlers verheerend ist, da diese Nachricht einerseits natürlich nicht wiederhergestellt werden kann, andererseits mit der schnelleren Übertragung die Wahrscheinlichkeit für einen Übertragungsfehler wächst. 4.2.3. Prozess-Definitionen Eine Prozessdefinition definiert eine Applikation für einen Queuemanager. Sie enthält zum Beispiel den Namen und den Pfad eines Programmes, für das eine Nachricht eintreffen kann. 18 5. Message-Queues Queues werden als Objekte definiert, die zu einem Queue Manager gehören. Daher gibt es auch hier wieder lokale und remote Queues MQSeries unterscheidet je nach Zweck versiedene Arten von Queues: - Lokale Queues - Cluster- Queues - Remote Queues - Transmission Queues - Dynamic Queues - Alias Queues 5.1. Local Queues Über diese Art von Queues wurde inzwischen schon einiges erwähnt. Daher hier nur noch einmal das Prinzip: Angenommen wir haben zwei Programme (die nicht notwendigerweise auf einer Maschine laufen müssen), welche mittels Queues kommunizieren möchten. Sie habe daher jeweils eine Ein- und Ausgangs Queue , welche alle von einem Queue- Manager verwaltet werden, zu denen sie ihre Messages senden bzw. abholen. Man spricht hier von zwei lokalen Queues. 5.2. Cluster Queues Eine Clusterqueue ist eine lokale Queue, die überall in einem Cluster bekannt ist. D.h. irgendein Queuemanager, der zu diesem Cluster gehört, kann mit ihr kommunizieren, ohne daß eine Remotedefinition etabliert werden muß. 5.3. Remote Queues Remote Queues heißen remote, da sie von einem Queuemanager verwaltet werden, der nicht auf der lokalen Maschine läuft. Die remote Queue stellt keine reale Queue dar, sondern implementiert eine Struktur, die Eigenschaften von einer Queue eines anderen Managers enthält. Sie können wie Queues eines lokalen Managers verwendet werden, d.h. die eigentliche Organisation übernimmt MQSeries. Remote Queues werden mittels transmission Queues mit der Zielqueue verbunden, die dann aber nur eine lokale Queue sein kann. (Zielqueues werden vom Administrator definiert). Eine Applikation kann nicht von einer Remote Queue Nachrichten lesen. Eine Cluster Queue braucht natürlich keine remote Definition. 19 5.4. Transmission Queues Transmission Queues sind spezielle lokale Queues. Da Transmission Queues als Zwischenschritt für die Kommunikation zweier nicht lokaler Queues verwendet werden, muß sie mit einer remote Queue verbunden sein. Wenn nun eine Message in einer Remote Queue abgelegt wird, so wird sie zunächst in der zugehörigen Transmission Queue gelagert, von wo aus sie dann gelesen und an den entsprechenden remote Queuemanager gesendet wird. Bei Managerclustern gibt es nur eine transmission Queue, welche für alle Messages verantwortlich ist, die an andere Queuemanager versendet werden. Der Benutzer (Programmierer) hat i.A. nichts mit ihnen zu tun, d.h. ihre Verwendung ist transparent. 5.5. Dynamic Queues Dynamic Queues werden automatisch erzeugt, wenn ein Programm sie benötigt. Sie werden vom Queuemanager belegt oder gelöscht und i.A. verwendet, um Zwischenergebnisse zu speichern. Es gibt zwei Arten: - temporäre Queues (enden mit Queuemanager- Restart) - permanente Queues (überleben Queuemanager- Restart) 5.6. Alias Queues Alias Queues sind keine realen Queues, sondern Definitionen, um einer realen Queue z.B. mehrere Namen zuweisen zu können. Dadurch können mehrere Programme mit der selben Queue arbeiten, indem auf diese mit verschiedenen Namen und verschiedenen Attributen zugegriffen wird. 6. Events Es gibt MQSeries-Instrumentation-Events, welche benutzt werden können, um Operationen eines Managers zu verfolgen. Events generieren spezielle Nachrichten, wenn bestimmte Bedingungen erfüllt sind. Sie lassen sich z.B. wie folgt kategorisieren: - Queuemanager- Events - Performance- Events - Channel- Events Ressourcendefinition innerhalb des Managers, d.h. eine Nachricht soll an eine nicht existierende Queue gesendet werden -> QueuemanagerEvent Ressourcendefinitionen außerhalb eines Managers, BufferOverflow z.B., wenn Channel-Instanz gestoppt wird 20 7. Zusammenfassung Middleware ist also nicht nur für Kommunikation innherhalb eines Clusters geeignet, sondern auch für die Kommunikation im Mainframebereich. Sie stellt eine Softwarekomponente für Kommunikation auf Applikationsebene dar. MQSeries ist das wichtigste Middlewareprogramm im Mainframebereich von IBM. Es gibt verschiedene Kommunikationsarten (RPC, DCE, MOM, ORB, DTPM) sowie verschiedene Modellansätze (DCOM, RMI, MPI, PVM, HPF). MQSeries ist eine Software für paketorientierte Programm-zu-Programm-Kommunikation. Es werden Nachrichten in sogenannten Message Queues abgelegt, von wo aus sie auch wieder abgeholt werden können. Diese Queues werden von Queuemanagern verwaltet. Die einzelnen Programme brauchen dabei nichts über Zielanwendung wissen, sondern nur über Zielqueue. 8. Quellenverzeichnis - Herrmann/Kebschull/Spruth: - Bulitz/Döhre: - Prof.Dr.Fey: Einführung in z/OS und OS/390 Seminararbeit Enterprise Middleware Vorlesung: “Clustercomputing“ 21
