1. Scientific Cloud Computing: Present & Future Charles (Cal) Loomis (CNRS/LAL & SixSq Sàrl) INFN CNAF, Bologna, Italy (22 May 2013)

2. 2 Cloud Marketing “Cloud” is currently very trendy, used everywhere  Many definitions that are often incompatible  Used (often) to market pre-existing (non-cloud) software Commodity Computing (Sun) Utility Computing (IBM, HP, …) Amazon EC2 Amazon EBS Mature Virtualization Simple APIs Excess Capacity

3. 3 In two pages NIST defines:  Essential characteristics  Deployment models  Service models What is a Cloud? http://csrc.nist.gov/publications/ nistpubs/800-145/SP800-145.pdf

4. 4 On-demand self-service  No human intervention Broad network access  Fast, reliable remote access Rapid elasticity  Scale based on app. needs Resource pooling  Multi-tenant sharing Measured service  Direct or indirect economic model with measured use Essential Characteristics http://csrc.nist.gov/publications/ nistpubs/800-145/SP800-145.pdf

5. 5 Private  Single administrative domain, limited number of users Community  Different administrative domains with common interests & proc. Public  People outside of institute’s administrative domain Hybrid  Federation via combination of other deployment models Deployment Models http://csrc.nist.gov/publications/ nistpubs/800-145/SP800-145.pdf

6. 6 Software as a Service (SaaS)  Direct (scalable) hosting of end user applications Platform as a Service (PaaS)  Framework and infrastructure for creating web applications Infrastructure as a Service (IaaS)  Access to remote virtual machines with root access Service Models http://csrc.nist.gov/publications/ nistpubs/800-145/SP800-145.pdf

7. 7 Advantages  No software installation  Universally accessible Disadvantages  Questions about data access, ownership, reliability, etc.  Integration of services & novel uses of data are (often) difficult Trends  Social scientific computing  Service APIs to allow integration  PaaS Software as a Service (SaaS)

8. 8 Advantages  Programmers take advantage of integrated load balancing, automatic failover, etc. Disadvantages  Restricted number of languages  Applications strongly locked to a particular provider Trends  Dearth of “pure” PaaS offers  Encroachment from both SaaS and IaaS sides Platform as a Service (PaaS)

9. 9 Advantages  Customized environment with “root” access  Easy access to scalable resources Disadvantages  Variety of APIs and interfaces  VM image creation is difficult and time-consuming Trends  Lots of specialized cloud providers appearing  Orchestration pushing into PaaS space Infrastructure as a Service (IaaS)

10. 10 Focus: Infrastructure as a Service

11. 11 State of the Art Commercial Provider: Amazon Web Services (AWS)  Leading and largest IaaS service provider  Improving and adding new services at a phenomenal rate  Almost all IaaS providers use AWS-like service semantics, but differentiate based on price, SLAs, location, etc. Commercial Cloud Distribution: VM-ware  VM-ware: extremely good and complete, but very expensive  Provide ESXi virtual machine host for free Open Source Cloud Distributions  Essentially none in 2004; now easily a dozen different distributions  StratusLab, WNoDeS, …, OpenStack, OpenNebula, CloudStack  Very different levels of maturity, stability, scalability, etc.

12. 12 Why are cloud technologies useful? For (scientific) users  Custom environment: no rewriting or porting applications to fit into a resource provider’s environment  Simple access: most providers use a REST or RPC API allowing simple access from all programming languages  Reasonable cost: only pay for what resources are used, especially attractive for individuals/groups that do not have large, existing hardware investment

13. 13 Why are cloud technologies useful? Separation of responsibilities  Hardware / Services / Platforms / Users  People at each layer can focus on their responsibilities with minimal interactions with people in the other layers. Resource Providers  Better utilization of shared resource because wider range of applications (and disciplines) can use the cloud  With hybrid cloud infrastructures, providers can outsource excess demand to other providers

14. 14 Trend for Scientific Computing Will we all just be users of the Amazon cloud? Pendulum swinging towards large data centers with “fat” machines  These can offer elastic cloud services at a reasonable price  With scientific clouds there is low barrier to entry and users can maintain administrative control of services and data  Providing shared resource between scientific disciplines much easier because of virtualization Migration will be gradual…

15. 15 Overcoming inertia… Users  How to use virtual machines to get my work done?  How to structure, store, access, and protect data?  Realize shared infrastructures with customized env. are possible Application Developers  How to use cloud techniques to improve my applications?  … and my development workflows?  Applications can be services (with assoc. pluses and minuses) Data Centers  Reuse existing (commodity) hardware investments  Take advantage of (and train) existing system administrators  How to manage/use a (private, community, public) cloud? Significant benefits from cloud even without large scale elasticity!

16. 16 Challenges

17. 17 Elasticity Can we have infinite elasticity with limited resources? “Local” solutions  Economic models to avoid hitting infrastructure limits?  Spot instances and/or different service classes?  Aside: IPv6 addressing is necessary for large (scientific) clouds Federated solutions  Hybrid (scale-out) infrastructures?  Higher-level brokers or orchestrators? Cannot have elasticity without some kind of accounting!

18. 18 Data Management (Legal) Transfer and treatment of data across borders  Differing legal protections in different jurisdictions  Legal constraints for data locality (banking, medical data)  Unclear responsibilities for data: guardian, custodian, owner, etc.  Europe working hard to come to a consistent legal framework Protection of data in the cloud  Consistent access controls for all data locations  Guarantees about data protection from cloud provider personnel  Reliability of the provider’s storage  Knowledge about provider’s policies for data protection

19. 19 Data Management (Technical) Efficient exploitation of large datasets  Need significant computing next to storage, AND/OR  High bandwidth remote access Locality matters  Sometimes it is inconvenient to transfer raw data away from instrument  Clouds can be used to reduce data locally before transfer “Open Data” requirements  Cloud may help meet such requirements  Does not remove need for well defined dataset metadata and format  Need long-term funding for the curation of those datasets

20. 20 Security How to maintain the security of a cloud infrastructure? Shifting some responsibility to users:  Users have root access and must secure services within their VMs  Users have less security experience  need for education & help  Dynamic network configurations can help improve security Changing expectations from administrators:  Leave firewall policies to users running VMs  Should not expect to run security software inside of VMs  Need to enhance monitoring to discover abnormal behavior

21. 21 Image Management Image metadata  What does an image contain (OS, services, configuration, etc.)?  What versions of the kernel, software, etc. are included?  Who is responsible and/or supports a given image?  How do I identify a given image? Creating machine images  How can an image be created for multiple clouds?  What do I have to do to create a secure machine image? Sharing images  How can I make my images available to others?  Can I parameterize my images to make them useful to more people?  Can the images be transported and used efficiently?

22. 22 Vendor Lock-in vs. Federation Common API  Fully interoperable API avoids duplication in cloud control software  Has very limited impact on applications and services in the cloud  Current (quasi-) standards: EC2, OCCI, CIMI, CDMI, … Common Semantics  Semantics determine how apps and services operate in the cloud  For IaaS, cloud providers have a broadly similar semantics, but…  File-based and block storage is one difference. Contextualization  Can a user run the same validated image on all clouds?  Can a user share the same parameterized image with others?  Neglected issue in standardization; CloudInit becoming de facto std.

23. 23 Solutions

24. 24 StratusLab History Informal collaboration to investigate running grid services on Amazon EC2 (2007) StratusLab Project (6/2010 to 5/2012) co-funded by EC with 6 partners from 5 countries Open collaboration to continue the development and support of the StratusLab software Website: http://stratuslab.euhttp://stratuslab.eu Twitter: @StratusLab Support: support@stratuslab.eusupport@stratuslab.eu Source: http://github.com/StratusLabhttp://github.com/StratusLab Identified need for open source cloud distribution. Production dist. with academic & commercial deployments.

25. 25 StratusLab Complete Infrastructure as a Service cloud distribution  Developed within EU project, software maintained by partners  Focus: Simple to install and simple to use Services  Compute: Virtual machine management (currently uses OpenNebula)  Storage: Volume-based storage service  Network: Simple configuration for public, local, and private VM access  Image mgt.: Complete system for trusted sharing of VM images  Tools (python CLI) and APIs (Libcloud) to facilitate use of cloud  Tools to facilitate installation of services

26. 26 SlipStream Cloud orchestrator and deployment engine  Facilitates testing, deployment, and maintenance of complex systems  Transparent access to multiple cloud infrastructures  Allows automated deployment of systems in one or more clouds

27. 27 Image Management

28. 28 Image Management Image metadata  What does an image contain (OS, services, configuration, etc.)?  What versions of the kernel, software, etc. are included?  Who is responsible and/or supports a given image?  How do I identify a given image? Creating machine images  How can an image be created for multiple clouds?  What do I have to do to create a secure machine image? Sharing images  How can I make my images available to others?  Can I parameterize my images to make them useful to more people?  Can the images be transported and used efficiently?

29. 29 Image Management Actors

30. 30 Marketplace Priorities  Mechanism for sharing and trusting images  Possible to distribute fixed, read-only data sets as well  Split the storage of image metadata and image contents  Define roles for creator, user, administrator, and validator Implementation  Marketplace API: Proprietary REST API for create, read, search  Marketplace acts as image registry and handles only metadata  Image contents can be located on any public (web) server  ‘Private’ images can also be held in cloud storage

31. 31 Marketplace: Key service in larger ecosystem Trust  Marketplace metadata plays key role in providing information about the image contents and provenance Factories  stratus-create-image facilitates customization of images  VirtualBox and other local virtual tools  Bitnami and many similar services for build of standard OS services  Quattor and other fabric management can be used Transport (& Storage)  StratusLab uses simple HTTP(S) for image transport  Could imagine using ftp, gridftp, bittorrent, etc.  vm-caster/catcher in EGI federated cloud task force

32. 32 Image Handling Workflow

33. 33 Cloud Federation

34. 34 StratusLab Federated Cloud Infrastructure Features  Two sites operating (LAL and GRNET) for ~3 years  Common user authentication  Ability to use the same images across resources  StratusLab client allows easy switching between sites  StratusLab Libcloud binding allows common view of both sites Need to go further…  To sites running different cloud software  Helix Nebula and EGI Fed. Cloud Task Force active in this area

35. 35 Federation Models Transparent Federation  Site operators “outsource” to other providers  Completely transparent to end users  Difficult to achieve in practice because of data protection concerns and network access/performance Brokered Federation  Variety of different cloud infrastructures are visible to users  Users choose to place virtual machines in particular locations  Simple clients can handle federation if differences are small  Orchestrators are needed for larger differences between clouds Both Helix Nebula and EGI take the brokered approach

36. 36 Vendor Lock-in vs. Federation Common API — minor issue  Fully interoperable API avoids duplication in cloud control software  Has very limited impact on applications and services in the cloud  Current (quasi-) standards: EC2, OCCI, CIMI, CDMI, … Common Semantics — important issue  Semantics determine how apps and services operate in the cloud  For IaaS, cloud providers have a broadly similar semantics, but…  File-based and block storage is one difference. Contextualization — critical issue  Can a user run the same validated image on all clouds?  Can a user share the same parameterized image with others?  Neglected in standardization but CloudInit becoming de facto std.

37. 37 “Our” Contributions StratusLab  Adopt CIMI as the standard interface to services  Provide Libcloud (python) driver for StratusLab  Provide EC2, OCCI, etc. as adaptors to CIMI interface  Move to CloudInit for contextualization framework  Flexible authentication system to support different methods SlipStream  Chosen as main interface to supported clouds in Helix Nebula  Already supports multi-cloud deployments  Support for all clouds within Helix Nebula

38. 38 Running Clouds in Production

39. 39 Cloud Experience at LAL Private cloud for laboratory services  Works well, plan to migrate all services including grid worker nodes and experiment-specific servers  Services switched to VMs without users being aware of change  Very different way of working, need to change administrator habits  Have seen some stability issues related to SL6 kernel/virtualization Public cloud open to university  Very positive reaction to cloud; LAL resources nearly 100% used  Variety of disciplines: biology, software eng., statistics, astrophysics, bioinformatics, …  After initial introduction, users require only low level of support  Other labs offering StratusLab training without our direct involvement

40. 40 Summary

41. 41 Summary Cloud for scientific computing  Already a common tool for many scientific disciplines  Cloud technologies will become more pervasive with time  Associated swing back to larger, centralized data centers Many challenges for cloud  Elasticity with limited resources  Data management (legal & technical)  Security  Image management — unique holistic approach from StratusLab  Federation — brokered federation with StratusLab & SlipStream LAL cloud experience  Very positive feedback from both administrators and users

42. 42 Questions and Discussion Website: http://stratuslab.eu/http://stratuslab.eu/ Twitter: @StratusLab Support: support@stratuslab.eusupport@stratuslab.eu Source: http://github.com/StratusLabhttp://github.com/StratusLab SixSq: http://sixsq.comhttp://sixsq.com SlipStream: https://github.com/organizations/slipstreamhttps://github.com/organizations/slipstream

43. http://stratuslab.eu/ Copyright © 2013, Members of the StratusLab collaboration. This work is licensed under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).