Gliederung - Uni Kassel

Studiengang Informatik, Universität Kassel
Ibis
Jan Frederik Naujoks
Gliederung:
1. Einleitung
2. Funktionalitäten und Features
3. Ibis-Architektur, -Einbindung und -Portability Layer
3.1 Architektur
3.2 Ibis Implementierungen und Applikationen
3.3 Kommunikation über den Ibis Portability Layer
4. Anwendungsentwicklung mit Ibis
4.1 Satin
4.2 Ibis RMI und GMI
5. Ibis und Middleware
6. Portabilität
7. Nutzung und Weiterentwicklung
8. Fazit
Quellen
1
1. Einleitung
Eines der Hauptprobleme bei der Erstellung von Anwendungen, die auf Grids ausgeführt
werden sollen, ist, dass Grids aus einer Vielzahl von Architekturen und Netzwerken bestehen
können. Es ist also notwendig, dass die Applikation, die man ausführen möchte, alle diese
Architekturen unterstützt und auf die unterschiedlichen Anbindungen im Netzwerk reagiert,
bzw. mit diesen umgehen kann.
Hinzu kommt, dass die Kommunikation zwischen den einzelnen Teilen bzw. Instanzen der
Anwendung möglichst schnell und effizient ablaufen muss.
Eine Möglichkeit, auf die Heterogenität der Grids und den damit verbundenen Aufwand
beim Erstellen von Anwendungen zu reagieren, ist die Verwendung von Java und der Java
Virtual Machine. Durch die Verfügbarkeit der Java Virtual Machine für eine große Anzahl
unterschiedlicher Architekturen und Betriebssysteme sind in Java geschriebene Programme
von sich aus portabler als z.B. in C oder FORTRAN geschriebene.
Ein Nachteil von Java, die niedrigere Performance im Vergleich zu C/C++, verschwindet durch
moderne Just In Time Compiler. Diese erreichen Ausführungszeiten, die mit denen von CProgrammen vergleichbar sind.
Weiter spricht für Java, dass Möglichkeiten zum parallelen und verteilten Rechnen bereits
integriert sind.
Eine Lösung für das Problem der schnellen Kommunikation bietet Java jedoch nicht. Java
bietet zwar mit Remote Method Invocation (RMI) eine Technologie zur Kommunikation
zwischen verschiedenen Virtual Machines an, RMI erzeugt jedoch einen massiven Overhead
und ist viel weniger effizient als MPI oder RPC.
Um die Vorteile von Java zu nutzen und die Schwächen auszugleichen, wurde das Projekt Ibis
begonnen.
Bei Ibis handelt es sich um ein Open Source Java-Grid-Software-Projekt welches von der
Computer Systems group (Teil des Computer Science department), an der Vrije Universiteit
in Amsterdam (Niederlande), entwickelt wurde.
Ziel von Ibis ist es, eine Java Programmierumgebung für Grids zur Verfügung zu stellen, die
die Flexibilität von Java erhält und hocheffiziente Kommunikation bietet.
Im Abschnitt 2 dieses Dokuments soll ein kurzer Überblick über die verschiedenen, von Ibis
bereitgestellten, Funktionalitäten und Features gegeben werden. In Abschnitt 3 wird kurz
auf die Ibis zugrunde liegende Architektur eingegangen. Abschnitt 4 stellt kurz einige der
Programmiermodelle vor, Abschnitt 5 behandelt die Verwendung von Middleware, Abschnitt
6 geht auf die Portabilität von Ibis-Anwendungen ein und Abschnitt 7 gibt einen kurzen
Überblick wie Ibis bereits verwendet wird und inwiefern das Projekt aktiv ist.
2
2. Funktionalitäten und Features
Quellen: [1][2][4]
Das Herausstellungsmerkmal von Ibis ist, dass es die Flexibilität beziehungsweise
Plattformunabhängigkeit von Java bietet und diese noch erweitert. Ibis läuft auf jeder
Standard-Java Virtual Machine, kann jedoch auch systemnative, optimierte Compiler
verwenden. Für die Kommunikation gilt das Gleiche: Ibis kann sowohl auf TCP/IP und UDP
zurückgreifen oder systemnahe Techniken wie MPI oder Myrinet GM verwenden.
Ein weiteres Merkmal von Ibis ist die Flexibilität der Kommunikation durch den Ibis
Portability Layer. Dieser bietet verschiedene Interfaces an, die die Kommunikationsebene
abstrahieren. Durch diese Abstraktion ist es möglich, Anwendungen unabhängig von später
verwendeten, eventuell nativen, Kommunikationsprotokollen zu erstellen.
Über verschiedene, zur Laufzeit austauschbare Ibis Portability Layer-Implementierungen ist
es möglich, die für die jeweilige Umgebung und Anwendungsanforderung beste
Kommunikationsmethode zu verwenden.
Ibis kann sowohl in ausfallsicheren Netzen eingesetzt werden als auch in Netzen, in denen
nicht sichergestellt ist, dass versendete Nachrichten den Empfänger erreichen, bzw. eine
erwartete Nachricht eintrifft.
Dies beinhaltet auch, dass Ibis sich dynamisch an die Anzahl der Knoten im Grid anpassen
kann.
Weiter wurde im Rahmen von Ibis ein zero-copy Protokoll für Java implementiert um den,
bei der Kommunikation entstehenden, Overhead zu reduzieren. Zero-copy Protokolle
nehmen sich dem Problem an, dass bei der Kommunikation mit vielen Clients identische
Nachrichten oft mehrfach im Speicher vorliegen. Durch das nichtvorhandensein dieser
Kopien werden Rechen- und Speicherkapazitäten frei. [6]
Weitere Bestandteile des Ibis Projektes:
•
Verschiedene Programmiermodelle, die alle in ein System integriert sind und
gleichzeitig verwendbar sind:
o RMI – Java-Equivalent zu RPC
o GMI – RMI mit Gruppenkommunikationserweiterung
o RepMI – Java-Erweiterung für effiziente, replizierbare Objekte
o Satin – stellt devide-and-conquer und replicated-worker-Programmiermodelle
zur Verfügung, speziell für Grid-Systeme gedacht.
•
Das Java Grid Application Toolkit (JavaGAT) bietet verschiedene Schnittstellen zur
Überwachung und Wartung von Grid-Applikationen. JavaGAT wird zwischen
3
Applikation und Grid-Middleware geschaltet. Eine Unterstützung verschiedener
Middleware-Systeme (unter anderem Globus, GridLab, SSH und Zorilla) ist bereits
vorhanden. Durch Verwendung/Entwicklung von Plugins (sog. adaptors) ist es
möglich, weitere Systeme anzubinden.
•
Zorilla, eine Peer-To-Peer-Grid-Middleware. Zorilla implementiert zum Beispiel
Scheduling, Dateiübertragung und Sicherheit. Es konfiguriert sich weitestgehend
selbst, die Peers werden selbständig zu einem Grid organisiert.
3. Ibis-Architektur, -Einbindung und -Portability Layer
In diesem Abschnitt soll die Flexibilität von Ibis weiter aufgezeigt werden. Hierzu wird kurz
auf die Architektur von Ibis eingegangen. Weiter wird kurz die Einbindung von Ibis in eine
Anwendung gezeigt. Abschließend soll dieser Abschnitt noch einen kurzen Einblick in den Ibis
Portability Layer geben.
3.1 Architektur
Quellen: [4]
Zentraler Bestandteil von Ibis ist der Ibis Portability Layer. Dieser stellt die Schnittstellen
zwischen der Anwendung und ihrer Laufzeitumgebung und Kommunikationsprotokollen
bereit (siehe Abbildung 1). Dadurch wird es möglich Anwendungen auf unterschiedlichen,
auf spezielle Architekturen optimierte, Ibis-Implementierungen einzusetzen. Ziel ist, dass
der Eisatz von Ibis beziehungsweise Java keinesfalls die Nutzung schneller und optimierter
Techniken unterbindet, sondern diese bereits vorhandenen Ressourcen nutzt.
Anwendungen, die Ibis verwenden, können zwar direkt an den Ibis Portability Layer
angebunden werden, die üblichere Vorgehensweise ist jedoch die bereitgestellten Modelle
(RMI, GMI, Satin, MPJ, RepMI (noch in Entwicklung)) zu verwenden.
Abbildung 1
Original Quelle: http://www.cs.vu.nl/ibis/images/ibis-design.png (Stand 15.01.2007)
4
3.2 Ibis Implementierungen und Applikationen
Quellen: [4][2]
Wie bereits klargestellt, kann es für unterschiedliche Architekturen unterschiedliche
Implementierungen von Ibis geben. Genauso kann es auch mehrere Implementierungen für
eine Architektur geben. Welche Implementierung von Ibis für die Anwendung genutzt wird,
entscheidet sich während der Laufzeit der Anwendung.
Eine von der Anwendung geladene Ibis-Implementierung wird im Weiteren als Ibis-Instanz
bezeichnet.
Ibis bietet die Möglichkeit, mehrere Ibis-Instanzen innerhalb einer Anwendung zu betreiben.
Jede Instanz der Anwendung, die mit Ibis kommunizieren soll, muss eine Ibis-Instanz
erstellen.
Beim Erstellen einer Ibis-Instanz oder beim Start einer Ibis-Anwendung werden
Anforderungen festgelegt, die die Kommunikation erfüllen muss. Anhand dieser
Anforderungen wählt Ibis während der Laufzeit die Ibis-Instanz, die diese Anforderungen am
besten erfüllt.
Die bereitgestellten Programmiermodelle definieren ihre Anforderungen üblicherweise
selbst.
Codebeispiel: Erstellen einer Ibis-Instanz
(Code aus [2])
Ibis ibis = null;
try {
ibis = Ibis.createIbis(props, null);
} catch(NoMatchingIbisException e) {
System.err.println("Could not find a matching Ibis");
...
}
Dieser Code erstellt eine neue Ibis-Instanz. Über den Parameter „props“ (vom Typ
StaticProperties [3]) wird festgelegt, welche Eigenschaften die Instanz haben soll.
3.3 Der Ibis Portability Layer
Quellen: [4][2]
Der Ibis Portability Layer (IPL) ist die Schnittstelle zwischen den unterschiedlichen IbisInstanzen und der Anwendung. Der IPL abstrahiert die Kommunikationsebene und
ermöglicht es, dass Anwendungen die für die jeweilige Architektur beste Ibis-Instanz
verwenden können, ohne dabei den Quellcode anpassen zu müssen.
Der IPL trennt eingehende und ausgehende Verbindungen strikt voneinander. Dies
ermöglicht es, verschiedene Anforderungen für eingehende bzw. ausgehende Verbindungen
zu definieren.
Zur Kommunikation stehen sowohl blockierende Methoden zur Verfügung, als auch
Methoden die auf Timeouts reagieren. Streaming von Daten ist ebenfalls möglich.
5
Zu beachten ist, dass der IPL Ausfälle oder Fehler nicht eigenständig behandeln kann. Es
werden jedoch Methoden gestellt, die es ermöglichen auf derartige Ereignisse zu reagieren.
4. Anwendungsentwicklung mit Ibis
Quellen: [1] [2] [4]
Auch wenn es Möglich ist eine Anwendung nur unter Verwendung des Ibis Portability Layers
zu entwickeln, so ist die empfohlene Vorgehensweise die Verwendung der bereitgestellten
Programmiermodelle. Jedes dieser Modelle bevorzugt zwar einen oder mehrere
Anwendungstypen, da jedoch unterschiedliche Modelle integriert sind, ist Ibis für ein breites
Spektrum an Anwendungen einsetzbar.
Dieser Abschnitt stellt kurz drei dieser Programmiermodelle vor.
4.1 Satin
Quellen: [4][2]
Satin bietet, auf Ibis aufsetzend, devide-and-conquer-Funktionalitäten für Java. Ziel von Satin
ist, devide-and-conquer-Anwendungen innerhalb weitverteilter Rechnernetze einsetzen zu
können. Dabei soll die Satin-Runtime die Optimierungen für derartige Netze enthalten und
somit ein optimieren der Anwendung unnötig machen.
Satin bietet eine Reihe von Mechanismen an um mit den Problemen, die in dieser Art von
Netzen entstehen, umzugehen.
Satin ist fehlertolerant und kann auf hinzukommen oder wegfallen von Prozessoren
reagieren. Hierzu restrukturiert Satin den Berechnungsbaum. Durch diese Vorgehensweise
können redundante Berechnungen verhindert werden. Weiter können Teilberechnungen
von ausgefallenen Prozessoren ohne den Verlust von Rechenzeit gerettet werden.
Durch diese Fehlertoleranz und durch verschiedene load-balancing-Mechanismen macht es
Satin zusammen mit Ibis möglich, devide-and-conquer-Anwendungen in Grids zu nutzen.
4.2 Ibis RMI und GMI
Quellen: [4]
Ibis bietet eine eigene Implementierung der Java Remote Method Invocation [7]. Durch
unterschiedliche Optimierungen steigert Ibis die Leistungsfähigkeit von RMI stark.
Ibis Group Method Invocation (GMI) erlaubt es Methoden auf einem einzelnen Objekt
auszuführen oder auf Objektgruppen. Werden Gruppen aufgerufen so ist es möglich
individuelle Parameter zu übergeben. Ergebnisse können (wie mit RMI) zurückgegeben,
verworfen, oder zu einem einzigen Ergebnis zusammengefasst werden. Hierdurch erleichtert
GMI die parallele Programmierung.
6
5. Ibis und Middleware
Quellen: [4]
Ibis unterstützt durch das Java Grid Application Toolkit (JavaGAT) unter anderem Globus,
GridLab, SSH und Zorilla. JavaGAT ist modular erweiterbar, eine Unterstützung weiterer
Systeme ist also möglich und kann bei Bedarf unter Verwendung der JavaGAT APIs
nachträglich hinzugefügt werden. Zur Zeit ist unter anderem ein Adapter zu ProActive in
Entwicklung.
6. Portabilität
Da Ibis nur die Standard-Java Virtual Machine benötigt, sind Ibis-Anwendungen auf fast allen
Systemen lauffähig (sofern Java installiert ist). Eine Liste der von Sun unterstützten
Plattformen ist im Internet unter http://java.sun.com/j2se/1.5.0/system-configurations.html
verfügbar.
7. Nutzung und Weiterentwicklung
Quellen: [4]
Ibis wird zurzeit unter anderem zur Auswertung von Elektroenzephalogramm-Daten
verwendet, sowie bei der Berechnung und Simulation von Boden-Struktur-Interaktionen.
Ibis dient weiter als Basis für verschiedene Projekte die sich mit Java in Grids beschäftigen,
so wurde unter anderem ProActive auf Ibis portiert.
Die neuste Version von Ibis (Version 1.4) wurde im September 2006 freigegeben. Das Projekt
scheint nach wie vor aktiv weiterentwickelt zu werden, zurzeit wird an der Integration von
RepMI gearbeitet, einem weiteren Programmiermodell das replizierbare Objekte bieten soll.
7
8. Fazit
Ibis erleichtert die Entwicklung von Grid-Anwendungen auf unterschiedliche Arten. Das
Problem der Heterogenität wird durch die Verwendung von Java gelöst.
Die Probleme die Java verursacht, vor allem die im Vergleich zu C/FORTRAN niedrigere
Performance, werden durch eigene Konzepte verringert oder gelöst. Bestehende,
systemoptimierte Treiber und Techniken können von Ibis genutzt werden, ohne dass
Anwendungen angepasst oder neu kompiliert werden müssen. Durch die modulare
Erweiterbarkeit von JavaGAT ist eine Anbindung an fast jede Grid-Middleware möglich,
wodurch die Überwachung und Steuerung der Ibis-Anwendungen zusätzlich vereinfacht
wird. Programmiermodelle wie Satin vereinfachen die Entwicklung von parallelen
Programmen.
Zusätzlich kann Ibis mit dem wegfallen oder hinzukommen von Knoten im Grid umgehen.
Durch diese Eigenschaften und die aktive Weiterentwicklung ist Ibis eine hervorragende
Plattform zur Entwicklung von Grid-Anwendungen.
Quellen
[1] Ibis: a Flexible and Efficient Java-based Grid Programming Environment Rob V. van
Nieuwpoort, Jason Maassen, Gosia Wrzesi´nska, Rutger Hofman, Ceriel Jacobs, Thilo
Kielmann, Henri E. Bal Faculty of Sciences, Department of Computer Science, Vrije
Universiteit De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
http://www.cs.vu.nl/ibis/papers/nieuwpoort_cpe_05.pdf (Stand 15.01.2007)
[2] Ibis Programmer's Manual by The Ibis Group, Ceriel JH Jacobs 2006-09-15
http://www.cs.vu.nl/ibis/progman/progman.html (Stand 15.01.2007)
[3] Ibis JavaDoc http://www.cs.vu.nl/ibis/api/index.html (Stand 15.01.2007)
[4]Ibis Homepage: http://www.cs.vu.nl/ibis/index.html (Stand 15.01.2007)
[5] Liste von Sun Microsystems unterstützter Plattformen:
http://java.sun.com/j2se/1.5.0/system-configurations.html (Stand 15.01.2007)
[6] Evaluation of a Zero-Copy Protocol Implementation (2001), K. Skevik and T. Plagemann
and V. Groebel, http://citeseer.ist.psu.edu/skevik01evaluation.html (Stand 21.01.2007)
[7] http://java.sun.com/j2se/1.4.2/docs/guide/rmi/index.html Copyright © 2003 Sun
Microsystems, Inc. (Stand 21.01.2007)
8