Erweiterung der D-Grid Basis für die kommerzielle Nutzung · Erweiterung der D-Grid Basis für die...

18
Erweiterung der D-Grid Basis für die kommerzielle Nutzung Konzept Koordination Andreas Eberhart ([email protected]) Datum 31. Juli 2010 Version 1.0 Status Entwurf Referenz http://www.fluidops.com/projects.html

Transcript of Erweiterung der D-Grid Basis für die kommerzielle Nutzung · Erweiterung der D-Grid Basis für die...

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Konzept

Koordination

Andreas Eberhart ([email protected])

Datum 31. Juli 2010

Version 1.0

Status Entwurf

Referenz http://www.fluidops.com/projects.html

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 2 von 18

Autoren:

Andreas Eberhart (fluid Operations GmbH)

Stefan Freitag (Technische Universität Dortmund)

Marcel Risch (fluid Operations GmbH)

Das diesem Bericht zugrunde liegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bil-

dung und Forschung unter dem Förderkennzeichen 01IS10019B gefördert. Die Verantwortung für

den Inhalt dieser Veröffentlichung liegt bei den Autoren.

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 3 von 18

Inhaltsverzeichnis Vorbemerkung ......................................................................................................................................... 4

Zielsetzung des Projekts .......................................................................................................................... 4

Verfolgter technischer Ansatz ................................................................................................................. 4

Nutzerverwaltung ................................................................................................................................ 6

Bezug der D-Grid Nutzerinformationen .............................................................................................. 7

Bezug aus dem VOMS Server bzw. VOMRS ..................................................................................... 7

Bezug über das dgridmap Skript...................................................................................................... 8

Handhabung D-Grid-fremder Kunden ............................................................................................. 9

Abbildung der Grid Nutzer auf lokale Nutzerkonten ...................................................................... 9

Anforderungen an die Umsetzung der Nutzerverwaltung ............................................................ 10

Zugriff auf die virtuellen Maschinen für D-Grid und externe Kunden .............................................. 10

Linux-basierte Distributionen ........................................................................................................ 10

Microsoft Windows-basierte Distributionen ................................................................................. 11

Accounting ......................................................................................................................................... 11

DGAS Architektur für Compute Elemente ..................................................................................... 11

Monitoring ..................................................................................................................................... 12

Informationssystem ....................................................................................................................... 12

Interaktion mit dem Grid Batchsystem ............................................................................................. 13

Einlagerung der Appliances ............................................................................................................... 15

Anforderungskatalog an das D-Grid Integrationsprojekt .................................................................. 15

Abkürzungsverzeichnis .......................................................................................................................... 17

Literaturverzeichnis ............................................................................................................................... 18

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 4 von 18

Vorbemerkung Das vorgestellte Konzept ist als Proof-of-Concept zu verstehen. Insbesondere wurden bei der

Konzepterstellung sowohl rechtliche als auch politische Fragestellungen und Probleme

weitestgehend ausgeklammert.

Zielsetzung des Projekts Ein besonderes Merkmal von D-Grid ist die Unterstützung von derzeit drei Grid Middleware

Systemen (Globus Toolkit[1], gLite[2] und UNICORE[3]), die allesamt aus dem akademischen Umfeld

stammen. Seitens D-Grid entwarf man dazu ein Betriebskonzept[4], welches u. a. notwendige

Rahmenbedingungen für den parallelen Betrieb dieser drei Middlewares auf einer Ressource

beschreibt. Eine prototypische Implementierung einer mit dem Betriebskonzept konformen

Ressource steht mit der D-Grid Referenz-Installation[5] zur Verfügung.

Die IT-Landschaft hat sich seit der Gründungszeit von D-Grid im Jahr 2005 besonders durch die

Verbreitung von Cloud Computing verändert. Obwohl Grid und Cloud Computing auf einer ähnlichen

Strategie der Benutzung externer IT-Dienste und Ressourcen basieren, gibt es bisher kaum

Berührungspunkte zwischen ihnen. Abstrakt gesehen entsprechen die Anwendercommunities im D-

Grid den Anbietern von Software as a Service (SaaS) beim Cloud Computing, während sich eine

ähnliche Beziehung zwischen den Ressourcenprovidern im D-Grid und dem Angebot von

Infrastructure as a Service (IaaS) beim Cloud Computing erkennen lässt. Ein wesentlicher Unterschied

zwischen Cloud und Grid Computing liegt in der Fokussierung des Kunden auf jeweils einen Anbieter

beim Cloud Computing, was zu einfachen Geschäftsmodellen und einer schnellen Umsetzung führt.

Im Gegensatz hierzu müssen beim Grid Computing unabhängige und teilweise im Wettbewerb

stehende Anbieter in das gleiche Geschäftsmodell eingebunden werden.

Der Aufschwung von Cloud Computing hat auch zu neuen Middlewaresystemen geführt, da

insbesondere die Anbieter von IaaS die akademischen Middlewaresysteme aus mehreren Gründen

für ihre Zwecke als ungeeignet hielten. Zu den Gründen gehört die bei Open Source-Software unklare

Supportfrage ebenso wie der Umgang mit und auch die Funktionalität der Systeme. Zurzeit hat sich

Elastic Compute Cloud (EC2) von Amazon als de facto Standard für IaaS im kommerziellen Umfeld

etabliert.

Das hier vorgeschlagene Projekt hat zum Ziel, die D-Grid Infrastrukturbasis um EC2 als vierte

Middlewaresäule zu ergänzen. Durch diese neue Säule wird die Nutzung der D-Grid Infrastruktur

durch ein breiteres Kundenspektrum, sowohl aus dem kommerziellen als auch dem akademischen

Bereich, ermöglicht und somit direkt die Nachhaltigkeit von D-Grid gestärkt.

Auf technischer Ebene ist die Integration einer EC2 Komponente in die existierende D-Grid

Infrastruktur äquivalent zu einer Erweiterung der D-Grid Referenz-Installation um diese Komponente.

Innerhalb des Projekts ist daher die prototypische Umsetzung der erzielten Ergebnisse auf eine an

der Technischen Universität Dortmund betriebene D-Grid Ressource vorgesehen.

Verfolgter technischer Ansatz Der Einsatz von Virtualisierungstechnologie ermöglicht es, ein physisches System zu partitionieren,

wodurch es z. B. gleichzeitig sowohl einen Grid Workernode als auch eine IaaS Ressource

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 5 von 18

bereitstellen kann. Technisch wird diese hybride Nutzung ermöglicht, indem verschiedene

Festplattenabbilder auf dem physischen System automatisiert gestartet werden. Dies ist

beispielsweise mittels eines Hypervisors oder auch mit Hilfe der "Boot from SAN" Technologie

möglich. Eines dieser Abbilder würde z. B. den Softwarestack eines D-Grid Workernode enthalten.

Dieses Abbild wird gestartet, wenn auf die Ressource D-Grid Jobs gerechnet werden sollen. Andere

Festplattenabbilder beinhalten Kundensysteme wie Webserver, Datenbanken oder einfach nur ein

leeres Betriebssystem. Diese werden für die Nutzung unter IaaS gestartet.

Diese technologische Basis muss für D-Grid sinnvoll orchestriert werden. Der eCloudManager

implementiert die IaaS Schnittstelle. Werden dem eCloudManager explizit Ressourcen zugeteilt ist

die Ausführung von IaaS Kundenanfragen relativ einfach. In der Interaktion mit D-Grid Ressourcen

müssen allerdings weitere Schritte realisiert werden, z. B.

1. Nutzerverwaltung: der eCloudManager muss D-Grid Nutzer authentifizieren können.

2. Ressourcenselektion: Das System muss vom IaaS Nutzer übermittelte Service Levels und

Angaben zur Nutzungsdauer mit den im Grid geplanten Jobs abgleichen. Aufgrund dieser

Information ist zu entscheiden wie bzw. ob eine Ressource verwendet werden kann.

Insbesondere bei der Ressourcenauswahl ist ein komplexes Vorgehen notwendig, da der eCloud

Manager nicht das alleinige Nutzungsrecht an den im Hintergrund verfügbaren Rechenressourcen

besitzt. Über Grid Middlewares an das lokale Ressourcenmanagement (LRMS) (vgl. Abbildung 1)

weitergeleitete Jobs werden auf denselben Ressourcen ausgeführt.

Ein Dienst soll die anfängliche Aufteilung und dynamische Neuverteilung der vorhandenen

Rechenressourcen in eine Cloud- und eine Grid-Partition koordinieren. In diesem Zusammenhang

benötigt der Dienst eine Schnittstelle, die mit möglichst vielen der gängigen LRMS (z. B. LSF[6], PBS[7]

und SGE[8]) kompatibel ist und mindestens die Operationen des Herausnehmens und Hinzufügens

von Workernodes unterstützt. Die andere Kommunikationsgegenstelle des Dienstes bildet der

eCloudManager. Hier bestehen die notwendigen Operationen aus dem Anhalten und Fortsetzen von

Virtual Appliances sowie deren Migration.

Die initiale Aufteilung der Rechenressourcen soll sowohl der Grid- als auch der Cloud-Partition

zunächst ausreichend Kapazitäten zusichern. In periodischen Abständen und in Abhängigkeit von der

Abbildung 1 Geplante Schichtenarchitektur einer D-Grid Grid & IaaS Ressource

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 6 von 18

Auslastung beider Partitionen kann die Verschiebung freier Kapazitäten von einer in die andere

Partition erfolgen, wobei über die Definition von Schwellwerten Grenzen definierbar sind.

In diesem Kontext ist zu evaluieren, inwieweit die Integration einer neuen EC2 Komponente in die

bisherige Dienste-Architektur des D-Grid erfolgen kann. Dazu sind im Einzelnen folgende

Themenbereiche zu betrachten:

Nutzerverwaltung

Das Zusammenspiel zwischen dem eCloudManager und den in D-Grid verwendeten

Mechanismen zur Nutzerautorisation und -authentifikation ist zu erarbeiten.

Accounting

Die über EC2 in Anspruch genommene Rechenleistung sollen über das Distributed Grid

Accounting System (DGAS) zum zentralen D-Grid Accounting Server publiziert werden.

Einlagerung von Virtual Appliances

Kunden benötigen Möglichkeiten zur persistenten Speicherung ihrer Virtual Appliances.

Informationssystem

Ein Adapter als Bindeglied zu D-MON, dem im D-Grid verwendeten Verfahren zur

Ressourcenüberwachung ist, ist konzeptionell zu erarbeiten. Mittels dieses Adapters werden

Informationen aus einer D-Grid IaaS Ressource ausgelesen, gebündelt und einer

strukturierten Darstellung zugeführt.

Monitoring

Integration in das D-Grid weite Ressourcenmonitoring mittels Nagios.

Für jeden der zuvor aufgeführten Punkte wird nachfolgend erläutert wie eine Integration des

eCloudManagers in D-Grid aussehen kann.

Nutzerverwaltung Das D-Grid bietet Communities aus verschiedensten Bereichen (z. B. der Teilchenphysik, Medizin,

Text- und Sozialwissenschaften) einen Zugang zu Rechen- und Speicherressourcen. Um einen Zugang

zu Ressourcen zu erhalten ist die Erzeugung und spätere Verwaltung einer oder mehrerer virtueller

Organisationen innerhalb einer Community notwendig.

In [9] ist eine virtuelle Organisation als „ein permanentes oder zeitlich begrenztes Konsortium

geographisch verteilter Individuen, Gruppen, Organisationseinheiten oder ganzer Organisationen […],

die Teile ihrer physischen oder logischen Ressourcen und Dienste, ihre Kenntnisse und Fähigkeiten

sowie Teile ihrer Informationsbasis derart zusammenlegen, dass die gemeinsamen Ziele erreicht

werden können.“ definiert. Diese Definition ist im Folgenden zu Grunde gelegt.

Neben einfachen Mitgliedern einer virtuellen Organisation lassen sich oftmals Rollen identifzieren

wie z. B.

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 7 von 18

ein oder mehrere Repräsentanten, welche über die Zulassung eines Mitgliedschafts-

anwärters zur virtuellen Organisation entscheiden

Administratoren, die die Verwaltung des VO Mangement Dienstes übernehmen

Des Weiteren lassen sich in virtuellen Organisationen auch Gruppen und Untergruppen (z. B. die

Menge aller Administratoren oder Mitglieder) definieren. Innerhalb der virtuellen Organisation sind

die verschiedenen Mitglieder durch den Distinguished Name des entsprechenden X.509

Nutzerzertifikats identifiziert.

Bezug der D-Grid Nutzerinformationen Für Communities gibt es mehrere Möglichkeiten der Verwaltung ihrer virtuellen Organisationen. Im

Kontext des D-Grid haben sich hierfür mit VOMS[10] und VOMRS[11] zwei Dienste durchgesetzt.

Aufgrund des Wunsches mehrerer D-Grid Ressourcenanbieter wird der VOMRS als Hauptwerkzeug

eingesetzt. Der VOMS Server, welcher durch das INFN und CERN entwickelt wurde, ist ebenso wie

VOMRS ein System, welches neben der Nutzerverwaltung z. B. zur Echtzeitautorisation für Mitglieder

einer virtuelle Organisation eingesetzt wird. Jedoch hält der VOMS Server nur eine minimale Menge

an Informationen über einen Nutzer vor, genauer genommen nur dessen Zertifikat. Im Gegensatz

hierzu ist der VOMRS Server in der Lage personenbezogene Daten (z. B. Anschrift des

Heimatinstitution, Telefonnummer, E-Mail) zu speichern, welche für viele Ressourcenanbieter aus

dem D-Grid eine minimale Menge zur Erfüllung ihrer lokalen Ressourcen-AUP (Acceptable Use Policy)

bilden.

Aus Kompatibilitätsgründen betreibt D-Grid neben den VOMRS Instanzen VOMS Instanzen, die von

Diensten der gLite Middleware kontaktiert werden. Die Synchronisation der Inhalte von VOMRS und

VOMS Server erfolgt täglich, wobei die Synchronisation stets in Richtung des VOMS Server

ausgeführt wird.

Bezug aus dem VOMS Server bzw. VOMRS

Der VOMS bzw. der VOMRS Server in Verbindung mit einem LCG oder CREAM Compute Element[12]

verwendet und setzt eine entsprechende Installation des VOMS Client Pakets (z. B. glite-security-

voms-clients-1.8.12-1.slc4) voraus. Des Weiteren wird für die Kommunikation mit dem VOMS Server

folgendes benötigt:

Festlegung der Ausgabedatei, z. B. /etc/grid-security/grid-mapfile

Pfad im Dateisystem zu den Zertifikaten der Certificate Authorities, z. B. /etc/grid-

security/certificates

Pfad im Dateisystem zum X.509 Hostzertifikat, z. B. /etc/grid-security/hostcert.pem

Pfad im Dateisystem zum privaten X.509 Schlüssel des Hosts, z. B. /etc/grid-

security/hostkey.pem

Kommandozeilenaufruf:

/opt/edg/sbin/edg-mkgridmap --output=/etc/grid-security/grid-mapfile.edg –safe

Nach der Ausführung des edg-mkgridmap Kommandos enthält die Datei /etc/grid-security/grid-

mapfile.edg Zeilen der Form

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 8 von 18

"Distinguished Name des D-Grid Nutzers" .lokale Nutzergruppe

"/C=DE/O=GermanGrid/OU=TU-Dortmund/CN=Vorname Nachname" .hp

bzw.

"Distinguished Name des D-Grid Nutzers" lokaler Nutzer

"/C=DE/O=GermanGrid/OU=TU-Dortmund/CN=Vorname Nachname" hp0045

Derzeit ist die Nutzung des VOMS bzw. VOMRS für die im D-Grid unterstützten Middlewares Globus

Toolkit und UNICORE nicht oder nur begrenzt möglich. In diesen Fällen kann auf das dgridmap

Skript[13] zurückgegriffen werden.

Bezug über das dgridmap Skript

Das dgridmap Skript erzeugt Ressourcen-spezifisch für die in D-Grid betriebenen Middlewares gLite,

Globus Toolkit und UNICORE notwendige Autorisierungsinformationen. Diese Informationen

inkludieren die Abbildung des Distinguished Name des X.509 D-Grid Nutzerzertifikats auf ein lokales

Nutzerkonto auf der Ressource. Dabei unterstützt das dgridmap Skript derzeit die Formate für

das grid-mapfile der Globus Toolkit Middleware (Option: -output-g)

das grid-mapfile, welches zudem Attribute enthält (Option: -output-g-attr)

eine Datei zur Erzeugung bzw. Aktualisierung der UNICORE5 User Database (UUDB) (Option: -

output-u)

eine Datei zur Erzeugung bzw. Aktualisierung der UNICORE6 User Database (XUUDB) (Option:

-output-xu)

die Mapping -Datei für OGSA-DAI (Option: -output-o)

wobei für den Einsatz mit dem eCloudManager insbesondere die Verwendung der bereits

existierenden Option -output-g-attr bzw. deren Ausgabe zu prüfen ist. Diese Option führt zu

Ausgaben der Gestalt

"<gruppe>/Role=<rolle>/Capability=NULL" .lokaleNutzergruppe

Hieran schließt sich der Output für das Mapping von Distinguished Names auf lokale Nutzerkonten

(analog zur Option -output-g) an.

Wünschenswert wäre eine Abbildung von dem Distinguished Namen des Nutzers UND dessen Rollen/

Attribute auf einen lokalen Nutzer. Dies scheint dgridmap, ebenso wie die anderen Dienste, nicht zu

realisieren.

dgridmap benötigt analog zum VOMS Client folgende Informationen:

Pfad im Dateisystem zu den Zertifikaten der Certificate Authorities, z. B. /etc/grid-

security/certificates

Pfad im Dateisystem zum X.509 Hostzertifikat, z. B. /etc/grid-security/hostcert.pem

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 9 von 18

Pfad im Dateisystem zum privaten X.509 Schlüssel des Hosts, z. B. /etc/grid-

security/hostkey.pem

Handhabung D-Grid-fremder Kunden

Das Projekt hat das Ziel die Nutzung der D-Grid Ressourcen für externe Kunden wie KMUs einfach

und attraktiv zu gestalten. Diese Kunden sollen möglichst dynamisch Rechen- bzw. später auch

Speicherressourcen zur Verfügung gestellt werden. Dieser Dynamik steht die notwendige Zeit zur

Beantragung eines X.509 Nutzerzertifikats wie es im D-Grid gebraucht wird und der Beantragung der

Mitgliedschaft in einer virtuellen Organisation gegenüber. Um D-Grid überhaupt in eine

konkurrenzfähige Situation zu bringen, soll von der Eingabe der Kundendaten an einer D-Grid IaaS

Ressource bis hin zum möglichen Start der ersten virtuellen Maschine durch den Kunden nur wenige

Minuten vergehen.

Die Erzielung der Dynamik ist durch verschiedene Vorgehen erreichbar, die nachfolgend beschrieben

sind:

die Registrierung eines Kunden an einer D-Grid IaaS Ressource

Das im Betriebskonzept des D-Grid beschriebene Verfahren zur Registrierung von Kunden (im

bisherigen D-Grid Kontext: Mitglieder von virtuellen Organisationen) sieht vor, dass diese sich

an einer zentralen Stelle wie dem VOMRS Server registrieren. In periodischen Abständen

synchronisieren die D-Grid Ressourcen ihre Nutzerinformationen mit den Informationen aus

dem Server. Der zeitliche Abstand zwischen zwei Synchronisierungsaufrufen liegt aber

mitunter bei einem Tag, was zu lange ist. Registriert sich der Kunde direkt an der D-Grid IaaS

Ressource, welche er verwenden möchte, kann über einen Automatismus im Hintergrund die

Nutzerverwaltung der Ressource unmittelbar aktualisiert werden. Nachteilhaft an dieser

Lösung ist die Notwendigkeit der erneuten Registrierung des Kunden an anderen D-Grid IaaS

Ressourcen.

die Anmeldung eines Kunden an einem Portal und die Nutzung von Robot-Zertifikaten

Der Einsatz von Roboterzertifikaten in Verbindung mit einem Portal bietet eine alternative

Lösungsmöglichkeit, die insbesondere die Mehrfach-Registrierung auf verschiedenen D-Grid

IaaS Ressourcen umgeht. Der Nutzer muss sich lediglich einmal am Portal registrieren um auf

alle D-Grid IaaS Ressourcen zugreifen zu können. Hierfür kommt das Robot-Zertifikat zum

Einsatz über das sich das Portal mit den verschiedenen Ressourcen in Verbindung setzt und

im Auftrag des Kunden Aktionen ausführt.

Dieser Lösung steht die nur unzureichende Akzeptanz von Robot-Zertifikaten seitens der

Ressourcenanbieter entgegen. Teilweise verstößt der Einsatz eines Robot-Zertifikats gegen

die Acceptable Use Policy der Ressource, da auf dieser nicht mehr unbedingt nachvollziehbar

ist, in wessen Auftrag das Robot-Zertifikat handelt.

Abbildung der Grid Nutzer auf lokale Nutzerkonten

Im D-Grid Betriebskonzept ist unter dem Punkt "IT-Sicherheit und Datenschutz" die eindeutige

Zuordnung eines Grid Nutzerzertifikats zu einem oder mehreren lokalen Nutzerkonten gefordert.

Eine Abbildung auf mehrere Nutzerkonten ist nur erlaubt, wenn diese zu paarweise

unterschiedlichen virtuellen Organisationen gehören.

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 10 von 18

Die Grid Nutzerinformationen erhält der eCloudManager wie vorher beschrieben über z. B. das

dgridmap Skript und generiert hieraus eine eineindeutige Abbildung auf lokale Nutzerkonten.

Informationen zu diesen Nutzerkonten können entweder in einer lokalen Datenbank oder externen

Authentifizierungsdiensten wie Active Directory oder LDAP abgelegt sein. Der eCloudManager besitzt

für beide Fälle entsprechende Schnittstellen.

Für die erste prototypische Implementierung kommt eine lokale Datenbank zum Einsatz. Das zu

verwendende Datenbankschema muss u. a. die Strukturierung der D-Grid Communities in virtuelle

Organisationen berücksichtigen.

Anforderungen an die Umsetzung der Nutzerverwaltung

In diesem Abschnitt sind die einzelnen Anforderungen bzw. notwendigen Erweiterungen des

eCloudManager ausgeführt, um eine nahtlose Integration der D-Grid Nutzer in die Nutzerverwaltung

der auf dem eCloudManager basierenden D-Grid IaaS Ressourcen zu ermöglichen.

Der eCloudManager von fluid Operations ist um mindestens einer der oben vorgestellten

Möglichkeiten zum Bezug von zur Nutzerinformationen (VOMS, VOMRS, dgridmap) zu

erweitern. Da das Betriebskonzept für die D-Grid Infrastruktur den Einsatz des dgridmap

Skripts zur Abholung der Nutzerinformationen empfiehlt, integriert der eCloudManager die

Abholung der Informationen über diese Schnittstelle. Dabei ergeben sich folgende zu

implementierende Unteraufgaben:

o Einsatz eines X.509 Hostzertifikats durch das sich der eCloudManager gegenüber

dem dgridmap (Server) authentifiziert.

o Installation der Zertifikate der Certificate Authorities

Die Zertifikate der verschiedenen Certificate Authorities sind gebündelt über die

EUGridPMA (European Policy Management Authority for Grid Authentication) zum

Download verfügbar. Ein Link auf das jeweils aktuelle Bündel ist

https://dist.eugridpma.info/distribution/igtf/current/.

o Tägliches Aktualisieren der Nutzerinformationen durch die Abfrage des dgridmap

Servers

Zugriff auf die virtuellen Maschinen für D-Grid und externe Kunden Angestrebt ist ein zu den am Markt befindlichen ähnliches Verfahren. Kunden haben hierbei die

Möglichkeit nach erfolgreicher Registrierung ein Schlüsselpaar bestehend aus einem öffentlichen und

einem privaten Schlüssel zu erzeugen. Der öffentliche Schlüssel ist z. B. durch den eCloudManager in

die vom Kunden erzeugten virtuellen Maschinen injizierbar. Abhängig von dem innerhalb der

virtuellen Maschine verwendeten Betriebssystems ist das Vorgehen für Linux-basierte und Microsoft

Windows-basierte Distributionen unterschiedlich.

Linux-basierte Distributionen

Im Fall von Linux-basierten Distributionen ist die Injektion des durch den Kunden hinterlegten

öffentlichen Schlüssels ohne weiteres möglich. Damit dem Kunden von außen eine Verbindung zu

seiner gestarteten virtuellen Maschine möglich ist, muss innerhalb der virtuellen Maschine ein ssh

Server aktiv sein. Des Weiteren ist der ssh Server für die Akzeptanz der Schlüssel-basierten

Autorisation vorzukonfigurieren.

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 11 von 18

Microsoft Windows-basierte Distributionen

Diese Distributionen verfügen nicht über einen vorinstallierten ssh Server. Für diesen Fall ist ein

alternatives Vorgehen geplant bei dem der Kunde nach Provisionierung seiner virtuellen Maschine

eine E-Mail erhält, die Informationen zu einem eingerichteten Nutzerkonto, ein randomisiertes

Passwort und weitere Zugangsinformationen (z. B. IP Adresse der virtuellen Maschine) enthält.

Accounting Die über D-Grid IaaS Schnittstelle in Anspruch genommene Rechenleistung ist über DGAS zum

zentralen D-Grid Accounting Server ref-dgas.d-grid.uni-hannover.de zu publizieren.

Bei Compute Clouds sind verschiedene Größen für eine Instanz einer virtuellen Maschine messbar:

die verbrauchten/ reservierten CPU-Stunden

der während der Ausführung verbrauchte Hauptspeicher. Hier sind sowohl Mittel- als auch

Spitzenwert von Interesse.

der von der virtuellen Maschine belegte Speicherplatz

die Menge der während der Ausführung über das Netzwerk ein- bzw. ausgelagerten Daten.

Momentan wird im D-Grid nur das Accounting von CPU-Stunden unterstützt. Der zu erstellende

Prototyp orientiert sich hieran, d. h. es werden vorerst nur die vom Kunden verbrauchten/

reservierten CPU-Stunden sowie der während der Ausführung der virtuellen Maschine reservierte

Speicher festgehalten.

Diese bilden die Grundlage für eine Lastinformation. Diese Lastinformation ist in das in DGAS [14]

verwendete Format umzuwandeln und dem DGAS Server zu übermitteln.

DGAS Architektur für Compute Elemente

DGAS setzt auf den Compute Elementen sogenannte Sensoren ein, welche im Wesentlichen aus zwei

Diensten bestehen:

1. glite-urcollector. Der urcollector (usage record collector) stellt für jeden einzelnen auf dem

Compute Element ausgeführten Job die Accountinginformationen zusammen. Diese

bestehen aus zwei Teilen: i) Informationen aus dem Grid Job Management und ii) aus dem

lokalen Ressourcenmanagementsystem (LRMS). Letztere erhält der urcollector durch

periodisches Auswerten der Accounting log files des LRMS. Ein Teil der gewonnenen

Information ist die Job ID über die der Job im Grid Job Management identifiziert und der

zweite Teil der Informationen gewonnen werden kann. Die beiden Informationsteile werden

anschließend zusammengeführt und lokal in eine Datei im URBox Verzeichnis gespeichert.

2. glite-dgas-pushd. Der glite-dgas-pushd untersucht periodisch den Inhalt des URBox

Verzeichnisses. Liegen dort Dateien, so werden diese nach und nach mittels des Kommandos

glite-dgas-atm-client an den HLRMon über eine gesicherte Verbindung übertragen. Teilweise

werden vor der Übertragung noch Compute-Element-spezifische Informationen zum UR

hinzugefügt.

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 12 von 18

Für die DGAS Software Installation sind durch das DGI Fachgebiet 5.2 drei Möglichkeiten

vorgeschlagen:

Ist ein gLite Compute Element als Dienst auf der D-Grid Ressource installiert, können die von

gLite als RPM bereitgestellten DGAS-Client Pakete benutzt werden.

Enthält die D-Grid Ressource kein gLite Compute Element, sondern nur ein Batchsystem wie

Platform LSF oder Torque sowie andere Grid Middlewares, dann kann eine Standalone

Version des DGAS Client installiert werden.

Liegt ein anderes Batchsystem (z. B. SGE oder LoadLeveler) vor oder ist ein eigenes

Accounting ist vorhanden, dann wäre ebenso der Standalone DGAS-Client nutzbar.

Jede dieser Varianten setzt zumindest die Existenz eines Batchsystems sowie ein Linux

Betriebssystem voraus, die in unserem beschriebenen Szenario nicht unbedingt gegeben ist. Daher

ist die Eignung des auf Java-basierten DGAS Enterprise Edition Prototyps (http://www.rrzn.uni-

hannover.de/d-grid_accounting.html) zu evaluieren. Ebenso sind eigene Sensoren und Adapter zu

definieren und implementieren, die aus den Nutzungsinformationen des eCloud Managers OGF-

konforme Usage Records[15] erzeugen.

Der zu implementierene Prototyp soll Kunden Templates für virtuelle Maschinen zur Verfügung

stellen, die so grob in die Kategorien Small, Medium, Large und ExtraLarge einteilbar sind. Diese

Unterteilung liefert gleichzeitig einen Hinweis auf die Anzahl an bereitgestellten Ressourcen wie z. B.

die Anzahl der CPU Kerne, die Menge an Hauptspeicher und den maximal verfügbaren

Festplattenplatz. Neben dieser Information ist noch die Nutzungsdauer der Ressourcen an DGAs zu

übertragen.

Monitoring

Im D-Grid existieren in den verschiedenen Communities Bestrebungen eine Ressourcenüberwachung

mittels eines Monitoringwerkzeugs zu betreiben. Diese Anstrengungen werden in einem vom D-Grid

Integrationsprojekt angestrebten D-Grid weiten und ressourcenübergreifenden Monitorings

gebündelt. Bis dato gibt es im Integrationsprojekt jedoch keine Festlegung auf ein bestimmtes

Werkzeug, es haben sich allerdings zwei Kandidaten kristallisiert. Auf der einen Seite ist dies

INCA[16], welches bereits in DEISA eingesetzt wird, und auf der anderen Seite ist es Nagios[17],

welches in EGI SAM ablösen und als regionales Monitoring Werkzeug zum Einsatz kommen soll.

Das Monitoring führen Mitglieder der virtuellen Organisation dgOps durch, weshalb die

Unterstützung dieser Organisation auf einer D-Grid IaaS empfohlen wird. Ziel des Monitorings ist die

Feststellung der Erreichbarkeit und der Funktionalität des EC2 Endpunktes um so eine hohe

Dienstgüte zu gewährleisten.

Informationssystem

Das konzeptionelle Vorgehen zur Integration der entstehenden Lösung in D-MON, welches das im D-

Grid verwendete Portal zur Darstellung von Ressourceinformationen ist, er läutert dieser Abschnitt.

Für jede der von D-Grid unterstützten Grid Middlewares verfügt D-MON über einen Adapter. Mittels

dieses Adapters werden die Informationen aus den unterschiedlichen Grid Middleware

Informationssystemen wie gLite siteBDII, UNICORE CIS oder Globus Toolkit MDS ausgelesen,

gebündelt und strukturiert dargestellt.

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 13 von 18

Bisherige kommerzielle Cloud Middlewares verfügen über kein von außen zugängliches

Informationssystem. Im eCloudManager sind somit eine neue Schnittstelle sowie deren Spezifikation

basierend auf den D-MON Vorgaben einzurichten.

Zunächst ist zu evaluieren, welche Größen der eCloudManager intern überwacht bzw.

welche Größen von der Virtualisierungssoftware bereitgestellt werden, z. B. Anzahl und

Zustand der physischen Systeme, Anzahl und Zustand der laufenden virtuellen Maschinen,

freie Kapazitäten oder vorhandene Templates virtueller Maschinen.

Implementierung des Datenmigrationsprozesses in Form der drei Schritte

o Data Extraktion: Extraktion der Daten aus dem eCloudManager bzw. aus den an den

eCloudManager angeschlossenen Systemen. In Anlehnung an das bisherige Vorgehen

bei D-MON sollen die extrahierten Informationen am Ende als XML Datei vorliegen.

o Data Transformation: Transformation des Informationsmodells des eCloudManagers

in das GLUE2.0 Modell[18]. Die Transformationen der siteBDII, CIS und MDS

Informationen sind bei D-MON als XSL-Transformationen realisiert, deren

Endprodukt eine SQL-Datei ist, welche Statements zum Einfügen der Informationen

aus den erzeugten GLUE2.0 Tabellen in die Datenbank enthält.

o Data Upload: Upload der transformierten Daten in die D-MON Datenbank. Über

einen SQL Client werden die Statements in die zentrale Datenbank geladen

Der Upload der transformierten Daten geschieht in D-MON selbst, d. h. es müssen lediglich

Möglichkeiten zur Extraktion, Transformation und zur Erzeugung der SQL Datei geschaffen werden.

Interaktion mit dem Grid Batchsystem Zur Unterstützung einer dynamischen Zuteilung der freien Rechenkapazität an die Grid- bzw. die

Cloud-Komponente ist ein Informationsdienst notwendig, der die aktuellen Auslastungszustände

beider Teilsysteme kennt. Basierend auf diesen Informationen übernimmt der Dienst die

Ansteuerung des eCloudManagers, der somit bedarfsabhängig Virtual Appliances (Grid bzw. Cloud)

startet, suspendiert oder stoppt.

Da sich die Virtual Appliances für das Grid aus Sicht des eCloudManagers nicht von anderen IaaS

Workloads unterscheiden, sind im eCloudManager selbst keine Änderungen notwendig. Jedoch ist

ein eCloudManager Klient als Teil des zentralen Dienstes zu implementieren.

Im Batchsystem selbst sind eine Menge von Worker Nodes angemeldet und verschiedenen Queues

zugeteilt. Durch das Entfernen oder Hinzufügen von Worker Nodes zum Batchsystem ändert sich die

höchstens die maximale Anzahl gleichzeitig ausführbarer Jobs. Über einen Schwellwert soll die

minimale Anzahl an verfügbaren Workernodes einstellbar sein.

Der Informationsdienst kann auf verschiedene Weisen Informationen über die Auslastung bzw. den

aktuellen Zustand des Batchsystems erhalten:

Abfrage des Batchsystem Servers

Der Zustand eines Batchsystems ist über entsprechende Client Software abfragbar. Im Fall des in

der D-Grid Referenz-Installation vorgeschlagenen Batchsystems Torque ist dies z. B. mittels des

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 14 von 18

Kommandos qstat möglich. qstat -x hat eine im XML-Format gehaltene Ausgabe wie sie

nachfolgend für einen Job exemplarisch dargestellt ist:

<Job>534154.udo-torque01.grid.tu-dortmund.de

<Job_Name>STDIN</Job_Name>

<Job_Owner>[email protected]</Job_Owner>

<resources_used>00:00:00</resources_used>

<resources_used>4052kb</resources_used>

<resources_used>20912kb</resources_used>

<resources_used>02:52:51</resources_used>

<job_state>R</job_state>

<queue>ops</queue>

<server>udo-torque01.grid.tu-dortmund.de</server>

<Checkpoint>u</Checkpoint>

<ctime>1278495048</ctime>

<Error_Path>udo-ce01.grid.tu-dortmund.de:/home/ops/opssgm/.globus/job/udo-

ce01.grid.tu-dortmund.de/1108.1278495042/stderr</Error_Path>

<exec_host>udo-wn012.grid.tu-dortmund.de/1</exec_host>

<Hold_Types>n</Hold_Types>

<Join_Path>n</Join_Path>

<Keep_Files>n</Keep_Files>

<Mail_Points>n</Mail_Points>

<mtime>1278495049</mtime>

<Output_Path>udo-ce01.grid.tu-dortmund.de:/home/ops/opssgm/.globus/job/udo-

ce01.grid.tu-dortmund.de/1108.1278495042/stdout</Output_Path>

<Priority>0</Priority>

<qtime>1278495048</qtime>

<Rerunable>True</Rerunable>

<Resource_List>48:00:00</Resource_List>

<Resource_List>1</Resource_List>

<Resource_List>1</Resource_List>

<Resource_List>72:00:00</Resource_List>

<session_id>738</session_id>

<Shell_Path_List>/bin/sh</Shell_Path_List>

<etime>1278495048</etime>

</Job>

Anhand der beiden tags <job_state> und <queue> ist nachvollziehbar, wie viele Jobs in

welchen Queues zur Ausführung warten. Ist die Anzahl an queued Jobs groß und in der Cloud-

Komponente noch freie Ressourcen verfügbar, so werden Worker nodes gestartet. Ein Nachteil

dieser Lösung besteht darin, dass kein Batchsystem Client für Microsoft Windows existiert.

Abfragen eines Informationssystems der D-Grid Ressource

Abhängig von der installierten Grid Middleware unterstützt eine D-Grid Ressource verschiedene

Informationssysteme. Im Einzelnen ist dies

MDS für die Globus Toolkit Middleware

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 15 von 18

BDII für die gLite Middleware

CIS für die UNICORE Middleware

Der zu entwerfende Dienst könnte einen der lokalen Informationsdienste anfragen und hieraus

Informationen über den Füllstand des Batchsystems erhalten; BDII und MDS bieten hierzu die

Möglichkeit, CIS vermutlich nicht.

Abfragen des zentralen Informationssystems D-MON

Anstatt wie gerade vorgestellt einen lokalen Informationsdienst abzufragen, ist die auch die

Abfrage des Füllstandes über das zentrale D-MON Portal1 möglich.

Je weiter man in dieser vorgestellten Hierarchie (Batchsystem, lokales Informationssystem, zentrales

D-Grid Informationssystem) nach oben steigt, desto veralteter sind die dort vorliegenden

Informationen, da diese langsam von unten nach oben propagiert werden. Daher ist es geplant mit

dem lokalen LRMS zu kommunizieren und von dort die notwendigen Informationen zu beziehen.

Einlagerung der Appliances Die Kunden benötigen Möglichkeiten zur persistenten Speicherung ihrer Virtual Appliances. Daher ist

zu evaluieren, ob sich für diese Aufgabe ein D-Grid Storage Element eignet und ob die damit

erzielbare Performanz ausreichend ist. Neben der Verwendung eines Storage Elements soll das

Design auch eine spätere Nutzung von S3 vorsehen.

Generell sollte hierbei ein Nutzerkonzept abgebildet werden, dass es zumindest erlaubt Appliances

als privat bzw. öffentlich zu markieren. Erstere sind nur für den Benutzer zugänglich, der die

Appliances erstellt hat; letztere sind für alle D-Grid Nutzer sichtbar. Alternativ ist auch ein

Gruppen/Rollen Konzept denkbar, in dem die Zugriffrechte auf Appliances über

Gruppenzugehörigkeit oder über die Rollenzugehörigkeit gesteuert werden kann.

Als Schnittstelle zum Hochladen von eigenen Appliances kann eine S3-kompatible Schnittstelle

entwickelt werden. Über diese Schnittstelle können dann Appliances in verschiedenen Formaten (z.B.

Xen, VMware, etc.) hochgeladen werden.

Die Replikation zwischen diversen Standorten wird derzeit nicht unterstützt. Allerdings kann eine

Replication zwischen Storage Arrays am selben Standort erfolgen, was allerdings relativ langsam ist.

Anforderungskatalog an das D-Grid Integrationsprojekt Eine derzeit schon absehbare Anforderung an das D-Grid Integrationsprojekt betrifft die Erweiterung

des D-Grid Grid Ressource Registration Service (GRRS).

Systeme, die eine EC2-Schnittstelle anbieten, müssen sich ebenso wie andere in D-Grid Ressourcen

im GRRS registrieren können. Im Rahmen des Registrierungsprozesses ist vom Betreiber der EC2-

Ressource folgendes bereitzustellen:

1 http://vo-mon.lrz-muenchen.de:8080/gridsphere/gridsphere

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 16 von 18

Ein gültiges und akkreditiertes X.509 Nutzerzertifikat des Systemadministrators, welches für

den Anmeldeprozess am GRRS in dessen Webbrowser importiert sein muss

der Distinguished Name des Hostzertifikats der EC2-Ressource

Eine in HTML gehaltene Ressourcenbeschreibung in Form einer Datei ist im Vorfeld zu

erstellen. Die Beschreibung soll die wesentlichen Eckdaten der Ressource enthalten (z. B. Art

und Anzahl der logischen bzw. physischen CPUs, die Anzahl der Knoten, Speicher)

Ebenso müssen Regeln für die Einbindung neuer D-Grid Standorte als D-Grid IaaS Ressourcen

definiert werden. Nachfolgend sind bereits erste Vorschläge aufgeführt:

1. Anmeldung des EC2- Endpunktes beim D-Grid GRRS

2. Akzeptanz von Kunden eines externen Dienstleisters, z. B. eines Portals (optional)

3. Integration in das D-Grid Accounting mittels DGAS. Dies ist notwendig für das Billing.

4. Weiterleitung der Accountinginformation an externen Dienstleister (optional)

5. Die Wahl der verwendeten EC2-Lösung (z. B. eCloud Manager, OpenNebula2, Eucalyptus3) auf

der Ressource bleibt dem Ressourcenbetreiber überlassen.

6. Definition eines minimal Set von Schnittstellen, die der Ressourcenbetreiber anbieten muss.

2 http://www.opennebula.org/

3 http://www.eucalyptus.com/

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 17 von 18

Abkürzungsverzeichnis AUP Acceptable Use Policy

BDII Berkeley Database Information Index

CERN Europäische Organisation für Kernforschung

CIS Common Information Service

DGAS Distributed Grid Accounting System

DGI D-Grid Integrationprojekt

EC2 Elastic Compute Cloud

EUGridPMA European Policy Management Authority for Grid Authentication

GLUE Grid Laboratory Uniform Environment

GRRS Grid Ressource Registration Service

IaaS Infrastructure as a Service

INFN Istituto Nazionale di Fisica Nucleare

LRMS Local Resource Management System

MDS Monitoring and Discovery System

NGI-DE National Grid Initiative – Deutschland

OGF Open Grid Forum

OGSA-DAI Open Grid Services Architecture Data Access and Integration

SaaS Software as a Service

SAN Storage Area Network

UUDB UNICORE User Database

VOMS Virtual Organization Membership Service

VOMRS Virtual Organization Membership Registration Service

XSL Extensible Stylesheet Language

Erweiterung der D-Grid Basis für die kommerzielle Nutzung

Seite 18 von 18

Literaturverzeichnis

1. Globus Toolkit Homepage, http://www.globus.org/toolkit/ 2. gLite Homepage, http://glite.web.cern.ch/glite/ 3. UNICORE Homepage, http://unicore.eu/ 4. Büchner, O., Dohmen, C., Eifert, T., Enke, H., Fieseler, T., Frank, A., Freitag, S., Garcia, A., Grimm,

C. and Gürich, W., et al.: Betriebskonzept für die D-Grid Infrastruktur, http://www.d-grid.de/uploads/media/D-Grid-Betriebskonzept.pdf

5. D-Grid Referenz-Installation Wiki, http://dgiref.d-grid.de/wiki/Introduction 6. Platform LSF Homepage, http://www.platform.com/workload-management/high-performance-

computing/lp 7. Torque Homepage, http://www.clusterresources.com/pages/products/torque-resource-

manager.php 8. Sun GridEngine Homepage, http://gridengine.sunsource.net 9. J. M. Milke, M. Schiffers, Ziegler, W.: Rahmenkonzept für das Management Virtueller

Organisationen im D-Grid Version 1.1 (2007) 10. Alfieri, R.: VOMS, an Authorization System for Virtual Organizations. Lecture notes in computer

science, No. 2970 (2004),33-40 (2004) 11. VOMRS Guide. Version 1.3 12. Aiftimiei, C., Sgaravatto, M., Zangrando, L., Traldi, S., Andreetto, P., Bertocco, S., Dalla Fina, S.,

Dorigo, A., Frizziero, E., Gianelle, A., et al.: Design and implementation of the gLite CREAM job management service. Future Generation Computer Systems 26, 654–667 (2010)

13. dgridmap Homepage, http://www.d-grid.de/index.php?id=335 14. Guarise, A.: DGAS Reference Manual. V 0.5.8 15. Mach, R., Lepro-Metz, R. and Jackson, S.: Usage Record – Format Recommendation,

http://www.ogf.org/documents/GFD.98.pdf 16. INCA Homepage, http://inca.sdsc.edu/drupal/ 17. Nagios Homepage, http://www.nagios.org/ 18. Andreozzi, S., Burke, S., Ehm, F., Field, L., Galang, G., Konya, B., Litmaath, M., Millar, P., Navarro,

J.: GLUE Specification v 2.0 (2009)