GTUG Bad Homburg Oktober 2016 Portierung und … - MQ8.pdf · CS Software GmbH, Schiersteiner...

CS Software GmbH, Schiersteiner Strasse 31, D-65187 Wiesbaden, Germany 1

GTUG Bad Homburg Oktober 2016

Portierung und Anpassung…



MQ: Die unendliche Geschichte



Das 800 Pfund Gorilla Projekt:Was sind schon 10 Millionen Lines of Code?



MQ v8 auf NonStop kommt – und wie!

Aber wie?


Agenda

1. MQ auf NonStop: Rückblick und Ausblick

2. MQ v8: Architekturfragen

3. Der steinige Weg zur Lösung

4. Performance: Darf es etwas mehr sein?


MQ auf NonStop: Was ist MQ?

• MQ = MQSeries, WebSphere MQ, heute: IBM MQ

• Ein führendes Produkt für Messaging von IBM

• International sehr weit verbreitet

• Von Android bis z/OS

• Wenn gar nichts geht: MQ geht immer



• Persistente und nicht persistente Nachrichten

• Nachrichtengröße bis 100 MB

• … und wenn das nicht genügt, gibt es Segmente und Gruppen

• Transaktionale und nicht transaktionale Arbeitsweise

• Konzepte für Request/Reply (nicht jeder hat NonStop)

• Relativ einfach handhabbares API – Komplexität gut versteckt



• Synchrone/asynchrone Funktion

• Ab neueren Versionen: Publish/Subscribe

• MQ Cluster für vereinfachte Konfiguration

• Datenkonvertierung

• Integriertes SSL (auf NonStop Basis Open SSL)


MQ auf NonStop

• MQ schon sehr lange auf NonStop verfügbar

• Recht viele (relativ) Nutzer, vor allem strategische Kunden

• Letzte verfügbare Version 5.3

• Aktuelle Version von IBM ist 8

• Wie geht es weiter mit MQ auf NonStop?


MQ auf NonStop

• IBM hatte MQ auf NonStop schon (fast) abgekündigt

• Dann kam Protest von großen IBM Kunden

• Also beschloss IBM, v8 auf NonStop zu bringen, …

• … das aber mit Partnern zu tun, da zu wenig eigenes NonStop Knowhow vorhanden

• comForte und CS wurden als Entwicklungs- und Supportpartnerausgewählt


Architekturfragen

• MQ 5 auf NonStop sehr eigenständige Implementierung

- Prozesspaare

- Administration über Pathway

- Queues in Enscribe• MQ 8 viele Entwicklungsjahre von MQ 5 entfernt

• Wie bekommt man MQ 8 auf NonStop?


Architekturfragen

• MQ 8 auf Linux verfügbar, OSS sieht fast aus wie Linux

• Also warum nicht einen “flat port” von Linux nach OSS?

• Kernfrage: Was ist mit TMF?

• TMF Transaktionen, die konsistent MQ und NonStop Datenbankumfassen, ist zwingende Anforderung


Architekturfragen

• Linux MQ hat sein eigenes Transaktionsmodell (“eingebautesTMF”)

• MQ unterstützt heterogene XA Transaktionen als Teilnehmer

• Also: MQ auf NonStop wie auf fremder Linux Plattform, Transaktionskonsistenz über XA

• MQ führt eigenes Transaktionslog (unabhängig von TMF)

• Technisch möglich über von HP nicht freigegebene Schnittstelle(OpenTMF)


Architekturfragen

TMF Audittrail

BEGINTRANSACTION

READUPDATEX/WRITEUPDATEX

MQPUT

ENDTRANSACTION

Enscribe

MQ Log

MQ Queue

MQ

Open TMF

TMF

XA

Anwendung


Architekturfragen

• MQ Log und MQ Queue sind (nicht auditierte!) OSS Dateien

• Konstruktion passt zur MQ Arbeitsweise auf Linux (“Write Ahead Logging Queue Manager”)

• Auf dieser Architektur beruhen MQ v8 Beta 1 bis Beta 4

• Auch der “flat port” war kein Spaziergang


OSS: wie Linux, nur anders

• Linux MQ basiert auf:- Threads- Shared Memory mit Synchronisation über Prozessgrenzen- schnellem Disk I/O (wenn gepuffert)

• NonStop hat- PUT Threads, aber keine Kernel Level Threads- Shared Memory, aber nicht über CPU Grenzen- keine PUT-Thread “aware” Semaphoren- relativ langsames OSS Disk I/O

• Also muss MQ v8 auf NonStop auf einer CPU laufen


Der steinige Weg zur Lösung

• An dieser Stelle kamen cF/CS ins Boot

• Kritikpunkte an der Lösung:

- Performance: 120 Msgs/Sek vs. > 700 Msgs/Sek bei MQ 5

- Nicht auditierte Dateien bedeutet: kein Support für RDF,

Shadowbase usw.

- Keine Partitionierung möglich• Kritik wurde akzeptiert, gemeinsames Projekt gestartet


Der steinige Weg zur LösungHerausforderungen

• Tool Landschaft unzureichend

- Sourcecode Verwaltung (von Visual Source Safe GIT)

- Entwicklungsumgebung (von ETK nach Eclipse)

- Ticketingsystem (GITLab)

• Viele Qualitätsprobleme mit HP Software- PUT Library instabil (inzwischen weitestgehend in Ordnung)- diverse CPU Abstürze (bevorzugt NonStop x)- NSDEE Eclipse Debugger problematisch (ca. 20 Probleme vs. Visual Inspect)- Eclipse Debugger einzige GUI Wahl auf NonStop x und Itanium/64 Bit

• Kein Thread Support im NSDEE Debugger


Der steinige Weg zur LösungExkurs über Threads

• PUT Threads vollkommen anders als “multi threaded”

• PUT Threads erlauben “quasi Nebenläufigkeit” im Programm

• Thread Synchronisreung erforderlich

• Bei shared Memory Inter-Prozess Synchronisierung erforderlich

• Standard Linux Verfahren: Semaphoren

• NonStop hat Semaphoren – aber nicht PUT Thread kompatibel


Der steinige Weg zur LösungExkurs über Threads

• Erste MQ v8 NonStop Implementierung verwendete Sockets

• Funkioniert, ist aber sehr langsam

• Aktuelle Implementierung verwendet USEREVENTs – relativschnell

• Leider nur 31 Userevents je Prozess verfügbar – das erhöht die Anzahl notwendiger Prozesse für viele gleichzeitigeAnwendungen

• Mehr Prozesse bei diesem Design nicht gut – alle müssen in einerCPU laufen und synchronisiert werden - Overhead


Der steinige Weg zur LösungGood old Enscribe

• Queue Persistenz ab Beta 5 in auditierten Enscribe Files

• Enscribe Key Sequenced Files können 27k Records haben – gut für längere Nachrichten!

• Interprozess Kommunikation am Anfang auch sockets – langsam!

• Inzwischen auf Guardian IPC umgestellt – viel besser und TMF Transaktionen unmittelbar vererbt


Der steinige Weg zur LösungFazit zu OSS vs. Linux

• Flat Port von Linux Anwendungen ist u.U. möglich

• Die resultierende Performance ist oft unzureichend

• Integration mit TMF und Enscribe ist eine großeHerausforderung…

• … aber für eine echte NonStop Anwendung unverzichtbar!


Performance: Darf es etwas mehr sein?

Operation

Installation

Anlegen Queue Manager

Starten Queue Manager

Beenden Queue Manager

Löschen Queue Manager

NonStop I

5 m 26 s

23 s

8 s

5 s

9 s

NonStop x

3m 1 s

11 s

3 s

3 s

3 s

NonStop x SSD

58 s

4 s

1 s

2 s

2 s


Performance: Testmethode

• Alle Operationen auf eine gemeinsame Queue

• n Prozesse MQPUT, n Prozesse MQGET

• Eine Operation je TMF Transaktion

• Tuning Paramater “Guardian Capacity” definiert Anzahl Threads je Prozess (Default = 10)

• Message Größe = 1000, Einfluss wird erst bei sehr viel größerenNachrichten (10000) relevant


Zahlen, bitte

1248128 (Cap 20)12 (Cap 25)16

NonStop I

70145286525645553710666

NonStop x

1232454859601357139614101389

NonStop xDaten SSD

122245…...………1478

NonStop xAuxtrailSSD122245……………1460

NonStop xMastertrailSSD9631500150015001500150015001500


Fazit NonStop x und SSD

• NonStop x ist etwa doppelt so schnell wie Itanium – wie erwartet

• Einfluss von SSD bei Datenplatten und AUX Trails ist fast 0

• Einfluss von SSD bei Master Trail und wenigen Applikationen istenorm

• Batchartige Anwendungen bzw. Solche mit geringerGleichzeitigkeit profitieren enorm von Mastertrail auf SSD


Fragen?

Werner AlexiCS Software GmbHSchiersteiner Straße 3165187 Wiesbaden0611 890 85 [email protected]

GTUG Bad Homburg Oktober 2016 Portierung und … - MQ8.pdf · CS Software GmbH, Schiersteiner...

Documents

Transcript of GTUG Bad Homburg Oktober 2016 Portierung und … - MQ8.pdf · CS Software GmbH, Schiersteiner...