Die meisten Organisationen lassen ihre oft weit verteilten, enormen Rechnerkapazitäten brach liegen. Mainframes sind im Durchschnitt 40 Prozent der Zeit im Leerlauf, die meisten Server sind nur zu zehn Prozent ausgelastet und der typische Arbeitsplatzrechner langweilt sich während 95 Prozent seiner Arbeitszeit.
Die Bezeichnung Grid Computing entstand Mitte der 90er aus dem Begriff des Power Grid, dem Netzwerk der amerikanischen Stromversorgung. Ähnlich wie wir eine Glühbirne mit Strom aus der Steckdose versorgen, ohne das erzeugende Kraftwerk zu kennen, wollen Visionäre Supercomputing Power mit einfachen Terminals und PCs aus dem Netz ziehen, anstatt ein eigenes Kraftwerk unter jedem Schreibtisch aufzustellen.
Das Grid-Problem
Um einen Rechnerverbund aufzubauen, benötigt man kontrolliertes und vor allem koordiniertes Ressourcen-Sharing, das für eine dynamische und skalierbare virtuelle Organisation tauglich ist. Hier geht es um mehr als nur Dateiaustausch oder direkten Zugriff auf Rechenpower, Software, Daten und andere Ressourcen. Sharing erfordert unter anderem
- Authentifizierung
- Authorisierung
- koordinierten Zugriff auf Ressourcen
- Finden verfügbarer Ressourcen
Damit liegt der eigentliche Fokus beim Grid Computing auf dem Ressourcen-Sharing in großen Verbünden, um den Nutzern die optimale (Hoch-)Leistung zur Verfügung stellen zu können.
Virtuelle Organisationen
Schließen sich mehrere Individuen oder Institutionen zu einem Rechnerverbund zusammen, werden sie als virtuelle Organisation bezeichnet. Sie zeichnen sich aus durch:
- sehr flexible Sharing-Beziehungen, die sich schnell ändern können: Client-Server- oder Peer-To-Peer-Strukturen werden je nach Bedarf eingerichtet.
- Finden und Charakterisieren von Ressourcen
- genaue Kontrolle über die geteilten Ressourcen
- Delegationsmechanismen zur lokalen oder globalen Ausführung von Programmen mit den jeweiligen Benutzerrechten
- generelle lokale und globale Policies
- Kostenkontrolle und Accounting der verfügbaren und benutzten Ressourcen
- Regelungsmechanismen zwischen hohen Performanceansprüchen und der Vermeidung hoher Kosten
- Quality of Service
- Scheduling
Grids und Distributed Computing
Grid Computing wird noch mindestens drei Jahre brauchen, bis es Mainstream geworden ist, trotzdem prognostiziert eine Studie von Insight Research eine Marktentwicklung für Grid Computing von 250 Millionen Dollar im Jahr 2003 auf fast fünf Milliarden im Jahr 2008 voraus [GridForecast].
Existierende verteilte Anwendungen sind oft keine echten Grid-Anwendungen, da sie nicht die verfügbaren Ressourcen-Typen bündeln und auch nicht über die Flexibilität und Kontrolle verfügen, um die notwendigen Beziehungen herzustellen und aufrechtzuerhalten.
Bei den heutigen Internet-Technologien steht vor allem die Kommunikation und der Informationsaustausch zwischen einzelnen Computern im Vordergrund, nicht aber der integrierte koordinierte Gebrauch von Ressourcen zwischen mehreren Rechenzentren (Sites). B2B-Marktplätze konzentrieren sich auf Informations-Sharing. In Unternehmen wird nur selten mit Technologien wie CORBA, DCE, Enterprise Java, etc. siteübergreifend programmiert, da die Programmierung schwierig und fehleranfällig ist. Auch in VPNs erfolgt der Gebrauch von ungenützter Computerkapazität fast immer nur über einen sehr zentralisierten Zugriff.
Beispiele
IBM und das Genfer Forschungszentrum CERN entwickeln das weltweit größte Daten-Management-System für verteiltes Rechnen. Das Netz soll dazu dienen, die Entstehung der Erde zu berechnen. Das Kernstück wird ab 2007 ein LHC (Large Hadron Collider) genannter Teilchenbeschleuniger sein, der den Urknall simuliert. Dabei fällt eine Datenmenge von 100 Megabyte pro Sekunde (!) an. Für die Berechnung jedes einzelnen Jahres nach dem Knall rechnen die Wissenschaftler mit zehn Petabyte an Daten (ein Petabyte = eine Million Gigabyte). IBM steuert einen Storage-Cluster mit einer Kapazität von 20 Terabyte (ein Terabyte = 1000 Gigabyte) bei, der auf sechs eServern der xSeries basiert. Als Betriebssystem des 2,5 Millionen Dollar teuren Rechnerverbunds kommt Linux zum Einsatz. Auch Hewlett-Packard (HP) und der Netzausrüster Enterasys Networks sind an der Entwicklung des Grids beteiligt. Von HP kommt ein Cluster mit 32 Knoten, in dem Itanium-2-Prozessoren takten. Enterasys übernimmt die Verkabelung via zehn-Gigabit-Ethernet.
Die Harvard-Universität entwickelt zusammen mit IBM das universitätsweite Hochleistungsnetzwerk Crimson Grid für die wissenschaftliche Forschung. Mit diesem Grid-Computing-Netzwerk können Studenten und Forscher aus den Bereichen Life Sciences, Ingenieurwesen und angewandte Wissenschaften zukünftig gemeinsam auf Forschungsdaten zugreifen und zusammenarbeiten. Durch die Vernetzung vieler verschiedener Computer entsteht ein virtueller Supercomputer, dessen Rechner-Ressourcen, Anwendungen und Speicherkapazität jederzeit und von jedem Ort aus zugänglich und verfügbar sind. Harvard und IBM werden außerdem zusammen Grid-Tools entwickeln und testen. Diese basieren auf offenen Standards und sollen anderen akademischen Einrichtungen dabei helfen, ebenfalls die Vorteile von Grid Computing für ihre Forschungen zu nutzen. Die technische Grundlage bilden hier unter anderem IBM-Server und die Open Grid Services Architecture (OGSA), die sich als Standard herausgebildet hat.
Architektur und Infrastruktur
Die Architektur für Grid Computing wird in der Open Grid Services Architecture (OGSA) definiert, die vom Global Grid Forum (GGF) entwickelt wird. Die OGSA definiert, was Grid Services sind, und welche Struktur und Services in Grid-Umgebungen vorhanden sein sollen. Die Open Grid Services Infrastructure (OGSI) ist eine formale Spezifikation der Konzepte, auf denen die OGSA basiert. Sie stellt einige Primitive bereit, die den gemeinsamen Kern aller Grid Service-Funktionalität bestimmt.
Aufgebaut wird auf bestehenden Web Service-Standards. Ein Grid Service ist damit einfach ein Web Service, der mit einigen zusätzlichen Konventionen konform geht. Die Grid Services werden mit einer Erweiterung der Web Services Definition Language WSDL beschrieben, wodurch sie mit Standards wie SOAP, XML und WS-Security kompatibel werden. OGSA-konforme Grids werden zudem miteinander interagieren können, auch wenn sie mit verschiedenen Tools erstellt wurden.
Die Standards konzentrieren sich auf die Art und Weise der Interaktion von Grids und halten sich aus der Implementation heraus. APIs und SDKs werden erst relevant, nachdem die Protokolle und Services festgelegt worden sind. Mit diesen Vorgaben können sich Virtuelle Organisationen schnell an neue Gegebenheiten anpassen und Ressourcen umverteilen. Wenn Japan schläft, steht für Europa viel Rechenleistung zur Verfügung.
Anwender der verschiedenen Toolkits wie zum Beispiel den noch zu besprechenden Globus Grid Tools sollten regelmäßig nach Aktualisierungen und Erweiterungen der Standards Ausschau halten, um ihren Grid-Anteil auf dem Laufenden zu halten.
Gemeinsames Protokoll
Die Realisierung von Beziehungen zwischen den möglicherweise verschiedenen Komponentenrechnern in einem Grid steht und fällt mit einem einfachen Übertragungsprotokoll. Unabhängigkeit von Programmiersprachen und Betriebssystemen ist hier oberstes Gebot, gleich gefolgt von Offenheit und Erweiterbarkeit. Wie wichtig das ist, hat die Geschichte des WWW eindrucksvoll gezeigt. Und in der Tat werden die Erfahrungen mit HTTP und HTML in die Entwicklung der Grid-tauglichen Protokolle und Beschreibungssyntax mit einbezogen, wenn es darum geht, sich den Schwierigkeiten bei der Beschreibung eines einheitlichen Sicherheitsmanagements zu stellen, das die Policies mehrerer Institutionen unter einem Dach vereinen muss.
Auch der sichere Zugriff auf Rechner und Datenquellen muss gelöst werden, damit die Daten auf dem schnellsten Weg zur entsprechenden Anwendung gelangen können. Die Überwachung der Netzwerkauslastung gehört genauso in dieses Aufgabenfeld wie der gesteuerte Zugriff auf Code Repositories (zum Beispiel CVS) und Kataloge (Datenbanken jeder Art).
Schichten
Ähnlich wie beim Internet wird auch hier eine Layer-Architektur verwendet. Die Grid Layers werden dabei verschiedenen Internet Layers zugeordnet:
Internet Protocol Architecture (vereinfacht)Anwendung -> Transport -> Internet -> Link
Grid Protocol Architecture Anwendung -> (Collective, Resource, Connectivity) -> Fabric
Die Fabric ist die Schnittstelle zur lokalen Kontrolle, z.B. einem Speichersystem. Es werden lokale, ressourcenspezifische Operationen (als Ergebnis von Sharing auf höherem Level) implementiert. Das oben schon erwähnte Globus Toolkit versucht, so viele existierende Fabrics wie möglich zu benutzen, liefert aber die Infrastruktur auch selbst, wenn es notwendig wird. Forschungsgruppen haben das Batch-System PBS [PBS] erweitert, um zum Beispiel die Reservierung von Ressourcen für einen späteren Zeitpunkt zu ermöglichen.
Die Connectivity implementiert einfache und sichere Kommunikations- und Authentifizierungsprotokolle sowie ein Single-Sign-on-Verfahren, mit dem man sich nur einmal am Grid anmelden muss, auch wenn man über Institutionsgrenzen hinweg auf Ressourcen zugreift. Per Delegation laufen die Programme dann im Auftrag des Benutzers und mit dessen Grid-Rechten, die auch an andere Programme weitergegeben werden können. Eine besondere Herausforderung für Globus war die Integration der verschiedenen lokalen Sicherheitslösungen wie Kerberos, Unix Security etc., die auf die verschiedenen lokalen Umgebungen abgebildet werden mussten. Das Globus Toolkit bietet nun die Public Key-basierten Grid Security Infrastructure (GSI)-Protokolle, die die bekannten Transport Layer Sicherheit (TLS)-Protokolle mit Kerberos und im X.509-Format identifizierten Zertifikaten integrieren.
Die gemeinsame Ressourcennutzung benötigt sichere Methoden für die Einleitung, Überwachung, Kontrolle, Buchhaltung und Bezahlung von verteilten Operationen und individuellen Ressourcen. Hierzu wurden zwei Arten von Resource Layer-Protokollen entwickelt:
- Informationsprotokolle tauschen Informationen über die Struktur und den Zustand der Ressource: Konfiguration, momentaner Load, Usage Policy, etc.
- Managementprotokolle verhandeln über den Zugriff auf eine gesharte Ressource: Reservierungen, Quality of Service, anstehende Operationen (Datenzugriff, Prozesserzeugung usw.)
Im Globus Toolkit wurden hierfür viele bekannte Protokolle abgewandelt:
- GRIP (Grid Resource Information Protocol) setzt auf LDAP auf und verwendet einen Grid Index Information Server
- das HTTP-basierte Grid Resource Access und Management (GRAM) für Protokollangelegenheiten (Allokation, Überwachung, Kontrolle)
- GridFTP (erweitertes File Transfer Protocol)
- LDAP (Lightweight Directory Access Protocol)
Während es im Resource Layer um einzelne Ressourcen geht, organisiert der Collective Layer die Interaktion zwischen mehreren Ressourcen:
- Directory Services stellen die Existenz und Eigenschaften neuer Ressourcen in der VO fest.
- Co-Allokation, Scheduling und Brokering Services
- Monitoring und diagnostische Services
Datenreplikation
- Grid-taugliche Softwareentwicklung (zum Beispiel Grid-enable MPI). Dieser Bereich erstreckt sich von Workload Management-Systemen und kollaborativen Frameworks bis zu Software Directory Services (entsprechend NetSolve, Ninf; man sucht sich die für die Problemparameter am besten passende Implementation und Ausführungsplattform aus), von Community Authorization Servers bis zu Community Buchhaltung und Bezahlung.
Globus Toolkit
Die Globus-Allianz ist ein Forschungs- und Entwicklungsprojekt, um Grid-Anwendungen im Ingenieur- und wissenschaftlichen Bereich voranzutreiben. Das Toolkit enthält viele Services und praktische Komponenten, die man einzeln oder zusammen verwenden kann, um Grids zu bauen und Anwendungen zu programmieren:
- Der Globus Resource Allocation Manager (GRAM) bietet Resource-Allokation und Prozesserzeugung, Überwachung und Management von Services. Die GRAM-Implementation übersetzt Anforderungen in eine Resource Specification Language (RSL), die in Kommandos für lokale Scheduler und Computer übersetzt wird.
- Die Grid Security Infrastructure (GSI) bietet einen Single-Sign-on, Run-anywhere"-Authentifizierungsdienst, der die lokale Kontrolle für Zugriffe unterstützt und Grid-Identitäten lokalen Usern zuordnet. Der Einsatz von Smartcards erhöht noch einmal die Sicherheit.
- Der Monitoring und Discovery Service (MDS) ist ein erweiterbarer Grid Information Service, der Heuristiken mit dem Lightweight Directory Access Protocol (LDAP) verbindet. MDS bietet ein einheitliches Framework, um System- und Statusinformationen wie Rechenserverkonfiguration, Netzwerkstatus oder den Ort von replizierten Datensets zu erhalten.
- Global Access to Secondary Storage (GASS) implementiert eine Vielzahl von automatisch oder vom Programmierer verwalteten Management- sowie Zugriffsstrategien für den Datenbestand, sodass Programme, die auf entfernten Rechnern laufen, lokal vorhandene Daten lesen und schreiben können.
- Der Heratbeat Monitor (HBM) erlaubt die Aufdeckung von Systemausfällen durch Systemadministratoren oder gewöhnliche Benutzer
Für alle Komponenten gibt es C-APIs und Kommandozeilentools. Für die wichtigsten Komponenten gibt es auch Java-Klassen. Zusätzlich zu diesen Core Services hat die Globus Allianz Prototypen von Higher Level-Komponenten entwickelt (Resource Broker, Resource Co-Allocator). Das Kondor Toolkit wird weltweit eingesetzt.
Wie mache ich meine Anwendung Grid-tauglich?
Manchmal reicht es schon, das Programm mit den richtigen Bibliotheken neu zu linken: anstatt normalem Message Passing Interface (MPI) verwendet man MPICH-G [MPICH-G2], eine Grid-taugliche MPI-Implementation.
Ansonsten wird man sich langsam an das Grid herantasten: Durch Resource Managment Services vereinfacht man den Programm-Start auf mehreren Computern, sodass man nicht mehr mehrere Logins und Scheduler-Kommandos braucht. Danach kommt DUROC, eine Globus-Bibliothek zum Einsatz, die das Starten über mehrere Sites vereinfacht und Fehlererkennung und -behebung bietet. Schließlich vereinfachen die Globus Data Access Services die Verbreitung von ausführbaren Programmen und Konfigurationsdateien und den Rücktransport der Resultate zum Auftraggeber.
Fazit
VOs werden verändern, wie wir heute Computer benutzen, genauso wie das Internet verändert hat, wie wir Informationen austauschen. Hoffen wir, dass das Grid der Informatiker robuster sein wird, als das Power Grid, welches diesen Winter durch Blackouts für große Aufmerksamkeit sorgte.
Missverständnisse
Was ist das Grid nicht?
- Das Grid ist nicht die nächste Generation des Internets, auch wenn Reporter das gerne predigen. Ein Grid ist per Definition Teil des Internets, da die Internet-Protokolle nur leicht erweitert werden.
- Das Grid wird kein Freibier sein. Durch genaue Buchhaltung können die Kosten für eine Berechnung präzise berechnet werden. Was sinnvolle Metriken sind, die von den Kunden auch akzeptiert werde, muss noch herausgefunden werden.
- Das Grid ist kein neues Programmiermodell und kein Ersatz für dedizierte High Performance Computer mit geringer Latenzzeit und hoher Kommunikationsbandbreite. Grid Computing wird den Bedarf nach High Performance Computing eher erhöhen als verringern.
Unterschied zu Condor
Condor [Condor] ist ein Batchsystem, das sich sehr gut für Untersuchungen mit wechselnden Parametern oder hohem Datendurchsatz eignet. Es ist komplementär zu Globus, wie in der Implementation von Condor-G [CondorG] deutlich wird. Globus kümmert sich um Sicherheit und Ressourcen, während Condor eingesetzt wird, um Jobs auf Systeme zu submitten, die von Globus gemanagt werden.
Anwendungsgebiete
- Verzahnung von vielen Legacy-Systemen, die an verschiedenen Orten ausgeführt werden, zum Beispiel Machbarkeitsstudien für ein neues Flugzeug
- Mitglieder einer langfristig angelegten, großen, internationalen Zusammenarbeit im Bereich der Hochenergiephysik
- verteiltes Supercomputing wie NASAs OVERFLOW D2 (numerisches Number Crunching) [Overflow], MM5 Wettervorhersage [MM5], Neph (Meterologie) [Neph]
Andere Player
Bereits im Februar hat Sun Microsystems angekündigt, die hauseigene Grid Engine in Sun ONE (Sun Open Net Environment) [SunONE] zu integrieren. Die Software ist ein Werkzeug zur Verwaltung von verteilten Ressourcen und kann für Cluster und Campus-Grids eingesetzt werden: Sie erteilt Rechenaufträge an innerhalb eines Grids verfügbare Computer und verwaltet diese Vorgänge. Nach Angaben von Wolfgang Gentzsch, Director für Grid Computing bei Sun, arbeiten Hunderttausende von CPUs in weltweit mehr als 8.000 Grids bereits mit dieser Software. Das Programmpaket - damals noch unter dem Namen Codine bekannt - erwarb Sun im Juli 2000 durch die Übernahme des Herstellers Gridware, dessen Mitbegründer Gentzsch war.
Die Grid Engine war für die McNealy-Company der Eintritt zum High Performance Computing (HPC). Zuvor hatte Sun nur wenig interessante Produkte für den wissenschaftlichen Bereich. Im HPC oder High Performance Technical Computing (HPTC) sieht Gentzsch die Basis für das neue Geschäft: HPTC ist die Wiege von Grid Computing. Heute bestehen nach Meinung von Gentzsch große Synergieeffekte zwischen Grid und HPTC, sodass Grid die Grundlage auch für leistungsstarke HPC-Knoten, Supercomputer oder Super-Cluster bildet.
Links
Hat Ihnen dieser Artikel gefallen? Dann abonnieren Sie das Entwickler Magazin direkt über unser
