Cloud Compu)ng: Overview & challenges. Aminata A. Garba

Transcription

1 Cloud Compu)ng: Overview & challenges Aminata A. Garba

2 Outline I. Introduc*on II. Virtualiza*on III. Resources Op*miza*on VI. Challenges 2

3 A Historical Note 1960, the idea of organizing computa)on as a public u)lity like electricity was issued (John McCarthy) 1967, IBM introduced its first system with virtual memory (360/67) 1972, IBM released VM/370 system. VMs created for users and the VMM managed hardware resources mul)plexing. Virtualiza)on was mo)vated by the cost of hardware & the need to share hardware among users and applica)ons 1980s & 1990s, the interest of virtualiza)on dropped with a drop in hardware cost and the expansion of personal computers 2005, regain of interest in virtualiza)on technology in research and commercial 2006, Amazon EC2 was ini)ally released as a limited public cloud compu)ng service 2008, MicrosoU Windows Azure was announced & became commercially available in , icloud was announced as a cloud storage and cloud compu)ng services from Apple Inc. stores content such as music, photos allows access from Apple devices 2012, the Oracle Cloud was announced

4 Defini)ons Several defini)ons in the literature Cloud Compu)ng [1] (NIST) A model for enabling ubiquitous, convenient, on- demand network access to a shared pool of configurable compu)ng resources (e.g., networks, servers, storage, applica)ons, and services) that can be rapidly provisioned and released with minimal management effort or service provider interac)on 4

5 Cloud Features On- demand self- service A consumer can unilaterally provision compu)ng capabili)es (server )me, storage) as needed No required human interac)on with service provider Broad network access Capabili)es are available over the network Accessed through standard mechanisms Promote use by heterogeneous client plaborms (e.g.,mobile phones, laptops) Resource pooling The provider s compu)ng resources are pooled to serve mul)ple consumers Different physical and virtual resources dynamically assigned and reassigned according to consumer demand Customer generally has no control or knowledge over the exact loca)on of the provided resources but may be able to specify loca)on at a higher level of abstrac)on (e.g., country, state, or datacenter) Examples of resources include storage, processing, memory, network bandwidth, and virtual machines 5

6 Cloud Features (cont.) Rapid elas*city Capabili)es can be rapidly and elas)cally provisioned, to quickly scale out and rapidly released, to quickly scale in Capabili)es available for provisioning ouen appear to the consumer to be unlimited and can be purchased in any quan)ty at any )me Measured service Cloud systems automa)cally control and op)mize resource use by leveraging a metering capability at some level of abstrac)on appropriate to the type of service (e.g.,storage, processing, bandwidth) Resource usage can be monitored, controlled & reported, providing transparency for both the provider and consumer of the u)lized service 6

7 Deployment Models Private cloud Infrastructure operated solely for an organiza)on Managed by the organiza)on or a third party May exist on premise or off premise Community cloud Infrastructure shared by several organiza)ons Supports a specific community with shared concerns (e.g., mission, security requirements, policy, compliance considera)ons) Managed by the organiza)ons or a third party May exist on premise or off premise Public cloud Infrastructure is made available to the general public or a large industry group Owned by an organiza)on selling cloud services Hybrid cloud A composi)on of two or more clouds (private, community or public) that remain unique en))es but are bound together by standardized or proprietary technology that enables data and applica)on portability 7

8 Service Models Classified according to Abstrac)on levels Applica)ons Models SoLware as a Service (SaaS) PlaMorm as a Service (PaaS) Infrastructure as a Service (IaaS) 8

9 SoLware as a Service (SaaS) Applica)ons running on the cloud infrastructure belong to the provider Consumer can use the provider s applica)ons running on the cloud infrastructure The consumer does not manage or control cloud infrastructure (network, servers, storage) or applica)ons The applica)ons are accessible from various client devices through a client interface such as a web browser (e.g., web- based ) Services are deployed and configured for user Possibly a limited user- specific configura)on seengs MicrosoU Office Suites IBM inotes Google Docs Photo Galleries (Yahoo Flickr, Google Picassa) 9

10 PlaMorm as a Service (PaaS) User can deploy applica)ons using the provider cloud infrastructure Applica)on are created using programming languages and tools supported by the provider s plaborm Consumer does not manage or control the cloud infrastructure (network, servers, storage) or souware ( OS and other souware) Consumer has control over the deployed applica)ons and possibly applica)on hos)ng environment configura)ons User are limited to programming languages defined by the cloud provider Google App Engine Developing and hos)ng Web applica)ons Limited to a number of applica)ons: e.g., Python and Java API for the implementa)on of web applica)ons MicrosoU s Windows Azure Data- intensive applica)ons IBM Blue Cloud 10

11 Infrastructure as a Service (IaaS) Users can provision compu)ng, storage and networking resources Users can deploy and run arbitrary souware, which can include opera)ng systems and applica)ons Consumer does not manage or control the underlying cloud infrastructure but has control over opera)ng systems, storage, deployed applica)ons Possibly limited control of select networking components (e.g., host firewalls) Amazon EC2 Users can create and use virtual machines (instances) Instances are classified according to memory, CPU, storage, etc. Amazon Simple Storage Service (S3) Public storage web service Data is stored on mul)ple devices Store for objects of variable sizes Clients can read and update objects remotely using a web services interface 11

12 Architecture of Cloud Compu*ng (Cloud Stack) [2] 12

13 Benefits of Clouds Users Pay as you go model: users pay for needed resources (bandwidth, storage, processing) Less opera)onal & less/no infrastructure deployment and maintenance costs for users Companies can focus on their main ac)vi)es High available throughput Easier processing of large amount of data Providers Economy of scale Efficiency Big revenues Na*on wide Accelerate na)on economy Create jobs and new revenues 13

14 Capacity is limited Reality Check Cloud providers promise more to customers than their capacity Reliability/Availability: several cloud services failover [6] MicrosoU Azure: 22h outage March 2008 Google search outage (Programming error) 40 min, 31 Jan 2009 Gmail and Google APP Engine: 2h hours February S3 outage 5h ( 17 June 2008) and 6-8h (July 2008) Slow/down network Cloud applica)ons can not run 14

15 Service Level Agreement Agreement between the provider and the consumer Dura)on of the agreement Availability of the resources (probabilis)c) Amount of resources Limits to the resource requirements According to workload fluctua)ons resources may be added Service Performance Penal)es Provider: if resources are unavailable/credit for user User: for using addi)onal resources (may not be supported in case of high resources demand) 15

16 Requirements Infrastructure Servers/clusters Storage Network ( inside the cloud and WAN connec)ng data centers & users) Power & cooling systems Tools Virtualiza)on Virtual Machines (VMs) Virtual Machines Monitors (VMM) Resource Management Tools Consumers Plaborm for communica)on with users Service Level Agreement Billing system ( for public clouds) 16

17 System virtualiza*on II. Virtualiza*on Abstrac)on obtained using a souware layer, Virtual Machine Monitor (VMM) or hypervisor, to par))on the physical resources into virtual machines (VM) VM (possibly) hos)ng different opera)ng systems (guest OS) can run on the same physical machine Hardware seen as a pool of resources to be shared by the VMs (Processor, Memory, Hard disk, Network) Types of system virtualiza*on Full virtualiza*on VMM on top of hardware Guest OS unmodified Hosted virtualiza*on Hypervisor is installed as an applica)on on top of exis)ng OS Simplicity of installa)on Increased overhead Hybrid VMM and the host opera)ng system share the hardware 17

18 Examples VM 1 VM 2 VM 3 VM 1 VM 2 VM 3 App 11 App 12 Guest OS : Unix App 21 Guest OS: Windows App 31 App 32 Guest OS: Lunix App 11 App 12 Guest OS : Unix App 21 Guest OS: Windows App 31 App 32 Guest OS: Lunix Virtual Machine Monitor (VMM/Hypervisor) Virtual Machine Monitor (VMM/Hypervisor) Hardware (CPU, Memory, storage, capacity) Host Operating System Hardware (CPU, Memory, storage, capacity) A physical machine hos)ng 3 VMs with dis)nct OS, souware & apps (full and hosted virtualiza)on) 18

19 Examples (cont.) Applications App 21 VM1 Guest OS: Windows VM 2 App 31 App 32 Guest OS: Lunix Host Operating System VMM Hardware (CPU, Memory, storage, capacity) Hybrid system 19

20 Characteris*cs of Virtualiza*on Benefits Isola*on Hardware: dis)nct applica)ons ( different users) run simultaneously on the physical machine Isola)on from other VM Reduce impact of failure to VM Increase security Flexibility Add or reduce hardware resources Mobility Move virtual machine between different physical hosts Disadvantages Increased overhead Increased Processing Reduced Performance 20

21 Virtual Machines Monitor (VMM) Also referred to as Hypervisor SoUware layer that par))ons a server into virtual machines VM can run exis)ng souware on the physical machine Provides isola)on between VM and from hardware Mul)plex virtual machines on a single hardware plaborm Manage VM access to the physical resources Migrate virtual machines across machines Load balancing Hardware failures System scaling Consolidate VM with low resources usage onto a single computer 21

22 Examples of VMM Kernel- based virtual machine (KVM) Full virtualiza)on Supported by several plaborms Support unmodified guest opera)ng systems (versions of Windows, Linux, UNIX) Open source VMWare Startup from Stanford University Full, hybrid virtualiza)on Commercial Xen hypervisor Started at Cambridge University Paravirtualiza)on Open- source product used by other virtualiza)on products 22

23 VMM Challenges VMM must be able to export a hardware interface to the souware in a VM Maintains control of the machine and retain the ability to interpose on hardware access VMM has to be compa)ble with the system (to run legacy souware) Performance Virtualiza)on overhead Run the VM at the same performance (speed) as the souware would run on the real machine VMM failure will affect all the virtual machines running on the computer A security failure occurrence in the VMM will impact all the VMs 23

24 III. Resource Op*miza*on Op*mize resource u*liza*on CPU Memory usage Capacity/bandwidth Storage Energy consump)on Constraints Available resources QoS: flexibility, latency, security, reliability, backup /replica)on, elas)city Service Agreement Level (capacity, performance) Priori)es Weights Cost 24

25 Challenges Modeling issue Modeling Memory, CPU, capacity, storage, cost, SLA, QoS is difficult Complexity/Difficulty Complex numerical ( computa)ons) problem Heavy processing Func)on of allocated resources is non linear with mul)ple unknowns Hard analy)cal analysis and op)miza)on NP hard problem Tradeoffs between complexity and op)mized solu)on It is usually difficult to consider mul)ple resource simultaneously Iden)fy a single resource with the highest impact on the resource alloca)on Scheduling and capacity alloca)on algorithms usually consider one argument or heuris)c models 25

26 Resource Management Admission control Resource availability SLA Resource alloca)on Resource provisioning Scheduling and Rou)ng Resource Management (QoS & SLA Compliance) VM migra)on Dynamic scaling Replica)on 26

27 Admission Control Admission control Accommodate new users Provide required capacity with a given (usually high) probability Select requests to be admiqed when the server is overloaded Police the incoming requests Request- based admission control Reject new requests if the servers are running to their capacity For a session with mul)ple requests, some requests may be admiqed and other rejected Session- based admission control Reject new sessions Once a session is admiqed, all future requests belonging to that session are admiqed SLA strategies Users are admiqed according to their SLA High- priority vs low priority user QoS- aware admission Control Depends on the QoS High capacity user may not be admiqed during overload situa)ons Policy- based admission control Based on a given policy 27

28 Resource Alloca*on: Provisioning Allocate hardware resources to applica)ons Provisioning Goals Elas)city Scalability Challenges Under- provisioning: SLA is not sa)sfied Over- provisioning: resource u)liza)on is not op)mized 28

29 Scheduling Problem formula*on Matching tasks to machines (VM) Throughput: number of tasks completed Turnaround )me: )me to complete a task Response )me: )me to access resources Methods Op)mal solu)on is a hard problem Heuris)c methods Several algorithms are proposed in the literature based on some criteria Dynamic vs Sta*c Sta)c: tasks are known prior to execu)on Dynamic: scheduling is performed when the task arrives Preemp*ve and non- preemp*ve A new task can interrupt execu)on of an old task Time Constrained Scheduling A deadline is set Priority can apply 29

30 Examples t1=10s T2=80 s T3 = 4s T4= 1s FIFO : Average waiting time (turnaround time) : ( )/3=96s T4= 1s T3 = 4s t1=10s T2=80 s Min-Min : Average turnaround time : ( )/3=38s T2=80 s t1=10s T3 = 4s T4= 1s Max-Min : Average turnaround time : ( )/3=119s 30

31 Examples VM 1 VM 2... VMn Fair Queuing

32 Start- Time Fair Queuing Server VM1 (2) VM2 (1) App11 (2) App12 (1) App21 (1) App22 (2) T111 (1) T112 (1) T121 (1) T211 (1) T212 (1) T221 (1)

33 Earliest Deadline First (EDF) (P1=3, C1=1) a a a a (P2=4, C2=2) b b b (P3=7, C3=1) c c a b a c b a 33

34 Op*mal Par**oning Rule P0 α1,σcms α2,σcms αn,σcmsc P1 α1,σcps P2 α2,σcps Pn αn,σcps - αi: data fraction allocated to the ith node - αiσ: amount of data to be transmitted to the ith node for processing, 0 < αi 1, sum (αi)=1 - Cms: Cost of transmitting a unit workload - Cps: Cost of processing a unit workload [(Lin et. al) ] Workload is par))oned to ensure the earliest possible comple)on )me Tasks are required to complete at the same )me Based on divisible load theory (DLT), which states that the op)mal execu)on )me is obtained when all nodes allocated to the task complete their computa)on at the same )me The head node distributes the data to worker nodes

35 VM Migra*on Moving a VM from one physical host to another VM running (live migra)on) No impact on other running VMs Objec)ve Reduce impact of hardware failure Load balancing Power management (server consolida)on) Failure or Network maintenance Features Minimize the migra)on )me Minimize the )me during which services are not 35 available (down)me)

36 Example VM 1 App 11 App 12 VM 1 App 11 App 12 VM 2 App 21 Before Migra)on VMM Hardware (Host A) VMM Hardware (Host B) VM 1 VM 2 VM 1 VMM App 11 App 12 App 21 VMM App 31 AUer Migra)on Hardware (Host A) Hardware (Host B) 36

37 VM 1 App 11 Example App 12 VMM VM 1 App 11 Hardware (Host A) VM 1 App 11 App 12 VMM Before Migra)on App 12 VMM Hardware (Host B) Hardware (Host C) VM 1 App 11 App 12 VM 2 App 21 App 22 VM 3 App 31 App 32 AUer Migra)on VMM VMM VMM Hardware (Host A) Hardware (Host C) Hardware (Host B) 37

38 Example VM 1 App 11 App 12 VMM VM 1 App 11 App 12 VM 2 App 21 VMM VM 3 App 31 Before Migra)on Hardware (Host A) Hardware (Host B) VM 1 App 11 App 12 VMM VM 2 App 21 VM 1 App 11 App 12 VMM VM 2 App 21 AUer Migra)on Hardware (Host A) Hardware (Host B) 38

39 IV. Cloud Compu*ng Challenges Scalability/Elas)city Performance & Fault Tolerance Security/ Confiden)ality Data loca)on Data security Data loss Data management by a third party Data access through Internet Resource alloca)on Cost op)miza)on Energy cost Networking/bandwidth Performance, QoS, Service Level Agreement (SLA) Portability 39

40 Security Issues Management delega)on Responsibili)es (agreed on the SLA) Data loca)on Iden)ty and consumer interface management Compliance of the cloud provider Data portability Data security Instance security Malicious aqack Failure to isolate from aqacked VM Hypervisor aqack Network security Encryp)on of data packets VPN 40

41 Specific Challenges in Africa Energy (power and cooling) Networking Data protec)on How can cloud compu)ng be viable in Africa? What are the alterna)ves for cloud compu)ng development in Africa? 41

42 Summary Introduc)on to Cloud Compu)ng Virtualiza)on Resources Op)miza)on Resources Management Strategies Resource Management Tools Virtual infrastructure management Data management tools Computa)onal tools Resource Management Challenges 42

43 References 1. P. Mell and T. Grance, The NIST Defini)on of Cloud Compu)ng, Na)onal Ins)tute of Standards and Technology, Informa)on Technology Laboratory, Technical Report, A. Lenk, M. Klems, J. Nimis, S. Tai, and T. Sandholm, What s inside the Cloud? An architectural map of the Cloud landscape, ICSE Workshop on SoUware Engineering Challenges of Cloud Compu)ng, pp , Mendel Rosenblum, Tal Garfinkel: Virtual Machine Monitors: Current Technology and Future Trends, IEEE Computer Society, Sherif Sakr, Anna Liu, Daniel M. Ba)sta, and Mohammad Alomari, A Survey of Large Scale Data Management Approaches in Cloud Environments, IEEE Communica)ons Surveys & Tutorials, B. Sotomayor, R. S. Montero, I. M. Llorente, and I. Foster, Virtual infrastructure management in private and hybrid clouds, IEEE Internet Compu)ng Conference, September/October, B.P. Rimal, E. Choi, I. Lumb, A Taxonomy and Survey of Cloud Compu)ng Systems, IEEE, 5 th Interna)onal Conference on INC, IMS and IDC, F. Chang, J. Ren, and R. Viswanathan. Op)mal resource alloca)on in clouds. IEEE Cloud Compu)ng (CLOUD), 2010 IEEE 3rd Interna)onal Conference on, pages , july C. Clark, K. Fraser, S. Hand, J. G. Hansen, E. Jul, C. Limpach, I. Praq, and A. Warfield, Live Migra)on of Virtual Machines, Proceedings of the 2nd Symposium on Networked Systems Design and Implementa)on (NSDI 05), K. J. Duda and D. R. Cheriton. Borrowed- virtual- )me (BVT) scheduling: suppor)ng latency- sensi)ve threads in a general- purpose scheduler, Proceedings of the 17th ACM SOSP, hqp://aws.amazon.com/ec2/ 11. hqp:// 43