Universität Paderborn Fakultät EIM I. Seminar zur Projektgruppe Do-It-Yourself Supercomputer: Der upb.de Computer. Prof. Dr.

Transkript

1 Universität Paderborn Fakultät EIM I Seminar zur Projektgruppe Do-It-Yourself Supercomputer: Der upb.de Computer Prof. Dr. Odej Kao Grundlagen der SUN Grid Engine Wilke Hagelweide wilkeh@uni-paderborn.de 29. November 2003

2 Inhaltsverzeichnis 1. Einleitung Motivation Distributed Ressource Management Geschichtliche Entwicklung der SUN Grid Engine Sun Grid Engine Grundlegende Funktionalität Systemanforderungen Struktur und übergeordnete Architektur Bearbeitung eines Jobs (Job Execution Cycle) Nutzung der Sun Grid Engine User Interface Software Integration Standard Edition und Enterprise Edition Einsatzbereich Funktionalität Zusammenfassung Mögliche Anwendung in der Projektgruppe Fazit und Ausblick Anhang Anhang A: Features der Sun Grid Engine Anhang B: Abkürzungsverzeichnis Anhang C: Literaturverzeichnis Abbildungsverzeichnis Abbildung 1: Vorteil der Nutzung der Sun Grid Engine... 2 Abbildung 2: SGE als Middleware... 3 Abbildung 3: SGE in einer heterogenen Systemumgebung... 4 Abbildung 4: Three-Tier-Architektur und Hosttypen der SGE... 6 Abbildung 5: Daemons und Queues auf verschiedenen Hosts... 8 Abbildung 6: Prinzip der Bearbeitung eines Jobs... 9 Abbildung 7: Job Flow der SGE...10 Abbildung 8: QMON Main Menu - grafische Oberfläche der SGE...11 Abbildung 9: Einsatzbereiche der SGE Standard und Enterprise Edition..12 Abbildung 10: Vergleich der Job Flows beider Editions der SGE...13

3 1. Einleitung 1.1. Motivation Die heutige Zeit ist gekennzeichnet durch immer leistungsfähigere vernetzte Rechnersysteme und die geringe Nutzung der vorhandenen Resourcen durch Anwendungen wie Textverarbeitung, oder Browser. Rechnersysteme sind dadurch nur zu Bruchteilen ausgelastet, obwohl sie für rechenintensive Anwendungen wie Multimedia oder Simulationen eingesetzt werden könnten. Um die vorhandenen, brachliegenden Resourcen einer Nutzung zuzuführen, wird die Sun Grid Engine (SGE) von Sun Microsystems eingesetzt. Sie übernimmt als Grid Management Software Aufgaben im Bereich des Workload Managements und des Distributed Resource Managements. Dies bedeutet, dass im Netzwerk vorhandene Hardwareund Softwareresourcen durch den Einsatz der Software optimiert ausgenutzt werden: Abbildung 1: Vorteil der Nutzung der Sun Grid Engine 1.2. Distributed Ressource Management Distributed Resource Management (DRM) ist ein IT-Konzept, das verschiedene Aufgaben im Bereich des Managements von Hardware- und Softwareresourcen vernetzter Rechnersysteme zusammenfasst. DRM umfasst Funktionalität im Bereich des Load Balancing, Job Accounting sowie des Monitorings (Beobachten und Überwachen), die auch zentrale Bestandteile für die Sun Grid Engine als DRM-Software sind. Die Basis für die Sun Grid Engine ist das sog. Batch Queuing : Anwender geben einen Rechenauftrag (Job) an die SGE, diese wählt aus den Rechnersystemen, die den Anforderungen des Auftrags entsprechen, das am besten geeignete System aus und leitet den Auftrag an dieses weiter. Sind die benötigten Resourcen - 2 -

4 zur Bearbeitung eines Auftrags nicht verfügbar, so bleibt der Job so lange in einer Warteschlange eingereiht, bis die benötigten Resourcen verfügbar sind. Damit wird die Auslastung der Rechnerlandschaft und die Effizienz dieser erhöht Geschichtliche Entwicklung der SUN Grid Engine Die Basis der Sun Grid Engine wurde zu Beginn der 90er Jahre durch die Firma Genias unter Leitung von Dr. Wolfgang Gentzsch gelegt. Im Jahr 1992 wurde von ihm der Prototyp von CODINE, eine Software für DRM vorgestellt, die bis 1999 in Projekten wie Unicore, Autobench und Medusa weiterentwickelt wurde firmierte die Firma Genias in Gridware um, Schnittstellen zu anderen Grid Systemen wie Globus wurden entwickelt. Nach dem Kauf der Firma Gridware durch Sun Microsystems im Juli 2000 wurde CODINE in Sun Grid Engine umbenannt, weiterentwickelt und Version 5.2 im September 2000 veröffentlicht. Zu Beginn des Jahres 2001 wurde die Sun Grid Engine 5.2 für Linux vorgestellt. Im Juli 2001 entschloss sich Sun, die Grid Engine als Open-Source-Projekt weiterzuführen. Im Juni 2002 wurden die Sun ONE Grid Engine und die Sun ONE Grid Engine Enterprise Edition in der Version 5.3 in das Sun ONE Studio integriert und veröffentlicht, die den aktuellen Stand der Entwicklung darstellen. 2. Sun Grid Engine Die Sun Grid Engine ist als DRM-Software zwischen der Betriebssystem- Ebene und der Applikations-Ebene anzusiedeln. Die Software stellt Schnittstellen für die User (Benutzer, Administrator) sowie für die Integration in andere Grid-Systeme bereit. User Interface ( Single Point of Entry ) User Interface Applikationen API Grid Middleware Globus Toolkit, Avaki Applikationen, Schnittstellen Sun Grid Engine Standard bzw. Enterprise Edition 5.3 DRM-Ebene Linux, Solaris, HP-UX, IRIX, AIX Betriebssystem-Ebene Rechnersysteme auf Basis der Inteloder Sparc-Architektur Hardware-Ebene Abbildung 2: SGE als Middleware - 3 -

5 Die Software kann auf jeder Art von Computer eingesetzt werden auf Desktops, Servern und in Rechenzentren. Dabei müssen keine Veränderungen an Programmen vorgenommen werden, die auf der SGE ausgeführt werden. Im folgenden Diagramm soll der flexible Einsatz der Software illustriert werden, hierzu ist ein Blick auf die Systemarchitektur der Sun Grid Engine hilfreich (detaillierte Informationen zur Systemarchitektur siehe Kapitel 2.3). Abbildung 3: SGE in einer heterogenen Systemumgebung Die Hauptaufgabe der SGE ist es, die verfügbaren Resourcen mit den Anforderungen der Aufgaben (Jobs) abzustimmen. Es können sequentielle, parallele und interaktive Jobs von der SGE bearbeitet werden. Die Jobs werden nach Submission bei Verfügbarkeit der benötigten Resourcen direkt geschedult und an den bearbeitenden Rechner weitergeleitet. Sind die geforderten Resourcen nicht verfügbar, so wird der Job in einer Holding Area zwischengelagert, bis die Resourcen verfügbar sind und der Job bearbeitet werden kann. Die interne Struktur der SGE besteht im Wesentlichen aus vier Elementen: Daemons, die Jobs aus verschiedenen Queues auf verschiedene Hosts verteilen und bearbeiten Grundlegende Funktionalität Die SGE stellt neben der DRM-Funktionalität, die im Kapitel 1.2 kurz erklärt wurde, weitere Funktionalität bereit, die grundlegende Funktionalität soll in diesem Kapitel kurz erläutert werden. Load Balancing (Lastverteilung) stellt sicher, dass keine Resource eines Hosts überlastet ist. Die SGE gleicht Last aus, indem sie auf Basis von Informationen, z.b. Resourcenauslastung, aktuell bearbeiteten Aufträgen oder ähnlichem entscheidet, auf welcher Ressource bzw. auf welchem Host der nächste Auftrag ausgeführt wird

6 Durch die Bereitstellung eines Checkpointing-Mechanismus, der den aktuellen Stand der Berechnung (Speicherabbild, bisherige Ergebnisse) sichert, kann die Berechnung eines Jobs ausgesetzt bzw. fortgesetzt werden. Auch ist es möglich, den Job auf ein anderes Rechnersystem umzuziehen, das für die Berechnung besser geeignet ist (Job Migration). Die Funktionalität des Aussetzen bzw. Fortsetzen einer Berechnung bietet einen weiteren Lastausgleich für den Fall, das ein Rechnersystem überlastet ist, wenn der dispatchte Job beginnt, Resourcen zu verbrauchen, die er während des Schedulings bzw. Dispatchings nicht konsumiert. Eine weitere Eigenschaft der SGE ist Fehlertoleranz bzw. Ausfallabsicherung: Fällt ein Host während der Bearbeitung eines Jobs aus, so wird dieser Auftrag als nicht beendet erkannt und kann hierdurch erneut zur Bearbeitung eingeplant und bearbeitet werden. Auch ist ein Shadow Master Host vorgesehen, der die Funktionalität des Master Hosts übernimmt, falls dieser ausfallen sollte. Die SGE stellt Administratoren und Benutzern Informationen über den Status von Hosts und Jobs zur Verfügung: Der Benutzer kann Informationen zum Status der Hosts und zu seinen Jobs abrufen. Hierzu senden die Execution Hosts Informationen über die sich derzeit in Bearbeitung befindenden Jobs an den Master Host, der diese den Benutzern zur Verfügung stellt, so dass die Bearbeitung des Jobs verfolgt werden kann. Auch sind Daten über die sich noch nicht in Bearbeitung befindenden sowie die schon berechneten Jobs und deren Ergebnisse abrufbar. Die Administratoren der SGE können Resourcen individuell spezifizieren, z.b. Hauptspeicher, CPU, Softwarelizenzen oder Auslastungsparameter. Resourcen, die nicht an einen Host gebunden sind, wie z.b. Softwarelizenzen, können als sog. Cluster-wide-Resources auf allen Rechnersystemen eingesetzt werden, auf denen die SGE eingesetzt wird. Auch können viele gleichartige Jobs, die sich nur sehr wenig unterscheiden, wie z.b. Video-Konvertierung, bei der ein Video in kleine Pakete aufgeteilt wird und die Pakete einzeln zur Bearbeitung aufgegeben werden, auf einmal zur Bearbeitung aufgegeben werden. Diese Fähigkeit wird als Meta-Job Capability bezeichnet Systemanforderungen Der Einsatz der SGE erfordert die Erfüllung von Systemanforderungen, die sich beschränkend auf das Einsatzgebiet der SGE auswirken. Die Anforderungen lassen sich in Hardware- Software und Netzwerkanforderungen untergliedern: Der Einsatz der aktuellen Version der SGE ist auf den gängigen Hardwareplattformen x86, Sparc, Opteron, Itanium sowie Apple möglich und erfordert den Einsatz eines der folgenden Betriebssysteme: Solaris (Version 2.6 bis 9.0), Linux (Linux-Kernel ab Version 2.4), MAC OS/X, AIX, HP-UX und IRIX. Eine Version der SGE für Betriebssysteme der Firma Microsoft ist nicht verfügbar

7 Die Rechner, auf denen die SGE eingesetzt werden soll, müssen untereinander vernetzt sein und mit der Netzwerkprotokollfamilie TCP/IP arbeiten. Dabei ist im Besonderen der TCP-Port 535 zu nennen, über den die SGE in Standardkonfiguration die Kommunikation abwickelt. Auch werden Anforderungen an die Benutzerverwaltung gestellt, über die die Zugriffskontrolle realisiert ist. Die Benutzernamen und rechte müssen auf dem Submit- und Execution-Host identisch sein um eine Bearbeitung der Jobs zu ermöglichen Struktur und übergeordnete Architektur Die für die SGE benötigte Rechner- und Netzwerkarchitektur entspricht der Standardarchitektur für Cluster Grids, einer sog. Three-Tier- Architektur mit Access Tier, Management Tier und Compute Tier. Die Architektur der SGE besteht aus vier Hosttypen (Submit Host, Administration Host, Master Host und Execution Host), die in diesem Kapitel kurz erklärt und den einzelnen Tiers zugeordnet werden. Abbildung 4: Three-Tier-Architektur und Hosttypen der SGE Die Systeme des Access Tiers bieten Anwendern und Administratoren Zugriff und Authentisierung zur Benutzung des Systems. Dabei kann sowohl per ssh oder telnet, als auch über webbasierte Services auf die Infrastruktur zugegriffen werden. Authentisierung erfolgt über gängige Verfah

8 ren wie LDAP, Kerberos oder NIS. Auch können zusätzliche Services wie Analyse oder Abrechnung in das System integriert werden. Bezogen auf die SGE sind in diesem Tier zwei Hosttypen zu finden: Über einen Submit Host werden Jobs vom Anwender an die SGE gegeben sowie der Status der Jobs überwacht und kontrolliert. Von einem Administration Host werden administrative Tätigkeiten durchgeführt, wie z.b. die Änderung oder Anpassung der Konfiguration, Hinzufügen neuer Hosts, etc. Auf den Systemen des Management Tiers ist die steuernde Funktionalität realisiert: Hier ist die serverseitige Software installiert, also die DRM- Software, die Diagnosesoftware und die Systemauslastungsüberwachungssoftware. Darüber hinaus enthält das Management Tier auch Systeme, die File Services, z.b. NFS, oder License Services bereitstellen. Im Management Tier ist der Master Host der SGE angesiedelt, der zentrales System der SGE ist. Der Master Host kontrolliert und überwacht über den Master Daemon und den Scheduling Daemon alle Komponenten der SGE, also alle Queues, Jobs und Status von Zugriffsrechten, etc. Der Master Host kann gleichzeitig auch Administration und Submit Host sein. Im Compute Tier sind die Compute Nodes zu finden, die Rechenresourcen für das Berechnen von Jobs bereitstellen. Auf den Compute Nodes ist die clientseitige DRM-Software installiert. Auf die SGE bezogen sind im Compute Tier die Execution Hosts der SGE angesiedelt, die mit Hilfe des Execution Daemon Jobs bearbeiten. Zusätzlich zu den vier Hosttypen verfügt die SGE über einen Shadow Master Host. Dieser übernimmt im Falle eines Ausfalls des Master Hosts dessen Funktionalität. Vorraussetzung zur Übernahme der Funktionalität des Master Hosts durch den Shadow Master Host ist, das beide Hosts über die gleiche Informationsbasis verfügen. Durch den Einsatz des Shadow Master Hosts wird eine höhere Ausfallsicherheit und Verfügbarkeit sichergestellt und Aufgaben im Falle eines Ausfalls automatisch und transparent übernommen werden. Die Funktionalität der SGE ist, wie schon kurz angesprochen, über vier verschiedene Daemons, die auf unterschiedlichen Hosts arbeiten, realisiert: sge_qmaster Der Master Daemon stellt den Kern der SGE dar: Er managt das System und das Scheduling, von ihm werden Informationen zu Hosts, Queues, Jobs, Auslastung und Zugriffsrechten bereitgestellt. Er erhält Scheduling-Entscheidungen vom sge_schedd, und startet die Berechnungen auf Compute Hosts über den sge_execd. sge_schedd Der Scheduling Daemon informiert sich mit Hilfe des Master Daemons über den aktuellen Status der Compute Hosts und trifft auf dieser Basis Scheduling-Entscheidungen, welcher Job in welche Queue dispatcht wird. Diese Entscheidung teilt er dem Master Daemon mit, der die Umsetzung übernimmt

9 sge_execd Der Execution Daemon ist für die Queues auf seinem Host und deren Abarbeitung verantwortlich. Er gibt in vorher definierten Zeitabständen Informationen über den Job Status, eigenen Status und Auslastung und ähnliches an den Master Daemon. sge_commd Der Communication Daemon ist für die Kommunikation zwischen den Hosts der SGE zuständig, die Kommunikation wird zwischen ihm und dem Master Daemon übernommen. In der Standardkonfiguration der SGE ist vorgesehen, den TCP-Port 535 für die Kommunikation zu verwenden. sge_shadowd Der Shadow Master Daemon stellt die Funktionalität für den Shadow Master Host bereit, um im Falle des Ausfalls des Masters die Aufgaben und Funktionalität des Master Hosts übernehmen zu können. In folgender Grafik soll veranschaulicht werden, auf welchen Hosts welche Daemons und Queues zu finden sind: Abbildung 5: Daemons und Queues auf verschiedenen Hosts 2.4. Bearbeitung eines Jobs (Job Execution Cycle) Die Abarbeitung eines Jobs durch die SGE gliedert sich in vier Schritte und wird in folgender Abbildung in seiner Grundstruktur veranschaulicht: - 8 -

10 Abbildung 6: Prinzip der Bearbeitung eines Jobs 1. Job Submission Wird ein Job von einem Submit Host in das System eingegeben, so wird diese Anfrage an den Master Host weitergeleitet 2. Job Scheduling Der Master Host berechnet, auf welchem Host der Job bearbeitet werden soll. Dabei wird sichergestellt, dass der ausgewählte Execution Host die Anforderungen (Hardware- und Softwareplattform) des Jobs erfüllt und die benötigten Resourcen wie Softwarelizenzen vorhanden oder Berechnungsgeschwindigkeiten erfüllt sind. 3. Job Execution (Dispatch) Nachdem der Master Host von seinem Scheduling Daemon die Scheduling Informationen bekommen hat, sendet er den Job an den ausgewählten Execution Host (Dispatch). Der Job wird in der Job- Informations-Datenbank gespeichert und der Execution Daemon startet auf dem Execution Host einen Unterprozess, der den Job bearbeitet. Der Execution Daemon wartet dann auf die Beendigung des Jobs. 4. Accounting Information (Record) Ist die Berechnung eines Jobs abgeschlossen, werden vom Unterprozess die Ergebnisse und weitere Informationen über den Job an den Execution Host gegeben, der wiederum die Daten und die Fertigstellung an den Master Host mitteilt. Der Master Host entfernt den Job der Job-Informations-Datenbank um damit die Fertigstellung des Jobs zu dokumentieren. In der Beschreibung wird nur teilweise auf die Kommunikation der Komponenten der SGE, des Master Hosts und auch nicht auf Queues eingegangen. Dieses Verhalten soll in einer Art Workflow-Darstellung des Job Execution Cycle detaillierter verdeutlicht werden: - 9 -

11 Abbildung 7: Job Flow der SGE Nachdem der Benutzer den Job aufgegeben hat, wird er in der zu Queue der zu schedulen Jobs im Queuesystem der SGE abgelegt. Der Master Host berechnet Anhand von Prioritäten die Reihenfolge der Abarbeitung der Jobs und sucht nach den für den Job benötigten Resourcen. Wurden die Resourcen gefunden, so wird der Job in die Queue des Hosts dispatched, wenn nicht, wird der Job später erneut zum Scheduling vorgesehen. Als nächstes erfolgt die Bearbeitung des Jobs. Ist die Bearbeitung erfolgreich, so werden die Ergebnisse an den Benutzer geschickt, bei nicht erfolgreicher Bearbeitung erfolgt eine erneute Suche nach benötigten Resourcen und eine erneute Bearbeitung des Jobs. 3. Nutzung der Sun Grid Engine 3.1. User Interface Die SGE bietet Benutzern und Administratoren die Möglichkeit, grafisch und textbasiert mit der SGE arbeiten zu können. QMON ist das Graphical User Interface (GUI) der SGE, mit dem sehr viele Aufgaben im Bereich der Administration und der Arbeit durchgeführt werden können. QMON ist individuell an die Bedürfnisse des Benutzers anpassbar, dies ist über eine Konfigurationsdatei möglich

12 Abbildung 8: QMON Main Menu - grafische Oberfläche der SGE In der Abbildung [aus SUNGrid03, S.9] ist die umfassende Funktionalität des QMOM im Ansatz zu erkennen, das Main Menu ist in Standardkonfiguration von QMON dargestellt Software Integration Die Integration und Kompatibilität von bestehenden Anwendungen mit der SGE ist für den Einsatz und die Akzeptanz der SGE ausschlaggebend. Die Kompatibilität der Sun Grid Engine mit bestehenden Anwendungen ist in der Regel gewährleistet, so dass nach Installation und Konfiguration des SGE-Software Jobs auf Basis der bestehenden Applikationen submittiert werden können. Für parallele Anwendungen sind besondere Vorbereitungen erforderlich, um diese im SGE-Kontext einsetzen zu können: Parallel Virtual Machines (PVM) bzw. Message Passing Interface (MPI) muss in die SGE eingebunden werden, um parallele Jobs durch die SGE bzw. deren Komponenten kontrollieren, verwalten und bearbeiten zu können. Das Design von speziellen Interfaces, z.b. für das automatische Aufgeben von Jobs ins Management Tier, oder die Integration eines Application Programming Interfaces (API), von Web Services oder angepasster GUI ist möglich. 4. Standard Edition und Enterprise Edition Die Sun Grid Engine ist in zwei Versionen erhältlich, in der Standard Edition 5.3 und der Enterprise Edition 5.3. Die SGE Standard Edition ist als Open Source Projekt unter SUN Industry Standards Source License kostenfrei verfügbar, die SGE Enterprise Edition ist bei Sun Microsystems kos

13 tenpflichtig zu erwerben. Beide Versionen unterscheiden sich durch verschiedene Einsatzbereiche und Funktionalität Einsatzbereich Die SGE Standard Edition ist für den Einsatz in Clustern vorgesehen und ist Sun Microsystems Standardlösung für DRM in diesem Bereich. Charakteristisch für den Einsatz der Standard Edition und den Cluster-Bereich ist die Nutzung des Systems durch ein Team (für ein Projekt) innerhalb einer Organisation. Die SGE Enterprise Edition erweitert im Vergleich zur Standard Edition das Einsatzgebiet, durch sie können mehrere Cluster konsolidiert (zusammengefasst) werden und ein Single Point of Entry geboten werden. Das Einsatzgebiet der SGE Enterprise Edition wird als campusweit bzw. unternehmensweit bezeichnet und ist charakterisiert durch die Nutzung des Systems durch mehrere Teams innerhalb einer Organisation. Abbildung 9: Einsatzbereiche der SGE Standard und Enterprise Edition 4.2. Funktionalität Aus dem erweiterten Einsatzbereich der SGE Enterprise Edition (SGEEE) ergeben sich neue Anforderungen an die Funktionalität der Software: Strategie zur Resourcenbereitstellung (policy-based resource allocation):

14 Zu- und Aufteilung des Resourcenkontingents zwischen verschiedenen Teams, Projekten und Abteilungen Dynamischer Resourcenausgleich (dynamic resource balancing): Resourcenverwendung zur Laufzeit entsprechend der Strategie zur Resourcenbereitstellung (mit möglicher Kompensation) Kontrolle der Einhaltung des Resourcenbudgets (resource budget control) Diese Anforderungen werden durch das sog. Policy Modul der SGE Enterprise Edition realisiert. Das Policy Modul beeinflusst durch Policies, wie Resourcen zwischen Teams bzw. Projekten aufgeteilt werden (nicht zwischen Jobs), so dass sich der Job Execution Cycle bei der Enterprise Edition im Vergleich zur Standard Edition ändert: Abbildung 10: Vergleich der Job Flows beider Editions der SGE Policies können in der SGE Enterprise Edition vom Administrator definiert und je nach Bedarf angepasst werden. Es werden vier Arten von Policies unterschieden: Share-Tree based Bei der Share-Tree based Policy wird jedem Benutzer oder jedem Projekt ein Prozentsatz der Gesamtresourcen zur Verfügung gestellt. In sofern ein Benutzer oder ein Projekt sein Resourcenbudget überschreitet und damit Resourcen beansprucht, die einem anderen Teilnehmer zustehen, wird dies protokolliert und später wieder ausgeglichen. Functional

15 Die Functional Policy gleicht der Share-Tree based Policy, hier wird jedoch die Resourcenbudgetüberschreitung nicht protokolliert und auch nicht ausgeglichen. Deadline Die Deadline Policy orientiert sich, wie der Name sagt, am Abarbeitungszeitpunkt (Deadline) der Jobs. Jobs mit früherer Deadline werden im Vergleich zu Jobs mit späterer Deadline in der Bearbeitung vorgezogen und brauchen dafür möglicherweise auch zusätzliche Resourcen. Die Resourcenbereitstellung wird in solchen Situation vom Administrator für diesen Job speziell angepasst. Override Die Override Policy erlaubt Administratoren, Entscheidungen der SGE bzgl. Ressource Allocation zu übergehen und manuell Resourcenzuteilungen vorzunehmen und somit die Wichtigkeit von Jobs und damit die Bearbeitung dieser zu beschleunigen. Die Policies werden verwendet, um die verfügbaren Resourcen innerhalb des von der SGEEE verwalteten Rechnerverbunds zu identifizieren und um eine optimierte Resourcenverteilung und nutzung zu ermöglichen. 5. Zusammenfassung 5.1. Mögliche Anwendung in der Projektgruppe Das Ziel der Projektgruppe ist die die Entwicklung einer Software für den upb.de-supercomputer, der freie Resourcen der Rechner der Universität Paderborn für die Berechnung rechenintensiver Probleme nutzt, während der Benutzer inaktiv ist. Die Software soll als Middleware sieben Teilsysteme (Resource Allocation, Resource Scheduling, Job Execution, Data Management, Information Service, Monitoring und User Interface) abdecken und vorgegebene Kriterien wie einfache, unkomplizierte Bedienung, transparente Aufgabenverteilung und automatische Aufgabenbearbeitung erfüllen. Das zu entwickelnde Produkt soll im Rechnerverbund der Informatik der Universität sowohl auf Pool-Rechnern als auch auf Büro- und Hochleistungsrechnern eingesetzt werden, primär ist der Einsatz auf dem Betriebssystem Linux geplant. Aus den bisher bekannten Anforderungen ist der Einsatz der Sun Grid Engine Standard Edition in der Projektgruppe möglich. Die SGE wird von SUN Microsystems als Middleware zwischen Betriebssystem-Ebene und Applikations-Ebene verstanden. Die Funktionalität deckt alle sieben Teilsysteme des upb.de-supercomputers ab. Die Software ist als Open-Source-Projekt für Linux und Solaris unter SUN Industry Standards Source License frei verfügbar und erweiterbar bzw. an

16 passbar: Die SGE kann als Basis zur Realisierung des upb.de- Supercomputers dienen, indem sie an unsere Anforderungen und Ziele angepasst wird. Anpassungen können sowohl über Weiterentwickelung der Software als auch über die Konfiguration der Software realisiert werden. Eine umfassende Dokumentation über Architektur, Administration und Nutzung der SGE wird von Sun Microsystems zur Verfügung gestellt. Die Anpassung der Software wird vermutlich notwendig sein, da die SGE in einigen Bereichen nur teilweise den bisher bekannten Anforderungen entspricht: Die Bearbeitung von Jobs nur bei Inaktivität von Benutzern ist nach derzeitigen theoretischen Kenntnissen über die SGE nicht möglich, hier könnte eine Lösung durch Checkpointing mit dem Suspend und Resume von Jobs bzw. durch Job Migration realisiert werden. Auch ist im Bereich des Schedulings der zu verwendende Scheduling-Algorithmus fest definiert. Bevor eine Entscheidung über den Einsatz der SGE in der Projektgruppe getroffen wird, sollte die Software im Praxiseinsatz evaluiert werden und geprüft werden, in wiefern die Anforderungen der Projektgruppe aus dem noch zu erarbeitenden Anforderungsdokument abgedeckt werden und welche Funktionalität innerhalb der Arbeit der Projektgruppe zu realisieren wäre Fazit und Ausblick Die Sun Grid Engine bietet als Software des Distributed Ressource Managements umfassende Funktionalität für den Einsatz im Bereich des Grid Computings und im Themengebiet der Projektgruppe. Das Thema Grid Computing bzw. die Nutzung von nur teilweise ausgelasteten Rechnersystemen wird nach Ansicht von Sun Microsystems in Zukunft neben Wireless und Real-Time einer der drei wichtigen Trends sein. Die Sun Grid Engine ist als zentraler Bestandteil der Softwarepalette von Sun Microsystems für Grid Computing eine Middleware und bietet einen zentralen Zugangpunkt zum Grid. Die SGE Standard Edition ist als Open Source Projekt auf über 7000 Systemen im Einsatz und damit eine weit verbreitete Software für den DRM-Bereich. Neben Sun Microsystems wird die Software von 800 Entwicklern in einer Open Developer Community stetig weiterentwickelt: Am 21. November 2003 wurde die SGE für MAC OS/X veröffentlicht. Die Version 6.0 der Software soll im Januar 2004 als Beta-Version veröffentlich werden, das Final Release der Version 6.0 ist für das zweiten Quartal 2004 geplant und umfasst ein neues Kommunikationssystem für die Kommunikation zwischen Hosts, einen neuen Scheduler mit erweiterter Funktionalität (Resourcenreservierung im Voraus, Einbinden von externen Scheduling-Algorithmen), neue Auswertungsmöglichkeiten für Analyse, Monitoring und Accounting sowie die Kompatibilität mit Standards (DRMAA 1.0 sowie Globus Toolkit 3.0)

17 6. Anhang 6.1. Anhang A: Features der Sun Grid Engine Funktionalität Betriebssysteme Job-Typen Funktionalität bezüglich Jobs User Interface Statusinformationen Einsatzgebiet Resourcenzuweisung Lizenzierung SGE Standard Edition 5.3 SGE Enterprise Edition 5.3 Distributed Resource Management sowie Load Balancing Solaris, Linux, MAC OS/X, Tru64, HP-UX, AIX, IRIX Batch, Interaktive und Parallele (PVM und MPI) Jobs Checkpointing, Suspend / Resume Jobs, Job Migration Textbasiert (Konsole) und Grafisch Zu Jobs und Hosts verfügbar Abteilungsweit, Zusammenfassen von Rechnern sammenfassen von Grids Unternehmensweit, Zu- Fest auf Basis von Prioritäten definiert licies (Regeln) definiert Flexibel auf Basis von Po- Source Code und Binaries Kostenpflichtig über Sun frei verfügbar Microsystems 6.2. Anhang B: Abkürzungsverzeichnis SUN Sun Microsystems, Inc. Sun ONE Sun One Net Environment SGE Sun Grid Engine SGEEE Sun Grid Engine Enterprise Edition DRM Distributed Resource Management CODINE COmputing in DIstributed Network Environment CPU Central Processing Unit GPL GNU Public License LDAP Lightweight Directory Access Protocol NIS Network Information Service NFS Network File System SSH Secure Shell TCP/IP Transmission Control Protocol / Internet Protocol API Application Programming Interface GUI Graphical User Interface PVM Parallel Virtual Machine MPI Message Passing Interface DRMAA Distributed Resource Management Application API

18 6.3. Anhang C: Literaturverzeichnis Literatur aus dem Internet: [SUNLearning] SUN Web Learning Center, Course Nr. WE / WE- 1600: Administrating and Supporting SUN Grid Engine SUN Microsystems, Inc., Palo Alto, CA, USA, Juni WE html [SUNGrid01] Informationsbroschüre Grid Computing from SUN for technical markets and commercial enterprises SUN Microsystems, Inc., Palo Alto, CA, USA, Juni [SUNGrid02] Sun Cluster Grid Architecture - A technical white paper describing the foundation of Sun Grid Computing SUN Microsystems, Inc., Palo Alto, CA, USA, Mai SunClusterGridArchitecture.pdf [SUNGrid03] [SUNGrid04] [SUNGrid05] [SUNGrid06] Sun ONE Grid Engine - Administration and User s Guide SUN Microsystems, Inc., Palo Alto, CA, USA, Oktober docs/pdf/ pdf Sun ONE Grid Engine Enterprise Edition Administration and User s Guide SUN Microsystems, Inc., Palo Alto, CA, USA, Oktober docs/pdf/ pdf SUN Grid Computing, Architecture and Implementation Dr. Wolfgang Gentzsch, Director Grid Computing SUN Microsystems, Inc., Palo Alto, CA, USA, Oktober SUN Grid Computing Projects Dr. Wolfgang Gentzsch, Director Grid Computing SUN Microsystems, Inc., Palo Alto, CA, USA, Juni hpc/2003presentations/heidelberg/s10_wolfgang_gentch.pdf

19 [SUNGrid07] [Aberdeen01] SUN Grid Engine Enterprise Edition Product Brief SUN Microsystems, Inc., Palo Alto, CA, USA, Dezember sgeee.pdf Sun s Grid Computing Solutions Outdistance the Competition - An Executive White Paper Aberdeen Group, Inc., Boston, MA, USA, Mai Grid_competitive.pdf [GinterGrid] Seminar: Grid Systeme Carsten Ginter, Technische Universität Ilmenau, Sommersemester Ginter02Grid.pdf