Unicore 6

Unicore 6 ist – ähnlich wie das Globus Toolkit oder gLite – eine Grid-Middleware und bietet “ready-to-run” Grid-Systeme, bestehend aus Client- und Server-Software, mit der verteiltes Rechnen und der Zugriff auf Ressourcen sowohl im Intranet als auch im Internet sicher und nahtlos möglich ist. Unicore steht für UNiform Interface to COmputing Ressources und ist seit Sommer 2004 als Open Source verfügbar.
Die Implementierung von Unicore baut auf vielen etablierten Standards auf (u.A. vom OGF, W3C, OASIS und IETF), wodurch die Software leicht zugänglich gemacht werden soll, Interoperabilität mit anderen Grid-Middlewares gewährleistet werden soll und Weiterentwicklungen problemlos möglich sind.

Funktionen

• Authentifizierung und Autorisierung: Unicore’s Sicherheitskonzept basiert auf einer Public Key Infrastruktur (PKI) zusammen mit X.509- und Proxy-Zertifikaten; für die Attribut-basierte Autorisierung werden SAML und XACML eingesetzt. Zudem werden Virtuelle Organisationen unterstützt.
• Meta-Daten und Ressourcen-Spezifikation: Die vorhandenen WebServices werden mittels WSDL beschrieben (Unicore basiert auf dem Konzept der WebServices).  Zudem verfügt Unicore über eine komplette Implementierung einer WSRF-Umgebung. In dieser Umgebung werden Grid-Ressourcen (Jobs, Target-Systeme und Speicher) als stateful WebServices implementiert und Ressourcen über das WS-Addressing angesprochen. Für den Nachrichten-Austausch werden WS-Notifications verwendet.
• Job-Beschreibung und -Management: Unicore enthält eine Implementierung des OGF’s Basic Execution Service (BES) und verwendet die Job Submission Description Language (JSDL)
• Informations-Modellierung: Unicore enthält eine Implentierung des OGF’s Grid Laboratory Uniform Environments (GLUE), um Grid-Ressourcen zu verwalten und zu überwachen. Auf GLUE baut der Common Information Service (CIS) von Unicore auf.
• Flexibilität und Interoperabilität: Unicore läuft unter der BSD-Lizenz (Open Source), ist in Java implementiert und bietet verschiedene Clients für die Job-Definition an (GUI, Commandline, API). Unicore implementiert die Open Grid Service Architecture (OGSA) und folgt dem Konzept der Service-orientierten Architektur (SOA), wodurch einzelne Komponenten leicht ausgetauscht werden können. Durch das TSI (Target System Interface) (siehe Grafik weiter unten) werden viele verschiedene Plattformen unterstützt

Architektur

Die nachfolgende Grafik verdeutlicht die Architektur von Unicore

Eine kurze Erklärung zu den einzelnen Elementen

• Client-Layer - hier sind die verschiedenen von Unicore angebotenen Clients zu finden (UCC, URC, HiLA; siehe unten)
• Service-Layer - enthält die gesamten Komponenten und Logik von Unicore
  • Gateway: Kann als “Tor zur Außenwelt” verstanden werden. Es authentifiziert alle eingehenden Anfragen und leitet diese ggf. weiter, agiert also als eine Art Firewall, wobei die wichtigste Funktion die Hauptansprechstelle ist. Entsprechend der Architektur (siehe Grafik) können hinter einem Gateway beliebig viele Ressourcen (Target Systems) liegen
  • XJNS: ist die Job-Management und -Ausführungs-Engine von Unicore und kann als Herzstück einer Unicore 6 Anwendung betrachtet werden. Es bietet Speicher-Ressoucen und Datei-Transfer- sowie Job-Management-Services. Wie in der Grafik zu sehen ist es über zwei Interfaces (Atomic Services, OGSA-*) zu erreichen
    • IDB (Incarnation Database): mapping der abstrakten Job-Definitionen in JSDL in konkrete Job-Beschreibungen für spezifische Ressourcen. Die Einträge werden dabei im XML-Format gespeichert (siehe Anmerkung 1)
    • XUUDB: Enthält die Anwender der XJNS und deren zugehörige Logins, Rollen und X.509-Zertifikate. Da die XUUDB ein eigenständiger WebService ist, kann sie von mehreren Unicore-Installationen verwendet werden
    • UVOS: Alternativ zu XUUDB kann auch UVOS, ein WebService für Virtuelle Organisationen und damit Authorisierung, verwendet werden. UVOS verwendet den SAML-Standard
  • XJNS-Interfaces
    • Atomic Services: das Unicore-proprietäre Interface zur XJNS
    • OGSA-*: Als Alternative zu Atomic Services gibt es einen Satz an standardisierten Interfaces, die auf offenen, verbreiteten Standards wie OGSA-* basieren. Diese können für die Erzeugung, Überwachung und Kontrolle von Jobs verwendet werden (z.B. OGSA-BES oder HPC-P)
  • Service-Registry: Ähnlich wie die UDDI bei WebServices verwaltet auch hier die Service-Registry alle vorhandenen Services, die sich bei der Registry registrieren können, um gefunden zu werden.
  • CIS: ist der Information Service von Unicore 6 und sammelt Informationen über alle verbundenen XNJS. Dabei basiert das CIS auf GLUE 2 und ist – ebenso wie die Service Registry – essentiell für den operationalen Betrieb von Unicore
  • Workflow-Unterstützung (optional): Workflows (siehe unten) werden bei Unicore 6 in einer zwei-Schichten-Architektur unterstützt: der Workflow-Engine-Schicht und der Service-”Dirigenten”-Schicht. Dadurch kann die Workflow-Engine leicht ausgetauscht oder unterschiedliche Workflow-Beschreibungs-Sprachen können verwendet werden.
    • Workflow-Engine: Die aktuelle Workflow-Engine basiert auf Shark XPDL.
    • Service-Orchestrator (“Service-Dirigent”): Ist verantwortlich für Ausführung der einzelnen Jobs innerhalb eines Workflows und deren Überwachung im Grid. Dabei werden die jeweils am besten passenden Ressourcen pro Workflow-Schritt gefunden (hierfür sind verschiedene Strategien verwendbar).
• System-Layer - Enthält einzelne Ressourcen, Festplatten, Rechner, …
  • TSI: Übersetzt die abstrakten Befehle des Grids auf systemspezifische Befehle, z.B. llsubmit oder qsub. Das TSI kann für viele verschiedene lokale Systeme verwendet werden (siehe oben), wie z.B. verschiedene Batch-Systeme (Torque, LoadLeveler, LSF, SLURM, OpenCCS, …).
  • USpace: Ist ein separates “Unicore Job-Verzeichnis”. Für jeden Job existiert ein eigenes Verzeichnis, in das XNJS und TSI sowohl jegliche Input-Daten als auch die Ausgabe wie stdout oder stderr schreiben. Ein USpace-Verzeichnis wird wieder aufgeräumt und freigegeben, sobald ein Job erledigt oder verfallen ist
  • Externe Speichermedien: Für den Datentransfer von/zu externen Speichermedien kann das GridFTP-Protokoll verwendet werden

Clients

In der Unicore-Beschreibung wird all das als Client definiert, womit man auf Ressourcen zugreifen und Grid-Jobs definieren kann: UCC (Commandline), URC (Rich Client, GUI), HiLA (API). Alle Clients können auf der Unicore Downloadseite heruntergeladen werden.

Ausprobieren kann man das ganze im Testgrid von Unicore. Dafür einen Testzugang anlegen und den gewünschten Client runterladen. In den beiden Video-Tutorials (1, 2) wird gezeigt, wie man den URC einrichtet und seinen ersten Job auf dem Grid laufen lassen kann.

UCC

Über den Unicore Commandline Client können alle Funktionen des Service-Layers (siehe Grafik) in einer Shell verwendet werden. Neben den üblichen Funktionen wir Job-Ausführung und Überwachung können sogar Workflows verwendet werden.

URC

Der Unicore Rich Client basiert auf dem Eclipse-Framework und bietet alle Funktionalitäten des Service-Layers in graphischer Form, also ein UI. Neben einer sehr detaillierten und umfassenden Verwaltung der zu verwendeten Grid-Ressourcen können auch die Jobs in der graphischen Oberfläche verwaltet und bearbeitet werden. Außerdem können Workflows (siehe unten) erstellt werden, was auch bei komplexen Strukturen übersichtlich bleibt. Durch die Verwendung von Eclipse als Basis ist der URC einfach erweiterbar, die Integration neuer Grid Services oder Anwendungen ist dabei bereits berücksichtigt.

Über GridBeans kann die URC nochmals erweitert werden, z.B. über die in einer GridBean definierten GUIs für die Bearbeitung der Input- und Output-Variablen des in der GridBean abstrahierten Grid-Jobs oder mittels Visualisierungen (Text, Bilder, 3D-Engine, …) der GridBean-Variablen.

HiLA

Als dritter Client-Typ wird HiLA angeboten, eine High Level API für Grid-Anwendungen. Mittels der HiLA können Clients für Grid-Anwendungen auf einfache Weise entwickelt und Unicore 6 in bestehende Anwendungen intergiert werden. So können Grid-Ressourcen direkt verwendet werden, ohne den Umweg über den UCC oder den URC gehen zu müssen. HiLA modelliert das Grid anhand eines objektorientierten Interfaces (von dem es mehrere Implementierungen gibt: Unicore 5, Unicore 6 und OGSA-BES), das eine abstrakte Repräsentation der darunterliegenden Ressourcen darstellt. Das Interface umfasst dabei die Objekte Grid, Site, Storage, Task und File, wobei all diese Objekte ein Locatable implementieren können. Ein Grid- und ein Site-Objekt können zusätzlich einSubmitable implementieren.

HiLA ist Ressourcen- statt Task-orientiert, wobei auf Ressourcen über URIs zugegriffen wird. Zum Erzeugen einer HiLA-Implementierung wird der Factory-Mechanismus verwendet. Eine ausführliche Erklärung der genannten Konzepte und Objekte ist in der Referenz zu finden!

Folgend ein Beispiel für die Verwendung der API (ebenfalls in der Referenz zu finden, Kapitel 5.3.4):

// Ein JSDL-Dokument parsen und ein Java-Objekt daraus generieren (Java-Binding)
JobDefinitionDocument jsdl = JobDefinitionDocument.Factory.parse(new java.io.File(this.args[1]));

// Verwendung der HiLA-Factory, um eine passende Site für die Job-Ausführung zu finden
Site site = HiLAFactory.getInstance().locate(new Location(args[0]));

// Das JSDL-Objekt an die gefundene Seite senden
Task task = site.submit(jsdl);

// Blockierendes Ausführen des Tasks
task.startSync();

Workflows

Über Workflows können auch komplexe Abläufe von einzelnen Jobs eingerichtet werden. Ein Workflow wird aus verschiedenen Systemaufrufen und Kontrollstrukturen zusammengestellt. Dabei werden folgende Funktionen unterstützt: parallele oder sequentielle Job-Ausführung, Schleifen (while, foreach), Kontrollstrukturen (if-then-else) und Workflow-Variablen.

Die Workflows werden im URC graphenbasiert bearbeitet, können aber auch über den UCC verwendet werden. Über gerichtete Kanten wird dabei die Abarbeitungsreihenfolge definiert. Der fertige Workflow kann dann an ein Grid-System übertragen und dort ausgeführt werden. An jeder Entität, die ausgeführt wurde, wird ein Häkchen angezeigt.

Innerhalb eines Workflows können neben “einfachen” Job-Definitionen auch verschiedene GridBeans verwendet werden.

Der Schwerpunkt bei der Entwicklung der Workflow-Unterstützung lag auf den vier Bereichen Flexibilität, Skalierbarkeit, Erweiterbarkeit und einfacher Anwendung.

Anmerkungen

Anmerkung 1

Ein Beispiel für einen IDB-Eintrag zeigt folgender Node, der die Anwendung “Date” auf “/bin/date” mappt:

<idb:IDBApplication>
   <idb:ApplicationName>Date</idb:ApplicationName>
   <idb:ApplicationVersion>1.0</idb:ApplicationVersion>
   <jsdl:POSIXApplication xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix">
      <jsdl:Executable>/bin/date</jsdl:Executable>
   </jsdl:POSIXApplication>
</idb:IDBApplication>

Eine Erklärung zur Syntax und den möglichen Node-Typen ist hier zu finden.

Quellen

• www.unicore.eu
• www.unicore.eu/documentation/files/PressKit.pdf
• sourceforge.net/apps/mediawiki/unicore/index.php?title=FAQ
• www.unicore.eu/documentation/files/UNICORE-Slides-Web.pdf
• www.unicore.eu/documentation/presentations/unicore6/files/2010-03-23_Unicore6-Tutorium.pdf
• www.unicore.eu/community/development/hila-reference.pdf