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)