Windows Desktop Grid

Transkript

1 Windows Desktop Grid Betreuer: Prof. Dr. Christoph Reich Michael Eckhardt Sebastian Garwers Thomas Rübsamen Tobias Stöffelmaier Jochen Zehnder Semesterprojekt WS 2008/ Januar 2009

2

3 Inhaltsverzeichnis I Inhaltsverzeichnis Inhaltsverzeichnis Abbildungsverzeichnis Abkürzungsverzeichnis I IV V 1. Einleitung Motivation Was ist ein Windows Desktop Grid Übersicht der untersuchten Frameworks Vergleich der Frameworks Auswahlkriterien Auswahlprozess bei Frameworks BOINC GridGain Condor Gründe gegen BOINC und GridGain Gründe gegen BOINC Gründe gegen GridGain Zusammenfassung der Frameworks Das Condor Framework Warum Condor? Zusammenfassung Condor Installation Voraussetzungen und Allgemeines Manuelle Installation

4 II Inhaltsverzeichnis 4.3. Condor unattended Installation Ergänzende Konfiguration Verwaltungstools Zusammenfassung Condor Submit Dateien Terminologie Zusätzliche Terminologien ClassAds Anwendungsbeispiel Zusammenfassung Sonstiger Einsatz von Condor Zusammenfassung Condor und Deployment Fehlermeldung Condor auf Multi-Core Rechnern Zusammenfassung Zusammenfassung und Ausblick Zusammenfassung Ausblick Literaturverzeichnis 75 A. HelloWorld-Job 79 B. SumUp-Job 79 C. Bild-Job 79

5 Inhaltsverzeichnis III D. Anhang CD-ROM 80

6 IV Abbildungsverzeichnis Abbildungsverzeichnis 1. Gridaufbau BOINC Architektur GridGain Architektur Condor Architektur Gebühren für den kommerziellen Support, [22] Condor Installation Condor License Agreement Pool-Setup - Create new Condor Pool Pool-Setup - Join existing Condor Pool Jobausführung-Setup Accounting-Setup Setup JRE-Setup Zugriffsrechte VM-Universe-Setup Service-Setup Custom- oder Default-Installation Pfadeinstellung condor status -Abfrage Anzahl an CPUs in der Condor Config vortäuschen

7 Abkürzungsverzeichnis V Abkürzungsverzeichnis AIX API AT&T BOINC CGI CPU DNS DRMAA EC FIFO FQDN GNU GUI HPUX HTC HTTP IBM JMX JRE LGPL LSF MB MHz MPI MPICH NASA OHG Advanced Interactive executive Application Programming Interface American Telephone & Telegraph Corporation Berkeley Open Infrastructure for Network Computing Common Gateway Interface Central Processing Unit Dynamic Name System Distributed Resource Management API Elastic Compute Cloud First In First Out Fully Qualified Domain Name Gnu is not Unix Graphical User Interface Hewlett Packard UniX High Throughput Computing Hypertext Transport Protocol International Business Machines Corporation Java Management extension Java Runtime Environment Lesser General Public License Load Sharing Facility Megabyte Megaherz Message Passing Interface Message Passing Interface Chameleon National Aeronautics and Space Administration Offene Handelsgesellschaft

8 VI Abkürzungsverzeichnis P2PGrid PBS PDA PHP RPC SMS SMTP VM VOS Peer-to-Peer Grid Portable Batch System Personal Digital Assistant PHP Hypertext Preprocessor Remote Procedure Call Short Message Service Simple Mail Transfer Protocol Virtual Machine Villingen Optical Storage

9 1 Einleitung 1 1. Einleitung 1.1. Motivation Die vorliegende Arbeit wurde im Rahmen eines Semesterprojekts erstellt und behandelt das Thema Windows Desktop Grid, welches von der Firma Deutsche Thomson OHG [1] gestellt wurde. Die Firma Deutsche Thomson OHG forscht an der Entwicklung von holografischen Speichern, deren Simulation sehr rechenintensiv ist. Die Aufgabe der Studenten war es die Möglichkeiten im Bereich Grid-Computing unter Microsoft Windows zu untersuchen und eine Infrastruktur auszuwählen und zu implementieren, die es erlaubt, rechenintensive Aufgaben (Jobs) und dazugehörige Daten auf Desktops zu verteilen. Eine weitere Anforderung an das Grid-System war, dass ausschließlich nicht genutzte Ressourcen auf verschiedener Arbeitsstationen zur Berechnung verwendet werden sollten so, dass der reguläre Arbeitsbetrieb unbeeinträchtigt blieb Was ist ein Windows Desktop Grid Ein Windows Desktop Grid ist ein Verbund von regulären Arbeitsstationen, auf denen das Betriebssystem Microsoft Windows zum Einsatz kommt. Dabei werden die Ressourcen dieser Rechner nur dann genutzt, wenn diese gerade nicht gebraucht werden, so dass der normale Benutzerbetrieb unbeeinträchtigt bleibt. Der Aufbau eines solchen Grids besteht im Normalfall aus drei verschiedenen Rollen: dem Client oder auch Submitter genannt, der eine Vielzahl an Jobs zur Bearbeitung absendet, einem Gateway, das für die Verteilung der Jobs verantwortlich ist und mehreren Worker Nodes, die die Abarbeitung der Jobs übernehmen. Ein Beispiel für den Aufbau eines Grids ist in Abbildung 1 dargestellt.

10 2 1 Einleitung Abbildung 1: Gridaufbau 1.3. Übersicht der untersuchten Frameworks Zu Beginn des Projektes wurde, aufgrund der von der Firma Thomson gestellten Anforderungen, nach Gridsystemen gesucht, bei denen zumindest die Worker Node Software auf einer Windows-Plattform (ab Microsoft Windows 2000) installiert werden konnte. Des Weiteren wurde ein Kriterienkatalog erstellt, anhand dessen die folgenden Gridysteme untersucht und bewertet wurden: Alchemie [2] BOINC [3] Condor [4] Globus Toolkit [5] GridGain [6] H2O [7] P2PGrid [8] SZTAKI [9]

11 1 Einleitung 3 UNICORE [10] WinGrid [11] XtremWeb [12] Bei einigen dieser Systeme stellte sich bereits frühzeitig heraus, dass sie den gestellten Anforderungen nicht gerecht werden konnten. Gründe für die vorzeitige Aussonderung dieser Systeme sind, dass wie z.b. im Fall von H2O, XtremWeb oder Alchemi die aktuellsten Releases bereits einige Zeit zurückliegen (Zeitraum größer als ein Jahr) und es seitdem keine erkennbare Betreuung der Systeme gab, der Internetauftritt schlecht gepflegt und/oder der Support zur Software, in Form von Mailinglisten oder Foren, gar nicht oder nur dürftig vorhanden war. Bei anderen Systemen wie beispielsweise WinGrid stellte sich heraus, dass sie ausschließlich kommerziell nutzbar sind. Da es durch die gestellten Anforderungen vorgegeben war, ein Windows Desktop Grid zu finden, welches frei zugänglich (also Open Source) ist, konnten solche Systeme von vornherein ausgeschlossen werden. Schlussendlich stellten sich BOINC, Condor und GridGain als die am vielversprechendsten Kandidaten, in Bezug auf Stabilität, Produktpflege und Support durch die Community, heraus. Diese drei Systeme werden im nächsten Kapitel genauer beschrieben.

12

13 2 Vergleich der Frameworks 5 2. Vergleich der Frameworks 2.1. Auswahlkriterien Für die bessere Bewertung der zu untersuchenden Gridsysteme wurde eine Liste mit Kriterien aufgestellt, die es ermöglicht die einzelnen Systeme besser zu vergleichen. MPI-Fähigkeit Das Message Passing Interface [13] (MPI) beschreibt den Nachrichtenaustausch bei parallelen Berechnungen. Programmiermodell Wie wurde das Gridsystem programmiert, z.b. nach einem Client/Server- Modell? Installationsaufwand/Administrationsaufwand Wie hoch ist der Aufwand für das Deployment des Gridsystems und wie hoch ist der abschätzbare Administrationsaufwand? Wartbarkeit Wie schwer oder leicht lassen sich Updates einspielen und wie hilfreich ist die Community (Mailinglist, Forum... ) bei eventuell auftretenden Problemen? Überwachbarkeit (Statistik, Log-Datei-Handling,... ) Bietet das Gridsystem einen Überblick über die abgeschickten Jobs oder sieht man welche Worker Nodes einen Job bearbeiten? Bietet das System eine Möglichkeit, Nutzungsdaten die beim Betrieb anfallen statistisch auszuwerten? Handling von Instabilen Knoten Wie wird vorgegangen wenn ein Worker Node während der Berechnung abstürzt oder wie wird ein Worker behandelt der oft ausfällt?

14 6 2 Vergleich der Frameworks Job-Scheduler/Resource Broker Intelligenz Wird bei der Verteilung auf die Auslastung der einzelnen Worker geachtet oder werden die Jobs gleichmäßig auf diesen verteilt? Sicherheit In wie weit ist das Grid gegen die Einschleusung falscher Ergebnisse abgesichert? Bietet das System eine Möglichkeit zur Authentifizierung oder können neue Worker ohne Hindernisse hinzugefügt werden? Einfluss auf den normalen Nutzerbetrieb Gibt es Einstellungsmöglichkeiten um den normalen Nutzerbetrieb nicht zu behindern, d.h. es werden nur Ressourcen verwendet, die anderweitig brach liegen würden? Bedienungskomfort Wie komfortabel ist das Handling und die Bedienung des Gridsystems? Leistung Informationen über die Performance bei der Jobverteilung und bei der Anmeldung der einzelnen Worker am Gateway. Entwicklungsstand Wie hoch ist die Stabilität des Gridsystems einzuschätzen? Datenhandling Wie werden die Daten vom Gateway zum Client geschickt oder werden diese auf einem zentralen Netzlaufwerk abgelegt? Open Source Unter welcher Lizenz steht das Gridsystem? Dokumentation Wie ausführlich, verständlich und aktuell ist die Dokumentation?

15 2 Vergleich der Frameworks 7 Accounting Gibt es die Möglichkeit zu ermitteln, welche Worker Nodes am effektivsten arbeiten? User-Accounting Können die einzelnen User anhand der Ergebnisse bewertet werden? Schnittstellen (Inter-Cluster-Communication) Gibt es Schnittstellen zu anderen Gridsystemen oder Toolkits (Global Toolkit)? Systemanforderungen Welche Systemanforderungen werden an die einzelnen Rechner und Rollen (Gateway, Submitter, Worker Node) gestellt? zukaufbarer Support Kann professioneller Support durch einen Dienstleister zugekauft werden? 2.2. Auswahlprozess bei Frameworks In diesem Abschnitt werden die drei Gridsysteme BOINC [3] GridGain [6] Condor [4] anhand des Kriterienkataloges genauer beschrieben und bewertet BOINC BOINC [3] (Berkley Open Infrastructure for Network Computing) ist ein Gridsystem, das an der Universität Berkeley [14] entwickelt wird und die Möglichkeit

16 8 2 Vergleich der Frameworks bietet zehntausende Computer, über das Internet verteilt, an einer großen Aufgabe rechnen zu lassen. Dabei muss ein Benutzer lediglich eine Clientsoftware installieren. In dieser kann er dann aus verschiedenen wissenschaftlichen Projekten wählen und von diesen Teilberechnungen durchführen. Deshalb bietet BOINC mehrere Arten von Replikation, um falsche Ergebnisse zu eliminieren. MPI-Fähigkeit Zur Zeit nicht vorhanden Programmiermodell BOINC ist nach dem Master-Worker-Modell aufgebaut, wobei der Master die Jobs verteilt und die Worker zur Berechnung benötigt werden. Der genaue Aufbau von BOINC ist in Abbildung 2 dargestellt und wird im folgenden Abschnitt genauer beschrieben. Der Server besteht aus einer MYSQL-Datenbank, die zur Speicherung von Daten des Projektes benötigt wird, einem Scheduler der periodisch die verschiedenen Daemons ausführt, die für die Verteilung der Jobs benötigt werden. Dazu wird noch eine Web-Site (PHP) mitgeliefert, die die Daten aus der Datenbank grafisch aufbereitet und in der projektspezifischen Web-Site darstellt. Das Backend, dass durch den Work Generator dargestellt wird ist für die Bereitstellung der Jobs zuständig und bereitet diese auf, bevor die Jobs verteilt werden. Der letzte Bestandteil der Serverseite ist die Science Application, die die Berechnung auf dem Worker Node ausführt, wenn diese noch nicht auf dem Worker Node vorhanden ist wird sie auf diesen kopiert. Auf dem Worker Node läuft nur die Clientsoftware, die die Science Application und somit die Berechnung startet. Insallationsaufwand/Administrationsaufwand Server Der Betrieb eines BOINC Projekt-Servers ist derzeit nur unter Un-

17 2 Vergleich der Frameworks 9 Abbildung 2: BOINC Architektur ix/linux praktikabel. Das BOINC Projekt liefert ein VMWare-Image aus, auf dem sich ein lauffähiges System (Debian GNU/Linux und die BOINC-Serversoftware) befindet. Aus Performancegründen sollte jedoch auf den Einsatz dieses VM-Images verzichtet werden. Die serverseitige Installation gestaltet sich sehr umfangreich. Neben der Installation der Projektsoftware an sich, ist die anschließende Konfiguration der einzelnen Komponenten (Web-Site mit Apache Server, MySQL Datenbank... ) sehr umfangreich. Die Installationsdokumentation ist an manchen Stellen nicht ausreichend bzw. nicht aktuell. Deshalb wurde im Rahmen dieses Projekts ein aktuelles Howto für die

18 10 2 Vergleich der Frameworks Installation unter Debian GNU/Linux angefertigt. Client Auf Linux-Clients gibt es bei den meisten Distributionen Pakete, wobei auf die Version geachtet werden muss, da nicht immer die aktuellsten vorhanden sind. Die Installation der Clientsoftware unter Microsoft Windows ist ungleich einfacher. Hier genügt es den Installeranweisungen zufolgen und am Ende ein Benutzerkonto im Projekt zu erstellen. Über den BOINCManager bzw. BOINCView können die Clients mittels einer GUI und RPC verwaltet werden. Wartbarkeit Bei der Wartbarkeit muss in zwei Kategorien unterschieden werden, die Wartbarkeit der Science Applikation ist sehr einfach, da sich der Client die aktuellste Version vom Master lädt, sobald eine neuere verfügbar ist. Die Clientsoftware hingegen muss ersetzt werden, was jedoch über die oben beschrieben Kombination auch keinen enormen Aufwand darstellen dürfte. Überwachbarkeit (Statistik, Log-Dateien-Handling,...) Für die Überwachbarkeit werden die Statistiken in der Datenbank abgelegt, jedoch wurde während der Evaluation noch kein Tool gefunden das diese Daten grafisch aufbereitet. Eventuell können die Statistiken durch das Webinterface dargestellt werden. Es bieten sich jedoch auch noch Möglichkeiten durch Add-Ons. Handling von Instabilen Knoten Da BOINC ursprünglich für das verteilte Rechnen im Internet geplant war werden die gleichen Jobs immer auf mehrere Worker verteilt, da es sein kann das ein Worker das Ergebnis nicht zurück schickt. Ein weiterer Vorteil ist, dass die Ergebnisse verglichen werden können um so falsche Ergebnisse zu eliminieren.

19 2 Vergleich der Frameworks 11 Job-Scheduler/Resource Broker Intelligenz Muss projektspezifisch selbst entwickelt werden. Sicherheit BOINC verhindert unautorisierten Zugriff auf einen Pool und verhindert durch Verschlüsselung, dass die Daten während der Übertragung von dritten gelesen werden können. Einfluß auf den normalen Nutzerbetrieb Die Einstellungen lassen sich durch den BOINCManager (Bestandteil der BOINC Clientsoftware) sehr leicht und vor allem detailliert einstellen, so dass jeder Benutzer die passende Konfiguration für sich findet. Bedienungskomfort BOINC kann je nach Wunsch über die Shell oder über ein GUI gesteuert werden. Performance Die Kommunikation zwischen Master und Worker Node wird über das CGI abgewickelt und könnte in Bezug auf die Skalierbarkeit problematisch sein, jedoch dürfte die Übertragung der Nutzdaten keine Probleme darstellen. Entwicklungsstand Die aktuelle Version von BOINC ist Version 6.4.5, durch dies und da die Software bereits seit vielen Jahren für große Projekte (wie z.b. verwendet wird, ist eine hinreichende Stabilität gegeben. Datenhandling Die Ergebnisse werden auf dem Master in dem Projektverzeichnis $project root/upload/ in eindeutig gekennzeichneten Verzeichnissen, für die jeweiligen Jobs, abgelegt.

20 12 2 Vergleich der Frameworks Open Source Die BOINC Software steht unter der LGPL (Lesser General Public License) [15]. Dokumentation Es existieren zwar etliche Wikis jedoch ist die Dokumentation an vielen Stellen recht dürftig und nicht immer auf dem aktuellsten Stand, weshalb viele Informationen durch das Studium von Source-Code und Makefiles erarbeitet werden mussten. Accounting Es kann für jeden Worker Node eine Statistik geführt werden, die das Rechnerverhalten (z.b. verbrauchte CPU-Zeit, Güte der Ergebnisse die ein Worker Node liefert,... ) speichert. Diese Daten können dann über Zusatzsoftware für BOINC ausgewertet werden. User-Accounting Da die Teilnahme an einem Projekt User bezogen ist, kann ein jeder User anhand seiner Anmeldung und gelieferten Ergebnissen bewertet werden. Schnittstellen (Inter-Cluster-Communication) Am Ende der Evaluierung waren keine Schnittstellen verfügbar. Systemanforderungen Server Die benötigten Ressourcen kommen sehr stark auf die Größe des Projekts an. So kann es bei einem kleinen Projekt mit wenigen beteiligten Worker Nodes schon ausreichend sein, den Projektserver auf einer ausgedienten Arbeitsstation zu betreiben. Jedoch braucht man sehr schnell deutlich mehr Ressourcen, vor allem mit steigender größe der Ergebnisste (Festplattenspeicher).

21 2 Vergleich der Frameworks 13 Client Als eine mögliche Untergrenze für den Betrieb eines Worker Nodes kann man eine eine 500MHz CPU und ca. 512MB Arbeitsspeicher angeben. Festplattenspeicher hängt auch hier sehr von der Größe der Berechnungsergebnisse ab. zukaufbarer Support Am Ender der Evaluierung war kein professioneller, zukaufbarer Support bekannt GridGain GridGain [6] ist unter den untersuchten Gridsystem ein Außenseiter, da es zum einen erst 2005 veröffentlicht wurde und zum anderen in Java programmiert ist. Ein Motto der Entwickler ist, dass GridGain ein Gridsystem von Java-Entwicklern für Java-Entwickler ist. Bei den zuvor untersuchten Systemen war es meistens so, dass eine bestehende Aufgabe als Executable zur Verfügung stand, bei GridGain wird diese jedoch in das Programm direkt integriert. MPI-Fähigkeit GridGain unterstützt das MPI. Programmiermodell Wie schon erwähnt ist GridGain in Java realisiert und beruht auf dem von Google entwickelten Prinzip des Map/Reduce. Bei diesem Prinzip wird der Job in gleich große Aufgaben geteilt und jeder Worker berechnet einen Teil der Aufgabe. Die Verteilung der Teilaufgaben wird in Abbildung 3 durch Schritt 2 dargestellt. Danach werden die Teilergebnisse (Schritt 3) an den Sender zurückgeschickt. Wenn alle Ergebnisse eingetroffen sind, wird das Ergebnis zusammengefasst und weiterverarbeitet oder abgespeichert (Schritt 4), je nachdem was mit diesem vorgesehen ist.

22 14 2 Vergleich der Frameworks Abbildung 3: GridGain Architektur Wie in der Abbildung 3 zu sehen ist, gibt es keine Unterteilung in Gateway oder Worker, sondern der Rechner, auf dem der Job gestartet wird (Schritt 1) ist in diesem Fall das Gateway. Insallationsaufwand/Administrationsaufwand Die Installation ist sehr einfach, da es nur eine Installationsroutine gibt, jedoch läuft GridGain nicht automatisch als Deamon, dafür muss nachträglich noch der Java Service Wrapper installiert werden. Wartbarkeit Hierüber wurden keine Informationen gefunden. Überwachbarkeit (Statistik, Log-Dateien-Handling,...) Die einzelnen Rechner werden über JMX (Java Management Extension) überwacht und grafisch aufbereitet. Wenn Informationen über den Stand der Berechnung gesammelt werden wollen, muss dies vom Programmierer in den Job direkt integriert werden. Handling von Instabilen Knoten Wenn ein Rechner abstürzt der eine Berechnung ausführt, dann wird der

23 2 Vergleich der Frameworks 15 Job an einen anderen Rechner gesendet. Inwieweit der Job von neuem gestartet wird ist wiederum dem Programmierer überlassen, da dieser für das Einfügen von Checkpoints verantwortlich ist. Job-Scheduler/Resource Broker Intelligenz Die Jobs werden anhand von early and late load balancing auf den Rechnern verteilt. Dabei werden beim early load balancing die Informationen die zum Zeitpunkt der Verteilung zur Verfügung stehen die Jobs an die Rechner verteilt. Auf den einzelnen Rechnern befinden sich die noch nicht gestarteten Jobs in einer FIFO-Schlange, aus der beim late load balancing Rechner Jobs holen können wenn diese keine mehr in ihrer Schlange haben. Sicherheit Während der Evaluierungsphase wurden keine Informationen über die Sicherheit bei GridGain gefunden. Einfluß auf den normalen Nutzerbetrieb Inwieweit ein Job Einfluss auf den Nutzerbetrieb nimmt, kommt wiederum auf den Programmierer an, da dieser angegeben kann wann ein Rechner mit der Berechnung anfängt und welche Systemvoraussetzung dieser haben muss. Bedienungskomfort Der Bedienungskomfort ist für erfahrene Java-Entwickler sehr gut, wenn jedoch noch nicht so viel Erfahrung in Java vorhanden ist, ist die Bedienung etwas gewöhnungsbedürftig. Performance Die Performance wird anhand des early and late load balancing optimal ausgenutzt.

24 16 2 Vergleich der Frameworks Entwicklungsstand GridGain wird seit 2005 entwickelt und liegt zur Zeit in der aktuelle Version vor. Datenhandling Der Programmierer entscheidet wo die Ergebnisse gespeichert werden. Open Source GridGain ist unter der LGPL (Lesser General Public License) [15] und der Apache Lizenz 2.0 [16] lizenziert Dokumentation Die Dokumentation von GridGain ist sehr ausführlich und mit vielen Beispielen, wodurch ein schneller Einstieg gewährleistet ist. Alle Dokumentationen wie Screencast befinden sich unter Accounting GridGain besitzt kein Accounting. User-Accounting GridGain besitzt kein User-Accounting. Schnittstellen (Inter-Cluster-Communication) Am Ende der Evaluierungsphase gab es für GridGain noch keine Schnittstellen. Systemanforderungen Die einzige Anforderung die GridGain stellt, ist das Java 1.5 oder höher verfügbar sein muss. zukaufbarer Support GridGain bietet drei verschiedene Arten von Support, wobei zwei davon kostenpflichtig sind.

25 2 Vergleich der Frameworks Condor Condor [4] wurde 1988 an der University of Wisconsin [17] herausgebracht und seit dem kontinuierlich weiterentwickelt. MPI-Fähigkeit Die MPI-Fähigkeit wird durch das MPI Universum gewährleistet, wobei dieses Universum in folgenden Versionen durch das parallele Universum ersetzt wird, was jedoch keinen Einfluss auf MPI hat. Programmiermodell Abbildung 4: Condor Architektur Bei Condor gibt es drei verschiedene Rollen, die ein Rechner einnehmen kann, diese sind der Submitter welcher die Jobs abschickt, der Central Manager oder auch Gateway welcher für die Verteilung der Jobs zuständig ist und die Resource Machine oder auch als Worker Node bezeichnet, die die Berechnungen durchführt. Die unterschiede der einzelnen Rollen sind in Abbildung 4 dargestellt. Für alle drei Rollen gibt es nur eine Installationsroutine, in der an einer Stelle entschieden werden muss welche Rolle der Rechner einnimmt. Dies wird im Abschnitt Condor-Installation noch genauer erläutert.

26 18 2 Vergleich der Frameworks Da alle drei Rollen die gleiche Installationsroutine durchlaufen unterscheiden sie sich nur in den Condor-Prozessen die gestartet werden, was wiederum durch den Master-Prozess gesteuert wird. Dieser Prozess liest die Konfigurationsdatei ein und entscheidet anhand dieser welcher Prozess gestartet werden soll und welcher nicht. Das führt dazu dass ein Rechner auch nach der Installation noch die Rolle wechseln oder sogar mehrere Rollen einnehmen kann. Insallationsaufwand/Administrationsaufwand Durch die einheitliche Installationsroutine ist der Installationsaufwand nicht sehr hoch, was auch durch die Batch-Datei für die Unattended-Installation, die für das Projekt geschrieben wurde, gezeigt wurde. Jedoch kann es sein, das je nach Rolle noch ein paar Änderungen in der Konfigurationsdatei vorgenommen werden müssen. Eine detaillierte Installationsanleitung befindet sich in Abschnitt 4. Wartbarkeit Die Wartbarkeit von Condor ist nicht sehr schwer, da bei allen drei Rollen die gleiche Konfigurationsdatei vorhanden ist und diese sehr gut Kommentiert ist. Jedoch wenn eine neue Version eingespielt werden soll, muss dies an jedem Rechner separat gemacht werden und kann je nach Anzahl der Rechner einige Zeit in Anspruch nehmen. Überwachbarkeit (Statistik, Log-Dateien-Handling,...) Condor bietet die Möglichkeit Ereignisse in Log-Dateien schreiben zu lassen um somit Probleme bei der Ausführung eines Jobs zu erkennen. Es kann sogar in der Konfigurationsdatei eine -Adresse festgelegt werden, an die eine geschickt wird wenn ein Fehler auftritt. Handling von Instabilen Knoten Es wird eine Möglichkeit geboten, die in periodischen Abstünden einen

27 2 Vergleich der Frameworks 19 Checkpoint von dem kompletten Job erstellt und diesen an das Gateway schickt für den Fall das der Worker abstürzt oder die Berechnung des Jobs abbricht. Jedoch ist dies unter Windows nicht möglich, daher werden die Jobs auf einem anderen Worker neu gestartet, falls ein Worker Node ausfällt. Job-Scheduler/Resource Broker Intelligenz Die Intelligenz des Job-Schedulers ist durch die jahrzehntelange Entwicklung von Condor sehr ausgereift. Es können Startzeitpunkte für den Beginn eines Jobs festgelegt werden, den einzelnen Jobs können Prioritäten zugewiesen werden, wodurch sich die Reihenfolge verändern kann. Es können aber auch ClassAdds definiert werden in denen angegeben wird, welche Systemvoraussetzungen ein Worker haben muss um diesen Job berechnen zu dürfen. Sicherheit Condor verhindert unautorisierten Zugriff auf einen Pool und verhindert durch Verschlüsselung, dass die Daten während der Übertragung von dritten gelesen werden können. Einfluß auf den normalen Nutzerbetrieb Auf dem Worker kann durch die Konfigurationsdatei sehr genau festgelegt werden, wann der Worker für Berechnungen zur Verfügung steht und wann nicht. Wenn der Worker während einer Berechnung, z.b. durch bewegen der Maus unterbrochen wird, wird der Job angehalten und erst fortgesetzt wenn die Voraussetzungen für die Fortführung der Berechnung erfüllt sind. Wenn der Worker heruntergefahren wird, wird der Stand der Berechnung abgespeichert und nach dem Start fortgesetzt.

28 20 2 Vergleich der Frameworks Bedienungskomfort Condor lässt sich ausschließlich über die Konsole und über die vorbildlich dokumentierte Konfigurationsdatei bedienen. Performance Nach dem Start des Gateways kann es bis zu 15 Minuten dauern bis sich alle Worker und Submitter am Gateway angemeldet haben und es kann auch dazu kommen, dass bis zu beginn eines Jobs 5-10 Minuten vergehen ehe dieser abgeschickt wird. Entwicklungsstand Durch den langen Einsatz von Condor, Projektstart 1988, ist die Software sehr ausgereift und somit sehr stabil. Datenhandling Die Ergebnisse können in einer Datei, die in der Submit-File angegeben werden muss, gespeichert werden. Open Source Apache Lizenz, Version 2.0 [16] Dokumentation Die Dokumentation von Condor ist sehr umfangreich und besteht aus über 1000 Seiten. Das Handbuch zur Version ist auf der beigelegten CD enthalten. Darüber hinaus gibt es auch Foren und Mailing-Lists. Vor allem auf der Mailing-List kommt man sehr schnell an mögliche Lösungen für auftretende Probleme. Accounting Das Accounting bei Condor bezieht sich speziell auf das User-Accounting, welches im folgenden Abschnitt beschrieben ist.

29 2 Vergleich der Frameworks 21 User-Accounting User Accounting wird von Condor unterstützt, da jeder Benutzer durch domain registriert ist. Dabei wird einerseits bewertet wie lange der Worker berechnet und andererseits wie viele Jobs dieser berechnet hat. Anhand dieser Bewertung werden bessere User bei neuen Jobs bevorzugt. Schnittstellen (Inter-Cluster-Communication) Condor bietet mehrere Schnittstellen zu anderen Gridsystemen und wird am häufigsten mit dem Globus Toolkit zusammen verwendet. Weitere Schnittstellen gibt es zu NorduGrid, BOINC, Unicore, PBS, LSF und EC2. Systemanforderungen Für den Einsatz unter Windows muss mindestens Windows2000 installiert sein und es sollten noch 300MB auf der Festplatte vorhanden sein. Wenn das Java Universum verwendet werden soll muss eine Java Virtuelle Maschine verfügbar sein. zukaufbarer Support Condor bietet einen kostenlosen und einen kostenpflichtigen Support an Gründe gegen BOINC und GridGain Gründe gegen BOINC Gegen BOINC sprach schlussendlich hauptsächlich die Tatsache, dass zumindest der Gateway auf einem Unix/Linux-basierten Betriebssystem installiert werden musste, was der Firmenpolitik der Deutschen Thomson OHG widerspricht. Des Weiteren wurde es für die Nutzung über das Internet entwickelt, was die Verteilung der Aufgaben über das HTTP-Protokoll erklärt. Dies ist für ein internes Netzwerk allerdings nicht wirklich sinnvoll.

30 22 2 Vergleich der Frameworks Gründe gegen GridGain GridGain ist zwar ein sehr mächtiges Middleware-Framework für Grid Systeme, allerdings nur wenn man unter JAVA entwickelt. Da bei der Deutschen Thomson OHG bevorzugt mit C und C++ arbeitet, schied dieses Grid-System auch aus Zusammenfassung der Frameworks In diesem Abschnitt werden die einzelnen Frameworks nochmal in einer Tabelle gegenüber gestellt um einen direkten Vergleich zu haben. Kriterien BOINC Condor GridGain MPI-Fähigkeit Nein Ja Ja Programmiermodell Master- Submitter, all in one Worker Gateway und Worker Installations- hoch niedrig mittel /Administrationsaufwand Wartbarkeit gut gut unzureichend Überwachbarkeit Statistikdaten an JMX (Java verfügbar, Admin bei Fehler, Management Extension keine grafische AddOns Darstellung verfügbar Handling von instabilen Job wird an unter Windows Job wird an Knoten mehrere Worker kein anderen Wor- gesendet Handling ker gesendet