In Cloud, Can Scien/fic Communi/es Benefit from the Economies of Scale?

Transcription

1 In Cloud, Can Scien/fic Communi/es Benefit from the Economies of Scale? By: Lei Wang, Jianfeng Zhan, Weisong Shi, Senior Member, IEEE, and Yi Liang Presented By: Ramneek (MT )

2 Introduc/on The power of cloud compu/ng is elas/city the ability to pay for resources only when they are needed and to scale infrastructure up and down on demand, without addi/onal wai/ng /me. In this paper, we intend to answer one key ques/on to the success of cloud compu/ng: in cloud, can small- to- medium scale scien0fic communi0es benefit from the economies of scale? Economy of Scale: refers to reduc/ons in unit cost as the size of a facility increases.

3 Introduc/on Differences between scien/fic compu/ng workloads and the ini/al target workload of clouds: in workload characteris/cs in resource consump/on in performance goals In scien/fic communi/es, more and more research groups show great interests in private clouds or proposing hybrid cloud models to augment their local compu/ng resources with external public clouds. However, this paper focuses on the public clouds.

4 Introduc/on Types of clouds: Public cloud: Hosted at service provider s site. Supports mul/ple customers. Supports connec/vity over internet. Suited for informa/on that is not sensi/ve. Can be cheaper than the private cloud. Private cloud: Hosted at the enterprise or at the service provider s site. Supports a single customer. Connec/vity over private network/fiber or internet. Suited for informa/on that needs a high level of security.

5 Introduc/on Hybrid cloud: A hybrid cloud is a composi/on of at least one private cloud and at least one public cloud. For e.g., an organiza/on might use a public cloud service, such as Amazon Simple Storage Service (Amazon S3) for shared data but con/nue to maintain in- house storage for personal data.

6 This paper focuses on public clouds because: They are not restricted within an enterprise. They offer wide availability and economies of scale. Cheaper. There is a need to propose innova/ve cloud usage models, and build enabling systems that support scien/fic communi/es to benefit from the economies of scale of public clouds.

7 Overview This paper addresses three main issues: First, it proposes an innova/ve cloud usage model, called an Enhanced Scien/fic Public cloud (ESP) model. Second, on a basis of the ESP model, it presents the design of the Dawning- Cloud system. Third, it presents the evalua/on of the system comprehensively using both emula/on and real experiments.

8 Overview Deelman s System: each client/user in the organiza/on directly leases virtual machine resources from public cloud provider in a specified period. Evangelinos s System: the organiza/on as a whole rents resources with the fixed size from a public cloud to create a virtual cluster system. Dawning Cloud system: the common management service framework (CSF) is pre- deployed at the resource provider s site and thin run/me environment (TRE) layer is built on top of it according to service provider s workload requirements.

9 Enhanced Scien/fic Public Cloud Model (ESP) Features: Developing a new service management layer (TRE) for another different workload is lightweight. Second, the service management tasks become simpler, e.g., for a TRE, we only need to deploy fewer modules, since other ones are delegated to the CSF, which is pre- deployed on the cloud site Third, this model provides flexible system controls, and a service provider can ac/vate, safe- deac/vate, deac/vate, suspend, and resume TRE at its own need.

10 ESP TABLE 1: THE COMPARISONS OF DIFFERENT USAGE MODELS item a DS PC HC DP EP ESP SP vs. RP b 1:1 1:1 n:1 n:1 n:1 n:1 Separation No No No No Yes Yes of concerns resources local local local + rented rented rented rented resource provisioning fixed fixed fixed + elastic elastic fixed initial + dynamic SP s system control No No No limited limited flexible a. DS: dedicated system; PC: private cloud; HC: hybrid cloud; DP: Deelman s public cloud; EP: Evangelinos s public cloud; ESP : our model. b. SP: service provider; RP: resource provider

11 ESP

12 ESP As a high- level management en/ty, a TRE has five different states: ini/al, deployed, running, deac/vated, and suspended: The ini/al state indicates that the service provider and the resource provider are in the process of planning the TRE. At the request of a service provider, the resource provider can create a TRE. The crea/ng opera/on turns the state of TRE from ini/al to deployed. The deployed state indicates that the TRE is configured and deployed.

13 ESP When the service provider ac/vates the TRE that is deployed, the laaer turns to the running state. The deac/va/on opera/on has two- fold effects: the running jobs will be killed and the user data and programs will be permanently kept in the home directories unless the service provider explicitly destroys its TRE. The suspended state indicates that the TRE will reject the submissions of new jobs, however it will finish the submiaed jobs.

14 Dawning Cloud: Architecture Thin Run/me Environment (TRE) TRE Management and Programming API Common management Service Framework (CSF) A Public Cloud Site

15 Dawning Cloud: Architecture Layered Architecture Built using boaom- up approach Lower layer: CSF facilitates building thin service management layers- TRE for heterogeneous workloads: Provides a uniform view of virtualized or physical resources Lifecycle management mechanisms of TRE Enforcing resource provisioning policy Virtual machines or physical nodes provisioning Middle Layer: Management and Programming API for building TREs. Upper Later: TRE implements core func/ons for a specific workload.

16 Reservoir: Architecture Service Abstrac/on Layer (Claudia) OCCI Interface Open Nebula Core EC2 plugins Elas/cHost plugins Xen Drivers EC2 EC2 Elas/cHost Internal Datacenter

17 Reservoir Architecture The service abstrac/on layer interacts with the service providers to receive their Service Manifests, nego/ate pricing, and handle billing. Claudia: it is an IaaS solu/on created by Telefonica R&D aimed at managing services by providing an abstrac/on layer on top of both private and public Virtualiza/on Providers. OCCI (Open Cloud Compu/ng Interface) is a Protocol and API for all kinds of Management tasks. Open Nebula Core: The core consists of a set of components to control and monitor virtual machines, virtual networks, storage and hosts. The core performs its ac/ons (e.g. monitor a host, or cancel a VM) by invoking a suitable driver.

18 Difference between Reservoir and the Dawning Cloud 1. As compared to the Reservoir, the CSF of Dawning Cloud facilitates building lightweight service management layers for heterogeneous workloads. The following figure shows a typical dawning cloud system:

19 Difference between Reservoir and the Dawning Cloud Reservoir project integrates sohware packages from different partners: OpenNebula a virtual infrastructure manager Claudia a service management layer. 2. Unlike Reservoir, the implementa/on of TRE is not bound to virtual machines, e.g., XEN or VMware.

20 Dynamic Resource Nego/a/on Mechanism e dynamic resource negotiation mechanism.

21 Dynamic Resource Nego/a/on Mechanism Resource management policy: Service provider specifies its requirement for resource management in a resource management policy. A resource management policy defines the behavior specifica/on of the HTC or MTC server i.e., the server resizes resources to what an extent according to what criterion. Resource provision service: It is responsible for provisioning resources to different TRE. Resource provision policy: Used by a resource provider specifies its requirement for resource provisioning.

22 Dynamic Resource Nego/a/on Mechanism Setup policy: It determines when and how to do the setup work. Each /me a node is assigned or reclaimed, a setup policy is triggered. Life cycle management service: responsible for managing life cycles of TRE and performs the setup work.

23 Resource Management and Provisioning Policies In Dawning Cloud, we dis/nguish two types of resources provisioned to a TRE: Ini/al resources: ini/al resources, once allocated, will not be reclaimed by the resource provider un/l the TRE is destroyed. Dynamic resources: dynamic resources assigned to a TRE may be reclaimed by the resource provider.

24 Resource Management and Provisioning Policies In Dawning Cloud, a service provider and a resource provider need to set four parameters: 1. The size of ini/al resources. 2. The /me unit of leasing resources. 3. The checking resource cycle. It is a periodical /mer that the HTC or MTC server checks jobs in the queue. 4. The threshold ra/o of obtaining dynamic resources.

25 Start yes No yes

26 Resource Management and Provisioning Policies This paper proposes a resource management policy for an HTC or MTC service provider as follows: At the startup of a TRE, the service provider will request ini/al resources with the specified size. Ra/o of obtaining dynamic resources = (accumulated resource demands of all jobs in the queue )/( current resources owned by a TRE) If this ra/o> 1, the server will request Dynamic Resources (DR) as follows: DR = (the accumulated resources demand of all jobs in the queue) (the current resources owned by the TRE).

27 Resource Management and Provisioning Policies Aher obtaining DR, the server registers a new periodical /mer and checks idle DR per /me unit of leasing resources. If size of idle resources < DR, the server release resources with size DR = (DR- idle DR). If size of idle resources >= DR, the server will release resources with size=dr and deregister the /mer.

28 Evalua/on Methodologies and Experiments Workloads Evalua/on Methodologies Evalua/on Metrics Emula/on Experiment Configura/ons Resource Configura/ons Scheduling policies Resource management and provisioning policies System Level Evalua/on

29 Evalua/on Methodologies and Experiments: Workloads HTC workload traces: Lower load: NASA ipse trace (46.6% u/liza/on). For the NASA trace, the /me dura/on is three months, the average execu/on /me is 764 seconds, and the total number of jobs is Higher loads: SDSC BLUE trace (76.2% u/liza/on). For the SDSC trace, the /me dura/on is 32 months, the average execu/on /me is 4381 seconds, and the total number of jobs is LLNL Thunder trace (86.5% u/liza/on). For the LLNL trace, the /me dura/on is five months, the average execu/on /me is 2227 seconds, and the total number of jobs is

30 Evalua/on Methodologies and Experiments: Workloads MTC workload traces: Montage workflow Montage is an astronomy workflow applica/on, created by NASA/IPAC Infrared Science Archive for gathering mul/ple input images to create custom mosaics of the sky. The chosen Montage workload includes 9 types of task with the total amount of 1,000 jobs. Each job requests one node for running, and the average execu/on /me of jobs is seconds.

31 Evalua/on Methodologies and Experiments: evalua/on methodology Mainly concerned with the public cloud Emula/on methodology is used. Resource provider deploys Dawning Cloud, Deelman s system, Evangelinos s system, and a dedicated cluster system. Emula/on is deployed on testbed with nodes of following configura/on: 1.6 GH processor 2 GB memory CentOS 5.0 Opera/ng System

32 Evalua/on Methodologies and Experiments: Evalua/on Metrics For the service provider, we choose the resource consump/on in terms of node*hours. In Deelman s system, there is no role of a service provider, so we calculate the ac- cumulated resource consump/on of all end users, which amounts to the cost of a service provider in other models. For the dedicated cluster system, since a service provider owns resources, we calculate the resource consump/on of a service provider as the product of the configura/on size of a dedicated cluster system and the dura/on of a certain period.

33 Evalua/on Methodologies and Experiments: Scheduling policies The aim of this paper is not to evaluate the effect of different scheduling policies. For Dawning Cloud, Evangelinos, and dedicated cluster systems, following policies are used: For HTC server: First Fit policy is used For MTC server: First Come First Serve (FCFS) is used. Deelman s system uses no scheduling policy, since all jobs run immediately without queuing.

34 Evalua/on Methodologies and Experiments: Evalua/on The Metrics of the Service Provider Using Four Systems for the NASA Trace.

35 Evalua/on Methodologies and Experiments: Evalua/on For the NASA, SDSC, and LLNL traces, in comparison with the dedicated cluster system or Evangelinos s system, service providers in Dawning Cloud save the resource consump/on maximally by 25.6% and minimally by 7.9%. This is because service providers in Dawning Cloud can resize resources according to varying workload status. We also find that the the saved resource consump/on is inversely propor/onal to the resource u/liza/on reported in the traces, this is because that high u/liza/on implies less space for saving resources.

36 Evalua/on Methodologies and WORKFLOW. Configuration Experiments: Evalua/on resource consumption (node*hour) saved resources tasks per second dedicated cluster / system Evangelinos s system Deelman s system % DawningCloud % THE METRICS OF THE SERVICE PROVIDER RUNNING FOUR SYSTEMS FOR THE MONTAGE WORKFLOW.

37 Evalua/on Methodologies and Experiments: Evalua/on In comparison with the dedicated cluster system or Evangelinos s system, the service provider in the Dawning Cloud saves the resource consump/on by 67.5%. This is because Dawning Cloud owns ini/al resources with the smaller size, and resizes dynamic resources driven by the change of workload status.

38 Evalua/on Methodologies and Experiments: Evalua/on The total resource consump/ons of the resource provider using four different systems.

39 Evalua/on Methodologies and Experiments: Evalua/on The management overhead of the resource provider.

40 Evalua/on Methodologies and Experiments: Evalua/on For the dedicated cluster system, since the resource provider owns resource, it has no management overhead in terms of obtaining dynamic resources. Evangelinos s system has the lowest management overhead, since it leases resources with the fixed dura/on. Dawning Cloud has smaller management overhead than that of Deelman s system, since the ini/al resources will not be reclaimed un/l a TRE is destroyed.

41 Conclusion For HTC and MTC workloads, we can conclude that that small- to- medium scale scien/fic communi/es indeed can benefit from the economies of scale of public clouds with the support of the enabling system Dawning Cloud.

42 Conclusion Scien/sts may prefer the ownership of virtual resources, since this reduces the uncertainty concerning access when needed and to have a beaer control over the virtualized resources which become difficult due to mul/- tenant architecture in case of public clouds. Studies have shown that private clouds like Nimbus incurred less variability and showed a beaer compu/ng performance due to the underlying hardware. The public cloud providers may not easily agree to implement these resource management architectures as they incur a large management overhead.