Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "Resource Allocation"

From EGIWiki
Jump to navigation Jump to search
Line 8: Line 8:


| style="width:60%; font-size:95%;" | <br>  
| style="width:60%; font-size:95%;" | <br>  
This page is developed for&nbsp; XXX<br>  
This page is developed for Resource Providers.<br>  


It describes Resource Allocation Process supported by [http://e-grant.egi.eu/ e-GRANT] tool.  
It describes Resource Allocation Process supported by [http://e-grant.egi.eu/ e-GRANT] tool.  
Line 53: Line 53:
<u>Activities beyond RA&nbsp;Procedure</u>:<br>  
<u>Activities beyond RA&nbsp;Procedure</u>:<br>  


#Pool creation - partie(s) involved: P &nbsp;  
#Pool creation - party(-ies) involved: P &nbsp;  
#User Request creation -&nbsp; partie(s) involved: C
#User Request creation -&nbsp; party(-ies) involved: C


<u>Ac</u><u>tivities directly involved in RA&nbsp;Procedure</u>:<br>  
<u>Activities directly involved in RA&nbsp;Procedure</u>:<br>  


#User Request validation - partie(s) involved: C and B  
#User Request validation - party(-ies) involved: C and B  
#OLA creation based on pool matching - partie(s) involved: B  
#OLA creation based on pool matching - party(-ies) involved: B  
#OLA (re)negotiation - partie(s) involved: P and B  
#OLA (re)negotiation - party(-ies) involved: P and B  
#OLA confirmation/rejection - partie(s) involved: P  
#OLA confirmation/rejection - party(-ies)) involved: P  
#SLA creation/updating &nbsp;- partie(s) involved: B  
#SLA creation/updating &nbsp;- party(-ies) involved: B  
#SLA negotiation step - partie(s) involved: B and C  
#SLA negotiation step - party(-ies) involved: B and C  
#SLA confirmation/signing - partie(s) involved: C
#SLA confirmation/signing - party(-ies) involved: C


All RA&nbsp;connected activities are being conducted in [https://e-grant.egi.eu/slaneg/auth e-GRANT].  
All RA&nbsp;connected activities are being conducted in [https://e-grant.egi.eu/slaneg/auth e-GRANT].  
Line 72: Line 72:
While participating in RA&nbsp;process parties can deal with following documents:  
While participating in RA&nbsp;process parties can deal with following documents:  


==== <span style="font-size:17px;font-family:'Trebuchet MS';color:#000000;background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;">Customer Request</span> ====
==== Customer Request  ====


Initial request specified by Customer, specifying their resource requirements.  
Initial request specified by Customer, describing their resource requirements.  


After Request validation, a reply to this document is an SLA with SLA Sections (underpinning OLAs). It contains all parameters about Customer’s resource allocation request (VO, description of activity, specified metrics etc.)  
After Request validation, a reply to this document is an SLA with SLA Sections (underpinning OLAs). It contains all parameters about Customer’s resource allocation request (VO, description of activity, specified metrics etc.)  


==== <span style="font-size:17px;font-family:'Trebuchet MS';color:#000000;background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;">Operations Level Agreement (OLA)</span>  ====
==== Operations Level Agreement (OLA) ====


Stand alone document describing a specific Resource Provider allocation associated with user request (SLA).  
Stand alone document describing a specific Resource Provider allocation associated with user request (SLA).  


It is created on the basis of SLA parameters and as a result of pool matching. Every created OLA is connected with some specific SLA, but can be handled parallely with or independently from SLA.  
It is created on the basis of SLA parameters and as a result of pool matching. Every created OLA is connected with some specific SLA, but can be handled parallel with or independently from SLA.  


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


<span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;"> </span>


<span style="font-size:16px;font-family:'Trebuchet MS';color:#000000;background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;" id="docs-internal-guid-b117f3c0-3c0c-e019-59d4-645651adb2c1">OLA states:</span>  
 
<u>OLA states:</u>  


*DRAFT – in this state OLA is visible only to its author  
*DRAFT – in this state OLA is visible only to its author  
Line 95: Line 95:
*AGREED-REVOKABLE – state indicates that OLA was created based on right-to-revoke scenario and it is in a period when it can be revoked.  
*AGREED-REVOKABLE – state indicates that OLA was created based on right-to-revoke scenario and it is in a period when it can be revoked.  
*AGREED – state indicates that both parties agreed on the OLA, however it is not linked to any binding SLA; OLA in this state can be invalidated only in case the association with underpinned SLA is deleted both based on Broker or User decision).  
*AGREED – state indicates that both parties agreed on the OLA, however it is not linked to any binding SLA; OLA in this state can be invalidated only in case the association with underpinned SLA is deleted both based on Broker or User decision).  
*BINDING – this state indicates that resource allocation must be perfomed based on details described in the OLA  
*BINDING – this state indicates that resource allocation must be performed based on details described in the OLA  
*REJECTED – this state indicates that OLA was rejected and is neither binding nor a subject of negotiation.
*REJECTED – this state indicates that OLA was rejected and is neither binding nor a subject of negotiation.


==== <span style="font-size:17px;font-family:'Trebuchet MS';color:#000000;background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;">Service Level Agreement (SLA)</span>  ====
==== Service Level Agreement (SLA) ====


<span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;"> </span>Document created on the basis (is exact copy) of Users Request after succesful pool matching (at least one OLA must be created/agreed). Parties involved in SLA handling are Broker and Customer. Every SLA contains underpinned OLAs (visible to Broker and Site Representatives) and corresponding to OLAs SLA sections (visible to Broker and Customer).  
Document created on the basis (is exact copy) of Users Request after succesful pool matching (at least one OLA must be created/agreed). Parties involved in SLA handling are Broker and Customer. Every SLA contains underpinned OLAs (visible to Broker and Site Representatives) and corresponding to OLAs SLA sections (visible to Broker and Customer).  


SLA must contain at least one SLA section (each section reflects a single underpinned OLA); SLA may contain metrics defined on federated level (there are direct obligations of EGI towards the User).  
SLA must contain at least one SLA section (each section reflects a single underpinned OLA); SLA may contain metrics defined on federated level (there are direct obligations of EGI towards the User).  
Line 106: Line 106:
SLA is created as a response to the RA User Request.  
SLA is created as a response to the RA User Request.  


<span style="font-size:16px;font-family:'Trebuchet MS';color:#000000;background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;">SLA states:</span>  
<u>SLA states:</u>  


*IN-NEGOTIATION – state indicates that a proposal was sent by one party to another and a negotiation step is expected.  
*IN-NEGOTIATION – state indicates that a proposal was sent by one party to another and a negotiation step is expected.  
Line 117: Line 117:
The document corresponding to OLA but exchanged between Broker and Customer along with SLA. Created as an exact copy of appropriate 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.  
The document corresponding to OLA but exchanged between Broker and Customer along with SLA. Created as an exact copy of appropriate 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.  


<span style="font-size:16px;font-family:'Trebuchet MS';color:#000000;background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;">SLA Sections states:</span>  
<u>SLA Sections states:</u>  


*DRAFT – in this state SLA Sections is visible only to its author  
*DRAFT – in this state SLA Sections is visible only to its author  
*PROPOSAL – state indicates that a proposal was sent by one party to another and a negotiation step is expected.  
*PROPOSAL – state indicates that a proposal was sent by one party to another and a negotiation step is expected.  
*BINDING – this state indicates that resource allocation must be perfomed based on details described in the OLA  
*BINDING – this state indicates that resource allocation must be performed based on details described in the OLA  
*REJECTED – this state indicates that OLA was rejected and is neither binding nor a subject of negotiation.
*REJECTED – this state indicates that OLA was rejected and is neither binding nor a subject of negotiation.


=== Example of RA implementation in E-grant  ===
=== Example of RA implementation in E-grant  ===


filmik<br>
TBD<br>  
 
<br>  


More about Recource allocation Procedure can be found [[Resource Allocation Procedure and Work Instruction|here]].  
More about Resource allocation Procedure can be found [[Resource Allocation Procedure and Work Instruction|here]].  


== Customer - related activities  ==
== Customer - related activities  ==


TBD
TBD  


== Provider - related activities  ==
== Provider - related activities  ==

Revision as of 10:11, 14 April 2014

Welcome to EGI Resource Allocation Page.

This page is developed for Resource Providers.

It describes Resource Allocation Process supported by e-GRANT tool.



Introduction to Resource Allocation

The effective usage of IT resources requires from Customers and Resource Provider reaching agreement on how much resources, with some specific requirements will be available to User at specific time period.

In heterogeneous IT environment it is difficult for Customers to find matching resources and for Resource Providers to manage their IT capacity.

The Resource Allocation process, if possible,  facilitates reaching agreement between Customers and Resource Providers.

Starting points are:

  • set of Resource Pools defined by Resource Providers describing in common metrics resources they are willing to deliver to Users
  • set of Customers expectations (Request) describing in common metrics resources they are willing to use

As a result of the process, if the Request was agreed by all parties, there is binding SLA signed, that is basis for resource configuration, allocation usage, support and allocation accounting.

In case there were not matched Requests, the output of the process is report to EGI.eu allowing to manage Pool Capacity (add new resources)

RA basics

In this section the most important elements of Resource Allocation Process can be found.

Parties involved

In RA process there are three parties involved:

  • Broker (B) - coordinator of RA process
  • Resource Provider (P) - Site Administrator or NGI manager responsible for resource allocation in involved sites
  • Customer (C) – scientist involved in a science project requesting storage or computing resources in EGI, person signing SLA with Resource Provider

Activities

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

There are 9 activities leading to this goal:

Activities beyond RA Procedure:

  1. Pool creation - party(-ies) involved: P  
  2. User Request creation -  party(-ies) involved: C

Activities directly involved in RA Procedure:

  1. User Request validation - party(-ies) involved: C and B
  2. OLA creation based on pool matching - party(-ies) involved: B
  3. OLA (re)negotiation - party(-ies) involved: P and B
  4. OLA confirmation/rejection - party(-ies)) involved: P
  5. SLA creation/updating  - party(-ies) involved: B
  6. SLA negotiation step - party(-ies) involved: B and C
  7. SLA confirmation/signing - party(-ies) involved: C

All RA connected activities are being conducted in e-GRANT.

Related documents

While participating in RA process parties can deal with following documents:

Customer Request

Initial request specified by Customer, describing their resource requirements.

After Request validation, a reply to this document is an SLA with SLA Sections (underpinning OLAs). It contains all parameters about Customer’s resource allocation request (VO, description of activity, specified metrics etc.)

Operations Level Agreement (OLA)

Stand alone document describing a specific Resource Provider allocation associated with user request (SLA).

It is created on the basis of SLA parameters and as a result of pool matching. Every created OLA is connected with some specific SLA, but can be handled parallel with or independently from SLA.

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


OLA states:

  • DRAFT – in this state OLA is visible only to its author
  • INVALIDATED - document (OLA) cancelled by its author before sending to another party
  • PROPOSAL – state indicates that a proposal was sent by one party to another and a negotiation step is expected.
  • AGREED-REVOKABLE – state indicates that OLA was created based on right-to-revoke scenario and it is in a period when it can be revoked.
  • AGREED – state indicates that both parties agreed on the OLA, however it is not linked to any binding SLA; OLA in this state can be invalidated only in case the association with underpinned SLA is deleted both based on Broker or User decision).
  • BINDING – this state indicates that resource allocation must be performed based on details described in the OLA
  • REJECTED – this state indicates that OLA was rejected and is neither binding nor a subject of negotiation.

Service Level Agreement (SLA)

Document created on the basis (is exact copy) of Users Request after succesful pool matching (at least one OLA must be created/agreed). Parties involved in SLA handling are Broker and Customer. Every SLA contains underpinned OLAs (visible to Broker and Site Representatives) and corresponding to OLAs SLA sections (visible to Broker and Customer).

SLA must contain at least one SLA section (each section reflects a single underpinned OLA); SLA may contain metrics defined on federated level (there are direct obligations of EGI towards the User).

SLA is created as a response to the RA User Request.

SLA states:

  • IN-NEGOTIATION – state indicates that a proposal was sent by one party to another and a negotiation step is expected.
  • BINDING-IN-PART – at least one SLA section is binding (also related underpinned OLA must be binding); this state is used in case some of the Site representatives agreed on their OLAs, but negotiations with others are still in progress.
  • BINDING – this is terminal state for the SLA; this state indicates that RA process was completed (even in case that the request is not satisfied fully)
  • REJECTED – this state indicates that SLA was rejected and is neither binding nor a subject of negotiation.

SLA Section

The document corresponding to OLA but exchanged between Broker and Customer along with SLA. Created as an exact copy of appropriate 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:

  • DRAFT – in this state SLA Sections is visible only to its author
  • PROPOSAL – state indicates that a proposal was sent by one party to another and a negotiation step is expected.
  • BINDING – this state indicates that resource allocation must be performed based on details described in the OLA
  • REJECTED – this state indicates that OLA was rejected and is neither binding nor a subject of negotiation.

Example of RA implementation in E-grant

TBD

More about Resource allocation Procedure can be found here.

Customer - related activities

TBD

Provider - related activities

TBD

Operations of Resource Allocation Process

wiki.egi.eu/wiki/Resource_Allocation_Operations_internals