1 / 11

Agreement Service for Resource Reservation and Allocation: Overview

Tiziana Ferrari, Elisabetta Ronchieri GRAAP WG, GGF14. Agreement Service for Resource Reservation and Allocation: Overview. The EGEE proejct. EGEE:

mairi
Download Presentation

Agreement Service for Resource Reservation and Allocation: Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Tiziana Ferrari, Elisabetta Ronchieri GRAAP WG, GGF14 Agreement Service forResource Reservation and Allocation:Overview

  2. The EGEE proejct • EGEE: • project funded by the European Union aiming at the realization of a production-quality wide-area Grid infrastructure for the support of a large number of scientific applications • gLite is the set of core Grid services developed within the project: • Data management services • Job scheduling and service discovery (Workload Management System) • Information services • Security services • Accounting • Monitoring • and others... • overall service architecture available at [ARCH]

  3. Requirements • Requirements: support of resource allocation and reservation. In order of priority: • Storage space reservation for guaranteed storage of: • large amounts of replicated data • Output files produced by distributed analysis jobs • Computing for the timely execution of high-priority jobs • Network bandwidth for guaranteed data throughput on shared paths • Agreement Service (AS): • A new gLite service • Based on WS-Agreement (see following slides) • supports agreement offer signalling for establishment of resource allocation Service Level Agreements

  4. Initiators • Our Agreement Initiators: • Users • Workload Management System (WMS): • Used as Agreement Service proxy in case of clients that are interested in the properties of the resource to be reserved, but not in its location • WMS is instrumented to discover: • the resources satisfying the client’s reservation requirements • the interfaces of the service providers associated to the resources discovered in step 1 • The Agreement Services that support the interfaces identified in step 2 • Performes resubmission of the agreement offer in case of failure • Supports logging and bookkeeping of the entire agreement signalling process • Data Management • To perform reservation of storage space before triggering a file transfer

  5. Architecture Agreement Initiators Agreement Offer Reservation request Reservation and Allocation Service Providers (RASPs) Computing farm Storage system Network infrastructure

  6. Agreement Service implementation 1/2 • Implementation work started in Dec 2004 (WS-Agreement reference draft: the one which went to public comment) • Agreement services use the WS-Agreement XML schema definitions, however: • We decided not to go for WSRF (due to lack of implementation experience), for this reason we currently do not comply to the current draft • A database (WMS Logging and Bookkeeping component) is used for mangement of state information • We currently have a single WS service (the so-called Agreement Service) exposing the following operations: • createAgreement(), agreementKill(), agreementUpdate() • getAgreementProperties(), getAgreementStatus() • getTemplates() • We plan to redesign the Agreement Service when the WS-Agreement draft will be finalized

  7. Agreement Service implementation 2/2 • Agreement Service for space reservation currently under development: • In C++ • Based on gSoap 2.7.1 • Corresponding storage space service provider interface: SRM v. 2.1 (Grid Resource Management WG, GGF) [SRM] • Correspondance between AS operations and SRM service provider operations: • createAgreement()  srmReserveSpace(), srmPrepareToPut/srmPrepareToGet • agreementKill()  srmReleaseSpace() • agreementUpdate()  srmUpdateSpace(), srmChangeFileStorageType() • getAgreementStatus()  srmGetSpaceMetaData()

  8. Comments: use of xs:choice • xs:choice in XML Schema definitions not correctly handled by gSoap 2.7.1 (corresponding class not correctly generated, i.e. no presence of arrays) • xs:choice replaced through the use of xs:sequence and minOccurs=0 Our version: From standard: <xs:complexType name="TermCompositorType"> <xs:sequence> <xs:element name="ExactlyOne" type="wsag:TermCompositorType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="OneOrMore" type="wsag:TermCompositorType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="All" type="wsag:TermCompositorType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="wsag:ServiceDescriptionTerm" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="wsag:GuaranteeTerm" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="TermCompositorType"> <xs:sequence> <xs:choice maxOccurs="unbounded"> <xs:element name="ExactlyOne" type="wsag:TermCompositorType"/> <xs:element name="OneOrMore" type="wsag:TermCompositorType"/> <xs:element name="All" type="wsag:TermCompositorType"/> <xs:element ref="wsag:ServiceDescriptionTerm" minOccurs="0"/> <xs:element ref="wsag:GuaranteeTerm" minOccurs="0"/> </xs:choice> </xs:sequence> </xs:complexType>

  9. Guarantee state monitoring • Guarantee state information: provided by the agreement service? • this information typically changes frequently over time and it is a function of private accounting information collected at the service provider level • Collection of guarantee status information from a general-purpose service such as the Agreement service, is extremely complex as information providers can choose different mechanisms and formats • Two approaches: • GRAAP: Guarantee state information currently provided by the Agreement service • Our preferred option: Guarantee state information directly notified by the service provider to the parties involved in the agreement

  10. Other comments • Service Description Terms vs Guarantee Terms: • It is sometimes difficult to decide if an attribute should belong to the SDT section or rather to the guarantees section. Eg. Lifetime of a reservation: is it an SDT or a guarantee term? • Handling of the recursive structure of Terms quite complex, especially for the implementation of the logic needed to support the “exactly one” and “one or more” compositors • gSoap parsing error on: xs:group <xs:complexType name="OfferItemType"> <xs:sequence> <xs:element ref="wsag:Location"/> <xs:group ref="xs:simpleRestrictionModel" minOccurs="0"/> <!--//AA REMOVE COMMENTS --> </xs:sequence> <xs:attribute name="name" type="xs:string"/> </xs:complexType>

  11. References • [ARCH] EGEE Middleware Architecture (https://edms.cern.ch/document/476451) • [AS] gLite Allocation and Reservation Architecture http://edms.cern.ch/document/508055 (v. 2.1) • [SRM] http://sdm.lbl.gov/gsm/ • Prototype code available from the gLite CVS repository: • http://jra1mw.cvs.cern.ch:8180/cgi-bin/jra1mw.cgi/ • See the org.glite.allocation sub-system

More Related