Monitoring. Björn Hagemeier 25. März 2005

Transkript

1 Monitoring Björn Hagemeier 25. März

2 1 Motivation 1.1 Was ist Monitoring? Monitoring ist das Sammeln von Status-Informationen einer Ressource. Da es sich bei einer Grid-Ressource um ein verteiltes System handelt, muss das Monitoring bestimmte Eigenschaften erfüllen, die es z. B. ausfallsicherer machen. Die gesammelten Informationen werden zu verschiedenen Zwecken verwendet. [7] nennt drei Gründe für Monitoring. Daten (über die Ausführung eines Programms) werden gesammelt, um Optimierungen für die nächste Ausführung vornehmen zu können. Die Daten können in bestimmten Fällen auch für Anpassungen am laufenden Programm bzw. den Beteiligten Bibliotheken verwendet werden. Ein Scheduler muss wissen, welche Ressourcen überhaupt zur Verfügung stehen und wie diese ausgelastet sind. Damit kann er dann möglichst gute Scheduling-Entscheidungen treffen. Die ersten beiden Gründe für das Monitoring sind für die Projektgruppe weniger wichtig. Der letzte Grund ist allerdings von zentraler Bedeutung für jedes System. Ohne überhaupt Statusinformationen über den Zustand einer Ressource zu haben, können z. B. keine Scheduling-Entscheidungen getroffen werden Einen Anwender der Grid-Ressource interessiert die Performance seiner Anwendung. Diese Informationen kann er mit Hilfe des Ressourcen-Informationsdienstes abfragen, der auf die Monitoring-Informationen zurückgreift. Einige Beispiele für Metriken, die das Monitoring betrachtet, seien im Folgenden genannt. host.mem.avail verfügbarer Speicher eines Knotens host.mem.size gesamter Speicher eines Knotens host.cpu.avail verfügbare Prozessoren host.swap.avail verfügbarer Auslagerungsspeicher host.swap.size gesamter Auslagerungsspeicher host.processes.all alle Prozesse host.processes.running laufende Prozesse Grundsätzlich können alle messbaren Daten zum Monitoring herangezogen werden. Die Mehrzahl der Systeme bietet die Möglichkeit, eigene Metriken zu definieren und gleichwertig mit einer Grundmenge von Standard-Werten zu behandeln. Im folgenden werden ein allgemeiner Architekturvorschlag, die Grid Monitoring Architecture (GMA) des Global Grid Forum (GGF), und 5 Implementierungen von Monitoring-Systemen vorgestellt. Bei den Implementierungen handelt es sich um die Monitoring and Discovery Services (MDS) aus dem Globus Toolkit, die Relational Grid Monitoring Architecture (R GMA) des European DataGrid Projektes, den Mercury-Monitor des GridLab Projektes, den Hawkeye-Monitor des Condor- Projektes und das Monitoring-System der Sun Grid Engine. 2

3 2 Architekturen 2.1 Global Grid Forum GMA Anforderungen Das Global Grid Forum (GGF) schlägt eine Grid Monitoring Architecture (GMA) vor. Sie berücksichtigt die speziellen Anforderungen an das Monitoring in Grid- Umgebungen. Die Anforderungen werden an Information und Systeme gestellt. Für Informationen gilt, dass Aktualisierungen häufig vorkommen können und Daten eine beschränkte, teilweise sogar sehr kurze, Aktualität haben. Das Monitoring-System als Ganzes, bzw. die beteiligten Komponenten, müssen die im Folgenden aufgeführten Anforderungen erfüllen: Geringe Latenz Hohe Datenrate Geringer Overhead für Messungen Skalierbarkeit Sicherheit Das gilt unter anderem auch aufgrund der oben genannten Kurzlebigkeit der Daten. Kurzlebige Daten, die mit einem System mit hoher Latenz übertragen werden, sind für den Anwender dieser Information mit großer Wahrscheinlichkeit nutzlos. Eine hohe Datenrate wird insbesondere für das Monitoring von Anwendungen benötigt. Anwendungen können in kurzer Abfolge große Mengen von Daten erzeugen, die vom Monitoring-System zu verarbeiten sind. Auf den Rechen-Knoten darf es durch die Messungen, die im Rahmen des Monitoring lokal vorgenommen werden, nicht zu Beeinträchtigungen kommen. Sicherheit kann unter verschiedenen Gesichtspunkten betrachtet werden. Zum einen sollte das Monitoring-System ausfallsicher sein, da verschiedene andere Komponenten in einer Ressource auf die Informationen des Monitoring angewiesen sind. Der Scheduler trifft seine Entscheidungen über die Platzierung eines Jobs unter Anderem aufgrund der Information über die Auslastung eines Knotens. Kann diese vom Monitoring-System nicht zur Verfügung gestellt werden, wird der betroffene Knoten nicht beim Scheduling berücksichtigt werden. Betrifft der Ausfall des Monitoring- Systems eine zentrale Komponente, kann der Scheduler möglicherweise gar nicht mehr arbeiten. Sicherheit kann aber auch als Schutz der Daten vor unberechtigtem Zugriff gesehen werden. Externe Benutzer einer Grid-Ressource müssen sich darauf verlassen können, dass nicht jeder andere Benutzer Zugriff auf ihre Daten hat. In besonders sensiblen Fällen darf nicht einmal bekannt werden, dass bestimmte Benutzer die Ressource überhaupt Nutzen. 3

4 Abbildung 1: Architekturvorschlag des GGF Architektur Anhand der geforderten Eigenschaften des Systems schlägt das GGF eine Architektur bestehend aus drei Komponenten vor. Diese besteht aus Producer, Consumer und einem Directory Service. Producer haben Informationen anzubieten, die von Consumern angenommen werden können. Der Directory Service verwaltet Informationen darüber, wo die Producer und Consumer zu finden sind. Ebenso speichert der Directory Service Informationen über die Beschaffenheit der Informationen die Producer anbieten bzw. Consumer abfragen. Im Folgenden werden die einzelnen Schritte der Kommunikation zwischen den einzelnen Komponenten erläutert. Producer und Consumer registrieren sich und ihr Angebots- bzw. Anfrageprofil beim Directory Service. Consumer können dann beim Directory Service anfragen, wo die sie interessierende Information zu lokalisieren ist. Producer finden mit Hilfe des Directory Service diejenigen Consumer, die an ihren Informationen interessiert sind. Vielfältiger ist die Kommunikation zwischen Consumer und Producer. Consumer können Informationen anfragen und Producer auf diese Anfrage antworten. Dieses Schema wird in der Architektur als query/response, also Frage und Antwort, bezeichnet. Consumer können sich aber auch bei Producern anmelden, die dann bei Änderung der Daten, periodisch oder aufgrund bestimmter Bedingungen, diese an die entsprechenden Consumer senden. In [10] wird noch eine Erweiterung dieses Mechanismus um spezielle Ereignisse genannt, die aber nicht weiter spezifiziert wird. Die Protokolle, über die die Kommunikation zwischen den Komponenten der GMA stattfindet, werden in dem Vorschlag nicht festgelegt. Es wird auch explizit angegeben, dass die Daten-Nachrichten über ein anderes Protokoll übertragen werden können als die Kontrollnachrichten. Mit Datennachrichten sind hier die Nachrichten gemeint, die die Monitoring- Informationen enthalten. Kontrollnachrichten werden verwendet, um die Komponenten untereinander zu registrieren. Als Beispie- 4

5 le für Protokolle bzw. Protokollkombinationen werden SOAP/HTTP, LDAP und XML/BXXP. Zu beachten ist auch, dass für die Nachrichtenübermittlung keine Garantien gefordert werden. Nachrichten können also auf dem Weg verloren gehen. Gerade vor dem Hintergrund einer sehr dynamischen und weit verteilten Umgebung kann diese Tatsache ein Monitoring-System anfällig für falsche bzw. nicht aktuelle Informationen machen. 2.2 Globus Toolkit MDS Die Monitoring and Discovery Services (MDS) des Globus Toolkit orientieren sich auch in groben Zügen an den Vorschlägen des GGF. Die Implementierung arbeitet auf Basis von drei Komponenten: dem Grid Index Information Service (GIIS), dem Grid Resource Information Service (GRIS) und dem Information Provider (IP). Ein IP ist auf jedem Knoten lokal vorhanden. Er stellt dem GRIS die Informationen der lokalen Sensoren zur Verfügung. Im GRIS werden die Informationen der IP gesammelt. Jede Grid-Ressource verfügt über einen GRIS. Die Daten eines GRIS können sowohl von den in der Hierarchie höher liegenden GIIS als auch von beliebigen Clients abgefragt werden. Ein GIIS verwaltet Informationen über die Grid-Ressourcen auf oberster Ebene. Durch das Caching der Daten wird verhindert, dass bei jeder Anfrage eines Client das Datum von der entsprechenden Ressource erneut geholt werden muss. Eine Invalidierung der gecachten Daten geschieht über einen Ablauf der Gültigkeitsdauer oder Update der Daten von der Ressource. Die einzelnen GIIS gleichen ihre Daten untereinander ab. Mittels der Grid Security Infrastructure (GSI) wird die Authentifizierung von Benutzern und anderen Clients gegenüber dem MDS realisiert. Die Daten werden von den IP bis zum GIIS einheitlich in XML übertragen. Damit bietet das Toolkit XPath und Query-by-name Fähigkeiten. Selbst-definierte Anfragetypen werden unterstützt. Wie genau diese letzte Aussage zu verstehen ist, wird in der Dokumentation nicht erwähnt. 2.3 European DataGrid R GMA Die Relational Grid Monitoring Architecture (R GMA) des European DataGrid Projektes ist eine Implementierung der Grid Monitoring Architecture (GMA) des Global Grid Forum. Sie benutzt ein relationales Daten-Schema und ist damit im Vergleich zu anderen Implementierungen, die z. B. ihre Daten in LDIF speichern, deutlich flexibler, wenn es darum geht, beliebige Anfragen an den Service zu stellen Anforderungen Bei der Implementierung der R GMA wurden folgende generellen Anforderungen berücksichtigt. Einheitlicher Zugriff auf aktuelle und historische Informationen 5

6 Abbildung 2: Monitoring im Globus Toolkit Timestamps für jedes Datum Skalierbarkeit des Systems Die Unterscheidung zwischen dem Zugriff auf aktuelle und historische Informationen deutet an, dass es überhaupt so etwas wie historische Information gibt. Damit könnte z. B. die Auslastung eines Knotens über die letzten 24 Stunden in Abständen von 15 Minuten verfolgt werden. Wie erwähnt soll der Zugriff auf die aktuelle und die historische Information einheitlich sein. Jedes Datum soll mit Timestamps versehen werden. Die Anforderung ergibt sich aus der vorherigen. Ohne Timestamps wäre das System nicht in der Lage, die Daten historisch einzuordnen. Besonders wenn ein Administrator verschiedene historische Daten miteinander vergleichen möchte, müssen alle diese Daten mit Timestamps versehen sein. Da die zu vergleichenden Daten nicht a priori bekannt sind, müssen alle Daten mit Timestamps versehen werden. Die Skalierbarkeit des Systems kann aus zwei Perspektiven betrachtet werden. Zum einen kann die Menge der zu verarbeitenden Daten größer werden, indem neue Informationen und Informationsarten hinzugefügt werden. Zum Anderen kann die Menge der Informationen steigen, indem die Anzahl der Knoten und Clients größer wird. In beiden Fällen bedeutet die Veränderung einen Mehraufwand für das System, der nicht überproportional zu den genannten Ursachen steigen soll. Nach den generellen Anforderungen an die Architektur sollen nun speziellere Anforderungen und Anforderungen an einzelne Komponenten erläutert werden. Producer sollen in der Lage sein, neue Tabellen hinzufügen zu können. Ein Producer, der ein Datum bislang unbekannten Typs hinzufügen möchte, soll dieses auch tun dürfen. Die Relationen der Datenbank sind verteilt. Ein Producer soll deshalb bestimmen können, welcher Teil einer Relation von ihm angeboten wird. Producer müssen also nicht immer ganze Zeilen in Relationen einfügen. Die eingefügten Daten dürfen keine Inkonsistenzen erzeugen. Es kann vorkommen, dass Consumer die Daten von Producern nicht schnell genug aufnehmen können. Es muss einen Producer-Typ geben, der sich dadurch nicht blockieren lässt. Daten, die ein Producer 6

7 versendet müssen garantiert ankommen. Das Global Grid Forum hatte diese Eigenschaft für die gesamte Kommunikation nicht explizit gefordert. Consumer müssen alle Producer auffinden können, die die sie interessierenden Daten anbieten. Informationen sollen ad hoc vom Producer abgerufen werden können. Im System soll es einen Mechanismus geben, der die Consumer über neue Producer informiert, die zu ihrem Interessenprofil gehören. Das Gesamtsystem soll keinen single point-of-failure aufweisen. Der Ausfall einer oder mehrerer Komponenten darf also nur lokale Auswirkungen haben. Der Rest des Gesamtsystems soll davon unbeschadet weiterarbeiten. Von einem Ausfall betroffene Komponenten sollen die Arbeit unverzüglich fortsetzen, nachdem die Fehlerquelle behoben ist. Als zusätzliche Eigenschaften soll der Zugriff auf das System auf unterschiedliche Art und Weise ermöglicht werden. Als Schnittstelle, über die Benutzer mit dem System kommunizieren können, sollen Kommandozeilenprogramme und eine Webmaske zur Verfügung stehen. Über ein API können Programme auf das System zugreifen. Gerade das API ermöglicht es, weitere Benutzerschnittstellen anzubieten. Als Beispiel hierfür kann ein Administrationstool gesehen werden, das einem Administrator die Interaktion mit der Registry und den Schema-Datenbanken ermöglicht. Sicherheitsanforderungen an dieses System sind, dass Producer bzw. deren Daten nicht ohne Einschränkung eingesehen werden können. Zum einen soll es möglich sein, das Wissen über die Existenz von Producern nur bestimmten Einheiten zur Verfügung zu stellen. Die Anforderungen bezüglich Ausfallsicherheit wurden weiter oben besprochen Architektur Zu Beginn dieses Abschnitts wurde Bereits erwähnt, dass R GMA eine Implementierung der Grid Monitoring Architecture des Global Grid Forum ist. Daraus lässt sich schließen, dass die Architektur drei Komponenten enthält, nämlich Producer, Consumer und den Directory Service. Letzterer wird in diesem Fall auch Registry genannt, um Verwechslungen mit hierarchisch organisierten Verzeichnisdiensten zu vermeiden. Wie bereits angedeutet, gibt es verschiedene Arten von Producer. Insgesamt sind es vier Arten, die zum Einsatz kommen. Der Pluggable-Producer ermöglicht es, beliebige Informationen zur Verfügung zu stellen, indem dem Producer benutzerdefinierte Module hinzugefügt werden. Ein Database-, CircularBuffer- und Persistent-Producer können über das Publisher-Interface aktiv Informationen in die Datenbank eintragen. Die Registry enthält Liste mit Einträgen von Producern und Daten, die diese zur Verfügung stellen. Die Beschreibung der Daten ist im Schema abgelegt. Ein Consumer kann auf Daten mehrerer Producer gleichzeitig zugreifen. Die Anfragen werden als SQL-Statements formuliert und ermöglichen eine große Flexibilität gerade im Vergleich mit Systemen, die die Daten in einem LDAP-Verzeichnis ablegen. 7

8 Abbildung 3: Funktionsweise von Mediatoren in der R GMA Zusätzlich zu den Komponenten der Grid Monitoring Architecture des Global Grid Forum definiert European DataGrid noch zwei weitere Komponenten, die zwar aus Producer und Consumer zusammengesetzt werden können, jedoch eine Sonderstellung in der Architektur einnehmen. Die zusätzlichen Komponenten sind Mediatoren und Archivierer. Consumer erwarten nach einer Anfrage Daten von nur einem Producer. Kommen für eine Anfrage mehrere Producer in Frage, gibt die Registry einen Mediator als Producer an. Dieser Mediator wiederum agiert gegenüber allen in Frage kommenden Producern als Consumer und kombiniert die Informationen, um sie dann an den ursprünglichen Consumer zu schicken. Archivierer sind ebenfalls kombinierte Producer und Consumer. Ein Archivierer wird instantiiert, indem man angibt, welche Daten archiviert werden sollen. Der Archivierer fungiert dann als Consumer für alle Relationen, die archiviert werden sollen. Werden diese von mehreren Producern angeboten, kommuniziert der Archivierer mittels eines Mediators mit diesen. Die R-GMA speichert Daten in Relationen. Damit ist sie deutlich flexibler als andere Systeme, die LDAP/LDIF für die Datenhaltung verwenden. Das Problem mit LDAP/LDIF ist, dass alle möglichen Anfragen schon bei der Implementierung bekannt sein müssen, um sie direkt und effizient abfragen zu können. Komplexere anfragen könnten nur beantwortet werden, indem einzelne Daten abgefragt und diese dann miteinander kombiniert würden. Der Zugriff auf die R-GMA wird durch ein API für die Programmiersprachen Java, C/C++ und Python zur Verfügung gestellt. 8

9 2.4 GridLab Mercury Der Mercury-Monitor des GridLab Projektes ist eine Implementierung der Grid Monitoring Architecture des Global Grid Forum Anforderungen Das GridLab Projekt stellt folgende Anforderungen an die Monitoring-Architektur. Es soll möglich sein, dass Consumer die Daten von den Producern abrufen können. Außerdem sollen die Producer die Daten aktiv an registrierte Consumer schicken können. Große Datenmengen sollen in kurzer Zeit verarbeitet werden können. Diese Anforderung ist besonders für das Anwendungs-Monitoring wichtig. Das Monitoring des Systems soll möglichst wenig Overhead mit sich bringen. Standard-Metriken sollen im Monitoring fest verankert sein. Es sollen alle Komponenten einer Ressource in das Monitoring mit einbezogen werden. Das System soll Verlässlich, Fehlertolerant und Sicher sein. Bei entferntem Zugriff auf die Daten soll es möglich sein, die Daten reduziert zu übertragen. Voraussagen sollen möglich sein Architektur Als Implementierung der GMA besteht der Mercury-Monitor aus Producer, Consumer und einem Directory Service. Auf jedem Knoten wird ein Local Monitor (LM) ausgeführt. Sensoren können als Module hinzugeladen werden. Häufig verwendete Sensoren können möglicherweise auch fest im LM verankert sein. Anwendungs- Monitoring wird über einen speziellen Sensor realisiert, der von der Anwendung über eine Bibliothek angesprochen werden kann. Der Local Monitor sendet die Daten an den Main Monitor (MM). Der MM sammelt die Informationen von allen LM und dient als zentraler Zugriffspunkt für den Monitoring-Service (MS). Der MM bietet Administratoren auch die Möglichkeit, Roh-Daten einzusehen. Der MS stellt die Informationen außerhalb der Ressource zur Verfügung Erweiterungen Gegenüber dem Vorschlag des GGF wurde die Architektur um Aktuatoren erweitert. Damit ist es möglich, über ein klar definiertes Interface, Control genannt, Aktionen auf den Knoten der Ressource auszuführen. Während die Sensoren durch Producer gesteuert werden, übernehmen Aktuator-Controller diese Aufgabe für die Aktuatoren (siehe Abbildung 4). Garantierte Kommunikation zwischen Producer und Consumer bzw. Sensor und Producer sorgt dafür, dass Nachrichten unterwegs nicht verloren gehen können. 2.5 Condor Hawkeye Hawkeye ist das Monitoring-System des Condor Projektes. Die Architektur ist unabhängig vom Global Grid Forum. Periodisch ausgeführte Tasks stellen hier die lo- 9

10 Abbildung 4: Aktuatoren in GridLab kalen Sensoren dar. Die Daten werden in sogenannten ClassAds gekapselt. ClassAds sind Sammlungen von Name/Wert Paaren, die unabhängig vom Monitor in Condor zu unterschiedlichen Zwecken verwendet werden. Werte von ClassAds können auch Ausdrücke enthalten, so dass auch Vergleiche mit anderen ClassAds möglich sind und Bedingungen formuliert werden können. Hawkeye liefert Sensoren für freien Plattenplatz, Speicherausnutzung, Netzwerkfehler, Geöffnete Dateien, CPU-Daten, Systemauslastung und Benutzer. Der Hawkeye-Monitor hat gegenüber den bisher vorgestellten Systemen zwei wesentliche Nachteile. Zum einen ist es auf Grund der Darstellung der Daten als ClassAds schwer möglich, Anwendungs-Monitoring zu betreiben. Da die Daten lokal über periodisch ausgeführte Tasks gesammelt werden, können sie nicht zu beliebiger Zeit abgerufen werden. Großer Vorteil des Hawkeye-Monitors ist, dass er einfach zu handhaben und installieren ist. 2.6 Sun Grid Engine Der Ausführungs-Daemon sge execd der Sun Grid Engine sendet periodisch eine Grundmenge von Statusinformationen an sge qmaster. Diese Grundmenge von Informationen besteht aus Architektur, der Anzahl der Prozessoren, vier Angaben zur durchschnittlichen Systemauslastung, selbige Werte heruntergerechnet auf einzelne Prozessoren und die prozentuale Prozessorausnutzung. Weiterhin gahören Angaben zur Speicherauslastung zu den Standard-Werten. Zusätzlich lassen sich weitere sogenannte load sensors hinzufügen. Ein load sensor kann als einfaches Skript realisiert werden, dass Paare von Namen und Werten auf die Standardausgabe ausgibt und über die Standardeingabe Steuerbefehle entgegennimmt. Die durch diese zusätzlichen Sensoren gesammelten Informationen können beim Scheduling auch mit berücksichtigt werden und sind zu den Standard-Werten 10

11 gleichwertig. Die Ausgabe besteht aus den Schlüsselwörtern begin und end in der ersten bzw. letzten Zeile. Pro Zeile wird ein Wert ausgegeben, der aus drei durch : getrennte Abschnitten besteht. Als erstes wird der Name des host genannt, auf den sich der Wert bezieht. Das Schlüsselwort global ist für global gültige Werte vorgesehen. Danach folgen der Name des Wertes und der Wert selbst. Auf diese Art und Weise lassen sich auf Anfrage von Benutzern oder anderen Komponenten des Systems Statusinformationen abfragen. Damit ist die Methode der Sun Grid Engine nicht so mächtig wie die Vorschläge des Global Grid Forum. 11

12 3 Fazit Für die Zwecke der Projektgruppe lässt sich aus den vorgestellten Systemen kein definitiv richtiger Kandidat auswählen. Die genauere Spezifikation der Anforderungen an unser System bleibt abzuwarten. Auf der einen Seite könnte man den einfacheren Modellen Hawkeye und SGE den Vorzug geben, da sich leichter zu installieren sind. Mit dem Monitoring der Sun Grid-Engine ist man aber dann auch an das gesamte Framework SGE gebunden, das um zusätzliche geforderte Eigenschaften erweitert werden müsste. Gegenüber den komplexeren Lösungen, wie denen der Projekte Grid- Lab und European DataGrid, bestehen Nachteile in der Verwendbarkeit. So sind Anwendungs-Monitoring und das Ereignisgesteuerte versenden von Statusinformationen z. B. nicht möglich. Die Lösungen von GridLab bzw. European DataGrid bieten den Vorteil, dass sie als losgelöste Komponenten entwickelt wurden und auch separat eingesetzt werden können. Beide implementieren die Vorschläge des Global Grid Forum. Erweiterungen gegenüber der vorgeschlagenen Architektur sind bei GridLab die Aktuatoren und garantierte Kommunikation. Beim European DataGrid ist es das relationale Datenmodell, welches einen großen Gewinn an Flexibilität liefert. Mit dem Mercury- Monitor des GridLab-Projektes gibt es auch eine einfach zu installierende Variante dieses deutlich flexibleren Vorschlags für ein Monitoring-System. Die Implementierung des Globus Toolkit wird in die Betrachtungen nicht einbezogen, da sie auf Grid-Ebene arbeitet und nicht auf der Ebene einer lokalen Ressource. In [11] werden Vergleiche zwischen MDS2 des Globus Toolkit, der R GMA des European DataGrid und dem Hawkeye-Monitor des Condor-Projektes angestellt. Dort geht es vor allem um die Skalierbarkeit der Performance bei steigender Anzahl von Benutzern und Rechenknoten. Dabei geht Hawkeye mit gleichzeitig 600 unterstützten Benutzern in Führung. Allerdings ist dabei zu betrachten, dass Hawkeye weniger Möglichkeiten und Flexibilität bietet als die anderen Implementierungen. 12

13 Literatur [1] Project home page. [2] Globus toolkit 2.2 mds technology brief. Technical report, the globus toolkit, [3] R-gma: Relational grid monitoring architecture, [4] Zoltàn Balaton and Gàbor Gombàs. Detailed architecture specification. Deliverable 11.2 of GridLab, [5] Zoltàn Balaton and Gàbor Gombàs. Requirements analysis report. Deliverable D11.1 of GridLab, [6] Karl Czajkowski, Steven Fitzgerald, Ian Foster, and Carl Kesselman. Grid information services for distributed resource sharing. In Proceedings of the 10th IEEE International Symposium on High-Performance Distributed Computing. IEEE Press, [7] Jeffrey K. Hollingsworth and Bart Miller. The Grid: Blueprint of a New Computing Infrastructure, chapter 14, pages Morgan Kaufmann, [8] Sun Microsystems, Inc. Sun Grid Engine 5.3 Administration and User s Guide, April Revision 01. [9] Condor Team. Condor Version Manual. University of Wisconsin Madison, December [10] B. Tierney, R. Aydt, D. Gunter, W. Smith, M. Swany, V. Taylor, and R. Wolski. A grid monitoring architecture. March [11] Xuehai Zhang, Jeffrey L. Freschl, and Jennifer M. Schopf. A performance study of monitoring and information services for distributed systems. In Proceedings of HPDC-12,