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 "Federated Cloud resource providers support"

From EGIWiki
Jump to navigation Jump to search
Line 19: Line 19:
== Why joining the EGI Cloud? ==
== Why joining the EGI Cloud? ==


* To support international [https://www.egi.eu/use-cases/ scientific communities linked to EGI].  
* To support international [https://www.egi.eu/use-cases/communities linked to EGI].  
* To align access interfaces and operational model of your cloud with international good practices
* To align access policies and operational model of your cloud with international good practices.
* To participate in e-Infrastructure projects (H2020, EOSC) as an IaaS cloud provider
* To participate in e-Infrastructure projects (H2020, EOSC) as an IaaS cloud provider.
*  
* To share and reuse best practices for supporting research use cases with cloud resources.


== Joining the EGI Federated Cloud as resource provider  ==
== Joining the EGI Federated Cloud as resource provider  ==

Revision as of 08:53, 13 September 2019

Overview For users For resource providers Infrastructure status Site-specific configuration Architecture



Overview

EGI Cloud providers are institutions and companies that contribute providing access to their cloud infrastructure via the Federation.

Resource providers are free to use any Cloud Management Framework (CMF) exposing interfaces compliant with the Federated Cloud Architecture. At the moment this compliance is guaranteed by the following CMFs:

  • OpenStack (optionally with OCCI)
  • OpenNebula with OCCI

IaaS joining the EGI Federation need to configure EGI Check-in as Identity providers, this allowing EGI users to access and use the services. On top of that a set of federation enabling tools will interact with your provider to support:

  • Accounting, to expose usage information to the central EGI accounting database
  • VM Image Management, to enable VM images from the supported communities to be replicated at the sites automatically
  • Information Discovery, to expose information about the available resources

If you have any comments on the content of these pages, please contact operations @ egi.eu.

Why joining the EGI Cloud?

  • To support international linked to EGI.
  • To align access policies and operational model of your cloud with international good practices.
  • To participate in e-Infrastructure projects (H2020, EOSC) as an IaaS cloud provider.
  • To share and reuse best practices for supporting research use cases with cloud resources.

Joining the EGI Federated Cloud as resource provider

IaaS providers are very welcome to join the EGI Federated Cloud becoming Resource Centres (RC) and joining the Federated Cloud Task Force to contribute to the design, creation and implementation of the federation.

The steps you should follow to join are:

1. Contact EGI operations team (operations at egi.eu) , expressing interest in joining EGI and providing few details about:

  • the projects you may be involved in as cloud provider
  • the user communities you want to support (a.k.a. Virtual Organisations, VO). You can also support the 'long-tail of science' through the access.egi.eu VO, or any of the exiting VOs of EGI.
  • the technologies (Cloud Management Framework) you want to provide (see the Federated Cloud Architecture for more details)
  • details on the current status of your deployment (to be installed or already installed, already used or not, how it is used, who uses the services,...)

EGI will provide proper guidance through all the following steps until the RC gets certified.

2. Perform technical integration with EGI, following these two steps (can go in parallel):

  • Install and configure the necessary connectors on top of your IaaS to get integrated into the EGI infrastructure. Besides AAI, these connectors use the existing APIs of your IaaS to interact with EGI without interfering in your daily operations.
  • Register and certify as a Resource Centre. In particular, the registration makes the EGI infrastructure aware of the new resources you offer, while the certification takes care of validating the registration itself and testing the behaviour of the services. In the context of the registration, you will become part of a Resource Infrastructure (such as NGIs, EIRO, or a multi-country Resource Infrastructure.

Questions and Answers

Do I lose control on who can access my resources if I join federated cloud?

No

EGI uses the concept of Virtual Organisation (VO) to group users. The resource provider has complete control on which VOs wants to allow into the resources and which quotas or restrictions to assign to each VO. In the case of OpenStack, each VO is mapped to a regular OpenStack project that can be managed as any other and are isolated to other projects as you have configured in your system. Although not recommended, you can even restrict the automatic access of users within a VO and manually enable individual members.

How many components do I have to install?

Depending on your cloud management framework and the kind of integration this will vary.

In general, the federation requires your cloud management framework to be configured to support Federated AAI with EGI Check-in. This may require changes in your current setup. Other components are designed to consume your cloud management framework APIs and do not require modification of your provider. For OpenStack, these components can be run on a single VM that encapsulates them for convenience.

Which components of my cloud will interact with the federated cloud components?

For OpenStack they are:

  • Keystone
  • Nova
  • Glance
  • Swift (optional)

Users will also interact with:

  • Neutron
  • Cinder

to perform their regular activities.

How my daily operational activities will change?

For the most part daily operations will not change.

A resource centre part of the EGI Federation, and supporting international communities, needs to provide support through the EGI channels. This means following up GGUS tickets submitted through helpdesk.egi.eu. This includes requests from user communities and tickets triggered by failures detected by the monitoring infrastructure.

A resource centre needs to maintain the services federated in EGI properly configured with the EGI AAI.

The resource centre will have to comply with the operational and security requirements. All the EGI policies aim at implementing service provisioning best practices and common requirements. EGI operations may promote campaigns targeted to mitigate security vulnerabilities and to update unsupported operating system and software. These activities are part of the regular activities of a resource centre anyways (also for the non-federated ones). EGI and the Operations Centres coordinate these actions in order to have them implemented in a timely manner.

In summary, most of the site activities that are coordinated by EGI and the NGIs are already part of the work plan of a well-maintained resource centre, the additional task for a site manager is to acknowledge to EGI that the task has been performed.