Difference between revisions of "Resource Allocation"

From EGIWiki
Jump to: navigation, search
 
(60 intermediate revisions by 5 users not shown)
Line 1: Line 1:
Welcome to page describing Resource Allocation Process.<br>  
+
{{Template:Op menubar}} {{Template:EGI RA menubar}}<br>  
  
== Introduction to Resource Allocation<br> ==
+
<br> {{TOC_right}}
  
The effective usage of IT&nbsp;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.
+
= '''Introduction to Resource Allocation in EGI'''<br>  =
  
In heterogeneous IT environment it is difficult for Customers to find matching resources and for Resource Providers to manage their IT&nbsp;capacity.  
+
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.<br>
  
The Resource Allocation process, if possible,&nbsp; facilitates reaching agreement between Customers and Resource Providers.  
+
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. <br>
  
Starting point are:  
+
The basic parameters of a RA contact are: '''duration''' and the '''amount of computing and /or storage resources'''.
  
*set of Resource Pools defined by Resource Providers describing in common [https://wiki.egi.eu/wiki/Resource_Allocation_Request_Metrics_Description metrics] resources they are willing to deliver to Users
+
The EGI offer is expressed in a form of '''Resource Pools''' which are declared by Providers using common [[Resource Allocation Metrics Description|metrics]]. The Customers use the same metrics while describing their needs (resource request).  
*set of Customers expectations (Request) describing in common [https://wiki.egi.eu/wiki/Resource_Allocation_Request_Metrics_Description 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.
+
<br>
  
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)
+
= '''Basics'''<br>  =
  
== RA basics<br>  ==
+
In this section basic elements of Resource Allocation Process are introduced. Please have a look at the [https://wiki.egi.eu/wiki/Resource_Allocation_Terminology RA terminology] to facilitate further reading.
  
In this section the most important elements of Resource Allocation Process can be found.<br>
+
== Parties involved<br>  ==
 
 
=== Parties involved<br>  ===
 
  
 
In RA&nbsp;process there are three parties involved:<br>  
 
In RA&nbsp;process there are three parties involved:<br>  
  
*<span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:bold;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline;">Broker (B)</span><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;"> - coordinator of RA process</span><br>  
+
*'''Broker (B)''' - matchmaker and coordinator of RA process<br>  
*<span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:bold;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline;">Resource Provider (P)</span><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;">- Site Administrator or NGI manager responsible for resource allocation in involved sites</span><br>  
+
*'''Resource Provider (P)''' - Site Manager or NGI Manager responsible for resource allocation on sites in their scope<br>  
*<span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:bold;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline;">Customer (C)</span> – scientist involved in a science project requesting storage or computing resources in EGI, person signing SLA with Resource Provider<br>
+
*'''Customer (C)''' - scientist involved in a science project requesting storage or computing resources in EGI, person signing SLA with Resource Provider<br><br>
 
 
=== Activities<br>  ===
 
 
 
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:<br>
 
 
 
<u>activities beyond RA&nbsp;Procedure</u>:<br>  
 
  
#<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;" id="docs-internal-guid-9ba7b433-3c1c-7aeb-2ff1-f36f31e8adae">Pool creation - partie(s) involved: P &nbsp;</span>
+
<br>  
#<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;">User Request creation -&nbsp;</span> partie(s) involved: C
 
  
<u>activities directly involved in RA&nbsp;Procedure:</u><br>
+
== Documents  ==
  
#<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;">User Request validation - </span><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;">partie(s) involved: C and B</span>
+
The RA process operates on the following documents:  
#<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;">OLA creation based on pool matching - </span><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 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;">partie(s) involved: </span>B</span>
 
#<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;">OLA (re)negotiation - </span><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 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;">partie(s) involved: </span>P and B</span>
 
#<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;">OLA confirmation/rejection &nbsp;- </span><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 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;">partie(s) involved: </span>P</span>
 
#<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;">SLA creation/updating &nbsp;- </span><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 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;">partie(s) involved: </span>B </span>
 
#<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;">SLA negotiation step - </span><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 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;">partie(s) involved: </span>B and C</span>
 
#<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;"> SLA confirmation/signing - </span><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 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;">partie(s) involved: </span>C</span>
 
  
<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;">All RA&nbsp;connected activities are being conducted in [https://e-grant.egi.eu/slaneg/auth E-grant].</span>  
+
{| cellspacing="1" cellpadding="1" border="1" width="291"
 +
|-
 +
| '''No.'''
 +
| '''Document Name'''
 +
| '''Involved'''
 +
|-
 +
| 1.
 +
| Customer Request
 +
| C
 +
|-
 +
| 2.
 +
| Service Level Agreement
 +
| C, B
 +
|-
 +
| 3.  
 +
| SLA Section
 +
| C, B
 +
|-
 +
| 4.  
 +
| Operations Level Agreement<br>  
 +
| P, B
 +
|}
  
=== Related documents  ===
+
<br>
  
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>  ====
 
  
<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;">Initial request specified by Customer, specifying their resource requirements. </span>
+
=== Customer Request  ===
  
<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;">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>
+
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.  
  
==== <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> ====
+
=== 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;">Stand alone document describing a specific Resource Provider allocation associated with user request (SLA).</span>
+
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).  
  
<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;">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.</span>  
+
<u>SLA states:</u>  
  
<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;">Parties engaged in OLA negotiation are EGI Broker and Resurce Provider (e.g. Site or NGI manager).</span>  
+
*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)<br>
 +
*REJECTED – this state indicates that SLA was rejected and is neither binding nor a subject of negotiation.<br>
  
<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>  
+
=== SLA Section<br> ===
  
<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>  
+
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.<br>  
  
*<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;">DRAFT – in this state OLA is visible only to its author</span>
+
<u>SLA Sections states:</u>  
*<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;">INVALIDATED - document (OLA) cancelled by its author before sending to another party</span>
 
*<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;">PROPOSAL – state indicates that a proposal was sent by one party to another and</span> <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;">a negotiation step is expected.</span>
 
*<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;">AGREED-REVOKABLE – state indicates that OLA was created based on right-to-revoke</span> <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;">scenario and it is in a period when it can be revoked.</span>
 
*<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;">AGREED – state indicates that both parties agreed on the OLA, however it is not linked to</span> <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;">any binding SLA; OLA in this state can be invalidated only in case the association with</span><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;"> underpinned SLA is deleted both based on Broker or User decision).</span>
 
*<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;">BINDING – this state indicates that resource allocation must be perfomed based on details</span><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;"> described in the OLA</span>
 
*<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;">REJECTED – this state indicates that OLA was rejected and is neither binding nor a</span> <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;">subject of negotiation.</span>
 
  
==== <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> ====
+
*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.<br><br>
  
<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;"> 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).</span>
+
=== Operations Level Agreement (OLA) ===
  
<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;">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).</span>
+
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.  
  
<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:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;">SLA is created as a response to the RA User Request.</span>'''
+
Parties engaged in OLA negotiation are Broker and Resource Provider (e.g. Site or NGI manager).<br><br>  
  
<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>OLA states:</u>  
  
*<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;">IN-NEGOTIATION – state indicates that a proposal was sent by one party to another and</span><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;"> a negotiation step is expected.</span>
+
*DRAFT – in this state OLA is visible only to its author
*<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;">BINDING-IN-PART at least one SLA section is binding (also related underpinned OLA</span>&lt;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;" /&gt;<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;"> must be binding); this state is used in case some of the Site representatives agreed on their</span><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;"> OLAs, but negotiations with others are still in progress.</span>
+
*INVALIDATED - document (OLA) cancelled by its author before sending to another party
*<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;">BINDING – this is terminal state for the SLA; this state indicates that RA process was</span><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;"> completed (even in case that the request is not satisfied fully)</span><br>
+
*PROPOSAL – state indicates that a proposal was sent by one party to another and a negotiation step is expected.  
*<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;">REJECTED – this state indicates that SLA was rejected and is neither binding nor a</span> <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;">subject of negotiation.</span>
+
*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.<br>
  
==== <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;">SLA Section</span><br>  ====
+
[[File:EGI-RA-SLA2.png]]
  
<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;">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>  
+
<br>
  
<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>  
+
== Activities<br> ==
  
*<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;">DRAFT – in this state SLA Sections is visible only to its author</span>
+
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.  
*<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;">PROPOSAL – state indicates that a proposal was sent by one party to another and</span><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;"> a negotiation step is expected.</span>
 
*<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;">BINDING – this state indicates that resource allocation must be perfomed based on details</span><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;"> described in the OLA</span>
 
*<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;">REJECTED – this state indicates that OLA was rejected and is neither binding nor a</span> s<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;">ubject of negotiation.</span>
 
  
=== Example of RA implementation in E-grant  ===
+
There are 9 activities leading to this goal:<br><br>
  
filmik<br>  
+
<u>Activities directly involved in RA&nbsp;Procedure</u>:<br><br>  
  
 +
{| class="wikitable"
 +
|-
 +
! 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
 +
|}
  
 +
<br> <u>Activities beyond RA&nbsp;Procedure</u>:<br>
  
More about Recource allocation Procedure can be found [[Resource Allocation Procedure and Work Instruction|here]].
+
{| class="wikitable"
 +
|-
 +
! No.
 +
! Activity Name
 +
! Involved
 +
|-
 +
| 1
 +
| Resource Pool creation
 +
| P
 +
|-
 +
| 2
 +
| User Request creation
 +
| C
 +
|}
  
== Customer - related activities  ==
+
All activities are being conducted in [https://e-grant.egi.eu/slaneg/auth e-GRANT] tool.<br>
  
strona
+
<br>
  
== Provider - related activities  ==
 
  
strona<br>
+
More about Resource allocation Procedure can be found [[Resource Allocation Procedure and Work Instruction|here]].<br><br>  
  
== Operations of Resource Allocation Process  ==
 
  
[https://wiki.egi.eu/wiki/Resource_Allocation_Operations_internals wiki.egi.eu/wiki/Resource_Allocation_Operations_internals]
+
[[Category:ResourceAllocation]]

Latest revision as of 15:38, 19 January 2015

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


EGI Resource Allocation menu:




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:

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


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:

  • 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 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:

  • 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.

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:

  • 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.

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.