Grid, and first level evaluation of EGI Cloud

Transcription

1 FEDERATED COMPUTE RESOURCES Grid, and first level evaluation of EGI Cloud Kick-off Interest Group Compute Resources for Life Science Research, SURF - DTL - 15 Jan 2015

2 Scalable solutions: where to go? Compute Resources for Life Science Research, SURF - DTL 2

3 Cluster Computing Grid Computing Cloud Computing Federated Cloud Compute Resources for Life Science Research, SURF - DTL 3

4 GRID COMPUTING Compute Resources for Life Science Research, SURF - DTL 4

5 GRID COMPUTING Geographically distributed heterogeneous resources Enormous Compute and Storage capacity Security based on: Authentication and Authorization X509 certificate and VO membership Collaboration among virtual communities Prerequisites: A grid certificate - proxy An account to a user interface machine (ui) A VO membership 5

6 DUTCH GRID Loose federation of resources 11 sites (AMC, LUMC, RUG, WUR, TUD, ) Interconnected with SURFnet network cores 7.1PB disk 7.7 PB tape UMD Grid middleware Part of European Grid Infrastructure (EGI) Life Science Grid (LSG) 6

7 GRID - A CLUSTER OF CLUSTERS Animation: EGI - SURFsara MOOC

8 BEST PRACTISES Embarrassingly parallel problems Hundreds, thousands jobs simultaneously A hello world program takes minutes Scheduling and bookkeeping overhead Adapt your solution Use pilot jobs WMS scheduling is inefficient Keeping track of job status Error handling and resubmission 8

9 PILOT JOBS Animation: EGI - SURFsara MOOC

10 LARGE HADRON COLLIDER AT CERN 150 sites - Worldwide CPU cores 160 PB disk and 90 PB tape SURFsara and NIKHEF are a tier 1 site ALICE, ATLAS, CMS and LHCb 10

11 CLUSTER VS. GRID Cluster One site Limited capacity Shared local storage with home account Username based authentication Relatively homogeneous hardware Direct job submission Hard-coded paths to home account Job: application script Logging info: stdout/stderr locally Grid Multiple sites Virtually unlimited capacity No shared storage Certificate authentication Heterogeneous hardware Job submission through Grid middleware Program portably Job: JDL and input sandbox Logging info: output sandbox 11

12 EGI FEDERATED CLOUD 12

13 WHY CLOUD? Assemble your virtual machine (VM) from the ground up as a Service: SaaS: Software - gmail, facebook PaaS: Platform - Google App Engine IaaS: Amazon EC2, SURFsara HPC Cloud, EGI Federated Cloud Benefits: No hardware to buy and maintain No software to buy and maintain (SaaS, PaaS) Tailor VMs to your needs: cores, RAM, disks, OS Dynamic scalability for peak capacities - add when needed Root access to your VM 13

14 INFRASTRUCTURE AS A SERVICE \ Compute Resources for Life Science Research, SURF - DTL 14

15 FIRST-LEVEL EVALUATION Scope of EGI Federated Cloud Existing user documentation Access methods - Environment setup Compute & storage services try-out Options for application porting EGI user support Next: high level brokering tools 15

16 EGI FEDERATED CLOUD It is a grid of institutional clouds that is offered as IaaS to support individual researchers scientific communities Into production since spring 2014 Problems that it aims to solve: Resource availability beyond the limited capacity of local institutional clouds Compatibility when migrating an application between resource centres Sharing scientific solutions in a marketplace Easy to handle environment without excessive technical and administrative skills 16

17 SURFsara HPC Cloud EGI Federated Cloud 960 HPC cores, 80 Light cores 8 GB RAM/core 800 TB NFS shared storage Nodes connected by fast network Interface: Sunstone and OCCI 6000 cores Sept 14 smallest site: 48 cores largest: 720 cores 300TB storage Interface: OCCI Compute Resources for Life Science Research, SURF - DTL 17

18 BELOW DECKS EGI Federated Cloud is built on a set of open-standards: VM management interface: OCCI Contextualization: Cloud-init standard Cloud management stacks: OpenStack, OpenNebula, Synnefo Data management: a) block storage - OCCI, b) object storage - CDMI User authentication/authorization: X509 personal certificates/ VO VO management: Perun Site information: GLUE Schema - LDAP based BDII Information System Central service registry: GOCDB Monitoring: SAM NAGIOS Resource/image discovery: a) BDII, b) EGI App Marketplace Published Image Management: VMCaster

19 GETTING ACCESS Grid X509 certificate Join a VO For testing purposes, fedcloud.egi.eu VO Perun VO management tool Set up a Grid UI: Configure trust anchors, fetch-crl utility, VO client tools, vomsdir, vomses file, ldapsearch, Plus rocci client VM management Plus bcdmi client Data management Non-Grid users will need a preconfigured UI or higher-level gateways to get access and possibly assistance to get a certificate 19

20 COMPUTE RESOURCES - IMAGES Define the images: Available images on the EGI sites/ EGI App Marketplace Self-customised image (needs verification and publish to EGI Marketplace) CVMFS for software and OS image management is possible 20

21 COMPUTE RESOURCES - TEMPLATES Two types of templates: OS_template - the image Resource_template - the recipe Define the templates: From command-line: occi/ldapsearch From EGI App Marketplace 21

22 COMPUTE RESOURCES - VM DEPLOYMENT Instantiate a VM: From command-line with rocci client OCCI provides a uniform interface for integration and interoperability across sites Supported back-ends: OpenNebula, OpenStack, Synnefo, High-level brokers Slipstream, WS-PGRADE, VMDIRAC, Catania Science Gateway, COMPS, VCYCLE 22

23 COMPUTE RESOURCES - START VM PREREQUISITES 1. Two types of templates for the VM instantiation: ID for OS_template - the image ID for Resource_template - the recipe 2. Contextualization script - launched at VM startup, e.g. to inject a public key 3. Site endpoint - host url. There are two types of endpoints: a) OCCI: sites that offer only compute and block storage resources (IaaS) e.g. BIFI (Spain): b) CDMI: sites that offer object storage resources (STaaS) e.g. Julich (Germany): 4. Proxy certificate 23

24 OCCI EXAMPLE - START VM occi --endpoint --action create --resource compute --mixin os_tpl#2cc50cbc f9-a3ed-0021fd0004b1 --mixin resource_tpl#m1-small --context user_data="file:// $PWD/tmpfedcloud.login" --attribute occi.core.title="sara VM" --auth x509 --user-cred / tmp/x509up_u500 --voms returned URL > be92-dce6-4f fd7babcd1ba 24

25 OCCI CLIENT - FEATURES Start a VM - returns a unique VM ID Get the status of a VM Attach network interfaces to a running VM Create a block device Attach/detach blocks of storage to/from a running VM Stop a VM - it is actually a delete action List the running VMs, OS_templates, Resource_templates for a specific site For detailed site information: ldapclient 25

26 COMPUTE RESOURCES - REMARKS Quite fast VM instantiation for small VMs Big VMs need site specific requirements OCCI standard required - basic documentation The endpoints have to be known in advance Two template types required (OS_template and Resource_template) OCCI description of available templates or images is fair Alternatives: EGI App Database - url IDs for images ldap search - more detailed description Login to VMs: Perun ssh key propagation is not supported. Contextualisation is used instead. 26

27 STORAGE RESOURCES - PERSISTENCE Images are non-persistent by default Persistent storage: Block storage Object storage 27

28 STORAGE RESOURCES Block storage is provided by most of the sites OCCI management - rocci client: Attach/Detach features No sharing - block attached to one VM at a time Suitable for db, application servers Object Storage Object storage is provided as STorage-as-a-Service (STaaS) - not in production CDMI standard - not OCCI management bcdmi client: list directories, upload/download/delete files or directories GET/PUT calls via HTTP/HTTPS, curl or wget Sharing is possible - ACLs arranged per object 28

29 STORAGE RESOURCES - REMARKS Data sharing among VMs is an issue (alternative solutions per site, e.g. NFS) It is not possible to move a block device from one cloud site to another There is a limit for the number of block devices that can be attached to a VM and for the maximum size of virtual disks Block storage: easy and accessible from any VM running at any EGI site (opposite to Block storage) 5 CDMI end-points at the moment 29

30 APPLICATION PORTING General Workflow: Prepare the OS image, install proprietary software, configure the image to support contextualisation, export it in.ova format, and publish the self-built image to the EGI Application database upon verification EGI Application Database: Reuse images Reconfigure each time or develop a contextualisation script Application Broker: Integration Start VMs according to the workload 30

31 TYPICAL WORKFLOW 31

32 OVERALL REMARKS Benefit for cases with requirements that cannot be covered within the local Cloud resources No well-defined procedures yet for pricing schemes Road to hello world not easy for the novice Cloud user Alternative with high-level broker tools Cloud sites are not unified coherently in a single system User has to know in advance the endpoints that support her application image and templates to land on VMs can access block storage only within the same site. Object storage is a potential solution, but only few sites support CDMI Porting takes time and effort, but EGI consultancy is available EGI Marketplace very useful for scientific communities EGI Federated Cloud User Support (FCUS) is fast and accurate 32

33 USE CASES Wide European network of researchers: Integrating: CLARIN (linguistics), BioVeL (ecology), WeNMR (biology), SSEP (earth observation), SCI-BUS (science gateway portals), VERCE (geology), LifeWatch (ecology), ATLAS (High energy physics) via HelixNebula and ELIXIR (Bioinformatics) rocci: 29 use cases broker tools: 12 use cases 33

34 GRID VS. FEDERATED CLOUD Grid Heterogeneous clusters Resources and Users belong to VOs Information Service: BDII Security via Certificate and VO Programming effort for bootstrap app No root access to the resources Porting complexity Big batch system Reliable Central & Distributed storage Embarrassingly parallel problems Precompiled unix-like software/cvmfs Proxy validity for running jobs Job requirements in JDL description EGI Federated Cloud Heterogeneous sites Images and Users belong to VOs Information Service: BDII Security via Certificate and VO Programming effort for VM setup Customise env: Root access to VMs Interoperability Elasticity and pay-per-use Data sharing not possible Any type EGI AppDB VMs/contextualization Explicit delete of VMs Supported site endpoints known in advance 34

35 Compute Resources for Life Science Research, SURF - DTL 35

36 KEY QUESTIONS Define your specific requirements: VM management and VM access: IT people or researchers Number of cores, Memory, Wall-clock time, data volumes Pipelines: what is shared in tasks, what needs to be communicated Data locality (private or shared) Operating system, software (licensing programs) and databases Network interfaces (private or public) - virtual cluster When you increase a load parameter, how much do you need to increase the resources if you want to keep performance unchanged? Balance programming effort: optimize applications or develop scalable solutions or both 36

37 ACKNOWLEDGEMENTS Front-slide picture: (istockphoto.com.) Slide 3 background picture: application-development/high-performance-computing Slide 14: Ignacio M. Llorente, Workshop GARR - Calcolo e Storage Distribuito Rome, Italy, November 30th, 2012 Slides 7 & 9 animations: EGI-SURFsara MOOC on Grid computing, 2014 Slide 31: Slide 33 graph: Diego Scardaci, EGI Federated Cloud Use Cases, F2F meeting 2015 EGI wiki page: Compute Resources for Life Science Research, SURF - DTL 37