2019-bidding/cloud

Main

EGI.eu operations services

Support

Documentation

Tools

Activities

Performance

Technology

Catch-all Services

Resource Allocation

Security

EGI Services and Service Management Support menu:

Bids •

Old Bids •

Performance •

Go back to the EGI Services Bidding page.

EGI Computing and Storage call

Introduction

EGI aims to bring cloud compute, storage and HPC providers into the INFRAEOSC-07a1 project to deliver baseline compute capabilities directly for users, for higher level & generic platforms and for science discipline-specific data analytics services.

This call invites providers to express their interest in participating in the project as an IaaS cloud provider, HPC centre, or other compute site that is willing to support users, platforms, and analytics services.

Responses are expected to include both a compute, and storage offer. (E.g. combine ‘Cloud compute’ with ‘Online file storage’; OR Combine ‘HPC compute’ with ‘Online file storage’)

Technical description

Compute

Cloud Compute

Cloud Compute providers offer IaaS (optionally also Bare-Metal as a Service) access to compute resources as Virtual Machines that can run any user-defined software (including operating system and applications). The service also includes management of block storage that can be associated to the VMs and network management to provide connectivity between VMs and external networks.

Providers of the service must be integrated, or must have the willingness to connect their setup to the following EGI services:

• Check-in for user authentication and authorisation
• Application DB to be able to pull virtualised applications into their own cloud for the benefit of the users they are committed to serve.

Additionally, the providers joining as generic or thematic clouds must connect with:

• Accounting repository to provide data about the resource consumption of EGI users at their site.
• Configuration Database and Messaging System to provide basic information about the cloud site for the Argo monitoring system.
• Monitoring to allow the periodic execution cloud-specific test probes on the site to alert the site and users about malfunctioning.
• Helpdesk to be able to receive alerts about the failures of monitoring tests, and requests from the EGI users.

EGI provides ready-to-use software components to perform the above integration for OpenStack or OpenNebula clouds. These components rely on public APIs of the IaaS system and use Check-in accounts for authenticating into the provider. Other IaaS platforms may be used if these are:

• Integrated with Check-in, so EGI users can login into the system
• Integrated with the core activities and services listed above
• Supported by the IM orchestrator, used by AppDB

The Cloud Container Compute is realised as a set of specific VM images with docker and Kubernetes support and the automated configuration of these using EC3/IM.

HPC compute

Those providers willing to offer computing capacity to EGI but not following an IaaS model, (e.g. for those resources with not easy-to-virtualise hardware like HPC sites, high performance networks, GPGPUs or providing services through job-submission mechanisms) can apply for this part of the call. With these providers we aim to reach a pilot setup in INFRAEOSC07a1 for streamlined access and integrated use of these resources in the project. The interested providers should reach a cloud-like service during the project focusing on four areas:

• Accessibility: Enable user single sign-on across the EOSC Portal and the HPC and Cloud systems of this project.
• Access enabling for users: Define and operate a resource allocation process that is responsive for use cases that require access to both HPC and Cloud systems.
• Data staging: Configure the project data transfer service and the HPC and cloud systems in a way that data can be moved between HPC and cloud systems of the project.
• User guides: Develop user guides that provide assistance for the integrated use of HPC and Cloud systems of the project.

Storage

File Storage

File Storage providers offer file-based access to storage through various protocols (including but not only gridftp, SRM, xrootd or webdav) and are integrated with Check-in for authentication. Providers of the service must integrate with the following EGI service:

• Check-in for authentication and authorization of users.

Additionally, the providers joining as generic or thematic clouds must integrate with:

• Accounting repository to provide data about the resource consumption of EGI users at their site.
• Configuration Database and Messaging System to provide basic information about the cloud site for the Argo monitoring system.
• Monitoring to allow the periodic execution cloud-specific test probes on the site to alert the site and users about malfunctioning.
• Helpdesk to be able to receive alerts about the failures of monitoring tests, and requests from the EGI users.

Object Storage

Object Storage providers offer object-based access to storage through HTTP based APIs, such as Swift or S3, and integration with Check-in for user authentication. Providers of the service must integrate with the following EGI service:

• Check-in for authentication and authorization of users.

Additionally, the providers joining as generic or thematic clouds must integrate with:

• Accounting repository to provide data about the resource consumption of EGI users at their site.
• Configuration Database and Messaging System to provide basic information about the cloud site for the Argo monitoring system.
• Monitoring to allow the periodic execution cloud-specific test probes on the site to alert the site and users about malfunctioning.
• Helpdesk to be able to receive alerts about the failures of monitoring tests, and requests from the EGI users.

EGI provides ready-to-use software components that enable integration for OpenStack. These components rely on public APIs of the IaaS system and use Check-in accounts for authenticating into the provider.

Capacity

The total capacity of an expression of interest may be provided by a set of partners (e.g. several resource centers within a NGI or several NGIs together). In that case a single partner will lead and coordinate operations for the whole set, while others will be considered as suppliers of capacity. Capacity allocation and reimbursement of usage through the project will follow the rules summarised in the table below:

	Generic Clouds	Thematic Clouds	Integrated Clouds
Capacity allocation	To providers of pre-agreed platforms. To EOSC portal users	To providers of pre-agreed platforms. Possibly to new EOSC users based on custom decision (e.g. discipline)	To ‘local’ users
SLAs	SLAs managed by the project	SLAs managed by the project	SLAs managed locally
Reimbursement of use	Reimbursement of 50% of the EOSC-related usage costs	Reimbursement of 25% of EOSC-related usage cost	No reimbursement of usage cost
Presence in EOSC Marketplace	As part of a European platform	As part of a European platform	As individual provider
Status in consortium	Full beneficiary	Full beneficiary	Associated partner with travel budget

Expressions of interest covering generic and thematic clouds are expected to provide as minimum aggregated capacity from the suppliers:

• 1000 cores / 2GB RAM per core available as IaaS VMs (Cloud Compute)
• 1PB of storage available as online storage (object and/or file storage)
• Significant GPGPUs capacity available for IaaS VMs (Cloud Compute)

Operations

Providers of the generic and thematic cloud categories must:

• Comply with the RC Operational Level Agreement (OLA)
• Comply with any further Operational Level Agreements (OLAs) established to support the existing SLAs with customers.

The integration with Check-in requires compliance to a set of policies as described in the AAI guide for SPs.

IT Service Management compliance

• Key staff who deliver services should have foundation or basic level ITSM training and certification.
  • ITSM training and certification could include FitSM, ITIL, ISO 20000 etc.
• Key staff and service owners should have advanced/professional training and certification covering the key processes for their services.
• Providers should have clear interfaces with the EGI SMS processes and provide the required information.
• Providers should commit to improving their management system used to support the services they provide.

Support

As specified in the OLA, generic and thematic clouds must provide support through the EGI Helpdesk.

Service level targets

For Generic/Thematic clouds:

• Minimum availability/reliability: 95%/95%

Response to incident records in GGUS within support hours: Medium