DGSI

Ziele
Das Gap-Projekt "DGSI" konzipiert und entwickelt eine Interoperabilitätsschicht für Scheduling in Service Grids, die es Benutzern einer Community erlaubt, Arbeitslast auf Ressourcen einer anderen Community zur Ausführung zu bringen. Hierbei soll insbesondere der Tatsache Rechnung getragen werden, dass die einzelnen, spezialisierten Scheduling-Lösungen der Communities weiterhin Bestand haben.

Zu diesem Zweck werden die vorhandenen Systeme verschiedener Service Grids im Rahmen des Projekts an die Interoperabilitätsschicht angebunden. Dieses Vorgehen stellt zudem sicher, dass die im D-Grid vorhandenen Rechen- und Speicherressourcen allen Communities nachhaltig zur Verfügung stehen können. Weiterhin wird im Projekt in Zusammenarbeit mit der SLA-Schicht angestrebt, den Nutzern Qualitätsgarantien für die Ausführung ihrer Arbeitslast zusichern zu können. Bei der Umsetzung wird konsequent auf anerkannte offene Standards gesetzt, um die Interoperabilität von D-Grid im internationalen Kontext zu stärken.

Nutzungsszenarien
Den meisten Service Grids im Rahmen von D-Grid ist die Anforderung gemein, vorhandene Arbeitslast in effizienter Weise auf die angeschlossenen Ressourcen zu verteilen. Diese unter dem Sammelbegriff Grid Scheduling gefasste Problematik ist bereits innerhalb einer Community sehr vielfältig: sowohl die eingereichten Jobs als auch die zur Verfügung stehenden Ressourcen unterscheiden sich derart stark, dass eine Koordination spezielles Wissen über Nutzungsszenarien und die verwendete Infrastruktur voraussetzt. Dies führt in der Konsequenz zu sehr verschiedenen Community-spezifischen Ansätzen bei der Entwicklung von Scheduling-Diensten, die diese Verwaltungs- und Verteilungsaufgabe übernehmen.

Für das beschriebene Szenario bietet sich daher ein Ansatz an, der eine integrative Zusammenarbeit auf Basis der Gemeinsamkeiten erlaubt, zu realisieren. Dabei werden die vorhandenen Scheduling-Lösungen beibehalten und so erweitert, dass eine Zusammenarbeit auf gleichberechtigter Basis möglich ist. Die beiden im Projekt vorgesehenen Szenarien sind dabei die Delegation von Aktivitäten und Ressourcen.

Delegation von Ressourcen
Bei der Ressourcen-Delegation kann ein Scheduler eine in seiner Domäne verfügbare Ressource für ein zuvor ausgehandeltes Zeitfenster in die Verwaltungshoheit eines anderen Community-fremden Schedulers stellen. Dieser Ansatz bietet sich insbesondere dann an, wenn die an der Verhandlung und Delegation beteiligten Partner ähnliche oder gleiche Basismiddleware-Systeme einsetzen, jedoch Unterschiede im Bereich der Aktivitätsbeschreibung oder Managementfunktionalität der involvierten Scheduler bestehen. Hierunter fallen beispielsweise die einseitige Unterstützung von Workflows, aber auch Aktivitäten, die den Rückgriff auf Community-spezifische Dienste erfordern.

Delegation von Aktivitäten
Bei der Aktivitäts-Delegation übergibt ein Scheduler eine Aktivität und das Management der Ausführung in die Domäne des Schedulers einer anderen Community. Voraussetzung hierfür ist die Kompatibilität oder zumindest eine Adaptierbarkeit von Aktivitätsbeschreibungen zwischen den Schedulern. Damit kann orthogonal zu dem zuerst vorgestellten Ansatz eine Inkompatibilität der Basismiddleware zweier Communities überbrückt werden. Auch dieser Ansatz setzt eine Verhandlung beider Schedulingdienste voraus.

Vermittlung von Delegationen
Die direkte Verhandlung zwischen zwei Community-Schedulern bietet zudem eine interessante Erweiterungsmöglichkeit beider Delegationsansätze. Zusätzlich zum Auftreten als Verhandlungspartner bezüglich der Annahme einer Aktivität oder Delegation einer Ressource kann ein Community-Scheduler als Vermittler auftreten, wenn er die an ihn gestellten Anforderungen bezüglich der Ausführung einer Aktivität selbst nicht erfüllen kann. Hierbei soll der Schwerpunkt auf der Bekanntmachung zweier Scheduler durch den Vermittler liegen; die eigentliche Verhandlung über den Delegationsprozess erfolgt danach ähnlich dem Vorgehen in Peer-to-Peer-Netzen zwischen den Verhandlungspartnern direkt.

Verwertung
Eine nachhaltige Interoperabilität von Grid-Schedulern kann nur erreicht werden, wenn eine kritische Anzahl von Grid-Schedulern aus beiden Welten die Interoperabilitätsschicht implementieren. Daher wird im Projekt angestrebt, die Interoperabilitätsschicht in eine möglichst große Anzahl von im D-Grid verwendeten Grid-Schedulern sowie in kommerzielle Produkte zu integrieren. Die beteiligten Partner im Projekt schaffen diese Möglichkeit, da sie entweder für die Entwicklung von Grid-Schedulern direkt verantwortlich sind oder mit den Entwicklern eng zusammenarbeiten. Insbesondere die leitende Beteiligung von Platform Computing erhöht die Chancen für einen Transfer in ein kommerzielles Produkt, mit dem dann die anderen Grid-Scheduler kooperieren können, erheblich.  Während erste Ansätze für eine solche Interoperabilität auch bei anderen Systemen angedacht werden und damit die Bedeutung dieser Fragestellung unterstreichen, bietet die Heterogenität innerhalb von D-Grid gegenüber den anderen Projekten die Möglichkeit eine genügend große Anzahl unterschiedlicher Grid-Scheduler zu berücksichtigen.

Bei der Interoperabilitätsschicht handelt es sich nicht um ein eigenständiges Softwareprodukt, das selbstständig vermarktet werden soll. Daher ist für dieses Projekt ein Geschäftsmodell nicht geeignet. Um eine nachhaltige Verwertung zu sichern, soll diese Schicht als ein offener Standard eingerichtet werden, damit möglichst viele Scheduler diese Funktionalität integrieren. Gegenwärtig ist für weltweite Standardisierungen im Grid das OGF zentraler Anlaufpunkt. Mehrere Partner des Projektes sind bereits in leitenden Funktionen in den dort angesiedelten Arbeitsgruppen mit Relevanz für Grid-Scheduling beteiligt, so dass für eine Standardisierung beste Voraussetzungen bestehen. Weiterhin erfordert das OGF vor einer Standardisierung zwei unterschiedliche Referenzimplementierungen.

Da diese Teil des Projektes sind, bestehen gute Bedingungen für die Standardisierung. Dies übt darüber hinaus einen hohen Druck auf weitere Grid-Scheduler aus, diese Schicht auch zu implementieren, so dass beste Voraussetzungen für eine Wirkung der Projektergebnisse über das Ende des Projekts hinaus gegeben sind.

Schließlich bestehen enge Kooperationen mit in D-Grid etablierten Ressourcenanbietern, um eine nachhaltige Anbindung an die in der Referenzinstallation eingesetzten Basismiddlewares Globus, UNICORE oder gLite zu sichern.