Im vorangegangen Artikel haben wir über einen Kunden geschrieben wie das Scheduling in einer großen Umgebung einsetzt wird. Hier erfahren Sie die Migrationsschritte: Was ist notwendig um eine Software-Migration in einem Rechenzentrum mit über 2.500 Servern und 300.000 Batch-Jobs durchzuführen.
Die Migration: die 1:1 Umstellung
Mit der Einführung von Beta 92 EJM sind nun beide Systeme für Scheduling und Archivierung integriert. Für die Bank bedeutet dies perspektivisch eine deutlich höhere Recovery-Fähigkeit.
Zunächst wird Beta 92 EJM in einem Zwischenschritt noch analog zur bisherigen Scheduling-Lösung verwendet: Pro Server-Job wird parallel auf dem Host ein identischer Job gestartet, der genauso lange läuft wie sein Pendant auf dem entfernten Server.
Nachteile dieser Lösung sind der zusätzliche Overhead durch diese „z/OS-Schattenjobs“ und die Notwendigkeit, aktive dezentrale Jobs nach einer Wartung mit IPL („Initial Program Load“) im z/OS manuell zu behandeln. Hierfür hat Beta Systems jedoch einen erweiterten Restart-Parameter bereit gestellt, der diese „Recovery“-Aktionen sehr vereinfacht.
Die Migration: Höhere Recovery-Fähigkeit
Die elegantere Beta 92 EJM-Lösung wird nun Schritt für Schritt eingesetzt. Bei dieser Lösung können alle beteiligten Komponenten jederzeit gestoppt werden oder sogar durch einen Fehler ungeplant ausfallen – in keinem Fall geht ein Job Event verloren. Wenn ein Zielserver während der Job-Ausführung einen Re-Boot erfährt, brechen die aktiven Jobs ab. TWS wird über diese Jobs von EJM mit speziellem Return Conde informiert und bis zum Abbruch angefallene JobOutputs werden durch die EJM-Recovery automatisch im Beta 92 zur Verfügung gestellt.
„Beta Systems bietet durch sein integriertes Konzept von Scheduling, Kontrolle und Archivierung eine sehr gute Lösung, die wir mittelfristig komplett realisieren werden“, erklärt ein System Specialist vom Batch Management, „der Vorteil ist eine sehr hohe Recovery-Fähigkeit unserer IT-Systeme.“ Der Mainframe-Scheduler übergibt dann Beta 92 EJM alle Aufträge und dieses startet die Jobs auf den unterschiedlichen Plattformen. Jede Aktion kann im Falle von Störungen kurzzeitig gestoppt werden und der Betriebsablauf geht anschließend verlustfrei weiter. Dies ist zum einen von der Architektur her effektiver. Außerdem ist es angesichts knapper Ressourcen völlig ausreichend, den Scheduler direkt mit dem Agent kommunizieren zu lassen, ohne eine Zwischenschicht paralleler Hostjobs.
Fast jeder Bank-Server wird mit Beta 92 EJM erreicht
Schon aus wirtschaftlichen Gründen ist es sinnvoll, Scheduling zu zentralisieren. Über den Konzern betrachtet, verbraucht die Bank wesentlich weniger Software-Ressourcen für den Betrieb und können die Aufgaben der Systementwickler besser bündeln. In Beta 92 EJM ist bei unseren Kunden derzeit ein Netzwerk von 2.500 Agenten für die unterschiedlichsten Systeme im Einsatz. Somit kann fast jeder dezentraler Server vom Host aus zentral gesteuert werden. Es kommt durchaus vor, dass das zentrale Batch Management beim Ausbau des plattformübergreifenden Job Managements mit kulturellen Widerständen zu tun hat. Denn nicht jeder Unix-Administrator, der gewohnt ist, sein System selbst im Griff zu haben, lässt „seine“ Jobs gern von externer Stelle aus steuern.
Administratoren dezentraler Systeme werden entlastet
Viele Unix-, Linux- und Windows-Administratoren (dezentral) sehen die Vorteile, sich um das Scheduling nicht mehr kümmern zu müssen. Im Kontrollraum unseres Kunden sitzen rund um die Uhr Fachkräfte vom Batch Management. Von einer riesigen elektronischen Anzeigetafel aus überwachen sie alle zentralen und dezentralen Prozesse der Banken-Gruppe und greifen bei ungeplanten Abbrüchen sofort ein, auch nachts um halb drei. Wenn der Unix-Administrator morgens seine nächtlichen Logs kontrolliert, muss er keinen Ausfall nachvollziehen und den Fehler beheben, sondern die zentralen Operatoren haben sich schon darum gekümmert. Das sind die großen Vorzüge der Anbindung dezentraler Prozesse an das zentrale Scheduling.
In diesem Zusammenhang kommt auch der Beta Web Enabler zum Einsatz. Unser Kunde hat ihn in ein Portal eingebunden in dem die Produktionssteuerung auf einen Blick erkennbar ist. Dezentralen Administratoren bietet sie damit eine komfortable Möglichkeit, den Output ihrer Jobs über eine Webmaske einzusehen – ohne dass sie sich dafür umständlich am Host anmelden müssen.
Monitoring und Auto-Update
Es werden auch seit kurzem die erweiterten Monitoring-Funktionen von Beta 92 EJM genutzt. Darüber können die Operatoren vom Mainframe aus direkt in das Logfile eines Agenten sehen und kontrollieren. Jederzeit kann EJM anzeigen, wann welcher Job gestartet und beendet wurde. Auch die Outputs noch aktiver Jobs lassen sich direkt einsehen.
Mit der neuen Software Generation Discovery sind auch Auto-Updates der Agenten möglich. Mit dessen Hilfe lassen sich zentral vom Host unterbrechungsfrei Updates auf die Server-Agenten spielen und neue Funktionen von Beta 92 EJM somit flexibler nutzen. Das bisherige Update ist zwar recht einfach. Da viele Anwender aber keinen direkten Zugang zu allen 2.500 Servern haben und ein 24-Stunden-Betrieb schwer mit Change-Prozessen zu vereinbaren ist, entsteht in der Summe doch ein recht hoher Aufwand.
Auch im Bereich Workload Balancing profitiert die Banken-Gruppe von den technischen Möglichkeiten von Beta 92 EJM. Da der Banken-IT-Dienstleister als Private-Cloud-Anbieter ist mit der Beta Systems-Lösung in der Lage ist, für eine ausgewogene Lastverteilung auf alle Servern zu sorgen und seine dezentralen Systeme hinsichtlich CPU-Auslastung, Memory und maximal erlaubter Anzahl paralleler Jobs sehr detailliert zu monitoren.