gLite – Wikipedia

gLite (ausgesprochen “gee-lite”) ist ein Middleware-Computersoftwareprojekt für Grid-Computing, das von den CERN-LHC-Experimenten und anderen wissenschaftlichen Domänen verwendet wird. Es wurde durch gemeinsame Anstrengungen von mehr als 80 Personen in 12 verschiedenen akademischen und industriellen Forschungszentren in Europa umgesetzt. gLite bietet ein Framework zum Erstellen von Anwendungen, die verteilte Computer- und Speicherressourcen über das Internet nutzen. Die gLite-Dienste wurden von mehr als 250 Rechenzentren übernommen und von mehr als 15000 Forschern in Europa und weltweit genutzt.

Geschichte[edit]

Nach Prototyping-Phasen in den Jahren 2004 und 2005 wurde die Konvergenz mit der LHC Computing Grid (LCG-2)-Distribution im Mai 2006 erreicht, als gLite 3.0 veröffentlicht wurde und die offizielle Middleware der Enabling Grids for E-Science (EGEE) wurde. Projekt, das 2010 endete.

Die Entwicklung der gLite Middleware wurde dann von der European Middleware Initiative übernommen und wird nun als Teil des EMI Software Stack gepflegt.

Die von EGEE aufgebaute verteilte Computerinfrastruktur wird nun von der European Grid Infrastructure unterstützt. Es betreibt die von der “European Middleware Initiative” produzierte Grid-Middleware, von der viele Komponenten aus der gLite-Middleware stammen.

Middleware-Beschreibung[edit]

Sicherheit[edit]

Die gLite-Benutzergemeinschaft ist in Virtual Organizations (VOs) gruppiert.^[1] Ein Benutzer muss einer VO beitreten, die von der Infrastruktur unterstützt wird, auf der gLite ausgeführt wird, um authentifiziert und zur Verwendung von Grid-Ressourcen autorisiert zu werden.

Die Grid Security Infrastructure (GSI) in WLCG/EGEE ermöglicht eine sichere Authentifizierung und Kommunikation über ein offenes Netzwerk.^[2] GSI basiert auf Public-Key-Verschlüsselung, X.509-Zertifikaten und dem Kommunikationsprotokoll Secure Sockets Layer (SSL) mit Erweiterungen für Single Sign-On und Delegierung.

Um sich selbst zu authentifizieren, benötigt ein Benutzer ein digitales X.509-Zertifikat, das von einer Zertifizierungsstelle (CA) ausgestellt wurde, der die Infrastruktur der Middleware vertraut.

Die Autorisierung eines Benutzers für eine bestimmte Grid-Ressource kann auf zwei verschiedene Arten erfolgen. Die erste ist einfacher und basiert auf dem Grid-Mapfile-Mechanismus. Der zweite Weg beruht auf dem Virtual Organization Membership Service (VOMS) und dem LCAS/LCMAPS-Mechanismus, die eine detailliertere Definition von Benutzerrechten ermöglichen.

Benutzeroberfläche[edit]

Der Zugangspunkt zum gLite Grid ist die Benutzeroberfläche (UI). Dies kann jeder Computer sein, auf dem Benutzer ein persönliches Konto haben und auf dem ihr Benutzerzertifikat installiert ist. Über eine Benutzeroberfläche kann ein Benutzer authentifiziert und autorisiert werden, die WLCG/EGEE-Ressourcen zu verwenden, und kann auf die Funktionalitäten zugreifen, die von den Informations-, Arbeitslast- und Datenmanagementsystemen angeboten werden. Es bietet CLI-Tools zum Ausführen einiger grundlegender Grid-Operationen:

• alle Ressourcen auflisten, die für die Ausführung eines bestimmten Jobs geeignet sind;
• Aufträge zur Ausführung übermitteln;
• Jobs abbrechen;
• Abrufen der Ausgabe abgeschlossener Jobs;
• den Status der übermittelten Jobs anzeigen;
• Abrufen der Protokollierungs- und Buchhaltungsinformationen von Jobs;
• kopieren, replizieren und löschen Sie Dateien aus dem Grid;
• Abrufen des Status verschiedener Ressourcen aus dem Informationssystem.

Rechenelement[edit]

Ein Computing Element (CE) ist in der Grid-Terminologie ein Satz von Computerressourcen, die an einem Standort (dh einem Cluster, einer Computerfarm) lokalisiert sind. Ein CE enthält ein Grid Gate (GG), das als generische Schnittstelle zum Cluster fungiert; ein Local Resource Management System (LRMS) (manchmal auch als Batch-System bezeichnet) und der Cluster selbst, eine Sammlung von Worker Nodes (WNs), den Knoten, auf denen die Jobs ausgeführt werden.

Es gibt zwei CE-Implementierungen in gLite 3.1: das von EDG entwickelte und in LCG-22 verwendete LCG CE und das von EGEE entwickelte gLite CE. Sites können auswählen, was installiert werden soll, und einige von ihnen bieten beide Typen. Das GG ist für die Annahme von Aufträgen und deren Weiterleitung zur Ausführung an die WNs über das LRMS zuständig.

In gLite 3.1 unterstützte LRMS-Typen waren OpenPBS/PBSPro, Platform LSF, Maui/Torque, BQS und Condor sowie Sun Grid Engine.^[3]

Speicherelement[edit]

Ein Speicherelement (SE) bietet einen einheitlichen Zugriff auf Datenspeicherressourcen. Das Speicherelement kann einfache Plattenserver, große Plattenarrays oder bandbasierte Massenspeichersysteme (MSS) steuern. Die meisten WLCG/EGEE-Standorte bieten mindestens eine SE.

Speicherelemente können verschiedene Datenzugriffsprotokolle und Schnittstellen unterstützen. Einfach gesagt ist GSIFTP (ein GSI-sicheres FTP) das Protokoll für die Übertragung ganzer Dateien, während der lokale und entfernte Dateizugriff über RFIO oder gsidcap erfolgt.

Die meisten Speicherressourcen werden von einem Storage Resource Manager (SRM) verwaltet, einem Middleware-Dienst, der Funktionen wie die transparente Dateimigration von der Festplatte auf das Band, das Anheften von Dateien, die Platzreservierung usw. bietet. Allerdings können verschiedene SEs unterschiedliche Versionen des SRM-Protokolls unterstützen und die Fähigkeiten können variieren.

Es gibt eine Reihe von SRM-Implementierungen mit unterschiedlichen Fähigkeiten. Der Disk Pool Manager (DPM) wird nur für relativ kleine SEs mit festplattenbasiertem Speicher verwendet, während CASTOR für die Verwaltung großer MSS mit Front-End-Festplatten und Back-End-Bandspeicher entwickelt wurde. dCache richtet sich sowohl an MSS- als auch an große Disk-Array-Speichersysteme. Andere SRM-Implementierungen befinden sich in der Entwicklung und die SRM-Protokollspezifikation selbst entwickelt sich ebenfalls weiter.

Klassische SEs, die keine SRM-Schnittstelle haben, bieten ein einfaches plattenbasiertes Speichermodell. Sie befinden sich im Auslaufverfahren.^[when?]

Informationsservice[edit]

Der Informationsdienst (IS) gibt Auskunft über die WLCG/EGEE Grid-Ressourcen und deren Status. Diese Informationen sind für den Betrieb des gesamten Grids unerlässlich, da über den IS Ressourcen entdeckt werden. Die veröffentlichten Informationen werden auch für Überwachungs- und Abrechnungszwecke verwendet.

Viele der an den IS veröffentlichten Daten entsprechen dem GLUE-Schema,^[4] die ein gemeinsames konzeptionelles Datenmodell definiert, das für die Überwachung und Erkennung von Grid-Ressourcen verwendet werden soll.

Das in gLite 3.1 verwendete Informationssystem erbt seine Hauptkonzepte vom Globus Monitoring and Discovery Service (MDS).^[5] Die GRIS und GIIS im MDB wurden jedoch durch die . ersetzt Berkeley-Datenbank-Informationsindex (BDII), bei dem es sich im Wesentlichen um einen OpenLDAP-Server handelt, der von einem externen Prozess aktualisiert wird.

Workload-Management[edit]

Der Zweck des Workload-Management-Systems (WMS)^[6] besteht darin, Benutzeraufträge anzunehmen, sie dem am besten geeigneten Computing-Element zuzuweisen, ihren Status aufzuzeichnen und ihre Ausgabe abzurufen. Der Resource Broker (RB) ist die Maschine, auf der die WMS-Dienste ausgeführt werden.

Zu übergebende Jobs werden mit der Job Description Language (JDL) beschrieben, die beispielsweise angibt, welche ausführbare Datei ausgeführt werden soll und deren Parameter, Dateien, die zum und vom Worker-Knoten, auf dem der Job ausgeführt wird, verschoben werden sollen, benötigte Eingabe-Grid-Dateien , sowie alle Anforderungen an den CE und den Worker Node.

Die Auswahl des CE, an das der Job gesendet wird, wird in einem als Matchmaking bezeichneten Prozess getroffen, der zunächst unter allen verfügbaren CEs diejenigen auswählt, die die vom Benutzer geäußerten Anforderungen erfüllen und die den angegebenen Eingabe-Grid-Dateien nahe kommen. Es wählt dann das CE mit dem höchsten Rang aus, eine aus den CE-Statusinformationen abgeleitete Größe, die die Güte eines CE (typischerweise eine Funktion der Anzahl der laufenden und in die Warteschlange gestellten Jobs).

Der RB lokalisiert die in der Jobbeschreibung angegebenen Grid-Eingabedateien unter Verwendung eines Dienstes namens Data Location Interface (DLI), der eine generische Schnittstelle zu einem Dateikatalog bereitstellt. Auf diese Weise kann der Resource Broker mit anderen Dateikatalogen als LFC kommunizieren (sofern diese über eine DLI-Schnittstelle verfügen).

Die neueste Implementierung des WMS von EGEE ermöglicht nicht nur die Übergabe einzelner Jobs, sondern auch Sammlungen von Jobs (evtl. mit Abhängigkeiten zwischen ihnen) viel effizienter als das alte LCG-2 WMS und bietet viele weitere neue Möglichkeiten .

Schließlich der Dienst Protokollierung und Buchführung (LB)^[7] verfolgt vom WMS verwaltete Jobs. Es sammelt Ereignisse von vielen WMS-Komponenten und zeichnet den Status und die Historie des Jobs auf.

Verweise[edit]

Externe Links[edit]

Softwarekomponenten[edit]

Einige gLite-Komponenten und -Dienste mit den beitragenden Partnern:

• VOMS und VOMSAdmin (INFN)
• Erneuerung von Proxy- und Attributzertifikaten (CESNET)
• Shibboleth-Interoperabilität: SLCS, VASH, STS (SWITCH)
• LCAS/LCMAPS (NIKHEF)
• gLExec (NIKHEF)
• Delegationsrahmen (CERN, HIP, STFC)
• CGSI_gSOAP (CERN)
• gsoap-Plugin (CESNET)
• Vertrauensmanager (HIP)
• Util-Java (HIP)
• Netzstandort (STFC)
• Berechtigungsrahmen (HIP, INFN, NIKHEF, SWITCH)
• BDII (CERN)
• Grid Laboratory Uniform Environment (CERN)
• R-GMA (STFC)
• CREME (INFN)
• CEMon (INFN)
• BLAH (INFN)
• WMS (INFN, ElsagDatamat)
• PFUND (CESNET)
• DPM (CERN)
• GFAL (CERN)
• LFC (CERN)
• FTS (CERN)
• lcg_utils (CERN)
• EDS und Hydra (HIP)
• AMGA (CERN, KISTI, INFN)