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 Process"

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


*it covers the request,  
*it covers the request,  
*it covers the request partially or doen't cover at all, but there is no option to improve the situation
*it covers the request partially or dosen't cover at all, but there is no option to improve the situation


VO can accept the offer or reject it (or continue the negotiation with modified request – step 2 again)  
VO can accept the offer or reject it (or continue the negotiation with modified request – step 2 again)  


[[Category:Task_forces]]
[[Category:Task_forces]]

Revision as of 13:33, 12 March 2013

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


<< Resource Allocation Task Force


This page is created by Resource Allocation Task Force. It contains proposal for RA process.

Introduction

Definitions

Pool

Pools of resources repository

Scientific review


Process

Resource allocation process

Step 1 Pools definition preparation

  • NGIs/Sites define pools and register them in EGI " Pools of resources repository".
  • Pools definition may be subject of change according to specific policy.
  • NGIs/Sites are free to modify this repository.

Pool concept

Definition: Let a pool be a specific capacity of resources available for EGI allocation according to defined process under defined conditions

Note: Pools covers any scenarios mentioned ever in RATF including “free hand”, “right to revoke”, “negotiation (elastic pool)”

The pool are defined in the Site/NGI declaration:

  • previously referred as pre-agreement, but it should not require EGI to agree/negotiate
  • can be subject of change in time (some limitation apply)

Pools is just a broad concept of defining/declaring for EGI Resource Allocation.

Pool concept: specification

  1. Part 1: Pool Offer specification
    • Description of what is offered (capacity)
    • Validity in time (when pool is available)
    • Who is responsible for allocation process (NGI / Site)  
    • Process definition (scenario) - selection of predefined processes
    • QoS (opportunistic | assigned share | reserved )
    • Resource specification (technical details)
  2. Part 2: Acceptance criteria for requests
    • Scope for VO (international | national, membership for NGI, discipline)
    • Scientific review (not-required | at least (fair | good | excellent))
    • Publications: required/not required
      • Type of acknowledgements: EGI/NGI/Site
    • Request size incl. also % of allocation eg.:
      • resources should not be allocated more than 10% of the pool per VO
      • resources should not cover more than 50% of the VO request

Pool concept: example

Pool-1 SiteA will offer:

  • up to 100 cores in 2013 as reserved pool (as a whole -> reservation applies to the whole pool not given usage), opportunistic inside pool
  • “free hand” to EGI - EGI has free choice to allocate resources 
  • each VO should not be allocated more than 10% of the pool
  • can be suitable for small resource requests

Pool-2 SiteB will offer:

  • up to 4000 cores between Jun’13 – Feb’14 with assigned fair-share
  • allocation based on negotiations
  • for requests that proved to be:
    • at least good in EGI scientific review
    • has members in NGI X
    • each requests can be supported up to 50%
  • can be suitable for big resource requests

Step 2 Request Submission

Resource allocation process in initiated by VO. VO specifies and submits a resource request.

Step 3 Pool matching

EGI Operator matches the resources request with currently available pools and decide on actions (may be more that one).

Step 4 Actions

Depending on the result from Step 3 "Pool matching" (what is available in "Pools of resources repository") EGI Operator can take following actions: 

Step 4a

In case some pools are matching the request, EGI operator can proceed with allocation according to process specified in the selected pool definition ("free hand", allocation based on negotiations, etc).

Step 4b

In case the are missing resources EGI Operator can forward the request to scientific review.

After scientific review the request goes to step 3 again. 

This step take place only if it is needed, for example:

  • if in "Pools of resources repository" are pools which match but require scientific review
  • to make request more attractive for resource providers

Step 4c

EGI Operator sends back the offer to the VO, in case:

  • it covers the request,
  • it covers the request partially or dosen't cover at all, but there is no option to improve the situation

VO can accept the offer or reject it (or continue the negotiation with modified request – step 2 again)