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 "Fedcloud-tf:Blueprint EGI Federated Clouds"

From EGIWiki
Jump to navigation Jump to search
m
Line 12: Line 12:
# Different VMs needed based on underlying Infrastructure such as 64 vs 32bits Or VT enabled  plus Xen vs KVM
# Different VMs needed based on underlying Infrastructure such as 64 vs 32bits Or VT enabled  plus Xen vs KVM
# Contextualization i.e. how users should login to this vm , how his public key transfer and active to login as root to this vm
# Contextualization i.e. how users should login to this vm , how his public key transfer and active to login as root to this vm
From a user perspective (WeNMR contribution) we would like to:
# Be able to install software on the pre-defined VM images (under the user account)
# Be able to save those images (at least for a pre-defined time) (i.e. no new installation each time we wish to use the image)


== Scenario 2: Running my data and VM in the Infrastructure  ==
== Scenario 2: Running my data and VM in the Infrastructure  ==

Revision as of 19:40, 21 October 2011


Introduction

Six scenarios for minimal functionality

Scenario 1: Running a pre-defined VM Image

Leader: Michel Drescher, EGI; Matteo Turilli, Oxford e-Research Centre

Following need to be considered with this scenario

  1. Trust level and Auditing of the VM (since it has to run as Root access)
  2. Different VMs needed based on underlying Infrastructure such as 64 vs 32bits Or VT enabled plus Xen vs KVM
  3. Contextualization i.e. how users should login to this vm , how his public key transfer and active to login as root to this vm

From a user perspective (WeNMR contribution) we would like to:

  1. Be able to install software on the pre-defined VM images (under the user account)
  2. Be able to save those images (at least for a pre-defined time) (i.e. no new installation each time we wish to use the image)

Scenario 2: Running my data and VM in the Infrastructure

Leader: Micheal Higgins, CloudSigma

WeNMR use cases

  1. Using VMs prepared with Gromacs and some other software to run MD simulations for educational purpose, possibly on multi-core VMs.
  2. Validating biomolecular NMR structures using VirtualCing, a VMware VM equipped with a complex suite of ~25 programs. A presentation of the current deployment at the Dutch National HPC Cloud is available here. The cloud usage framework is based on a pilot job mechanims making use of the ToPoS tool. Therefore, such a framework would naturally allow for execution of VirtualCing tasks across multiple cloud providers. Do notice that the framework is independent on the cloud access interface: it would work also with simple grid jobs, as far as the user-defined (or VO manager defined) VirtualCing VM is available at the grid site e.g. in a SE (or in the VO software area mounted by the WNs) and the grid job is allowed to start the VM. Technical details about its current implementation are available here.

Scenario 3: Integrating multiple resource providers

Leader: Floris Sluiter, SARA

Scenario 4: Accounting across Resource Providers

Leader: John Gordon, STFC

Scenario 5: Reliability/Availability of Resource Providers

Leader: Daniele Cesini, INFN

Scenario 6: VM/Resource state change notification

Leader: Peter Solagna, EGI

Key Capabilities

VM Management

Data access

Information discovery

Accounting

Monitoring

Notification

References

  1. http://go.egi.eu/435: Draft of Federated Clouds profile
  2. http://go.egi.eu/803: Task Force presentations at the EGI Technical Forum 211, Lyon


--Michel 14:40, 26 September 2011 (UTC)