Resource Allocation

From EGIWiki
Jump to: navigation, search
Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


EGI Resource Allocation menu:
  • Home


Contents


Introduction to Resource Allocation in EGI

The goal of the Resource Allocation (RA) process is to reach an agreement between Customer and Provider concerning the parameters and conditions of use of resources.

The RA process is useful for the Customers (VO representatives, individual users) because in a multi-provider EGI environment they have a single point of contact to ask for a share on resources. RA is also beneficial for Providers (Site Manager, NGI Manager) as it allows more effectively plan the use of resources and closer communication with Customers.

The basic parameters of a RA contact are: duration and the amount of computing and /or storage resources.

The EGI offer is expressed in a form of Resource Pools which are declared by Providers using common metrics. The Customers use the same metrics while describing their needs (resource request).


Basics

In this section basic elements of Resource Allocation Process are introduced. Please have a look at the RA terminology to facilitate further reading.

Parties involved

In RA process there are three parties involved:


Documents

The RA process operates on the following documents:

No. Document Name Involved
1. Customer Request C
2. Service Level Agreement C, B
3. SLA Section C, B
4. Operations Level Agreement
P, B



Customer Request

A document created by Customer describing their resource requirements. In a reply to a Customer Request the Broker creates an SLA containing one or more SLA Sections. There is one SLA Sections for each Resource Pool selected to satisfy a Request.

Service Level Agreement (SLA)

Document created on the basis (in fact it is exact copy) of Customer Request. Parties involved in SLA handling are Broker and Customer. An SLA must contain at least one SLA Section. Each SLA Section is linked to an underpinning OLA. SLA may contain metrics defined on federated level (there are direct obligations of EGI towards the User).

SLA states:

SLA Section

The document exchanged between Broker and Customer along with SLA. Created as an exact copy of a corresponding OLA, can be modified in the negotiation process. If changed, OLA should be modified accordingly. At the end of negotiations metrics values in SLA Section must be equal to those in OLA. SLA Section cannot be handled separately from SLA.

SLA Sections states:

Operations Level Agreement (OLA)

The document created by the Broker as a result of selecting a Resource Provider to satisfy a given Customer Request. There may be a number of OLAs linked with an SLA. Stand alone document describing a specific Resource Provider allocation associated with some SLA. OLA is created on the basis of SLA parameters and as a result of pool matching. Each created OLA is connected with some specific SLA, but can be handled in parallel with or independently from SLA.

Parties engaged in OLA negotiation are Broker and Resource Provider (e.g. Site or NGI manager).

OLA states:

EGI-RA-SLA2.png


Activities

As mentioned Resource Allocation Process main goal is to reach a point at which Customer and Resource Provider reach an understanding about resources allocated for Customer and sign the SLA.

There are 9 activities leading to this goal:

Activities directly involved in RA Procedure:

No. Activity Name Involved
1 User Request validation C,B
2 OLA creation based on pool matching B
3 OLA (re)negotiation P, B
4 OLA confirmation/rejection P
5 SLA creation/updating B
6 SLA negotiation step B, C
7 SLA confirmation, signing C


Activities beyond RA Procedure:

No. Activity Name Involved
1 Resource Pool creation P
2 User Request creation C

All activities are being conducted in e-GRANT tool.



More about Resource allocation Procedure can be found here.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox
Print/export