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 for Provider"

From EGIWiki
Jump to navigation Jump to search
 
(43 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== Provider-related activities  ==


This is page describing activities  of providerduring Resource Allocation process.
{{Op_menubar}} {{EGI_RA_menubar}} <br>


Provider edits [https://wiki.egi.eu/wiki/Resource_Allocation#Operations_Level_Agreement_.28OLA.29 OLA] document. On the Figure there is schema presenting OLA document flow between parties (P - provider, B - broker) and available states.<br>
{{TOC_right}}
 
The&nbsp;'''goal'''&nbsp;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.&nbsp;
 
The basic parameters of a RA contact are:&nbsp;'''duration'''&nbsp;and the&nbsp;'''amount of computing and /or storage resources'''. The EGI offer is expressed in a form of&nbsp;'''Resource Pools'''&nbsp;which are declared by Providers using common&nbsp;[[Resource Allocation Metrics Description|metrics]]. The Customers use the same metrics while describing their needs (resource request).
 
= Glossary  =
 
For basic terms used in Resource Allocation process, please go&nbsp;[[Resource Allocation Terminology|here]]
 
= Roles  =
 
*[[Resource Allocation Terminology#Customer|Customer]] - scientist involved in a science project requesting storage or computing resources in EGI, person signing SLA with Resource Provider
*[[Resource Allocation Terminology#Broker|Broker]] - matchmaker and coordinator of RA process
*[[Resource Allocation Terminology#Resource_Provider|Resource Provider]] -Site Manager or NGI Manager responsible for resource allocation on sites in their scope


<br>  
<br>  


[[Image:EGI-RA-OLA-flow.png|OLA state flow]]  
= Provider activities  =
 
== Log in  ==
 
Log in through GOCDB
 
[[Image:Egrant-logowanie.png]]  


<br>  
<br>  


=== 1. Pool creation ===
== Dashboard ==
 
After login to e-Grant you are directed to the dashboard. Here you can administrate yours Pools and handle OLAs.
 
First tab (Home)
 
[[Image:Egrant-tabhome.png]]
 
arranges all OLAs concerning your site(s)
 
*'''INBOX''' - contains SLAs awaiting for your action (negotiation, approval, rejection)
*'''OUTBOX''' - contains SLA documents being negotiated and awaiting for Broker's action (negotiation, approval, rejection)
*'''AGREED SLAs''' - documents containing allocations approved by you (Provider)


<span class="editsection">[[https://wiki.egi.eu/w/index.php?title=Resource_Allocation_Process&action=edit&section=4 edit]]</span> <span class="mw-headline" id="Pool_concept"> Pool concept  </span>
*'''BINDING&nbsp;OLAs''' - documents with allocation being in place. OLAs change their status automatically from 'Agreed' to 'Binding' after Customers approval of RA Request.


'''Definition:'''''Pool '''is a specific '''capacity '''of resources available for EGI allocation according to defined '''process '''under defined '''conditions'<br>'''  
*'''DRAFTS''' - drafts of OLAs<br>
*'''STARRED''' - contains OLAs requiring special attention - starred by Provider.


The pool are defined in the Site/NGI declaration:
<br>


*previously referred as pre-agreement, but it should not require EGI to agree/negotiate
[[Image:Egrant-home.png|600px|Egrant-home.png]]
*can be subject of change in time (some limitation apply)


<br>  
<br>  


''Pool Creation activity is a preparatory step in which Provider declares size and type of resources and time span when they will be available to Resource Allocation process. ''
Second tab (Pools)
 
[[Image:Egrant-bar.png]]<br>
 
allows to administrate Pools offered by Site:


''All the metrics and declared type of pool should be defined.''
*creating new Pool
*editing new Pool
*capacity management for Pool Providers


''This procedure is valid only for adding new pool to EGI Resource Allocation process.''
[[Image:Egrant-pools.png]]<br>


''The pool record is visible in e-GRANT tool.''
== Pool creation <br>  ==


<br>  
<br>  


'''Input/conditions:'''  
1. Click “Create new pool” button. [[Image:Egrant-create.png]]<br>
 
2. Set general Pool properties
 
=== Basic information  ===
 
*'''Enabled/Disabled: '''Provider decides id a Pool is available for the Customer at the moment
*'''Pool Type -''' defines the role of EGI Broker EGI Resource Provider in RA Process for a given resource Pool<br>
**'''Free hand''': the broker, responsible of matching demand and offer, is free to allocate the resources from one RP Pool according to local criteria which aim to optimize usage of available resources and user demand. The Resource Provider delegates the responsibility of accepting a proposed resource allocation to the Broker.
**'''Right to revoke''': the broker matches demand and offer and defines a resource allocation proposal. The RP Pool Manager is responsible of accepting or rejecting the resource allocation proposal of the Broker (EGI.eu), in case of no reply to a Broker's proposal after a default time, the resource allocation proposal is considered to be accepted.
**'''Negotiated''': the broker matches demand and offer and defines a resource allocation proposal. The RP Pool Manager is responsible of accepting or rejecting the resource allocation proposal of the Broker (EGI.eu) and to '''explicitly''' accept or reject.
*'''Quality of Service''' - Resource Provider can offer different types of access to resources according to its local policies and the user requirements: <br>
**'''Level C1: Opportunistic''': Resources are not guaranteed and are subject to local availability.
**'''Level C2: Time allocation''': Resources are available in fair share-like mode for a fixed time period.
**'''Level C3: Reserved allocation''': Resources are exclusively reserved to the VO and the job will be executed immediately after submission.
 
*'''Local Polices'''
*'''Select Entity''' - Site which will deliver resources


*Provider wants to add resources to Resource Allocation process.
[[Image:Egrant-provider-Etap1.png]]<br>
*NGIs/Sites define pools and register them in EGI " Pools of resources repository".
*Pools definition may be subject of change according to specific Resource alloction policy.
*NGIs/Sites are free to modify this repository.


'''Action:'''
<br>


*Provider can add resources to Pool description
When ready, click on "'''Save'''" button.
*Provider can edit pool (modify metrics) in Pool description
*Provider can accept Pool description and make it available to Broker


<br>  
<br>  


[https://wiki.egi.eu/wiki/Pool_Allocation_For_Providers Work instruction.]  
3. Edit pool details ('''all relevant metrics should be filled in''')
 
&nbsp;
 
According to resources offered by a Site, all metrics describing the resources must be specified.<br>4 different resource types can be offered (with regards to P4U activity):
 
*HTC Computing<br>
*HTC Storage<br>
*Cloud Computing<br>
*Cloud Storage<br>
 
<br>To add a resource type choose "Add resources and metrics" button.<br>
 
[[Image:Egrant-addresource.png]]<br>
 
To delete a resource type / non-required metric click on a delete button (cross) next to it.  
 
[[Image:Egrant-removing.png]]<br>


[https://wiki.egi.eu/wiki/Resource_Pool#Resource_allocation_policies Pool type.]
<br>


[https://wiki.egi.eu/wiki/Resource_Pool#Computing:_QoS_levels Quality of Service.]
=== General metrics<br>  ===


[https://wiki.egi.eu/wiki/Resource_Allocation_Metrics_Description Metrics description.]
'''Start Date and End Date '''- when pool will be available for Customers


<br>  
<br>  


Short film [TODO]  
=== HTC Computing metrics  ===
 
{| class="wikitable sortable"
|- class="sortableHeader"
! class="confluenceTh sortableHeader tablesorter-headerSortDown" data-column="0" | <div class="tablesorter-header-inner">Metric name</div>
! class="confluenceTh sortableHeader" data-column="1" | <div class="tablesorter-header-inner">Description</div>
|-
! class="confluenceTh" | '''Max job duration'''
'''<span class="mw-headline">[hours] </span>'''
 
| class="confluenceTd" |
Maximum execution time for a single job. After this time, the job can be interrupted by site administrator.
 
Example: For grant with Max Job Duration metric equal to 72h job using four slots will be canceled after 72 real time hours (the number of slots used by the task does NOT affect the task time)
 
The user can expect (require) that a task with a duration of less than defined in this metric will not be interrupted.
 
|-
! class="confluenceTh" colspan="1" |
'''Min local storage'''
 
'''[<span class="confluence-link">GB</span>]<br>'''
 
| class="confluenceTd" colspan="1" |
The minimum scratch space used in the calculations for each slot involved in job execution.<br> The User can expect that the amount of scratch space specified in this metric will be the minimum available for each slot allocated for the job. The usage of more scratch space than specified may not be possible.
 
|-
! class="confluenceTh" colspan="1" |
'''Min physical memory per core'''
 
'''[<span class="confluence-link">GB</span>]<br>'''
 
| class="confluenceTd" colspan="1" | &nbsp;The minimum RAM that can take a user application (job) on a single slot. The user can expect that if a job submitted uses no more RAM per slot than declared in the metric, it will be executed.
|-
! class="confluenceTh" |
'''Opportunistic computing time'''
 
'''<span class="mw-headline">[HEPSPEC-hours] </span>'''
 
| class="confluenceTd" | Computing time offered on opportunistic basis. Time specified in this metric is a subset of time specified in main metric ''Total computing time''.
|-
! class="confluenceTh" colspan="1" | '''Supported middlewares'''
| class="confluenceTd" colspan="1" | &nbsp;Middlewares supported in Site
|-
! class="confluenceTh" |
'''Total computing time'''
 
'''<span class="mw-headline">[HEPSPEC-hours] </span>'''
 
| class="confluenceTd" | Total computing time offered. This metric is obligatory for computing. By default time offered in this metric is guaranteed. In case metric ''Opportunistic computing time'' is specified, the amount of guaranteed time allocated is lowered by the amount of opportunistic time.
|}
 
<br>
 
=== HTC Storage metrics  ===
 
{| class="wikitable sortable"
|- class="sortableHeader"
! class="confluenceTh sortableHeader tablesorter-headerSortDown" data-column="0" | <div class="tablesorter-header-inner">Metric name</div>
! class="confluenceTh sortableHeader" data-column="1" | <div class="tablesorter-header-inner">Description</div>
|-
! class="confluenceTh" |
'''Opportunistic storage capacity'''
 
'''<span class="mw-headline">[GB] </span>'''
 
| class="confluenceTd" |
The target limit of capacity intended to long-term storage of data, on the basis of guarantees.
 
|-
! class="confluenceTh" |
'''Total storage capacity'''
 
'''<span class="mw-headline">[GB] </span>'''
 
| class="confluenceTd" | By default capacity allocated in this metric is guaranteed. In case metric Opportunistic storage capacity is specified, the amount of guaranteed storage capacity is lowered by the amount of opportunistic capacity.
|}
 
<br>
 
=== Cloud Computing metrics  ===
 
{| class="wikitable sortable"
|- class="sortableHeader"
! class="confluenceTh sortableHeader" data-column="0" | <div class="tablesorter-header-inner">Metric name</div>
! class="confluenceTh sortableHeader" data-column="1" | <div class="tablesorter-header-inner">Description</div>
|-
! class="confluenceTh" |
'''Total number of virtual cores'''
 
'''<span class="mw-headline">[VC] </span>'''
 
| class="confluenceTd" | Total amount of computing capacity available for allocation measured in &lt;i&gt;virtual cores&lt;/i&gt;. EGI virtual core is equal to EC2 virtual core ([http://aws.amazon.com/ec2/ http://aws.amazon.com/ec2/]).
|-
! class="confluenceTh" |
'''Virtual Machines (maximum)'''
 
'''<span class="mw-headline">[VM] </span>'''
 
| class="confluenceTd" | Maximum number of each type of resource template that may be hosted within your service.&nbsp; This may take into account the physical characteristics of your facilities.
|-
! class="confluenceTh" | '''Small Virtual Machines'''
| class="confluenceTd" |
- Number of virtual cores &lt; 2
 
- RAM [GB] &lt; 2
 
- Scratch/ephemeral storage [GB] &lt; 20
 
|-
! class="confluenceTh" colspan="1" |
'''Medium Virtual Machines'''
 
'''<br>'''
 
| class="confluenceTd" colspan="1" |
- Number of virtual cores&nbsp; &lt; 4 (AND)
 
- RAM [GB] &lt; 4 (AND)
 
- Scratch/ephemeral storage [GB] &lt; 40
 
|-
! class="confluenceTh" colspan="1" | '''Large Virtual Machines'''
| class="confluenceTd" colspan="1" |
- Number of virtual cores &lt; 8 (AND)
 
- RAM [GB] &lt; 32 (AND)
 
- Scratch/ephemeral storage [GB] &lt; 80
 
|-
! class="confluenceTh" colspan="1" | '''Extra Large Virtual Machines'''
| class="confluenceTd" colspan="1" |
- Number of virtual cores &gt;= 8 (OR)
 
- RAM [GB] &gt;= 32 (OR)
 
- Scratch/ephemeral storage [GB] &gt;= 80
 
|-
! class="confluenceTh" colspan="1" |
'''Allowed level of oversubscription'''
 
(0% - 50%)
 
| class="confluenceTd" colspan="1" | What is the state level of over provisioning that you are utilising in CPU and possibly memory.
|}
 
=== Cloud Storage metrics  ===
 
{| class="wikitable sortable"
|- class="sortableHeader"
! data-column="0" class="confluenceTh sortableHeader" | <div class="tablesorter-header-inner">Metric name</div>
! data-column="1" class="confluenceTh sortableHeader" | <div class="tablesorter-header-inner">Description</div>
|-
! class="confluenceTh" |
'''Capacity'''
 
'''<span class="mw-headline">[GB] </span>'''
 
| class="confluenceTd" | Total available storage volume made available to the user community, this should also note any over provisioning that is made of storage capability
|-
! class="confluenceTh" |
'''High availability levels'''
 
'''<span class="confluence-link">[yes/no</span>] '''
 
| class="confluenceTd" |
Facilities or capabilities to provide high availability quality of service to user communities
 
|-
! colspan="1" class="confluenceTh" |
'''Connectivity resilience'''
 
'''<span class="confluence-link">[yes/no</span>]'''
 
| colspan="1" class="confluenceTd" | Does the underlying facility have multiple network routes of entry (another form but more specific of high availability).
|}
 
<br>
 
<br>
 
There is a lot of information marks next to the metrics inbox. When you point with mouse cursor on the mark the hint will show you like on example below: [[Image:Engrant help3.jpg]]
 
When ready, choose "'''Save pool'''" button.<span style="color: rgb(0,128,0);">
</span>
 
<br>
 
<br> '''See  [[Image:Youtube.jpg|link=http://youtu.be/Eg9ZCQV7UkQ]]<br>
 
<br>
 
== Editing Pools  ==
 
1. Click "Edit" button. [[Image:Egrant-edit.png]]<br>
 
<br>
 
2. Change chosen metric values.
 
[[Image:Egrant-editpool.png]]  


<br>  
<br>  


=== 2. OLA (re)negotiation  ===
When ready, click '''"Save Pool"''' button.
 
<br>
 
 
See '''[[Image:Youtube.jpg|link=http://youtu.be/Eg9ZCQV7UkQ]]'''
 
== <span class="mw-headline">OLA (re)negotiation and confirmation/rejection</span> ==


''Provider can negotiate metrics in OLA.''
<br>
<div class="message-content">
'''''Provider can negotiate metrics in OLA.'''''  


''Note: PARTY is the actor who operates the procedure; OTHER PARTY means: P in case B runs the actions, or B in case P runs the actions;''  
''PARTY is the actor who operates the procedure; OTHER PARTY means: P in case B runs the actions, or B in case P runs the actions;''  


'''Input/condition:'''  
<br> '''Input/condition:'''  


*OLA are IN-NEGOTIATION and proposal was received from OTHER PARTY
*OLA are IN-NEGOTIATION and proposal was received from OTHER PARTY
Line 79: Line 357:
*PARTY can reject the proposal; then the OLA is set to CANCELLED  
*PARTY can reject the proposal; then the OLA is set to CANCELLED  
*PARTY can send a new proposal (offer changes); then the OLA remains in IN-NEGOTIATION, the new proposal is sent to OTHER PARTY
*PARTY can send a new proposal (offer changes); then the OLA remains in IN-NEGOTIATION, the new proposal is sent to OTHER PARTY
&nbsp;
[https://wiki.egi.eu/wiki/Resource_Allocation Work instruction.]


<br>  
<br>  


[https://wiki.egi.eu/wiki/Resource_Allocation_R Work instruction.]
'''Activity handling in E-grant:'''


Buttons description
1. Choose one of the following actions:


*<u>Negotiate proposal</u> - allows Provider to '''make a counter offer'''. Provider has 7 days from recieving OLA Proposal to conduct this action.
*<u>Accept proposal</u> - finishes negotiation with '''resource allocation proposed by Broker''' (confirmation).
*<u>Reject</u> - finishes negotiation with '''no resources allocated for Customer's SLA&nbsp;'''(rejection)


<br>


<br>  
<br>  


=== 3. OLA confirmation/rejection ===
[[Image:Egrant-RejectConf.png]]
</div>
<br>
 
== <span class="mw-headline">OLA life cycle</span> ==
 
Provider edits [https://wiki.egi.eu/wiki/Resource_Allocation#Operations_Level_Agreement_.28OLA.29 OLA] document. In the Figure there is a schema presenting OLA document flow between parties (''P - provider, B - broker'') and available states.


''OLA confirmation/rejection activity is available only for the right-to-revoke scenario. Provider can reject or confirm OLA manually.''
<br>


''In case of no action, OLA is made AGREED automatically after revoke period.''
[[Image:EGI-RA-OLA-flow.png]]


<br>  
<br>  


'''Input/conditions:'''
== Capacity management  ==


*OLA is in the state AGREED-REVOKABLE
1. Click on "View Pool" button [[Image:Egrant-viewpool.png]]<br>


'''Action:'''  
<br>
 
2. Check information about your Pool (resource metrics) along with resources allocated in your Site.
 
[[Image:Egrant-capacity.png]]
 
<br>
 
<br>
 
= Help and Support  =
 
To avoid problems with using e-Grant remember about using HINTS:
 
'''HELP!''' Button with help is on the left side. It shows hints oriented on the each options like on the example below:
 
[[Image:Egrant help1.jpg|600px|Egrant help1.jpg]]
 
'''Information marks.''' There is a lot of information marks next to the metrics inbox. When you point with mouse cursor on the mark the hint will show you like on example below:  
 
[[Image:Engrant help3.jpg|600px|Engrant help3.jpg]]
 
'''Contact with us.''' The staff at EGI.eu will support the applicant at any point of the process, from request creation to accessing the assigned resources. Please send your questions to: resource-allocation-support@mailman.egi.eu
 
<br>


*Provider can confirm OLA, which makes OLA AGREED
[[Category:ResourceAllocation]]
*Provider can reject OLA, which makes OLA CANCELLED
*Provider can propose changes to the OLA, which makes OLA IN-NEGOTIATION and proposal is sent to B

Latest revision as of 16:12, 21 January 2015

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


EGI Resource Allocation menu:



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

Glossary

For basic terms used in Resource Allocation process, please go here

Roles

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


Provider activities

Log in

Log in through GOCDB

Egrant-logowanie.png


Dashboard

After login to e-Grant you are directed to the dashboard. Here you can administrate yours Pools and handle OLAs.

First tab (Home)

Egrant-tabhome.png

arranges all OLAs concerning your site(s)

  • INBOX - contains SLAs awaiting for your action (negotiation, approval, rejection)
  • OUTBOX - contains SLA documents being negotiated and awaiting for Broker's action (negotiation, approval, rejection)
  • AGREED SLAs - documents containing allocations approved by you (Provider)
  • BINDING OLAs - documents with allocation being in place. OLAs change their status automatically from 'Agreed' to 'Binding' after Customers approval of RA Request.
  • DRAFTS - drafts of OLAs
  • STARRED - contains OLAs requiring special attention - starred by Provider.


Egrant-home.png


Second tab (Pools)

Egrant-bar.png

allows to administrate Pools offered by Site:

  • creating new Pool
  • editing new Pool
  • capacity management for Pool Providers

Egrant-pools.png

Pool creation


1. Click “Create new pool” button. Egrant-create.png

2. Set general Pool properties

Basic information

  • Enabled/Disabled: Provider decides id a Pool is available for the Customer at the moment
  • Pool Type - defines the role of EGI Broker EGI Resource Provider in RA Process for a given resource Pool
    • Free hand: the broker, responsible of matching demand and offer, is free to allocate the resources from one RP Pool according to local criteria which aim to optimize usage of available resources and user demand. The Resource Provider delegates the responsibility of accepting a proposed resource allocation to the Broker.
    • Right to revoke: the broker matches demand and offer and defines a resource allocation proposal. The RP Pool Manager is responsible of accepting or rejecting the resource allocation proposal of the Broker (EGI.eu), in case of no reply to a Broker's proposal after a default time, the resource allocation proposal is considered to be accepted.
    • Negotiated: the broker matches demand and offer and defines a resource allocation proposal. The RP Pool Manager is responsible of accepting or rejecting the resource allocation proposal of the Broker (EGI.eu) and to explicitly accept or reject.
  • Quality of Service - Resource Provider can offer different types of access to resources according to its local policies and the user requirements:
    • Level C1: Opportunistic: Resources are not guaranteed and are subject to local availability.
    • Level C2: Time allocation: Resources are available in fair share-like mode for a fixed time period.
    • Level C3: Reserved allocation: Resources are exclusively reserved to the VO and the job will be executed immediately after submission.
  • Local Polices
  • Select Entity - Site which will deliver resources

Egrant-provider-Etap1.png


When ready, click on "Save" button.


3. Edit pool details (all relevant metrics should be filled in)

 

According to resources offered by a Site, all metrics describing the resources must be specified.
4 different resource types can be offered (with regards to P4U activity):

  • HTC Computing
  • HTC Storage
  • Cloud Computing
  • Cloud Storage


To add a resource type choose "Add resources and metrics" button.

Egrant-addresource.png

To delete a resource type / non-required metric click on a delete button (cross) next to it.

Egrant-removing.png


General metrics

Start Date and End Date - when pool will be available for Customers


HTC Computing metrics

Metric name
Description
Max job duration

[hours]

Maximum execution time for a single job. After this time, the job can be interrupted by site administrator.

Example: For grant with Max Job Duration metric equal to 72h job using four slots will be canceled after 72 real time hours (the number of slots used by the task does NOT affect the task time)

The user can expect (require) that a task with a duration of less than defined in this metric will not be interrupted.

Min local storage

[GB]

The minimum scratch space used in the calculations for each slot involved in job execution.
The User can expect that the amount of scratch space specified in this metric will be the minimum available for each slot allocated for the job. The usage of more scratch space than specified may not be possible.

Min physical memory per core

[GB]

 The minimum RAM that can take a user application (job) on a single slot. The user can expect that if a job submitted uses no more RAM per slot than declared in the metric, it will be executed.

Opportunistic computing time

[HEPSPEC-hours]

Computing time offered on opportunistic basis. Time specified in this metric is a subset of time specified in main metric Total computing time.
Supported middlewares  Middlewares supported in Site

Total computing time

[HEPSPEC-hours]

Total computing time offered. This metric is obligatory for computing. By default time offered in this metric is guaranteed. In case metric Opportunistic computing time is specified, the amount of guaranteed time allocated is lowered by the amount of opportunistic time.


HTC Storage metrics

Metric name
Description

Opportunistic storage capacity

[GB]

The target limit of capacity intended to long-term storage of data, on the basis of guarantees.

Total storage capacity

[GB]

By default capacity allocated in this metric is guaranteed. In case metric Opportunistic storage capacity is specified, the amount of guaranteed storage capacity is lowered by the amount of opportunistic capacity.


Cloud Computing metrics

Metric name
Description

Total number of virtual cores

[VC]

Total amount of computing capacity available for allocation measured in <i>virtual cores</i>. EGI virtual core is equal to EC2 virtual core (http://aws.amazon.com/ec2/).

Virtual Machines (maximum)

[VM]

Maximum number of each type of resource template that may be hosted within your service.  This may take into account the physical characteristics of your facilities.
Small Virtual Machines

- Number of virtual cores < 2

- RAM [GB] < 2

- Scratch/ephemeral storage [GB] < 20

Medium Virtual Machines


- Number of virtual cores  < 4 (AND)

- RAM [GB] < 4 (AND)

- Scratch/ephemeral storage [GB] < 40

Large Virtual Machines

- Number of virtual cores < 8 (AND)

- RAM [GB] < 32 (AND)

- Scratch/ephemeral storage [GB] < 80

Extra Large Virtual Machines

- Number of virtual cores >= 8 (OR)

- RAM [GB] >= 32 (OR)

- Scratch/ephemeral storage [GB] >= 80

Allowed level of oversubscription

(0% - 50%)

What is the state level of over provisioning that you are utilising in CPU and possibly memory.

Cloud Storage metrics

Metric name
Description

Capacity

[GB]

Total available storage volume made available to the user community, this should also note any over provisioning that is made of storage capability

High availability levels

[yes/no]

Facilities or capabilities to provide high availability quality of service to user communities

Connectivity resilience

[yes/no]

Does the underlying facility have multiple network routes of entry (another form but more specific of high availability).



There is a lot of information marks next to the metrics inbox. When you point with mouse cursor on the mark the hint will show you like on example below: Engrant help3.jpg

When ready, choose "Save pool" button.



See Youtube.jpg


Editing Pools

1. Click "Edit" button. Egrant-edit.png


2. Change chosen metric values.

Egrant-editpool.png


When ready, click "Save Pool" button.



See Youtube.jpg

OLA (re)negotiation and confirmation/rejection


Provider can negotiate metrics in OLA.

PARTY is the actor who operates the procedure; OTHER PARTY means: P in case B runs the actions, or B in case P runs the actions;


Input/condition:

  • OLA are IN-NEGOTIATION and proposal was received from OTHER PARTY


Actions:

  • PARTY can agree on the proposal; then the OLA is set AGREED
  • PARTY can reject the proposal; then the OLA is set to CANCELLED
  • PARTY can send a new proposal (offer changes); then the OLA remains in IN-NEGOTIATION, the new proposal is sent to OTHER PARTY

 

Work instruction.


Activity handling in E-grant:

1. Choose one of the following actions:

  • Negotiate proposal - allows Provider to make a counter offer. Provider has 7 days from recieving OLA Proposal to conduct this action.
  • Accept proposal - finishes negotiation with resource allocation proposed by Broker (confirmation).
  • Reject - finishes negotiation with no resources allocated for Customer's SLA (rejection)



Egrant-RejectConf.png


OLA life cycle

Provider edits OLA document. In the Figure there is a schema presenting OLA document flow between parties (P - provider, B - broker) and available states.


EGI-RA-OLA-flow.png


Capacity management

1. Click on "View Pool" button Egrant-viewpool.png


2. Check information about your Pool (resource metrics) along with resources allocated in your Site.

Egrant-capacity.png



Help and Support

To avoid problems with using e-Grant remember about using HINTS:

HELP! Button with help is on the left side. It shows hints oriented on the each options like on the example below:

Egrant help1.jpg

Information marks. There is a lot of information marks next to the metrics inbox. When you point with mouse cursor on the mark the hint will show you like on example below:

Engrant help3.jpg

Contact with us. The staff at EGI.eu will support the applicant at any point of the process, from request creation to accessing the assigned resources. Please send your questions to: resource-allocation-support@mailman.egi.eu