Anpassung und Erweiterung eines Web-basierten Überwachungsprogramms für Grid-Jobs. Adaption and Extension of a Web-based Monitoring Tool for Grid Jobs

Transkript

1 Anpassung und Erweiterung eines Web-basierten Überwachungsprogramms für Grid-Jobs Adaption and Extension of a Web-based Monitoring Tool for Grid Jobs von Johannes Nadenau Bachelorarbeit in Physik vorgelegt der Fakultät für Mathematik, Informatik und Naturwissenschaften der RWTH Aachen angefertigt im III. Physikalisches Institut B, RWTH Aachen bei Prof. Dr. Achim Stahl Oktober 2015

2

3 Ich versichere, dass ich die Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Aachen, den Johannes Nadenau

4 III

5 Inhaltsverzeichnis 1 Einleitung CERN und LHC Grid-Computing Tier-2/3 - Aachen Programmierumgebungen Perl MySQL Ajax Jobmon Allgemeines Anpassung JSON Beendete Jobs MySQL Erweiterung Pay-Load-Jobs Übersicht Daten aus StarterLog Andere Daten Fazit 39 A Programmcode 40 B Dateigrößen der XML-Dateien 46 IV

6 1

7 Zusammenfassung An den Experimenten am Forschungszentrum CERN in Genf werden jedes Jahr mehr als 15 PB an Daten generiert. Der größte Teil stammt vom weltweit größten Teilchenbeschleuniger, dem Large Hardron Collider (LHC). Zusätzlich laufen jeden Tag über zwei Millionen sogenannter Jobs, die Daten auswerten und Ereignisse für die Experimente simulieren und dabei wieder neue Daten produzieren. Dadurch erfordert der Betrieb des LHC leistungsfähige Rechenressourcen und große Speicherkapazitäten. Durch die Entwicklung des Worldwide LHC Computing Grid (WLCG) ist es möglich, die Daten auf Rechenzentren in der ganzen Welt, den sogenannten Grid- Zentren, zu verteilen und die dort vorhandenen Ressourcen zu verwenden. Dies führt gleichzeitig dazu, dass Wissenschaftler überall auf der Welt auf diese Daten zugreifen können. Für diese Wissenschaftler ist es von Vorteil, schon während der Laufzeit der Jobs Informationen über diese erhalten zu können. Fehler in der Programmierung können so schon früh erkannt und behoben werden. Zudem kann ein derartiges Monitoring der Jobs für die Administratoren der einzelnen Zentren ein wichtiges Diagnosewerkzeug bei Fehlern im System sein. Diese beiden Anforderungen verbindet das Programm jobmon. Auf einer Weboberfläche werden alle Informationen, die zur Fehleranalyse der Jobs notwendig sind, dargestellt. Hier ist es möglich, die Jobs nach bestimmten Eigenschaften zu filtern. Dies ist vor allem für Administratoren wichtig, um Jobs mit gleichen Fehlern untersuchen zu können. Eines dieser Zentren befindet sich an der RWTH Aachen. Nach einigen Erneuerungen der Hard- und Software war das Anzeigen der Daten durch jobmon nicht mehr möglich und jobmon deshalb nicht mehr in Verwendung. Primäres Ziel dieser Arbeit ist es, jobmon an das neue System anzupassen, um die vorherige Funktionalität wiederherzustellen. Zusätzlich sollen die Möglichkeit und der nötige Aufwand, die ausgewählten Informationen auch für die sogenannten Pay-Load-Jobs zur Verfügung zu stellen, überprüft werden. Pay-Load-Jobs sind Jobs, die innerhalb der sogenannten Pilot-Jobs laufen, wodurch nur für die Pilot-Jobs ein Monitoring zur Verfügung steht. Um auch für die Pay-Load-Jobs ein Monitoring zur Verfügung stellen zu können, müssen Quellen für die entsprechenden Daten gefunden werden. 2

8 1 Einleitung 1.1 CERN und LHC Das CERN ist die weltweit größte Forschungseinrichtung für Teilchenphysik. Es liegt in der Nähe von Genf auf der schweizerisch-französischen Grenze. Hier werden Teilchen in verschiedenen Beschleunigern beschleunigt und mit anderen Teilchen oder festen Zielen zur Kollision gebracht. Dabei entstehen neue Teilchen, die von großen Detektoren gemessen und als sogenannte Events aufgezeichnet werden, um daraus Informationen über die grundlegende Struktur des Universums [1] zu erhalten. Der größte dieser Beschleuniger ist der Large Hadron Collider (LHC), ein Ringbeschleuniger mit einer Länge von ca. 27 km. Geladene Teilchen, hauptsächlich Protonen, werden auf nahezu Lichtgeschwindigkeit beschleunigt, um dann an den Standorten der vier großen Detektoren CMS, ATLAS, ALICE und LHCb zur Kollision gebracht zu werden. Durch die hohen Impulse der Teilchen beträgt die Energie dieser Kollisionen bis zu 13 TeV [2]. Für die Zukunft sind Kollisionen mit einer Energie von 14 TeV [3] [4] geplant. 1.2 Grid-Computing Der LHC zeichnet sich nicht nur durch die Höhe der Kollisionsenergie, sondern auch durch eine sehr hohe Kollisionsrate aus. Von den Daten, die am CERN generiert werden, besteht der größte Teil aus Daten von Teilchenkollisionen im LHC. Pro Sekunde ereignen sich hier pro Experiment um die 40 Millionen Strahlkreuzungen. Die Daten dieser Kollisionen werden durch ein Triggersystem geschickt und vorsortiert. Obwohl danach nur noch ungefähr 0, 0005 % der Events übrigbleiben und gespeichert werden, ergeben sich allein 15 PB an Rohdaten [5], die jedes Jahr am CERN generiert werden. Zusätzlich müssen auch die Ergebnisse von Auswertungen und Simulationen gespeichert werden. Neben großen Speicherkapazitäten werden jedoch für den Betrieb des LHC auch leistungsfähige Rechenressourcen benötigt, die jeden Tag zwei Millionen [6] Jobs abarbeiten können. Jobs sind kleine Programme, die Daten auswerten oder Simulationen durchführen. Als Erfinder des Grid-Computings gilt Ian Foster. Von ihm stammt die folgende Definition: The sharing that we are concerned with is not primarily file exchange but rather direct access to computers, software, data, and other resources, as is required by a range of collaborative problem-solving and resource-brokering strategies emerging in industry, science, and engineering. This sharing is, necessarily, highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs. A set of individuals and/or institutions defined by such sharing rules form what we call a virtual organization. [7] 3

9 Nach dieser Definition sind nicht nur Rechenressourcen, sondern zum Beispiel auch Experimente mögliche Bestandteile eines Grids. Meistens handelt es sich jedoch um heterogene Rechencluster, die räumlich sehr weit verstreut liegen. Rechencluster sind lokale Ansammlungen ähnlicher Rechner 1. Diese werden verbunden, um rechenintensive Aufgaben erledigen zu können. Die Heterogenität bezieht sich auf die Eigenschaften der Rechencluster. Diese können sich zum Beispiel in der verwendeten Hardware, insbesondere im Hinblick auf Rechenleistung und Speicherkapazität, in der verwendeten Software, zum Beispiel dem Batch-System 2 und der Software, die auf die Speichersysteme zugreift, aber auch in der Grundstruktur des Clusters unterscheiden. Das zentrale Element eines Grids ist die sogenannte Middleware. Sie dient dem Nutzer als Schnittstelle zu den Rechenclustern und kapselt dadurch deren Heterogenität ab. So spielen die Eigenschaften des Clusters, auf dem der Job läuft, für den Besitzer des Jobs keine Rolle. Diese Struktur des Grids zeigt Abb. 1. Abbildung 1: Allgemeines Konzept Grid-Computing [8] Alle Nutzer des Grids gehören einer sogenannten Virtuellen Organisation (VO) oder auch mehreren Virtuellen Organisationen an. Jede Virtuelle Organisation ist eine Gruppe von Nutzern, die eine oder mehrere bestimme Eigenschaften haben. So existiert zum Beispiel die VO cms. Zu dieser VO gehören alle Nutzer, die am Experiment CMS beteiligt sind. Innerhalb dieser 1 Es ist jedoch durchaus möglich, dass sowohl einzelne PCs als auch ganze Rechenzentren zum gleichen Grid gehören. 2 Das Batch-System ist dafür zuständig, die Jobs an die vorhandenen Workernodes zu verteilen. 4

10 VOs existieren Untergruppen wie zum Beispiel dcms, in der sich alle deutschen Wissenschaftler befinden, die am CMS beteiligt sind. Die Mitglieder einer VO erhalten bestimmte Rollen, zum Beispiel die eines normalen Nutzers oder eines Administrators. Um die Zuordnung zu einer VO und die Rolle kontrollieren zu können, erhält jeder Nutzer ein X.509-Zertifikat 3, über das er authentifiziert werden kann. Grid-Computing bietet die Möglichkeit, ungenutzte Ressourcen zu verwenden. So gibt es viele Projekte, wie zum Beispiel [10], denen man die Rechenleistung des heimischen PCs immer dann zur Verfügung stellen kann, wenn dieser sich im Leerlauf befindet. Dies ist bei den Rechenclustern im WLCG jedoch nicht der Fall. Sie stehen ausschließlich den beteiligten VOs zur Verfügung und werden nach Möglichkeit rund um die Uhr für Berechnungen eingesetzt. Um den Wissenschaftlern, die sich überall auf der Welt befinden, die Daten der verschiedenen Experimente und die ebenfalls weltweit verteilten Rechenressourcen effektiv zur Verfügung stellen zu können, ist das WLCG aus sogenannten Tiers aufgebaut, wie Abb. 2 zeigt. Abbildung 2: Struktur des WLCG [11] 3 X.509 ist ein Standard, den diese Zertifikate einhalten [9]. 5

11 Tier-0 Das CERN Data Centre in Genf ist das Tier-0-Zentrum. Hier werden alle Rohdaten der Experimente gespeichert und den Tier-1-Zentren zur Verfügung gestellt. Am Wigner Research Centre for Physics in Budapest befindet sich ein zweiter Standort des Tier-0-Zentrums [11]. Tier-1 Es gibt 13 Tier-1-Zentren; eins davon liegt in Deutschland am Karlsruher Institut für Technologie (KIT). An den Tier-1-Zentren liegen Backups der Rohdaten des Tier-0-Zentrums. Zusätzlich werden dort auch Daten der Simulationen, die auf den Tier-2-Zentren laufen, gespeichert. Neben dem Speichern von Daten besteht eine weitere Aufgabe der Tier- 1-Zentren im Aufbereiten der Rohdaten. Dabei werden aus den Rohdaten der Experimente die Events rekonstruiert und bestimmte Events selektiert, um die späteren Auswertungen zu erleichtern [11]. Tier-2 An den Tier-2-Zentren werden die zentralen Simulationen der Ereignisse an den Experimenten durchgeführt. Zusätzlich stehen die Ressourcen den Nutzerjobs zur Verfügung, die die an den Tier-1-Zentren rekonstruierten Daten auswerten. Die Ergebnisse dieser Auswertungen werden ebenfalls an den Tier-2-Zentren gespeichert [11]. Tier-3 Die Tier-3-Zentren dienen ausschließlich den Nutzerjobs. Sie unterscheiden sich von den Tier-2-Zentren dadurch, dass dort lokale Hoheit besteht. So dürfen die Betreiber der Tier-3-Zentren selber entscheiden, welchen Nutzern bzw. welchen Jobs das Rechencluster zur Verfügung steht. Die Rechner, über die die Wissenschaftler Zugang zum WLCG erhalten, werden manchmal als Tier-4-Zentren bezeichnet. 1.3 Tier-2/3 - Aachen An der RWTH Aachen befinden sich ein Tier-2- und ein Tier-3-Zentrum. Dabei handelt es sich um ein System, dessen Ressourcen zu festgelegten Anteilen den Aufgaben des Tier-2-Zentrums und des Tier-3-Zentrums dynamisch zugeteilt werden. Dieses System befindet sich im IT-Center der RWTH Aachen, wird jedoch von den Physikalischen Instituten IB, IIIA, IIIB betrieben. Es stehen über 5200 Prozessorkerne und eine Speicherkapazität von 2 PB zum Abarbeiten der Jobs und Speichern von Daten zur Verfügung. Die Struktur des Tier-2-Zentrums in Aachen kann man in Abb. 3 sehen. 6

12 CE Site-BDII SE WN POOl WN POOL WN POOL Abbildung 3: Aufbau des Tier-Zentrums in Aachen Die Schnittstelle nach außen, also zu den anderen Elementen des Grids, besteht aus dem CE (Computing Element), dem SE (Storage Element) und dem Site-BDII. Das SE ist für das Verwalten der Daten zuständig. Möchte ein Wissenschaftler Daten speichern oder lesen, schickt er eine entsprechende Anfrage an das SE. Diese Anfragen werden vom Datenmanagementsystem dcache verarbeitet und an die sogenannten Pools, auf denen die Daten liegen bzw. abgelegt werden können, weitergeleitet. Die Jobs werden an das CE geschickt, auf dem das Batch-System Torque läuft. Dabei handelt es sich um ein Open Source Programm, das auf dem Batch-System PBS beruht. Da Torque jedoch nur wenige Optionen beim Scheduling 4 der Jobs bietet, wird dafür das Open Source Programm Maui verwendet. Benötigen die Jobs Daten, greifen sie entweder direkt auf die Pools zu oder stellen eine Anfrage an das SE. Der Site-BDII stellt alle für das Grid relevanten Informationen über die angebotenen Dienste zur Verfügung. Ein Dienst wäre zum Beispiel das Ausführen von Jobs. Zu diesem Dienst gehören Informationen, wie das verwendete Batch-System, die Nutzergruppen, die Jobs auf diesem Cluster ausführen dürfen, und die zur Verfügung stehenden Rechenressourcen. Das Grid-Zentrum in Aachen wird hauptsächlich von den Wissenschaftlern des CMS-Experiments genutzt. Ein kleiner Teil der Ressourcen wird den 4 Der Scheduler entscheidet, wann welcher Job auf welchem Workernode läuft. 7

13 Experimenten am Pierre Auger Observatory 5 und am IceCube (South Pole Neutrino Observatory) 6 zur Verfügung gestellt

14 2 Programmierumgebungen Um die Grundlagen für das nächste Kapitel zu legen, in dem das Programm jobmon erklärt wird, werden in diesem Kapitel die wichtigsten Werkzeuge, auf die der jobmon zurückgreift, erklärt. 2.1 Perl Perl ist eine Programmiersprache, die 1987 von Larry Wall entwickelt wurde. Er geriet bei der Aufgabe, Informationen aus verschieden Logdateien herauszulesen und zu Berichten zusammenzufassen, an die Grenzen von Awk 7. Um dessen Fähigkeiten nutzen zu können, ohne durch die Spezialisierung beschränkt zu werden, entwarf er Perl als eine Mischung aus verschiedenen Programmiersprachen. Deshalb kann man zum Beispiel die regulären Ausrücke aus Awk auch in Perl wiederfinden. Die Man-Page von Perl 1.0 fasst die Eigenschaften von Perl sehr gut zusammen: The language is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal). It combines (in the author s opinion, anyway) some of the best features of C, sed, awk, and sh, so people familiar with those languages should have little difficulty with it. (Language historians will also note some vestiges of csh, Pascal, and even BASIC PLUS.) Expression syntax corresponds quite closely to C expression syntax. [13] Aufgrund dieser Kombination der verschiedenen Programmiersprachen eignet Perl sich sowohl für kurze, eben mal zusammengetippte Programme als auch für langen und trotzdem gut lesbaren Programmcode. So ist Perl ein wichtiger Bestandteil von Anwendungen wie heise online 8, Slashdot 9 und Idealo 10. Weil Perl einerseits, wie andere Programmiersprachen auch, das Erstellen komplexer Programmstrukturen erlaubt 11, und andererseits ein vergleichsweise einfaches Extrahieren aus Textdateien erlaub, erweist es sich für die Programmierung von jobmon als besonders geeignet. Als Administratorenwerkzeug ist jobmon ein typisches Beispiel für die Nutzung von Perl. Für die Verbindungen zur MySQL-Datenbank und zur Ajax-Anwendung greift jobmon auch auf die effektiven Schnittstellen von Perl zu anderen Systemen zurück. 7 Awk ist eine Skriptsprache, die darauf spezialisiert ist, Textdateien auszuwerten und zu verändern. So sind Aufgaben wie das Extrahieren von Zeilen, die mit einer bestimmten Zeichenfolge beginnen, oder das Verändern dieser Zeilen mit Awk leicht zu bewerkstelligen [12] jobmon besteht aus über 4000 Zeilen Code. 9

15 2.2 MySQL MySQL ist ein relationales Datenbanksystem. Eine relationale Datenbank kann man sich vereinfacht als eine Sammlung von Tabellen vorstellen, in denen die Daten abgespeichert werden. Dabei entspricht jede Zeile einer Tabelle einem Datensatz. Die Tabellen enthalten für eine Reihe von Attributen diese entsprechen den Spalten bestimmte Attributwerte, aus denen sich die Datensätze letztlich zusammensetzen. Die Tabellen können zusätzlich noch in Beziehung gesetzt werden, um bestimmte Sachverhalte darzustellen entwarf IBM das erste quasirelationale Datenbanksystem, das System R. Um die Daten im System R manipulieren zu können, wurde die domänenspezifische Sprache SEQUEL (Structured English Query Language), später aufgrund von Namensrechten als SQL bezeichnet, entwickelt. Diese wird auch zur Manipulation von MySQL-Datenbanken verwendet. [14, 15] benötigte David Hughes für Minerva, ein System für die Netzwerkadministration, ein Datenbanksystem, um Konfigurationen und andere Daten speichern zu können. Da es keine preisgünstigen oder freien Datenbanksysteme für SQL gab, entwarf er msql (Mini SQL). [16] 1997 wurde dann MyS- QL 3.1 veröffentlicht. Zunächst war es hauptsächlich ein Klon von msql; der Funktionsumfang wurde aber regelmäßig erweitert. Die Versionsnummer wurde mit Rücksicht auf die lange Geschichte des Kerns von MySQL gewählt. [17] MySQL [...] ist nicht besonders anspruchsvoll, was seine Arbeitsumgebung angeht [aber dennoch] äußerst vielseitig und flexibel [18]. Da MySQL in C und C++ geschrieben ist, ist es auf fast allen Plattformen verfügbar und besitzt die Fähigkeiten, die Daten schnell und effizient zu speichern und weiterzugeben. Auch die Schnittstellen zu den meisten Programmiersprachen dürften ein Grund für die weite Verbreitung von MySQL und die Verwendung für den jobmon sein. 2.3 Ajax Die Webansicht des jobmon ist eine Ajax-Anwendung. Die Abkürzung Ajax steht für Asynchronous JavaScript and XML. Es handelt sich dabei um ein Zusammenspiel mehrerer Technologien, darunter HTML, JavaScript, XML und DOM. Bei klassischen Web-Anwendungen stellt der Webbrowser jedes Mal, wenn er eine neue Information benötigt, eine Anfrage an den Webserver. Solange die Antwort auf diese Anfrage nicht erfolgt ist, kann der Benutzer die Anwendung nicht benutzen, da jede Antwort aus einer komplett neuen Seite besteht. Bei Ajax steht zwischen der Anwendung und dem Server noch eine Ajax- Engine, die meistens in JavaScript geschrieben ist und die Anwendung be- 10

16 treibt. Werden jetzt neue Informationen vom Server benötigt, stellt die Ajax-Engine die entsprechende Anfrage an den Webserver. Gleichzeitig sorgt sie dafür, dass der Nutzer die Seite direkt, also asynchron zur Webserveranfrage, weiter benutzen kann. So sind Funktionen, wie zum Beispiel das Navigieren auf einer Seite, auch dann weiter möglich, wenn die Antwort vom Webserver noch nicht angekommen ist. Kommt dann die Antwort, braucht nicht die ganze Seite neu geladen zu werden, sondern es werden nur Teile der Seite erneuert. Damit bietet Ajax gegenüber klassischen Web-Anwendungen den Vorteil, dass der Nutzer weniger Wartezeit hat. Auch sind weniger Anfragen an den Server notwendig, da vieles, zum Beispiel die Validierung von Daten, schon von der Ajax-Engine erledigt wird. [19] Den Unterschied zur klassischen Web-Anwendung verdeutlicht auch Abb. 4. Abbildung 4: Unterschied zwischen klassischer Web-Anwendung und Ajax- Anwendung [19] 11

17 3 Jobmon 3.1 Allgemeines Ziel von jobmon ist es, ein Quasiechtzeit-Monitoring 12 der auf dem Grid laufenden Jobs zur Verfügung zu stellen. Werden Fehler in der Programmierung der Jobs schon während deren Laufzeit gefunden, kann dies einen Beitrag zur effizienten Nutzung der Ressourcen und zur Stabilisierung des Systems leisten. Vor allem lange laufende Jobs 13 mit Fehlverhalten belegen unnötig Ressourcen, da sie nicht die benötigten Ergebnisse produzieren. Das frühe Erkennen dieser fehlerhaften Jobs ermöglicht es, die Ressourcen für andere Jobs freizugeben, und kann den Besitzern der Jobs Wartezeit ersparen. Zusätzlich soll jobmon den Administratoren der Zentren als Diagnosewerkzeug dienen. Über die ausführlichen Informationen, die der jobmon über die Jobs liefert, können Rückschlüsse auf das System gemacht und damit Fehler, insbesondere Ausfälle von Rechnern, erkannt und behoben werden. Diese Informationen sollen auf einer Weboberfläche dargestellt werden, die dem look-and-feel [20] einer Desktop-Anwendung entspricht. Diese Weboberfläche zeigt Abb. 5. Abbildung 5: Weboberfläche von jobmon 12 Die Daten werden standardmäßig alle 10 Minuten auf den neusten Stand gebracht. 13 Viele der Jobs laufen viele Stunden bis mehrere Tage. 12

18 Das Grundsystem wurde von Subir Sarkar (INFN-Pisa) entwickelt. Einige Plug-ins, insbesondere die Anpassungen an verschiedene Batch-Systeme, stammen von Catalin Dumitrescu (USCMS/FNAL), Andreas Nowack (RW- TH Aachen) und Sanjay Padhi (USCD). [20] Das Programm jobmon besteht aus drei Teilen, nämlich den Sensoren, die sowohl auf dem Computing Element als auch auf den Workernodes die Informationen zusammenstellen, der Datenbank, die mit diesen Informationen gefüllt wird, und der Weboberfläche, von der die Daten aufbereitet und dargestellt werden. Diesen Aufbau zeigt Abb. 6. Weboberfläche (AJAX) WebService Datenbank (MySQL) JobSensor NodeSensor CE WN Abbildung 6: Aufbau des Programms jobmon Die Sensoren und der WebService, der die Daten aus der Datenbank an die Weboberfläche weitergibt, sind in Perl programmiert. Der Aufbau von jobmon und die Möglichkeit von Perl, Schnittstellen ohne großen Aufwand an unterschiedliche Systeme anpassen zu können, ermöglichen es bei Bedarf, die einzelnen Teile von jobmon zu verändern oder auszutauschen, ohne den gesamten Jobmonitor umprogrammieren zu müssen. So wäre es zum Beispiel möglich, eine eigene Webseite zu schreiben, die die Daten aus der Datenbank abfragt, oder auch eine Alternative zu MySQL zu verwenden. Eine besondere Rolle spielt dies für die Batch-Systeme; jobmon unterstützt mittlerweile Condor, LSF, Lustre und PBS. Wird ein anderes Batchsystem verwendet, genügt es, die Sensoren anzupassen. Die Datenbank und die Weboberfläche können ohne Veränderungen verwendet werden. Die Datenbank Die Datenbank ist eine MySQL-Datenbank, die aus drei Tabellen besteht. In jobinfo summary werden die Daten gespeichert, die auf dem CE gesammelt werden, in wninfo die Daten, die auf den Workernodes gesammelt werden, und jobinfo timeseries enthält die Daten, die notwendig sind, um die Graphen der CPU- und Arbeitsspeicherauslastung zu erstellen. Die Tabellen 1 3 enthalten Erläuterungen zu den einzelnen Spalten der Datenbank. 13

19 Tabelle 1: Spalten der Tabelle jobinfo summary Spalte Bezeichnung Erläuterung (Weboberfläche) jid Local JobID Auf dem lokalen Cluster eindeutige (fortlaufende) Nummer user Local User (ggf. virtuelle) Person, die den Job ans Grid geschickt hat usergroup In Klammer bei Local VO des Users User queue Queue Warteschlange, in der der Job wartet oder gewartet hat qtime Submitted at Zeitpunk, an dem der Job ans Batch- System geschickt wurde start Started at Zeitpunkt, an dem der Job gestartet wurde end Finished at Zeitpunkt, an dem der Job beendet wurde status Status mögliche Werte: laufend, beendet, angehalten, in der Warteschlange und unbekannt cputime CPU Time Zeit, in der der Prozessor arbeitet walltime Wall Time Zeitdifferenz zwischen Start- und Endzeit mem RAM-Belegung vmem virtuelle RAM-Belegung diskusage durch den Job belegter lokaler Festplattenspeicher exec - host Host Workernode, auf dem der Job läuft oder gelaufen ist ex st Exit-Status Status beim Beenden des Jobs ceid CE ID Grid-weite Identifikation des CE subject Benutzername (aus dem Zertifikat) grid id Grid JobID Gridweite eindeutige Identifikation rb verwendeter Ressource Broker timeleft Gültigkeitsdauer des Zertifikats role Role Rolle des Users in seiner VO statusbit kann fürs schnelle Filtern der Jobs verwendet werden rank Standpunkt des Jobs in der Warteschlange priority Priorität des Jobs 14

20 Spalte jid timestamp mem vmem cpuload cpufrac diskusage Tabelle 2: Spalten der Tabelle jobinfo timeseries Erläuterung Auf dem lokalen Cluster eindeutige (durchlaufende) Nummer Zeitpunkte, an denen gemessen wurde Messwerte des Speichers Messwerte des virtuellen Speichers Messwerte der absoluten CPU-Auslastung Messwerte der relativen CPU-Auslastung durch den Job belegter Festplattenspeicher Tabelle 3: Spalten der Tabelle wninfo Spalte Erläuterung type Dateiformat des Eintrags data name Name der Datei, aus der der NodeSensor den Eintrag data ausgelesen hat size Dateigröße der Datei, aus der der NodeSensor den Eintrag data ausgelesen hat data zusätzliche Daten (vgl. Tab. 4) timestamp Zeitpunkt, an dem diese Datei das letzte Mal ausgelesen wurde Die Spalte data in der Tabelle wninfo enhält die Informationen, die über Reiter (vgl. Abb. 7), die sich auf der Weboberfläche rechts oben befinden, abgerufen werden können. Die Tab. 4 enthält kurze Erläuterungen zu den einzelnen Reitern. Abbildung 7: Reiter zum Anzeigen der Daten aus wninfo 15

21 Tabelle 4: Erläuterungen zu den Reitern auf der Weboberfläche Bezeichnung Erläuterung auf Weboberfläche Job ps Prozessliste des Jobs WN top Prozessliste des Workernodes, auf der Job läuft Work Dir Ordner, in dem der aktuelle Prozess läuft Job Dir Ordner, in dem der Job gestartet wurde Job Output Ausgaben des Jobs Job Error Fehlermeldungen des Jobs Im folgenden werden die Daten eines Jobs, die in der Tabelle jobinfo summary liegen, mit Jobsummary, die Daten aus wninfo mit WN-Info und die Daten aus jobinfo timeseries mit Timeseries bezeichnet. Die Weboberfläche Die drei Datenbanktabellen lassen sich auf der rechten Seite der Weboberfläche (vgl. Abb. 5) wiederfinden. Die tabellarisch dargestellten Informationen sind die Jobsummary des Jobs; die Timeseries werden in die Graphen umgewandelt und auf die WN-Info kann man über die oben erwähnten Reiter zugreifen. Auf der linken Seite befindet sich die Jobliste, die all die Jobs enthält, über die genauere Informationen abgefragt werden können. Beim Aufrufen der Weboberfläche 14 muss der Anwender sich über das Grid-Zertifikat (vgl. Kap. 1.2) authentifizieren. Ausgehend von diesem Zertifikat wird dann die Jobliste erstellt. Den Administratoren eines Clusters werden alle Jobs angezeigt; Administratoren einer VO dürfen alle Jobs der VO sehen, normale Nutzer dürfen nur ihre eigenen Jobs sehen

22 Abbildung 8: Linke Seite der Weboberfläche mit Jobliste Wie in Abb. 8 zu sehen ist, kann die Jobliste weiter gefiltert werden. Standardmäßig werden alle laufenden Jobs angezeigt. Es ist ebenfalls möglich, Jobs mit einem anderen Status oder auch generell anderen Eigenschaften, wie der CPU-Auslastung oder der Bezeichnung des Workernodes, auf dem sie laufen, anzeigen zu lassen. Über den Jobinformationen befinden sich die oben erwähnten Reiter, über die die WN-Info des Jobs abgefragt werden kann. Unten rechts ist ein Bereich, in dem einige Konfigurationen der Weboberfläche möglich sind. Gibt es beim Laden von Daten Probleme, tauchen hier auch Fehlermeldungen auf (vgl. Abb. 9). 17

23 Abbildung 9: Fehlermeldung auf der Weboberfläche (vgl. Kap ) WebService Die Weboberfläche ist eine Ajax-Anwendung (vgl. Kap. 2.3). Benötigt die Ajax-Engine neue Daten aus der Datenbank, werden diese vom WebService geliefert. Den Aufbau des WebService zeigt Abb. 10. Weboberfläche Monitor.cgi (Shell-Skript) Monitor.pl (Perl-Programm) Monitor.pm (Modul von Monitor.pl) MonitorCore.pm (Modul von Monitor.pl) Abbildung 10: Aufbau des WebService Benötigt die Weboberfläche Daten, die die Ajax-Engine nicht zur Verfügung stellen kann, wendet sie sich mit einem entsprechenden Befehl an das Shell- Skript Monitor.cgi. Dieser Befehl wird auch in der Logdatei ssl access log gespeichert und könnte zum Beispiel folgendermaßen aussehen: /cgi-bin/jobmon/rwth-aachen/monitor.cgi?jid= &command= summary& = Hier benötigt die Ajax-Engine die Jobsummary für den Job mit der Job-ID 18

24 Die Zahl am Ende ist der Zeitstempel des Befehls 15. Das Programm Monitor.cgi sorgt dann dafür, dass das Perl-Programm Monitor.pl ausgeführt wird, indem es Perl startet und diesem Monitor.pl zum Ausführen vorlegt. Von Monitor.pl wird der Befehl an das Modul Monitor weitergegeben. Dieses übersetzt den Befehl in die entsprechende Methode aus dem Modul MonitorCore und ruft diese auf. Im vorliegenden Fall ist dies die Methode sendjobinfo. Dieses holt die gesuchten Daten aus der Datenbank und gibt sie an MonitorCore weiter. Über den Weg, auf dem der Befehl gekommen ist, gehen die Daten dann zurück an die Ajax-Engine und können schließlich vom Nutzer auf der Weboberfläche betrachtet werden. Die Sensoren Wie in Abb. 6 zu sehen ist, hat jobmon zwei Sensoren, zum einen den JobSensor, der auf dem Computing Element läuft und die Tabellen jobinfo summary und jobinfo timeseries füllt, zum anderen den NodeSensor, der auf den Workernodes läuft und die Tabelle wnfino füllt. In Abb. 11 ist ein vereinfachter Aufbau des NodeSensor zu sehen. Um ein möglichst gutes Verständnis zu ermöglichen, sind nur die wichtigste Module und die wichtigsten Verbindungen zwischen diesen Modulen dargestellt. Gleiches gilt für das Schaubild, das den JobSensor darstellt (vlg. Abb. 12). nodesensor daemon.pl ConfigReader NodeSensor ObjectFactory NodeInfo DBHandle PBS::NodeInfo Abbildung 11: Aufbau des NodeSensor Das eigentliche Programm ist nodesensor daemon.pl. Ist es einmal gestartet, läuft es in Endlosschleife, wobei zwischen den einzelnen Schleifendurchgängen eine Pausenzeit eingelegt wird, so dass standardmäßig alle 10 min eine neue Datenabfrage beginnt. In jedem Durchgang werden einige Konfigurationen abgefragt und das Modul NodeSensor aufgerufen. Die Konfigurationen, die 15 Um Zeitpunkte in eine ganze Zahl umzuwandeln, werden häufig (und auch hier) die Sekunden seit dem 01. Januar :00:00 GMT, dem offiziellen Geburtstag von UNIX, berechnet. 19

25 der ConfigReader zur Verfügung stellt, umfassen einige Einstellungen zum System vor Ort, wie das verwendete Batch-System, die Ordner, in denen sich die einzelnen Programmteile von jobmon und die Zugangsdaten für die Datenbank befinden, weiterhin auch persönliche Einstellungen wie die Zeitintervalle, die zwischen den einzelnen Durchgängen der Sensoren liegen; auch das Logging-Verhalten, also ob und wie viel protokolliert wird, kann hier eingestellt werden. Der NodeSensor ist für das Sammeln der Daten zuständig; von ihm werden die Module ObjectFactory, NodeInfo und DBHandle aufgerufen. Für jedes unterstütze Batch-System steht eine eigene Sammlung an Modulen zur Verfügung. Das Modul ObjectFactory ruft diese Batch-Systemspezifischen Module entsprechend dem auf dem System laufenden Batch- System auf. Wie oben beschrieben beruht das in Aachen verwendete Batch- System Torque auf PBS, wodurch es möglich ist, die PBS-Module von jobmon zu verwenden. Von hier wird der NodeSensor mit der Liste der aktuell auf dem Workernode laufenden Jobs versorgt, die dann an NodeInfo übergeben wird, um die Daten für die Jobs aus der Liste zusammenzustellen. DBHandle stellt die Verbindung zur Datenbank her, über die die gesammelten Daten dann an die Datenbank wiedergegeben werden. jobsensor daemon.pl ConfigReader JobSensor DBHandle JobStatus GridInfo ObjectFactory GridInfoCore PBS::JobList Abbildung 12: Aufbau des JobSensor Wie Abb. 12 zeigt, ist die Struktur des JobSensor sehr ähnlich der Struktur des NodeSensor. Auch hier werden wieder die Konfigurationen durch den ConfigReader und die Verbindung zur Datenbank mit Hilfe des Moduls DBHandle zur Verfügung gestellt. Auch läuft das eigentliche Programm, jobsensor daemon.pl, wieder in Endlosschleife und ruft den eigentlichen Datensammler JobStatus in jedem Schleifendurchgang auf. Während beim No- 20

26 desensor nur die Liste der Jobs vom Batch-System abgefragt wird, werden beim JobSensor auch gleichzeitig die Daten, die für das Laufen der Jobs interessant sind, wie CPU- und Speicherverbrauch, Startzeit und Workernode, auf dem der Job läuft, abgerufen. Die für das Grid interessanten Daten, wie der Eigentümer des Jobs, dessen VO und die Grididentifikation des Jobs, werden vom Modul GridInfo abgefragt. Die gesammelten Daten übergibt JobStatus an den JobSensor, der sie dann an die Datenbank weiterleitet. 3.2 Anpassung Das Programm jobmon war bis vor ca. vier Jahren voll funktionstüchtig. Nach einem Hardware-Upgrade des Tier-2-Zentrums in Aachen konnten nicht mehr alle Daten angezeigt werden. Nach einem späteren Software- Update blieb die Weboberfläche komplett leer, so dass jobmon am Tier-2- Zentrum in Aachen nicht mehr verwendet werden konnte. Deshalb war es notwendig, vor Beginn der Erweiterungen die Ursachen für die Funktionsprobleme zu finden und diese zu beheben. Die Fehlersuche geschah zu einem großen Teil durch das Ausgeben verschiedener Variablen 16. Dadurch wurde es möglich, das Geschehen im Programm besser zu verstehen und den Ursprung fehlerhafter Variabeln finden zu können. Ein besonders wichtiges Hilfsmittel war dafür die Perl-Funktion Dumper() aus dem Paket Data. Hiermit kann der Inhalt von Variablen ausgegeben werden. Dabei spielt es keine Rolle, ob es sich um einen Wert, eine Liste oder einen Hash 17 handelt. Ist die Variable die Referenz zu einer anderen Variablen, wird der Inhalt der referenzierten Variable ausgegeben. In Abb. 13 sieht man einen Auszug aus der Ausgabe des Befehls Dumper($conf), wobei $conf eine Referenz auf den Hash enthält, der wiederum alle Konfigurationen enthält. 16 sogenanntes printf-debugging 17 In Perl ist ein Hash eine Liste, in der jedes Element aus einer Kombination aus einem Schlüssel und einem Wert für diesen Schlüssel besteht. Der Wert kann dann über diesen Schlüssel abgerufen werden. 21

27 $VAR1 = { verbose =>0, query cache =>{ file => /tmp/qstat f.list, lifetime =>180 }, site ce =>{ master => grid-ce, list =>[ grid-ce ] }, acctdir => /var/spool/pbs/server priv/accounting, lrms version => 2.5, domain => physik.rwth-aachen.de, }; Abbildung 13: Auszug aus der Ausgabe von Dumper($conf) in dem Modul ConfigReader Die folgenden Beschreibungen sollen nur die wichtigsten Eckpunkte des Erkenntnisgewinns enthalten, um ein Verständnis für die Fehler und deren Auswirkungen herzustellen. Sie entsprechen nicht genau dem Vorgehen beim Debuggen. Insbesondere sind nur wenige der Dumper-Ausgaben enthalten, da diese zwar den Großteil der Arbeit ausgemacht und auch die meisten Informationen gebracht haben 18, jedoch nur in wenigen Fällen für das Verständnis des Problems notwendig sind JSON JSON steht für JavaScript Object Notation. Dabei handelt es sich um einen leicht lesbaren Standard für Textdokumente, der dazu dient, Informationen zwischen unterschiedlichen Anwendungen zu übermitteln. Das Programm jobmon verwendet diesen Standard, um die Daten, die der WebService zusammenstellt, an die AJAX-Engine weiterzugeben. Zunächst wurden auf der Weboberfläche keine Daten angezeigt, sondern nur die folgende Fehlermeldung: filljobidlistjson: Error detail: response is null Die Logdatei des WebService, jobmoncgi.log, enthielt die Fehlermeldung: JSON Problem likely!!, Usage: JSON::XS::new(klass) at /opt/jobmon/lib/webservice/monitorcore.pm line Für das Debuggen des JSON-Fehlers (vgl. Kap wurden mehrere Wochen lang Variablen ausgegeben. Das Lösen des Problems dauerte dann nur wenige Minuten. 22

28 Damit ließ sich eingrenzen, dass es sich um ein Problem mit JSON handelte und auch, wo der entsprechende Fehler im Programmcode ungefähr zu finden ist. Die entsprechenden Zeilen lauten: eval { my $json = new JSON(pretty => 1, delimiter => 1, skipinvalid => 1); $jsval = ($json->can( encode ))? $json->encode({ jids => $jidlist }) : $json->objtojson({ jids => $jidlist }); }; $@ and print STDERR qq JSON Problem likely!!, $@\n ; Zunächst wird ein Objekt der Klasse JSON mit dem Namen $json erstellt; dann wird überprüft, ob für dieses Objekt die Methode encode() zur Verfügung steht. Wenn dies nicht der Fall ist, soll JSON Problem likely!! mit genaueren Informationen, wie es auch in der Fehlermeldung aus dem jobmoncgi.log zu sehen ist, ausgegeben werden. Durch die Anwendung der Funktion Dumper() auf $json konnte der Auslöser der Fehlermeldung gefunden werden; $json war gar nicht erstellt worden. Eine Suche in der Perl-Dokumentation [21] brachte die Lösung des Problems. Zum einen waren die Parameter delimiter und skipinvalid durch space before und allow unknown ersetzt worden; zum anderen hatte sich auch die Syntax verändert, so dass das Problem durch die Ersetzung von durch my $json = new JSON(pretty => 1, delimiter => 1, skipinvalid => 1); my $json =JSON->new->pretty(1)->space_before(1)->allow_unknown(1); behoben werden konnte Beendete Jobs Für die Jobs, die gerade laufen, in der Warteschlange stehen oder angehalten wurden, konnten nach der Anpassung des JSON-Aufrufs alle Daten angezeigt werden. Das Betrachten von Jobs, die bereits fertig waren, war allerdings nicht möglich, da sie nicht in der Jobliste im linken Bereich der Weboberfläche auftauchten. Es wurde allerdings weder auf der Weboberfläche noch in der Logdatei jobmoncgi.log eine Fehlermeldung ausgegeben. Die Jobliste wird über einen SQL-Befehl gefüllt, der alle Job-IDs abfragt, die einen bestimmten vorher vom Nutzer ausgewählten Status haben. Bei den fertigen Jobs existiert als zusätzliche Bedingung, dass die Zeit, zu der die Jobs beendet wurden, in einem bestimmten Zeitintervall liegen muss. Suchte man in der Datenbank die Jobs, die diese Bedingungen erfüllen, erhielt man eine leere Liste; es gab also keine Jobs, die beide Bedingungen, also 23

29 dass der Status beendet ist und die Endzeit in einem vorher bestimmten Zeitintervall liegt, erfüllten. Die beendeten Jobs tauchten in der Datenbank auf; es fehlte immer ein Wert in der Spalte end, die die Endzeit enthält. Das erklärte, weshalb die Jobliste leer blieb, da der SQL-Befehl die Endzeit als Bedingung abfragt. Dadurch wurde klar, dass der Fehler in der Befüllung der Datenbank lag. Das Eintragen der Endzeit findet im Modul JobSensor in der Methode fetch statt; hier gibt es die Variable $sthub, die das Befüllen der Datenbank mit Endzeit und Exit-Status bezeichnet. Bei genauerem Hinsehen fiel auf, dass den fertigen Jobs in der Datenbank auch der Exit-Status fehlte, also ein generelles Problem an dieser Stelle existierte. Die Werte für Exit-Status und Endzeit entstammen der Variablen $js. In dieser fehlten jedoch ebenfalls Werte für Exit-Status und Endzeit. Verfolgt man diese Variable im Programmcode zurück, gelangt man schlussendlich zu einem Befehl, der grep heißt. Dieser kann aus bestimmten Dateien Zeilen herauslesen, die über bestimmte Inhalte oder Strukturen verfügen. Im vorliegenden Fall wird aus bestimmten Dateien, deren Dateipfad in config.pl konfiguriert ist, die Endzeit sowie der Exit-Status ausgelesen. Der angegebene Dateipfad /var/torque/pbs/server priv existierte jedoch nicht. Durch Vergleich mit den anderen Einstellungen war es möglich, den richtigen Dateipfad /var/spool/pbs/server priv zu bestimmen, so dass die Jobs jetzt eine Endzeit erhalten; dadurch erfüllen sie die Bedingung in der Datenbankabfrage und werden auf der Weboberfläche angezeigt. Die Änderung dieses Pfads konnte auf eine Aktualisierung von Torque zurückgeführt werden MySQL Ein weiteres Problem bestand darin, dass immer dann, wenn viele Jobs auf einem Workernode liefen, die Informationen, die in der Tabelle wninfo liegen sollten, nicht mehr angezeigt wurden und stattdessen eine Fehlermeldung der Form Job finished or re-located!,jobid= auftauchte (vgl. Abb. 14). Abbildung 14: Ausschnitt der Weboberfläche mit Fehlermeldung Dieses Problem tauchte zum ersten Mal auf, nachdem neue Workernodes 24

30 mit mehr als acht Prozessorkernen angeschafft wurden. Die Anzahl der Jobs und der Prozessorkerne hängt direkt zusammen, da auf jedem Prozessorkern ein Job laufen soll. Die Logdatei nodesensor daemon.log gibt die folgende Fehlermeldung aus: DBD::mysql::st execute failed: MySQL server has gone away at /opt/jobmon/lib/collector/nodesensor.pm line 164 Die WN-Info eines Workernodes wird in eine XML-Datei gespeichert und diese wird dann an die Datenbank übergeben. Diese Übergabe findet in den Zeilen statt, auf die die obige Fehlermeldung verweist. Bis zu dieser Übergabe an die Datenbank schien es keine Probleme zu geben. Dennoch kam die XML-Datei nicht in der Datenbank an. Eine Recherche im Internet im Hinblick auf die oben genannte Fehlermeldung bestätigte die Vermutung, dass es bei der Übergabe ein Problem gibt [22]. Standardmäßig ist MySQL so konfiguriert, dass die Pakete, die zwischen Client und Server übertragen werden, nicht größer als 1 MB sein dürfen. Dies lässt sich allerdings umstellen, in dem man das Argument max allowed packet mit einer passenden Angabe der erlaubten Paketgröße in der Konfigurationsdatei hinzufügt. Um jedes dieser Pakete annehmen zu können, hält der Server immer einen entsprechend großen Bereich im Arbeitsspeicher frei. Die Beschränkung dient auch als Möglichkeit, das übergebene Paket auf Richtigkeit zu überprüfen. Ist es zu groß und enthält demzufolge einen falschen Inhalt, wird es abgelehnt. Deshalb sollte die Größe so gewählt werden, dass alle erlaubten Pakete in der Datenbank ankommen. Um den Arbeitsspeicher nicht unnötig zu belasten und die Kontrollfunktion der Beschränkung verwenden zu können, sollte der Wert dabei aber möglichst klein sein. Um zu bestimmen, wie groß die zu übertragenden Pakete maximal sind, wurden zunächst für zufällig ausgewählte Workernodes die Anzahl der gerade laufenden Jobs und die Größe der XML-Datei bestimmt. Dise wurden dann gegeneinander aufgetragen (vgl. Abb. 15); im Anhang befindet sich eine Tabelle mit den Messwerten (vgl. Anh. B). Aus dem Vergleich zwischen der Anzahl laufender Jobs und der Größe der XML-Datei ergibt sich, dass die Dateigröße im Durchschnitt ungefähr 150 kb pro laufendem Job beträgt. Die Workernodes besitzen bis zu 32 Prozessorkerne. Damit sind maximal 32 laufende Jobs möglich, was einer Größe der XML-Datei von ungefähr 5 MB entspricht. Um Workernodes mit bis zu 64 Prozessorkernen verwenden zu können und zusätzlich noch Reserve zur Verfügung zu haben, wird der Wert des größtmöglichen Pakets auf 15 MB 19 gesetzt. Alternativ zum Umstellen dieses Parameters könnte man jobmon so umzuprogrammieren, dass die an die Datenbank übertragenen Pakete kleiner 19 Aufgrund der großzügigen Reserve ist eine Fehlerrechnung hier nicht erforderlich. 25

31 Dateigröße der XML-Datei (MB) y(x) = x Anzahl laufender Jobs Abbildung 15: Größe der XML-Datei aufgetragen gegen Anzahl der laufenden Jobs werden. Dies könnte man zum Beispiel erreichen, indem man nicht mehr für jeden Workernode, sondern für jeden Job eine eigene XML-Datei erstellt. Dies würde den Vorteil bringen, dass es nicht nötig wäre, bei einem Systemumbau die MySQL-Konfiguration den verwendeten Workernodes anzupassen. Diese Umprogrammierung würde allerdings auch Nachteile mit sich bringen. So ist insbesondere der Eintrag unter Job ps für alle Jobs eines Workernodes derselbe. Das Abspeichern dieser Daten für jeden Job würde damit zu einer Dopplung in der Datenbank führen, die sich nur auflösen ließe, indem man Daten trennt, die eigentlich zusammengehören. Auch wären mehr Datenbankaktionen nötig, da statt einem Datensatz für jeden Workernode ein Datensatz für jeden Job anfallen würde. Das Hauptargument gegen eine Umprogrammierung ist jedoch ein anderes. Es ist geplant für einen Job mehrere Prozessorkerne zu verwenden. Dadurch laufen auf jedem Workernode weniger Jobs und damit sind auch die entsprechenden XML-Dateien deutlich kleiner. Es ist davon auszugehen, dass die Anzahl der Prozessorkerne, die einem Job zur Verfügung stehen, in Zukunft in gleichem Maße ansteigen wie die Anzahl der Prozessorkerne, die in einem Workernode verbaut sind. Eine Konfigurationsänderung wird demnach nur in sehr seltenen Fällen notwendig sein und den Aufwand des Umprogrammierens deutlich unterschreiten. 26

32 3.3 Erweiterung Pay-Load-Jobs Übersicht Neben den normalen User-Jobs laufen auf dem Grid auch die sogenannten Pilot-Jobs. Den Ablauf eines Pilot-Jobs kann man in Abb. 16 sehen. Zum Vergleich zeigt Abb. 17 den Ablauf eines normalen User-Jobs. Grid-Nutzer schickt Job an zentrales Managementsystem. Zentrales Managementsystem schickt Pilot-Job an das CE eines Grid-Zentrums. Dort kommt der Pilot-Job in eine Warteschlange CE schickt Pilot-Job an ein Workernode, der ihn ausführt Pilot-Job fragt beim zenralen Managementsystem nach auszuführenden Jobs Pay-Load-Job wird beendet. Jobs in der Warteschlange des zentralen Managementsystems? ja Erster Job aus der Warteschlange des zentralen Managementsystems wird als Pay-Load-Job unter der Kontrolle des Pilot-Jobs ausgeführt. nein Pilot-Job wird beendet. Abbildung 16: Ablauf eines Pilot-Jobs 27

33 Grid-Nutzer schickt Job an das Workload Managementsystem Workload Managementsystem schickt Job an das CE eines Grid-Zentrums. Dort kommt der Job in eine Warteschlange CE schickt Job an ein Workernode, der ihn ausführt Job wird beendet. Abbildung 17: Ablauf eines User-Jobs Die Verwendung von Pilot-Jobs bietet die Möglichkeit, das Scheduling der Jobs, die am Ende ausgeführt werden sollen, sehr flexibel zu gestalten. Diese stehen in einer zentralen Warteschlange und die Entscheidung, wann welcher Job läuft, muss erst getroffen werden, wenn ein Workernode zur Verfügung steht. Dadurch ist es möglich, dass der Job, der den Pilot-Job getriggert hat, nicht der Job ist, der als erstes ausgeführt wird. Für die Jobs, die an das Workload-Managementsystem (WMS) geschickt werden, wird diese Entscheidung sofort getroffen. Dabei muss anhand der aktuellen Situation eine Prognose dafür erstellt werden, welches das beste Grid-Zentrum für diesen Job ist. Bis der Job dann tatsächlich auf einem Workernode ausgeführt werden kann, kann sich diese Situation schon wieder geändert haben. So ist es zum Beispiel möglich, dass das WMS den Job an ein Grid-Zentrum schickt, bei dem wenige Jobs in der Warteschlange stehen. Wenn dies jedoch Jobs sind, die sehr lange laufen, wäre es besser, den Job an ein Grid-Zentrum mit vermeintlich längerer Warteschlange zu schicken. Die Verwendung von Pilot-Jobs hat jedoch auch einen Nachteil: Weil das Cluster nur den Pilot-Job sieht, steht auch nur für diesen ein Monitoring zur Verfügung. Dies gilt insbesondere für jobmon. Auf der Weboberfläche kann man die Pilot-Jobs daran erkennen, dass in der Zeile Role Role=pilot steht. 28

34 Abbildung 18: Ausschnitt Role eines Pilot-Jobs Die einzelnen Pay-Load-Jobs, die innerhalb des Pilot-Jobs laufen, tauchen im Monitoring jedoch nicht auf; jobmon soll daher so modifiziert werden, dass auch für diese die wichtigsten Informationen zur Verfügung stehen. Die bereits vorhandenen Sensoren sind dazu nicht in der Lage und müssen deshalb erweitert werden. Das Erweitern der Sensoren besteht dabei aus zwei Schritten. Zunächst müssen Quellen für die verschiedenen Daten gefunden werden. Danach muss jobmon so umprogrammiert werden, dass diese Quellen zusätzlich abgefragt werden. Der erste Schritt konnte innerhalb dieser Arbeit bereits abgeschlossen werden. Bevor die einzelnen Quellen genauer beschrieben werden, gibt Tab einen Überblick über die Herkunft der einzelnen Daten. Tabelle 5: Quelle der Daten für die Pay-Load-Jobs Information Jid Status Local User Queue Submitted at Finished at Exit-Status CPU Time Wall Time Host CE ID RB/WMS Subject Proxy Validity Role Graph CPU- Auslastung Quelle Job-ID des Pilot-Jobs+fortlaufende Nummer Logdatei StarterLog im Jobordner Zertifikat im Jobordner Queue des Pilot-Jobs Logdatei StarterLog im Jobordner Logdatei StarterLog im Jobordner Logdatei StarterLog im Jobordner Aus Timeseries des Pilot-Jobs berechenbar Differenz zwischen Start- und Endzeit für beendete Jobs, Differenz zwischen Startzeit und aktueller Zeit für laufende Jobs Variable $host (in NodeSensor.pm vorhanden) CE ID des Pilot-Jobs Batchsystem, das die Pay-Load-Jobs verteilt (Condor für Pay-Load-Jobs der VO cms) aus Zertifikat im Jobordner aus Zertifikat im Jobordner aus Zertifikat im Jobordner zeitlicher Ausschnitt CPU-Auslastung des Pilot- Jobs 29

35 Graph Arbeitsspeicherauslastung Job ps WN top Work Dir Job Dir Job Output Job Error zeitlicher Ausschnitt aus Graph Arbeitsspeicherauslastung des Pilot-Jobs Ausschnitt aus Job ps des Pilot-Jobs Logdatei im Jobordner Logdatei im Jobordner Logdatei im Jobordner Logdatei im Jobordner Logdatei im Jobordner Der Jobordner ist der Datei-Ordner, der für jeden laufenden User-Job auf dem Workernode erstellt wird, auf dem der Job gerade läuft. Er heißt Job- ID.grid-ce.physik.rwth-aachen.de. Wie in Tab zu sehen ist, stammen viele Daten aus diesem Jobordner. Die Daten aus den Pilot-Jobs zu extrahieren, ist relativ leicht möglich, weil die Pilot-Jobs eine feste Grundstruktur besitzen. Zu beachten ist, dass die folgenden Ergebnisse anhand der Ordnerstruktur von Pilot-Jobs der VO cms ermittelt wurden. Diese sind in Aachen von besonderer Bedeutung, da hier nur sehr selten Pilot-Jobs anderer VOs laufen. Die Pilot-Jobs der VO cms haben die Gemeinsamkeit, dass das zentrale Managementsystem das Batch-System Condor verwendet, um Pay-Load-Jobs an die Pilot-Jobs zu schicken. Es ist daher möglich, dass die Abfrage der Informationen von Pay-Load-Jobs anderer VOs angepasst werden muss, insbesondere dann, wenn dort ein anderes Batch-System für das zentrale Managementsystem verwendet wird. Dies sollte jedoch ohne großen Aufwand möglich sein. Das Extrahieren der Daten aus der Datei StarterLog ist bereits in jobmon integriert und wird in Kapitel beschrieben. In Kapitel werden Möglichkeiten beschrieben, an die restlichen Daten zu gelangen Daten aus StarterLog Bei Pilot-Jobs enthält der Jobordner einen Ordner, dessen Name aus glide gefolgt von einer sechsstelligen Zeichenfolge besteht. Dieser Ordner glide xxxxxx wiederum enthält einen Ordner log, der die Datei Starter- Log enthält. Hier werden alle wichtigen Ereignisse und deren Uhrzeit mitgeschrieben. Da dazu insbesondere das Starten und Beenden der Pay-Load- Jobs gehört, kann hier aus bestimmten Zeilen, die für jeden Pay-Load-Job auftauchen (vgl. Abb. 19), die Start- und Endzeit sowie der Exit-Status extrahiert werden. 30

36 09/25/15 10:35:43 (pid:21612) ** condor starter (CONDOR - STARTER) STARTING UP. 09/25/15 11:01:05 (pid:30165) Got SIGQUIT. Performing fast shutdown. 09/25/15 11:01:05 (pid:30165) ShutdownFast all jobs. 09/25/15 11:01:05 (pid:30165) **** condor starter (con dor STARTER) pid EXITING WITH STATUS 0 09/25/15 11:06:55 (pid:21612) I am: hostname: grid-wn093, fully qualified doman name: grid-wn093.physik.rwth-aachen.de, IP: , IPv4: , IPv6: 09/25/15 11:06:55 (pid:21612) I am: hostname: grid-wn093, fully qualified doman name: grid-wn093.physik.rwth-aachen.de, IP: , IPv4: , IPv6: 09/25/15 11:06:55 (pid:21612) ****************************************************** 09/25/15 11:06:55 (pid:21612) ** condor starter (CONDOR - STARTER) STARTING UP 09/25/15 11:06:55 (pid:21612) **/tmp/ grid-ce.physik. rwth-aachen.de/glide mmfpu8/main/condor/sbin/condor - starter Abbildung 19: Ausschnitt aus der Logdatei StarterLog Die zweite markierte Zeile wird im Folgenden als Start-, die erste als Endzeile bezeichnet. Im vorliegenden Fall wurde der Pay-Load-Job mit der Pid am um 10:35:43 Uhr gestartet und um 11:01:05 Uhr am selben Tag beendet. Um 11:06:55 Uhr wurde dann der Job mit der Pid gestartet. Bei der Pid handelt es sich um die Prozess-ID auf dem jeweiligen Workernode. Über diese ist es möglich die Pay-Load-Jobs innerhalb eines Pilot-Jobs zu identifizieren. Anhand dieser beiden charakteristischen Zeilen lassen sich für jeden Pilot- Job die Pay-Load-Jobs bestimmen, die innerhalb von diesem laufen oder bereits gelaufen sind. Zusätzlich enthalten sie den Exit-Status und über die Differenz zwischen Start- und Endzeit kann die Wall Time bestimmt werden. Beim Status besteht ein Unterschied zwischen den User-Jobs und den Pay- Load-Jobs. Da sie erst dann im lokalen Cluster landen, wenn sie ausgeführt werden, können sie sich hier nicht im Status in der Warteschlange oder angehalten befinden. Der Status wird über das Vorhandensein der Endzeile bestimmt. Der Job läuft, wenn die Endzeile nicht vorhanden ist, und ist beendet, wenn die Endzeile vorhanden ist. Der Status unbekannt kann daher ebenfalls nicht eintreffen. 31

37 Im Modul NodeSensor.pm des NodeSensors befindet sich eine Schleife, die für jeden User-Job, der auf dem entsprechenden Workernode läuft, durchlaufen wird und einige Daten sammelt. In dieser Schleife findet nun auch das Extrahieren der Daten über die Pay-Load-Jobs statt. Diese Stelle im Programmcode wurde gewählt, da die Abfrage der Daten über die Pay- Load-Jobs ebenfalls für jeden Pilot-Job neu durchgeführt werden muss und so gut in der Schleife integriert werden kann. Auch existiert hier bereits eine Liste der Job-IDs der User-Jobs, so dass die Namen der Jobordner der Pilot-Jobs leicht bestimmt werden können. Die Abfrage dieser Daten mit dem NodeSensor ist sinnvoll, da die Daten auf den Workernodes liegen und der NodeSensor bereits auf den Workernodes läuft. Eine Abfrage mit dem JobSensor würde inhaltlich besser passen, da es die Jobsummary der Pay-Load-Jobs ist, die hier abgefragt wird und die Jobsummaries der User-Jobs über den JobSensor abgefragt werden. Dies würde aber zu einer großen Belastung für das Netzwerk führen, da vom CE immer wieder auf alle Workernodes zugegriffen werden müsste. Die Abfrage auf den Workernodes bringt allerdings auch einen Nachtteil mit sich. Um auf der Weboberfläche richtig angezeigt zu werden, müssen die Jobsummaries der Pay-Load-Jobs in der Datenbanktabelle jobinfo summary abgespeichert werden. Dadurch übertragen die beiden Sensoren Daten in die gleiche Datenbanktabelle und sind damit nicht mehr komplett getrennt. Langfristig kann es sinnvoll sein, für die Pay-Load-Jobs eine eigene Tabelle zu erstellen, um neue Fähigkeiten der Weboberfläche zu ermöglichen. So wäre es zum Beispiel denkbar, per Knopfdruck alle Pay-Load-Jobs eines Pilot-Jobs anzeigen zu lassen. Gleichzeitig würde eine neue Tabelle die Trennung zwischen den beiden Sensoren wiederherstellen. Mit der Änderung in der Datenbank wäre auch eine Umprogrammierung des WebService nötig. Das primäre Ziel liegt jedoch zunächst im Sammeln der Daten. Hierfür bringt die Veränderung in der Struktur der Datenbank keinen Vorteil und würde damit einen unnötigen Arbeitsaufwand bedeuten. Da es auch später noch ohne großen Aufwand möglich ist, die Tabelle, in der diese Daten abgelegt werden, zu ändern, bleibt zunächst die alte Datenbankstruktur erhalten. Das Auswerten der Logdatei StarterLog ist in dem Programmablaufplan in Abb. 20 schematisch dargestellt. Der Übersicht halber ist das Speichern der Daten in die Datenbank dort nur als ein Prozess eingezeichnet. Den Programmablaufplan für das Speichern in der Datenbank zeigt Abb. 21. Die dort auftretende Variable status db enthält den Status, den der Job laut Datenbank hat. Der Status in der Datenbank weicht vom tatsächlichen Status ab, wenn dieser sich der letzten Abfrage geändert hat. Der Programmcode befindet sich im Anhang (vgl. Anh. A). 32

38 Start Job-ID des Pilot-Jobs nein Unterordner glide * existiert? ja Startzeilen extrahieren ja alle Startzeilen abgearbeitet? nein Pid, starttime aus Startzeile Job-ID festlegen exec host=$host Endzeile existiert? ja endtime, exit - status aus Endzeile nein status= laufend walltime=aktuelle Zeit-starttime status= beendet walltime=endtimestarttime Füllen der Daten in die Datenbank Ende Abbildung 20: Programmablaufplan: Sammeln der Daten 33

39 Start Job bereits in der Datenbank? ja nein Neuer Datenbankeintrag mit jid, starttime, endtime, exit status, walltime, exec host anlegen (nicht vorhandene Werte als undef gesetzt) ja status db= beendet? nein status= laufend ja walltime, endtime, exit - status, status aktualisieren nein walltime aktualisieren Ende Abbildung 21: Programmablaufplan: Speichern der Daten in der Datenbank Es existiert allerdings ein Fall, der noch nicht abgedeckt ist. In den meisten Fällen wird der Jobordner gelöscht, sobald der User-Job beendet ist. Dadurch ist auch kein Zugriff auf die Datei StarterLog mehr möglich. Werden zwischen zwei Abfragen sowohl der Pilot-Job als auch der Pay-Load-Job beendet, wird jobmon für diesen letzten Pay-Load-Job keine Endzeile finden und dieser wird damit im Status laufend bleiben, obwohl der Pilot-Job schon beendet ist, womit auch der Pay-Load-Job nicht mehr laufen kann. Um diesen Fall zu verhindern, prüft der NodeSensor für alle laufenden Pay- Load-Jobs, ob der dazugehörige Pilot-Job noch läuft und ändert die Einträge in der Datenbank, falls dies nicht der Fall ist. Der Status ist dann beendet und die Endzeit wird auf den Wert des Pilot-Jobs gesetzt. Der Exit-Status bleibt undefiniert, weil es sowohl möglich ist, dass der Pay-Load-Job vor dem Beenden der Pilot-Jobs fertig geworden ist, als auch, dass der Pay-Load-Job 34

40 durch das Beenden des Pilot-Jobs abgebrochen wurde. Den entsprechenden Programmablaufplan zeigt Abb. 22. Der Programmcode befindet sich im Anhang (vlg. Anh. A). Start Liste laufender Pay-Load-Jobs ja Liste abgearbeitet? nein Job-ID des Pilot-Jobs für nächsten Pay-Load-Job festlegen ja status Pilot- Job= beendet? nein status= beendet exit status= undef endtime=endtime des Pilot-Jobs walltime=endtime-starttime Aktualisieren von exit - status, endtime, walltime,status in der Datenbank Ende Abbildung 22: Programmablaufplan: laufende Pay-Load-Jobs beenden, deren Pilot-Job bereits beendet ist Die auf die oben beschrieben Weise gesammelten Daten können bereits auf der Weboberfläche betrachtet werden, wie Abb. 23 zeigt. 35

41 Abbildung 23: Jobsummary eines Pay-Load-Jobs Andere Daten Authentifizierung Die Daten eines Pay-Load-Jobs sollen für den Besitzer des Pay-Load-Jobs und für den Besitzer des entsprechenden Pilot-Jobs sichtbar sein. Deren Zertifikate müssen gefunden und die entsprechenden Daten in der Datenbank gespichert werden, um später mit den Daten des Nutzers der Weboberfläche verglichen werden zu können. In den Jobordnern der Pilot-Jobs befindet sich unter glide xxxxxx/execute/ ein Ordner, dessen Name aus dir gefolgt von der Pid des gerade innerhalb dieses Pilot-Jobs laufenden Pay-Load-Jobs besteht. Dabei handelt es sich um die Jobordner der Pay-Load-Jobs. In diesen Jobordnern befindet sich eine Datei, die das Zertifikat des Besitzers des Pay-Load-Jobs enthält. Es besteht allerdings die Schwierigkeit, diese Datei zu identifizieren. Häufig ist der Name der Datei myproxy.pem oder beginnt mit x509 gefolgt von einer Zeichenfolge. Bei manchen dieser Dateien besteht der Name ausschließlich aus einer zumindest scheinbar strukturlosen Zeichenfolge. Eine Alternative, an das Zertifikat des Pay-Load-Job-Besitzers zu kommen, ist das Programm glexec. Im Pilot-Job wird die Identität des Besitzers des gerade laufenden Pay-Load-Jobs abgespeichert. Wird dieser beendet und ein neuer Pay-Load-Job gestartet, sorgt glexec dafür, dass diese Identität geändert wird. Dazu wird auch das Zertifikat übergeben und könnte abge- 36