Harnessing the High Performance Capabili5es of Cloud over the Internet

Transcription

1 Harnessing the High Performance Capabili5es of Cloud over the Internet Jaison Paul Mulerikkal, PhD HPC Knowledge Portal Meeting 2015 Barcelona, Spain

2 About Me Jaison Paul Mulerikkal B Tech Mahatma Gandhi University, Kerala, India MS (RMIT University, Melbourne, Australia) PhD (Australian Na5onal University) Computa5onal Scien5st, NeSI, New Zealand Asst Professor at Rajagiri School of Engineering & Technology, Kochi, Kerala, India

3 Kerala 3

4 Hegelian Dialec5cs German philosopher Georg Wilhelm Friedrich Hegel explained philosophy of history as a dialec5c between thesis, an5- thesis and resul5ng synthesis. there could emerge a theory first and it could be confronted by an opposing theory. The dialec5c between these opposing theories may find a consensus by assimila5ng the main aspects of both, in the due course of 5me 4

5 History of Compu5ng (According to me!) 5

6 Cloud Compu5ng The most powerful feature of cloud compu5ng is its capacity to transfer compu5ng as a 5 th u5lity a[er water, electricity, gas, and telephony. That was the promise! My Defini5on: Cloud Compu5ng is a form of parallel and distributed system which uses virtualiza5on techniques to orchestrate large storage, memory and network resources of data- centres or similar resources as a unified unit but with apparent elas5c availability on- demand by the customers. It relies on the economy of scale to provide infrastructural and applica5on services without upfront commitment of customers over a network or Internet with minimal management, running and maintenance costs. 6

7 Hype Cycle

8 State of the Cloud

9 Public Cloud Usage

10 Private Cloud Usage 10

11 Private Cloud Usage

12 HPC in Cloud? Gartner CIO survey 2011 predicts that 23% of compu5ng ac5vity would never move to cloud. Some of the High Performance Compu5ng (HPC) applica5ons will be among those 23% that would never move to cloud. Ian Foster noted: The one excep5on that will likely be hard to achieve in cloud compu5ng (but has had much success in Grids) are HPC applica5ons that require fast and low latency network interconnects for efficient scaling to many processors. 12

13 Silver Lining in the Cloud However the future for high performance compu5ng in cloud is not that bleak. It could be possible for specialized clouds and providers with new tools and technology to enable HPC applica5ons on cloud with acceptable level of speed and efficiency. Science Cloud supported by Nimbus project - is an early indica5on of that trend 13

14 Two Ques5ons Whether Cloud could produce HPC like performance? Whether HPC capabili5es of Cloud can be harnessed effec5vely over slow networks like the Internet? 14

15 Whether Cloud could produce HPC like performance? 15

16 Dell Experiment Comparison between a bare metal (BM) installa5on (with RHEL 6.5) and a virtual machine (VM) running on a hypervisor (OpenStack), on a single node (15 Jul 2014). Running NAS Parallel Benchmarks, ANSYS, etc. Applica5ons which are embarrassingly parallel and compute intensive perform 1-2% lower on the VM rela5ve to the BM Applica5ons which have very high memory bandwidth requirements may perform up to 25% lower on the VM rela5ve to the BM. Ref: 16

17 Cluster vs Cloud Comparison - ANU Data size: 4000, Iterations:100, No of Machines/Instances: 4, Unit: Seconds 17

18 How do we cut the fat? 18

19 Docker A Container management system 19

20 Background Google s lmcpy project (Let Me Contain That For You) Linux containers (LXC): Pros: faster lifecycle and limited overhead Cons: configura5on complexity and weaker security isola5on Oracle Solaris also has a similar concept called Zones Docker is built on top of LXC (Linux Containers). 20

21 Docker vs VM 21

22 Docker vs VMs VM hypervisors, such as Hyper- V, KVM, and Xen, all are based on emula5ng virtual hardware. That means they re fat in terms of system requirements. Containers use shared opera5ng systems. They are supposed to be much more efficient than hypervisors in system resource terms. Loading 5me and system resources that need to launch those applica5ons could be lower That s theory, what s prac5cal? 22

23 IBM Experiment Passive Benchmarking with docker LXC, KVM & OpenStack on IBM So[Layer By Boden Russell Disclaimer: The tests herein are passive no in depth tuning, analysis, etc. More ac5ve tes5ng is warranted. These results do not necessary reflect your workload or exact performance nor are they guaranteed to be sta5s5cally sound. Ref: 23

24 What Openstack IS A group of 7+ core open source projects aimed at providing comprehensive cloud services. It is more than a hypervisor manager. It sits above the pool of virtualized resource as a master control plane. It provides users with a single point of control and orchestra5on.

25 OpenStack Components

26 OpenStack Components OpenStack Compute (code- named Nova ) OpenStack Object Store (code- named Swi[ ) OpenStack Image (code- named Glance ) OpenStack Iden5ty (code- named Keystone ) OpenStack Block Storage (code- named Cinder ) OpenStack Networking (formerly code- named Quantum ) OpenStack Dashboard (code- named Horizon )

27 Docker on OpenStack?

28 Benchmark Environment IBM So[Layer rally dstat + Awesome! glance api / reg nova api / cond / etc keystone nova api / cond / etc cinder api / sch / vol KVM controller compute node rally dstat + glance api / reg nova api / cond / etc nova api / cond / etc Awesome! keystone cinder api / sch / vol docker lxc controller compute node Ref: Boden Russell (brussell@us.ibm.com) 28

29 7 6 Cloudy Performance: Serial VM Boot Average Server Boot Time Docker 1.5x faster Time in Seconds docker KVM docker KVM Ref: Boden Russell (brussell@us.ibm.com) 29

30 Cloudy Performance: Serial VM Boot CPU Usage In Percent Docker: Compute Node CPU Averages usr sys Time CPU Usage In Percent KVM: Compute Node CPU Averages usr sys Time Ref: Boden Russell (brussell@us.ibm.com) 30

31 Cloudy Performance: Serial VM Boot Memory Used 5.00E E E E E+09 Docker: Compute Node Used Memory Delta 687 MB Per VM 45.8 MB Memory 0.00E Time Memory Used 5.00E E E E E+09 KVM: Compute Node Used Memory Delta 2775 MB Per VM 185 MB Memory 0.00E Time Ref: Boden Russell (brussell@us.ibm.com) 31

32 Whether HPC capabili5es of Cloud can be harnessed effec5vely over slow networks like the Internet? 32

33 A Surprise By- product of my PhD My PhD research at ANU has produced a SOA middleware that is intended to produce high performance outcomes for not so embarrassingly parallel scien5fic applica5ons. ANU- SOAM was moulded by adop5ng the architecture of IBM- Pla5orm Symphony Enterprise SOA middleware. The programming model supported ANU- SOAM with its Data Service extension is found to effec5vely harness cloud compu5ng resources over Internet to produce HPC results. 33

34 Service Oriented Architecture SOA is a compu5ng paradigm that considers services as building blocks for applica5ons. In SOA, atomic units of computa5on(s) are considered as a Service, which are at the disposal of Clients. A Resource Manager nego5ates the availability/ scheduling of services to clients. 34

35 SOA Tradi5onal Architecture 35

36 High Performance Scien5fic Compu5ng - Main Challenge Inter- dependency of underlying computa5onal tasks in many scien5fic applica5ons. Eg: N Body problem. When these applica5ons are parallelized, the inter- dependency shall compel atomic units of work - tasks - to progress in phases (we call it as genera8ons). This increases task granularity which result in increased communica5on and communica5on costs (Overheads) that slows down the applica5on. They are not embarrassingly parallel! 36

37 N Body Problem 37

38 N Body Problem Conven5onal Approach The naïve NBS algorithm starts with a known set of values for the mass, velocity and posi5on of bodies involved. The future posi5ons and veloci5es of bodies can be predicted by itera5vely moving forward in small 5me increments. This linear algorithm is split into client and service processes and the algorithm is parallelized by sending subset(s) of the N bodies to each SI. The SIs process these subsets and the par5al results are communicated back to the client to synchronize all updates from all SIs. 38

39 N Body Problem Conven5onal Approach RM Client Service Request Resources Assign Resources Sync all partial results *Next Generations.. Send Tasks(particle info) Parallel computation of partial data Send back updated (partial) particle info Send Tasks(particle info) * Next generation tasks are depended on previous generation results. 39

40 Data Service Extension Introduced to deal with interdependency of tasks in scien5fic apps (as explained in the example of NBS). The Data Service allows SIs to communicate each other without 5ght coupling so that many decisions can be taken among SIs, rather than going back to client all the 5me. This will reduce communica5ons between client and SIs in many applica5ons. allow applica5on programmers to move cri5cal applica5on logic from client side to service side. 40

41 SOAM with Data Service Resource Manager C Data Service Instance Client Common Data C Data Service Instance C Data Service Instance 41

42 Data Service Func5ons Data common to all SIs can be set (add) using this service. The common data is replicated among all SIs and client process. This common data can be accessed (get) either by client or SIs. Updates to this common data (put) can also be made by individual SIs or client processes, without changing common data for a for a par5cular genera5on of tasks). put is a deferred opera5on in CDS. These updates (put) can be synchronized between SIs and the client process using sync. isync applies sync only to service instances. The common data will be synchronized among SIs but won t be updated back to the client side. 42

43 Deferred put Update Meta Update Update Meta Update CD sync CD Update (from other) Time High Performance Cloud Computing Using an Efficient Data Service.com 43

44 N Body Problem ANU- SOAM Approach RM Client DS Service Request Resources Assign Resources add particle info Send tasks isync command get particle info Parallel computation of partial data put partial updates isync updates b/n SIs Send tasks *Next Generations.. * Next generation tasks are get updated data from CDS. 44

45 Experimental Setups - within Cloud Two types of cloud experimental scenarios 1) ANU-SOAM deployed within cloud: both the client and SIs to run within a public cloud IaaS. 2) ANU-SOAM deployed over the Internet: access a public cloud IaaS across Internet, from home PC. Selec5on of a right cloud provider turned out to be cri5cal. Because, ANU- SOAM uses OpenMPI as its communica5on backbone, which does not support Network Address Transla5on (NAT). Since the Amazon cloud uses NAT to translate the public IP addresses of its compute nodes, Rackspace (which doesn't use NAT technology) was chosen, especially to enable the second set of experiments. 45

46 NBS All within Cloud 20 NBS-SOAM within cloud - Loading time NBS-SOAM within cloud - Compute time NBS-SYMPHONY within cloud - Total time 15 Time (Sec) Service Instances 46

47 Cloud over Internet 47

48 NBS - Cloud over Internet Conven5onal SOA Approach 400 NBS-SYMPHONY within cloud - Total time NBS-SYMPHONY over the Internet- Total time Time (Sec) Service Instances 48

49 NBS - Cloud over Internet ANU SOAM Approach NBS-SOAM within cloud - Loading time NBS-SOAM within cloud - Compute time NBS-SOAM over the Internet - Loading time NBS-SOAM over the Internet - Compute time Time (Sec) Service Instances 49

50 Comparison NBS-SOAM over the Internet - Total time NBS-SYMPHONY over the Internet- Total time 400 Time (Sec) Service Instances 50

51 Intelligent Be ng? 51

52 Supercompu5ng over a Coffee? 52

53 This slide is intentionally kept blank 53

54 HPC in India 54

55 Thank you Ques5ons? 55