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:InventoryOfAvailableSoftware"

From EGIWiki
Jump to navigation Jump to search
 
(16 intermediate revisions by 7 users not shown)
Line 1: Line 1:
These two surveys aim at providing an inventory and a quick overview of software that is used to provision existing virtualised infrastructures, and what software is actually available that implements specific Cloud Capabilities exposing which standardised access interfaces.
#REDIRECT [[Fedcloud-tf:WorkGroups:Workbenches]]
 
These surveys are intended to be filled out by the participating Resource Centres and Technology Providers as indicated and as appropriate.
 
== Resource Centre inventory  ==
 
For the description of the Capabilities please refer to the Cloud Integration Profile document available at [https://documents.egi.eu/document/435 https://documents.egi.eu/document/435]
 
To indicate the type of information we are after, a sample hypothetical Resource Centre is provided for guidanc. Note that wherever suitable and possible, make not of any standards that yo know are implemented by the software you deployed for Cloud infrastructure management.
 
<br>
 
{| cellspacing="1" cellpadding="1" border="1"
|-
! scope="col" | Resource Centre
! scope="col" | committed test bed capacity
! scope="col" | Capability:<br>VM Management
! scope="col" | Capability:<br>Data
! scope="col" | Capability:<br>Information
! scope="col" | Capability:<br>Monitoring
! scope="col" | Capability:<br>Accounting
! scope="col" | Capability:<br>Notification
|-
| Happy Cloud, Bratislava
|
*10 servers each with the following capacity
**2 x 8 core Intel
**64 GB RAM
**2 TB local physical disk space each
**4 x dual port 10 Gb copper Ethernet(Intel® 82598EB)
 
| OpenNebula, OCCI based access interface, OVF based VM Image management and provisioning<br>
| FTP over TLS to external storage providers, no local data storage
| BDII, using LDAP query interface and STOMP based data feed (ApacheMQ)
| Nagios based with custom probes
| n/a
| Messaging infrastructure based on STOMP, also available as a service to our users
|-
| CESNET (Miroslav Ruda)
| several servers quickly, more (~10) can be added later this year
| OpenNebula 3.0, to increase heterogenity we could add Eucalyptus 2.0 or Nimbus+Cumulus interface too
| Shared NFS filesystem, GridFTP remote access, can provide S3 Cumulus implementation too
| N/A? OpenNebula web interface?
| Nagios infrastructure is ready, custom probes from other groups can be added quickly. Ganglia/Munin can be added on request.
| N/A? If reporter for standard usage records is implemented, can be deployed.
| N/A? STOMP based EGI messaging infrastructure in available on the site
|-
| UK NGS (David Wallom)
|
*&gt;10 servers
 
| Currently open Eucalyptus 2.0, moving to 3.0 or Openstack, both supplied by Canonical as suppied in Ubuntu Enterprise Cloud
| Data supplied through S3 capable service
| N/A
| NAGIO based through mediated service based probes
| Developed service utilising extended OGF&nbsp;UR&nbsp;schema
| N/A
|-
| Cyfronet (Tomasz Szepieniec, Marcin Radecki)
| for initial setup 12 servers ready, extensions depending on usage
| Most likely OpenNebula 3.0
| Possibility for mounting iSCSI devices in VMs, others to be defined
| Web interface integrated with PL-Grid User Portal
| Nagios integration, experimenting with zabbix
| planned for early 2012 integration with PL-Grid Accounting using OpenNebula 3 accounting components
| N/A
|-
| SARA (Floris Sluiter, Maurice Bouwhuis)
|
|
|
|
|
|
|
|-
| KTH (Zeeshan Ali Shah)
| Initially 2 Servers with Total 4 cores , 16 GB RAM and 1TB storage -
| OpenNebula
| Possibility to mount nfs storage
| OpenNebula Web interface with OCCI and OCA api
| Ganglia (need to experiment)
| N/A
| N/A
|-
| CloudSigma (Micheal Higgins)
|
|
|
|
|
|
|
|-
| GWDG (Philipp Wieder)
|
|
|
|
|
|
|
|-
| Trinity College Dublin (David O'Callaghan, Stuart Kenny)
| 6 servers
| StratusLab, OpenNebula
| Shared NFS filesystem
| n/a
| Nagios
| n/a
| n/a
|-
| FZ Jülich (B. Hagemeier)
| 1 Server (24 Cores, 12GB RAM (will be 24GB later), 1.5TB Disk)
| StratusLab or openStack (to be decided)
| To be defined
| n/a depends on solution above
| Nagios
| n/a
| n/a
|}
 
== Technology Provider inventory  ==
 
Likewise, an inventory survey for Technology Providers to fill in below:
 
For the description of the Capabilities please refer to the Cloud Integration Profile document available at [https://documents.egi.eu/document/435 https://documents.egi.eu/document/435]
 
To indicate the type of information we are after, a sample hypothetical Resource Centre is provided for guidanc. Note that wherever suitable and possible, make not of any standards that yo know are implemented by the software you deployed for Cloud infrastructure management.
 
<br>
 
{| cellspacing="1" cellpadding="1" border="1"
|-
! scope="col" | Technology Provider
! scope="col" | Capability:<br>VM Management
! scope="col" | Capability:<br>Data
! scope="col" | Capability:<br>Information
! scope="col" | Capability:<br>Monitoring
! scope="col" | Capability:<br>Accounting
! scope="col" | Capability:<br>Notification
|-
| StratusLab (Cal Loomis)
| OpenNebula using XML-RPC interface (eventually OCCI); standard OpenNebula VM description for files (eventually OVF); authentication options are username/password, grid certificates and VOMS proxies, others methods should be easy to add
| Proprietary Persistent Disk Store with RESTful interface (eventually also CDMI)
| Planned in architecture, not implemented
| Planned in architecture, not implemented
| Some functionality in OpenNebula, implementation for all StratusLab services planned but not yet implemented
| Prototype implementation in place, allows notification through AMQP if users provide messaging coordinates when starting a virtual machine
|-
| EGI-InSPIRE JRA1 (Daniele Cesini)
| None
| None
| None
|
EGI-JRA1 offers NAGIOS probes integration Capability - No NAGIOS probes development is foreseen within JRA1 (with the exception of very few cases) - Technology Providers are expected to produce NAGIOS probes for their own systems.
 
Availability/Reliability calculation and reporting for sites and services are currently produced outside EGI-JRA1.
 
No information discovery systems are developed within JRA1.
 
| EGI-JRA1 contains a task (TJRA1.4) responsible for the development of an accounting system capable of encompassing the new resource types that will appear in the EGI infrastructure including virtualised resources. See the EGI&nbsp;DoW for TJRA1.4 details.
| None
|}
 
--[[User:Michel|Michel]] 16:54, 13 September 2011 (UTC)
 
[[Category:Fedcloud-tf]]

Latest revision as of 18:06, 2 November 2011