28-06-2013, 01:06 PM
In Cloud, Can Scientific Communities Benefit from the Economies of Scale?
Cloud, Can Scientific.pdf (Size: 789.04 KB / Downloads: 19)
Abstract
The basic idea behind Cloud computing is that resource providers offer elastic resources to end users. In this paper,
we intend to answer one key question to the success of Cloud computing: in Cloud, can small or medium-scale scientific
computing communities benefit from the economies of scale? Our research contributions are three-fold: first, we propose an
enhanced scientific public cloud model (ESP) that encourages small or medium scale research organizations rent elastic
resources from a public cloud provider; second, on a basis of the ESP model, we design and implement the DawningCloud
system that can consolidate heterogeneous scientific workloads on a Cloud site; third, we propose an innovative emulation
methodology and perform a comprehensive evaluation. We found that for two typical workloads: high throughput computing
(HTC) and many task computing (MTC), DawningCloud saves the resource consumption maximally by 44.5% (HTC) and 72.6%
(MTC) for service providers, and saves the total resource consumption maximally by 47.3% for a resource provider with respect
to the previous two public Cloud solutions. To this end, we conclude that for typical workloads: HTC and MTC, DawningCloud
can enable scientific communities to benefit from the economies of scale of public Clouds.
INTRODUCTION
raditionally, in scientific computing communities (in
short, scientific communities), many small- or
medium-scale organizations tend to purchase and
build dedicated cluster systems to provide computing
services for typical workloads. We call this usage model
the dedicated system model. The dedicated system model
prevails in scientific communities, of which an
organization owns a small- or medium-scale dedicated
cluster system and deploys specific runtime environment
software that is responsible for managing resources and its
workloads. A dedicated system is definitely worthwhile
[35] as such a system is under the complete control of the
principal investigators and can be devoted entirely to the
needs of their experiment. However, there is a prominent
shortcoming of the dedicated system model: for peak
loads, a dedicated cluster system can not provide enough
resources, while lots of resources are idle for light loads.
THE ESP MODEL
In this section, first we describe three roles in a Cloud site;
second, we introduce the details of the ESP model; third,
we list the distinguished features of the ESP model.
2.1 Three Players
We identify three roles in a Cloud site: resource
provider, computing service provider and end user.
A resource provider owns a Cloud site (or a federated
cloud systems [17]), and offers elastic resources to service
providers in a pay-as-you-go manner [2].
Different from EC2, of which a resource provider
directly offers resources to ends user, we identify another
role: computing service provider (in short, service provider). A
service provider acts as the proxy of an organization, leases
resources from a resource provider and provides
computing service to its end uses. Each staff in an
organization plays the role of an end user. In this paper,
we do not consider the case of which there are many
compelling resource providers
AN ENABLING SYSTEM: DAWNINGCLOUD
To provide computing services, traditionally a small or
medium scale organization owns a dedicated cluster
system. Since different organization may have different
work plans, their workloads may vary in the same period.
We argue that on a Cloud site, the consolidation of large
amount of heterogeneous scientific workloads may
achieve the economies of scale. So, according to the ESP
model and on a basis of our previous PhoenixCloud
system [13] [14], we design and implement an enabling
system, DawningCloud, for a resource provider to
consolidate heterogeneous scientific workloads. In this
paper, we mainly consider two workloads: HTC and
MTC.
Our previous PhoenixCloud system has two major
features: first, it presents a runtime environment
agreement that expresses diverse runtime environment
requirements of different service providers; second, it
treats runtime environment as a first-class entity and
enables creating coordinated runtime environments on
demand. PhoenixCloud supports two workloads: web
service applications and parallel batch jobs.
Dynamic Resource Negotiation Mechanism
We present the dynamic resource negotiation mechanism
in DawningCloud as follows:
1) A service provider specifies its requirement for
resource management in a resource management policy. A
resource management policy defines the behavior
specification of the HTC or MTC server in that the server
resizes resources to what an extent according to what
criterion. According to a resource management policy, the
MTC or HTC server decides whether and to what an
extent resizes resources according to current workload
status, and then sends requests of obtaining or releasing
resources to the resource provision service.
2) A resource provider specifies its requirement for
resource provisioning in a resource provision policy, which
determines when the resource provision service
provisions how many resources to different thin runtime
environments in what priority. According to a resource
provision policy, the resource provision service decides to
assign or reclaim how many resources to or from a thin
runtime environment.
CONCLUSION
In this paper, we have answered one key question to the
success of Cloud computing: In scientific communities,
can small- or medium-scale organizations benefit from
the economies of scale? Our contributions are four-fold:
first, we proposed a dynamic service provisioning (ESP)
model in Cloud computing. In the ESP model, a resource
provider can create specific runtime environments on
demand for MTC or HTC service providers, while a
service provider can resize dynamic resources. Second, on
a basis of the ESP model, we designed and implemented
an enabling system, DawningCloud, which provides
automatic management for heterogeneous MTC and HTC
workloads. Third, our experiments show that for typical
MTC and HTC workloads, MTC and HTC service
providers and the resource service provider can benefit
from the economies of scale on a Cloud platform.