Architektur des SLA-Frameworks und Integration D 2.1 Arbeitspaket AP 2: Architektur und Integration Veröffentlichungsdatum: 17/11/2009 Verantwortlicher Editor: Axel Tenschert Version: 9 Status: Review

Autoren Axel Tenschert, Höchstleistungsrechenzentrum Stuttgart Roland Kübert, Höchstleistungsrechenzentrum Stuttgart Dominic Battré, TU Berlin Oliver Wäldrich, FhG SCAI Alexander Willner, UBO Internes Review Philipp Wieder, TUDO Versionshistorie Version Datum Kommentar Autoren 0.1 03.07.2009 Inhaltsverzeichnis und erster Vorschlag einer Architektur Axel Tenschert 0.2 06.07.2009 Referenzen, UML-Kommentar, neues Dateiformat Alexander Willner 0.3 30.07.2009 Inhaltliche Erweiterungen / erste Komponenten-beschreibungen Axel Tenschert 0.4 20.08.2009 Inhaltliche Erweiterungen Dominic Battré 0.5 09.09.2009 Anpassung der Architektur Axel Tenschert 0.6 29.09.2009 Erweiterung des Dokumentenumfangs und inhaltliche Überarbeitung
Axel Tenschert
0.7 10.10.2009 Inhaltliche Erweiterungen Dominic Battré, Oliver Wäldrich 0.8 27.10.2009 Inhaltliche Überarbeitung Axel Tenschert, Roland Kübert 0.9 17.11.2009 Bereich Netze Alexander Willner 1.0 24.11.2009 Inhaltliche Überarbeitung der Architektur Axel Tenschert

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 3
Kurzzusammenfassung Im Rahmen des SLA4D-Grid-Projektes wird eine Service Level Agreement (SLA)-Schicht entwickelt, die es Nutzern, Communities, sowie Ressourcenanbietern erlaubt, SLAs auszuhandeln und ihre Einhaltung zur Laufzeit zu überprüfen. Somit soll es möglich gemacht werden, Dienstgüten zu garantieren, deren Erfüllung bezahlen zu lassen und deren Verletzung mit Strafen zu belegen. Dieses Dokument beschreibt die vorgesehene Architektur des SLA-Frameworks, das im Rahmen des SLA4D-Grid-Projektes entwickelt werden soll.

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 4
Inhaltsverzeichnis 1
  Einleitung...................................................................................................................... 5
 2
  Einordnung in das D-Grid ............................................................................................. 6
 3
  Integrationsaspekte ...................................................................................................... 7
 4
  Reservierung von Ressourcen ..................................................................................... 8
 5
  Schnittstellen zwischen den Arbeitspaketen ................................................................ 8
 6
  Architektur des SLA Frameworks ............................................................................... 10
 6.1
  Anforderungen an die Architektur ......................................................................... 10
 6.2
  Umsetzung der Architektur ................................................................................... 11
 6.2.1
  SLA Preselection............................................................................................ 13
 6.2.2
  Komponenten der Community ....................................................................... 13
 6.2.3
  SLA-Verhandlung und -Überwachung ........................................................... 14
 6.2.4
  Konkrete Implementierungen......................................................................... 17
 7
  Meilensteine................................................................................................................ 18
 7.1
  Aktueller Stand ..................................................................................................... 18
 7.2
  Ziele für Meilenstein M12...................................................................................... 19
 7.3
  Prozess................................................................................................................. 19
 8
  Anmerkungen ............................................................................................................. 20
 Referenzen ........................................................................................................................ 20
 

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 5
Abbildung 1: D-Grid SLA Management Schicht
1 Einleitung Ziel des SLA4D-Grid-Projektes ist die Entwicklung einer Service Level Agreement Management Schicht (SLA-Schicht) im D-Grid. Mittels dieser Schicht sowie weiteren Entwicklungen für die momentane D-Grid Infrastruktur soll bestehenden und zukünftigen D-Grid-Communities sowie Dienstanbietern die Möglichkeit gegeben werden, ökonomische Aspekte im D-Grid zu betrachten und entsprechende Geschäftsmodelle im D-Grid zu entwickeln. Abbildung 1 zeigt die geplante D-Grid SLA Infrastruktur. Die blau hinterlegten Komponenten werden durch das SLA4D-Grid-Projekt entwickelt.

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 6
2 Einordnung in das D-Grid Das SLA4D-Grid-Projekt findet im Rahmen der D-Grid-Initiative statt. Hierbei wird eine SLA-Schicht angestrebt, die den unterschiedlichen Anforderungen im Rahmen von D-Grid gerecht wird. Im Rahmen des Projektes wird ein generisches D-Grid-SLA definiert und um community-spezifische Anforderungen erweitert. Das generische SLA bildet das grundlegende Nutzungsszenario im D-Grid, die Verwendung von Rechnerressourcen, ab und erlaubt deren Nutzung unter wirtschaftlichen Rahmenbedingungen. Community-spezifische Anforderungen ergeben sich zum einen aus den beiden kommerziellen Anwendungsszenarien des Vorhabens, des der con terra GmbH sowie dem von Sun Microsystems, zum anderen auch aus solchen, die bei Workshops evaluiert werden. Das übergeordnete Ziel des Projektes SLA4D-Grid ist es, einen Verbund von Diensten zu entwerfen und zu realisieren, der eine Service Level Agreement Management Schicht für das D-Grid bereitstellt. Diese Schicht ist, wie in Abbildung 1 dargestellt, zwischen der D-Grid-Middleware (gLite1, Globus2 und UNICORE3) und der Benutzerebene des D-Grid anzusiedeln und wird in die bestehende Infrastruktur integriert (unter anderem durch Anbindung an ausgewählte Kern-D-Grid-Dienste). Communities können die SLA-Schicht entweder über spezielle Klienten oder aber eine Schnittstelle nutzen, wie in Abbildung 2 gezeigt. Da die SLA-Schicht einen Mehrwertdienst darstellt, beeinflusst sie die gegenwärtige Nutzung des D-Grid nicht sondern greift bei Communities ohne Bedarf nach SLAs nicht in den Betrieb ein (wie in Abbildung 2 durch Community A dargestellt) und ermöglicht deshalb einen nahtlosen Übergang in den Regelbetrieb. Sie bietet sowohl den Benutzern, ganzen Communities, sowie den Anbietern von D-Grid-Ressourcen eine Gewährleistung der Ressourcennutzung unter wirtschaftlichen Bedingungen. Zu diesem Zweck werden Dienstgütenachfragen und die korrespondierenden Angebote durch Service Level Agreements verbindlich zusammengeführt.
1 http://glite.web.cern.ch/glite/common/introduction.asp 2 http://globus.org/ 3 http://www.unicore.eu/

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 7
Abbildung 2: Generelle Einordnung der SLA-Schicht bezüglich des D-Grid Mittels der SLA-Schicht und unter Zuhilfenahme weiterer D-Grid-Dienste wie beispielsweise Monitoring oder Accounting können SLAs automatisch erstellt, verhandelt und ihre Einhaltung überwacht werden, so dass das D-Grid von akademischen und industriellen Nutzern gemäß ihrer jeweiligen Geschäftsmodelle in einer ökonomisch effizienten Weise genutzt werden kann. Die in Abbildung 2 dargestellte Anbindung der Communities an die Kern-D-Grid Dienste, bzw. an die SLA-Schicht geben hier nur einen Überblick. Die Anbindung an die D-Grid-Infrastruktur wird im Detail in AP1 behandelt. 3 Integrationsaspekte Während des gesamten Projektverlaufs wird ein integrativer Ansatz verfolgt. Hierdurch wird eine enge Kooperation der einzelnen Partner und zwischen den Arbeitspaketen sichergestellt. Dabei sind sämtliche Partner in die Entwicklung der Architektur für die SLA Schicht mit einbezogen. Die einzelnen Komponenten des SLA Frameworks werden mit Hilfe einer gemeinsamen Versionsverwaltung entwickelt und täglichen Funktions- und Integrationstests unterzogen, um frühzeitig Probleme zu erkennen und zu beheben. Das Maven-Build-Management-Tool4 ist für automatisierte Tests sowie die interne und externe Versionierung von Komponenten zuständig. Somit können bereits während der Projektlaufzeit Revisionsstände veröffentlicht und ausgetauscht werden. Um die Integration der SLA Schicht mit bestehenden und noch zu entwickelnden Komponenten des D-Grid sicherzustellen, werden die Anforderungen an die SLA Schicht 4 http://maven.apache.org/

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 8
aus anderen Community Projekten im Rahmen der Arbeitspakete 1 und 6 erhoben. Am 03.09.2009 hat bereits ein Workshop zur Anforderungserhebung stattgefunden. Hier haben Mitglieder der Projekte ValueGrids, Services@MediGRID, WissGrid, PT-Grid, BIS-Grid, OptiNum-Grid und GDI-Grid teilgenommen. 4 Reservierung von Ressourcen Entsprechend der Anforderungserhebung aus dem Szenario des Geodateninfor-mationssystems der con terra GmbH (s. D3.1 Fehler! Verweisquelle konnte nicht gefunden werden.) ist die Reservierung von Ressourcen sowie die anschließende Ausführung eines Programmes auf diesen Ressourcen das erste Ziel, das erreicht werden soll. Um die anzufordernden Ressourcen in einem SLA zu spezifizieren, wurde zusammen mit AP3 eine Spezifizierungssprache, die so genannten „Advanced Reservation Term Language“ definiert (s. D3.1 Fehler! Verweisquelle konnte nicht gefunden werden.). Mittels der Job Submission and Description Language (JSDL) ist es zudem möglich, zu spezifizieren, welches Programm innerhalb der Reservierung zur Ausführung gebracht werden soll. Die Aufgabe der SLA-Schicht soll es nun sein, die im SLA beschriebene Reservierung im Resource Management System zu realisieren und den beschriebenen Job auszuführen. Die Middleware UNICORE besitzt bereits nativ die Möglichkeit, Resourcenreservierungen durchzuführen. Für das Globus Toolkit soll die Einsatzfähigkeit von HARC5 [4] erprobt werden. In diesem Fall wird die SLA-Schicht mit HARC kommunizieren, welches wiederum die Reservierung im RMS6 umsetzt. Unabhängig von der eingesetzten Middleware soll es weiterhin möglich sein, zusätzlich benötigte Ressourcen zu reservieren, um Dienstgüten auf einer ganzheitlichen Basis zusichern und verhandeln zu können. Dies beinhaltet exemplarisch die Verwaltung von Netzwerkkomponenten zwischen beteiligten Rechen- und Speicherressourcen. Das Netzwerkreservierungssystems ARGON7 [5] soll hier beispielhaft eingesetzt werden, um die Aspekte der Aushandlung, Reservierung und Beobachtung prototypisch umzusetzen. 5 Schnittstellen zwischen den Arbeitspaketen Arbeitspaket 2 definiert die Architektur des SLA4D-Grid-Projektes und koordiniert die integrativen Aspekte des SLA4D-Grid Vorhabens. Hierzu werden innerhalb von Arbeitspaket 2 die Schnittstellen zu den weiteren Arbeitspaketen, insbesondere zu AP3 und AP4, berücksichtigt. Die Evaluierung der vorhandenen Schnittstellen wurde während des Workshops am 03.09.2009 diskutiert und weiter ausgearbeitet. Außerdem wurde der Workshop genutzt, um gemeinsam einen Architekturentwurf zu entwickeln, der die vorhandenen Schnittstellen berücksichtigt. Arbeitspaket 3 hat im Rahmen eines Workshops am 03.09.2009 sowie im Bericht „Initial Version of D-Grid SLA D3.1“ Fehler! Verweisquelle konnte nicht gefunden werden. 5 HARC = Highly-Available Resource Co-allocator 6 RMS = Resource Management System 7 ARGON = Allocation and Reservation of Grid-enabled Optical Networks

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 9
Szenarien und Anforderungen an die umzusetzenden Dienstgütevereinbarungen definiert. Dies sind im Besonderen die Unterstützung von Ressourcenreservierungen mittels eines einfachen Advanced Reservation Schemas sowie die Unterstützung der JSDL zur Beschreibung von Resourcenanforderungen und der auszuführenden Anwendung. Da sowohl das Advanced Reservation Schema als auch die JSDL konkrete definierte Schnittstellen bieten, kann mit der Abbildung der Anforderungen auf Ressourcenmanagementsysteme begonnen werden. Die konkrete Strukturierung der SLAs kann später sehr einfach angepasst werden. Domänenspezifische SLA Spracherweiterungen werden über entsprechende Plugins abgebildet. Auch diesen wird das SLA zur Verfügung gestellt, sodass keine komplexen Interfaces und Datenstrukturen neben den domänenspezifischen Schemata definiert werden müssen. Arbeitspaket 4 benötigt den Zugriff auf SLA Templates von Ressourcen- und Dienstanbietern. Die WS-Agreement-Spezifikation [3] schreibt vor, dass Templates als Teil des Resource Property-Dokumentes der AgreementFactory exponiert werden. Damit ist sichergestellt, dass der Zugriff über standardisierte Interfaces erfolgen kann. Neben dem Zugriff gemäß der WSRF-Spezifikation soll es möglich sein, sich über WS-Notification über Änderungen der verfügbaren SLA Templates informieren zu lassen. Auch hier regelt ein anerkannter Standard den Zugriff. Zur SLA-Provisionierung sollen Plugins für das SLA-Framework geschrieben werden, welche das SLA-Angebot des Verhandlungsinitiators übergeben bekommen. Diese Plugins sind zu einem gewissen Teil domänenspezifisch. Durch die Definition der SLA-Strukturen in AP3, ergeben sich die Eingabeparameter der Plugins. Die Anbindung an das Backend erfolgt über die Grid Middleware - UNICORE, Globus Toolkit beziehungsweise gLite. UNICORE verfügt bereits nativ über die notwendigen Mechanismen zur Reservierung von Ressourcen. Im Globus Toolkit soll die zur Verfügung stehende Methode genutzt werden, um wiederum mit verschiedenen Resource Management Systemen zu kommunizieren. Die vorgesehenen Mechanismen zum SLA-Monitoring sind in [1] aufgeführt: Der aktuelle Status eines Agreements soll als Resource Property in Service Term States und Guarantee Term States ausgedrückt werden. Das folgende Pseudo-Schema zeigt die Struktur eines Service Term States. <wsag:ServiceTermState termName="xs:string"> <wsag:State>wsag:ServiceTermStateDefinition</wsag:State> { <wsag:Processing><xs:any##other/></wsag:Processing> | <wsag:Idle><xs:any##other/></wsag:Idle> | <xs:any##other/> } ? </wsag:ServiceTermState> * Der xs:any-Erweiterungspunkt erlaubt die Exponierung des aktuellen Status einer Reservierung. Das folgende Fragment demonstriert dies für eine Ressourcen-beschreibung, bei der der Nutzer mindestens 1.8 GHz angefordert hat und genau 2 GHz geliefert bekommt: <wsag:ServiceTermState termName="JOB_DESCRIPTION"> <wsag:State>Ready</wsag:State> <wsag:Processing> <jsdl:Resources>

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 10
<jsdl:IndividualCPUSpeed><jsdl:Exact>2.0E9</jsdl:Exact></…> <jsdl:IndividualCPUCount><jsdl:Exact>2.0</jsdl:Exact></…> <jsdl:TotalResourceCount><jsdl:Exact>16.0</jsdl:Exact></…> </jsdl:Resources> </wsag:Processing> </wsag:ServiceTermState> Da ServiceTermStates als Teil des ResourcePropertyDocuments der Agreement-Instanz veröffentlicht werden, ergibt sich die Möglichkeit, über GetResourceProperty-Anfragen oder WS-Notification-Subscriptions entsprechend WS-Agreement den Staus des Agreements zu beobachten. Das Monitoring im RMS hängt vom konkreten RMS ab und ist nach außen hin an dieser Stelle transparent. Die konkreten Informationen des RMS werden über einen Plugin-Mechanismus an die SLA-Schicht propagiert. 6 Architektur des SLA Frameworks 6.1 Anforderungen an die Architektur Es wurden die folgenden Anforderungen von SLA4D-Grid bezüglich der Architektur erhoben:
• Standard WS-Agreement-Protokoll und Möglichkeit der (Nach-)Verhandlung. Aus Gründen der Interoperabilität und aufgrund des Standardisierungsstandes von WS-Agreement ist dieses zur Repräsentierung und Erzeugung von SLAs ausgewählt worden. Es soll aus diesem Grund eine vollständig kompatible Implementierung des Protokolls vorgenommen werden. Da der Bedarf besteht, Agreements individuell auszuhandeln und auch nachträglich nachzuverhandeln, soll eine Erweiterung entwickelt werden, die diese Möglichkeiten bietet. Diese Erweiterung soll zunächst im Rahmen der OGF spezifiziert und dann im Rahmen des SLA4D-Grid-Projektes umgesetzt werden. • Unterstützung unterschiedlicher Domänen mit eigenen Vokabularen. Die SLA-Schicht muss in der Lage sein, Vokabulare aus unterschiedlichen Domänen zu unterstützten. Die WS-Agreement-Spezifikation ist generisch und definiert selbst keine Sprachkonstrukte, die beschreiben, welche Eigenschaften und Dienstgüten ein Dienst bieten muss. Im Rahmen des SLA4D-Grid-Projektes soll daher ein gewisser Basissatz (JSDL, Advanced Reservation Term Language) unterstützt werden. Des Weiteren soll es aber ebenfalls möglich sein, dass Communities eigene Spracherweiterungen beitragen und durch domänenspezifische Plugins realisieren. • Erweiterbarkeit und Revisionierung von Templates. Die Erfahrung aus vergangenen Projekten hat gezeigt, dass SLAs nur sehr schwer frei spezifiziert werden können. Stattdessen basieren sie auf Templates deren Struktur sowohl Nutzer als auch Anbieter von Ressourcen bekannt ist. Da sich Anforderungen mit der Zeit ändern, soll es möglich sein, diese Templates nachträglich anzupassen und zu revisionieren. • Komponierbarkeit (z.B. Komponente für Auswerten einer JSDL Beschreibung). Da unterschiedliche Domänen häufig gemeinsame Anforderungen besitzen wie zum Beispiel die Beschreibung der angeforderten Infrastruktur (zum Beispiel mittels JSDL) oder Zeitpunkte zu denen eine Reservierung durchgeführt werden soll, soll

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 11
es möglich sein, diese Aspekte in separaten Komponenten zu kapseln und für domänenspezifische SLAs zu komponieren. • Unterstützung von UNICORE und Globus Toolkit. Aufgrund der Verbreitung, soll der Fokus der SLA-Schicht auf den Grid Middlewares UNICORE und Globus Toolkit liegen. Da das Globus Toolkit 4.0 auf einer Draft-Version der WS-Resource Framework und WS-Addressing Spezifikationen basiert, während UNICORE die finalen Standards verwendet, wird das Globus Toolkit 4.2 voraussichtlich aus Interoperabilitätsgründen als Umgebung für die Globus Welt fungieren. Jedoch ist zu berücksichtigen, dass die Entscheidung über die zu verwendende Globus Version von den Anforderungen des D-Grid abhängt, daher ist diese Entscheidung noch nicht endgültig. • Skalierbarkeit. Die Skalierbarkeit der SLA-Schicht soll auf zwei Wegen gewährleistet werden. Zum einen soll es möglich sein, parallel Verhandlungen um SLAs durchzuführen. Zum anderen soll die Aushandlung von Rahmenverträgen erlauben, dass für eine große Zahl kleiner Aufträge keine individuellen Verhandlungen durchgeführt werden müssen. • Überprüfbarkeit von Agreements. Da Service Level Agreements Provisionen und Strafen für die Erfüllung bzw. Verletzung der beschriebenen Dienstgüten definieren, ist es wichtig, dass die realisierten Dienstgüten nach außen überprüfbar dargestellt werden, sodass eine Abrechnung erfolgen kann. • Anforderungen bezüglich D-Grid Integration Die SLA-Schicht soll alle notwendigen Voraussetzungen mitbringen, sodass eine Anbindung an Ressource–Management-Systeme, Billing-Systeme und VO-Management-Systeme erfolgen kann. 6.2 Umsetzung der Architektur Die Architektur der SLA-Schicht soll dem folgenden Diagramm folgen.

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 12
Abbildung 3: Architektur Übersicht

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 13
6.2.1 SLA Preselection SLA Template Registry (Discovery) Die SLA Template Discovery Komponente kommuniziert mit dem agreementFactoryPortType und der Discovery Komponente der Community. Hierdurch kann ein geeignetes SLA Template aus der SLA Template Registry aus dem Bereich SLA-Verhandlung und -Überwachung genutzt werden, dass den Ansprüchen des Specific SLA Client gerecht wird. Hierbei greift die SLA Template Registry (Discovery) auf sämtliche notwendigen im D-Grid vorhandenen Daten zu. Weiterhin werden die SLAs der verschiedenen Standorte im D-Grid ermittelt, um ein angemessenes SLA zu identifizieren. User Der User ist in der Lage Anfragen an die SLA Template Registry (Discovery) zu stellen. Nach eingegangener Anfrage des Users identifiziert sich die SLA Template Registry (Discovery). Admin Der Admin hat die Berechtigung die SLA Template Registry (Discovery) zu aktualisieren. Dies geschieht zunächst manuell. 6.2.2 Komponenten der Community Discovery Die Discovery Komponente der Community ist der Mediator zwischen SLA Template Registry (Discovery) und Specific SLA-Client. Die Discovery ermittelt einen geeigneten Dienst. Specific SLA-Client Beim Specific SLA-Client handelt es sich um den Client eines spezifischen Dienstes, der die domänenspezifischen Anforderungen des Dienstes berücksichtigt. Seine Aufgabe ist es, den Benutzer bei der Aushandlung von SLAs zu unterstützen. Es werden Specific SLA-Clients für die beiden Anwendungsfälle von con terra GmbH sowie von Sun Microsystems entwickelt, die zugleich als Beispiel für weitere Community-Projekte fungieren sollen. Aufgrund der Komponierbarkeit, sollen die dort unterstützten Aspekte in weitere Specific SLA-Clients übernommen werden können. Der Specific SLA-Client nutzt das WS-Agreement Client API zur Kommunikation mit der SLA-Implementierung der Middleware. Hierbei stellen Specific SLA-Clients eine konkrete Schnittstelle zum Benutzer dar. WS-Agreement Client API Die WS Agreement Client API ist ein Interface, das mittels des WS-Agreement-Protokolls mit einem WS-Agreement-Service kommuniziert. Hierbei finden der AgreementFactoryPortType und der AgreementPortType Berücksichtigung. Das WS-Agreement Client API stellt die clientseitige Implementierung des WS-Agreement-Protokolls dar und ist agnostisch

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 14
hinsichtlich spezifischer SLAs, ihrer Struktur und ihres Inhalts. Das API stellt die benötigten Funktionalitäten bereit, um über die in der WS-Agreement-Spezifikation definierten Mechanismen (PortTypes) mit WS-Agreement konformen Diensten zu kommunizieren. Die WS-Agreement-Spezifikation umfasst die folgenden PortTypes: AgreementFactory, PendingAgreementFactory, Agreement-Acceptance, Agreement und AgreementState. Das WS-Agreement Client API soll Middleware-Aspekte wie Authentifizierung und sichere Kommunikation dem Specific SLA-Client gegenüber transparent machen. Momentan sind zwei Implementierungsmöglichkeiten der WS-Agreement Client API zu berücksichtigen: a) Die Client API umfasst einen Layer für Globus Toolkit und einen für UNICORE.
b) Die Client API ist mit einer Implementierung für Globus Toolkit und mit einer für UNICORE verbunden.
Die Entscheidung für eine der beiden Ansätze wird sich im weiteren Projektverlauf konkretisieren. Jedoch ist zu gewährleisten, dass sowohl Globus Toolkit, als auch UNICORE adäquat eingesetzt werden können. 6.2.3 SLA-Verhandlung und -Überwachung Generic Agreement Factory Die Generic Agreement Factory ist eine Kernkomponente der SLA-Schicht und repräsentiert eine generische Implementierung eines WS-Agreement Factory-Webservices. Dieser ist für die Kommunikation mit dem WS-Agreement Client API zur Erzeugung von SLAs zuständig. Er orchestriert die Nutzung diverser weiteren Komponenten, welche die Verhandlung sowie den vollen Lebenszyklus eines SLAs kontrollieren. Hierbei implementiert der SLA-Layer den AgreementFactory-PortType und den PendingAgreementFactory-PortType.

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 15
Der AgreementFactory-PortType erlaubt Webservice-Clients die synchrone Erstellung von Agreements, während der PendingAgreementFactory-PortType die asynchrone Erstellung von Agreements ermöglicht. Sowohl Anfragen an den AgreementFactory-PortType als auch an den PendingAgreementFactory-PortType werden an diese generische Agreement Factory delegiert. Die generische Agreement Factory realisiert die Verbindung zwischen der Webservice-Schicht und der SLA-Schicht. Sie lädt Agreement Templates aus der Template Registry und erzeugt neue Agreement-Instanzen basierend auf den eingehenden Anfragen (Agreement Offer). Jede Anfrage muss auf einem Template der Agreement Factory basieren. Die generische Agreement Factory validiert eingehende Anfragen zur Erstellung neuer Agreements hinsichtlich der Creation Constraints, die in dem zugrunde liegenden Template definiert sind. Damit wird sichergestellt, dass Anfragen zur Erstellung Agreements korrekt von einem Agreement Client erzeugt wurden. Die generische Agreement Factory nutzt die Agreement Offer Validation zum Prüfen der Gültigkeit einer Anfrage. Nach der erfolgreichen Validierung einer Anfrage führt die generische Agreement Factory die spezifische Logik zur Erstellung des Agreements beziehungsweise zur Erzeugung des mit dem Agreement verbundenen Dienstes aus. Im Falle einer erfolgreichen Erzeugung des Dienstes wird eine neue Agreement-Instanz erzeugt. AgreementOfferValidation Die AgreementOfferValidation-Komponente ist damit beauftragt, vor dem Akzeptieren eines SLA-Angebots zu prüfen, ob dieses den CreationConstraints des zugehörigen SLA-Templates genügt. Hierbei unterstützt die WS-Agreement-Spezifikation die Definition so genannter „Creation Constraints“ als Teil eines Agreement Templates. Sie definieren sowohl die Struktur als auch die Wertebereiche einzelner Elemente eines Templates. Eine gültige Anfrage zur Erstellung eines Agreements muss auch hinsichtlich der Creation Constraints des ihr zugrunde liegenden Agreement Templates valide sein. Der Agreement Offer Validator überprüft die Validität jeder Creation Constraint für eine eingehende Anfrage. Dazu generiert der Validator für jede Creation Constraint einen XML Schema-Datentyp basierend auf der Constraint. Anschließend selektiert er die Daten der Anfrage, die durch die jeweilige Creation Constraint referenziert werden. Im Anschluss werden die selektierten Daten mittels XML Schema-Validierung hinsichtlich ihrer Gültigkeit entsprechend dem Constraint-Datentyp überprüft. Mittels der AgreementOfferValidation-Komponente kann bereits über das Design des SLA-Templates verifiziert werden, dass nur solche Ressourcen angefordert werden können, die auch tatsächlich angeboten werden können. Die AgreementOfferValidation stellt eine Art Vorfilter für eingehende Anfragen dar. SLA Template Registry Die SLA Template Registry speichert SLA-Templates, die von Nutzern angefordert werden können und als Grundlage für neue SLAs dienen. Die

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 16
Agreement Factory nutzt bei Anfragen die im SLA Template Repository gespeicherten Templates. Das SLA Template Repository soll in der Lage sein, Templates zu revisionieren. Des Weiteren soll es dazu dienen domänenspezifische Plugins an bestimmte Templates und deren Revisionen zu binden, so dass die domänenspezifischen Anforderungen realisiert werden können. Weiterhin beinhaltet die Agreement Factory Action-Mechanismen zur Verhandlung von Agreement-Templates und zur Erzeugung von neuen Agreements. Die Template Registry ermöglicht einer Agreement Factory den Zugriff auf Agreement Templates und den zugehörigen Factory Actions über den Namen und die ID eines Templates. Zudem ermöglicht sie das Auflisten aller Templates dieser Registry. SLA-Repository Im SLA-Repository werden abgeschlossene SLAs mit allen assoziierten Daten gespeichert. Hierdurch ist es möglich, auf diese sowohl zur Laufzeit als auch später zuzugreifen. Dies ist unter anderem für das Accouting und Billing relevant. Das SLA-Repository ist primär für die statischen Daten des SLAs zuständig, da die dynamischen Daten dem Monitoring entstammen. Das SLA Repository stellt die Persistenzschicht der SLA-Schicht dar. Agreement Eine Agreement-Instanz speichert die Daten (Properties) eines Agreements und implementiert die Geschäftslogik zum terminieren des Agreements. Zu den Daten des Agreements zählen neben dem Agreement Context und den Agreement Terms unter anderem auch die verschiedenen Zustände einer Agreement-Instanz. Die Zustandsdaten des Agreements werden während des SLA-Monitoring-Prozesses regelmäßig aktualisiert. Zu den Zustandsdaten gehören der Agreement-Status, der Service Term-Status und der Guarantee Term-Status. Agreement-Clients können die Daten mittels der in WSRF spezifizierten GetResourceProperty-Methode abfragen. Hierdurch ist der Agreement-Webservice mit dem SLA-Repository sowie dem Monitoring verbunden und kommuniziert mit dem Nutzer über das WS-Agreement Client API. SLA-Monitor Der SLA-Monitor sammelt die relevanten dynamischen Daten eines SLAs während der Ausführung. Die Zustandsdaten eines Agreement bestehen aus dem Agreement-Status, dem Service Term-Status und dem Guarantee Term-Status. Der SLA-Monitor aktualisiert diese Zustandsdaten periodisch. Der Monitor wird beendet sobald das Agreement einen finalen Status erreicht. Der Agreement-Status repräsentiert den Zustand des SLA-Monitoring-Prozesses. Solange sich ein Agreement in einem überwachten Status befindet wird der Status der Service Terms und der im Agreement definierten Garantien aktualisiert.

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 17
Für jeden Service Term eines Agreements existiert ein Service Term-Status. Dieser Status spezifiziert den Zustand eines Service Terms (NotReady, Ready, Complete). Darüber hinaus kann dieser Status zusätzliche Informationen zu einem Service Term beinhalten, die zur Auswertung der Garantien des Agreements notwendig sind. Für jede im Agreement definierte Garantie existiert ein Garantie Term-Status. Dieser Garantie Term-Status wird auf Basis der Service Term-Statusobjekte ermittelt. Der SLA-Evaluator ist für die Auswertung des Garantie Term-Status verantwortlich. Hingegen nimmt der SLA-Monitor keine Auswertung vor. SLA-Evaluator Der SLA-Evaluator bezieht zur Laufzeit Daten vom SLA-Monitor und führt eine Auswertung durch. Hierbei ermittelt er auf Basis der Agreement Terms und der Service Terms den Status der einzelnen Garantien (Guarantee Terms) des Agreements. Der SLA-Evaluator wird zu diesem Zweck vom SLA Monitor aufgerufen, nachdem die Zustände der Service Terms vom Monitor aktualisiert wurden. Der SLA-Evaluator stellt zudem die Schnittstelle zum SLA-Accounting dar. Er stößt die Meldung von SLA-Verletzungen und -Erfüllungen für das externe Monitoring an und bietet dem Agreement Webservice die Daten für die Garantien .Die Auswertung der Garantien resultiert in Gutschriften und Strafen, basierend auf der Erfüllung bzw. Verletzung der definierten Garantien. 6.2.4 Konkrete Implementierungen Um die Unterstützung von verschiedenen Domänen zu ermöglichen, ist es notwendig, dass Plugins domänenspezifische Funktionalitäten übernehmen. Beispiele für solche Plugins sind Entscheidung, ob ein SLA-Angebot akzeptiert werden kann, die Durchführung der Allokation von Ressourcen im RMS, das Monitoring, etc. AgreementFactoryAction Hierbei handelt es sich um die konkreten Implementierungen der Logik einer Agreement Factory. Die AgreementFactoryAction realisiert die Geschäftslogik zur Verhandlung von Templates sowie zur Erstellung neuer Agreements. Die Aktionen erlauben Entscheidungen zu fällen, ob SLA-Angebote akzeptiert werden, und kommunizieren mit dem zugrundeliegenden RMS. Da eine Validierung von SLA-Angeboten gegen die SLA-Templates bereits zuvor von der AgreementOfferValidation-Komponente durchgeführt wurde, können diese domänenspezifischen Aktionen von konkreten SLA-Strukturen ausgehen und sehr einfach relevante Daten aus dem SLA-Angebot extrahieren und umsetzen. Die Aktionen selbst zerlegen sich in komponierbare Teilaspekte, sodass zum Beispiel die Allokation von Ressourcen zwischen verschiedenen domänenspezifischen Implementierungen geteilt wird, während das Starten

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 18
und Beenden von domänenspezifischen Diensten in diesen Ressourcen individuell implementiert wird. Monitoring Handler Ein oder mehrere Monitoring Handler werden mit einem konkreten Agreement assoziiert. Die Monitoring Handler sind für das Monitoring erforderlich und liefern die Daten anhand derer entschieden wird, ob die Garantien eines SLAs erfüllt oder verletzt werden. Diese Daten können aus dem RMS direkt entstammen oder Monitoringdiensten des D-Grid entnommen werden. Die Monitoring Handler sind verantwortlich für die Aktualisierung der Zustände der Service Terms und realisieren die Verbindung zum Service Monitoring. 7 Meilensteine In Projektmonat 12 soll ein erster Prototyp der SLA-Schicht vorliegen. Aus Sicht der Architektur wird hier insbesondere angestrebt, dass ein SLA-Client mit der AgreementFactory sowie Agreement Services in den Grid Middlewares kommunizieren können. Dies bedeutet insbesondere auf Seiten der Globus Toolkit-Middleware eine bedeutende Entwicklung und Integrationsleistung. Dazu muss die zugrundeliegende WS-Agreement Implementierung, voraussichtlich WSAG4J, angepasst und um den SOAP Stack reduziert werden. Des Weiteren wir angestrebt, eine erste Kommunikation mit dem RMS in der Grid-Middleware durchzuführen. Weiterhin ist eine generische Reservierung von Resourcen für Rechenjobs vorgesehen, die Reservierung von Speicher in gLite wird analysiert und die Möglichkeiten einer Integration eines Netzwerkreservierungssystems wird untersucht. 7.1 Aktueller Stand Die bereits vorhandenen Komponenten sind im Folgenden aufgelistet. o Generische Komponente eines Verhandlungsdienstes: Eine Anpassung der Komponente ist für die verschiedenen Anwendungsfälle erforderlich. o Eine Komponente, die die Aufgaben der Agreement Factory erfüllt. o Ein SLA Template Speicher. o Client API Jedoch ist zu berücksichtigen, dass sämtliche Komponenten angepasst werden, um eine optimale Lösung für die angestrebten Ziele zu liefern. Die bereits teilweise vorhanden Komponenten: o Eine Provisionierungs-Komponente: Die entsprechende Komponente ist in UNICORE implementiert. Weiterhin ist eine grundlegende Anpassung der Komponente erforderlich. Eine detaillierte Aufwandsabschätzung folgt.

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 19
o Eine Provisionierungs-Komponente in Globus Toolkit 4. Die vorläufige Aufwandsabschätzung beträgt 2 Monate. o Eine Provisionierungs-Komponente in gLite. o Eine Provisionierungs-Komponente für MPLS- und GMPLS-Netzwerke. o Eine Monitoring-Komponente: Bisher fehlen die Kerndienste der SLA-Schicht. Eine detaillierte Aufwandsabschätzung folgt. o Wie bereits in Kapitel 4 dargelegt, ist die Ressourcenvorauswahl das erste Ziel, das erreicht werden soll. o Weiterhin ist die Planung & Koordination der Abläufe eines der ersten Ziele. 7.2 Ziele für Meilenstein M12 Die folgenden Komponenten sollen bis Monat 12 erreicht werden: o Umsetzung eines Generisches D-Grid-SLA. o Vorraussetzungen hierfür sind: 1. Abstrahierung SOAP aus der WS-Agreement Implementierung. Die vorläufige Aufwandsabschätzung hierfür beträgt einen Monat. 2. Die Umsetzung fehlender respektive teilweise vorhandener Kerndienste und der Provisionierung. Folgende Abhängigkeiten bestehen: o Eine Spezifikation generischer SLAs (AP3, SLA4D-Grid). o Eine Anbindung an die Sicherheitsinfrastruktur im D-Grid (direkt Abhängigkeit zum D-Grid). Noch offene Punkte: o Eine D-Grid-weite Discovery. 7.3 Prozess
• Sämtliche Implementierungen werden in Globus Toolkit integriert. Der abgeschätzte vorläufige Aufwand hierfür beträgt 2 Monate. Als zweite Phase des Vorhabens ist die Realisierung durchzuführen. Der Aufwand für Phase 2 wird während der Integrationsphase detaillierter abgeschätzt.
• Weiterhin werden die Implementierungen in UNICORE integriert. Der voraussichtliche Aufwand hierfür beträgt ebenfalls 2 Monate. Phase 2 ist auch hier die Realisierung, deren Aufwandsabschätzung während der ersten Phase konkretisiert wird.
• Für die Nutzung von gLite ist eine Anforderungsanalyse erforderlich, die mit einem Aufwand von 2 Wochen veranschlagt ist.
• Generische Prozesse: Eine Persistenzschicht wird benötigt, der Aufwand hierfür ist momentan noch nicht im Detail abzuschätzen.
• Weiterhin wird ein integrativer Ansatz verfolgt. Hierfür werden die aktuellen Implementierungen getestet, um frühzeitig Unregelmäßigkeiten zu erkennen und angemessen darauf reagieren zu können.

con terra, HLRS, FZK, FZJ, LRZ, RRZN, SCAI, SUN, TUB, TUDO, UBO, 2009
SLA4D-Grid AP2 – Architektur des SLA Frameworks und Integration 20
8 Anmerkungen Die Architektur des SLA Frameworks von AP2 und beeinflusst das Vorgehen des gesamten Projektes. Daher werden die zukünftigen Deliverables von AP 2 Erweiterungen von Deliverable 2.1 sein. In diesem Sinne ist Deliverable 2.1 als „Living Document“ zu verstehen. Referenzen [1] Battré, D., Havestadt, M., Wäldrich, O., Lessons learned from implementing WS-AGREEMENT, Grid 2009, IEEE Workshop on Service Level Agreements in Grids, Springer, CoreGRID Series, to appear. [2] Initial Version of D-Grid SLA D3.1: http://bscw.uni-duisburg-essen.de/bscw/bscw.cgi/7842472 [3] WS-Agreement-Spezifikation: http://www.gridforum.org/documents/GFD.107.pdf [4] The Highly-Available Resource Co-allocator: http://www.cct.lsu.edu/harc.php [5] Barz, C. and Bornhauser, U. and Martini, P. and Pilz, M. and de Waal, C., Willner, A., ARGON: Reservation in Gridenabled Networks, Proceedings of the 1. DFN-Forum on Communication Technologies 2008.