Alien-Services mit klaren Schnittstellen
Nach Installation, Setup (per Konfigurationsmanager) und Start beginnen die Alien-Services miteinander zu kommunizieren. Die zwischen den Komponenten (Dienste) ausgetauschten Nachrichten benutzen XML und SOAP. Vorteil des Dienste-Konzepts: Wegen der allgemein gehaltene Kommunikation braucht der Client keine Kenntnis über die Technik des Servers. In der Praxis sitzt zwischen Client und Serverapplikation meist ein vermittelnder Proxy-Service.
Das ist auch bei dem eben beschriebenen Filekatalog mit seiner SQL-Datenbank der Fall: Der Client muss nicht gegen spezielle Datenbanktreiber linken. Die Anwendung verbindet sich über einen Alien-Proxy-Treiber mit dem Proxy-Service, sodass der echte Datenbanktreiber nur dort installiert sein muss, wo deren Instanz läuft.
Derselbe Proxy-Service, der die Datenbankzugriffe übersetzt, arbeitet auch für den Authentication Service. Der Authentifizierungsdienst prüft per SASL-Protokoll[6] die Credentials (englisch etwa für Ausweispapiere) der Benutzer. Alien kennt die SASL-Mechanismen GSSAPI mit Globus/GSI, AFS-Passwort, SSH-Key, X509-Zertifikate und Alien-Token (siehe Artikel "Safer Grid").
Der Alien Resource Broker (RB) benutzt eine Pull-Architektur, im Gegensatz zur Push-Architektur der Globus-Grid-Systeme. Beim Pull fordert ein eingebundenes Computing-Element (siehe unten) neue Aufgaben vom Server an, sobald es wieder freie Kapazitäten hat. In dieser Konstellation muss der RB nicht den Status aller Systemressourcen kennen.
Wie das European Data Grid erwartet Alien von jedem übergebenen Programm eine nähere Beschreibung seiner Eigenschaften, um es ausführen zu können. Beispielsweise die Forderung nach einer bestimmten Laufzeitumgebung. Für die Beschreibung verwendet Alien die Condor Class Ads[7], gespeichert wird in Datenbanktabellen. Das Beschreibungsformat heißt Job Description Language (JDL). Das System wartet einfach darauf, dass sich ein Computing-Element mit ihm verbindet, und preist ihm als Antwort seine Fähigkeiten an.
Die Pull-Architektur erlaubt ein robustes System, das nicht auf die ständige Gegenwart aller Ressourcen angewiesen ist. Die lose Kopplung zwischen Ressourcen und den Resource Brokern, die die auszuführenden Programme an die Rechenressourcen verteilen, erlaubt es, fremde Grid-Systeme als Alien-Rechen- und Speicher-Elemente im Alien-Grid abzubilden. Nach diesem Prinzip entstand eine Alien-Schnittstelle zum European Data Grid. Seit März 2004 benutzen Forscher die EDG-Schnittstelle als Zugang zum LHC Computing Grid[8].
|
Abbildung 4: An einen Alien-Server kann man ein Alien-Rechenzentrum, aber auch ein anderes Grid anbinden.
|
Lokale Dienste
Üblicherweise läuft in einem Alien-Client-Zentrum eine Reihe von Diensten lokal. Ein typisches Beispiel ist der Cluster Monitor. Er fungiert als Gatekeeper, bietet also eine einheitliche Schnittstelle für alle einlaufenden Anfragen. Außerdem ist er der Proxy für die Dienste hinter dem Firewall. Ein anderer lokaler Dienst sind die Computing-Elemente (CE, Rechen-Elemente). Sie bilden die Schnittstelle zu lokalen Batchsystemen. Die Storage-Elemente (SE, Speicher-Elemente) übernehmen das Abrufen und Speichern von Daten auf und von den lokalen Massenspeichern.
Über den Process Monitor Service, der als Interface zu jedem Alien-Job fungiert, steuert der Benutzer seine laufenden Jobs. Der File Transfer Service - sein Name ist selbsterklärend - läuft auf demselben Rechner wie das Storage-Element. Die Filetransfer-Dienste haben die Entwickler als Daemons implementiert. Sie authentifizieren sich gegenseitig mit den von der Alien-CA ausgestellten Zertifikaten und führen Datenübertragungen im Namen des Benutzers durch.
Als Teil des Alien-Monitoring-Moduls installiert sich das Mona-Lisa-System. Es sammelt Statusinformationen aus dem Grid ein und veröffentlicht sie über Webdienste. Nutznießer sind Alien-Optimierprogramme und Visualisierungen, Abbildung 5 zeigt ein Beispiel.
|
Abbildung 5: Das Mona-Lisa-Monitoring-System zeigt angeschlossene Rechenzentren (gelbe Kreise). Zudem sind rechnende Alien-Jobs in Karlsruhe zu sehen.
|
| Whitepaper |
|---|
|
Daten Migration - Eine Publikation von Bloor Research
Datenmigrationsprojekte überschreiten häufig das Budget, neigen zu Verzögerung und werden unter Umständen komplett abgebrochen. Bloor Research ist eines der weltweit führenden IT-Forschungs-, Analyse- und Beratungsunternehmen und wird in dem vorliegenden White Paper die wichtigsten Aspekte dieser Problematik näher beleuchten. Ferner werden praktische Empfehlungen für erfolgreiche Migrationsprojekte gegeben, die Sie auf Ihr nächstes Projekt übertragen können.
Download PDF (Registrierung erforderlich)
|
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele
Über die letzten Jahre hinweg haben sich Open Source Lösungen als fester Bestandteil des gesamten Datenintegrationsmarktes etabliert. Viele Unternehmen haben bereits das Open Source Modell für Ihre Datenintegrationsprojekte aufgegriffen. Das vorliegende White Paper illustriert anhand ausgewählter Fallstudien und Anwendungsbeispiele die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|
