Evaluation und Vergleich von Cluster und Gridmanagementlösungen

Transkript

1

2

3 Evaluation und Vergleich von Cluster und Gridmanagementlösungen DIPLOMARBEIT für die Prüfung zum Diplom Ingenieur (Berufsakademie) der Fachrichtung Informationstechnik an der Berufsakademie Stuttgart von JOHANNES WIEDMANN September 2005 Bearbeitungszeitraum Kurs Ausbildungsfirma Gutachter der Ausbildungsfirma Gutachter der Studienakademie 3 Monate TIT02NSB transtec AG Tübingen Dr. Andreas Koch Prof. Dr. Christoph Reich

4

5 Copyright 2005 Dieses Werk ist geistiges Eigentum. Es darf ohne Zustimmung des Autors weder kopiert noch auszugsweise abgedruckt oder in einer anderen Form vervielfältigt werden. Alle in diesem Werk enthaltenen Informationen wurden mit größter Sorgfalt zusammengestellt. Dennoch können fehlerhafte Angaben nicht völlig ausgeschlossen werden. Der Autor haftet nicht für etwaige Fehler und deren Folgen. Die in diesem Werk verwendeten Soft- und Hardwarebezeichnungen sind häufig eingetragene Warenzeichen. Sie werden in diesem Buch ohne Gewährleistung der freien Verwendbarkeit genutzt. Das Abdrucken von Waren- und Handelsnamen auf den folgenden Seiten berechtigt nicht zu der Annahme, diese Namen als frei im Sinne der Markenschutzgesetzgebung zu betrachten.

6

7 Erklärung Ich versichere hiermit, dass ich die vorliegende Arbeit mit dem Thema Evaluation und Vergleich von Cluster- und Gridmanagementlösungen selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Ort, Datum Unterschrift

8

9 Zusammenfassung Die Anwendungsgebiete für Clustersysteme in Forschung und Industrie erstrecken sich von der finiten Elementanalyse der Automobilindustrie bis hin zu den Special Effects aus Hollywood. In der Wirtschaft und Industrie findet sich eine Vielzahl an Verwendungsmöglichkeiten und eine große Nachfrage nach immer mehr Rechenleistung. Clustersysteme decken einen großen Teil der Nachfrage. Auf Clustersystemen, bestehend aus untereinander vernetzten Standardrechnersystemen, kümmert sich eine spezielle Linux-basierte Software um die Verteilung der Jobs auf die einzelnen Rechner und lässt die einzelnen Systeme für den Anwender wie ein einzelnes System wirken. Die immer größer werdenden Cluster erfordern ein integriertes und monolithisches Management. Der Verwaltungsaufwand für die Administration und Pflege der Software steigt nahezu exponentiell zu der Anzahl der Maschinen im System an. Aus diesem Grund wird eine spezielle Managementsoftware eingesetzt. Diese sorgt für eine reibungslose Integration von neuen Knoten, verfügt über eine Paketverwaltung (Repository) für die Softwareverwaltung, liefert Monitoringfunktionen und lässt verschiedene Konfigurationen rasch einspielen. Aktuell existieren viele verschiedene kommerzielle und freie Anbieter solcher Software auf dem Markt. Manche setzen auf eine vorhandene Linuxinstallation auf, andere bringen von Haus aus ein eigenes Linuxbetriebsystem mit. Diese Systeme unterscheiden sich in Implementierung und Umfang der Managementfunktionen. Auch im Grad der Komplexität liegen zum Teil beachtliche Unterschiede. Die Evaluation der entsprechenden Managementfunktionen und teilweise Implementierung mit nachfolgender Herausarbeitung der Merkmale der verschiedenen Systeme ist die Aufgabenstellung für die vorliegende Arbeit. Die Wahl der Managementlösungen wurde anhand von Marktbeobachtungen und Expertengesprächen getroffen, wodurch sich eine gute Übersicht über die verbreitetsten und vielversprechendsten Systeme ergibt.

10

11 Abstract The areas of application for cluster systems in research and industry extend from the finite element analysis of the automobile industry to the special effects of Hollywood. There is a high demand in a variety of topics in Research and Industry for ever more computing power. These cluster systems consist of interconnected standard computer systems. A specialized Linux based software distributes compute jobs on these individual nodes and makes the cluster appear like a monolithic system to the user. These ever more complex clusters require a highly integrated management software. The expense for the administration and care of the software rises almost exponentially with the number of cluster nodes. To address this problem, a special management software is used. This management software allows the smooth integration of new nodes, features a repository for the software administration, offers monitoring functions and implements a variety of configurations quickly. Currently many different commercial and free vendors of such software exist on the market. Some of them operate on top of an existing Linux installation, others provide their own Linux operating system. These systems differ in the implementation, extent of management functions and details of the software solution. The degree of complexity is differing as well. The topic of this diploma thesis is the evaluation of the appropriate management systems, partial implementation with subsequent characterization of the different systems and usability test with final assessment. The choice of the management solutions covered in the thesis was based on market observations and expert opinions, whereby a comprehensive overview of the most common and promising system was acquired.

12

13 Danksagung Viele haben mir bei dieser Arbeit geholfen und ich möchte Ihnen meinen Dank aussprechen. Als fachmännische Lektoren und Betreuer dieser Arbeit möchte ich ganz herzlich bei Herrn Dr. Andreas Koch (transtec AG) und Herrn Prof. Dr. Christoph Reich (Fachhochschule Furtwangen) für ihre investierte Zeit und Mühen danken. Mein Dank gebührt auch Herrn Dr. Karsten Gaier (Altreia Solutions) dessen Ideenvorschlag dieser Arbeit zu Grunde liegt. Bei Herrn Bernd Zell (transtec AG) und Herrn Leonardo Lapeira (transtec AG) möchte ich mich für ihre fachkundige und literarische Unterstützung und für die investierte Zeit recht herzlich bedanken. Für Möglichkeit zur freien Zeiteinteilung, für die bereitgestellte Hardware samt schnellem Internetanschluss und für die finanziellen Mittel möchte ich der transtec AG recht herzlich danken. Zu guter Letzt bedanke ich mich vielmals bei Frau StR Janine Dilbat und Herrn Oliver Peter Kübel M.A., für die germanistische Korrektur und den damit verbundenen Zeitaufwand.

14

15 Inhaltsverzeichnis 1 Einführung Einblick in verteilte Systeme Einführung in verteilte Systeme Hardwarearchitektur eines verteilten Systems Softwarearchitektur eines verteilten Systems Applikationen-Schicht Middleware-Schicht Ressourcen-Schicht Netzwerk-Schicht Die unterschiedlichen Typen von verteilten Systemen Kategorie: Applikation Compute Cluster/Grid Scavenging Cluster/Grid Data Cluster/Grid Kategorie: Größe Clustersysteme Intra Grids Extra Grids

16 Einführung Inter Grids Historie, Gegenwart und Zukunft Die Evolution der Nachrichtendienste Die Evolution der verteilten Systeme Anforderungen an Managementsysteme Softwarelizenzierungsmodell Support Managementfunktionen Monitoringfunktionen Das Ganglia Toolkit Hardware-Inventur Konfigurationsverwaltung Repository Lights-Out-Management (LOM) Health-Check Benutzerverwaltung Parallele Programmierumgebungen Parallel Virtual Machine (PVM) Der Aufbau...35 Die virtuelle Maschine Message Passing Interface (MPI) LAM/MPI MPICH Scali MPI Connect OpenMP High Performance Fortran (HPF) Ressourcenmanagementsysteme OpenPBS Architektur Die Scheduler Server Interaktion Sun Grid Engine (SGE) Jobverarbeitung innerhalb der SGEEE Benutzungsrichtlinien der SGEEE

17 3.5.3 Globus Toolkit (GT) openmosix Migrationsverhalten Praxisbeispiel Transparenz und Sicherheit Input/Output Probleme und Lösungen (DFSA) Beschränkungen Unterstützte Hardware Unterstützte Architektur Unterstütztes Netzwerk Ethernet (10/100/1000/ MBit/s) InfiniBand Myrinet Quadrics SCI Vergleich der Bandbreiten Vergleich der Latenzzeiten Unterstützte Betriebssysteme (Master/Clients) Verteilte/Cluster Dateisysteme (VCDs) Zwischenspeicher (Cache) Zeitstempel (time stamp) Verbindungskonsistenz (link consistency) Aufstellung aktueller VCDs Das Parallel Virtual File System (PVFS) Betrachtung der Managementsysteme ClusterKnoppix Übersichtstafel: Managementsystem ClusterKnoppix CLUTO Übersichtstafel: Managementsystem CLUTO Cluster Systems Management (CSM) Die Clusterinstallation mit CSM Übersichtstafel: Managementsystem CSM

18 Einführung 4.4 OSCAR Die Clusterinstallation mit OSCAR Übersichtstafel: Managementsystem OSCAR Rocks Übersichtstafel: Managementsystem Rocks s.cluster / scvenus Übersichtstafel: Managementsystem s.cluster / scvenus Scali Manage Übersichtstafel: Managementsystem Scali Manage Scyld Beowulf Die Clusterinstallation mit Scyld Beowulf 27 bz Übersichtstafel: Managementsystem Scyld Beowulf Weitere Managementsysteme Sun Control Station (SCS) Warewulf OpenSCE Schlussbetrachtung ANHANG A Struktur eines Clusters (asymmetrisch/symmetrisch) Das Boot from LAN (BfL) Konzept Das Single System Image Konzept (SSI) ANHANG B Literatur- und Quellenverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis Glossar Index

19 Einführung 1 Einführung Supercomputer kommen zum Einsatz, wenn Berechnungen auf normalen Computern entweder gar nicht oder nicht in einem angemessenen Zeitraum zu bewältigen sind. Werden die Berechnungen so fein aufgelöst, dass aufgrund dieser Diskretisierung die Datenmengen sehr groß werden, ist der Einsatz eines Supercomputers unumgänglich. Die Hardwareinfrastruktur eines normalen Computers legt hierbei schnell die Grenze fest. Thematiken, die nach Rechenleistung auf dem Niveau eines Supercomputers verlangen, erstrecken sich von der Astrophysik bis hin zu den Special Effects aus Hollywood. Auch die Wirtschaft und die Industrie haben eine Vielzahl an Verwendungsmöglichkeiten für Supercomputer. Aus diesem Grund ist Supercomputing ein aktuelles Thema. Doch Supercomputer haben ihren Preis. In kleinen Stückzahlen mit exotischer Hardware gefertigt, mit großen finanziellen Mitteln erforscht und mit viel Wissen zur Produktionsreife gebracht, kostet ein traditioneller Supercomputer schnell mehr als die Universitäten oder die Industrie dafür aufbringen können. Solche Computer werden von renommierten Firmen wie Cray oder IBM hergestellt und kosten meist mehrere Millionen Dollar. Diese hohen Kosten waren eben einer der wichtigsten Gründe, warum sich Anfang der 90er Jahre Thomas Sterling und Don Becker, damalige Mitarbeiter einer Forschungsgruppe bei der 5

20 Einführung amerikanischen Luft- und Raumfahrtbehörde (NASA), mit der Entwicklung von Rechenarchitekturen beschäftigten, die deutlich kostengünstiger werden sollten, als es das traditionelle Supercomputing bis dato war. Das Ergebnis und der Lösungsweg waren äußerst interessant: Eine Ansammlung von 16 Prozessoren des Typs Intel 80486, welche über channel bonding Ethernet miteinander kommunizierten und unter dem Namen Beowulf 1 im Sommer 1994 bekannt gegeben wurden. Als Betriebssystem kam Linux zum Einsatz. Ein Clustersystem besteht vereinfacht aus zwei Arten von Rechnern: einem oder mehreren Servern und mehreren Clients. Der Server wird im Clusterumfeld meistens als Master bzw. Masterknoten bezeichnet. Synonyme Begriffe im Englischen sind Master bzw. Masternode. Analog dazu werden die Clients als (Rechen-)Knoten, englisch Node, bezeichnet. In diesem Werk werden die Begriffe Master, Masterknoten, Knoten und Rechenknoten verwendet. Der prinzipielle Aufbau eines Clustersystems ist meistens asymmetrisch. Es existieren auch symmetrische Clustersysteme. Eine Unterscheidung zwischen symmetrisch und asymmetrisch erfolgt in ANHANG A. Bei den asymmetrischen Systemen fungiert der Master als Verwaltungsrechner für den Cluster, nimmt Aufgaben entgegen und verteilt sie an die Knoten. Diese werden nur für Berechnungen verwendet und verfügen darum im Gegensatz zum Master über keine Peripheriegeräte, wie Monitor, Tastatur und Maus. Standardmäßig werden die Geräte der Clustersysteme in einem 19 Rack montiert. 1 Beowulf ist eine epische Erzählung über die Abenteuer eines großen skandinavischen Kriegers aus dem sechsten Jahrhundert. Diese wurde in einer alten Form der englischen Sprache aus dem zehnten Jahrhundert geschrieben. Dass die Maschine von Sterling und Becker mit diesem Namen benannt wurde, hat wohl eher mit den literarischen Vorlieben der Architekturdesigner zu tun, als dass ein näherer Vergleich zwischen ihnen gezogen werden könnte. 6

21 Einführung Abbildung 1 Anordnung eines Clustersystems Abbildung 1 zeigt die Anordnung eines Clustersystems im 19 Rack. Zur Aufnahme großer Datenmengen verfügt der Master in bestimmten Fällen über einen externen Speicher. Zusätzlich wird meistens noch eine Notstromversorgung für den Masterknoten bereitgestellt. Meistens werden die Netzwerkkomponenten ganz oben bzw. ganz unten in den Schrank integriert. Der Master wird an einer Stelle im Schrank montiert, an welcher er leicht zugänglich ist. Den restlichen Platz füllen die Rechenknoten und die eventuell vorhandene Notstromversorgung. Natürlich sind auch viele andere Konstellationen für Clustersysteme möglich und im Einsatz. Der große Vorteil der Clustersysteme besteht in der Flexibilität ihrer Konfiguration. Die Erfindung der Clustersysteme sprach sich schnell bei Universitäten herum und sofort wurden vielfach Supercomputer mit ausgemusterten PCs zusammengestellt. Die schnelle Verbreitung machte die Industrie, die sich schon lange um günstigere Supercomputer bemüht hatte, darauf aufmerksam. 7

22 Einführung Cluster sind also im Prinzip eine Ansammlung normaler PCs 2 wie sie weltweit als Bürorechner oder Server eingesetzt werden, die über ein schnelles Netzwerk Daten austauschen. Dazu wird eine besondere Softwarekonfiguration aufgesetzt, welche das System für den Anwender wie ein einheitliches System wirken lässt. Durch diese standardisierte und in großen Stückzahlen produzierte Hardware kommen Clustersysteme sehr kostengünstig auf den Markt. Die erhöhte Nachfrage nach großer Rechenpower eröffnete auch den Markt der Clustersysteme für etablierte Anbieter wie Sun Microsystems, SGI, Hewlett-Packard oder IBM. Viele dieser Anbieter konzentrieren sich auf die Programmierung von Anwendertools, welche die Bedienung des Gerätes vereinfachen sollen. Meistens läuft diese Software auch nur auf der Hardware des jeweiligen Herstellers und die Nutzung ist durch Lizenzen geregelt. Eine gute Alternative zu dieser Software ist Linux. Der offene Quellcode des Unix-Ablegers lässt eine individuelle Anpassung an alle IT-Bereiche zu. Linux findet sich auf Organizern, auf Arbeitsstationen, auf Servern und eben auch auf Supercomputern. Eine Einführung in verteilte Systeme mit dem Schwerpunkt linuxbasierte Cluster- und Gridsysteme befindet sich in Kapitel 2. Um Ansammlung von Rechnern zu einem Clustersystem zusammenzufügen, wird in vielen Fällen eine komplexe Managementsoftware eingesetzt. Das Hinzufügen und Entfernen von Rechenknoten, sowie die Benutzerverwaltung ist dabei nur eine Disziplin. Aufwändige Software- und Konfigurationsupdates können verwaltet und gezielt eingefügt werden. Denkbar ist auch die tägliche Umkonfiguration zu bestimmten Tageszeiten. Managementsysteme für den Einsatz auf Cluster- oder Gridsystemen haben das Ziel, die Komplexität der Installation und der Konfiguration zu verstecken. Um Unklarheiten zu vermeiden wird an dieser Stelle der Begriff Cluster- bzw. Gridmanagementsystem genauer definiert. Mit diesem Begriff werden Softwarezusammenstellungen bezeichnet, welche die Einrichtung eines Cluster- oder Gridsystems übernehmen. Diese Einrichtung betrifft viele Bereiche und besteht nicht nur aus der Verwaltung der Benutzer oder der Auslastungsüberwachung. Somit steht der Begriff Cluster- und Gridmanagementsystem für die folgenden Tätigkeiten und Bereiche eines Cluster- oder Gridsystems: 2 Diese Ansammlung wird auch gern Steinsuppe (= Stone Soup, engl.) genannt. Daraus entsteht dann Stone Souper Computer. Ein interessanter Artikel hierzu ist Der selbst gebastelte Supercomputer aus Spektrum der Wissenschaft, März 2002 von William W. Hargrove, Forrest M. Hoffman und Thomas Sterling. 8

23 Einführung Installation Einrichtung/Konfiguration Unterstützung bestimmter Hardware Kontrolle/Überwachung des Systems Pflege/Aktualisierung (hard- und softwaretechnisch) Benutzerverwaltung Bereitstellung relevanter Software (Parallele Programmierumgebungen, Ressourcenmanagementsysteme, etc.) Durch die starke Nachfrage nach großer Rechenleistung wuchsen die Anzahl der Rechner pro Cluster stetig an. Für diese Art Cluster ist ein integrierteres monolithisches Management nötig, da der Verwaltungsaufwand für die Administration und Pflege der Software bzw. Konfiguration überproportional ansteigt. Vergleichbar sind diese Managementsysteme mit Lösungen für den Client/Server-Betrieb in großen Netzwerken. Während ein System mit 16 Maschinen noch von Hand betreut werden kann, ist diese Methode bei mehreren Hundert Rechnern im Clusternetzwerk unmöglich durchzuführen. Aus anfänglichen Skripten und kleinen Hilfsprogrammen für die Verwaltung der Rechner hat sich eine Reihe mächtiger Werkzeuge entwickelt. Viele dieser Werkzeugpakete basieren auf Open Source, andere auf kommerzieller Basis. Ein Teil dieser Werkzeugpakete zielt stark auf den Einsatz in Rechnernetzwerken, wie sie in Firmen existieren. Diese Pakete bringen für den Einsatz bei Clusterund Gridsystemen schon viele nützliche Werkzeuge mit. Darüber hinaus gibt es speziell auf den Cluster- und Gridbereich abgestimmte Werkzeuge. Eine Anforderungsanalyse der Managementsoftware findet sich in Kapitel 3. Betrachtet wurden die am Markt verfügbaren und verbreiteten kommerziellen Produkte sowie Lösungen, die auf einer freien Lizenz basieren. Die Schnittmenge der Funktionen der Managementsysteme bildet hierbei den gemeinsamen Nenner, an welchem sich die Systeme in Kapitel 4 messen müssen. Das Fazit über die evaluierten Ergebnisse befindet sich in Kapitel 5. Eine allgemeingültige Aussage lässt sich bei einem so weitläufigen Thema nicht bilden. Aus diesem Grund werden die Ergebnisse nach den möglichen Anforderungen in der Praxis sortiert. ANHANG A enthält weitergehende Informationen zu Themen aus diesem Werk. In den meisten Fällen ließen sich die Themen nicht einem einzigen Kapitel allein zuweisen und wurden darum in den Anhang aufgenommen. 9

24 Einführung Das Literatur- und Quellenverzeichnis, das Abbildungs- und Tabellenverzeichnis, das Glossar und der Index für ein schnelles Auffinden der benötigten Informationen befindet sich in ANHANG B. 10

25 Einblick in verteilte Systeme 2 Einblick in verteilte Systeme Dieses Kapitel hat das Ziel, dem Leser das Thema Cluster- und Gridsysteme näher zu bringen. Zunächst wird der hardware- und softwaretechnische Aufbau erläutert. Anschließend wird die Geschichte, die Gegenwart und die Zukunft der verteilten Systeme beschrieben. 2.1 Einführung in verteilte Systeme Wenn verteilte Rechen- und Speicherkapazitäten an einem Ort und zu einer Zeit nutzbar gemacht werden, können selbst große Rechenprobleme in kürzester Zeit gelöst werden. Diese Bündelung der Rechen- und Speicherkapazitäten zu einem einheitlich wirkenden System nennt man Cluster. Das nächste Ziel ist die Vernetzung mehrerer Forschungseinrichtungen untereinander, um die gemeinsame Rechenkapazität zu einem Grid zu bündeln. Der Name Grid ist vom Begriff des Power Grid, zu deutsch Stromnetz, abgeleitet. Wie beim Stromnetz der Strom soll beim Grid die entsprechende Rechnerressource aus der Steckdose erhältlich sein so der Grundgedanke. Das endgültige Ziel ist die Vernetzung sämtlicher Leistungen eines Rechners oder eines Clusters wie der Rechenkapazität, der Speicherkapazität, der Informationen und der Applikationen. 11

26 Einblick in verteilte Systeme Hardwarearchitektur eines verteilten Systems Der technologische Schritt vom Ein- zum Mehrprozessorsystem war nur eine Frage der Zeit. Schon für den INTEL 8086 existierte ein Koprozessor, der Dieser war für die Berechnung von Floating- Point Operationen zuständig. Letztere waren beim Koprozessor in Hardware implementiert, wodurch sich eine Leistungssteigerung bei dieser Art von Gleitkomma-Berechnungen ergab. Diese Konstellation der Prozessoren wird asymmetrisch genannt. Der nächste Schritt erfolgt von diesen asymmetrischen Systemen hin zu den symmetrischen Mehrprozessorsystemen Symmetric Multiprocessor (SMP)). Bei einem SMP-System greifen alle Prozessoren über einen schnellen Bus gemeinsam auf den Speicher des Systems zu. Dabei sind alle Prozessoren vom gleichen Typ. In Abbildung 2 ist der schematische Aufbau eines SMP-Systems qualitativ aufgezeigt. Abbildung 2 Schematischer Aufbau eines SMP-Systems Alle Geräte, die an das Bussystem angeschlossen sind, können jeweils einzeln das Bussystem für die Übertragung der Daten nutzen. Ist ein Gerät (hier: ein Prozessor) im Sendestatus, also der sogenannte Busmaster, dann schalten alle anderen Geräte in den Nichtsendestatus. So behindern sie den Datenverkehr nicht, bis sie an der Reihe sind. Heutige Systeme haben mehrere Busse. Einen Kontroll-, einen Adress- und einen Datenbus. Durch pipelined operations können auf den verschiedenen Bussen unterschiedliche Busmaster gleichzeitig operieren. Bei den aktuellen AMD Opteron Systemen kommt eine andere Technologie zum Einsatz: der Non- Uniform Memory Access (NUMA). Bei dieser Technologie besitzt jeder Prozessor seinen eigenen Speicher (vgl. Abbildung 3). 12

27 Einblick in verteilte Systeme Abbildung 3 Schematischer Aufbau eines NUMA Systems Zusätzlich kann jeder Prozess über den sogenannten HyperTransport-Kanal (HTX) auf den Speicher der anderen Prozessoren zugreifen. Dieser hat eine Bandbreite von 12,8 GBit/s. Ein Zugriff von CPU0 auf den Speicher von CPU1 ist natürlich langsamer als der Zugriff von CPU0 auf ihren lokalen Speicher. Ganz ähnlich wie die NUMA-Systeme sind die Clustersysteme aufgebaut. Jeder Knoten besitzt seinen eigenen Speicher. Über ein Verbindungsnetzwerk kann er auf den Speicher der anderen Rechenknoten zugreifen (siehe Abbildung 4). Abbildung 4 Schematischer Verbindungsaufbau eines Clustersystems (vgl. NUMA) Die grundlegende Idee heutiger Clustersysteme ist, die Leistung eines SMP-Systems zu erreichen, aber den geringen Preis eines Clusters zu bezahlen. Das Ziel ist also ein virtuelles SMP-System. Vergleicht man SMP-Systeme mit Clustersystemen, so fällt auf, dass das Verbindungsnetzwerk die Aufgabe des Busses übernehmen muss. Der Nachteil der Verbindungsnetzwerke ist der Overhead 13

28 Einblick in verteilte Systeme der Netzwerkprotokolle und die damit verbundene Latenzzeit 3. Die grundlegenden Schwierigkeiten in diesem Fall werden in Kapitel erläutert Softwarearchitektur eines verteilten Systems Um ein funktionierendes verteiltes System zu entwickeln, bedarf es mehrerer Zwischenstufen. Die reine Vernetzung und Aggregation der Rechenleistung und des Speichers entspricht einem Clustersystem. Der Aufbau eines Gridsystems ist komplizierter. Es ist in Schichten unterteilt und an das OSI-Modell angelehnt. Ein geschichteter Aufbau bringt viele Vorteile mit sich. Es werden lediglich die Schnittstellen definiert, welche eine Schicht nach oben und nach unten ausweisen muss. Aus diesem Grund sind die Techniken (physikalisch/software) innerhalb der Schicht, welche diese Schnittstellen realisieren, nicht vorgegeben und lassen sich bestmöglich realisieren bzw. austauschen. In der nachfolgenden Abbildung 5 sind der Aufbau und die einzelnen Schichten eines verteilten Systems schematisch dargestellt. 3 Unter der Latenzzeit (latency, engl.) versteht man in der Netzwerktechnik die Verzögerung, bis Daten transferiert werden können. Bei sehr kleinen, aber häufigen Datenpaketen ist die Latenzzeit der entscheidende Faktor eines Netzwerkes und Grund für die Wahl einer bestimmten Netzwerktechnik. 14

29 Einblick in verteilte Systeme Abbildung 5 Verteilte Systeme: Schichtenmodell Die einzelnen Funktionen der Schichten sind wie folgt: Applikationen-Schicht In der obersten Schicht befinden sich die Applikationen und Dienste für den Anwender, beispielsweise Entwicklungsumgebungen und Zugangsportale. Die Entwicklungsumgebungen differieren zum Teil sehr stark, abhängig vom jeweiligen Einsatzgebiet. Unter den Diensten versteht man die Managementfunktionen, wie zum Beispiel Accounting, Abrechnungs- und Monitoringfunktionen. Nur durch diese Funktionen lassen sich die Ressourcen sicher benutzen und verteilen. 15

30 Einblick in verteilte Systeme Middleware-Schicht In der Middleware sitzt die eigentliche Intelligenz eines verteilten Systems. In dieser Schicht werden die Protokolle und Kontrollinstrumente bereitgestellt. Dies ist die Schicht der Ressourcenmanagementsysteme. Ressourcen-Schicht In der nächst tiefer gelegenen Schicht liegen die Ressourcen, wie Hardware, Speicher und die Rechenkapazitäten. Es kann sich bei einem Cluster um einzelne Rechenknoten oder bei einem Grid um ganze Cluster handeln. Im letzteren Fall nimmt der Masterknoten des Clusters die Anfragen und Aufgaben, welche aus dem Grid stammen, an und verteilt sie an seine Rechenknoten. Diese weitere Verteilung ist natürlich abhängig vom Batch-Queuing-System, welches hier Verwendung findet. Netzwerk-Schicht Die unterste Schicht bildet, wie in jedem vernetzten System, das Netzwerk selbst. Diese Schicht, mit ihren Protokollen und der entsprechenden Hardware, ist für die Übermittlung der Pakete zuständig, welche ihr übergeben werden. Auch hier gilt, dass die Ausstattung abhängig von der jeweiligen Anwendung ist. Sind sehr niedrige Latenzzeiten erforderlich, so ist eine andere Netzwerktechnik vonnöten, zum Beispiel wie bei der Übermittlung großer Datenpakete. Die aktuell verfügbaren Netzwerktechniken werden in Kapitel aufgeführt und erläutert. Gerade bei Gridsystemen spielt hier das Internet natürlich eine sehr große Rolle. Aber in diesem Fall ist die Netzwerktechnik und Architektur leider nicht leicht veränderbar. Es wird jedoch von Experten die Meinung geteilt, dass Applikationen welche große Datenmengen untereinander austauschen, sehr selten sein werden. Derweil ist das Problem weniger eine Frage der Netzwerktechnologie als eine Frage von nationalen Interessen und des Budgets. Die entsprechende Netzwerktechnik und auch das Wachstum sind vorhanden Die unterschiedlichen Typen von verteilten Systemen Verteilte Systeme können auf zwei unterschiedliche Weisen kategorisiert werden. Zum einen ist eine Unterteilung auf Applikationsebene, zum anderen anhand ihrer Größe möglich. 16

31 Einblick in verteilte Systeme Kategorie: Applikation Werden verteilte Systeme auf der Applikationsschicht, also anhand der Applikationen, für welche sie bereitstehen, kategorisiert, ergeben sich folgende Typen: Compute Cluster/Grid Compute Cluster/Grids sind heutzutage die hauptsächliche Anwendung für verteilte Systeme. Die Verteilung von Batch-Aufgaben wird hierbei nicht auf die sehr homogene Welt der Clustersysteme beschränkt, sondern ist Rechenzentren übergreifend. Bei der Zusammenfassung von Clustern zu Gridsystemen gewinnt die eventuell vorhandene Inhomogenität der Rechnerarchitekturen mehr an Bedeutung. Scavenging Cluster/Grid Wie weiter oben bereits erwähnt, ist eine der größten Herausforderungen der Cluster- und Grid- Designer der Zusammenschluss sämtlicher auf der Welt verteilten Rechnerressourcen. Diese Ressourcen werden im Falle der örtlichen Nichtbenutzung geplündert, daher auch der Name Scavenging. Das große Problem, welches das verteilte System in diesem Falle zu lösen hat, ist die Inhomogenität der Ressourcen. Weiter unten wird die Middleware beschrieben, welche in diesem Fall die Vermittlung übernimmt. Auch das Scheduling- und Queuing-Prinzip ist eine wichtige Frage im Bereich dieser verteilten Architektur. Data Cluster/Grid Nach den Compute Cluster/Grids sind die Data Cluster/Grids die wohl derzeit am verbreitetste verteilte Architektur. Data Cluster/Grids ermöglichen überall in ihrem Bereich dem Benutzer Zugriff auf die vorhandene Datenkapazität und Information. Denkbar und umsetzbar ist der Gedanke der verteilten Datenbank gerade in medizinischen Anwendungen. Man denke hier an eine verteilte Datenbank für Transplantationsorgane oder Knochenmarkspender. 17

32 Einblick in verteilte Systeme Kategorie: Größe Die Evolution der verteilten Systeme machte eine Kategorisierung anhand ihrer Größe sinnvoll. In der nachfolgenden Abbildung sind die in Zukunft möglichen Typen aufgeführt (Abbildung 6). Abbildung 6 Kategorisierung der Gridsysteme nach Größe Clustersysteme Heutzutage existieren nahezu ausschließlich Clustersysteme. Diese sind meist auf einen Raum, wenn nicht sogar auf ein Rack o.ä. beschränkt. Cluster werden im Bereich von Universitäten und der Industrie eingesetzt, um umfangreiche Berechnungen auszuführen. Der Vorteil der örtlichen Begrenzung macht zum Teil sehr niedrige Latenzzeiten in der Netzwerkarchitektur technisch 18

33 Einblick in verteilte Systeme umsetzbar. Es ist hier möglich, mit Kabellängen von zum Teil nur 2 Metern eine Technik einzusetzen, welche aufgrund ihrer Datentransferleistung nur sehr kurze Distanzen überbrücken kann. Ein vielfach angesprochenes Thema bei Clustern ist die Wartung und die Auslastung. So kann es sein, dass für die zeitnahe Berechnung großer Jobs eine große Rechenkapazität vonnöten ist. Die Intervalle zwischen den Aufgaben können jedoch so groß sein, dass der gesamte Cluster zeitweise brach liegt. Auch hier wäre eine Vermietung an andere Institutionen denkbar und würde zur Kosteneinsparung beitragen. Intra Grids Unter diesem Begriff versteht man die Verknüpfung mehrerer Cluster zu einem Grid. Diese Erweiterung zu einem abteilungs- oder sogar unternehmensweiten Grid zeigt schon einen Teil der Herausforderung an das Gridmanagement. Bei dieser Anwendung kommen bereits erste Accountingund Abrechnungsfunktionen zum Einsatz, um einen kontrollierten Ablauf zu gewährleisten. Einen spürbar steigenden Einfluss hat die Latenzzeit der Netzwerkverbindungen, die bei diesen meist räumlich schon weiter getrennten Systemen ansteigt. Ein Vorteil ist jedoch die meist unternehmensinterne Homogenität der Rechnerarchitekturen. Extra Grids Extra Grids sind der Zusammenschluss mehrerer Intra Grids über größere Distanzen und über Unternehmensgrenzen hinweg. Dieses Modell bedarf jedoch schon ausgeklügelter Authentifizierungsund Abrechnungsfunktionen. Eine Zugriffssteuerung muss hierbei nicht nur den erlaubten Zugriff steuern, sondern auch die Ressourcen je nach Vertrag bzw. Auflagen entsprechend verteilen. Auch reicht eine LAN-Netzwerktopologie nicht mehr aus. In diesem Fall müssen WAN und andere Langstrecken-Netzwerktechnologien zum Einsatz kommen. Ein schon vorhandenes Einsatzgebiet findet sich im Bereich von Universitäten und anderen Forschungseinrichtungen. Hierbei können Rechnerkapazitäten sehr effizient genutzt werden. Inter Grids Diese Art der Grids ist die letzte Entwicklungsstufe. Der Begriff ist mit Recht an den Begriff des Internets angelehnt. Diese Grids sind umfassend. Jeder kann Zugriff auf die vorhandenen Kapazitäten, seien es Rechen- oder Speicherkapazitäten, erhalten. Die Authentifizierungs- und Zugriffssteuerung mit Abrechnung und Monitoring stellt eine große Herausforderung an die Managementschicht dar. 19

34 Einblick in verteilte Systeme Es gibt bereits ehrgeizige Projekte, welche die Idee des globalen Gridsystems verwirklichen wollen. Diese Projekte sind unter anderem das Eurogrid oder das Tera Grid. Entwicklungen auf dieser letzten Stufe werden wohl noch mindestens 10 Jahre dauern Historie, Gegenwart und Zukunft Nachdem nun die Technologie hinter dem Schlagwort verteiltes System erklärt und differenziert wurde, ist die zeitliche Einordnung und die Geschichte ein hilfreiches Wissen, wenn es in den späteren Kapiteln um die einsetzbaren Techniken geht Die Evolution der Nachrichtendienste Die Evolution der Nachrichtendienste gründet auf der Entstehung des ARPANET, welches Anfang der 70er Jahre durch die Advanced Research Projekts Agency (ARPA), einer Abteilung des US- Verteidigungsministeriums, initiiert wurde. Die Anzahl der Knoten in diesem Netzwerk wuchs ständig an. Universitäten und Forschungseinrichtungen nutzten die neue Möglichkeit, Daten per Kabel zu verschicken. Im Jahr 1990 erfolgte der Startschuss für das Internet durch Stilllegung des ARPANET. Schon während der Entwicklung des Internets zu einem weltumspannenden Netzwerk war die Idee des Grid Computing in den Köpfen von Wissenschaftlern vorhanden. Der Informationsaustausch zwischen vielen verteilten Rechnern existierte bereits zu Zeiten des ARPANET. Der Mangel, dass die Rechner zwar Informationen, aber keine Rechenleistung austauschen, soll nun behoben werden. In Zukunft hat dieser Austausch an Ressourcen eine gleich große Bedeutung wie der Nachrichtenaustausch im Internet. Abbildung 7 veranschaulicht qualitativ die Evolution der digitalen Nachrichtendienste. 4 Die Problematik ist hier nicht nur auf Hard- und Softwareseite verankert, sondern besteht auch im Mangel der globalen Einigung und Verständigung der verschiedenen Länder. 20

35 Einblick in verteilte Systeme Abbildung 7 Evolution der Nachrichtendienste Auf den Tag festgelegte Einweihungstermine mit einer zerschlagenen Champagnerflasche auf einem Fuzzball Router 5 gab es bei dem Selbstläufer Internet nicht. Aus diesem Grund lassen sich die einzelnen Phasen nicht auf das Jahr genau voneinander trennen Die Evolution der verteilten Systeme Eine schwierige Frage ist die nach der genauen Spezifikation von verteilten Systemen. Die gegebene Antwort hängt vom Einsatzzweck des Systems ab. Eine Art Cluster- oder Gridcomputing zu betrachten, ist die der Metacomputing-Architektur, welche natürlich Auswirkungen auf viele Bereiche haben kann. Mit einem Satz lassen sich verteilte Systeme wie folgt erklären: Ein Cluster bzw. Grid ist eine Zusammenfügung von verteilten Rechen-, Speicher- und Netzwerkressourcen, welche dadurch eine größere Performanz, besseren Zugriff auf Daten und mehr Service bieten. Im Falle eines Grids sind diese Ressourcen geographisch verteilt. Für diesen Einsatzzweck müssen zusätzliche Funktionen zur Verfügung gestellt werden. 5 Fuzzball Router waren die ersten Router des Internets. Bereits 50 von ihnen wurden in den frühen 80ern im Internet installiert. 21

36 Einblick in verteilte Systeme Die Leistung des Systems wird der Applikationsschicht zur Verfügung gestellt. Eine gleichwertige Definition lässt sich am besten finden und verstehen, wenn die Geschichte der Cluster- und Gridsysteme betrachtet wird. Viele wissenschaftliche Thematiken erfordern Rechenleistung auf dem Niveau eines Supercomputers. Wie in der Einführung bereits genannt, waren Anfang der 90er Jahre die in kleinen Stückzahlen gefertigten Mainframesysteme sehr teuer. Das war der Grund, warum zwei Spezialisten im Auftrag der NASA günstigere Rechnerarchitekturen erforschten. Durch ständige Weiterentwicklung auf diesem Gebiet und durch den Einstieg großer Firmen wie IBM und SUN Microsystems wurden schnell etliche Programme für verteiltes Rechnen geschaffen. Viele dieser Programme haben ihren Ursprung in Forschungsprojekten. So wurde 1989 die Parallel Virtual Machine (PVM) von Vaidy Sundaram vorgestellt, welche als Middleware Jobs auf verschiedene Clientsysteme verteilt. Im Jahre 1992 wurde das Message Passing Interface (MPI) von einer Gruppe der IEEE vorgestellt. Das MPI stellt eine einheitliche Schnittstelle für den Austausch von Nachrichten zwischen den Rechenknoten dar. Die Weiterentwicklung der Netzwerktechniken und immer höhere Bandbreiten mit niedrigen Latenzzeiten trugen zum Erfolg einer großen Anzahl von Clusterprojekten bei. Zur gleichen Zeit wurde der Grundstein für Gridsysteme von der Firma Genias aus Regensburg gelegt, welche eine Software mit dem Namen Codine zur Verteilung von Batch-Jobs auf Clustersystemen entwickelte. Die Firma änderte 1999 ihren Namen in Gridware. Im Jahr 1999 wurde eines der wichtigsten Open Source Projekte geboren: Globus. Ein großer Schritt war der Kauf der Firma Gridware von SUN Microsystems im Jahr Die Entwicklung der Software wurde weitergeführt und eine einheitliche Codebasis geschaffen. Im gleichen Jahr wurde diese neue Software mit dem Name Sun Grid Engine (SGE) veröffentlicht. Im Juli 2001 wurde der Code offen gelegt und das Grid Engine Projekt initiiert. In den folgenden Jahren hat ein richtiger Boom der Clustersysteme begonnen. Auch große Gridprojekte wurden gestartet, unter anderem die Open Grid Service Architecture (OGSA) im Januar Viele große Clustersysteme hielten Einzug in die Top der schnellsten Rechner der Welt

37 Anforderungen an Managementsysteme 3 Anforderungen an Managementsysteme Managementsysteme gehören zur nächsten Stufe in der Entwicklung der Rechnersysteme (vgl. Abbildung 7). Während es in kleineren Computernetzen mit einigen wenigen Rechnern leicht möglich ist, Turnschuhadministration zu betreiben, würde es in großen Netzwerken mit mehreren hundert oder sogar tausend Rechnern Tage dauern, die gleiche Aufgabe zu bewältigen. Zu diesen Aufgaben zählt nicht nur die Installation eines neuen Programms, sondern auch komplexere Tätigkeiten, wie zum Beispiel die Statusüberprüfung wichtiger Funktionen. Der Vorteil der räumlichen Nähe in den meist in einem Rack montierten Clustersystemen wird durch die sehr große Anzahl an Rechnern zunichte gemacht. Auch darf nicht zu sehr auf Homogenität der Systeme gehofft werden. Gerade im Bereich des Gridcomputing ist die Vielzahl an Rechnerarchitekturen und Systemen als Pluspunkt zu sehen. Eine allgemein gültige Aussage zu tätigen, welche Mindestanforderungen an ein Managementsystem gestellt werden ist nicht möglich. Es hängt vom jeweiligen Einsatzzweck ab, welche Unterstützung und welche Werkzeuge wünschenswert sind. Zum Teil können in die Managementsysteme eigene Skripte und Programme als vollwertiger Bestandteil eingebunden werden. Dadurch ist eine gute Anpassung an die örtlichen Gegebenheiten möglich. Es lässt sich jedoch eine Maximalanforderungsliste mit allen derzeit für den Einsatz in Cluster- und Gridsystemen nötigen und möglichen Werkzeugen erstellen. Die Betrachtung heutiger auf dem Markt 23

38 Anforderungen an Managementsysteme und im Internet verfügbarer Linux-basierter Systeme ergibt eine Vereinigungsmenge der Funktionen. In Tabelle 1 wurden die einzelnen Funktionen der aktuellen Managementsysteme aufgenommen. Dabei wurde darauf geachtet, die Begriffe so allgemein wie möglich und zugleich so präzise wie nötig zu wählen. Der Schwerpunkt wurde dabei auf Funktionen gelegt, welche für den Betrieb eines Clusters oder eines Grids relevant sind. Eine strikte Unterscheidung und Zuordnung der Funktionen der Managementsysteme zu den jeweiligen Begriffen ist schwierig. Die Betrachtung der aktuell auf dem Markt verfügbaren Systeme und Zuordnung ihrer Funktionen findet in Kapitel 4 statt. Softwarelizenzierungsmodell Support Managementfunktionen Monitoringfunktionen Hardware-Inventur Konfigurationsverwaltung Repository Lights-Out-Management (LOM) Health-Check Benutzerverwaltung Parallele Programmierumgebungen Parallel Virtual Machine (PVM) Message Passing Interface (MPI) OpenMP High Performance Fortran (HPF) LAM/MPI MPI/CH Scali MPI Ohio State University (OSU MPI) 24

39 Anforderungen an Managementsysteme Ressourcenmanagementsysteme OpenPBS Sun Grid Engine (SGE) Globus openmosix Unterstützte Hardware Unterstützte Architektur Unterstütztes Netzwerk Ethernet InfiniBand Myrinet Quadrics SCI Unterstützte Betriebssysteme Master Clients Unterstützte verteilte Dateisysteme (Clusterdateisysteme) Tabelle 1 Funktionen der Managementsysteme In den nachfolgenden Unterkapiteln werden die oben aufgeführten und für das Cluster- und Gridmanagement wichtigen Funktionen und Programme evaluiert und erklärt. Die Liste hat keinen Anspruch auf Vollständigkeit, jedoch wurde versucht, alle relevanten Eckpunkte für das Management einer großen Zahl von Rechnern im Verbund einzugehen. Zusätzlich wurde das Management der Cluster- und Gridsoftware evaluiert. 25

40 Anforderungen an Managementsysteme 3.1 Softwarelizenzierungsmodell Unter welcher Lizenz eine Software auf den Markt gebracht wird, unterliegt der Entscheidung des Programmautors bzw. der Softwarefirma. Die Software kann unter einer proprietären oder unter einer freien Lizenz (Open Source) veröffentlicht werden. Einschränkungen existieren, wenn Programmteile oder ganze Programme der Programmsuite von einem anderen Projekt übernommen wurden welches unter einer speziellen Lizenz, zum Beispiel der GPL (General Public Licence), steht. Neben der GPL gibt es eine ganze Reihe weiterer Lizenzen für Software. Eine anschauliche Darstellung der unterschiedlichen Softwarelizenzierungsmodelle findet sich auf der Seite Nachfolgende Abbildung (Abbildung 8) veranschaulicht grafisch die gängigsten Softwarelizenzierungsmodelle und ihre Verknüpfungen untereinander. Abbildung 8 Grafische Gegenüberstellung der verschiedenen Softwarelizenzierungsmodelle 26

41 Anforderungen an Managementsysteme 3.2 Support Ein wichtiger Aspekt bei der Anschaffung und beim Betrieb eines Cluster- oder Gridsystems ist die Unterstützung des Herstellers. Eine kleine Anzahl Supercomputer der Top Liste der schnellsten Rechner der Welt trägt in der Beschreibung das Stichwort self-made. Bei diesen Systemen kann von einem engagierten Team von Administratoren ausgegangen werden, welches die Pflege und Verwaltung des Systems ausführt. Nur in seltenen Fällen und bei kleineren Systemen wird der Hardware-Support ebenfalls durch ein internes Team geleistet. In den meisten Fällen ist nicht nur der Hardware-Support, sondern auch die Administration durch ein externes Unternehmen gewährleistet, welches auch die Software für die Anlage verwaltet. Bei großen Systemen ist eine Einteilung der Tätigkeiten in verschiedene Bereiche von selbst gegeben und nicht anders durchführbar. Die Administration und Wartung der Rechner und Software wird vom Hersteller und Lieferanten der Software übernommen. Die Administratoren vor Ort haben also die Hände frei, sich um die Belange der Benutzer des Systems zu kümmern. Die Reaktionszeiten des Supports sind ein wichtiger Kostenfaktor. Je größer das System, desto teurer jede Minute Stillstand. Wie bei jedem Produkt ist auch beim Wartungsvertrag das Preis/-Leistungsverhältnis ausschlaggebend. Aus diesem Grund sind die Supportmöglichkeiten des Herstellers der Managementlösung von großer Wichtigkeit und werden beim Vergleich der Systeme in Kapitel 4 aufgeführt. Es bleibt dem Entscheider überlassen, die Softwarepflege des Systems dem Administrator vor Ort zu delegieren oder den Support des Herstellers in Anspruch zu nehmen. Bei vielen Open Source Projekten helfen Firmen aus, um die Supportlücke zu schließen. In manchen Fällen sind Internetforen und Mailing-Listen die einzige Möglichkeit, bei einem gegebenen Problem Hilfe zu bekommen. 27

42 Anforderungen an Managementsysteme 3.3 Managementfunktionen Dieses Unterkaptitel befasst sich mit den essentiellen Managementfunktionen einer Cluster- und Gridmanagementlösung. Diese Funktionen dienen dem Analysieren, Evaluieren und Lösen von anstehenden Tätigkeiten und eventuell auftretenden Problemen Monitoringfunktionen Monitoringfunktionen sind bei Systemen für verteiltes Rechnen eine grundlegende Einrichtung. Mit ihrer Hilfe kann der Administrator Daten über die Auslastung, den Speicherverbrauch, die Temperatur und andere Faktoren überwachen, speichern, auswerten und gegebenenfalls eingreifen. Teile dieser Informationen können in vereinfachter Weise dem Benutzer zugänglich gemacht werden. Dieser ist dadurch in der Lage, den optimalen Ort und Zeitrahmen für seinen Job auszuwählen. Oft besitzen diese Monitoringwerkzeuge eine Weboberfläche mit einer darunter liegenden aktiven Serversprache. Dadurch ist es leicht möglich, die Funktionalität an verschiedenen Orten ohne größeren Aufwand und Sicherheitsprobleme anzubieten. Ein solches Werkzeug ist Ganglia 7. Für den Aufbau des Grid wurde Ganglia als Projekt der Universität von Kalifornien initiiert. Es entwickelte und verbreitete sich schnell und ist auf vielen self-made Clustern und ebenso auf vielen kommerziellen Clustern anzutreffen. Das Ganglia Toolkit Nachfolgend wird die allgemeine Funktion der Monitoringwerkzeuge anhand des Ganglia Toolkit erläutert. Ganglia besteht aus mehreren Werkzeugen der Kommandozeile und mehreren Daemons. Die beiden wichtigsten Daemons sind

43 Anforderungen an Managementsysteme gmond und gmetad, wobei der erste auf jedem Clusterknoten und der zweite nur auf dem Masterknoten läuft. gmond sammelt die Informationen auf dem Rechenknoten und sendet sie per Multicast an gmetad und an die anderen Überwachungs-Deamons. Aus diesen Multicasts zieht sich der gmetad seine Informationen, sammelt und verarbeitet sie weiter (siehe Abbildung 9). Durch dieses dezentrale System ist Ganglia sehr ausfallsicher und ressourcensparend. Zudem sind auch die einzelnen Knoten über den Zustand des ganzen Clusters informiert, ohne dass eine obere Instanz die Information bereit hält. Abbildung 9 Nachrichtenverteilung in Ganglia Die Auswertung der Daten erfolgt mit Hilfe einer speziellen Datenbank (Round Robin Database, RRDtool). Durch Installation des Ganglia Web-Paketes und eines Webservers mit PHP-Unterstützung können die Daten in einem Browser ausgegeben werden. In Abbildung 10 ist der Ganglia-Monitor des Berkeley Millennium Projekts 8 abgebildet. Neben der grafischen Umsetzung der Ergebnisse im Browser, lassen sich die Werte auch auf der Kommandozeile auslesen. Die starke Verbreitung verdankt Ganglia auch in großem Maße der Kompatibilität mit vielen unterschiedlichen Plattformen, wie Linux, FreeBSD, Solaris, Mac OS X, AIX, IRIX, HPUX, Cygwin und True

44 Anforderungen an Managementsysteme Abbildung 10 Ganglia-Monitoring im Browser Das Ganglia Toolkit verfügt über eine riesige Anzahl an Zustandsinformationen des einzelnen Rechners. Diese können entweder über die Kommandozeile oder durch eventuelle Modifikation der XML-Vorlagen auch im Webbrowser ausgelesen werden. Nachfolgende Tabelle 2 enthält die aktuell auslesbaren Messgrößen und ihre Beschreibung sowie die unterstützten Plattformen: Messgröße Beschreibung Plattform boottime Zeitstempel seit Starten des Systems Linux, FreeBSD bread_sec Gepufferte Lesezugriffe Solaris bwrite_sec Gepufferte Schreibzugriffe Solaris bytes_in Eingegangene Bytes pro Sekunde Linux, FreeBSD, HPUX, Solaris bytes_out Ausgegangene Bytes pro Sekunde Linux, FreeBSD, HPUX, Solaris cpu_aidle Prozentuale Leerlaufzeit der CPU seit Starten des Systems Linux 30

45 Anforderungen an Managementsysteme cpu_idle Aktuelle, prozentuale Leerlaufzeit der CPU Linux, FreeBSD cpu_intr Verbrauchte Zeit durch Interrupt-Behandlung HPUX cpu_nice Prozentuale Belastung der CPU durch Hintergrundprozesse Linux, FreeBSD, HPUX, True64 cpu_num Anzahl der Prozessoren alle Plattformen cpu_speed Taktfrequenz der Prozessoren alle Plattformen cpu_ssys Zeit des Prozessors im Kernel-Modus HPUX cpu_system Prozentuale Belastung der CPU durch das System Linux, FreeBSD, HPUX, Solaris, True64 cpu_user Prozentuale Belastung der CPU durch Benutzer Linux, FreeBSD, HPUX, Solaris, True64 cpu_wait Verbrauchte Wartezeit HPUX cpu_wio Verbrauchte Zeit beim Warten auf I/O Solaris disk_free Freier Plattenspeicher insgesamt Linux, FreeBSD disk_total Plattenspeicher insgesamt Linux, FreeBSD load_fifteen Durchschnittliche Belastung in den letzten 15 min. alle Plattformen load_five Durchschnittliche Belastung in den letzten 5 min. alle Plattformen load_one Durchschnittliche Belastung der letzten Minute alle Plattformen location GPS Koordinaten der Maschine alle Plattformen lread_sec Lineare Lesezugriffe pro Sekunde Solaris lwrite_sec Lineare Schreibzugriffe pro Sekunde Solaris machine_type Typ der Maschinenhardware alle Plattformen mem_buffers Größe des gepufferten Speichers Linux, FreeBSD, IRIX mem_cached Größe des gecachten Speichers Linux, FreeBSD, HPUX mem_free Größe des verfügbaren Speichers alle Plattformen mem_shared Größe des gemeinsam geteilten Speichers Linux, FreeBSD mem_total Größe des verfügbaren Speichers Linux, FreeBSD mtu Maximale unfragmentiert übertragbare Datenmenge Linux, FreeBSD os_name Name des Betriebssystems Linux, FreeBSD os_release Version des Betriebssystems Linux, FreeBSD part_max_used Maximaler prozentualer Speicherplatzverbrauch auf Linux, FreeBSD allen Partitionen phread_sec Physikalische Lesezugriffe pro Sekunde Solaris phwrite_sec Physikalische Schreibzugriffe pro Sekunde Solaris pkts_in Eingegangene Pakete pro Sekunde Linux, FreeBSD 31

46 Anforderungen an Managementsysteme pkts_out Ausgegangene Pakete pro Sekunde Linux, FreeBSD proc_run Anzahl der laufenden Prozesse Linux, FreeBSD proc_total Anzahl der Prozesse insgesamt Linux, FreeBSD rcache Anzahl der Speicherlesezugriffe pro Sekunde Solaris swap_free Größe des unbenutzten SWAP in MB Linux, FreeBSD swap_total Größe des SWAP insgesamt Linux, FreeBSD sys_clock Aktuelle Rechnerzeit Linux, FreeBSD wcache Anzahl der Speicherschreibzugriffe pro Sekunde Solaris Tabelle 2 Von Ganglia unterstützte Monitoring Messgrößen Die oben genannte Tabelle hat keinen Anspruch auf Vollständigkeit. Funktionen werden hinzugefügt und eventuell auch wieder entfernt Hardware-Inventur Hardware-Inventur wird eher in großen Client/Server Netzwerken benötigt. Die Clients geben Informationen wie Art und Taktfrequenz des Prozessors, Speicherausbau, Netzwerkkonfiguration und Kapazität der Festplatte(n) an den Server weiter. Anhand einer grafischen Auswertung dieser Ergebnisse könnte der Administrator eine Übersicht aller Rechner mit zum Beispiel weniger als 1 GB Arbeitsspeicher erstellen. Auf diesen Ergebnissen könnte später die Wahl des Rechnerpools für die Berechnung eines Jobs gründen Konfigurationsverwaltung Die Konfigurationsverwaltung dient dem Wiederherstellen bestimmter Konfigurationen. 9 Man stelle sich ein verteiltes System vor, bei welchem abends die Rechner durch Einspielen einer spezifischen Konfiguration zum Clusterknoten werden und morgens die Konfiguration als wissenschaftlicher Arbeitsplatz für die Mitarbeiter wiederhergestellt wird. Im kleineren Rahmen kann dies auch die Verwendung zweier inkompatibler Middlewarelösungen im Cluster erleichtern. Für große verteilte Systeme kann eine Konfigurationsverwaltung helfen, unterschiedliche Gruppen von Rechnern mit gleicher Software und Einstellungen auszustatten. 9 Unter Konfigurationen versteht man in diesem Kontext Zusammenstellungen bestimmter Software und Einstellungen. 32

47 Anforderungen an Managementsysteme Repository Server mit Repository-Unterstützung verwalten einen bestimmten Bestand an Softwarepaketen. Diese können zum Beispiel durch Nachfrage bei einem übergeordneten Server aktualisiert werden. Ein Beispiel ist der YOU-Server (YaST Online Update) von SUSE Linux. Die Verteilung der Software an die Clients übernimmt ein Scheduler zu einem bestimmten Termin. Das Entfernen von Paketen ist umgekehrt auch möglich Lights-Out-Management (LOM) Lights-Out-Management stellt Funktionen wie Hardware-Reset, Reboot und das Auslesen bestimmter Sensoren für Temperatur, Lüfterdrehzahl, etc. bereit. Die Softwarefunktionalität muss dabei natürlich auf entsprechender Hardware gründen. Ein weit verbreiteter Industriestandard ist IPMI (INTELs Intelligent Platform Management Interface). Neben IPMI gibt es eine Reihe anderer firmenspezifischer Sensorchips mit eingeschränkteren Möglichkeiten. Viele dieser Chips werden durch die Treiber des lm_sensors Projekt 10 unterstützt. Sie können Temperatur und Lüfterdrehzahl auslesen. Für eine Unterstützung des Hardware-Reset und Reboot muss ein spezieller Out-Of-Band Chip eingesetzt werden. Dieser intelligente Mikrocontroller (Baseboard Management Controller, BMC) bildet das Herzstück des LOM und sorgt für das hardwareseitige Wohlergehen des Systems. Er sammelt Informationen und kann auf festgelegte Ereignisse reagieren Health-Check Unter Health-Check versteht man das Überwachen bestimmter Dienste. Am Health-Check Modul können besondere Dienste registriert werden, welche dann in regelmäßigen Abständen auf Funktion überprüft werden. Der Health-Check kann auch die Überwachung vorher definierter Eckwerte, wie zum Beispiel Prozessorauslastung übernehmen

48 Anforderungen an Managementsysteme Benutzerverwaltung Ein zentraler Aspekt großer Cluster- und Gridsysteme ist die Benutzerverwaltung. Verschiedene Benutzer benötigen verschiedene Benutzerrechte. Allein das Pflegen aller Benutzer-Accounts von Hand auf allen Rechnern im Cluster würde viel Zeit verschlingen. Eine einfache Implementierung ist das Duplizieren der Benutzerdatenbank auf alle Rechner oder der Einsatz eines NIS-Servers. 3.4 Parallele Programmierumgebungen Das Kernelement eines Cluster- bzw. Gridsystems bildet die parallele Programmierumgebung. Durch Parallelisierung werden Prozesse in Teilstücke aufgeteilt, welche parallel und zeitgleich auf verschiedenen Rechnern ausgeführt werden können. Diese Aufteilung kann durch den Programmierer der Anwendung geschehen, welcher explizit die Aufteilung eines Prozesses in mehrere Threads unternimmt. Andernfalls erfolgt diese Aufteilung automatisch, so dass kausal unabhängige (nebenläufige) Anwendungen entstehen. Die Aufteilung kann vom Compiler vorgenommen werden. Der Erfolg der Clustersysteme beruht auf der Entwicklung von Message Passing Bibliotheken (Message Passing Libraries). PVM und MPI sind die erfolgreichsten unter ihnen. Diese Bibliotheken anhand ihrer Fähigkeiten und Funktionen zu vergleichen, ist ein falscher Ansatz. Solche Vergleiche sind irreführend, zumal beide Systeme für unterschiedliche Funktionen die gleichen Namen benutzen Parallel Virtual Machine (PVM) Die Parallel Virtual Machine (PVM) 11 wurde entwickelt, um ein Netzwerk aus heterogenen Rechnern zu einem verteilten, parallelen, virtuell monolithischen System zusammenzuschließen. Die erste Version von PVM wurde 1989 von Vaidy Sunderam und Al Geist am Oak Ridge National Laboratory entwickelt. Zunächst war diese Entwicklung nur für den internen Gebrauch bestimmt und nicht für die Öffentlichkeit. Diese frühe Version war nur für Unix verfügbar

49 Anforderungen an Managementsysteme 1991 wurde PVM an der Universität von Tennessee komplett neu geschrieben und als Version 2.0 herausgegeben. Als Verbesserung wurde mehr Wert auf eine klare Spezifikation, mehr Robustheit und große Portabilität gelegt. Eine erneute Neuauflage 1993, die zu Version 3.0 führte, versprach mehr Skalierbarkeit und noch mehr Portabilität. Hinzu kamen die Unterstützung für Linux und Windows. Die aktuellste Version ist vom September Um die Entwicklung von PVM auf einen Nenner zu bringen: PVM war die Anstrengung einer einzelnen Forschungsgruppe. Aus diesem Grund sind Merkmale wie Fehlerbehandlung rudimentär ausgefallen. Eine aktive Weiterentwicklung erfolgt nicht, dennoch hat PVM einen entscheidenden Einfluss auf die Entwicklung verteilter Systeme und Gridcomputing gehabt. Einen kommerziellen Support sucht man leider vergebens. Neue Versionen enthalten keine neuen Features, sondern lediglich Bugfixes. Der Aufbau PVM bietet ein Framework aus Libraries, Runtime-Environment und Hilfsprogrammen für die Erstellung von PVM-Programmen in C, C++ und Fortran. Zusätzliche Projekte liefern Unterstützung für Perl, Python und Java (jpvm). Der Grundsatz, dass PVM die zugrundeliegende Architektur verschleiert, ermöglicht es dem Programmierer, sich nicht um die spezifischen Merkmale der Plattform kümmern zu müssen. Das Hauptmerkmal von PVM ist die dynamische Prozesserzeugung. Diese kann vor der Programmausführung oder dynamisch während der Programmausführung erfolgen. Die virtuelle Maschine Die besagte Unabhängigkeit der zugrundeliegenden Architektur wird durch den Einsatz eines angepassten PVM-Daemon bereitgestellt (pvmd). Dies bedeutet, dass der pvmd auf jeder Maschine laufen muss. Seine Aufgabe ist nicht nur die Kommunikation. Er ist auch die zentrale Instanz für das Task-Management und die Kommunikation der PVM-Tasks auf dem Rechner. Der erste im Netzwerk gestartete pvmd wird der Master pvmd. Dieser ist verantwortlich für das Starten der Slave pvmds auf den anderen Rechnern im Netz. Das Starten des Master pvmds und der Slave pvmds wird normalerweise über die PVM-Konsole erledigt. Diese Konsole erlaubt es dem Anwender, neue PVM- Rechner hinzuzufügen oder PVM-Programme zu starten. Anstatt der Konsole lassen sich auch Library-Funktionen hierfür verwenden. Neben der Konsole existieren grafische Werkzeuge, zum Beispiel xpvm, mit dessen Hilfe sich die PVM auch grafisch überwachen lässt (siehe Abbildung 11). 35

50 Anforderungen an Managementsysteme Abbildung 11 xpvm als grafisches Benutzerwerkzeug für PVM Der Master pvmd verbindet sich mit seinen Slave pvmds entweder über rsh, ssh oder rexec. Während der Ausführung eines PVM-Programms gibt es zwei Arten von Kommunikation: Task-zu-pvmd und pvmd-zu-pvmd. Eine Task-zu-Task Kommunikation findet nicht statt Message Passing Interface (MPI) Die Spezifikationen, welchen MPI unterliegt, werden vom MPI Forum 12 herausgegeben. Dieses Forum wurde 1993 von mehreren Hardware- und Softwareherstellern und Entwicklern ins Leben gerufen. Vertreten sind unter anderem viele Universitäten, die Firmen Hewlett-Packard, INTEL, NEC, Sun Microsystems und viele weitere. Die erste MPI-Spezifikation (MPI-1) wurde 1994 veröffentlicht

51 Anforderungen an Managementsysteme Der weiterentwickelte Standard erschien im Jahr 1997 mit Version MPI-2. Die vom MPI Forum angestrebten Ziele lauten wie folgt: MPI ist eine Library für die Programmierung von Programmen, nicht von verteilten Betriebssystemen. (Daraus ergibt sich die Unabhängigkeit vom Ressourcenmanagement). Die MPI-Spezifikation schreibt keine Thread-Sicherheit 13 vor, erlaubt jedoch die freie Implementierung dieser Technik. MPI soll in der Lage sein, auf leistungsfähigen Systemen hohe Performanz zu erreichen. (Aus diesem Grund gibt es keine Speicherkopien). MPI ist modular aufgebaut, um die Entwicklung zu beschleunigen. (Dies bedeutet auch, dass Verweise nur auf ein Modul und nicht auf das gesamte Programm zeigen). MPI ist darauf ausgerichtet, zukünftige Bedürfnisse und Entwicklungen zu erfüllen. (Aus diesem Grund ist MPI objekt-orientiert aufgebaut und viele Funktionen sind ähnlich zu C und Fortran). MPI unterstützt heterogenes Rechnen. MPI soll ein gut definiertes Verhalten zeigen. (Dies bedeutet, dass die Funktion und das Verhalten nicht von der Implementierung abhängt). Der zugrundeliegende Standard fordert eine Implementierung auf höchstem Niveau. Dies beinhaltet eine korrekte Fehlerbehandlung im Gegensatz zu PVM, welches bei einem Fehler einfach abbricht und keine Unterscheidung zwischen wiederherstellbaren und nicht-wiederherstellbaren Fehlern bietet. Aufgrund der klaren Spezifikation wird der MPI-Standard weit verbreitet eingesetzt und implementiert. Es gibt neben kommerziellen MPI-Implementierungen, wie zum Beispiel Scali MPI, auch Open Source Implementierungen, wie zum Beispiel das weit verbreitete MPICH. MPI ist für C und Fortran verfügbar. In den nachfolgenden Unterkapiteln werden die drei wichtigsten MPI-Implementierungen (LAM/MPI, MPICH und Scali MPI) der MPI-Spezifikation genauer betrachtet. 13 Thread-Sicherheit (engl., thread-safety) ist die Kontrolle bezüglich konkurrierenden Zugriffs auf den Adressraum mehrerer parallel ablaufender Threads. Diese Sicherheit kann zum Beispiel durch gegenseitigen Ausschluss erfolgen (engl. = mutual exclusion). 37

52 Anforderungen an Managementsysteme LAM/MPI Das Local Area Multicomputer/Message Passing Interface (LAM/MPI) 14 ist eine Open Source Implementierung der MPI-Spezifikation mit allen Funktionen von MPI-1.2 und Teilen von MPI-2. Ursprünglich wurde es am Ohio Supercomputing Center entwickelt und wird nun an der Universität von Indiana vom Open Systems Laboratory betreut. Als Einsatzzweck ist Produktion und Forschung angegeben. LAM/MPI wird mit einem Set an Funktionen für Systemadministratoren, Programmierer paralleler Anwendungen, Anwender und Forscher (= System Service Interface) ausgeliefert. Neben Unterstützung für ein Globus-basiertes Grid existiert eine Unterstützung für Myrinet. Es ist auf fast allen Unix-Systemen lauffähig und es mangelt nur an einer Unterstützung für Windows. MPICH Seit dem 24. Juni 2005 ist die Version des Message Passing Interface Chameleon (MPICH) 15 verfügbar. Parallel dazu erschien am 10. Juni 2005 die MPICH2 16 Version Sie verspricht MPI-1 und MPI-2 Funktionalität. MPICH und MPICH2 sind Open Source und stehen unter einer freien Lizenz. MPICH2 soll Stück für Stück MPICH ablösen. Es werden mehrere Linux-fähige Architekturen (x86_32, x86_64, ia64, Alpha) unterstützt. Neben Unix existiert auch Unterstützung für Windows NT und Somit lassen sich heterogene Umgebungen realisieren. Entwickelt wird MPICH am Argonne National Laboratory. Auf MPICH (MPI-1) basierend wurde von mehreren namhaften Herstellern das MVAPICH 17 (MPI-1 über VAPI für InfiniBand), auch genannt Ohio State University MPI (OSU MPI), ins Leben gerufen, um eine native Unterstützung für InfiniBand anzubieten. Die derzeit aktuelle Version ist MVAPICH

53 Anforderungen an Managementsysteme Scali MPI Connect Scali MPI Connect ist eine kommerzielle Implementierung des MPI-1.2 Standards für den Unternehmenseinsatz mit Support und einer Unterstützung für eine Vielzahl an Interconnects (TCP/IP, Fast Ethernet, Gigabit Ethernet, SCI, Myrinet und InfiniBand). Die Merkmale von Scali MPI Connect sind unter anderem: Interconnect-unabhängige Architektur Dynamische Wahl des Interconnects während des Betriebs Interconnect-Failover Funktionalität Unterstützung für heterogene Konfigurationen Thread-Sicherheit Ein kommerzieller Support ist meist an bestimmte Auflagen gebunden. Eine dieser Auflagen ist die Benutzung eines der folgenden Linux Systeme: Red Hat Linux, Red Hat Enterprise Linux oder SUSE Linux Enterprise Server. Unterstütze Architekturen sind: x86_32, x86_64, ia64, Power4, Power5 und PowerPC. Aufgrund des kommerziellen Supports, der breiten Herstellerunterstützung und der hervorragenden Integration in Scali Manage ist Scali MPI Connect sicherlich eine gute Möglichkeit für Unternehmen mit Supportanspruch. Die Installation wird entweder komfortabel mit Hilfe eines Installationsskripts oder durch Scali Manage durchgeführt. Das technische Verfahren basiert auf einem Master/Slave Daemon Prinzip, wobei die Daemons die Jobs zur Ausführung bringen bzw. die Jobs vom Master-Daemon annehmen. Die Latenzzeiten und Bandbreiten für Scali MPI Connect beziffert Scali folgendermaßen (gemessen mit einem ping-pong-half Testverfahren 18 ): 18 Beim ping-pong-half - Test wird eine MPI-Nachricht mit der Länge 0 einmal hin und her geschickt. Die Zeit wird gemessen und durch zwei geteilt. Dieser Test entspricht bei weitem nicht der realen Latenzzeit, wird aber verwendet, um die Latenzzeiten der unterschiedlichen Hochgeschwindigkeits-Interconnects zu vergleichen. 39

54 Anforderungen an Managementsysteme Interconnect Latenzzeit Bandbreite Gigabit Ethernet 26,2 µs 222 MByte/s InfiniBand 5,6 µs 820 MByte/s InfiniBand/Express 4,3 µs 1838 MByte/s Myrinet 7,7 µs 490 MByte/s SCI 4,3 µs 385 MByte/s Tabelle 3 Latenzzeiten und Bandbreiten bei Scali MPI Connect /SCA01/ Ein großer Vorteil von Scali MPI Connect ist die Möglichkeit, automatisch oder manuell während der Laufzeit das Interconnect zu wechseln. Mehr Informationen zu Scali MPI Connect und zur Einbindung in Scali Manage finden sich in Kapitel OpenMP Open specifications for Multi Processing (OpenMP) 19 ist ein offener API-Standard für die Parallelisierung von C, C++ und Fortran Programmcode. Die erste Spezifikation erschien im Frühling Im Mai 2005 wurde Version 2.5 dieses Standards vom OpenMP Architektur Besprechungsausschuss herausgegeben. Mit dieser Versionsnummer wurde das Ziel verfolgt, C, C++ und Fortran in einer Version zu kombinieren. Viele namhafte (Software-) Hersteller sind Mitglied in diesem Gremium, unter anderem Hewlett-Packard, INTEL, SGI, Sun Microsystems und Portland Group. Die Ziele dieses Gremiums für den OpenMP-Standard sind: Standardisierung: Ein Standard für eine Vielzahl an Architekturen und Plattformen Einfach und schmal: Komplexe Direktiven werden aus mehreren einfachen Direktiven zusammengestellt Leichte Benutzung: Leichte Parallelisierung serieller Programme Portabilität: Unterstützung für Fortran 77/90/95, C und C++ OpenMP enthält Compiler Direktiven, Laufzeit Libraries, Routinen und Umgebungsvariablen, um zum Beispiel eine Schleife auf mehreren Rechnern parallel auszuführen. Die Granularität von

55 Anforderungen an Managementsysteme OpenMP ist auf Thread-Ebene angesiedelt. Betriebssystemunterstützung existiert für UNIX, Linux und Windows High Performance Fortran (HPF) Das High Performance Fortran Forum (HPFF) 20 ist ein Zusammenschluss aus Industrie, Forschung und Lehre mit dem Ziel, ein Erweiterungsset für Fortran 90 bereitzustellen. Die HPF-Erweiterung soll Zugriff auf eine hochperformante Architektur haben und dabei über Portabilität zwischen verschiedenen Plattformen verfügen. Diese Erweiterungen finden sich in einer Reihe kommerzieller sowie in freien Compilern wieder, so zum Beispiel im PGHPF von der Portland Group. 3.5 Ressourcenmanagementsysteme Wie bei der Auslastung eines öffentlichen Verkehrssystems, so kostet auch bei einem Cluster bzw. Grid jede nicht genutzte Rechenzeit unnötig Geld. So ist das Ziel der Ressourcenmanagementsysteme (Scheduler/Batch-Queuing-System) eine Auslastung von 100% zu erreichen. Unterschieden werden können die Ressourcenmanagementsysteme anhand ihrer Hierarchie und anhand der unterstützten Granularität. 21 Die Hierarchie der meisten Systeme ist linear. Dies bedeutet, dass der Masterknoten als obere Instanz die Aufgabe entgegennimmt, die Aufgabe gegebenenfalls zerteilt und den Rechenknoten zuweist. Bei einer flachen Hierarchie kann jeder Knoten selbst darüber bestimmen, welchem anderen Knoten er eventuell eine Aufgabe übergibt. Ein Prozess kann aus einem oder mehreren für den Prozessor ausführbaren Teilen, den sogenannten Threads, bestehen. Ein Scheduler mit einer bestimmten Granularität hat nun die Möglichkeit, einzelne Threads oder ganze Prozesse auszulagern Unter Granularität versteht man im Cluster und Gridumfeld die kleinste Einheit, in welche eine Aufgabe unterteilt werden kann. 41

56 Anforderungen an Managementsysteme Um dem Leser einen Einblick in die Ressourcenmanagementsysteme zu geben, werden vier der wichtigsten Ressourcenmanagementsysteme in den nächsten Unterkapiteln beschrieben. Diese sind: OpenPBS Sun Grid Engine (SGE) Globus openmosix OpenPBS Die Verbreitung der Clustersysteme brachte das vielfach als Batch- Queuing-System eingesetzte Network Queuing System (NQS) 22 an seine Grenzen. Aus diesem Grund wurde ein neues Batch-Queuing- System entwickelt und in IEEE POSIX d niedergeschrieben. Auf diesem Standard beruhend entwickelte die Firma Veridian in den frühen 90ern das Portable Batch System (PBS). Es existiert heute in zwei Versionen: Dem OpenPBS ohne Support und dem PBS Pro als Version für den Einsatz in Unternehmen übernahm die Firma Altair Grid Technologies die Rechte an PBS Pro. PBS Pro ist sicherlich einen Blick wert, vorausgesetzt es sind die entsprechenden Ressourcen verfügbar. Mangels der Unterstützung und weiteren Pflege kann der Einsatz von OpenPBS erschwert werden. Architektur OpenPBS basiert auf einem Client/Server-Modell. Die Organisation übernehmen mehrere Benutzerprogramme und drei Daemons (pbs_server, pbs_mom und pbs_sched). Eine Einbringung von Jobs erfolgt mit Hilfe der Benutzerprogramme. Verwaltet werden die Jobs wird durch die Daemons. Die Daemons und die Benutzerprogramme kommunizieren über das Netzwerk per TCP. Auf dem Masterknoten läuft der pbs_server und bildet das Herz von OpenPBS. Er stellt die folgenden Batch-Job Funktionen bereit: 22 Das NQS ist ein UNIX basierendes Batch Queuing System des NASA Ames Research Centers ( 42

57 Anforderungen an Managementsysteme Empfang Erstellung Modifizierung Schutz vor Absturz Starten Die Verwaltung der Jobs kann in mehreren Queues erfolgen. Dadurch ist eine feinere Handhabung der eingereihten Jobs möglich. Der pbs_mom 23 Daemon läuft auf jedem System im Cluster und ist zum einen für das Starten der jeweiligen Batch-Jobs und zum anderen für das Zurücksenden der Ergebnisse zuständig. Der pbs_sched Daemon hat die Aufgabe, die Ressourcen bereitzustellen. Er sorgt für die Kommunikation der beiden anderen Daemons und entscheidet über die Art und Weise, wie Jobs zur Ausführung gebracht werden. Die Algorithmen dahinter sind frei modifizierbar. Eine Übersichtsgrafik (Abbildung 12) veranschaulicht die Funktion der OpenPBS Daemons. Abbildung 12 Die OpenPBS Daemons und ihre Funktionen 23 Das mom in pbs_mom steht für Mother (engl. = Mutter), da dieser Daemon die Mutter der verteilten Prozesse ist. 43

58 Anforderungen an Managementsysteme Die Scheduler Server Interaktion Die frei wählbaren Regeln für das Scheduling sind ein Vorteil von OpenPBS. Die Kontrolle liegt nicht im Server (pbs_server). Der Server stößt den Scheduler bei bestimmten Ereignissen an. Diese Ereignisse können sein: ein neuer Job ist ausführbar: SCH_SCHEDULE_NEW ein ausgeführter Job endet: SCH_SCHEDULE_TERM das vorher festgelegte Zeitintervall ist abgelaufen: SCH_SCHEDULE_TIME das Server Attribut scheduling ist auf wahr gesetzt worden: SCH_SCHEDULE_CMD der Scheduler wurde aktiviert und verlangte vom Server nur einen Job (der Scheduler bekommt eine weitere Chance, noch einen Job zu verlangen.): SCH_SCHEDULE_RECYC der Server wurde soeben aktiviert: SCH_SCHEDULE_FIRST Sobald der Scheduler mit einem entsprechenden obigen Grund angestoßen wurde, wird der Scheduler privilegierter Benutzer auf dem Server. Er führt die benötigten Operationen aus und beendet danach die Verbindung zum Server Sun Grid Engine (SGE) SUN powers the grid heißt es in einem Werbeslogan von SUN Microsystems. Schaut man sich die Software des Unternehmens für die Cluster- und Gridtechnologie an, trifft dieser Slogan zu. Die Produkte SUN Grid Engine (SGE) und SUN Grid Engine Enterprise Edition (SGEEE) sind mit hochwertigen Funktionen ausgestattet. 24 Neben den kommerziellen SGE und SGEEE gibt es ein von Sun unterstütztes freies Projekt. 25 Die aktuelle Ausgabe dieses freien Ressourcenmanagers, genannt Grid Engine, ist Version 6.0 und basiert auf Quellen der kommerziellen Versionen. Die SGE ist auf der Applikationsebene angesiedelt und funktioniert sehr gut als Mitglied in einem Globusbasierten Grid

59 Anforderungen an Managementsysteme SGE gibt es nur für Linux und Solaris. Einen Windowsableger sucht man vergebens. Der Stabilität ist die Abwesenheit von Windows sicherlich zuträglich, steht jedoch der globalen Verbreitung und somit dem weltweiten Grid im Weg. Vielleicht trägt der Einstieg von Microsoft in die Welt der Supercomputer dazu bei, die Portierung sämtlicher Clusterservices auch auf Windows zu wagen. Die kommerzielle SGEEE Version zielt auf Unternehmen mit Supportanspruch ab. Jedoch kann die SGE mit Hilfe eines Flags als SGEEE kompiliert werden. Als SGE-Variante bietet sie zwar nicht den vollen Funktionsumfang wie die SGEEE, jedoch den gleichen starken Scheduler. Leider ist diese Version ungeeignet für große Gridsysteme, sie bietet aber die gleiche Funktionalität wie das Batch- Queuing-System OpenPBS. Grid Cluster für verteiltes Rechnen lassen sich darum hervorragend realisieren. Als SGEEE Variante kann sie als starkes Gridsystem verwendet werden. Ein weiterer Pluspunkt ist die Verträglichkeit der SGEEE als Gridressource in einem Globus Grid. Jobverarbeitung innerhalb der SGEEE Eine Bearbeitung eines Jobs innerhalb der SGEEE verläuft nach folgendem, stark vereinfachten und stilisierten Schema, wie in Abbildung 13 gezeigt. Es wird hierbei deutlich welcher Teil die SGE zur SGEEE vom System für verteiltes Rechnen zum Gridsystem erweitert (gestrichelte Linie). 45

60 Anforderungen an Managementsysteme Abbildung 13 Jobverarbeitung innerhalb der SGEEE Die Jobs (Batch-Jobs, interaktive und parallelisierte Jobs) erhält der qsub, welcher den Eingang von neuen Jobs dem qmaster meldet. Der Job wird registriert und seine Anforderungen werden bestimmt. Ebenso wird die Ankunftszeit gespeichert. Der qsub informiert den Scheduler, welcher den Job in der laufenden Jobliste platziert bzw. eine geeignete Ressource ausfindig macht. Durch Verwendung von Prioritäten können die Jobs noch individueller verwaltet werden. Für die Abarbeitung sorgen die Execution Daemons (execd) auf den einzelnen Rechnern. Eine Routine sendet Statusinformationen an den Master zurück, welcher eventuell regelnd eingreift. Nach Beendigung des Jobs wird eine Accounting Routine angeworfen, welche sich um die Abrechung der verbrauchten Leistung kümmert. Benutzungsrichtlinien der SGEEE Dem Administrator wird es mit Hilfe von Tickets ermöglicht, das Verhalten der Gridressourcen vorrangig zu steuern. Den Jobs können Prioritäten zugewiesen werden, welche auf den folgenden vier Richtlinien gründen: 46

61 Anforderungen an Managementsysteme Funktionelle Richtlinie: Die Prioritäten werden gemäß Benutzer, der Gruppenzugehörigkeit und dem Typ des Jobs eingeteilt. Verteilte, baumbasierende Richtlinie: Die Prioritäten werden anhand der vergangenen Benutzung und anhand der Rechte anderer Benutzer und Gruppen festgelegt. Deadline Richtlinie: Dem Job wird eine Deadline zugewiesen. Bei zeitlicher Annäherung an diese Deadline steigt seine Priorität. Beeinflussungsrichtlinie: Der Administrator kann manuell die Ausführung des Jobs initiieren. Die oben aufgeführten Richtlinien werden mit Hilfe eines Ticketmodells verwaltet und angewandt Globus Toolkit (GT) Den verschiedenen Middleware-Systemen für die Gridtechnologie liegen unterschiedliche Standards zu Grunde. Es haben sich während der Evolution der Gridsysteme mehrere Standardisierungsgremien gefunden bzw. wurden neu initiiert. Diese Gremien bilden den Rückhalt für die Middlewaretechnologien. Eines der wichtigsten Standardisierungsgremien ist Globus 26, besonders aufgrund seiner herausgegebenen Middleware, dem Globus Toolkit (GT) 27. Das Hauptaugenmerk von Globus liegt auf den Schnittstellen zu den Applikationen, welche durch diese Schnittstellen einfach und einheitlich entworfen werden können. Es existieren vier Bereiche des Gremiums: Applikation Forschung Software Werkzeuge Testumgebungen Durch diese Unterteilung sind die Schnittstellen organisch schon vorgegeben. Natürlich unterstützt das Globus Projekt das GT als Middleware

62 Anforderungen an Managementsysteme Die oben genannten Gremien geben nicht nur die Spezifikationen und Standards heraus, sondern bestehen zu großen Teilen aus Mitgliedern, die sich aktiv für die Software der Middleware einsetzen. Die viel genannte Offenheit der Software findet sich auch beim GT. Aus diesem Grund ist GT eine der größten Middleware Software. GT besteht aus Open Source Werkzeugen und Protokollen, welche dem Administrator die Konfiguration und Benutzung leichter machen sollen. Durch diese Werkzeuge lassen sich Datenbanken und Rechenleistung gut über geografische Grenzen hinweg verteilen und benutzen. Aufgrund der Offenheit der Werkzeuge und des breiten Anwendungsspektrums findet das GT große Aufmerksamkeit und Verbreitung an Universitäten und in Unternehmen. GT unterstützt folgende Anforderungen der Middleware: Sicherheit Ressourcen Management Portabilität Fehlererkennung Informationsverteilung Die einzelnen Module sind getrennt aufgebaut und können unabhängig oder zusammen agieren. Das Problem der heterogenen Architekturen kann mit GT umschifft werden und der Anwender kann mit Hilfe von einheitlichen Schnittstellen auf die entfernten Ressourcen zugreifen. Die starke Verbreitung sorgt dafür, dass viele Firmen ihre Software mit den Werkzeugen des GT erstellt und die vorgegebenen Standards übernommen haben. GT wurde entworfen, um folgende Grundlagen einer Gridinfrastruktur, wie sie zum Beispiel das GGF vorschlägt, zu erfüllen: Performance Skalierbarkeit Sicherheit Einheitlichkeit Eindeutigkeit Erweiterbarkeit Unterstützung für mehrere Quellen Dynamische Daten Flexibler Zugriff Ausnutzungsgrad Dezentralisierte Kontrolle 48

63 Anforderungen an Managementsysteme Als Protokoll für den Informationsaustausch verwendet GT das Lightweight Directory Access Protocol (LDAP) 28. Das LDAP ist ein Netzwerkprotokoll, welches die Abfrage und die Modifikation von Informationen eines Verzeichnisdienstes erlaubt openmosix Den Ursprung hatte Mosix 29 in den 80-er Jahren durch Studenten von Professor Amnon Barak von der Hebräischen Universität von Jerusalem. Der Startschuss für das openmosix Vorhaben war 2002, als das Mosix Projekt einen unfreien Weg einschlug, seinen Code nicht mehr unter die GPL stellte und somit die freie Weiterentwicklung von Mosix unter dem Namen openmosix 30 auslöste. Auch Mosix ist allerdings bei Annahme der Lizenz frei herunterzuladen. Dieses Kapitel konzentriert sich wegen der größeren Verbreitung und der aktiven Community auf openmosix. Das Entwicklerteam von openmosix mit seinem Teamleiter Dr. Moshe Bar arbeitet aktiv an Erweiterungen, welche openmosix flexibler machen sollen. Unter anderem wird an einem Netzwerk RAM Interface gearbeitet, durch welches ein Programm bei Bedarf auf den Arbeitsspeicher sämtlicher Knoten zugreifen kann (migshm). Mittlerweile kann openmosix weltweit mehr als 1000 Clusterinstallationen vorweisen, was nicht nur der äußerst engagierten Community zuzuschreiben ist. Für openmosix wurden direkt Änderungen am Linux Kernel vorgenommen. Dadurch lässt sich die sonst nötige Middleware für das verteilte Rechnen vermeiden. Durch diese Operation wird die Unabhängigkeit von der Programmiersprache ermöglicht. Kein Programm und kein Programmierer muss sich um die verteilte Ausführung seines Programms kümmern. Ressourcen können hinzugelinkt und wieder entfernt werden. Dadurch ergibt sich eine breite Palette an Anwendungsmöglichkeiten, vom Cluster für mathematische Berechnungen über eine Thin-Client-Architektur bis zu Serverfarmen mit Lastverteilung. Sämtliche Funktionen und Schnittstellen, die der Linux Kernel bietet, stehen im Rechnerverbund verteilt zur Verfügung. Wie aber dennoch Transparenz und Sicherheit gewährleistet werden kann, zeigen die nächsten Unterkapitel auf

64 Anforderungen an Managementsysteme Migrationsverhalten Eine transparente Ausführung sämtlicher Vorgänge im System und die damit verbundene Sicherheit sollte stets im Vordergrund stehen. Die Lösung dieses Problems wird bei openmosix durch die Aufspaltung eines Prozesses in seinen User- und Kernel-Space-Anteil ermöglicht. Abbildung 14 zeigt eine Darstellung des Betriebssystemaufbaus. Im Kernel-Space befinden sich die internen Informationen über den Prozess und sein derzeitiger Status, so zum Beispiel die Process ID (PID). Der User-Space-Anteil kann auf einen anderen openmosix Knoten verschoben werden. Der User- Space-Anteil ist also der Teil, welcher auf dem Kernel aufsetzt und die eigentliche Berechnung durchführt. Auf dem Unique-Home-Node (UHN) verbleibt nur der Systemteil. Die Kommunikation zwischen diesen beiden Teilen wird von openmosix übernommen. Abbildung 14 Betriebssystem - Aufbau Die Steuerung der Lastverteilung ist dezentral ausgelegt. Dies bedeutet, dass jeder Knoten seine migrierbaren Prozesse auf einen anderen Knoten verschieben kann. Es ist kein Master/Slave-Prinzip erkennbar. Ob ein Prozess migrierbar ist, wird anhand eingegangener Zustandsinformationen und anhand von Beobachtungen des Rechen- bzw. des Input/Output-Verhaltens des Prozesses festgestellt. Anhand von Statusinformationen anderer Knoten wird entschieden, auf welchen Knoten verschoben wird. Die Migration kann sowohl aufgrund der Prozessorlast als auch aufgrund von Speicheranforderungen, welche der UHN nicht oder nicht mehr erfüllen kann, festgelegt werden. Es wird ein Knoten gewählt, der die Speicheranforderungen erfüllen kann. Die Entwickler von openmosix nennen dieses Prinzip fork and forget. Der Benutzer initialisiert also das Programm und überlässt es sich selbst. Der Algorithmus hinter der Kostenfunktion, welche bei jedem Knoten die Leistungsdaten ermittelt, ist nicht trivial, jedoch in jedem Falle kohärent. Dies bedeutet, dass die Leistungsdaten mit Hilfe komplexer, in sich geschlossener Algorithmen gewonnen werden, welche den inneren Zusammenhang der derzeitigen Belastung gut nach außen repräsentieren. 50

65 Anforderungen an Managementsysteme Praxisbeispiel Abbildung 15 zeigt den schematischen Ablauf der Interknotenkommunikation zweier Knoten. Dabei ist deutlich zu sehen, dass der Systemteil der Prozesse nicht mitverschoben wird. Der Gastgeberknoten (Invitation Node, IN) hat keinen Zugriff auf den Gastprozess, d.h. er kann ihm keine Signale schicken oder ihn anderweitig beeinflussen. Abbildung 15 Funktionsweise von openmosix /LM01/ In der obigen Abbildung schickt Prozess A auf Knoten 1 Prozess B auf demselben Knoten ein Signal. Prozess B ist jedoch auf Knoten 2 migriert und erhält durch openmosix die Nachricht von Prozess A. Es handelt sich um eine Aufforderung, auf die Festplatte zu schreiben. Natürlich kann er nicht auf die Festplatte seines IN schreiben. Die Daten werden also wieder mit Hilfe von openmosix zurück auf die Festplatte von Knoten 1 geschrieben. Transparenz und Sicherheit Zur Evaluation und Veranschaulichung der Migration wird eine Berechnung gestartet, welche die gesamte Rechenleistung, die zur Verfügung steht, verbraucht. Zu sehen ist die Migration über den Migrationsmonitor der openmosix Benutzerwerkzeuge. Wird der Monitor gestartet, so wird ein Kreis um den UHN gezeichnet. Außerhalb des Kreises befinden sich die Gastgeberknoten (INs) (vgl. 51

66 Anforderungen an Managementsysteme Abbildung 16). Deutlich ist zu sehen, dass IN 2 und 3 von UHN 1 einen Prozess zugewiesen bekommen haben. Abbildung 16 openmosix Migration Monitor Beobachtet man in dieser Zeit die Prozesstabelle von Knoten 2 oder 3, so ist kein systemleistungsverbrauchender Prozess zu sehen, obwohl die Prozessorauslastung nahezu bei 100 % liegt (vgl. Abbildung 17). 52

67 Anforderungen an Managementsysteme Abbildung 17 openmosix Prozesstabelle Der Systemteil der migrierten Prozesse bleibt also auf dem UHN, während die Berechnungen auf einem anderen Knoten ausgeführt werden. Durch die Benutzerwerkzeuge von openmosix kann der migrierte Prozess wieder nach Hause geschickt bzw. nach Hause geholt werden. Die Prozessausführung auf INs ist also preemptive. Durch Abschalten der IN-Funktion seines Rechners kann jeder Benutzer seine Sicht auf den Cluster in einen einfachen, linearen Compute Cluster 31 wandeln oder durch Deaktivieren seiner eigenen Prozessmigrationsfähigkeit sein System in ein Single Prozessor System zurückstufen. Input/Output Probleme und Lösungen (DFSA) Obwohl openmosix mit prozessorlastigen Aufgaben sehr gut umgehen kann, hat es Schwierigkeiten mit Aufgaben, welche einen großen Ein- und Ausgangsdatenstrom haben. Diese I/O-intensiven Aufgaben müssen oft nach Hause telefonieren. Eine Lösung hierfür ist der Direct File System Access (DFSA). Durch diesen Standard können manche Befehle direkt auf dem IN ausgeführt werden. Ein Prozess kann durch diese Technik I/O-Operationen ausführen, ohne über seinen Home-Node gehen zu müssen. Tabelle 4 enthält eine Liste dieser Befehle. DFSA setzt auf einem verteilten Dateisystem wie GFS oder MFS auf. 31 Unter einem linearen Compute Cluster versteht man einen Cluster mit Master/Slave-Konzept, bei welchem die Jobs ausschließlich durch den Master initiiert werden und die Rechenknoten keinerlei Eingriffsmöglichkeiten haben. 53

68 Anforderungen an Managementsysteme read, readv, write, writev, readahead, lseek, llseek, open, creat, close, dup, dup2, fcntl/fcntl64, getdents, getdents64, old_readdir, fsync, fdatasync, chdir, fchdir, getcwd,stat, stat64, newstat, lstat, lstat64, newlstat, fstat, fstat64, newfstat, access, truncate,truncate64, ftruncate, ftruncate64, chmod, chown, chown16, lchown, lchown16, fchmod, fchown, fchown16, utime, utimes, symlink, readlink, mkdir, rmdir, link, unlink, rename Tabelle 4 Systemaufrufe über DFSA Der DFSA Standard unterliegt folgenden Spezifikationen: DFSA Spezifikationen Das Dateisystem ist auf allen Knoten identisch gemountet. Dateikonsistenz muss gewährleistet werden: Ändert ein Prozess auf einem beliebigen Knoten eine beliebige Datei, so muss die Änderung allen Knoten bekannt gemacht werden. Dies ist nötig, da openmosix hintereinander verschiedene Operationen auf Dateien anwenden kann. Ferner muss der Zeitstempel konsistent sein. Tabelle 5 DFSA Spezifikationen Beschränkungen Eine ganze Reihe von Programmen (= Prozessen) lassen sich nicht oder nicht sinnvoll migrieren. Verwendet ein Programm Shared oder Locked Memory oder hat es direkten Zugriff auf die Hardware, so ist eine Migration nicht möglich. Auch mehrere Klone des Prozesses, sogenannte Threads, können nicht getrennt voneinander verschoben werden. Ein Apache Webserver lässt sich auf diese Art und Weise leider nicht clustern, da nur seine Prozesse und nicht seine einzelnen Threads migriert werden können. Kurz gesagt, die Granularität von openmosix beschränkt sich auf den Prozess, der eine nicht weiter aufspaltbare Instanz darstellt. Auch einige Systemprozesse lassen sich sinnvollerweise nicht verschieben, unter anderem der init-prozess. Es können Migrationssperren für bestimmte Prozesse festgelegt werden. 54

69 Anforderungen an Managementsysteme 3.6 Unterstützte Hardware Die besten Softwareeigenschaften einer Cluster- und Gridmanagementlösung nützen nichts, wenn die geforderte Hardware nicht unterstützt wird. Bei Managementlösungen aus einer Hand, wie es zum Beispiel bei ROCKS Linux der Fall ist, hat die unterstütze Hardware den entscheidenden Einfluss. Die voranschreitende Entwicklung neuer Technologien wirft neben immer schneller werdenden Prozessoren und Chipsätzen auch neue Technologiestufen auf den Markt, wie der Wechsel von 32 Bitzur 64 Bit-Technologie. Die unter Linuxclustern verbreitetsten Architekturen werden in Kapitel beschrieben. Neben der Architektur spielt das unterstützte Netzwerk eine ebenso wichtige Rolle. Für viele Clusteranwendungen ist die Latenzzeit des Netzwerks der Flaschenhals. Aus diesem Grund sind viele verteilte Rechnersysteme mit einer speziellen Netzwerktechnik ausgestattet, welche niedere Latenzzeiten bietet. Diese werden im nachfolgenden Kapitel diskutiert Unterstützte Architektur Der sich derzeitige vollziehend Wandel von 32 Bit- zur 64 Bit-Architektur bringt neben vielen neuen Möglichkeiten auch viele Probleme mit sich. Mit 32 Bit lassen sich maximal 4 GB Arbeitsspeicher nutzen, mit 64 Bit wächst der theoretisch adressierbare Speicher auf 2 64 Byte. Die aktuell nutzbare Größe ist von den Prozessoren und vom Betriebssystem abhängig. So unterstützt der Xeon mit EM64T derzeit 64 GB Arbeitsspeicher. Neben dem Speicherbedarf aktueller Clusteranwendungen entscheidet die Wort-Breite des Prozessors über die zu verwendende Architektur. Virtuell sind auch auf 32 Bit-Architekturen Wort-Breiten mit 64 Bit möglich. Jedoch müssen diese in zwei 32 Bit-Pakete für den Prozessor aufgeteilt werden. Bei den 64 Bit-Architekturen ist dies nicht mehr nötig. Es können direkt 64 Bit-Worte in die Prozessorregister geladen werden. 55

70 Anforderungen an Managementsysteme Für die aktuellen Linuxdistributionen können die Prozessorarchitekturen in drei wichtige Hauptkategorien unterteilt werden: Hauptkategorie Kurzbezeichnung Prozessoren 32 Bit Systeme x86_32 INTEL Pentium INTEL Xeon INTEL Celeron AMD Athlon AMD Duron 32/64 Bit Systeme x86_64 (EM64T) INTEL Xeon 64 EM64T INTEL Pentium EM64T AMD Athlon 64 AMD Opteron reine 64 Bit Systeme ia64 INTEL Itanium INTEL Itanium II Tabelle 6 Die drei Hauptkategorien der Prozessorarchitekturen Innerhalb ihrer Kategorie sind die Prozessoren zueinander binärkompatibel. Dies bedeutet, dass die Distributoren meist drei verschiedene Versionen ihrer Software herausgeben, eine x86_32-, eine x86_64- und eine ia64-version. Neben diesen aufgeführten Architekturen gibt es natürlich noch andere Prozessoren. In der Clusterund Gridwelt erlangt jedoch aus Kostengründen meist nur Massenware weite Verbreitung. Aus Gründen der Vollständigkeit sind nachfolgend die anderen Prozessorarchitekturen aufgelistet. Diese Prozessoren und ihre Architekturen spielen für die hier vorgestellten Cluster- und Gridmanagementlösungen keine oder eine untergeordnete Rolle. Alpha Prozessorarchitektur Beschreibung Beim Alpha handelt es sich um einen 64 Bit-Prozessor. Ursprünglich wurde er von DEC entwickelt. Durch Marketingversäumnisse erreichte der Alpha Prozessor nie die große Verbreitung, welche ihm vorausgesagt wurde. Er findet sich in manchem Supercomputer. Die Alpha-Technologie floss in Teilen in den INTEL Itanium ein. 56

71 Anforderungen an Managementsysteme Cell HP PA-RISC MIPS NEC SX PowerPC, PPC SPARC-Architektur Der Cell Prozessor wurde von IBM gemeinsam mit Sony und Toshiba entwickelt. Derzeit wird er mit einer Strukturgröße von 65nm gefertigt. Es ist ein 64 Bit- PowerPC Prozessor mit Pipeline-Architektur, Simultaneous Multithreading und Mehrkern-Architektur, um ein hohes Maß an Parallelisierung zu erreichen. Entwickelt und verkauft wird die PA-RISC-Architektur (Parallel/ Precision Architecture Reduced Instruction Set Computer) 32 von Hewlett-Packard in den Serversystemen der Firma. Bei den aktuellen Modellen handelt es sich um einen 64 Bit-Prozessor. Zunächst war geplant, die Architektur durch die INTEL Itanium Architektur im Jahr 2004 abzulösen. Bisher gibt es dafür aber noch keinen Termin. Die MIPS-Architektur (Microprocessor without interlocked pipeline stages) ist eine RISC-Prozessorarchitektur und wurde von SGI in Grafikworkstations eingesetzt. Heute ist der MIPS nur noch in embedded Anwendungen zu finden. Der NEC SX ist ein aktueller Vektorrechner 33, welcher bei NEC Produkten wie dem NEC Earth Simulator 34 aus Japan zum Einsatz kommt. Die PowerPC-Architektur wurde 1991 durch ein Konsortium aus Apple, IBM und Motorola spezifiziert. Dieser Prozessor findet sich in sehr großen Cluster-Supercomputern (vgl. die Top 500 der schnellsten Rechner: Scalable Processor ARChitecture von SUN Microsystems ist hauptsächlich in SUN Produkten zu finden. Es gibt 32 Bit- und 64 Bit- Varianten (aktuell ist 32-Bit V8 und 64-Bit V9). Tabelle 7 Weitere Prozessorarchitekturen 32 Unter einer RISC-Architektur (Reduced Instruction Set Computing) versteht man eine Prozessorarchitektur mit reduziertem Befehlssatz. Die Mikrobefehle, welche der Prozessor ausführen kann, sind in Hardware implementiert und nicht wie bei anderen Prozessoren zum Teil als Software und Summe anderer Befehle. 33 Unter einem Vektorrechner versteht man einen Rechner mit pipeline-artig aufgebauten Rechenwerken zur Verarbeitung von Arrays aus Gleitkommazahlen

72 Anforderungen an Managementsysteme Unterstütztes Netzwerk Durch den Schritt der Supercomputertechnologie von SMP- zu Clustersystemen eröffneten sich neben vielen neuen Möglichkeiten auch bestimmte Schwierigkeiten. Während bei einem SMP-System alle Prozessoren über einen schnellen Bus gemeinsam auf den Speicher des Systems zugreifen, muss bei Clustersystemen das Verbindungsnetzwerk mit seinen spezifischen Protokollen diese Aufgabe erledigen. In Abbildung 2 ist der schematische Aufbau eines SMP-Systems qualitativ aufgezeigt. Wie in der Einführung bereits erläutert, kommt bei heutigen Systemen eine andere Technologie zum Einsatz: der Non-Uniform Memory Access (NUMA). Bei dieser Technologie besitzt jeder Prozessor seinen eigenen Speicher und kann zusätzlich beim AMD Opteron über den HyperTransport-Kanal auf den Speicher der anderen Prozessoren zugreifen (vgl. Abbildung 3). Von der Architektur ähnlich wie die NUMA-Systeme sind die Clustersysteme aufgebaut. Jeder Knoten besitzt seinen eigenen Speicher. Über ein Verbindungsnetzwerk kann er auf den Speicher der anderen Rechenknoten zugreifen (siehe Abbildung 4). Die grundlegende Idee heutiger Clustersysteme ein virtuelles SMP-System zu erschaffen, hat einen entscheidenden Flaschenhals: das Verbindungsnetzwerk. Im Gegensatz zu den SMP-Systeme muss bei den Clustersystemen das Verbindungsnetzwerk die Aufgabe des Busses übernehmen. Der Nachteil der Verbindungsnetzwerke ist der Overhead der Netzwerkprotokolle und die Latenzzeit. Je mehr Rechner zu einem virtuellen SMP-System zusammengeschlossen werden, umso größer ist die Diskrepanz zwischen idealem und realem Zugewinn an Rechenleistung (vgl. Abbildung 18). Diese Diskrepanz wird durch die interne Clusterkommunikation erzeugt. Der entscheidende Faktor ist in diesem Falle nicht die Bandbreite des Verbindungsnetzwerkes, sondern die Latenzzeit. 58

73 Anforderungen an Managementsysteme Abbildung 18 Diskrepanz zwischen idealer und realer Skalierung (Speedup) Aus Gründen der Effektivität wird bei fast allen aktuellen Netzwerktechniken auf eine kleine Latenzzeit geachtet, um die optimale Skalierung (Speedup) der Systeme zu erreichen. Der Durchsatz ist für den optimalen Speedup zweitrangig, jedoch für viele Anwendungen wichtig. Der Aufbau und Betrieb eines Gridsystems ist sehr stark von der Netzwerktechnik und den Protokollen des Internets abhängig. Die Technologie lässt sich in diesem Fall nicht, bzw. nur lokal austauschen. Für Clustersysteme lassen sich aufgrund der räumlichen Nähe von nur wenigen Metern, extrem schnelle Netzwerktechniken einsetzen. Nachfolgend werden die wichtigsten Netzwerktechniken für den Clusterbetrieb erläutert und Vor- und Nachteile aufgezeigt. Bei der Betrachtung werden folgende Gesichtspunkte beleuchtet: Bandbreite Latenzzeit Topologie Transport Busanschluss Netztechnik Unter der Bandbreite versteht man den maximal möglichen Datendurchsatz pro Minute. Eine Beschreibung zur Latenzzeit befindet sich im Glossar. Der Begriff Topologie bezeichnet die mögliche logische Vernetzung der Netzwerkknoten. Mehr zum Thema Netzwerktopologie wird im ANHANG A 59

74 Anforderungen an Managementsysteme erläutert. Die Übermittlung der Daten kann entweder als einzelne Datenpakete oder als Datenstrom erfolgen. Dies wird unter dem Stichwort Transport aufgeführt, ebenso wie die erlaubten Paketgrößen. Die möglichen Bus-Anschlüsse für die Netzwerkkarten werden mit dem Begriff Bus-Anschluss definiert. Die unterste Schicht der Netzwerktechnik bildet die physikalische Grundlage. Im Stichwort Netztechnik werden die möglichen physikalischen Verfahren aufgeführt. Ethernet (10/100/1000/ MBit/s) Ethernet ist seit Jahren die Standardtechnologie für lokal begrenzte Netzwerke (Local Area Network, LAN). Der Ethernet-Standard blickt auf eine lange Geschichte zurück. Entwickelt wurde der Standard am Xerox Palo Alto Research Center (PARC). Im Jahr 1976 veröffentlichten Robert Metcalfe und sein Assistent David Boggs ein Whitepaper mit dem Titel Ethernet: Distributed Packet-Switching for Local Computer Networks. Metcalfe verließ später das Unternehmen und gründete die Firma 3Com. So durchlebte Ethernet in seinem Lebenszyklus mehrere Medientypen und Varianten. Der wichtigste Medientyp ist das Twisted-Pair Kabel. Der Stand der Technik erreicht die 10 GBit/s-Schranke. Weit verbreitet ist der 100 MBit/s-Standard. Für Clusteranwendungen interessant sind nur Geschwindigkeiten ab dem 1 GBit/s-Standard. Als Vorteil von Ethernet kann sicherlich der niedrige Preis genannt werden, der durch die große Verbreitung als Massenware erzielt werden kann. Die zuvor genannte und für verteiltes Rechnen wichtige Latenzzeit ist ein Nachteil des Ethernet-Standards (siehe Abbildung 18). Diese ist für viele Clusteranwendungen ungeeignet. Ethernet ist der Quasistandard für das Managementnetzwerk. Nahezu jeder Clusterknoten verfügt über einen Ethernetanschluss. Nachfolgende Tabelle zeigt die Leistungsdaten von Gigabit-Ethernet auf. Spezifikation Wert Bandbreite 1 GBit/s Vollduplex ( ) Latenzzeit µs Topologie Stern, früher Bustopologie Transport Paketvermittlung, Nutzdaten pro Paket Byte (Jumbo-Pakete mit 9000 Byte) Busanschluss PCI 64, PCI-X, PCIe, PCI, USB Netztechnik Twisted-Pair Kupferkabel bis 100 m Tabelle 8 Leistungsdaten von Gigabit Ethernet über Twisted-Pair 60

75 Anforderungen an Managementsysteme Abbildung 19 INTEL Dualport Gigabit Netzwerkkarte Bei Ethernet besteht die Möglichkeit, channel bonding zu verwenden. Dies wird entweder per Software über ein sogenanntes bonding-device oder über Hardwareeinstellungen aktiviert. In beiden Fällen muss der Switch diese Technik unterstützen. In Abbildung 19 ist eine INTEL Dualport Gigabit Netzwerkkarte zu sehen. Auf dem Markt gibt es auch Karten mit vier Eingängen. InfiniBand Der InfiniBand-Standard wurde durch ein Firmenkonsortium als offener Standard ins Leben gerufen. Die Hardware wird im wesentlichen von der Firma Mellanox Technologies 35 hergestellt. Neben Mellanox gibt es mittlerweile auch andere Hersteller für InfiniBand-Produkte. InfiniBand definiert ein System Area Network (SAN) für den Interconnect von Rechenressourcen und I/O-Knoten. Die Ressourcen oder Knoten werden entweder über einen Host Channel Adapter (HCA) oder über einen Target Channel Adapter (TCA) angeschlossen (siehe Abbildung 20). Die InfiniBand- Hosts werden über die VAPI-Schnittstelle angesprochen. Diese Schnittstelle unterstützt Senden und Empfangen sowie RDMA-Operationen 36. Über diese Schicht lässt sich eine MPI-Implementierung legen RDMA bedeutet Remote Memory Access. 61

76 Anforderungen an Managementsysteme Abbildung 20 Aufbau einer InfiniBand Netztopologie In der nachfolgenden Tabelle sind die Leistungsdaten der Mellanox InfiniBand-Karte aufgeführt. Spezifikation Wert Bandbreite 850 MByte/s duplex Latenz 5 µs Topologie Stern Transport Paketvermittelt Busanschluss PCI-X, PCIe (Pathscale: HTX) Netztechnik Kupfer, maximal 2 m Länge Tabelle 9 Leistungsdaten von Mellanox InfiniBand Einen sehr interessanten Ansatz verfolgt die Firma Pathscale 37 mit dem Produkt InfiniPath. Bei dieser InfiniBand-Implementierung wird der HCA direkt in den HyperTransport (HTX) eines AMD Opteron Systems implementiert. Durch diese Technologie sollen Latenzzeiten von rund einer Mikrosekunde erreicht werden. Die Netzwerkadapterkarten nehmen im speziellen HTX-Slot Platz. Es existieren auch Adapterkarten für den PCI-X Slot. Durch den zusätzlichen Overhead der Northbridge ist die Variante für den PCI-X Slot weniger performant als die Technik für den HTX Slot. Die aktuellen Werte von InfiniPath im HTX sind im Folgenden aufgeführt:

77 Anforderungen an Managementsysteme Spezifikation Wert Bandbreite Latenz Topologie Transport Busanschluss Netztechnik 1875 MByte/s bi-direktional 1.32 µs über MPICH mit HTX Stern Paketvermittelt HTX, PCI-X, PCIe Kupfer, maximal 2 m Länge Abbildung 21 Leistungsdaten von Pathscale InfiniPath Abbildung 22 Mellanox InfiniBand Netzwerkkarte 63

78 Anforderungen an Managementsysteme Myrinet Myrinet von der Firma Myricom 38 unterliegt dem ANSI/VITA Standard. Die technischen Spezifikationen liegen offen und freie Implementierungen sind von Drittanbietern zu beziehen. Myrinet bietet zwei Low-Level Nachrichtenübermittlungssysteme: GM und MX. GM wird heutzutage auf fast allen Clustern mit Myrinet eingesetzt. MX bedeutet Myrinet Express und ist eine Neuentwicklung des Nachrichtenübermittlungssystems. Schnittstellensoftware für MPI, PVM, etc. ist ebenfalls von Myricom und Drittanbietern verfügbar. Spezifikation Wert Bandbreite 500 MByte/s Latenz 7 µs Topologie beliebig Transport Paketvermittelt, beliebig lange Pakete Busanschluss PCI32/64, 33/66 MHz Netztechnik Kupferkabel (bis 10 m Länge), Lichtwellenleiter (bis 200 m Länge) Tabelle 10 Leistungsdaten von Myricom Myrinet Abbildung 23 Myricom Dualport Netzwerkkarte

79 Anforderungen an Managementsysteme Quadrics Die von Quadrics Ltd. 39 hergestellte Netzwerktechnik findet sich in vielen großen Supercomputern der Top 500-Liste, wie zum Beispiel im Thunder Cluster 40 mit Itanium II Prozessoren des Lawrence Livermore National Laboratory. Quadrics unterliegt einer proprietären Lizenz. Dennoch gibt es die Möglichkeit, Open MPI über Quadrics zu betreiben. Das Quadrics-eigene, kommerzielle Low-Level Message Passing System trägt den Namen Elan. Spezifikation Wert Bandbreite 800 MByte/s bi-direktional Latenz 1,4 2,6 µs Topologie Stern Transport Paketvermittelt Busanschluss PCI 64, PCI-X Netztechnik Kupfer Tabelle 11 Leistungsdaten von Quadrics Abbildung 24 Quadrics Netzwerkkarte

80 Anforderungen an Managementsysteme SCI Das Scalable Coherent Interface unterliegt dem IEEE 1596 Standard. Produziert wird SCI von Dolphin Interconnect Solutions 41. Eine freie Implementierung der Technik bzw. ein offener Quellcode existiert nicht. Spezifikation Wert Bandbreite 500 MByte/s Latenz 1,5 µs Topologie Bus (Token Ring, 2- oder 3-dimensional) Transport Paketvermittelt Busanschluss PCI32/64 Netztechnik Kupfer Tabelle 12 Leistungsdaten von Dolphin SCI Abbildung 25 Dolphin SCI Netzwerkkarte

81 Anforderungen an Managementsysteme Vergleich der Bandbreiten In Abbildung 26 sind die Bandbreiten der oben beschriebenen Netzwerktechniken grafisch dargestellt. Jedes System verwendet sein spezielles Low-Level Message Passing System. Die Ergebnisse wurden praktisch im High-Performance Computing and Simulation Research Laboratory der Universität von Florida ermittelt. Abbildung 26 Bandbreitenvergleich der verschiedenen Netzwerktechniken /HCS01/ 67

82 Anforderungen an Managementsysteme Vergleich der Latenzzeiten In Abbildung 27 sind die Latenzzeiten der oben beschriebenen Netzwerktechniken grafisch dargestellt. Wie bei der Bandbreitenbestimmung wurde auch für diese praktischen Tests für jedes System das hierfür spezielle Low-Level Message Passing System verwendet. Abbildung 27 Latenzzeitenvergleich der verschiedenen Netzwerktechniken /HCS02/ 68

83 Anforderungen an Managementsysteme 3.7 Unterstützte Betriebssysteme (Master/Clients) Oft ist die Wahl des Managementsystems abhängig von der Unterstützung der Betriebssysteme. Für Managementsysteme in Client-Netzwerken ist diese Unterstützung sehr viel wichtiger als für Clusterund Gridsysteme. In den meisten Fällen wird das Betriebssystem je nach Anforderung und zu lösender Aufgabe ausgewählt. Viele Cluster- und Gridmanagementsysteme bringen ihre eigenen Betriebssysteme mit. So zum Beispiel ROCKS Linux, welches auf Red Hat Linux basiert, jedoch die freie Version CentOS 42 benutzt. Für ROCKS Linux lässt sich die Linuxdistribution für den Masterknoten durch eine Red Hat kompatible Version ersetzen. Die Kompatibilität hat aber auch ihre Stolperfallen. So ist es unter Umständen von der zu lösenden Aufgabe abhängig, welche Linuxdistribution verwendet wird. Nicht jedes Programm ist binärkompatibel mit allen Distributionen. Es muss unterschieden werden, ob der Masterknoten als reiner Server oder zusätzlich als Rechenknoten fungiert. Bei RAM-Boot-Konfigurationen ist es oftmals nicht möglich, dass Masterknoten und Rechenknoten unterschiedliche Linuxdistributionen besitzen. Die Clientrechner importieren größtenteils Verzeichnisse des Masterknotens. Somit wären Inkompatibilitäten zwischen den Bibliotheken unausweichlich. 3.8 Verteilte/Cluster Dateisysteme (VCDs) Verteilte Dateisysteme (engl. Distributed File Systems) lassen physikalisch verteilte Daten für den einzelnen Rechenknoten wie lokale Daten wirken. Die Benutzer müssen den physikalischen Speicherort der Daten nicht kennen. 42 CentOS ist von den frei verfügbaren Sourcen des Red Hat Enterprise Linux (RHEL) kompiliert. Lediglich die Namen wurden verändert. Dadurch wird eine 100%-ige Kompatibilität zu Red Hat sichergestellt, ohne dass die zum Teil recht hohen Lizenzgebühren fällig werden. Einen Supportanspruch hat man in diesem Fall natürlich nicht. Siehe: 69

84 Anforderungen an Managementsysteme Clusterdateisysteme (engl. Cluster File Systems) erlauben konkurrierende Zugriffe der Rechner aus dem Cluster auf einen gemeinsamen Speicher (Shared Storage). Diese Dateisysteme finden oft Anwendung in High Availability Clustern, wo sie den Zugriff auf den gemeinsamen Speicher managen und kontrollieren. In High Performance Clustern dienen diese Dateisysteme der Aufnahme von großen Datenmengen in sehr kleiner Zeit, wie zum Beispiel am CERN 43, dem weltweit größten Teilchenphysiklabor. Nachfolgend werden verteilte Dateisysteme und Cluster Dateisysteme als VCD bezeichnet. Sind schnelle Zugriffszeiten und eine große Bandbreite gefragt, gibt es auf der Hardwareseite Alternativen. Mit einem Network Attached Storage (NAS) Server lassen sich gute Ergebnisse erreichen. In diesem Fall existiert ein zusätzlicher Server mit Speicheranbindung, welcher für die Vermittlung von Daten zuständig ist. Der nächste Schritt wäre der Einsatz eines Storage Area Network (SAN), bei welchem der Zugriff über das Netzwerk direkt auf Blocklevelebene des Speichers erfolgt. Beide Hardwarelösungen haben den Nachteil des relativ hohen Preises. Günstiger ist hier der Einsatz einer Softwarelösung. Eine praxisnahe und beispielhafte Betrachtung eines VCD erfolgt anhand des Parallel Virtual File System (PVFS) in Kapitel VCDs verfügen im Gegensatz zu herkömmlichen Dateisystemen über zusätzliche Leistungen. Auf einen gemeinsamen Nenner gebracht ergeben sich die folgenden Schlagworte: cache time stamp link consistency Zwischenspeicher (Cache) Im Gegensatz zu herkömmlichen Netzwerkdateisystemen, wie NFS, besitzt ein VCD einen Zwischenspeicher. Durch das Zwischenspeichern von Datensätzen, wie bei einem Proxy im Internet, kann die Geschwindigkeit bei häufigen Zugriffen gesteigert werden. Natürlich ist die Geschwindigkeit auch vom Typ und der Architektur des Netzwerks abhängig (Latenzzeit und Durchsatz). 43 CERN: Organisation Européenne pour la Recherche Nucléaire, ehemals Conseil Européen pour la Recherche Nucléaire. Siehe und 70

85 Anforderungen an Managementsysteme Zeitstempel (time stamp) Ein wichtiger Aspekt innerhalb von VCDs sind Zeitstempel. Durch diese in einem bestimmten Format abgespeicherten Werte kann einem Ereignis (beispielsweise dem Senden oder Empfangen einer Nachricht, der Modifikation von Daten u.a.) ein Zeitpunkt zugeordnet werden Verbindungskonsistenz (link consistency) Verbindungskonsistenz bedeutet, dass stets für die Übereinstimmung von Daten und Verbindungen gesorgt wird, sowohl auf der Seite der Quelle als auch auf der Seite des Ziels. Dies kann durch Löschen des ungültigen Links oder durch sein Richtigstellen erfolgen. Es soll also verhindert werden, dass Verbindungen reißen (= broken links) Aufstellung aktueller VCDs Die Dienste können zusätzlich in den Cluster eingebunden werden oder sie sind schon von Haus aus bei der Managementlösung dabei. Eine Übersicht verfügbarer VCDs befindet sich in nachfolgender Tabelle: 71

86 Anforderungen an Managementsysteme Verteiltes/Cluster Dateisystem (Open) GFS CODA DRBD GPFS Intermezzo Lustre Beschreibung / URL Das Global File System (GFS) ist ein verteiltes Dateisystem mit Journaling-Funktion. Das Dateisystem erscheint bei allen Knoten als lokal gemountet, während GFS das Management im Hintergrund erledigt. Es gibt keinen Flaschenhals, da es symmetrisch angelegt ist und alle Knoten gleiche Priorität besitzen. Entwickelt wurde GFS ursprünglich von der Firma Sistina, welche von Red Hat übernommen wurde. Im Dezember 2004 wurde das GFS in den aktuellen Entwicklerzweig von Fedora Linux 44 gebracht. Somit enthält Fedora Linux die entsprechenden Kernelmodule. Siehe und Das CODA File System ermöglicht es mehreren Servern, die gleichen Daten zu speichern. Siehe: Das Distributed Replicated Block Device sorgt für eine Spiegelung eines Gerätes auf Blockebene. Siehe: Das General Parallel File System (GPFS) ist ein von IBM entwickeltes leistungsfähiges, paralleles VCD. Es unterstützt inhomogene Architekturen. Die aktuelle Version ist 2.3. Siehe: Das Intermezzo File System hat seinen Fokus auf High Availability. Siehe: Lustre ist ein Cluster File System mit Unterstützung von mehreren tausend Knoten. Es zielt stark auf Performanzsteigerung und Datendurchsatz. Siehe:

87 Anforderungen an Managementsysteme MFS, omfs OCFS Panasas Polyserve PVFS V9fs Mit dem MFS von openmosix kann jeder Knoten im Cluster auf das Dateisystem der anderen Knoten zugreifen. Mit DFSA über MFS können Befehle direkt auf dem Heimatknoten des ausgelagerten Prozesses ausgeführt werden. MFS ist aus den aktuellen openmosix Versionen entfernt worden, um Platz für eine Implementierung von GFS zu schaffen. Siehe: Das Oracle Cluster File System (OCFS) legt ein konsistentes Dateisystem über mehrere Server. Siehe: Panasas ist auf Performanzsteigerung in Clustersystemen ausgelegt. Siehe: Polyserve ist ein hoch-performantes NAS. Die Daten werden dabei in einem SAN gespeichert. Siehe: Das Parallel Virtual File System (PVFS) ist ein frei verfügbares, softwarebasierendes Dateisystem mit vielversprechenden Eigenschaften. Eine genaue Betrachtung erfolgt im nächsten Unterkapitel. Siehe: Das V9fs Projekt unternimmt den Versuch, das Ressourcenverteilungssystem von Plan 9 Linux auf andere Betriebssysteme zu bringen. Siehe: Tabelle 13 Übersicht: Verteilte/Cluster Dateisysteme Das Parallel Virtual File System (PVFS) Das Parallel Virtual File System (PVFS) 45 ist ein frei verfügbares, softwarebasierendes Clusterdateisystem mit vielversprechenden Eigenschaften. Entwickelt wird es vom Argonne National Laboratory und der Clemson Universität. PVFS dient der Verteilung des Festplattenspeichers durch das Netzwerk und funktioniert mit seriellen und parallelen Programmen. Es bietet einen konsistenten

88 Anforderungen an Managementsysteme Namensraum und transparenten Zugriff. Das Hauptbetriebssystem ist Linux. Portierungen auf andere Plattformen sind im Aufbau. PVFS bietet keine Unterstützung für symbolische oder harte Links und keine Redundanz. In einem PVFS-Netzwerk gibt es drei Arten von Rechnern: Einen Metaserver, verschiedene I/O- Server und Clients. Abbildung 28 veranschaulicht den Aufbau. Abbildung 28 Der Aufbau eines PVFS-Netzwerkes Der Metaserver sorgt für das Dateisystemmanagement. Es speichert Informationen wie Zugriffsrechte und Speicherorte. Vergleichbar ist diese Art Aufgabe mit dem Superblock einer lokalen Festplatte mit lokalem Dateisystem. Hierbei können die Daten verteilt auf der Festplatte liegen. Im Superblock werden die entsprechenden Metadaten zu diesen Daten gespeichert. Die I/O-Server halten die Daten, welche im Netzwerk verfügbar sind, mit Hilfe realer, verfügbarer Hardware. Durch Verteilung einer einzigen Datei auf mehrere dieser Knoten kann der Zugriff auf eine Datei parallel über mehrere Wege erfolgen. Diese Verteilung vergrößert den Flaschenhals beim Zugriff auf den tertiären Speicher. 46 Ein Knoten kann den Anfang einer Datei von einem bestimmten Knoten beziehen und parallel dazu das Ende der Datei von einem anderen Knoten. 46 Speicher kann in drei Kategorien unterteilt werden. Die erste und von den Zugriffszeiten schnellste Kategorie bildet der Cache des Prozessors. Dieser Speicher wird auch primärer Speicher genannt. Unter dem sekundären Speicher versteht man den Hauptspeicher eines Rechners. Der Zugriff darauf erfolgt langsamer als auf den primären Speicher. Als tertiären Speicher bezeichnet man Speicher auf Datenträgern, wie zum Beispiel Festplatten. Der Zugriff auf den tertiären Speicher ist verhältnismäßig langsam. Aus diesem Grund wird versucht, durch den Einsatz von entsprechend viel Arbeitsspeicher die Zugriffe auf den tertiären Speicher zu minimieren. 74

89 Anforderungen an Managementsysteme Die Client-Rechner bezeichnen die Rechenknoten des Clusters. Diese führen parallele Jobs aus. Natürlich können I/O-Server und Client-Rechner ein und derselbe Rechner sein, je nach Größe des Netzwerkes. 75

90 Anforderungen an Managementsysteme 76

91 Betrachtung der Managementsysteme 4 Betrachtung der Managementsysteme In diesem Kapitel folgt nun die Kategorisierung der einzelnen Eigenschaften der Cluster- und Gridmanagementsysteme. Die Auswahl der Systeme erfolgte durch Beobachtung des Marktes für HPC-Systeme und Diskussion mit Experten. Neben frei verfügbaren Open Source Managementlösungen wurden kommerzielle Produkte ebenfalls evaluiert. Einige der kommerziellen Produkte sind Bestandteil von schlüsselfertigen Komplettlösungen. In die engere Wahl rückten Lösungen, welche speziell für HPC entwickelt und abgestimmt wurden. Zum Teil entsprechen die in Kapitel 3 aufgeführten Anforderungen auch Systemen für den Einsatz in Client/Server Netzwerken. Ausgewählt und in diesem Kapitel evaluiert werden folgende Systeme: ClusterKnoppix CLUTO von der transtec AG Cluster Systems Management (CSM) von IBM OSCAR der Open Cluster Group Rocks von NPACI s.cluster mit scvenus von der science + computing ag Scali Manage von Scali Inc. Scyld Beowulf von Scyld Software 77

92 Betrachtung der Managementsysteme Die Anforderungsschablone wurde auf alle Systeme anhand von frei zugänglichen Informationen aus dem Internet und anhand praxisnaher Tests gelegt. Eine Übersichtstabelle, erstellt aus den Eckdaten von 3, ist für alle Systeme mit den spezifischen Daten in den jeweiligen Kapiteln vorhanden. Eine zusammengefasste Tabelle mit allen evaluierten Systemen ist in digitaler Form unter zu beziehen. Die Reihenfolge der Managementsysteme ist alphabetisch und drückt keine Präferenz aus. In jedem Kapitel befindet sich eine Übersichtstafel mit stichwortartigen Einträgen zu den Anforderungen. 4.1 ClusterKnoppix ClusterKnoppix 47 ist der absolute Favorit, wenn es um die Geschwindigkeit geht, einen Cluster in Betrieb zu nehmen. ClusterKnoppix basiert in der aktuellen Version 3.6 vom 16. August 2004 auf der Linux Live-CD Knoppix 48 Version 3.6. ClusterKnoppix startet direkt von CD und benötigt keine Festplatte für eine Installation. ClusterKnoppix kann an dieser Stelle nicht als herkömmliches Clustermanagement aufgeführt werden, bietet jedoch eine Reihe interessanter Eigenschaften. Aus diesem Grund wurde es in das vorliegende Werk aufgenommen. Durch das nicht permanent installierte Betriebssystem müssen erstellte Daten vor dem Herunterfahren des Rechners auf einem Datenträger abgespeichert werden, um Datenverlust zu verhindern. Bei ClusterKnoppix wurde der Knoppix-Kernel gegen einen Kernel mit openmosix-erweiterungen ausgetauscht (Kernel mit SMP-Unterstützung). Das openmosix Filesystem omfs mit DFSA Unterstützung ist enthalten. Dadurch kann von jedem Knoten aus auf das Dateisystem der anderen Knoten zugegriffen werden. Die für den Betrieb eines openmosix Clusters wichtigen Benutzerwerkzeuge wurden ebenfalls integriert. Dienste von openmosix organisieren sich beim Starten des Systems von selbst, nur ein DHCP-Server sollte vorhanden sein. Die einzelnen Clusterknoten finden einander durch den Autodiscovery Daemon (omdiscd). Da ein openmosix Cluster symmetrisch ausgelegt ist, können die Rechenknoten in beliebiger Reihenfolge mit Hilfe einer Knoppix wird von Karl Knopper entwickelt und basiert auf Debian GNU/Linux. Diese Linuxdistribution ist direkt von CD startbar und benötigt keine Festplatte. Knoppix ist bei Systemadministratoren für Rettungszwecke sehr beliebt. Siehe: 78

93 Betrachtung der Managementsysteme ClusterKnoppix-CD gestartet werden. Es ist kein dedizierter Masterknoten erforderlich. Clusterknoten können dynamisch hinzugefügt und wieder entfernt werden. In der aktuellen Version kann ClusterKnoppix mittels PXE und DHCP andere Clusterknoten über Netzwerk booten. Diese benötigen in diesem Fall keine ClusterKnoppix-CD. Die Überwachung der Systeme kann von jedem Clusterknoten aus mit den Benutzerwerkzeugen openmosixview und openmosixmigmon erfolgen (siehe Abbildung 29). In ClusterKnoppix 3.6 sind diese mit der aktuellsten Version 1.5 vertreten. Abbildung 29 Die openmosix Monitoringwerkzeuge openmosixview und openmosixmigmon Eine Benutzerverwaltung ist nicht vorhanden. Wie bei der Linuxdistribution Knoppix existiert ein Benutzer Knoppix mit nahezu kompletten root-rechten. Aus diesem Grund sollte ClusterKnoppix nicht in sicherheitskritischen Bereichen eingesetzt werden. Der Haupteinsatzzweck von ClusterKnoppix ist die Einrichtung eines temporären Clusters in Arbeitsgruppen, Abteilungen, o.ä. um kurzzeitig genügend Rechenleistung für eine bestimmte Aufgabe bereitzustellen. Vorstellbar sind Cluster für das kurzzeitige Rendern einer Videosequenz oder der nächtliche Einsatz eines Clusters in Forschungslaboren. Dadurch, dass die Festplatten der Rechenknoten nicht benutzt werden, lassen sich normale Arbeitsstationen für den Clusterbetrieb umwandeln. Bedacht werden sollte jedoch auf jeden Fall die Tatsache, dass durch das gebootete Knoppix Betriebssystem jegliche manuelle Manipulationen auf dem Gastsystem möglich sind. 79

94 Betrachtung der Managementsysteme Neben ClusterKnoppix existieren eine Vielzahl weiterer Linux Live-CDs mit openmosix Kernelerweiterung. Eine aktuelle Liste befindet sich auf der Homepage des openmosix Projekts. 49 Die ständige Weiterentwicklung von openmosix lässt auf eine baldige Version mit Kernel 2.6 hoffen. Das openmosix Projekt verkündete im April 2005 die Herausgabe der openmosix Kernelerweiterungen für Kernel 2.6. Leider werden diese noch nicht durch entsprechende Benutzerwerkzeuge begleitet, wodurch sich der Einsatzzweck relativiert

95 Betrachtung der Managementsysteme Übersichtstafel: Managementsystem ClusterKnoppix Organisation / Hersteller Softwarelizenzierung Version Support Wim Vandersmissen Managementfunktionen GPL 3.6 Mailingliste Forum Monitoringfunktionen Hardware-Inventur Konfigurationsverwaltung Repository openmosixview openmosixmigmon nicht möglich nicht möglich nicht möglich Lights-Out-Management Health-Check Benutzer-Verwaltung nicht möglich nicht möglich keine Benutzerverwaltung möglich Parallele Programmierumgebungen Durch die Verwendung der openmosix Kernelerweiterungen werden keine parallelen Programmierumgebungen benötigt. Ressourcenmanagementsysteme openmosix Kernelerweiterungen Unterstützte Hardware Unterstützte Architektur x86_32 Unterstütztes/benötigtes Netzwerk Ethernet (eventuell mit PXE) Unterstützte Betriebssysteme Masterknoten Unterstützte verteilte Dateisysteme (Clusterdateisysteme) omfs/dfsa Allgemeine Anmerkungen / Boot-Konzept Clients ClusterKnoppix eignet sich in erster Linie für die kurzfristige Umwandlung normaler Arbeitsstationen in Clusterknoten. Durch die Verwendung der openmosix Kernelerweiterungen müssen keine Anwendungen für den Clusterbetrieb umgeschrieben werden. Bedenken bezüglich der Sicherheit sind angebracht, da ClusterKnoppix jeder Person mit physischem Zugang zum Rechner volle Rechte einräumt. Tabelle 14 Übersichtstafel: Managementsystem ClusterKnoppix 81

96 Betrachtung der Managementsysteme 4.2 CLUTO Die CLUsterTOols sind eine Zusammenstellung von Open Source Werkzeugen und sehr speziellen Shellskripten. Entwickelt wurde CLUTO im Jahr 2002 bei der Firma Dr. Koch Computertechnik AG von Leonardo Lapeira. Im Jahr 2003, nach der Übernahme durch die transtec AG, wurde CLUTO fester Bestandteil der Clustersysteme, um die unterschiedlichen Kundenwünsche nach Architektur und Distribution bedienen zu können. CLUTO steht unter der GPL. Support wird nur für Clustersysteme der transtec AG geleistet. Eine eigenständige, nicht an Hardware gekoppelte Version von CLUTO ist nicht verfügbar. Grafische Schnittstelle für das Management mit CLUTO existieren in der aktuellen Version noch nicht. CLUTO ist speziell für die Kommandozeile entwickelt worden und sorgt durch seine Simplizität für ein äußerst schnelles Arbeiten. Die Kompatibilität ist das Hauptaugenmerk von CLUTO. Es ist lauffähig auf allen aktuellen Desktop- und Enterprise-Linuxdistributionen, wie SUSE Linux, Fedora/Red Hat oder Debian. Auch in Sachen Architekturunterstützung ist CLUTO äußerst kompatibel. Alle von den Linuxdistributionen abgedeckten Architekturen werden unterstützt (x86_32, x86_64 und ia64). Neben den Distributionen lassen sich die Kernel und Applikationen der Systeme austauschen. So ist die Einrichtung eines openmosix Clusters ebenso möglich wie der Einsatz diverser MPI Implementierungen. Die Einrichtung des Knotenmanagementsystems erfolgt nach der Installation des Masterknoten manuell anhand der Dokumentation. Systemspezifische Merkmale können durch Modifizieren der Shell-Algorithmen abgedeckt werden. Die Knoten werden standardmäßig mit Hilfe von PXE über ein Ethernet-Managementnetzwerk gestartet (Boot from LAN, BfL). Weiterführende Informationen zu BfL befinden sich in ANHANG A. Aus diesem Konzept ergibt sich automatisch ein asymmetrisches Clustermodell. Zusätzliche Netzwerkkarten, wie InfiniBand o.ä. dienen nur dem Datenaustausch der parallelen Programme. Der Großteil der Software wird vom Masterknoten importiert. Aus diesem Grund sollte auf dem Masterknoten und den Rechenknoten die gleiche Linuxdistribution verwendet werden. Es existiert die Option, Knoten lokal zu installieren und zu administrieren. In diesem Fall können die Linuxdistributionen voneinander abweichen. 82

97 Betrachtung der Managementsysteme Die Software- und Konfigurationsverwaltung beruht auf Images, welche zentral auf dem Masterknoten vorliegen. Diese Clusterkonfiguration heißt auch Single System Image (SSI). 50 Die Größe eines Standardimage für BfL beträgt lediglich 128 MB. Aufgrund der geringen Größe können ohne Probleme mehrere dieser Images gespeichert werden, welche dann bei Bedarf auf den Rechenknoten gebootet werden. Die benötigte Zeit, bis die Rechenknoten ein Image gebootet haben, liegt bei unter zwei Minuten. Ein schnelles und komplettes Umkonfigurieren des Clusters mit sehr kurzer Downtime ist möglich. Es können auch nur bestimmte Teile des Clusters mit einer neuen Konfiguration gestartet oder spezielle Tests nur auf bestimmten Knoten gefahren werden. Als Monitoringwerkzeug wird das KDE-Projekt ksysguard 51 verwendet. Von einem Rechner, auf welchem ksysguard installiert ist, lassen sich unter anderem folgende Informationen auslesen: (Mehr-) Prozessorauslastung (Benutzerlast, Nice-Last, Systemlast, etc.) Festplattendurchsatz Netzwerkdurchsatz Partitionsbelegung Speicherauslastung (physikalischer Speicher und Auslagerungsspeicher) Logfiles Mittels SSH oder RSH kann sich ksysguard auf entfernte Rechner verbinden und die dortigen Werte auslesen. Für diesen Zweck muss ksysguard aber auf dem entfernten Rechner installiert sein. Es lassen sich mehrere Konfigurationen erstellen und abspeichern. Das Bedienfeld ist übersichtlich mittels Karteireitern und Tabellen aufgebaut. Abbildung 30 zeigt eine Detailansicht von ksysguard auf einem Cluster mit vier Knoten zu je zwei Prozessoren. 50 Mehr dazu in ANHANG A

98 Betrachtung der Managementsysteme Abbildung 30 Cluster-Monitoring mit ksysguard (mögliche Detailansicht) Abbildung 31 zeigt eine mögliche Ansicht der Prozessorauslastung beider Prozessoren auf allen Knoten in einem 16 Knoten Cluster. Abbildung 31 Cluster Monitoring mit ksysguard auf einem 16 Knoten Cluster Die Benutzerverwaltung wird zentral auf dem Masterknoten ausgeführt und die Benutzerdatenbank auf die Rechenknoten repliziert. Alternativ kann ein (externer) NIS Server eingerichtet werden. Durch 84

99 Betrachtung der Managementsysteme die freie Gestaltung der Bootimages ist die Einbindung unterschiedlicher paralleler Programmierumgebungen und Ressourcenmanagementsysteme dem Systemintegrator bzw. Administrator überlassen. Auch über die Wahl der Netzwerkverbindung kann frei entschieden werden. 85

100 Betrachtung der Managementsysteme Übersichtstafel: Managementsystem CLUTO Organisation / Hersteller Softwarelizenzierung Version Support transtec AG Managementfunktionen GPL Bestandteil der Clusterlösungen von transtec Es werden unterschiedliche Supportmodelle abgeboten, welche jeweils an Hardwaresysteme von transtec gebunden sind. Ohne Support ist es frei erhältlich. Monitoringfunktionen Hardware-Inventur Konfigurationsverwaltung Repository Verwendung von ksysguard, opt. Ganglia manuelle Implementierung möglich Verwendung unterschiedlicher Bootimages, manuelle Intervention Lights-Out-Management Health-Check Benutzerverwaltung manuelle Implementierung möglich Parallele Programmierumgebungen manuelle Implementierung möglich manuelle Implementierung möglich Die Benutzerverwaltung erfolgt zentral auf dem Masterknoten (Reproduzierung auf Rechenknoten). Wahlweise kann ein NIS Server eingesetzt werden. Eine spezifisch dem Kundenwunsch angepasste Implementierung ist möglich. Oftmals wird die Konfiguration durch den Paketmanager der zugrundeliegenden Linuxdistribution unterstützt. Die Anpassung muss auf dem Masterknoten und den Images der Knoten erfolgen. Eine Integrationsschnittstelle von MPICH und PVM an CLUTO ist vorhanden. Ressourcenmanagementsysteme Eine freie Implementierung sämtlicher Ressourcenmanagementsysteme ist möglich. Das entsprechende Expertenwissen ist Voraussetzung. Eine Neugenerierung der Images für die Knoten ist nach Änderungen an der Konfiguration nötig. Das Einspielen der neuen Konfiguration kann durch Neustarten der Knoten (< 2 min.) oder während des Betrieb erfolgen. Wahlweise lassen sich Änderungen per Synchronisation verbreiten. Unterstützte Hardware Unterstützte Architektur x86_32, x86_64, ia64 Unterstütztes/benötigtes Netzwerk Managementnetzwerk: Ethernet mit PXE (clientseitig), manuelle Impl. möglich Unterstützte Betriebssysteme Masterknoten SUSE Linux Professional, SLES, RHEL, Fedora, Debian, o.ä. Clients siehe Masterknoten Unterstützte verteilte Dateisysteme (Clusterdateisysteme) Eine Einbindung von PVFS wird derzeit entwickelt. Manuelle Implementierungen sind möglich. Allgemeine Anmerkungen / Boot-Konzept CLUTO ist ein äußerst kompatibles und konfigurierbares Managementsystem mit möglichen Anpassungen an viele Distributionen. Verwendet wird das Single System Image (SSI) Konzept mit Boot from LAN. Wahlweise sind auch lokale Installationen des SSI möglich. Nachteilig ist das nötige Expertenwissen für die Installation und die mangelnde zusätzliche grafische Oberfläche. Pluspunkt ist die schnelle Bedienung über die Kommandozeile. Tabelle 15 Übersichtstafel: Managementsystem CLUTO 86

101 Betrachtung der Managementsysteme 4.3 Cluster Systems Management (CSM) Das Cluster Systems Management (CSM) 52 steht unter einer kommerziellen Lizenz von IBM. Bis Mitte 2001 konnte das IBM Cluster Starter Kit for Linux, welches Teile des CSM verwendet, frei von IBM heruntergeladen werden. Diese Möglichkeit wurde eingestellt. CSM kann von IBM bezogen und 60 Tage lang mit einer Try and Buy Lizenz getestet werden. CSM ist wird On-Top auf eine Linuxdistribution installiert. Die Installationsroutine läuft ohne grafische Oberfläche ab und erfordert das genaue Studieren des 250 Seiten starken Handbuches. Vorhandene Linuxrechner können als Clusterknoten eingebunden werden. Für die Installation der Rechenknoten verwendet CMS die Installationssysteme SUSE AutoYaST beziehungsweise Red Hat Kickstart. Die Unterstützung für Linuxdistributionen fällt eher konservativ aus. So werden die Unternehmensversionen von Red Hat und SUSE unterstützt (RHEL AS/ES/WS und SLES). Für ein erweitertes Knotenmanagement setzt CSM den Distributed Command Execution Manager (DCEM) ein. Dieser basiert auf dem Resource Monitoring and Control (RMC) Subsystem für die Überwachung der Knoten. DCEM Versionen existieren für folgende Plattformen: AIX 5L für PowerPC RHES ES/AS/AS 3 SLES Die Clustersysteme von IBM benutzen das General Parallel File System (GPFS) in Version 2.3. CSM ist ein mächtiges Werkzeug auf IBM Hardware und im Verbund mit mehreren Systemen, zum Beispiel lassen sich einzelne Knoten zwischen zwei Clustern verschieben. Diese Technologie trägt den Namen Reliable Scalable Cluster Technology (RSCT). Die Engineering and Scientific Subroutine Library (ESSL) bietet zwei Laufzeitbibliotheken für die Parallelisierung von Programmen. ESSL gibt es für 32 Bit- und 64 Bit-Applikationen

102 Betrachtung der Managementsysteme Als Lastverwaltung wird LoadLeveler eingesetzt. Dieses System ermöglicht es den Benutzern, durch Wahl der geeigneten Maschine, mehr Jobs in weniger Zeit auszuführen. LoadLeveler verwaltet Jobs und bietet verschiedene Funktionen um Jobs schnell und effizient in eine dynamische Umgebung einzuführen. Mehr Informationen zu Clustersystemen der IBM und zur manuellen Einrichtung der Clusterfunktionen unter Die Clusterinstallation mit CSM Die Installation wird mit Hilfe des Handbuches begleitet. Als Linuxdistribution wurde SLES 9 mit Service Pack 1 (SP-1) gewählt. SP-2 wird in der CSM Version noch nicht unterstützt, kann aber mit eventuellen Einschränkungen aber trotzdem verwendet werden. Vor Beginn der Installation muss das Netzwerk (Schnittstellen, Namensauflösung, etc.) vorbereitet werden. Die Informationen werden aus dem Handbuch übernommen. Für die Konfiguration muss zunächst sichergestellt werden, dass bestimmte Pakete auf dem CSM Masterknoten installiert sind. Dies kann dadurch geschehen, dass diese Pakete von den Datenträgern der Linuxdistribution in das CSM Installationsverzeichnis (/csminstall) kopiert werden. Die Installation von CSM erfolgt mittels RPM-Pakete. Ein Aufruf der Installationsroutine /opt/csm/installms mit Angabe des Paketverzeichnisses startet die Installation des Managementservers, welche die CDs der Linuxdistribution verlangt. Mit /opt/csm/csmconfig L kann die 60 Tage Try and Buy Lizenz angenommen werden. Alternativ kann hier auch eine gültige Lizenzdatei angegeben werden. Die Kommandos von CSM sind stark an typische Linuxbefehle angelegt. So können nach Abschluss der Installation des Masterknotens, die Knoten des Clusters mit dem Befehl definenode definiert werden. Dieser Befehl erwartet entweder einzelne Rechnernamen als Attribut oder eine Datei, welche die Rechnernamen enthält. Die Definition mit Anzeige der einzelnen Werte der Rechner kann mit lsnode erfolgen (siehe Abbildung 32). CSM trägt die Werte meistens passend ein, trotzdem sollten diese genaustens überprüft werden. 88

103 Betrachtung der Managementsysteme Abbildung 32 Die Attribute des Clusterknoten (CSM) CSM unterstützt inhomogene Plattformen. Für diesem Fall können die Werte für das Betriebssystem, wie im Handbuch beschrieben, auf einen anderen Wert abgeändert werden. Es besteht die Möglichkeit, vorinstallierte Clusterknoten in CSM einzubinden. So ließe sich ein anderes Knotenmanagementsystem für die Installation und Verwaltung des Clusterknoten einsetzten. Um vorinstallierte Rechner zum CSM Cluster hinzuzufügen, müssen diese zuerst definiert werden und anschließend die automatische CSM Installation (/opt/csm/update P) gestartet werden. Hierbei wird zunächst die Verbindung auf die Knoten geprüft und nach dem root-passwort gefragt. Die Einbindung des Rechner in den CSM Cluster erfolgt parallel. Nach erfolgter Installation kann der passwortfreie Einsatz der Distributed Shell (DSH) überprüft werden (siehe Abbildung 33). Zuvor müssen die beiden Umgebungsvariablen DSH_LIST (zeigt auf eine Datei mit gesamter Liste aller Knoten) und WCOLL (zeigt auf Datei mit aktiven Knoten) gesetzt werden. Die in den Cluster eingebundenen Rechner müssen neu gestartet werden. Abbildung 33 Anzeige der eingeloggten Benutzer auf den Knoten mittels DSH Neben der Einbindung vorhandener Rechner in den Cluster existiert die Möglichkeit, Rechner automatisch durch CSM installieren zulassen. CSM verwendet für diese Installation, wie oben bereits erwähnt, Red Hat Kickstart beziehungsweise SUSE AutoYaST. Die Konfiguration der beiden Installationssysteme erfolgt durch CSM. Zusätzlich können Treiber für benötigte Hardware dem System übergeben werden. Trotz allem ist die Installation sehr für IBM Hardware ausgelegt. Die 89

104 Betrachtung der Managementsysteme Verwendung anderer Hardware ist möglich, aber nicht so komfortabel. Mit definenode werden die neuen Knoten definiert und deren MAC-Adressen manuell eingetragen. Bei IBM Hardware kann dies automatisch erfolgen. Nachfolgende Installation ist für SLES beschrieben. Die Werte der Knoten können wiederum mit lsnode angezeigt und überprüft werden. csmsetupyast startet zunächst den Kopiervorgang der SLES CDs in das /csminstall Verzeichnis. Die weitere Konfiguration der DHCP- und PXE-Umgebung wird automatisch von CSM erledigt. Die DHCP-Anfragen der startenden Knoten werden vom Masterknoten beantwortet. Diese sendet die AutoYaST-Dateien und führt die Installation der Rechner durch. Nach erfolgter Installation führt CSM die Einbindung der Rechner als Clusterknoten durch. Während des Installationsvorganges können benutzerdefinierte Skripte ausgeführt werden. Zusätzlich lassen sich eigene RPM-Pakete für die Installation mit angegeben. 90

105 Betrachtung der Managementsysteme Übersichtstafel: Managementsystem CSM Organisation / Hersteller Softwarelizenzierung Version Support IBM Corporation Managementfunktionen kommerziell Support durch die IBM Corporation. CSM ist Bestandteil der IBM Cluster bestehend aus entweder xseries, pseries, Bladecenter und eserver. Monitoringfunktionen Hardware-Inventur Konfigurationsverwaltung Repository Distributed Command Execution Manager (DCEM) basierend auf Resource Monitoring and Control (RMC) nur für IBM Hardware möglich automatisiert Software Maintenance System (SMS) Lights-Out-Management Health-Check Benutzerverwaltung Unterstützung für Baseboard Management Controller (BMC) und Hardware Management Console (HMC) Parallele Programmierumgebungen Engineering and Scientific Subroutine Library (ESSL) Ressourcenmanagementsysteme LoadLeveler 3.3 Resource Monitoring and Control (RMC) Configuration File Manager (CFM) Unterstützte Hardware Unterstützte Architektur x86_32, x86_64, PowerPC Unterstütztes/benötigtes Netzwerk Managementnetzwerk: Ethernet mit PXE (clientseitig) Unterstützte Betriebssysteme Masterknoten Clients RHAS 2.1, RHEL 3 AS/ES, SLES 8/9 RHAS 2.1, RHEL 3 AS/ES/WS, SLES 8/9 Unterstützte verteilte Dateisysteme (Clusterdateisysteme) General Parallel File System (GPFS) 2.3 Allgemeine Anmerkungen / Boot-Konzept Der Zugriff auf die Managementfunktionen von CSM erfolgt mittels Kommandozeile oder IBM Director Console. Für verteilte Ausführung von Befehlen wird die Distributed Shell (DSH) verwendet. Der Distributed Command Execution Manager (DCEM) sorgt für erweitertes Rechnermanagement. DCEM benutzt das Resource Monitoring and Control (RMC) Subsystem. Die Installation der Knoten erfolgt über Diskette, CD oder PXE mit AutoYaST oder Red Hat Kickstart. In gewissem Maße kann inhomogene Hardware verwendet werden (siehe IBM CSM Planning and Installation Guide ). Durch den Einsatz des CSM High Availability Management Servers kann der CSM Server hoch-verfügbar ausgelegt werden. Tabelle 16 Übersichtstafel: Managementsystem CSM 91

106 Betrachtung der Managementsysteme 4.4 OSCAR OSCAR (Open Source Cluster Application Resources) 53 ist ein spezielles Softwarepaket für die Vereinfachung der Installation und Verwaltung eines HPC Clusters. Die aktuelle Version ist 4.1 vom 22. April OSCAR nimmt dem Administrator die komplette Installation von Beginn an ab. Die Wissensbarriere bei OSCAR liegt dadurch für den Einstieg nicht sehr hoch. Das Ziel von OSCAR ist, die besten freien Softwarepakete in einer Installationsroutine zu bündeln. Entwickelt und betreut wird OSCAR von der Open Cluster Group 54, einer informellen Gruppe die das Ziel hat, die Verbreitung von Clustern zu unterstützen. Im Laufe der Jahre fand sich herstellerseitige Unterstützung zum Beispiel von Dell, IBM oder INTEL. OSCAR zielt auf den Einsatz auf HPC Systemen. Eine neue Untergruppe kümmert sich seit Neuestem um die Integration in HA Cluster (HA-OSCAR). Eine homogene Hardware ist nicht unbedingt erforderlich, vereinfacht aber die Installation. Vom Aufbau verwendet OSCAR ein asymmetrisches Modell (siehe ANHANG A). Abbildung 34 zeigt einen für OSCAR typischen Cluster Aufbau. Der normale Anwender loggt sich ausschließlich auf dem Masterknoten ein. OSCAR sorgt für passwortloses SSH zwischen Masterknoten und Rechenknoten

107 Betrachtung der Managementsysteme Abbildung 34 Aufbau eines OSCAR Clusters Die Wahl der unterstützten Hardware ist bei OSCAR eher konservativ gestaltet. Dies ist auch einer der großen Kritikpunkte an diesem Managementsystem. OSCAR selbst bringt kein Linux mit, sondern sitzt On-Top auf einer Linuxdistribution. Die unterstützte Hardware wird durch die folgenden fünf Distributionen beschränkt: Red Hat Linux 9 (x86_32) Red Hat Enterprise Linux 3 (x86_32, ia64) Fedora CORE 3 (x86_32) [nicht für Produktivsysteme geeignet] Fedora CORE 2 (x86_32) Mandriva Linux 10.0 (x86_32) Damit ist für die aktuelle Version 4.1 der Einsatz eines modernen 64 Bit-Systems nicht ohne weiteres möglich. Mit Sachverstand lässt sich die Installationsroutine aber für 64 Bit-Systeme anpassen. 93

108 Betrachtung der Managementsysteme Die Clusterinstallation mit OSCAR 4.1 Die Installation von OSCAR basiert auf der System Installation Suite (SIS). Diese sorgt für die nötige Festplatteninstallationen. SIS verwendet eine RPM-basierte Installation (SystemInstaller). Für den vorliegenden Test wurde Fedora CORE 2 verwendet. Die dritte Release von Fedora wird leider nicht komplett unterstützt. Es existiert zwar ein Workaround, um OSCAR 4.1 auf Fedora CORE 3 zu installieren, jedoch konnten wohl nicht alle Funktionen eingebunden werden. Nach erfolgter Installation des gewählten Betriebssystems kann mit der Konfiguration und Installation von OSCAR begonnen werden. Die Sourcen können zuerst von bezogen werden. Die folgenden Installationsschritte müssen als Benutzer root durchgeführt werden: Zunächst muss das Linux Betriebssystem auf die Funktion als Masterknoten vorbereitet werden. Dazu wird ein eigener privater Adressraum für die Managementnetzwerkkarte eingerichtet, zum Bespiel die IP-Adresse für die interne Netzwerkkarte des Masterknotens. Nun kann mit der Einspielung der RPM-Pakete in das Repository von OSCAR begonnen werden. Diese Einspielung muss vor der Installation stattfinden, da automatisch nach den Paketen an der entsprechenden Stelle gesucht wird. Die RPM-Pakete auf den Installationsmedien des Linuxbetriebssystems werden alle nach /tftpboot/rpm kopiert. Dieses Verzeichnis muss vorher angelegt werden. Nach diesem zeitaufwändigen Vorgang kann das Archiv mit den Quellen von OSCAR entpackt werden. Ein standardmäßiges./configure und make install startet nach Ausgabe zahlreicher Meldungen auf der Konsole den OSCAR Installation Wizard (siehe Abbildung 35). 94

109 Betrachtung der Managementsysteme Abbildung 35 Der OSCAR Installation Wizard Übersichtlich aufgeführt lassen sich die einzelnen Schritte für die Installation des Clusters ablesen. Es können zusätzliche Pakete hinzugefügt und konfiguriert werden (siehe Abbildung 36). Abbildung 36 OSCAR Package Selector 95

110 Betrachtung der Managementsysteme Nachdem komfortabel mit der Maus die Einstellungen festgelegt wurden, kann mit dem Aufbau des Knotenimages begonnen werden. Diese Prozedur läuft automatisch ab und dauert nur wenige Minuten (siehe Abbildung 37). Abbildung 37 OSCAR: Generierung des Knotenimages Im nachfolgenden Schritt können die Clusterknoten definiert werden. Anschließend werden sie gestartet und die DHCP-Anfragen der PXE-fähigen Netzwerkkarten mittels der in Abbildung 38 dargestellten Maske abgefangen. Die Knoten können auch mit Hilfe einer in OSCAR erstellbaren Diskette gestartet werden, falls sie keine PXE-fähigen Netzwerkkarten besitzen. Abbildung 38 Die Definition der Knoten bei OSCAR 96