Come Together Part Ii - The secrets of mainframe island - Wie iws und ejm zusammenarbeiten

Come together Part II The Secrets of Mainframe Island - Wie IWS und EJM zusammenarbeiten Willkommen zur Präsentation The Secrets of Mainframe Island. Worum geht es hier? Es geht um die Kombination von IWS und EJM. IWS steht für "IBM Workload Scheduler" und das ist ein Software-System für die Steuerung von Jobs, vor allem auf Mainframe-Systemen. IWS ist vielen noch unter den alten Namen TWS oder OPC bekannt. EJM steht für "Enterprise Job Manager" und das ist ein Software-System von Betasystems, mit dem IWS um Funktionen für das Distributed-Scheduling und das Joblog-Management erweitert werden kann. EJM wurde ehemals Beta48 genannt. Distributed ist der von IBM geprägte Begriff für die Batch-Job-Verarbeitung auf Non-Mainframe-Systemen wie zum Beispiel AIX, Linux oder Windows. Es wird gezeigt, wie IWS und EJM bei der plattformübergreifenden Batch-Verarbeitung eingesetzt werden können. Was bisher geschah... Zunächst waren wir auf Mainframe-Island mit der Batch-Job-Verarbeitung ganz alleine. Dann wurden erste Verbindungen mit den Board-Mitteln von TWS gebaut. Die Lösung nannte sich TWS-E2E. Dieses wurde später durch die Hinzunahme von EJM erweitert. Neu sind die EJM-Funktionen für das Agentless-Scheduling, mit dem auch Jobs in der DMZ geseteurt werden können. Plattformübergreifende Batch-Job-Verarbeitung Die frühen Versionen des Scheduling-Systems IWS waren nur für die Steuerung von Jobs auf Mainframe-Systemen konzipiert. Irgendwann kamen auch Tracker für Unix-Systeme hinzu. Diese wurden mit der Version 8.1 von TWS durch Fault Tolerant Agent (FTA) ersetzt. Für die Verwendung von FTA musste ein komplexes Umfeld auf dem Mainframe betrieben werden. Dafür konnte man aber die vorhandenen Agenten von Maestro-Systemen weiterverwenden. Maestro ist ein Scheduling-System für Distributed-Scheduling, später bekannt als TWS for Distributed. In späteren TWS-Versionen kamen weitere Agenten-Typen hinzu, aber einige wesentliche Unterschiede zu EJM blieben dabei erhalten. Shadow-Jobs oder direkte Anbindung? Zur Erweiterung der Scheduling-Funktionen von IWS wurden einige Bridge-Lösungen angeboten. Diese hatten aber den Nachteil, das für jeden Distributed-Job ein Shadow-Job auf dem Mainframe laufen musste. Shadow-Jobs werden auf dem Mainframe gestartet und aus dem Job-Adressraum heraus wird die Verbindung zum Distributed-System aufgebaut. Dort fand die eigentliche Job-Ausführung statt. Ein großer Vorteil von EJM ist, dass es keine Shadow-Jobs benötigt. EJM-Jobs werden direkt aus der IWS-Workstation an das Distributed-System gesendet und Joblogs kommen direkt in Beta92 auf dem Mainframe an. Die Kommunikation erfolgt über TCP/IP und IWS-User-Schnittstellen. Das hilft dabei System-Ressourcen auf dem Mainframe zu sparen. Z.B. CPU, Memory, Service Units und JES-Initiatoren. Wir kommen zur System-Architektur Hier ein Überblick mit allen Agenten-Typen und allen Tasks, die man für IWS und EJM einsetzen kann. Das hier wird auf jeden Fall gebraucht: die IWS-Controller zur Steuerung des zentralen Schedulings, der Beta92-Lock-Manager-Master für die Verwaltung der Joblogs und auf den z/OS-System IWS-Tracker und Beta92-Sub-Systeme. Für EJM wird zusätzlih das gebraucht: Eine EJM-Task auf dem Mainframe und auf jedem angeschlossenen Server ein Beta92-EJM-Agent. Für IWS-E2E wird das gebraucht: eine zusätzliche End-to-end-Task, eine Verbindung und Einrichtung auf dem Unix-System-Service und auf Distributed-Systemen jeweils ein Scheduling-Agent vom Typ FTA und ein Beta92 OSY-Agent. Verwendet man nur EJM anstatt die IWS-Onboard-Lösung mit TWS-E2E, kann man die Tasks einsparen. Damit kann auch die DMZ erreicht werden. EJM verwendet, ähnlich wie IWS, eine zentrale Task auf dem Mainframe zur Steuerung der Jobs und des Agenten-Netzwerks. Die EJM-Starter-Task ist aber sparsamer als z.B. eine IWS-E2E-Task und EJM erfordert keinen speziellen Tagesplan für Distributed-Jobs. Die Vorteile der Task sind: Die zentrale Netzwerk-Kommunikation macht Shadow-Jobs überflüssig. Die zentrale Job-Steuerung ermöglicht Workload-Balancing. Es ist eine zentrale Administration für Systeme, Agenten, Connections und User möglich. Es kann auch zentral auf Logs von aktiven und erledigten EJM-Jobs zurückgegriffen werden. Dafür gibt es Benutzeroberflächen im TSO und im Browser (ECC). IWS-Workstations können sehr unterschiedlich mit EJM-Agenten verbunden werden. Das Einfachste wäre eine solche Single-Konfiguration. Eine IWS-Workstation ist genau mit einem EJM-Agenten verbunden. Aber meistens braucht man mehr Ausfallsicherheit und dann kommen solche Cluster-Konfigurationen in Frage. Hier sind zwei EJM-Agenten, die auf unterschiedlichen Servern laufen, mit einer IWS-Workstation verbunden. Findet ein Cluster-Schwenk statt, sendet der erste EJM-Agent ein Signal zu EJM auf dem Mainframe und die Verbindung wird umgeschaltet. Die nächsten Jobs starten dann auf dem neuen aktiven Agenten. Noch breiter ist man mit einer solchen Group-Konfiguration aufgestellt. Hier sind zum Beispiel vier EJM-Agenten mit einer IWS-Workstation verbunden. Die EJM-Agenten können unterschiedlich priorisiert sein oder (bei gleicher Priorität) werden die Jobs gleichmäßig auf alle Agenten verteilt. Es gibt aber noch weitere Konstrukte. Intelligenter läuft die Job-Verteilung mit dem EJM-Workload-Balancing. Dabei sind mehrere EJM-Agenten mit einer IWS-Workstation verbunden. Die Zuteilung der Jobs erfolgt dann nach Workload-Balancing-Kriterien. Die EJM-Agenten senden ständig ihre Auslastungsdaten zur EJM-Task, die dann den besten Agenten für den nächsten Job bestimmt. Bei Multi-STC ist die Pyramide auf den Kopf gestellt, da ein EJM-Agent mit mehreren IWS-Workstations verbunden ist. Diese laufen üblicherweise auf unterschiedlichen IWS-Systemen. Das ist eine interessante Variante für übergreifende Unternehmensfunktionen, bei denen ein Server von allen Seiten angesprochen werden muss. Ganz neu ist EJM-Agentless. Damit können auch Jobs in einer DMZ oder in Cloud-Umgebungen automatisiert werden. In diesem Beispiel ist zunächst eine Workstation konventionell mit einem EJM-Agenten verbunden. Für Agentless wäre diese Verbindung nicht unbedingt erforderlich, ist aber meist nützlich. Eine zweite Workstation ist mit einem EJM-Remote-System in der DMZ verbunden. Das Remote-System ist aber kein Agent oder aktiver Prozess, sondern die Definition einer Verbindung, über die dann Jobs gestartet werden können. Vom EJM-Agenten-Baukasten kommen wir zu den EJM-Zeitfunktionen, die anspruchsvolles Scheduling ermöglichen. Kurze Startintervalle für Jobs sind mit IWS nicht einfach zu realisieren und belasteten das System. Startintervalle kleiner als einer Minute und das Begrenzen der Job-Laufzeit sind mit IWS nicht machbar. Zeitfenster für die Job-Ausführung, exakte Startzeiten, häufige Job-Wiederholungen und ähnliches sind mit IWS nur schwierig zu realisieren. Hier einige Anforderungen an ein Scheduling-System. Zwei dieser Anforderungen heben wir besonders hervor. Ein Job soll zum Beispiel drei Stunden laufen und bei einer Zeitüberschreitung mit Return-Code 3 enden. Ein anderer Job soll alle 30 Sekunden laufen. Für IWS beides sehr schwierige Herausforderungen. Mit den EJM-Zeitfunktionen kann es allerdings sehr einfach realisiert werden. Dafür sind nur ein paar zusätzliche Zeilen im Job erforderlich. Im ersten Beispiel sollte die Laufzeit des Jobs auf drei Stunden begrenzt werden. Das sehen wir hier oben: MAXRUNTIME=180m MAXRUNTIMERC=3 Bei Überschreitung der Laufzeit endet der Job dann mit Return-Code 3. Im zweiten Beispiel sollte der Job alle 30 Sekunden gestartet werden. Das sehen wir hier unten: INTERVAL=30s Wenn sich Jobs häufig wiederholen, kann es interessant sein den Output zusammenzufassen. Dafür gibt es den Output-Pooling-Parameter. Outputs können dann stunden-, tageweise oder in anderen Paketen zusammengefasst werden. EJM-Agentless haben wir auch schon beim Agenten-Baukasten kennengelernt. Auf Distributed-Systemen mit umfangreicher Batch-Job-Verarbeitung ist ein Agent nützlich und sinnvoll. In der DMZ ist aber ein Agent und die dafür notwendige Kommunikation nicht erlaubt. Hier kann aber mit der Agentless-Technik gearbeitet werden. Von einem dafür ausgewählten Agenten außerhalb der DMZ werden dann Jobs über Secure Shell verarbeitet. Durch die Hinterlegung von Schlüsseln auf den Systemen ist eine sichere Job-Verarbeitung ohne Passwort möglich. Nur der EJM-Agent außerhalb der DMZ baut Verbindungen auf, startet Jobs, kontrolliert diese und holt die Joblogs ab. Die Definitionen für Agentless werden transparent und sicher in EJM (in den Host-Panels oder in der ECC) hinterlegt. Agentless ist auch geeignet für Jobs in Computing Clouds. Hier eine Übersicht zum Agentless. Jeder Agentless-Teilnehmer benötigt ein Key-File. Ein dedizierter EJM-Agent startet die Jobs in der DMZ per Secure Shell. Der Job-Status wird während der Job-Laufzeit überwacht. Das Joblog wird nach Job-Ende zu Beta92 auf dem Mainframe übertragen. Wir kommen zum Schluss. Aber es heißt nicht "Game Over", sondern "All together now!" Mit IWS bekommt man solide Plan- und Job-Features für alle Jobs. Mit EJM eine Erweiterung für Distributed-Systeme und ein sehr sicheres Joblog-Management. Für alle Systeme gibt es zusätzliche Browser-Oberflächen. XINFO für die Übersicht in der Batch-Verarbeitung und zur Visualisierung von umfangreichen Daten. Damit ist alles geregelt und alles gesagt. Ich bedanke mich für Ihre Aufmerksamkeit. Auf Wiedersehen!