PaperlayerView exact revision on arXiv

Source-linked AI summary

In Cloud, Can Scientific Communities Benefit from the Economies of Scale?

Lei Wang, Jianfeng Zhan, Weisong Shi, Yi Liang

arXiv:1004.1276v1cs.DC

TL;DR

Small and medium scientific communities face a question unresolved by existing cloud approaches: can public clouds provide economies of scale for their workloads? The paper proposes the ESP model and DawningCloud, evaluates them with emulation, and reports substantial resource savings for HTC and MTC workloads.

  • Problem

    The paper asks whether small or medium scientific communities can benefit from economies of scale in public clouds.

  • Method

    The paper proposes ESP, implements DawningCloud to consolidate heterogeneous workloads, and evaluates it through emulation.

  • Results

    For typical HTC and MTC workloads, DawningCloud maximally saves service-provider resource consumption by 44.5% and 72.6%, respectively.

  • Takeaways & Limitations

    For typical MTC and HTC workloads, the paper concludes that DawningCloud can enable scientific communities to benefit from public-cloud economies of scale.

  • Takeaways & Limitations

    The evaluation constrains most parameter analysis to one or two varying parameters, with other settings fixed at a representative baseline configuration.

Abstract

from arXiv · show

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 organizations to 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.

1 INTRODUCTION

The paper asks whether small and medium scientific communities can gain economies of scale from public clouds, addressing limitations in dedicated, private, hybrid, and existing public-cloud models. It proposes ESP and DawningCloud, then evaluates their resource savings for scientific workloads.

  • Motivation: Dedicated clusters can be insufficient during peak loads while leaving resources idle during light loads.This motivates elastic resource provisioning for scientific communities.
  • Research question: The paper focuses on whether small or medium scientific communities can benefit from economies of scale in public clouds.The proposed public-cloud option is presented as complementary to private and hybrid solutions.
  • Research gap: Prior work leaves this question unresolved for scientific communities and mainly addresses private or hybrid clouds.Existing public-cloud solutions also provide limited support for scientific-community workloads.
  • Contributions: The ESP model lets service providers rent elastic resources, retain runtime-environment control, and resize resources according to workload status.This differs from dedicated systems, private or hybrid clouds, and earlier public-cloud models.
  • Contributions: DawningCloud consolidates heterogeneous scientific workloads on one cloud site and is evaluated using an emulation methodology against two public-cloud solutions.The evaluation targets typical high-throughput computing and many-task computing workloads.
  • Results: 44.5% for HTC and 72.6% for MTC are the maximum service-provider resource-consumption savings reported for DawningCloud.The cited comparison is against the system incarnating Deelman’s model.

2 THE ESP MODEL

The ESP model separates resource provision from scientific computing services: public-cloud providers create runtime environments, service providers manage them, and end users submit workloads. Its design supports multiple small or medium communities sharing elastic resources while preserving service-provider control.

  • Roles: The ESP model distinguishes resource providers, computing service providers, and end users within a cloud site.The resource provider owns the cloud site, the service provider leases resources and offers computing services, and end users submit applications.
  • Scenario: Two service providers can rent resources from a public cloud provider and consolidate their workloads on one cloud site.This scenario illustrates shared use of public-cloud resources by scientific communities.
  • Usage pattern: A service provider specifies workload, resource, and operating-system requirements, then receives a customized runtime environment from the resource provider.The service provider subsequently manages the environment and its end-user accounts.
  • Usage pattern: Runtime environments can resize resources by leasing more capacity or releasing idle resources according to current workload status.When service ends, users back up data, accounts are destroyed, and the runtime environment and resources are withdrawn.
  • Distinguished features: ESP provisions resources and runtime environments for n small or medium scientific communities, enabling shared use beyond dedicated or private-cloud scopes.The model is designed to guide a platform for studying economies of scale.
  • Distinguished features: ESP separates the resource provider from the independent service-provider role, while service providers rent resources and serve end users.This separates resource ownership from computing-service delivery.

3 AN ENABLING SYSTEM: DAWNINGCLOUD

DawningCloud is a layered system that consolidates heterogeneous HTC and MTC scientific workloads through shared services, thin runtime environments, and dynamic resource management. Its design supports workload-specific execution, lifecycle management, and elastic resource negotiation.

  • Architecture: DawningCloud uses a layered architecture with a common service framework and thin runtime environments for different scientific workloads.The thin runtime environments delegate common functions to the shared framework while retaining workload-specific services.
  • MTC runtime: MTC execution parses workflow descriptions, submits dependent tasks to a scheduler, monitors triggers, and supports visual workflow editing.The trigger monitor tracks conditions such as database-record or file changes to drive later workflow stages.
  • Workload support: HTC and MTC runtime environments coexist by reusing the common service framework while adapting to different application structures and service needs.MTC workflows contain dependent small jobs, whereas HTC batch jobs are independent and have varying runtimes.
  • Lifecycle management: A thin runtime environment progresses through four states—inexistent, planning, created, and running—before providing services to end users.Lifecycle management configures resources, starts components according to dependencies, and marks the environment running once startup completes.
  • Resource management: DawningCloud dynamically resizes resources using provider-defined policies, initial and dynamic allocations, queue checks, demand thresholds, and idle-resource release.MTC uses a shorter checking resource cycle than HTC because its tasks typically run in seconds, while HTC jobs run longer.

4. EVALUATION METHODOLOGY AND EXPERIMENTS

The evaluation compares DawningCloud with dedicated, Deelman, and Evangelinos systems using representative HTC and MTC workloads. It measures provider performance, resource consumption, peak capacity, and resource-adjustment overhead over two-week workload periods.

  • Workloads: NASA and BLUE provide lower-load and higher-load HTC traces with 46.6% and 76.2% utilization, respectively.Their scales are 128 and 144 nodes, representative of small or medium organizations.
  • Workloads: The NASA HTC trace contains 2,604 jobs with a 575-second average execution time.The selected trace covers two weeks.
  • Workloads: The BLUE HTC trace has a 2,092-second average execution time and 2,666 total jobs.Its job resource-demand distribution and execution-time variation are shown in the corresponding trace figure.
  • Workloads: The Montage MTC workload contains 1,000 jobs across 9 task types, with one node requested per job and an 11.38-second average execution time.The workload is repeatedly submitted to match the two-week duration of the HTC traces.
  • Experimental design: The experiments compare DawningCloud with dedicated, Deelman’s, and Evangelinos’s systems under public-cloud scenarios.The comparison uses one resource provider and workload-serving organizations represented by the emulated systems.
  • Metrics: Evaluation metrics include completed jobs for HTC, tasks per second for MTC, node*hour resource consumption, peak nodes, and accumulated node-adjustment time.Metrics are measured over the same two-week workload-trace period.

4.3 Evaluation Methodology

The evaluation primarily uses emulation to accelerate repeated experiments and reduce the resource requirements of consolidating multiple scientific workloads. Separate simulators and simplified deployments represent the compared systems on a test bed.

  • Emulation methodology: Emulation enables many repeated experiments over multi-week traces within shorter execution periods.The authors motivate it by the time cost of real-system experiments and the hundreds of nodes needed for workload consolidation.
  • Test bed: All emulation systems run on a test bed with dual AMD Opteron CPUs, 2G memories, and CentOS 5.0.The test bed provides a common deployment environment for the emulated systems.
  • Simulation: Job simulators reproduce HTC submissions from trace times, runtimes, and node demands, while MTC submissions follow workflow dependencies.Submission and completion are accelerated by a factor of 1000.
  • Compared systems: Dedicated clusters are represented with simplified DawningCloud deployments containing resource and job simulation modules.The resource simulator defines the dedicated-cluster configurations.
  • Compared systems: The emulated DawningCloud retains resource provision, one server, and one scheduler per thin runtime environment while simulating resource requests and releases.The emulated Evangelinos system resembles a dedicated cluster because it leases fixed-size resources for fixed periods.
  • Compared systems: The emulated Deelman system and Evangelinos system are implemented within the DawningCloud framework for comparison.The emulation isolates the modeled resource-provisioning behavior of each system.

4.4 Experiment Configurations

The experiment emulates one resource provider serving two HTC organizations and one MTC organization. Scheduling uses first-fit for HTC, while MTC job flow follows dependency constraints.

  • Scenario: The scenario includes one resource provider, two HTC service organizations, and one MTC service organization.The methodology can extend to more service providers.
  • Scheduling: HTC scheduling uses first-fit, scanning queued jobs in arrival order and selecting the first job whose resource demand can be met.The study does not investigate differences among scheduling policies.
  • Scheduling: MTC job flow is generated according to dependency constraints before scheduling.This preserves workflow ordering during the experiment.

4.5 System-level Evaluation

The system-level evaluation compares DawningCloud with dedicated, Evangelinos’s, and Deelman’s systems across HTC and MTC workloads. DawningCloud reduces resource consumption while preserving comparable performance, and lowers consolidated resource-provider consumption.

  • Service-provider evaluation: 37.8% to 31.7%: DawningCloud saves service-provider resource consumption versus dedicated cluster and Evangelinos’s systems for NASA and BLUE traces, with the same or higher throughputs.The comparison uses fixed-size resources in the alternative systems and dynamic resizing in DawningCloud.
  • Service-provider evaluation: 44.5%: DawningCloud maximally saves service-provider resource consumption versus Deelman’s system for NASA and BLUE traces at the same performance.Dynamic resource negotiation and queue-based resource sharing reduce consumption relative to direct end-user resource acquisition.
  • Service-provider evaluation: 72.6%: DawningCloud saves service-provider resource consumption versus Deelman’s system for Montage, although Deelman’s system achieves higher throughput.Deelman’s immediate provisioning supports the high peak demand of the MTC workload.
  • Resource-provider evaluation: 47.3%: DawningCloud reduces the resource provider’s total resource consumption versus dedicated cluster and Evangelinos’s systems when three service providers’ workloads are consolidated.DawningCloud starts with smaller initial resources and resizes them according to changing demand.
  • Resource-provider evaluation: 705 nodes: DawningCloud’s resource-provider peak is 1.61 times that of dedicated cluster and Evangelinos’s systems, while its peak is 0.45 times Deelman’s system.The resource-provider total consumption is also 44.7% lower than Deelman’s system.
  • Management overhead: 120.6 node*hour: node-adjustment consumption is approximately this amount out of 77581 node*hour, and the paper describes the overhead as acceptable.Assigning and reclaiming one node takes 15.743 seconds in the real test, excluding operating-system wiping.

4.6 Parameter Analysis

The parameter analysis examines how initial resources, dynamic-resource thresholds, checking cycles, and leasing time units affect consumption, throughput, adjustment frequency, and management overhead. It uses baseline configurations and reports workload-specific settings and tradeoffs.

  • Analysis scope: The analysis varies one or two parameters while holding the others at baseline values because space limits prevent presenting all parameter effects.The authors state that these cases represent trends observed across all cases.
  • Initial resources and thresholds: B128_R100, B144_R100, and B166_R100: DawningCloud matches Evangelinos’s performance metrics when initial resources equal Evangelinos’s configuration and dynamic resources are effectively disabled.These configurations correspond respectively to NASA, BLUE, and Montage workloads.
  • Initial resources and thresholds: For HTC workloads, resource consumption increases with initial-resource size, while larger threshold ratios reduce dynamic-resource acquisition without an obvious relationship to completed jobs.Below Evangelinos’s configuration size, initial-resource size has no significant effect on completed jobs because dynamic resources remain available.
  • Checking resource cycle: S has small impact on resource consumption, completed jobs, and node-adjustment frequency; the selected checking cycle is 60 seconds for HTC and 1 second for MTC.The MTC setting reflects an average task execution time of about 10 seconds.
  • Leasing time unit: Management overhead is inversely proportional to C because shorter leasing units cause more frequent dynamic-resource requests.The authors select C as 60 minutes for DawningCloud and Deelman’s system as a tradeoff involving charging granularity.
  • Parameter recommendations: For MTC workloads, B can be approximately one-eighth of the dedicated-cluster configuration size, with R satisfying (B*R < RA) and (RA*R > RM), and S set to 1 second.RA is typical accumulated queued demand and RM is maximal accumulated queued demand, calculated through experiments.

4.7 Total Cost Ownership of a service provider in the Evangelinos’s system and the dedicated

The total-cost analysis compares a service provider using Evangelinos’s system with a real dedicated cluster system. It specifies the cluster’s hardware, depreciation, capital, maintenance, energy, and space-cost assumptions, and uses Amazon EC2 pricing for the cloud comparison.

  • Dedicated cluster assumptions: $30,000: the dedicated-cluster maintenance cost, with energy and space costing about $1,600 per month.These figures are included as operating expenses in the total-cost comparison.
  • Evangelinos’s system assumptions: Amazon EC2 pricing is used as the pricing meter for Evangelinos’s system, whose instance configuration is specified by CPU, memory, and disk capacity.The supplied passage introduces the EC2 pricing basis and instance resources for the cloud comparison.

4.8 Analysis

The analysis concludes that DawningCloud improves on two alternative Cloud solutions through dynamic resource management and policies, while Evangelinos’s system is more cost-effective than a dedicated cluster for service providers.

  • Evangelinos’s system is more cost-effective than a dedicated cluster because it delivers the same performance with lower total cost of ownership.
  • DawningCloud outperforms Evangelinos’s and Deelman’s systems from both service-provider and resource-provider perspectives.
  • MTC and HTC service providers can benefit from Cloud economies of scale when using DawningCloud.

5 THE PROOF OF THE ECONOMIES OF SCALE

The section analytically establishes that DawningCloud can match or improve service-provider performance while using no more resources than Evangelinos’s system, and can reduce total consumption when workloads are consolidated.

  • DawningCloud is analytically evaluated for achieving economies of scale on a Cloud platform irrespective of specific workloads.
  • DawningCloud’s initial configuration is not always optimal across configurations for MTC or HTC workloads.
  • For any MTC or HTC workload, some DawningCloud configuration uses no more resources and provides no worse performance than Evangelinos’s system.
  • For any sets of MTC and HTC workloads, configurations exist that keep the resource provider’s total consumption no greater than Evangelinos’s systems.
  • With workload consolidation, DawningCloud limits total resource consumption relative to Evangelinos’s system, while Evangelinos’s system remains more cost-effective than a dedicated cluster for service providers.

6. RELATED WORK

Related work covers Cloud economies-of-scale analyses, hybrid-cloud performance studies, elastic-site policies, storage evaluation, virtual execution environments, and resource-management systems, but the scientific-community question remains distinct.

  • Prior theory showed economies of scale for Web service workloads, but did not answer the question from the perspective of scientific communities.
  • Hybrid-cloud research examined using external Cloud providers to improve request performance for organizations operating local clusters.
  • Elastic-site evaluation compared on-demand, steady-stream, and burst policies to balance job turnaround time against thrashing and idle virtual machines.
  • Other efforts evaluated S3 for science grids, proposed virtual execution environments, or addressed fairness and lease management in Cloud and grid resource pools.

7. CONCLUSION

The paper answers whether small- or medium-scale scientific organizations can benefit from Cloud economies of scale. It proposes ESP and DawningCloud, and reports benefits for typical MTC and HTC workloads.

  • The paper proposes ESP, allowing resource providers to create runtime environments on demand while service providers resize resources for MTC or HTC workloads.
  • DawningCloud provides automatic management for heterogeneous MTC and HTC workloads on the ESP model.
  • Experiments show that MTC and HTC service providers and the resource service provider can benefit from Cloud economies of scale.
  • An analytical approach verifies that DawningCloud can achieve Cloud-platform economies of scale irrespective of specific workloads.
Loading 1004.1276v1…