Download:
Statusbericht über die Kern-Grid-Infrastruktur 02/09

05. Februar 2010

 

Dieser Fortsetzungsbericht basiert auf dem dritten Statusbericht über die Kern-Grid-Infrastruktur vom 07. August 2009. Informationen aus den vorherigen Berichten (1) (2) werden nur wiederholt, wenn sich in diesem Bereich etwas geändert hat.

1. Fachgebiet 1

Die durch Fachgebiet 1 derzeitig betreuten und zur Verfügung gestellten Versionen der Middleware-Komponenten sind in Tabelle 1 dargestellt.


Middleware

Versionen

UNICORE

5 und 6.2

gLite

3.1

Globus Toolkit

4.0.7 und 4.2

GAT/SAGA

GAT

Tabelle 1: Durch Fachgebiet 1 betreute Middlewarekomponenten


Die Referenzinstallation (3) läuft auf aus Sonderinvestitionen beschaffter Hardware am Forschungszentrum Karlsruhe und ist unter http://dgiref.d-grid.de/ detailliert dokumentiert. Aktualisierungen der Referenzinstallation werden halbjährlich in Abstimmung mit dem D-Grid TAB vorgenommen. Die Aufgaben des TAB sowie Sitzungsprotokolle sind unter http://www.d-grid.de/tab/ zu finden.
Die Ansprechpartner für den Support bei Communities und Kompetenzzentren sind in der SuKo gebündelt und treffen sich halbjährlich in Karlsruhe (http://dgiwiki.d-grid.de/dgi/SuKo). Das D-Grid User Support Portal wurde basierend auf diesen Treffen weiterentwickelt und ist über http://dgus.d-grid.de/ zugreifbar.
Neben den internen Workshops und der SuKo wurde im November 2009 zum zweiten Mal ein gemeinsamer Workshop mit Fachgebiet 1 und 2 veranstaltet, der die Abstimmung zwischen den Fachgebieten verbessert.

2. Fachgebiet 2

Betrieb der VO- und Nutzerdienste im D-Grid

Die VO- und Nutzerdienste wurden am FZJ betrieben, insbesondere wurde für jede unterstützte VO ein VOMRS-Server betrieben und gewartet. Um neue Konfigurationen und neue Softwareversionen außerhalb der Produktionsumgebung testen zu können, wurde eine zweite virtuelle Maschine als VOMRS-Server betrieben und aktualisiert. Die VOs wurden im Umgang mit VOMRS unterstützt, insbesondere bei der Änderung der VOMRS-Einträge zu Nutzer-Zertifikaten und bei der Verlängerung von Zertifikaten. Ein erheblicher Mehraufwand entstand durch die Unterstützung der Nutzer, deren von der alten DFN-CA "DFN-Verein User CA Grid - G01 " ausgestellte Zertifikate durch Zertifikate der neuen DFN-CA "DFN-Verein PCA Grid – G01" ersetzt wurden, da das Root-Zertifikat der CA "DFN-Verein User CA Grid - G01" am 07.07.2009 ablief. Die neuen VOs dgsi für das Gap-Projekte DGSI (D-Grid Scheduler Interoperability), valuegrids für das Call 3 Projekt ValueGrids, gapslc für das Gap-Projekt Gap-SLC sowie interloggrid zur Unterstützung des Call-3-Projektes InterLogGrid wurden eingerichtet. Außerdem wurden Untergruppen zu VOs eingerichtet und neue Repräsentanten zugelassen. DGUS-Tickets zu VOMRS wurden bearbeitet und gelöst. Es wurden Konfigurationsarbeiten und Tests zur Synchronisation des neuen VOMS-Servers am KIT durch die VOMRS-Server am FZJ durchgeführt und der Betrieb auf die Synchronisation des neuen Servers umgestellt. Die Grid-Server-Zertifikate auf den VOMRS-Servern vomrs.zam.kfa-juelich.de und vomrs2.zam.kfa-juelich.de wurden erneuert.
Weiter wurden Arbeiten zur Umstellung der Web-Schnittstelle des VOMRS Testsystems vomrs2.zam.kfa-juelich.de und des Produktionssystems vomrs.zam.kfa-juelich.de von DFN-Server-Zertifikaten der Hierarchie "Grid" auf DFN-Server-Zertifikate der Hierarchie "Global" vorgenommen. Diese Arbeiten wurden aufgrund der Anforderungen einzelner VOs (pneumogrid) durchgeführt, für deren Nutzer die Akzeptanz des DFN Root-Zertifikates der Hierarchie "Grid" im Browser eine große Hürde darstellt. Nach der Umstellung auf Global-Zertifikate bekamen Nutzer immer noch Sicherheitswarnungen vom Browser, weil den CAs "FZJ Certification Authority - G02" und "DFN-Verein PCA Global - G01" der Zertifizierungskette der Global-Zertifikate nicht vertraut wurde. Nur die Root-CA "Deutsche Telekom Root CA 2" wird von gängigen Browsern akzeptiert. Das Problem lag darin, dass die Zertifizierungskette vom Tomcat des VOMRS-Servers nicht mitgeliefert wurde. Als Abhilfe wurde Tomcat6 neu konfiguriert, so dass die Zertifizierungskette jetzt mitgeliefert wird und Nutzer keine Sicherheitswarnungen mehr erhalten.
Es wurde ein Script zum Verlängern der VO-Mitgliedschaft für die VO-Administratoren erstellt. Mit Hilfe dieses Scripts wurde die Mitgliedschaft der VO-Administratoren bis zum 31.12.2020 in allen VOs verlängert. Die Übernahme der Repräsentanten aus den VOMRS-Datenbanken in die Oracle-Datenbank des GRRS und damit auch in die Liste der VOs im User-Portal wurde automatisiert.
Das KIT betreibt weiterhin den SAML VOMS Server (dgrid-voms.fzk.de) für D-Grid. Desweiteren wurden die neuen D-Grid VOs pneumogrid, valuegrids und dgsi in VOMS eingerichtet.
Im Zusammenhang mit VOMS wurden insgesamt 2 Tickets vom KIT Help Desk (DGUS) bearbeitet und gelöst.
Insgesamt werden vom FZJ die VOMRS Server für die folgenden D-Grid VOs betrieben: aerogrid, bauvogrid, bioif, bisgrid, biz2grid, bwgrid, c3grid, dgcms, dgops, dgsi, dgtest, education, fingrid, gapslc, gdigrid, hepcg, ingrid, interloggrid, kerndgrid, lifescience, medigrid, optinum, partnergrid, pneumogrid, progrid, ptgrid, softcomp, textgrid, valuegrids, viola, wisent.


Technical Advisory Board

Support Koordination

AstroGrid-D betreibt für die VO astrogrid einen eigenen VOMRS Server.
Zurzeit gibt es folgende Gruppen innerhalb einzelner VOs:

  • bwgrid
    • hsesslingen, unifreiburg, uniheidelberg, unihohenheim, unikarlsruhe, unikonstanz, unimannheim, unistuttgart, unituebingen, uniulm
  • education
    • fzj, rrzn, tukaiserslautern, unigoettingen
  • ingrid
    • ingridcas, ingridform, ingridkop, ingridopt, ingridturb, ingridvis, ingridwas, ingridwfl, ingridwms
  • medigrid
    • md-bi, md-bv, md-kf, md-on, md-rp, md-sv

Seit Januar 2009 werden für alle neu eingerichteten VOs automatisch die folgenden Standard-Gruppen und -Rollen angelegt:

  • Gruppe: admin
    • Rolle: softwareadmin
    • Rolle: dataadmin
  • Gruppe: member
    • Rolle: developer

Betrieb der Ressourcen im D-Grid

Es wurden zahlreiche koordinierende Gespräche im Zusammenhang mit der Weiterentwicklung des Betriebskonzeptes für D-Grid Ressourcen, insbesondere aus den BMBF-Sonderinvestitionen, geführt sowie über E-Mails kommuniziert. Die Version 2.0 des Betriebskonzeptes wurde fertiggestellt (4).
Der zentrale GRRS-Server für D-Grid, das zentrale Gateway für UNICORE5, die UNICORE6-Registry, der UNICORE6-Workflow-Service, der UNICORE6-Orchestrator sowie der zentrale UNICORE6-CIS wurden betrieben. Ressourcenanbieter wurden bei der Anmeldung von Ressourcen zum GRRS bzw. bei der Änderung von Ressourcen-Einträgen unterstützt. Die GRRS-Datenbank wurde um Informations-Provider für UNICORE, Globus und gLite erweitert. Entsprechende Erweiterungen wurden an den Oberflächen zur Registrierung und Änderung einer Ressource vorgenommen.
Außerdem wurde der GRRS zur Registrierung von Globus 4.2 als eigene Middleware neben Globus 4.0 erweitert sowie entsprechende Erweiterungen der Oberflächen zur Registrierung und Änderung einer Ressource vorgenommen.
dgridmap wurde zur Unterstützung von UNICORE6 erweitert und die Dokumentation von dgridmap entsprechend weiterentwickelt. dgridmap wurde außerdem um eine Ausgabemöglichkeit von Attributen erweitert. Dazu gibt es neue Output-Formate für Globus und UNICORE. DGUS-Tickets zu GRRS, zu Problemen von D-Grid-Ressourcen mit GRRS und zu den D-Grid Ressourcen der Ressourcen-Provider wurden von diesen bearbeitet. Eine eXist-Datenbank zur Entwicklung einer XML-Version des GRRS wurde eingerichtet und konfiguriert. An dieser Datenbank wurde die Implementierung der Methoden für die Migration der Datenbestände aus dem jetzigen GRRS in die XML-Datenbank und zu deren Verwaltung in Zusammenarbeit mit FIRST getestet sowie eine Fehlersuche bei Fehlverhalten vorgenommen. Die Datenbestände aus dem jetzigen GRRS wurden migriert. Damit wurde der Meilenstein M-2-3-2-2 "Erste prototypische Anwendung von D-GRDL auf Ressourcen" fristgerecht erreicht. Die GRRS-Daten stehen in der XML-Datenbank zur Verfügung.

Die D-Grid Compute- und Speicher-Ressourcen wurden betrieben und gewartet. Es wurden Updates der Installationen und Neuinstallationen vorgenommen. Mit diesen Ressourcen wurde am Testlauf eines Firewall Verification Tools im D-Grid teilgenommen. Die DGAS-Funktionalität wurde für das RRZN Hannover (Fachgebiet 5.2) durch Aufsetzen von Testsystemen und Debugging getestet. Die Funktionalität der stand alone DGAS-Clients für Torque Systeme wurde getestet und Rückmeldungen zu Mängeln und Problemen bei der Installation gegeben. Dabei wurden auch Arbeiten zum Anschluss der UNICORE-Ressource SoftComp an das DGAS-Accounting durchgeführt.

Ausbau der Redundanz für die D-Grid-Infrastruktur

Für die Arbeiten zum Meilenstein M-2-5-1-2, "Redundanter FC in Betrieb", wurde ein Verfahren entwickelt, um mithilfe von Datenbankreplikation die Datenbestände zwischen Karlsruhe und Jülich abzugleichen. Dieses Verfahren sollte sowohl sicher (Vertraulichkeit) als auch zuverlässig sein. Als Voraussetzung für den Betrieb des redundanten LFC-Servers wurde eine virtuelle Maschinen-Umgebung zum Einrichten des Servers aufgebaut. In dieser Umgebung wurde der redundante LFC-Server eingerichtet und das Verfahren zum sicheren Abgleich der LFC-Kataloge des KIT und des FZJ über das Internet implementiert. Der redundante Server am FZJ ist ein read-only Server, d.h. Daten können nur auf den Server des KIT geschrieben, aber von beiden Servern gelesen werden. Insbesondere steht der redundante Server des FZJ beim Ausfall des KIT für lesenden Zugriff mit dem letzten Datenbestand vor einem Ausfall zur Verfügung. Der Meilenstein M-2-5-1-2 wurde erreicht: Der LFC-Server wurde eingerichtet und in Betrieb genommen.
Der redundante BDII-Server und der redundante WMS-Server wurden betrieben und gewartet (insbesondere Security-Updates). Nach fehlerhaften CERN-Updates erfolgte eine Neuinstallation des Top-Level BDII-Servers.
Der Meilenstein M-2 (Redundanter MDS Server in Betrieb) wurde fertiggestellt. Der redundante MDS 4.0 Server ist unter http://dgrid-mds.scc.kit.edu:8080/webmds verfügbar.
Eine Anleitung für Ressourcen Provider zur Nutzung des MDS 4.0 Servers wurde unter http://dgiref.d-grid.de/wiki/middleware:Globus/service#MDS4_configuration in der Referenzinstallation dokumentiert.
Nach der Einführung von UNICORE6 in die Referenzinstallation wurde eine redundante UNICORE-6-Registry im KIT aufgebaut. Des Weiteren leistete das KIT beim Aufbau der redundanten gLite Server in Jülich Unterstützung. Die redundanten Server sind erreichbar unter:

Das LRZ betrieb im Rahmen von Fachgebiet 2.3 die Ressourcen, die im Rahmen von Sonderinvestitionen (2006, 2007 und 2008) beschafft wurden. Die von der HEP-Community aus den Sonderinvestitionen 2006/2007 beschaffte LCG-Hardware wurde einschließlich der notwendigen Betriebs- und Batchsysteme ebenso durch das LRZ betrieben. Die HEP Community wurde bei der Nutzung dieser Systeme umfassend betreut. Da diese Hardware auf den Produktionsbetrieb des LHC-Beschleunigers am CERN vorbereitet wurde, war ein hoher Personaleinsatz erforderlich.
Das LRZ betrieb außerdem zentrale Dienste für das D-Grid:

  • das zentrale Grid Monitoring mit MDS, WebMDS und GridCSM:

http://webmds.lrz-muenchen.de:8080/webmds/xslfiles/csm/

  • den zentralen MyProxy Server des D-Grid:

myproxy.lrz-muenchen.de
Das LRZ leistete Support für die Communities und Ressourcen-Provider für Fragen, die die zentrale Dienste betreffen, wie lokale Information-Provider und Indexe, den Geo-Maint Sensor, die Anbindung an das Monitoring-System und die Infrastruktur. In diesen Rahmen wurden zahlreiche D-GUS Trouble-Tickets bearbeitet und neue VOs, wie optinum und ptgrid, im grid-mapfile und im MDS aufgenommen.
Der Betrieb von zentralen Diensten verlangte ständige Wartung von Hardware und Software. Unter anderem mussten die Server-Zertifikate für die Produktions-Maschinen beantragt oder erneuert werden, und neue Maschinen, z.B. für das Monitoring durch Inca, aufgesetzt werden.
Weiterhin wurden folgende Tätigkeiten durchgeführt:

  • Installation von GT 4.2 in mds2.lrz-muenchen.de für LRZ, DGI und D-GRID MDS
  • Installation von WebMDS Service (webmds2.lrz-muenchen.de) für GT 4.2
  • Unterstützung beim Aufsetzen der redundanten MDS Server am FZK
  • Identifikation von Problemen im Design und Inkonsistenzen in den Inhalten der D-Grid Datenbank aufgespürt. Eine brauchbare Lösung mit Fuzzy-Logic gefunden und implementiert. An einer konsistenten Zuweisung von Account-Namen wird noch gearbeitet.
  • Mit MediGrid zusammengearbeitet, um dessen spezielle Wünsche (ein /opt/medigrid Verzeichnis auf jeder Ressource) in D-Grid abzubilden.

Hinsichtlich D-MON erfolgte die termingerechte Fertigstellung des FG2-Deliverables "D-MON Übernahmeplan". Es gab erste Arbeiten, um D-MON in den Produktivbetrieb zu bringen, einschließlich des intensiven Austauschs mit dem D-MON Projekt und den Entwicklern der GridSphere-basierten Benutzerschnittstelle. Zu wurden die Aliase d-mon.d-grid.de und d-mon-db.d-grid.de gesichert und die D-MON Web Seite http://d-mon.d-grid.de in Betrieb genommen.

3. Fachgebiet 3

Durch das RRZN wurde im Fachgebiet 3.2 in Zusammenarbeit mit den Fachgebieten für den D-Grid Betrieb und die D-Grid Referenzinstallation die im ersten Halbjahr 2009 begonnene Einführung der VO-Attribut-basierten Autorisierung vorangetrieben. Ziel war und ist weiterhin die zeitnahe Umsetzung in einem neuen Release der D-Grid Referenzinstallation. Das D-Grid Betriebskonzept wurde für die Erweiterung der AAI aktualisiert sowie im Bereich Sicherheit erweitert. Über die Neuerungen sowie weiterhin offene Punkte im Bereich der D-Grid AAI wurde in Berichten, beim von Fachgebiet 3.1 organisierten 4. D-Grid Security Workshop in Göttingen und durch Rundemails

Rundemails informiert. Im Fachgebiet 3.3 wurden am RRZN Sicherheitsfunktionen und -modelle ausgewählter Cloud-Computing-Anbieter (Amazon S3, Nirvanix und Rackspace) auf die Möglichkeit hin untersucht, bestehende D-Grid Speicher-Dienste mit Cloud Ressourcen zu erweitern. Die Ergebnisse wurden auf dem Cracow Grid Workshop ´09 präsentiert. Die Arbeiten im Fachgebiet 3.3 wurden in Zusammenarbeit mit Fachgebiet 3.1 auf dem 4. D-Grid Security Workshop vorgestellt.
Das Fachgebiet 3.3 leitete die Session der "Firewall Virtualization for Grid Application Working Group” auf dem OGF 27 Meeting in Kanada. Die im Rahmen des OGF entwickelten Proposals für ein "Firewall Transfer Protokoll (FiTP)" wurden zwecks Reviews und mit dem Ziel einer Standardisierung an die IETF weitergeleitet. In Aachen wurde in Fachgebiet 3.3 die Masterarbeit "Konzeption eines Verfahrens zur dynamischen Freischaltung von Transportverbindungen über einen Grid-Scheduler" betreut und abgeschlossen.

4. Fachgebiet 4

Das Supportzentrum für dCache, iRODS, Stellaris und OGSA/DAI ist in Betrieb. Es wurden Tickets im DGUS und GGUS Portal bearbeitet, teilweise gemeinsam mit der Supportgruppe der Helmholtz Allianz "Physics at the Terascale". Desweiteren wurden regelmäßig Schulungen vorbereitet und angeboten, die immer gut angenommen wurden. MedInfoGrid wurde weiterhin beim Einsatz von iRODS unterstützt. WissGrid hatte Interesse an iRODS bekundet und erste Kontakte aufgenommen.

Die Vorbereitungen für gemeinsame Leistungstests mit SUN sind angelaufen. Die Entwicklung zum Einsatz von dCache mit NFS4.1 wurde erfolgreich weitergeführt. Die aktuelle dCache Version enthält einen vollständig implementierten und mit dem name space Chimera lauffähigen NFS4.1 Server. Klienten sind in aktuellen Linux Distributionen vorhanden.
Im Bereich Metadaten wurde nach der Organisation einer Session auf dem AHM 2009 eine Erhebung bei den Communities durchgeführt. Dabei wurde insbesondere der Workflow untersucht, um Gemeinsamkeiten heraus zuarbeiten. Für die Erhebung wurden Interviews mit FinGrid, AstroGrid-D, C3Grid, GDIGrid, TextGrid, MediGrid und AeroGrid geführt. Die Auswertung der Ergebnisse ist in "Metadaten-Verwendung in Community-Grids" dokumentiert. Daraus wurde das "Template für Metadaten Policies in den Grid-Communities" entwickelt, das den Communities bei der Organisation ihrer Metadaten hilft. Die Ergebnisse wurden auf einem Metadaten Workshop vorgestellt, auf dem auch die weitere Vorgehensweise und Empfehlungen diskutiert wurden. Der Metadaten Workshop wurde gemeinsam mit WissGrid durchgeführt mit Teilnehmern aus dem DGI2 und aus sechs Communities.

5. Fachgebiet 5

In 2009 wurde die Accounting-Software DGAS in der Version 3.4 in der Testumgebung in Hannover evaluiert, in Zusammenarbeit mit dem Standort Dortmund pilotiert und zur Produktionsreife gebracht. Die Umstellung der Infrastruktur auf die neue Version hat signifikante Performance-Verbesserungen zur Folge. Der Roll-Out der entsprechenden Software-Komponenten für die Sites ist für das Frühjahr 2010 vorgesehen. Auch für die neue Infrastruktur sind vereinfachte Client-Installationspakete entwickelt worden, um den Anschluss der Sites unabhängig von der Middleware gLite zu unterstützen.
In Kooperation mit dem italienischen Instituto Nazionale di Fisica Nucleare (INFN) wurde die Software für die Accounting-Infrastruktur weiterentwickelt. So wurde im Berichtszeitraum der Prototyp einer Integrationslösung auf Basis von Java Enterprise (JEE) fertig gestellt und getestet. Diese Software wird die Basis für zukünftige Weiterentwicklungen im D-Grid bilden.
An das D-Grid Accounting sind Ende 2009 insgesamt 16 Ressourcen  der folgenden Sites angeschlossen: Forschungszentrum Jülich, Karlsruher Institut für Technologie (KIT), Leibniz Universität Hannover (RRZN), RWTH Aachen, TU Dortmund , Universität Kassel (IT Servicezentrum), Universität Oldenburg (OFFIS) sowie Universität Wuppertal.

6. Sondermaßnahmen 2006, 2007 und 2008

Im Rahmen der D-Grid Projekte haben sich einzelne Institutionen bereit erklärt, eigene Ressourcen im D-Grid zur Verfügung zu stellen. Allerdings wurden damit keine Verpflichtungserklärungen bezüglich der zu installierenden Softwarekomponenten abgegeben.
Die im Bereich DGI1-FG2 beteiligten Institutionen bildeten ursprünglich das so genannte Kern-D-Grid. Mit Hilfe dieser Institutionen wurde ein erstes Betriebsmodell erstellt. Unabhängig von der erklärten Verpflichtung dieser Institutionen, Ressourcen dem D-Grid zur Verfügung zu stellen, wird im diesem Bericht nur der Status der im Rahmen der Sondermaßnahmen 2006, 2007 und 2008 für das D-Grid erworbenen Ressourcen dargestellt.
Dabei ist zu berücksichtigen, dass die Antrag stellenden Institutionen auch explizite Verpflichtungen bezüglich dieser Ressourcen im Antrag akzeptiert haben. Diese Verpflichtungen betreffen die zu installierenden Softwarekomponenten, den Zeitpunkt der Betriebsbereitschaft, die Unterstützung des D-Grid Betriebsmodells sowie eine Bericht Erstattungspflicht gegenüber dem D-Grid Beirat. Diese Berichte werden in  Tabelle 2 zusammengefasst. Bei Anforderung werden den Mitgliedern des Beirats auch Einzelberichte zur Verfügung gestellt.
Die in  Tabelle 2 aufgestellte Hardware entspricht dem aktuellen Kenntnisstand des D-Grid. Serverknoten bleiben unberücksichtigt. Der Speicher ist zusammengefasst und soll nur einen Anhaltspunkt liefern. Es wird daher nicht zwischen Cache und Hauptspeicher unterschieden.

In Dortmund sind zwei Cluster installiert, die unabhängig voneinander Nutzungsdaten an das zentrale Accounting melden.

Tabelle 2: Sonderinvestitionen 2006 bis 2008 (DC= DualCore, QC= QuadCore, 8C= 8 Core, TB=TByte)  öffnen/Schließen

Tabelle 3: Ansprechpartner für die Sonderinvestitionen  öffnen/Schließen

Innerhalb des 2. Halbjahres 2009 sind ca. 66,5 Millionen CPU Stunden auf den Ressourcen der D-Grid Sonderinvestitionen gerechnet worden. Dies ist einer Abnahme von 5% im Vergleich zum 1. Halbjahr 2009. Die Verteilung der verbrauchten CPU Stunden verschob sich leicht zu Gunsten der Virtuellen Organisationen außerhalb von D-Grid. Diese Organisationen verzeichneten einen Zuwachs von etwa vier Prozent, gleichzeitig viel der D-Grid Anteil auf 54% zurück (siehe Abbildung 1). Die restlichen 21% der verbrauchten CPU Stunden entstanden durch lokale Anwender.

Betrachtet man nur die Virtuellen Organisationen des D-Grid, so wurden ca. 36 Millionen CPU Stunden in Anspruch genommen; ein Großteil dieser CPU-Stunden entfällt auf die Virtuellen Organisationen AstroGrid-D, BWGrid, HEPCG, MediGrid und SoftComp. Abbildung 2 zeigt eine genaue Aufschlüsselung der angefallenen CPU Stunden nach Virtueller Organisation des D-Grid. Zur besseren Darstellung besitzt die x-Achse eine logarithmische Skala, Virtuelle Organisationen ohne Job Submission im Erhebungszeitraum sind ausgeblendet.

Abbildung 1: Verbrauchte CPUh gegliedert nach Nutzergruppen

Betrachtet man nur die Virtuellen Organisationen des D-Grid, so wurden ca. 36 Millionen CPU Stunden in Anspruch genommen; ein Großteil dieser CPU-Stunden entfällt auf die Virtuellen Organisationen AstroGrid-D, BWGrid, HEPCG, MediGrid und SoftComp. Abbildung 2 zeigt eine genaue Aufschlüsselung der angefallenen CPU Stunden nach Virtueller Organisation des D-Grid. Zur besseren Darstellung besitzt die x-Achse eine logarithmische Skala, Virtuelle Organisationen ohne Job Submission im Erhebungszeitraum sind ausgeblendet.

 

Abbildung 3 zeigt die verbrauchten CPU Stunden über den Berichtszeitraum hinweg.

 

Abbildung 3: Verbrauchte CPU Stunden gegliedert nach Monat

Neben der reinen Anzahl an CPU-Stunden wurde auch die Anzahl an submittierten Jobs festgehalten. Wie aus Abbildung 4 ersichtlich, ergibt sich analog zum Vorjahr ein Übergewicht zugunsten der Non-D-Grid Nutzung. Von den mehr als 12,1 Millionen gerechneten Jobs stammen circa 40% bzw. 4,8 Millionen von D-Grid Nutzern.

Abbildung 4: D-Grid/ Non-D-Grid Anzahl Jobs

Untersucht man die Anzahl gerechneter Jobs und gliedert diese bzgl. der einzelnen Virtuellen Organisationen des D-Grid auf, so ergibt sich die in Abbildung 5 dargestellte Aufteilung. Virtuelle Organisationen, die im Erhebungszeitraum keine Jobs gerechnet haben, wurden in der Graphik nicht berücksichtigt.

Abbildung 5: Anzahl Jobs gegliedert nach D-Grid VO

Zum besseren Erkennen von Tendenzen ist in Abbildung 6 die Anzahl gerechneter Jobs nach Monaten dargestellt.

Abbildung 6: Anzahl Jobs gegliedert nach Monat


Abbildung 7 stellt die bereits auf den D-Grid Ressourcen gespeicherten Datenvolumens bezogen auf die Middleware dCache dar. Eine Nutzung des über OGSA-DAI angebotenen Speichers erfolgte durch die MediGrid VO.

Abbildung 7: dCache Datenvolumen pro D-Grid VO [GByte]

Neben dCache und OGSA-DAI wurden weitere Formen von Storage Elementen durch Communities verwendet. Die Nutzung dieser teils Community-spezifischen Storage Elemente ist in Abbildung 8 zusammengefasst.
Das IZBI stellte zudem mehrere Datenbanken/ Ontologien wie SwissProt, D-Grid Ontology und Ensembl Homo Sapiens bereit.

 

Abbildung 8: Andere Middlewares: Datenvolumen pro D-Grid VO [GByte]

Abschließend sind in Abbildung 9 noch einmal die durch die einzelnen virtuellen Organisationen des D-Grid verbrauchten CPU Stunden dargestellt. Der betrachtete Zeitraum beschränkt sich jedoch im Vergleich zu Abbildung 2 bzw. 3 nicht nur auf das letzte halbe Jahr, sondern betrachtet den Zeitraum Juli 2008 bis Dezember 2009.

 

Abbildung 9: Verbrauchte CPU Stunden gegliedert nach Monaten (Zeitraum 07/2008 bis 12/2009)

Die auf den insgesamt verbrauchten CPU Stunden basierende Trendlinie belegt einerseits die über die letzten 18 Monate stetig angestiegene Nutzung des D-Grid und deutet auf ein weiteres, zukünftiges Wachstum hin.

 

Literaturverzeichnis

  1. Statusbericht über die Kern-Grid-Infrastruktur. [Online] 10. 02 2009. [Zitat vom: 12. 01 2010.] http://www.d-grid-ggmbh.de/fileadmin/downloads/Berichte/StatusberichtKern0208.pdf.

  2. Schwiegelshohn, Uwe, et al. Statusbericht über die D-Grid Kern Infrastruktur. [Online] 07. 08 2009. [Zitat vom: 12. 01 2010.] http://www.d-grid-ggmbh.de/fileadmin/downloads/Berichte/StatusberichtKern0109.pdf.

  3. D-Grid Referenz-Installation. [Online] [Zitat vom: 13. Juli 2009.] http://dgiref.d-grid.de/.

  4. Betriebskonzept für die D-Grid Infrastruktur, Version 2.0. [Online] 04. 12 2009. [Zitat vom: 02. 02 2010.] http://www.d-grid.de/fileadmin/user_upload/documents/Kern-D-Grid/Betriebskonzept/D-Grid-Betriebskonzept.pdf.

  5. Fieseler, Thomas, et al. Konzept für die Mehrfachmitgliedschaft in Virtuellen Organisationen im D-Grid. [Online] 30. Juni 2008. [Zitat vom: 13. Juli 2009.] http://www.d-grid.de/fileadmin/user_upload/documents/Kern-D-Grid/VO-und-Ressourcen-Management/DGI-2-M-2-2-5-1-Konzept-Mehrfachmitgliedschaft-V-1.0.pdf.

  6. Konzept für die Rechtevergabe an Untergruppen im D-Grid. [Online] 30. Juni 2008. [Zitat vom: 13. Juli 2009.] http://www.d-grid.de/fileadmin/user_upload/documents/Kern-D-Grid/VO-und-Ressourcen-Management/DGI-2-M-2-2-4-1-Konzept-Gruppen-V-1.0.pdf.

  7. FG 2.3: Meilenstein 5-1, "Erstellen eines Übernahmeplans der D-MON Funktionen".

  8. FG. 2.2: Meilenstein 6-1, "Erstellung eines Implementierungsplans für die Ergebnisse von IVOM".

  9. FG 2.2: Prototyp zur automatisierten Erzeugung von VOMRS-Instanzen.

 

Anhang

 

Tabelle 4: D-Grid/ Non-D-Grid CPU Stunden Gesamtübersicht   öffnen/Schließen

 

Tabelle 5: D-Grid/ Non-D-Grid Anzahl Jobs Gesamtübersicht   öffnen/Schließen

 

Tabelle 6: D-Grid/ Non-D-Grid akkumuliertes Datenvolumen dCache [GByte]   öffnen/Schließen

 

Tabelle 7:  D-Grid/ Non-D-Grid akkumuliertes Datenvolumen OGSA-DAI [GByte]   öffnen/Schließen

 

Tabelle 8: D-Grid/ Non-D-Grid akkumuliertes Datenvolumen andere Storage Middlewares [GByte]   öffnen/Schließen