Scientific Cloud Computing Present Future Charles Cal Loomis

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

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

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

Essential Characteristics 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 http: //csrc. nist. gov/publications/ nistpubs/800 -145/SP 800 -145. pdf 4

Deployment Models 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 http: //csrc. nist. gov/publications/ nistpubs/800 -145/SP 800 -145. pdf 5

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

Software as a Service (Saa. S) 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 Paa. S 7

Platform as a Service (Paa. S) 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” Paa. S offers § Encroachment from both Saa. S and Iaa. S sides 8

Infrastructure as a Service (Iaa. S) 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 Paa. S space 9

Focus: Infrastructure as a Service 10

State of the Art Commercial Provider: Amazon Web Services (AWS) § Leading and largest Iaa. S service provider § Improving and adding new services at a phenomenal rate § Almost all Iaa. S 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 § Stratus. Lab, WNo. De. S, …, Open. Stack, Open. Nebula, Cloud. Stack § Very different levels of maturity, stability, scalability, etc. 11

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 12

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 13

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… 14

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! 15

Challenges 16

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: IPv 6 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! 17

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 18

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 19

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 20

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? 21

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: EC 2, OCCI, CIMI, CDMI, … Common Semantics § Semantics determine how apps and services operate in the cloud § For Iaa. S, 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; Cloud. Init becoming de facto std. 22

Solutions 23

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

Stratus. Lab 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 Open. Nebula) § 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 25

Slip. Stream 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 26

Image Management 27

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? 28

Image Management Actors 29

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 30

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 § Virtual. Box 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) § Stratus. Lab uses simple HTTP(S) for image transport § Could imagine using ftp, gridftp, bittorrent, etc. § vm-caster/catcher in EGI federated cloud task force 31

Image Handling Workflow 32

Cloud Federation 33

Stratus. Lab Federated Cloud Infrastructure Features § Two sites operating (LAL and GRNET) for ~3 years § Common user authentication § Ability to use the same images across resources § Stratus. Lab client allows easy switching between sites § Stratus. Lab 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 34

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 35

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: EC 2, OCCI, CIMI, CDMI, … Common Semantics — important issue § Semantics determine how apps and services operate in the cloud § For Iaa. S, 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 Cloud. Init becoming de facto std. 36

“Our” Contributions Stratus. Lab § Adopt CIMI as the standard interface to services § Provide Libcloud (python) driver for Stratus. Lab § Provide EC 2, OCCI, etc. as adaptors to CIMI interface § Move to Cloud. Init for contextualization framework § Flexible authentication system to support different methods Slip. Stream § Chosen as main interface to supported clouds in Helix Nebula § Already supports multi-cloud deployments § Support for all clouds within Helix Nebula 37

Running Clouds in Production 38

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 SL 6 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 Stratus. Lab training without our direct involvement 39

Summary 40

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 Stratus. Lab § Federation — brokered federation with Stratus. Lab & Slip. Stream LAL cloud experience § Very positive feedback from both administrators and users 41

Questions and Discussion Website: http: //stratuslab. eu/ Twitter: @Stratus. Lab Support: support@stratuslab. eu Source: http: //github. com/Stratus. Lab Six. Sq: http: //sixsq. com Slip. Stream: https: //github. com/organizations/slipstream 42

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