Verteiltes Rendern im GRID - Distributed Rendering within a GRID mit Ausrichtung auf D-Grid
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Verteiltes Rendern im GRID
mit Ausrichtung auf D-Grid
Distributed Rendering within a GRID
focusing on D-Grid
Bachelorarbeit Bachelor of Science
vorgelegt an der Fachhochschule Köln Campus
Gummersbach im Studiengang Medieninformatik
ausgearbeitet von: Mathias Häusler
Erster Prüfer: Prof. Horst Stenzel
Zweiter Prüfer: Prof. Dr. Kristian Fischer
Gummersbach, im Februar 2009
–2– Einleitung In dieser Bachelorarbeit wird eine Einführung in die GRID-Technologie mit spezieller Aus- richtung auf D-GRID gegeben. Zusätzlich wird die Technologie zur Verteilung von 3D-Ren- dering beschrieben und das Verfahren von 3D-Rendering vorgestellt. Vordergründig wird die Möglichkeit geprüft eine bereits implementierte OpenSource Lösung zur Verteilung von 3D- Renderaufträgen – DrQueue – in D-GRID zu portieren. Mögliche Unterschiede und mögliches Konfliktpotential werden aufgezeigt. Im speziellen stützt sich diese Arbeit auf die Erkenntnisse, welche der Autor sich im Laufe seines Praxisprojektes „Verteiltes Rendern in heterogenen Netzwerken“ angeeignet hat. This bachelor thesis gives an introduction into GRID-Technologies particularly focusing on the D-GRID technology. Additionally the technology of 3D rendering distribution will be explained. Especially the possibility of porting an existing open source solution for distributing 3D rendering jobs – DrQueue – into D-GRID will be examined. Possible differences between D-GRID infrastructure and DrQueue as well as possible conflict potential will be specified. This thesis specifically draws on conclusions which the author gained during his practical- project: „Distributed Rendering in heterogeneous Environments“.
–3–
Inhaltsverzeichnis
1. Einleitung ........................................................................................... 2
2. Was ist ein Grid?..................................................................................5
2.1 Herkunft des Begriffes „Grid“........................................................................... 5
2.2 Three Point Checklist for a Grid ...................................................................... 8
2.3 Fazit – Was ist ein Grid? .................................................................................. 9
2.3.1 Definition Grid.....................................................................................................9
2.3.2 Kritikpunkte........................................................................................................10
2.4 Grid Klassifikation.......................................................................................... 11
2.4.1 Kritikpunkte an der Aufteilung eines Grid ........................................................12
2.5 Grid-Architektur.............................................................................................. 14
2.6 Grid Middleware............................................................................................. 20
2.6.1 Definition Middleware.......................................................................................20
2.6.2 Grid-Middleware................................................................................................20
2.7 Webservice-Resource Framework................................................................... 25
3. D-Grid . .............................................................................................. 27
3.1 Was ist D-GRID?............................................................................................. 27
3.1.1 Zugang zu den Ressourcen.................................................................................29
3.2 D-GRID Architektur........................................................................................ 30
3.2.1 D-Grid Architektur.............................................................................................31
3.2.2 High Level Application Progamming Tools D-Grid..........................................31
3.2.3 Fazit ...................................................................................................................32
3.3 Test- und Programmierumgebungen für D-Grid............................................. 33
4. 3D-Rendering .................................................................................... 35
4.2 Renderfarm...................................................................................................... 39
4.3 Renderfarmkonzept und Übertragbarkeit auf Grid-Computing...................... 41
4.3.1 Master..................................................................................................... 41
4.3.2 Slaves...................................................................................................... 43
4.3.4 Fazit – Architekturvergleich auf konzeptioneller Ebene....................................44
4.4 DrQueue Architektur....................................................................................... 45
4.4.1 DrQueue Architektur im Vergleich zu Grid........................................................45
4.4.2 DrQueue Klassendiagramm...............................................................................49
4.4.3 Fazit - DrQueue Portierung ...............................................................................51
Glossar.................................................................................................... 53
Literaturverzeichnis.............................................................................. 54
–4–
–5–
2. Was ist ein Grid?
Grid und Grid-Computing können verschiedene Bedeutung für verschiedene Individuen
haben.1 Daher gibt es auch unterschiedliche Definitionen aus unterschiedlichen Perspektiven,
mit verschiedenen Ansätzen, wie man sich dem Begriff des Grid oder des Grid-Computing
nähern kann. Die gängigsten Definitionen und Taxonomien werden in diesem Kapitel vorge-
stellt und miteinander verglichen.
2.1 Herkunft des Begriffes „Grid“
Der Begriff „Grid“ kann zur Zeit nicht vollständig und korrekt definiert werden. Zum einen
liegt dieser Sachverhalt daran, dass es verschiedene Experten mit verschiedenen Ansichten zu
diesem Thema gibt und zum anderen, dass sich die Grid-Technologie noch in der Entwick-
lungsphase befindet. Deshalb werden und müssen bereits bestehende Definitionen fortwährend
angepasst werden. Um den Begriff des „Grid“ zu verstehen sollten wir unseren Blick zuerst in
die Vergangenheit, in die Geschichte der Computertechnologie richten. In diesem Kapitel wird
die Evolution des Begriffes „Grid“ beschrieben und vergleichend dargestellt.
Die ersten Wissenschaftler, die auf dem Gebiet der Netzwerktechnologien forschten, legten
mit ihren Visionen einen Grundpfeiler für unseren heutigen, bereits erreichten technologischen
Entwicklungsstand und geben mit ihren Visionen immer noch Ziele vor, welche für die Mensch-
heit aus heutiger Sicht „zum Greifen nahe“ erreichbar sind. So auch die Grid-Technologie.
Bereits 1968 entwickelte J. C. R. Licklider, in seinem Memorandum
„Memorandum For Members and Affiliates of the Intergalactic Computer Network“2 die Vision
eines „Intergalactic Computer Network“, welches als Vorläufer der Idee des Internets, aber auch
der Idee des Grids gesehen werden kann. Len Kleinrock, ein Wissenschaftler der Universität
von Kalifornien, L.A., hatte bereits zehn Jahre zuvor die mathematischen Grundlagen für die
1 Vgl. Introduction to Grid Computing, An IBM Redbooks publication, (2005), S. 3
2 Vgl. Memorandum For Members and Affiliates of the Intergalactic Computer
Network, J.C.R. Licklider,
URL: http://www.kurzweilai.net/articles/art0366.html?printable=1, [15.02.2009]–6–
Datenpaketvermittlung in Computernetzwerken geschaffen. So war es auch Len Kleinrock, der
als erstes Computer paketbasiert miteinander, innerhalb des amerikanischen ARPA-Projektes,
kommunizieren lies. In diesem Umfeld konnte Len Kleinrock folgende Vision entwickeln:
„The spread of computer utilities, which like present electric and telphone utilities will
service individual homes and offices across the country.“3
Die Postulation dieser Vision durch Len Kleinrock im Jahre 1969 gilt als die
Geburtsstunde des Grids. Seine Vision bestand darin, dass Computerhardware, Computerdiens-
te und Computerprogramme, in Heimen und Büros, über die gleiche Art und Weise verbreitet
werden, wie damalige Telefondienste und Elektrizität. Diese abstrakte Vision stellt die erste
Definition eines Grids dar. Aus dieser Definition geht vor allem der Vorteil dieser Technologie
hervor, aber auch wie man auf diese Technologie zugreifen können sollte. Erst 30 Jahre später,
im Jahre 1998, wurde der Gedanke des Grids erneut formuliert:
“A computational grid is a hardware and software infrastructure that provides
dependable, consistent, pervasive, and inexpensive access to high-end computational
capabilities.”4
Obige Definition wurde von Ian Foster und Carl Kesselmann in dem Buch „The Grid:
Blueprint for a New Computing Infrastructure“ 1998 veröffentlich. Aus der Definiti-
on geht hervor was ein Grid ist: eine Hardware- und Software Infrastruktur, die verlässlich,
beständig, überall verfügbar und kostengünstig Zugriff auf High-End-Rechenleistung bietet. Die
qualitative Dimension dieser Definition liegt vor allem auf der technischen Ebene, da beschrie-
ben wird aus welchen Komponenten das Grid besteht und welche Anforderungen diese Kom-
ponenten erfüllen müssen. Wie aus der Definition von Len Kleinrock gehen aus der Definition
von Ian Foster und Carl Kesselmann aus dem Jahre 1998 ebenfalls die Vorteile der Techno-
logie des Grids für den Endanwender hervor: „überall verfügbar und kostengünstig“. Diese
Definition kann als Grundlage zur weiteren Definition eines Grids gesehen werden.
Kritik daran kann man an ihrer fast beliebigen Anwendbarkeit auf Computersysteme üben.
3 Vgl. Pressebericht, Office of Public Information, University of California,
URL: http://www.lk.cs.ucla.edu/LK/Bib/REPORT/press.html [15.02.2009]
4 Ian Foster, What is the grid? A three point checklist, 2002
URL: http://www-fp.mcs.anl.gov/~foster/Articles/WhatIsTheGrid.pdf [15.02.2009]–7–
Man könnte sie durchaus auf ein heutiges mobiles Computerssystem, wie zum Beispiel ein
„Mac Book Pro5“, anwenden:
Ein „Mac Book Pro“ besteht aus einer Hardware- und Softwareinfrastruktur, welche
verlässlich, beständig, überall verfügbar und kostengünstig high-end Rechenleistung bie-
tet. An der Anwendung dieser Definition auf ein „Mac Book Pro“ kann man wiederum
kritisieren, dass der Erwerb dieses Gerätes alles andere als kostengünstig ist. Ob etwas
kostengünstig ist, oder nicht hängt allerdings vom tatsächlichen Nutzungsgrad sowie dem
damit einhergehenden Kosten zu Nutzenverhältnis ab und nicht vom absoluten Betrag
des Anschaffungspreises. Aus der Tatsache, dass die 1998 von Ian Foster veröffentlichte
Definition eine gewisse Beliebigkeit in ihrer Anwendbarkeit aufweist, hat Ian Foster zusam-
men mit Jacob Kesselmann und Steve Tuecke die Definition in dem Artikel „The Anatomy of
the Grid“ zunächst um soziale und politische Aspekte erweitert und in seinem Artikel „What
is the Grid? A Three Point Checklist“, um eine drei Punkte Checkliste ergänzt, mit welcher
sicher gestellt werden kann ob es sich um ein Grid handelt oder nicht. Zunächst wird hier die
Erweiterung bezüglich der sozialen und politischen Aspekte vorgestellt:
„First, we review the “Grid problem,” which we define as flexible, secure, coordinated
resource sharing among dynamic collections of individuals, institutions, and resources—
what we refer to as virtual organizations.“6
Im oben genannten Zitat wird das Grid nicht mehr nur als Hardware- und Softwareinfra-
struktur gesehen, sondern als eine anpassungsfähige, sichere, koordinierte Teilung vorhandener
Ressourcen zwischen einer Sammlung von Individuen, Institutionen und Ressourcen
wiederum selbst, welche fortan als virtuelle Organisationen bezeichnet werden. Diese Sicht-
weise auf ein Grid, welche zu obiger Definition führt, birgt eine ganz andere Qualität. Die
Qualität liegt darin, dass ein Grid als Ressourcenteilmaschinerie zwischen verschiedenen
sozialen Gruppen, gesehen wird. Im Vordergrund stehen nicht mehr Hard- und Software
selbst, sondern die Teilung dieser Ressourcen zwischen virtuellen Organisationen und deren
Mitgliedern. Im Gegensatz zu denen in diesem Kapitel zuvor behandelten Definitionen werden
in dieser sozialen Definition weder die Vorteile der Technologie noch die dafür zur Verfügung
5 Vgl. URL: http://www.apple.com/de/macbookpro/ [15.02.2009]
6 Vgl, Ian Foster, Carl Kesselmann, Steven Tuecke, The Anatomy of a Grid, 2001
URL: http://www.globus.org/alliance/publications/papers/anatomy.pdf [15.02.2009]–8–
stehende Technologie beschrieben. Im Gegensatz zu dieser Definition handelt die Abhandlung,
aus dem dieses Zitat stammt, nicht nur von den sozialen Aspekten und der sozialen Architektur
eines Grids, sondern geht auch detailliert auf die technischen Aspekte, wie Architektur oder
Protokolle eines Grids ein. Auf der Basis dieser Abhandlung hat Ian Foster eine drei Punkte
Checkliste ausgearbeitet, die den Begriff des Grids ziemlich genau abgrenzt:
2.2 Three Point Checklist for a Grid
1) coordinates resources that are not subject to centralized control …(A Grid integra-
tes and coordinates resources and users that live within different control domains—for
example, the user’s desktop vs. central computing; different administrative units of the
same company; or different companies; and addresses the issues of security, policy, pay-
ment, membership, and so forth that arise in these settings. Otherwise, we are dealing
with a local management system.)
2) … using standard, open, general-purpose protocols and interfaces…
(A Grid is built from multi-purpose protocols and interfaces that address such fundamen-
tal issues as authentication, authorization, resource discovery, and resource access. As I
discuss further below, it is important that these protocols and interfaces be standard and
open. Otherwise, we are dealing with an applicationspecific system.)
3) … to deliver nontrivial qualities of service. (A Grid allows its constituent resources
to be used in a coordinated fashion to deliver various qualities of service, relating for
example to response time, throughput, availability, and security, and/or co-allocation of
multiple resource types to meet complex user demands, so that the utility of the combined
system is significantly greater than that of the sum of its parts.) 7
Diese „drei Punkte Checkliste“ erlaubt die Abgrenzung des Begriffes „Grid“ von anderen
Technologien. So kann man den Begriff „Grid“ – trivial gesehen – nicht ohne weiteres unter
Berücksichtigung der „drei Punkte Checkliste“ weiterhin8 auf ein „MacBook Pro“, anwenden.
7 Vgl, Ian Foster, Carl Kesselmann, Steven Tuecke, The Anatomy of a Grid, 2001
URL: http://www.globus.org/alliance/publications/papers/anatomy.pdf [15.02.2009]
8 siehe oben, S. 7–9– Schon im ersten Absatz der obigen „drei Punkte Checkliste“ käme man zu dem Problem, dass ein „Mac Book Pro“ einer zentralisierten Kontrolle unterliegt und damit gegen den ersten Satz des ersten Absatzes der obigen Checkliste verstößt: (a grid) “... coordinates resources that are not subject to centralized control“. Darüber hinaus bedient ein „MacBook Pro“ auch nicht Benutzer mehrerer Domänen, was gegen folgende Aussage der obigen „drei Punkte Checklis- te“ verstößt: „A Grid integrates and coordinates resources and users that live within different control domains“. Insbesondere dient die „drei Punkte Checkliste“ zur Abgrenzung von Systemen, die grid- ähnlich sind. Fälschlicherweise – teilweise sicherlich auch weil der Begriff des „Grids“ oder „Grid-Computings“ gerade in Mode ist – oder aus marketingtechnischen Gründen, werden bestimmte Systeme als „Grid“ bezeichnet, die eigentlich keine Grid-Systeme sind. So zum Beispiel: „Meta Computing“, „Peer 2 Peer Computing“, oder „Cluster Computing“. 2.3 Fazit – Was ist ein Grid? In diesem Fazit wird eine Definition des Begriffes Grid, welche auf denen in den beiden vorausgegangenen Unterkapiteln vorgestellten Definitionen und Visionen basiert, versucht zusammenfassend zu geben. 2.3.1 Definition Grid Ein Grid ist ein verteiltes und vernetztes Computersystem, welches auf einer Infra- struktur aufbaut, die aus Hard- und Softwareressourcen, sowie aus – in dieser Arbeit so- genannten – weichen Ressourcen besteht. Die Infrastruktur eines Grids baut wiederum auf den Protokollen und der Infrastruktur des Internets auf. Weiche Ressourcen werden an dieser Stelle als die soziale und politische Organisation der Grid Hard- und Softwareressourcen bezeichnet. Die soziale und politische Organisation erfolgt in sogenannten virtuellen Organisationen. Die hier genannte „politische Organisation“ bezeichnet die Restriktionen und Rechte die Mitglieder von virtuellen Organisationen bei der Benutzung des Grids innerhalb dieser inne haben. Die soziale und politische Organisation ist wesentlicher Teil eines Grids und nicht minder wichtig als Hardware- und Softwareressourcen selbst. Die Organisation der Ressourcen
– 10 –
erfolgt autonom, ohne zentralisierende Instanz und geographische Abhängigkeit. Ein Grid
nutzt offene allgemein gehaltene Protokolle und Schnittstellen, die wesentliche funktionale
Anforderungen eines Grids bereitstellen. Dazu zählt beispielsweise: Authentifizierung,
Autorisierung, Ressourcenermittlung und Ressourcenzugriff (Vgl. Abschnitt 2.2, S. 8). Des
Weiteren bietet ein Grid eine nicht-triviale Qualität seiner Dienste in Hinsicht auf: kurze
Antwortzeiten, hohen Datendurchsatz, Sicherheit, Transparenz, Abrechenbarkeit, Nachvoll-
ziehbarkeit und stetige Erreichbarkeit. Die Ressourcen eines Grids lassen sich durch den An-
wender in Zukunft ebenso einfach und ähnlich nutzen wie elektrischer Strom, das Telefonnetz,
oder heutzutage das Internet. Ressourcen eines Grids sind beispielsweise: Rechenleistung,
Speicherplatz, oder auch wissenschaftliche Gerätschaften wie Teleskope, Rasterelektronenmi-
kroskopen, et cetera. Die allgemeine Vision ist es alle Computer der Welt zu einem einzigen
großen Supercomputer in einem Grid zu vernetzen.9
2.3.2 Kritikpunkte
Kritik kann an der Funktionsfähigkeit der politischen und sozialen Struktur des Grids,
organisiert in „Virtuellen Organisationen“ gegeben werden. Eine virtuelle Organisation ist
eine künstlich geschaffene Interessengruppe von Individuen. Zwischen diesen Individuen
bestehen möglicherweise Interessenkonflikte oder sie befinden sich im Wettbewerb
zueinander. Dieses Konflikt- und Wettbewerbspotential ist bereits in real existierenden Organi-
sationen allgegenwärtig und es gibt kein Grund zur Annahme, dass dies nicht auch für virtuelle
Organisationen gilt.10
Eine weiterer Befürchtung liegt darin, dass Grid – wie viele vielversprechende innovative
Technologien zuvor – sich auf Grund der menschlichen Handlungskomponente zu der unter
anderem auch Fehler gehören, sich nicht durchsetzen wird. Dies können Fehler sein, die
bei der Umsetzung der Grid-Vision zu einem real existierenden Grid, begangen wer-
den. Als Beispiel kann man an dieser Stelle den „OSI Standard for Internet Communica-
tion“ aufführen. Dieser Standard wurde lange sehr genau und sorgfältig entwickelt und ist
prinzipiell TCP/IP überlegen. Bevor man es schaffte den OSI Standard zu implementieren, war
TCP/IP, trotz seiner Mängel, schon der weit verbreitete Datenübertragungsstandard des Internets.
Als Konsequenz daraus versucht die Grid-Entwicklergemeinde bewusst solche Fehler zu
9 Vgl. URL: http://www.gridcafe.org/version1/whatisgrid/dream.html [15.02.2009]
10 Vgl. URL: http://www.gridcafe.org/version1/grid&you/skeptical.html [15.02.2009]– 11 –
vermeiden. Allerdings können natürlich neue, bisher nicht begangene Fehler mit ähnlichen
Konsequenzen, bei der Entwicklung des Grids einhergehen.10
2.4 Grid Klassifikation
Grids werden im allgemeinen nach Verwendungszweck oder Teilsystemen
klassifiziert. Eine Klassifizierung der Teilsysteme eines Grids, nach der in 2.3.1 gegebenen
Definition eines Grids, wird an dieser Stelle vorgestellt:
• Computational Grid: ist für die verteilte Bereitsstellung von Rechenkapazität, die sonst
dem Anwender in diesem Maße nicht zur Verfügung stünde, zuständig. Dies kann durch
die Nutzung brachliegender Ressourcen einer virtuellen Organisation geschehen. 11
• Data Grid: verteilte Speicherung und Indizierung von großen Datenmengen. Beispiel: Bei
der Nutzung des LHC12 des CERN fallen Petabytes an Daten in sehr kurzer Zeit an. Diese
Daten müssen zur Speicherung und Weiterverarbeitung verteilt werden, da ein einzelnes
Rechenzentrum nicht in der Lage wäre diese große Menge an Daten zu speichern.
• Application Grid: dient der Bereitsstellung von Services zum Betreiben Domänen–
übergreifender virtueller Organisationen. Im Application Grid müssen die Themen
Autorisierung, Abrechnung, Authentifizierung und Benutzerkontenmanagement
behandelt sein. Von einem Nutzer einer virtuellen Organisation in Anspruch genomme-
ne Leistungen, müssen dokumentiert und nachvollziehbar abgespeichert werden. Dazu
gehört im wissenschaftlichen Betrieb, wer, wo, wann, welche Ressourcen wie und für
was benutzt hat. Dies geschieht um aus dem Grid heraus erlangte wissenschaftliche
Erkenntnis eindeutig nachvollziehbar und somit validierbar zu machen.11
„Ziel ist die organisationsübergreifende gemeinsame Nutzung von Ressourcen und damit
die verbesserte Auslastung für den Betreiber sowie ein breiteres Angebot für den Nut-
zer“11.
11 Vgl. Barth, Grid Computing S. 22, 2006
12 LHC= Large Hadron Collider,
Vgl. URL: http://de.wikipedia.org/wiki/LHC [15.02.2009]– 12 –
• Resource Grid: stellt den Zugriff auf Grid Ressourcen zur Verfügung. Es koordiniert in
erster Linie den Zugriff auf das Data und Compute Grid. Außerdem sorgt das Resource
Grid für eine klare Rollenverteilung zwischen Grid-Ressourcenanbieter, Grid-Zugangsan-
bieter und den Grid-Nutzern. Dies hat zum Vorteil, dass zwischen den Grid-Zugangsan-
bietern und dem Grid-Ressourcenanbieter offene Schnittstellen existieren müssen, welche
sinnigerweise standardisiert werden sollten. Für den Endanwender selbst wird sich die
Form des Zugriffs auf ein Resource Grid nicht von der des Zugriffes auf ein Application
Grid unterscheiden. 11
• Service Grid: stellt Grid-Funktionalität im Sinne von Grid-Algoritmen als „Utility“ be-
reit. Jeder Grid-Ressourcenanbieter kann ein anderes „Utility“ auf seinen Ressourcen
bereit stellen. Da sich Grid-Ressourcen kombinieren lassen, kann man die auf ihnen
angebotenen „Utility“ in einen Workflow zusammenführen, so dass ein neuer Dienst entsteht:
„Ein Workflow aus den unterschiedlichsten Dingen soll aufge-
baut werden können [...], so dass ein neuer Dienst entsteht“13
Ein Grid-Service-Anbieter kümmert sich um die Auswahl der Ressourcen und Utilitys,
die auf diesen Ressourcen ausgeführt werden. Daher wählt der Grid-Service-Anbieter die
Ressourcen-Anbieter aus und rechnet gegenüber ihnen erbrachte Leistungen, genauso wie
gegenüber denjenigen, die diese Leistungen in Anspruch nehmen ab. Der Grid-Service-
Anbieter ist somit für den gesamten Nutzer-Service verantwortlich.11
2.4.1 Kritikpunkte an der Aufteilung
eines Grid
Probleme an obiger Aufteilung eines Grids wird in mehreren Aspekten gesehen. Ein As-
pekt ist, dass es derzeit kein Softwarelizenzmodell gibt, welches eine nutzungsabhängige
Abrechnung von Software erlaubt. Um Grid-Systeme zur Nutzung kommerzieller Software
zu verwenden, müssen neue Lizenzmodelle entworfen werden, die eine nutzungsabhängige
13 Vgl. Dipl.-Inf. Joachim Götze, FH Kaiserslautern – Vorlesung „Grid Computing“,
Folie „A Grid Classification“, 2007,
URL: http://www.icsy.de/~j_goetze/Grid_VL_html/t001/g007/index.htm?nav= ,
13.01.2009 ,[15.02.2009]– 13 –
Abrechnung von Software erlauben. Des Weiteren kommt der Aspekt der Sicherheit hinzu.
Firmen müssen, wenn sie das Konzept des Service-Grids in Anspruch nehmen wollen, auf
die Sicherheit ihrer Daten und auf Authentifizierungs- sowie Autorisierungsverfahren ver-
trauen können. Hierbei ist fraglich, ob Firmen die damit verbundenen Risiken eingehen wollen,
Denn das Grid System entzieht sich der Kontrolle einer zentralen Instanz und somit auch der
Kontrolle der Firmen. Demgegenüber stehen natürlich Kosteneinsparungen, in Form von Mit-
arbeitern (Humankapital) die über ein hohes IT-Know-How verfügen müssen sowie wieder-
kehrende Kosten für IT-Infrastruktur und die Organisation dieser. Es wird nach geeigneten
Mechanismen gefragt, welche das Risiko der Grid-Nutzung kalkulierbar und den Gesamt-
prozess effizient machen. Diese Mechanismen existieren bis heute nur auf experimenteller
Basis.
Grid
is a
is a
uses
Resource Grid Service Grid
is
a
is a
Compute Grid Data Grid
Abbildung 2. Grid Klassifkation 13 nach Götze ohne Integration von Application Grid nach Barth11
Application Grid is a
Grid
use
s is a
is a uses
Resource Grid Service Grid
is
a
is a
Compute Grid Data Grid
Abbildung 1. Grid Klassifkation 13 mit Integration des Application Grid nach Barth11. So könnte nach
Auffassung des Autors dieser Bacherlorarbeit eine Integration aller Grid-Klassen in einem
weltweit umspannenden Grids aussehen. .– 14 –
2.5 Grid-Architektur
Um ein funktionierendes Grid-System zu betreiben ist mehr nötig als eine reine
Aggregation der Rechenleistung und der Vernetzung einzelner Computer. Dies ergäbe kein
System mit Grid-Architektur, sondern wäre das Äquivalent der Architektur eines Cluster-
systemes. In einem Gridsystem werden, abstrakt gesprochen, alle Ressourcen über eine
Grid-Software miteinander verbunden. Auf jeder Ressource laufen Monitoring-Dienste,
welche die Ressource überwachen und den aktuellen Status der Ressource an einen Ressource-
Broker14 mitteilen. Ein solcher Ressource-Broker speichert von jeder im System verfügbaren
Ressource den Status in einer Art „Katalog“, hält diesen permanent aktuell und leitet ressour-
cenbeanspruchende Aufträge an die dementsprechenden, frei verfügbaren Ressourcen weiter.15
Das auf Seite 11 eingeführte Application Grid sorgt dafür, dass diese ressourcenbeanspru-
chenden Aufträge nur von authentifizierten und autorisierten Benutzern erteilt, verändert
und die Ergebnisse, welche die Ressourcen nach einer Ressourcenbeanspruchung liefern,
nur von diesen authentifizierten und autorisierten Benutzern eingesehen und nachvollzogen
werden können. Zudem kümmert sich das Application Grid um den Aspekt der Abrechnung
der Ressourcennutzung. Dies kann in einem Geldsystem einer beliebigen, auch virtuellen,
Währung geschehen. Darüber hinaus stellt das Application Grid Methoden und Werkzeu-
ge zur dynamischen Verwaltung virtueller Organisationen zur Verfügung. Dynamisch heißt
hierbei, dass sich die virtuellen Organisationen zu jedem Zeitpunkt ändern können. Än-
dern in Bezug auf ihre Mitgliederzahl, auf diejenigen Ressourcen, welche ihre Mitglieder
beanspruchen und teilen können sowie beanspruchen und teilen dürfen sowie die Ressourcen die
geteilt und bereitgestellt werden. Ändern auch in Bezug auf die Hierarchie in der eine virtuelle
Organisation steht. So können virtuelle Organisationen wiederum aus virtuellen Organisationen
bestehen oder Teil einer virtuellen Organisation sein. Auf diese Weise können hierarchische,
baumartige auf‘s höchste miteinander verzahnte, sehr komplizierte Strukturen von virtuellen
Organisationen entstehen.
14 Vgl. Ressourcenmanagement Grid, Forschungszentrum Karlsruhe,
URL: http://www.iai.fzk.de/www-extern/index.php?id=282, [19.01.2009]
15 Vgl. Dr. Klaus Manhart, 2006, Grid-Technologie: Grundlagen, Dienste, Tools;
URL: http://www.tecchannel.de/webtechnik/soa/435980/grid_technologie_teil_1_
grundlagen_dienste_und_tools/index7.html, [15.01.2009]– 15 –
Abbildung 3. Grid Architektur nach Foster 16
Abbildung 4. Grid Layermodell nach Foster17
16 Ian Foster, Carl Kesselman The Grid: Blueprint for a new computing infrastructure,
2004, S. 48, Figure 4.3
17 Vgl, Ian Foster, Carl Kesselmann, Steven Tuecke, The Anatomy of a Grid, 2001, S.7– 16 –
Die auf der vorhergehenden Seite dargestellten, Abbildungen, geben die Architektur
eines heute üblichen Gridsystems nach Foster 16 und 17
wieder. Abbildung drei ist ähnlich zu
Abbildung vier. Der Unterschied zwischen den Abbildungen liegt darin, dass Abbildung drei ein
granulareres Grid-Protokollmodell darstellt und Abbildung vier das Grid in mehrere
Schichten, zu denen natürlich auch die Protokolle aus Abbildung drei gehören, unterteilt.
Abbildung drei stellt das Grid-Protokollmodell in Relation zum Internet-Protokollmodell dar.
Abbildung vier zeigt dem Betrachter eine „Stundenglas-Ansicht“ auf die Gridarchitektur in
Schichten. Diese Schichten bauen in Abbildung vier von unten nach oben aufeinander auf,
wobei jede höhere Schicht auf den Fähigkeiten und dem Verhalten der darunter liegenden
Schicht basiert. Das Stundenglasmodell in Abbildung vier besitzt eine optisch-symbolische
Verengung in der Mitte. Diese Verengung stellt die minimale Basis dar, auf deren Grundla-
ge man ein breitgefächertes Applikations- und Dienstespektrum – im Modell nach oben
hin – anbieten, aber auch eine sehr große Menge an – im Modell nach unten hin – Ressour-
cen anbinden kann.18 Die Verengung soll vermutlich auch vermitteln, dass der Zugriff von
den oberen Schichten auf die unteren Schichten nicht durchgängig ist, sondern über die
definierten „Resource and connectivity“ Protokolle erfolgen muss. Durch die Aufteilung
des Grids in Schichten können Standardisierungsverfahren für Schnittstellen vorausge-
plant werden. Darüber hinaus beschreibt eine solche Darstellung welche Teile des Grids auf
welchen basieren und proklamiert indirekt eine nachhaltig komponentenbasierte Entwicklung.
Das Modell in Abbildung 4 ist in vier Schichten aufgeteilt:
• Fabric Layer: Sie ist die Basis eines Grids und regelt den Zugriff auf eine lokale Ressource
durch diverse Grid-Zugriffsprotokolle. Die Fabric Implementierungen müssen jeweils den
lokalen ressourcenspezifischen Anforderungen entsprechen und werden für jeden Ressour-
centypus speziell angefertigt. Abstrakt gesprochen wird durch die Fabric-Implementie-
rung auf einer Ressource der Zugriff von außen, also der darüber liegenden Grid-Schicht,
standardisiert, indem innerhalb der Fabric Implementierung auf die Eigenarten und Ty-
pus der Ressource eingegangen wird. Nach außen hin hält eine Ressource eine Schnitt-
stelle auf die mit Hilfe von Grid-Protokollen standardisiert zugegriffen werden kann bereit.
„Dadurch entsteht eine enge und subtile Abhängigkeit zwischen denen in der Fabrik Schicht
definierten Funktionen auf der einen und den Freigabeoperationen auf der anderen Seite“18
18 Vgl. Detlef Schroder, Kai Fischbach, Rene Teichman, Peer-to-Peer, 2002, S. 129– 17 –
Was Detlef Schroder & Co. in ihrem Buch „Peer-to-Peer“ hiermit sagen wollen ist, dass ein Grid
nach oben hin gesehen in der Grid-Architektur (siehe Abbildung 4, S. 15) nur soviel Ressour-
centeilungsfunktionalität bereit gestellt werden kann, wie in der Fabric Layer definiert wurde.
Wird viel definiert steigt der Aufwand bei der Umsetzung der Grid-Infrastruktur, wird
wenig definiert, „ ... then deployment of Grid infrastructure is simplified.“19, so ist die
Umsetzung der Grid-Infrastruktur einfacher. Die Anforderungen an die Fabric-Implemen-
tierung einer Ressource ergibt sich laut Foster auch aus dem Typus dem sie angehört.
Die wichtigsten Ressourcentypen zwischen denen unterschieden wird, sind:
¥¥ Betriebsmittel die Rechenkapazität zur Verfügung stellen und
¥¥ Datenspeicherressourcen und Netzwerkressourcen.
Der jeweilige Ressourcentyp sollte zumindest via Fabric-Implementierung in der Lage
sein sich selbst über seinen Zustand, seine Struktur und seine Fähigkeiten abzufragen
(Stichwort: „Introspektion“). Darüber hinaus sollte er die Fähigkeit inne haben Auskunft
an andere Gridschichten geben zu können, so dass zum Beispiel innerhalb des „Ressour-
ce Grid“ (siehe oben, Seite 14ff) Ressourcenmanagementmechanismen optimal einge-
setzt werden können. Durch dieses Vorgehen soll eine „Quality of Service“ Steuerung
ermöglicht werden, welche, siehe „Three Point Checklist“ (Vgl. S.8f), als notwendige
Grundlage eines Grids definiert wird. Introspektive Abfragen zielen zum Beispiel auf
folgende Dinge ab:
¥¥ Aktuelle Arbeitsbelastung der Ressource,
¥¥ aktueller Stand der Warteschlange der Ressource, wieviele Anfragen mit welcher
Priorität, werden vor „meiner“ Anfrage noch bearbeitet und wie lange wird dies
ungefähr dauern?,
¥¥ zur Verfügung stehende Bandbreite der Netzwerkressource und andere Netzwerk-
charakteristiken,
¥¥ et cetera.
19 Vgl. Ian Foster and Carl Kesselman, The Grid: Blueprint for a new computing
infrastructure, 2004, S. 47ff– 18 –
• Resource and connectivity protocols: Diese Schicht definiert grundlegende Konnekti-
vitätsprotokolle zu denen Authentifizierungs- und Kommunikationsprotokolle, die für
gridspezifische Netzwerktransaktionen zwischen Fabric Layer Ressourcen benötigt
werden, gehören.19 Fundamentale Internetprotokolle, wie TCP/IP, UDP, HTTP, DNS,
et cetera sind Teil dieser Schicht (Vgl. Abbildung 3, S. 15). Hinzu kommt, dass Grid-
Systeme Sicherheit gewährleisten müssen. Daher enthält diese Schicht Protokolle wel-
che den Sicherheitsaspekt (GSI = Grid Security Infrastructure) abdecken.20 Zu den
Konnektivitätsprotokollen dieser Schicht kommen Ressourcenprotokolle hinzu, die auf
Basis der Konnektivitätsprotokolle arbeiten und die es ermöglichen Ressourcen individu-
ell zu kontrollieren. Ressourcenprotokolle unterteilen sich nochmals in zwei Hauptkatego-
rien. Das sind:
¥¥ Informationsprotokolle und
¥¥ Kontrollprotokolle.
Erstere erlauben den Zugriff auf Ergebnisse von introspektiven Abfragen der Grid-
ressource (siehe oben, Fabric Layer), letztere ermöglichen es, bis zu einem gewissen
Grade, die Ressource zu kontrollieren, zu überwachen, zu reservieren und zu nutzen. Die
Protokolle dieser Schicht konzentrieren sich auf Interaktionen innerhalb einer einzelnen
Ressource. Zu den Ressourcenprotokollen gehören:
¥¥ Grid Resource Allocation Management – kurz GRAM –,
¥¥ GridFTP,
¥¥ Grid Resource Information Management – das Zugriff auf Struktur- und Statusin-
formationen einer Ressource geben kann –,
¥¥ et cetera.
Die Schicht Resource and connectivity protocols dient zur Interkation mit der Fabric
Layer einer einzelnen Ressource und nicht zur globalen Kommunikation und Interaktion
zwischen Ressourcen selbst.
20 Vgl. Sotomayor und Childers, Globus Toolkit 4, 2006, S. 8f– 19 –
Collective services:
„While the Resource layer is focused on interactions with a single resource, the next
layer in the architecture contains protocols and services (and APIs and SDKs) that are
not associated with any one specific resource but rather are global in nature and cap-
ture interactions across collections of resources. For this reason, we refer to the next
layer of the architecture as the Collective layer. Because Collective components build on
the narrow Resource and Connectivity layer “neck” in the protocol hourglass, they can
implement a wide variety of sharing behaviors without placing new requirements on the
resources being shared.“21
Der Collective Layer ist nicht auf spezielle Ressourcen zugeschnitten, sondern umfasst
die Interaktion über verschiedene Ressourcen. Das heißt der Collective Layer bündelt
die Operationen und Möglichkeiten, um auf mehreren Ressourcen gleichzeitig, oder
nacheinander zugreifen zu können. In der Collective Layer Schicht ist eine breitgefä-
cherte Auswahl an Diensten implementiert. Directory Services: Auffinden von Diensten,
Scheduling, Queue Allokation, Monitoring, Date Replication Service, auch Sicherheit
Accounting, aber hier werden Rechte für virtuelle Organisationen vergeben, Accoun-
ting, Payment, et cetera.
• User applications: Anwendungen die am besten über Grid-SDKs, oder auf Basis der Grid-
Middleware entwickelt und vom Grid-Nutzer ausgeführt können. Beispiele für Grid-SDKs
sind: GPE und GAT.
21 Vgl, Ian Foster, Carl Kesselmann, Steven Tuecke, The Anatomy of a Grid, 2001, S.
11f
URL: http://www.globus.org/alliance/publications/papers/anatomy.pdf [15.02.2009] ,– 20 –
2.6 Grid Middleware
2.6.1 Definition Middleware
„Middleware ist eine Verteilungsinfrastruktur über die verschiedene Anwendungen
auf unterschiedliche Ressourcen zugreifen können. Sie dient dem Aufbau von verteilten
Systemen in denen Programme bzw. Anwendungen die entfernten Ressourcen genauso
nutzen können, wie die lokalen Anwendungen. Es handelt sich um eine Verteilungsplatt-
form, die zwischen den Applikationen und der Betriebsystemebene angesiedelt ist und
zwischen den Anwendungen und dem Betriebssystem, dem Netzwerkbetriebssystem oder
dem Datenbank-Managementsystem vermittelt. Diese kann sich auf die Kommunikation
beziehen, die synchron oder asynchron sein kann, ebenso auf die Protokollierung des Da-
tenflusses, auf die Portierung, die Interaktion zwischen Anwendungskomponenten in he-
terogenen Systemen sowie die Sicherheit in Bezug auf die Zugriffsberechtigungen ebenso
wie auf die Datensicherheit bei Transaktionen.“ 22
2.6.2 Grid-Middleware
Die oben unter Absatz 2.5 vorgestellte Gridarchitektur stellt derzeit lediglich das allgemeine
Ideal des Aufbaus eines Grids dar. Allgemein heißt, dass es zu diesem Thema auch andere An-
sichten gibt, auf die im Rahmen des Bachelorarbeit jedoch nicht weiter eingegangen wird, da
der allgemeine Konsens und die allgemeine wissenschaftliche Gemeinde auf in 2.5. vorgestellte
Architektur setzt.
Eine solche, in die Praxis umgesetzte Grid-Architektur, wird auf Grund ihres Aufbaus und
der damit einhergehenden Unterstützung verteilter heterogener Ressourcen, Grid-Middleware
genannt. Zur Standardisierung der Schnittstellen von Grid-Middleware wurde ein Forum, das
Global Grid Forum, ins Leben gerufen, in welchem wichtige Vertreter der Industrie (von Firmen
wie IBM, Fujitsu, Hewlet Packard, SAP, etc.) und Wissenschaftler – unter anderem auch dem
22 Vgl.: IT-Wissen, Online Lexikon, DATACOM Buchverlag GmbH,
URL: http://www.itwissen.info/definition/lexikon/Middleware-middleware.html
[15.02.2009]– 21 –
Grid-Visionär Ian Foster – zusammen an der Standardisierung der Grid-Schnittstellen arbeiten.
Dabei ist zunächst die OGSI – Open Grid Service Infrastructure – entstanden. Diese wurde
mittlerweile von der OGSA – Open Grid Service Architecture – abgelöst. Derweil gibt es welt-
weit mehrere Versuche die Grid-Architektur als Grid-Middleware zu implementieren. In den
aktuellen Versionen dieser Grid-Middleware wurde die OGSA23 in Konvergenz zu den W3C24
Standards für Webservices implementiert. Was wiederum heißt Grid-Services lassen über ein-
heitliche Zugriffsverfahren, wie normale Webservices, ansprechen. Da Grid-Services im Ge-
gensatz zu normalen Webservices explizit zustandsbehaftet sind, wie zum Beispiel ein simples
Java-Objekt (siehe oben, Service Grid: Introspektion), wurde von der OGSA der Einsatz des
Web Services Resource Framework (kurz: WSRF) vorgeschlagen:
„It is desirable to define Web service conventions to enable the discovery of, int-
rospection on, and interaction with stateful resources in standard and interoperable
ways.“25
Diese bedeutet, dass der Zugriff auf und die Veröffentlichung von Information über den
Zustand einer Ressource über standardisierte Schnittstellen erfolgt. Die wichtigsten Implemen-
tierungen von Grid-Middleware werden an dieser Stelle kurz vorgestellt:
• Unicore ist eine auf Open Source basierende Middleware die überwiegend in europäi-
schen Grid-Projekten eingesetzt wird. Sie bietet in ihrer neuesten Version Unicore 6.x
Standardschnittstellenkonformität und wird permanent weiterentwickelt. Sie verfügt über
grafische Benutzerschnittstellensteuerung, aber auch über reine Kommandozeilensteue-
rung. Für fortgeschrittene Applikationsentwickler bietet Sie zur Zeit noch eine speziel-
le grafische Benutzerschnittstelle an. Diese soll durch ein Eclipse-Plugin, das noch im
Betastadium ist, abgelöst werden. Unicore ist auch Bestandteil der Deutschen Grid-
Initiative D-Grid. Unicore ist als Testumgebung für das Netzwerk zu Hause oder in
kleinen Firmen sogar als vorkonfigurierte Linux-Live-CD vorhanden, so dass der Ein-
stieg in Unicore Einfachheit verspricht. Im Übrigen hat man die Möglichkeit unter:
23 OGSA = Open Grid Service Architecture,
URL: http://en.wikipedia.org/wiki/Open_Grid_Services_Architecture [15.02.2009]
24 W3C = World Wide Web Consortium,
URL: http://de.wikipedia.org/wiki/World_Wide_Web_Consortium [15.02.2009]
25 K. Czajkowski, D. F. Ferguson, I. Foster, The WS-Resource Framework, June 2005,
URL: http://www.globus.org/wsrf/specs/ws-wsrf.pdf [15.02.2009]– 22 –
http://www.unicore.eu/testgrid/ den einfachen Unicore Client mit einem Zertifikat für
30 Tage auf bereitgestellten Testressourcen kostenlos zu testen. Den Einstieg in Unicore
findet man durch – auf der Unicore Webseite in englischer Sprache – vorhandene Doku-
mentationen.
• Globus ist eine Middleware die von der Globus Alliance entwickelt wird. Die Globus Al-
liance setzt sich hauptsächlich aus namhaften amerikanischen Forschungsinstituten (zum
Beispiel dem Argonne National Institute) zusammen und genießt weltweite Verbreitung.
Globus basiert wie Unicore, auf Open Source. Die Globus Alliance ist Mitbegründer und
stärkste Kraft im Global Grid Forum. Daher wird die Globus Middleware als standard-
konformste und richtungweisendste Grid-Middleware-Implementierung gesehen. Zur
Entwicklung von Grid-Applikationen stellt die Globus Alliance das Globus Toolkit 4 zur
Verfügung. Globus und Globus Toolkit gibt es im Rahmen des Instant Grid-Projektes der
deutschen D-Grid Initiative als Live-CD zum Download. Bestandteil ist zum Beispiel
eine fertige Grid-Implementierung des POV-Ray Renderers, der sofort nach dem Booten,
über den mit der CD ausgestatteten Rechner, im Grid betrieben werden kann. Für das
Globus Toolkit 4 gibt es ein Buch „Globus Toolkit 4“ in englischer Sprache, mit wel-
chem man die Entwicklung von Anwendungen im Grid erlernen kann. Dieses Werk ist
sehr zum empfehlen. Es existiert, wenn man nach den Autoren via Google sucht auch
eine offene Vorversion des Buches, welche man kostenlos als PDF laden kann. Diese
offene Vorversion nennt sich: „GlobusToolkit4_ProgrammerTutorial“. In diesem
Dokument wird eine hervorragende Einführung in die grundlegenden Eigenschaften Service
orientierter Architekturen, über Webservices und introspektiven Webservices (also Web-
Service Ressourcen) bis hin zur Programmierung von Web-Service Ressourcen und Anwen-
dungen für Globus via Globus Toolkit 4 gegeben. Natürlich stellt das kostenlose Dokument
lediglich einen sehr rudimentären Einstieg im Vergleich zum ausführlicheren Buch dar.
• gLite: ist eine Grid-Middleware die bei der Verteilung der Petabytes an Daten des LHC
zum Einsatz kommt. gLite ist die verkürzte Schreibweise für „Lightweight Middleware
for Grid Computing“. Sie ist die leistungsfähigste und vollständigste Grid-Middleware
auf dem Markt. gLite unterstützt die Verwendung von Rechenressourcen, Datenressour-
cen, Monitoring, Logging und Accounting (Authentifizierung, Delegation und Autori-
sierung) sowie das Konzept der „Virtuellen Organisation“. Des Weiteren verfügt diese– 23 –
Grid-Middleware über einen implementierten Resource-Broker, welcher dazu in der Lage
ist ressourcenbeanspruchende Aufträge im Grid optimal zu verteilen. Diese Aufträge
werden mittels einer gLite eigenen JDL (Job Description Language) beschrieben. Mittels
der JDL lassen sich wie über ein Shellskript auf dem Betriebsystem installierte Programme
starten. In D-Grid ist gLite die am wenigsten verbreitete Grid-Middleware, wohingegen
Globus mit Globus Toolkit 4 von den meisten Rechenzentren und Unicore 5 am zweit-
häufigsten unterstützt wird. Der Nachteil an gLite kommt dann zum Tragen, wenn Intero-
perabilität zwischen heterogenen Ressourcen gefragt ist. So lässt sich gLite nur unter der
„Scientific Linux Distribution 32 bit“ installieren und betreiben. Eine Portierung auf an-
dere Linuxderivate gestaltet sich äußerst schwierig, ist aber unter erhöhtem Mehraufwand
dennoch möglich. Bisher werden von gLite 64 Bit-Systeme nur in geringem Maße unter-
stützt. Literatur oder Dokumentation zu diesem Grid-Projekt findet man fast ausschließlich
nur auf der Webseite von gLite in englischer Sprache. Der Autor dieser Bachelorarbeit
empfand die Dokumentation bei kurzem Querlesen recht gut verfasst und verständlich
geschrieben.
Auf der nächsten Seite wird lediglich ein Vergleich zwischen Globus mit Globus Toolkit 4
und Unicore 6 geführt, da diese Grid-Middleware am plattformunabhängigsten sind und den
neuen Standard der Webservice-Ressourcen implementiert haben. Unicore 6 ist zur Zeit nur
auf wenigen Testsystemen im D-Grid vorhanden, wird aber in naher Zukunft seinen Vorgänger
Unicore 5 ablösen und ist daher richtungsweisend. Der Vergleich der beiden Grid-Middleware
wird an dieser Stelle durchgeführt, um später eine optimalere Auswahl zwischen diesen bei-
den Grid-Middlewaresystemen, hinsichtlich der Belange einer etwaigen Grid-Integration der
Open Source Renderfarm DrQueue, durchführen zu können. Zunächst wurden Grid spezifische
Merkmale identifiziert. 26 + 27 Im Anschluss wird überprüft ob, wie und als was das Merkmal in
der jeweiligen Grid-Middleware vorhanden ist.
26 Vgl, Ian Foster, Carl Kesselmann, Steven Tuecke, The Anatomy of a Grid, 2001
URL: http://www.globus.org/alliance/publications/papers/anatomy.pdf [15.02.2009]
27 Ian Foster, Carl Kesselman, Nick Tuecke;
The Physiology of the Grid, Global GridForum, 2002 (Version: 6/22/2002.)
URL: http://www.globus.org/alliance/publications/papers/ogsa.pdf [15.02.2009]– 24 –
2.6.3 Tabellarischer Vergleich: Globus versus Unicore
Grid-Middleware-Merkmal Unicore 6 Globus + Globus Toolkit 4
Sicherheit: Verfügt über alle gestellten Si- Globus verfügt über alle gestellten
Authentifizierung, Autorisierung, cherheitsanforderungen (+++)* Sicherheitsanforderungen. (+++)
Verschlüsselung, X.509, Single
Sign On
Scheduling & Ressourcenmana- Scheduler: Es gibt verschiedene Ressourcen Management wird in
gement bereits existierende Scheduler Form von GRAM 2 (Grid Resour-
die integriert werden können. ce Allocation Management) zur
Es gibt einen „MetaScheduling Verfügung gestellt. Allerdings wird
Service“ der speziell für Grids für einen sinnvollen Betrieb in Form
entwickelt wurde und per Plug- eines richtigen Grids, oft der SUN
in in Unicore integriert werden GRID Scheduler installiert um in
kann. Kombination mit GRAM 4, als
vollwertiger Grid Scheduler und
Ressourcenmanager zu fungieren.28
(–) (+)
Kontrolle der Ressourcen Volle Kontrolle über die Res- Kontrolle durch: Monitoring, Res-
sourcen: Jobmanagement, Job source Allocation. (++)
Monitoring, Job Data (++)
Flexibilität Alle im Grid verfügbaren Res- Directory Service, das alle verfügba-
sourcen werde identifiziert und ren Services auflistet. (++)
können aufgelistet werden.
Unterstützung verschiedener Eigene Jobskriptsprache, unter- JAVA, C und Python, stellt entspre-
Programmiersprachen stützt aber auch Shellskripts und chende Bibliotheken zur Verfügung.
Batchprocessing vorhandener (+++)
Anwendungen. (+)
Heterogenität Unterstützung von Standard- Unterstützung von Standardschnitt-
schnittstellen und erweiterten stellen und erweiterten Webservices
Webservices (+++) (+++). wird von jedem D-Grid
Projekt unterstützt und mit GT4
entwickelte Grid-Software ist daher
auch innerhalb der D-Grid-Projekte
interoperabel anwendbar.
Grafische Benutzerschnittstelle Ja. GPE, erweiterte GPE und keine (– )
Ecplise Entwickler-Plugin im
Beta-Stadium verfügbar! (+)
Dokumentation Es gibt kein Buch zu Unicore Es existiert ein hervorragendes
5 oder 6. Es gibt für Unicore 5 Einstiegsbuch in das Globus Toolkit
eine Dokumentation und etliche 4, viele Onlinetutorials und weiteres
Tutorials (sugi) im Internet die sehr ausführliches und ausgereiftes
den Einstieg in die Technologie Dokumentationsmaterial das einen
erleichtern sollen. Für Unicore Einstieg in die Globus Technologie
6 gibt es lediglich eine unvoll- erleichtert. (+++)
ständige Dokumentation. (++)
* Die Wertung mit + und - stellt lediglich eine subjektive Gewichtung des Autors, auf einer
Skala von „-“ bis „+++“ dar. Ersteres bedeutet soviel wie „nicht vorhanden“, letzteres soviel
wie „sehr gut umgesetzt“.
28 Vgl. URL: http://www.unicore.eu/community/development/scheduling.php– 25 –
2.7 Webservice-Resource Framework
Applikationen
OGSA
WSRF
Abbildung 5. Verbindung zwischen Webservices, WSRF, OGSA und Grid-Applikationen
Das Webservice Resource Framework (kurz: WSRF) ist eine vom Global Grid Forum und
vom W3C verabschiedeter offener Standard zur Erweiterung von Webservices. Das Webservice
Resource Framework wurde notwendig, da Grid-Services in jeder existierenden Grid-Midd-
leware über verschiedene, middlewarspezifische Schnittstellen aufgerufen werden mussten.
Dieser Sachverhalt ist wenig förderlich, wenn man Interoperabilität zwischen verschiedenen
Middleware und deren Grid-Services wünscht. Der bereits existierende Standard für Webser-
vices und deren Schnittstellen erschien für ein weltweit operierendes heterogenes Grid aus
folgenden Gründen geeignet:
• Webservices sind plattformunabhängig,
• die Kommunkation von Webservice und Anwendung läuft via http und somit auf dem in
der Regel Firewall-offenen Port 80,
• hinzu kommt, dass der Einsatz der Webservice Technologie zu skalierbaren, weil lose
gekoppelten Systemen führt, was in der heutigen Informatik als eine sehr nachhaltige Soft-
[13.02.2009]– 26 –
warestruktur betrachtet wird. 29
Der Nachteil dieser Technologie ist, dass Webservices, nicht wie zum Beispiel Java Objekte,
zustandsbehaftet sind und einen hohen Overhead bei der Kommunikation, da XML-basiert,
mit sich bringen. Gegen letzteres kann man wenig tun, da man sozusagen Interoperabilität
gegen Effizienz tauscht. Um Webservices zustandsbehaftet zu machen – was von den meisten
Grid-Applikationen benötigt wird – hat man das WSRF eingeführt. Mit Einführung dessen
wird nicht der herkömmliche Standard der Webservices geändert, sondern lediglich ergänzt. So
speichert man den Zustand nicht innerhalb eines Webservices oder in einer Art
Instanz des Webservices ab, sondern in einer sogenannten, den Webservice, ergänzenden Res-
source, auf die man üblicherweise mit Hilfe von WS-Adressing (Webservice-Adressierung)
zugreift. WS-Adressing ist ein XML-Konstrukt welches aus einer sogenannten ERP (End Point
Reference) besteht und sich nochmals in eine herkömmliche URI und eine Ressourcen-ID,
welche zur eindeutigen Speicherung der Zustände benötigt wird, aufschlüsselt. Die Zustän-
de werden in eine über die Ressourcen-ID adressierbare Ressourcen-Entität gespeichert. Die
Ressourcen-Entität kann nicht nur die Daten des Zustand eines Webservices halten, sondern da-
zugehörige Metadaten (Datum des letzten Zugriffs, Datum der letzten Änderung, et cetera). Zu
den Metadaten gehören auch Daten welche benötigt werden um die Ressourcen-Entität selbst
zu beschreiben (Lebensdauer, Besitzer, et cetera).
Die in Abbildung 5, Seite 25, dargestellte Grafik verdeutlicht den Zusammenhang des
WSRF in der Architektur eines Grids. So wird eine Applikation, zumindest wenn man High
Level Utilitys (GAT, GPE) zur Programmierung einsetzt, nie direkt auf einen Webservice zu-
greifen, sondern hierfür die OGSA benutzen, die einen passenden Webservice, inklusive EPR
bereitstellt.
29 Vgl. Sotomayor Borja, Childer Lisa, Globus Toolkit 4, 2006, S. 20– 27 –
3. D-Grid
Abbildung 6. Aufbau und Organisation der D-Grid Initiative 30
Dieser Abschnitt gibt eine Einführung in die Deutsche D-Grid Intiative und erläutert die
technologischen, sowie organisatorischen Gegebenheit von D-Grid. Eine Erörterung der
Konsequenzen dieser Erläuterungen in Hinsicht auf eine mögliche Portierung der Renderfarm
DrQueue wird formuliert.
3.1 Was ist D-GRID?
D-Grid ist eine vom deutschen Bundesministerium für Bildung und Forschung geförderte
Grid Initiative. Diese Grid-Initiative hat den nachhaltigen, planvollen und strukturierten Aufbau
einer Grid-Infrastruktur in Deutschland zum universellen und nicht nur rein wissenschaftlichen,
Nutzen zum Ziel. Dabei unterteilt sich die D-Grid Förderung in mehrere sich überlappende
Phasen: 30
• 2005-2008 D-Grid 1: Entwicklung von Grid-Software für Wissenschaftler
30 Vgl. Neuroth, Kerzel, Wolfgang Gentzsch (Hg.), Die D-Grid Initiative,
September 2007, S. 7ff,
URL: http://webdoc.sub.gwdg.de/univerlag/2007/D-Grid_de.pdf [15.02.2009]Sie können auch lesen
