GRID-Computing ist eine neue Methode, um Daten und Rechenleistung dezentral zu verteilen. Zunächst eigentlich als Hilfsmittel für Teilchenphysiker und Forscher erdacht, sehen mittlerweile auch IBM & Co. in GRID ein enormes Potenzial.

Um den Teilchenphysikern des Europäischen Kernforschungszentrum CERN ein Mittel zum effizienten Informationsaustausch in die Hand zu geben, wurde Anfang der 90er Jahre an eben diesem CERN in Genf das World Wide Web aus der Taufe gehoben[1]. Eine große Zahl an den Experimenten beteiligter Physiker musste eng zusammenarbeiten, wobei die Partner üblicherweise über die gesamte Erdkugel verteilt waren. An den verschiedenen Teilchen- und Kernphysik-Experimenten des CERN sind insgesamt mehr als 10000 Physiker aus zurzeit 20 Mitgliedsstaaten sowie vielen anderen Ländern beteiligt.

Neben anderen Instituten steht jetzt das CERN wieder im Zentrum einer Entwicklung, die in gewisser Weise die Fortsetzung des WWW ist, jedoch ist nicht mehr der reine Austausch von Informa-tionen die zentrale Aufgabe, sondern die Verarbeitung großer Datenmengen.

Die meisten Experimente der Teilchenphysiker erzeugen gewöhnlich eine gewaltige Menge an Daten, daher ist es nicht verwunderlich, dass die Rechen- und Speicherkapazitäten dieser Großforschungseinrichtung bereits in absehbarer Zeit zur Bewältigung des stetig wachsenden Da- tenaufkommens nicht mehr ausreichen.

Spätestens mit der für 2006 geplanten Inbetriebnahme der vier großen Experimente des Speicherrings im Large Hadron Collider (LHC) wird diese Situation eintreten. Die Kollision hoch energetischer Protonen wird dann innerhalb kurzer Zeit zu einem Datenaufkommen im Petabyte-Bereich (Millionen Gigabyte) führen. Das ist eine Größenordnung, bei der die Daten unmöglich lokal an einem Ort verarbeitet und gespeichert werden können.

Gut verteilte Petabytes

Ein möglicher Ausweg aus dem Dilemma besteht darin, die freien Kapazitäten anderer beteiligter Forschungsinstitute nutzbar zu machen. Dieser an sich einleuchtende Ansatz wirft jedoch eine Reihe neuer Fragen auf, die zu einer regen Forschungstätigkeit über die Grenzen der Teilchenphysik hinaus geführt haben. In Erweiterung des ursprünglichen Gedankens geht die Zielvorstellung der Forscher dieses Themenbereichs heute eher in Richtung eines Konzepts “Rechenzeit aus der Daten-Steckdose”. In Anlehnung an das Stromnetz (Power Grid) spricht man deshalb heute in diesem Zusammenhang auch vom Computing Grid oder einfach GRID.

Rechenleistung aus der Steckdose

Die damit verbundene Vorstellung bedeutet eine Demokratisierung von Computerressourcen. Eine weltweite, funktionierende GRID-Infrastruktur würde ohne Ansehen der Person jedem einen transparenten Zugang auch zu den Riesen unter den Höchstleistungsrechnern geben – allerdings nicht notwendigerweise ohne Kosten.

Wie schon beim World Wide Web gehen viele der Impulse in diesem neuen Forschungsbereich vom CERN aus. Das ist nicht verwunderlich, da GRID unter anderem der Bereitstellung hinreichender, weltweit verteilter Mengen an Speicher- und Rechenkapazität dienen soll. Nicht nur aufgrund der Analogie im Namen kann man das GRID-Computing deshalb als logische Fortsetzung des World Wide Web betrachten.

Ein weiterer wichtiger Aspekt des GRID ist die Zusammenführung verteilter Informationen. Etwa im Falle der Entschlüsselung des Genoms arbeiten unterschiedliche Forschergruppen unabhängig voneinander an verschiedenen Gattungen. Meist sind ihre Datenbanken offen einsehbar, jedoch ist das lokale Vorhalten aller verfügbaren Informationen besonders wegen der schnellen Updatezyklen ziemlich schwierig. Die Lösung des Problems besteht darin, eine verteilte Datenbank mit parallelen Suchalgorithmen oder Software-Agenten zu verwenden.

Was ist GRID-Computing – und was nicht?

Neben diesen derzeit meist noch im akademischen Bereich angesiedelten Initiativen finden in der kommerziellen Welt und im Linux-Bereich viele Aktivitäten statt, die zu demselben Themenbereich gehören wie das GRID-Computing. Hierzu zählen Microsofts .NET-Initiative sowie Dot-GNU[2] von der Free Software Foundation oder Ximians Mono-Initiative[3]. Auch Suns Open Net Environment, kurz Sun ONE, sowie Novells One Net versuchen Standards in diesem Bereich zu setzen.

Ganz neu ist die Idee des weltweit verteilten Rechnens nicht. Die verteilte Auswertung radioastronomischer Signale mit Seti@home und verwandte Applikationen, beispielsweise zum Brechen starker Verschlüsselungen, waren Vorreiter dieser Bewegung.

Die Frage, was man heute als GRID-Computing bezeichnen möchte und was nicht, hat gegenwärtig eher rein akademischen Wert und auch die zurzeit verfügbaren Veröffentlichungen in verschiedenen Zeitschriften widersprechen sich zum Teil in ihren Beschreibungen. Das Gebiet ist wohl noch zu dynamisch, um eine eindeutige abschließende Definition liefern zu können. Jedoch kann man die verschiedenen Strömungen der Forschung kategorisieren und einordnen. Prinzipiell gibt es hier zwei unterschiedliche Ausrichtungen, und zwar für datenzentrierte sowie für rechenzeitzentrierte Probleme. Im ersten Falle spricht man von Data GRID, im zweiten Fall von Computational GRID.

Abbildung 1: Seti@home mit seiner verteilten Suche nach Außerirdischen ist einer der Vorläufer der GRID-Projekte.

Probleme des verteilten Rechnens

Man kann parallele Applikationen grob anhand ihres Maßes an Interaktion kategorisieren, die zwischen den einzelnen Rechenknoten stattfindet. In einem traditionellen Multiprozessorsystem greifen die parallelen Applikationen oft direkt auf dieselben Speicherbereiche zu, was beinahe ohne Geschwindigkeitseinbußen möglich ist.

Will man aber eine Berechnung in einem Computational GRID aus mehreren durch ein Netzwerk gekoppelten Rechnern ausführen, spielt die Geschwindigkeit dieser Netzwerkverbindung eine dominierende Rolle. Je weniger Daten die auf verschiedenen Knoten laufenden Programmteile miteinander austauschen müssen, desto besser skaliert die Ablaufgeschwindigkeit eines Programms mit der Zahl der beteiligten Rechner.

Neben der reinen Bandbreite eines Netzwerks spielt dabei besonders die Frage eine Rolle, wie lange jedes Bit von der Quelle bis zum Empfänger unterwegs ist (Latency). Wenn ein Rechenknoten keinen konstanten Strom an Daten erhält, sondern immer wieder auf die Antwort eines an einer entlegenen Stelle des Wide Area Networks liegenden Rechenknotens warten muss, wird das die Geschwindigkeit einer verteilten Berechnung stark beeinflussen.

Abbildung 2: Bei Experimenten mit dem Large Hadron Collider (LHC) des Kernforschungszentrums CERN entstehen Datenmengen, die einzelne Superrechner nicht mehr bewältigen können.

Physikalische Grenzen des Informationsflusses

Einige Millisekunden Verzögerung über ein Wide Area Network sind im Vergleich zu den im Nanosekundenbereich liegenden Zugriffszeiten auf lokalem Speicher eine halbe Ewigkeit. Für aufwändige Computersimulationen etwa kann eine ungeschickt entworfene Anwendung leicht Tage oder Wochen länger rechnen als nötig wäre.

Zwar lässt sich die Bandbreite einer Netzwerkverbindung mit technischen Mitteln leicht skalieren und das Problem sich so entschärfen, im Falle der Latency gibt es aber physikalische Grenzen. Das wirkt sich auch auf die Art von Anwendungen aus, die vom GRID profitieren können. Zum Beispiel wäre wohl kaum ein Computerspiel denkbar, bei dem das Rendering der Szenen auf einem Zentralrechner des Spielherstellers stattfindet, während ein Rechner an einem anderen Ort die Kommunikation zwischen den Spielteilnehmern regelt.

Die Teilchenphysik hat es hier verhältnismäßig leicht, da die Analyse einer Vielzahl von Zerfällen von vornherein ein gut parallelisierbares Problem ist. Im einfachsten Fall wird man zehn identische Programme jeweils ein Zehntel des Datensatzes auf verschiedenen Rechnern in einem Data GRID abarbeiten lassen und die Ergebnisse jedes einzelnen Programms nach Abschluss der Berechnung zusammenfügen. Während der eigentlichen Rechenarbeit findet hierbei keinerlei Informationsaustausch zwischen den einzelnen Rechenknoten statt: Die Geschwindigkeit der Berechnung skaliert fast linear mit der Anzahl beteiligter Computer.

Bereits in diesem einfachen Fall lassen sich einige Randbedingungen für die benötigte Infrastruktur definieren: Zwar tauschen die einzelnen Knoten während der Berechnung keine Daten aus, jedoch muss der transparente Zugriff auf das einem Programmteil zugeordnete Datenfragment gewährleistet sein. Sind diese Daten nicht bereits lokal vorhanden, bedeutet das meist, dass sie zum Ausführungsort kopiert werden müssen.

In der Teilchenphysik können einzelne Datensätze durchaus mehrere hundert GByte groß sein. Zum Vergleich: Mit einem einfachen Modem würde der Transfer von 100 GByte von einem Server zum Client bereits mehrere Wochen benötigen – vorausgesetzt die Verbindung bricht zwischendurch nicht ab. Es werden also Netzwerke mit einer enormen Bandbreite benötigt.

Abbildung 3: Typische Spuren von Teilchen-Kollisionen, wie sie im LHC entstehen.

Ohne schnelle Netze geht nichts

Viele Großforschungseinrichtungen bauen derzeit Hochgeschwindigkeitsverbindungen mit Kapazitäten im 10-Gigabit-Bereich auf. In den Labors der Hersteller von Netzwerkhardware steht schon die Terabit-Technologie auf dem Prüfstand. Die Hochgeschwindigkeitsnetze kann man als Skelett des GRID-Computings bezeichnen.

Auch auf den kommerziellen Bereich wird die Netzwerkentwicklung entscheidende Auswirkungen haben. Der GRID-Teilnehmer möchte eigentlich nicht wissen, wo sein Programm physisch wirklich abläuft. Von Interesse ist eher, dass die Ergebnisse im Hinblick auf die Rechengenauigkeit reproduzierbar sind, unabhängig vom eigentlichen Ausführungsort. Ferner ist wichtig, dass das Programm diese Ergebnisse in möglichst kurzer Zeit zurückliefert.

Nach dem Abschicken des Programms ist deshalb eine Reihe administrativer Schritte erforderlich. Zunächst müssen geeignete Zielrechner zur Ausführung des Programms bereitstehen und ausgewählt werden. Dazu sind sowohl Parameter des auszuführenden Programms (Speicherbedarf, benötigte Rechenzeit) als auch des Zielrechners (Prozessortyp, Betriebssystem, vorhandene Bibliotheken oder Compiler) festzulegen.

Abbildungen 4 und 5: Neben der Teilchenpyhsik ist die Modellierung von Biomolekülen und Pharmaka eine zukunftsträchtige Anwendung des GRID-Computings. Links Hämoglobin, rechts Viagra.

Der Teufel liegt im Detail

Insbesondere mit Blick auf die Rechengenauigkeit ist die Notwendigkeit zur genauest möglichen Festlegung der Randbedingungen der Programmausführung wichtig. So sind selbst zwischen Prozessoren derselben Bauart geringfügige Unterschiede in der Rechengenauigkeit zwischen verschiedenen Prozessorsteppings feststellbar, von Unterschieden bei Verwendung abweichender Bibliotheken (etwa der Libm) ganz zu schweigen. Danach müssen Authentifizierung und Autorisierung erfolgen, um das unbefugte Benutzen von Rechenressourcen zu verhindern. Anwendungen wie Videostreaming, die konstanten Datenstrom voraussetzen, brauchen zudem eine garantierte Qualität der Netzwerkverbindung (QoS, Quality of Service).

Abbildungen 6 und 7: Die Pioniere des GRID-Computings Ian Foster und Carl Kesselman.

Viel Verwaltung unvermeidbar

Es folgt das Kopieren des eigentlichen Programms sowie möglicherweise benötigter Daten. Während und nach der Programmausführung ist der Austausch von Status-Informationen (etwa Ausgaben und Fehlermeldungen) und Programmergebnissen notwendig. Zu guter Letzt möchte man dem Benutzer die verwendete Rechenzeit eventuell in Rechnung stellen, und zwar über Länder- und Währungsgrenzen hinweg.

Schon um ein einfaches “Hello World”-Programm im GRID laufen zu lassen, muss folglich ein großer administrativer Apparat in Bewegung gesetzt werden. Der Benutzer des GRID will – und soll – davon aber möglichst wenig merken. Kurz gesagt ist also ein standardisiertes Protokoll notwendig, das die Interaktion zwischen den einzelnen Benutzern und Knoten des GRID regelt. Dieses Protokoll, eine leistungsfähige Netzwerkinfrastruktur und die Möglichkeit, verteilten Applikationen transparent Daten zur Verfügung zu stellen, sind die Stützpfeiler des GRID-Computings.

Die heute wohl wichtigste Komponente des GRID-Computings im Bereich der Teilchenphysik ist das Globus-Toolkit[4] der Argonne National Laboratories. Es handelt sich dabei um eine so genannte Middleware, also eine Vermittler-Software zwischen den physischen Knoten des GRID, den verteilten Applikationen und dem Benutzer. Die Entwicklung dieses Toolkits begann bereits 1996. Globus bildet einen Layer zwischen GRID-Anwendung und Betriebssystem und sorgt so für die reibungslose Kommunikation zwischen den teilnehmenden verteilten Programmteilen. Globus stellt damit Lösungen für die meisten der angesprochenen Probleme bereit.

Globus vermittelt

So behandelt etwa die Grid Security Infrastructure (GSI) genannte Globus-Komponente die Authentifizierung und Autorisierung von Benutzern. Zusätzlich zu dieser Protokollfunktion gibt es weitere Funktionen, etwa für den Zugriff auf entfernte Datenbestände (GASS, Global Access to Secondary Storage) oder zur Identifizierung nicht mehr laufender Systeme (HBM, Heartbeat Monitor).

Es ist zu erwarten, dass innerhalb von ein paar Jahren die von Globus bereitgestellten Dienste weiter in das jeweilige Betriebssystem eingegliedert werden, so wie heute etwa die Kommunikation mit TCP/IP auch als Bestandteil des Betriebssystems aufgefasst werden kann.

Verteilte Filesysteme

Globus stellt zwar bereits Funktionen zum Zugriff auf verteilte Ressourcen bereit, wegen ihrer zunehmenden Bedeutung soll hier aber auch ein kurzer Blick auf eine Alternative geworfen werden: die verteilten Filesysteme. Das Andrew Filesystem (AFS)[5], heute im Besitz von IBM, ist einer der ältesten Vertreter dieser Gattung. Nach der Authentifizierung erlaubt es transparenten Zugriff auf verteilte Datenbestände als (virtuellem) Teil des lokalen Filesystems.

Im Unterschied zu NFS, dem Network Filesystem, eignet es sich auch zum Zugriff auf entfernte Datenbestände. AFS erreicht dies durch die Verwendung eines lokalen Cache, der in vielen Fällen den langsamen Transfer großer Datenbestände über ein Wide Area Network unnötig macht. Weitere Entwicklungen wie das Global Filesystem (GFS)[6] und IBMs GPFS[7] sind für den Einsatz in lokalen Netzwerken gedacht und wegen der unvermeidbaren Latenzzeiten nur bedingt in einem Wide Area Network einsetzbar. GPFS kommt in IBMs Supercomputer ASCI Blue zum Einsatz. PVFS[8] ist eine weitere, freie Alternative.

Linux und GRID-Computing

Aller Voraussicht nach kommt Linux künftig eine wichtige Rolle im GRID-Computing zu: Derzeit ist es eine der am häufigsten verwendeten Plattformen in diesem Bereich. Die Vorteile eines Open-Source-Betriebssystems treten hier in besonderem Maße hervor, weil die Weiterentwicklung von GRID-Technologien ein Betriebssystem erfordert, das die Möglichkeiten zum Experimentieren nicht einschränkt, sondern fördert.

Das gilt auch unter dem Aspekt, dass Teile der Globus-Dienstleistungen genauso gut oder besser auf Betriebssystemebene implementiert werden könnten statt auf Benutzer- und Programmebene. Die Forderung nach dem Schutz des Benutzers vor unnötigen Details könnte man ja auch auf Programmierer beziehen, jedenfalls wenn man will, dass möglichst viele Applikationen von vornherein die Fähigkeit haben sollen, im GRID zu laufen.

GRID-Initiativen

Weltweit existiert mittlerweile eine ganze Reihe verschiedener GRID-Initiativen. Hier ein kurzer Überblick: Das European Data GRID[9] wird mit 9,8 Millionen Euro von der Europäischen Union finanziert. Ziel des Projekts sind die Entwicklung und der nachfolgende Test einer europaweiten Infrastruktur im GRID-Bereich. Die Leitung des Projekts liegt beim CERN. Es soll aber nicht nur der Teilchenphysik dienen, sondern auch der Biologie und der Prozessierung medizinischer Bilddaten sowie Projekten zur Erdbeobachtung der European Space Agency ESA.

Auf diesem Data GRID wird Cross GRID aufbauen, eine neue Initiative des europäischen Wissenschaftsforums und derzeit noch in der Genehmigungsphase. Cross GRID will sich hauptsächlich mit der Applikationsentwicklung im Data-GRID-Umfeld beschäftigen, man könnte dieses neue Vorhaben als den praxisbezogenen Zwilling des Data-GRID-Projekts bezeichnen[10].

Griphyn ist das amerikanische Pendant zum European Data GRID, es beschäftigt sich hauptsächlich mit der Infrastruktur- und Applikationsentwicklung in der Hochenergiephysik. Die Finanzierung stellt die National Science Foundation[11] sicher. Das Information Power GRID (IPG) der NASA[12] soll den Zugang zu den über viele Standorte verteilten Computerressourcen der NASA durch ihre Techniker und Wissenschaftler vereinheitlichen. Wie schon das Data GRID und Griphyn ist auch diese Initiative Globus-basiert.

Das NEESgrid (National Virtual Laboratory for the Earthquake Engineering Simulation Community) möchte verschiedene Forschungsinstitute aus dem Bereich der Erdbebenforschung bündeln und so vorhandene Ressourcen besser nutzen[13]. Eine wohl eher untypische Anwendung von GRID-Technologien ist N.I.C.E., eine Art elektronischer Garten für Kinder[14].

Trotz der vielen bereits bestehenden GRID-Initiativen hält sich die Anzahl an echten Anwendungen noch sehr in Grenzen. Wo es sie gibt, wird zumindest im wissenschaftlichen Bereich die vorhandene Infrastruktur eher als verteiltes Batchsystem verwendet und das Anwendungsspektrum bei weitem nicht ausgeschöpft. Eine Liste vieler weiterer Initiativen und sonstiger Ressourcen findet sich auf[15].

Kommerzielle Aktivitäten

Tim Berners-Lee, einer der Väter des World Wide Web, war sicherlich vom kommerziellen Erfolg seiner Schöpfung überrascht. Sogar Microsoft hatte den neuen Trend damals fast verschlafen, dann aber mit dem Internet Explorer um so kräftiger aufgeholt. Mit .NET hat Microsoft jedoch heute eine eigene, dem GRID verwandte Entwicklung gestartet. Andere Firmen wie Sun oder IBM warten entweder ebenfalls mit eigenen Projekten auf oder arbeiten direkt im GRID-Umfeld auf der Basis von Globus.

So hat sich IBM dazu entschlossen, vier Milliarden Dollar in eigene GRID-Zentren sowie die Weiterentwicklung von GRID-Technologien zu investieren. Zum Vergleich: Das ist viermal so viel wie IBM in die Förderung von Linux investiert! Auf den Fachkonferenzen der GRID-Gemeinschaft, etwa dem Global Grid Forum in Frascati im Oktober, waren bereits die ersten Venture Capitalists zu beobachten.

Erste zaghafte Versuche zu Firmengründungen im GRID-Umfeld sind auch bereits zu finden. Jedoch wird es wohl noch zwei bis drei Jahre dauern, bis diese Netzwerke wirklich eine sichere Basis für den Aufbau einer wirtschaftlichen Existenz sind. Nicht zuletzt sind eine tragfähige Software-Infrastruktur sowie schnelle Datennetze unabdingbar für den kommerziellen Erfolg.

Kommerzielle Ableger etwa des Data GRID werden sich immer weit eher an große Firmen mit dem Bedarf an der Simulation komplizierter Prozesse richten als an Heimbenutzer. Deren Bereich werden wohl eher .NET und die damit konkurrierenden Linux-Projekte abdecken. Weil damit die potenzielle Benutzerzahl deutlich höher ist, dürften in diesem Bereich auch viel früher Firmenneugründungen in großem Umfang stattfinden: Es gibt schon mehrere Millionen .NET-Passport-Anmeldungen und damit potenzielle Kunden.

Übrigens sehen die Väter des GRID, Ian Foster und Carl Kesselman, in .NET nicht unbedingt eine Konkurrenz. Microsoft stellt sogar Geldmittel bereit, um Middleware-Tools wie Globus auch auf Microsofts Betriebssystemen verfügbar zu machen.

Fazit

Es ist gut möglich, dass den Technologien des GRID-Umfelds ein ähnlicher Erfolg beschieden sein wird, wie wir ihn beim World Wide Web beobachtet haben; für eine Vorhersage ist es zwar noch zu früh, aber Initiativen wie etwa die von IBM als Vorreiter in Sachen Technologieförderung machen es sehr wahrscheinlich.

Die Vision des GRID wurde zuerst in der Bibel des GRID-Computings beschrieben, dem Buch “The GRID, Blueprint for a New Computing Infrastructure” von Ian Foster und Carl Kesselman. Obwohl es mittlerweile etwas veraltet ist, handelt es sich immer noch um die umfangreichste Darstellung dieses neuen Themenbereichs[16]. Es lohnt sich sicherlich vor allem aus Linux-Sicht, die Entwicklung des GRID-Computings nicht aus den Augen zu verlieren. (uwo)