wp4 – cloud platform & provisioning
DESCRIPTION
WP4 – Cloud Platform & Provisioning. Technical Review Period 1 Michel van Adrichem , Mick Symonds, Josep Martrat Atos. WP4 Objectives. - PowerPoint PPT PresentationTRANSCRIPT
WP4 – Cloud Platform & Provisioning
Technical Review Period 1Michel van Adrichem, Mick Symonds, Josep Martrat
Atos
This document produced by Members of the Helix Nebula consortium is licensed under a Creative Commons Attribution 3.0 Unported License.Permissions beyond the scope of this license may be available at http://helix-nebula.eu/. The Helix Nebula project is co-funded by the European
Community Seventh Framework Programme (FP7/2007-2013) under Grant Agreement no 312301
WP4 ObjectivesAssemble the resources needed to meet the requirements provided by WP3, plus the tools necessary to configure, deploy, monitor and evaluate the flagship.
Specific goalsTo produce, validate and make available a method of determining and describing a suitable service offering to meet user requirements for the Science Cloud (beyond tools).To produce, validate and make available a method of matching services to requirements in any specific case.To deploy that method in the three flagships, based on the specific requirement statements for each flagship (from WP3), in order to allow evaluation (by WP9) of the approach.
- 2 -
The high level process
The matching process
This high level method is part of the process description to match services to requirements resulting from Work Package 4
- 3 -
Effort ContributionLead Beneficiary: Atos
WP410%
Person-Months per Participant
Participant Person-months
EGI.eu 3.00
T-Systems 3.00
Atos 12.00
CloudSigma 3.00
TOTAL 21.00PM23PM11PM1
WP4 – 21 pm WP4 – 1pm
Extension of WP4 into P2 requested to update D4.3: ‘Cloud Provisioning Report’ with the evaluation of the pilots after they are completed.
- 4 -
Scientific/technical achievements and their impact
The main objective of Work Package 4 (service provisioning) is to produce, describe and analyse a suitable service offering. WP4 is at the centre of the project execution since it liaises:
Work Package 3 where requirements for the flagships use cases are elicited and Work Package 5 where the response to those requirements is instantiated for each of these use-case.
The main contribution of Work Package 4 to Helix Nebula has been in bringing knowledge and experience of how “services” are actually delivered. This has included, for instance, documentation of the options and recommendations regarding the establishment of a “broker” role.
Work Package 4 has documented many of the service aspects, which have also appeared in the documents produced by the Service Architecture (ServArch) team.
- 5 -
Requirements perspectives
Requirements from
Requirements perspective
Technical requirements
Service requirements
Financial / Business
requirements
Current flagshipsRequirements
availableRequirements were
neededRequirements were
needed
Future flagships Need to allow for new requirements
Need to allow for new requirements
Need to allow for new requirements
Potential future users
Need to predict industry-standard requirements (e.g.
from ODCA)
Need to predict industry-standard requirements (e.g.
from ODCA)
Need to predict industry-standard requirements (e.g.
from ODCA)
[1] Open Data Center Alliance, see: http://www.opendatacenteralliance.org/
Requirements situation at the start of the project
Example of knowledge and experience of how “services” are actually delivered contributed by Work Package 4 to Helix Nebula
- 6 -
Deliverables and Milestones – Period 1Type Del. no Name Nature Dissemination
levelDate Delivered
Deliverable 4.1 Access to the Services Defined for WP5 Other RE 17/01/2013
http://www.helix-nebula.eu/index.php/media-room/videos.htmlDeliverable 4.2 Cloud Provisioning: Case histories of
decisions takenReport PU 30/05/2013
Deliverable 4.3 Cloud Provisioning Report Report RE 26/06/2013
Milestone 9 Supplier workshop to validate inputs and service matching as part of GA1
Report PU 18/12/2012
Milestone 10 Workshop to gather learnings and improvement opportunities
Report PU 11/03/2013
- 7 -
Overall modifications, corrective actions, re-tuning of objectives
Initially WP4 followed the Waterfall approach as described in the Seventh Framework ProgrammeDuring the execution it became clear that a more iterative and innovative approach resulted in a more efficient and effective way in product deliveryLearning in relative short cycles is an efficient way to deliver products with a higher qualityFollowing an iterative approach means:
extra effort is needed to schedule additional product and review cyclesextra effort is needed for monitoring the development in requirements (Requirements management)release management must be in place in order to have control on the progress and development of versions of the deliverables.
- 8 -
Exploitation and use of foreground
Knowledge and experience of how Blue Box services are actually delivered, and documentation of options and recommendations regarding the establishment of a “broker” role, were the main contributions of Work Package 4 to Helix Nebula
Documentation of service aspects (see also documents produced by the Service Architecture (ServArch) team)
Contributed to the identification and description of the roles in the HN ‘value chain’, elaborated in Work Package 7 (business models)
Above mentioned aspects are crucial for the establishment of Helix Nebula as a viable and sustainable service, incorporating both commercial and public contributions
- 9 -
Cooperation modelsContribution by Work Package 4 to the identification and description of the roles in the HN ‘value chain’, elaborated in Work Package 7 (business models)
- 10 -
Implementation without Blue Boxduring Proof of Concept
Without a Blue Box each customer and supplier have a point-to-point connection resulting in M x N relationships
- 11 -
Helix Nebula Proofs of ConceptLearnings from the Supplier perspective
The technology works: required workloads from participating scientific organisations can be successfully deployed in cloud environmentsThe Demand sides each had slightly different requirements, and Supply-side clouds all differ significantly in implementation, even those sharing common hypervisors
so each user-supplier case was effectively a bespoke deploymentSoftware requirements (“legacy”) from the demand side can be complex and are critical to understanding POC requirements and ensuring a successful outcomeA common API is desired and would significantly streamline driving deployments across multiple cloudsThe ability to move VM images between clouds and potentially convert VM formats is needed for better cross cloud deploymentDifferences between private and public deployment models on the supply side are important and influence various aspects of PoC’s directly
i.e. WAN, open Internet or VPN accessNetworking between demand-side institutions and supply-side providers, and between multiple supply-side providers, is an important success criteriaAreas such as service structure/architecture require further exploration
Proof of Concepts were successful
All PoC environments completed successfully by most suppliersClouds can deliver the facilities required to fulfil the scientific requirements
starting at the IaaS level
Inter-Supplier communication (open and often) was crucial to successWe now/then need(ed) to move on to improving the overall experience
making the multi-supplier environment more coherentperformance optimisation and price/performance not yet considered
Points of learning for further addressingcommon interfaces: e.g. unified APIserver image management and conversion, especially to cope with bespoke/ legacy software usageinter-cloud workload assignment and scalingnetworking: bandwidth and interfaces, charging algorithmsbreaking the demand-supply scaling “chicken and egg” syndromecommon charging and billing mechanisms not yet in sight
Blue Box functionsEach customer and supplier have a single connection to
the Blue Box resulting in M + N relationships
- 14 -
Blue Box use in pilotImplementing two Blue Boxes in the pilot improves the evaluation by adding
practical experience to the study before the pilot
- 15 -
Interaction with other FP7 projectsand stakeholders outside the consortium
Taking part in the Select Industry Group (SIG) discussions, established by the EC as part of the European Cloud Partnership (ECP) programme.
Active member of the Open Data Centre Alliance (ODCA http://www.opendatacenteralliance.org/) which is developing common user requirements, leading to implementation within standards, for many of these subjects.
Use has been made of knowledge gained from the development of other cloud management projects, such as Optimis (www.optimis-project.eu), BonFire (www.bonfire-project.eu) and Stratuslab (stratuslab.eu) for interaction with FP7 projects.
- 16 -
Contribution to the disseminationof project results
Most of the documents produced by Work Package 4 (and the associated documents produced by the ServArch team) have been published on the Helix Nebula web site.
Service aspects have been discussed at a number of internal Helix Nebula events and externally, most recently at IM2013 (http://www.bdim.net/2013/). WP4 has also contributed to position the HN initiative in several conferences such as EUDAT with data infrastructure providers. These have helped promulgate the services, as opposed to just technology, thinking that is necessary for such developments to succeed.
Work Package 4 has also contributed to the Communications Plan and reviewed other deliverables
- 17 -
SummaryWP4 very useful for obtaining a clear statement of the Requirements, beyond the technical configurations requiredActed as a linking point between gathering requirements (WP3) and flagship deployment (WP5)Highlighted the need for service aspects, rather than technical, aspects, especially as regards federation and brokerage
Necessary to act as ambassadors for the need to define a complete Service Architecture, most of which was done outside the scope of this WP
Also highlighted the business questions and need for business requirements that arose from WP7
- 18 -