Abstract

This paper does a systematic review of the possible design space for cloud-hosted applications that may have changing resource requirements that need to be supported through dynamic service level agreements (SLAs). The fundamental SLA functions are reviewed: Admission Control, Monitoring, SLA Evaluation, and SLA Enforcement - a classic autonomic control cycle. This is followed by an investigation into possible application requirements and SLA enforcement mechanisms. We then identify five basic Load Types that a dynamic SLA system must manage: Best Effort, Throttled, Load Migration, Preemption and Spare Capacity. The key to meeting application SLA requirements under changing surge conditions is to also manage the spare surge capacity. The use of this surge capacity could be managed by one of several identified load migration policies. A more detailed SLA architecture is presented that discusses specific SLA components. This is done in the context of the OpenStack since it is open source with a known architecture. Based on this SLA architecture, a research and development plan is presented wherein fundamental issues are identified that need to be resolved through research and experimentation. Based on successful outcomes, further developments are considered in the plan to produce a complete, end-to-end dynamic SLA capability. Executing on this plan will take significant resources and organization. The NSF Center for Cloud and Autonomic Computing is one possible avenue for pursuing these efforts. Given the growing importance of cloud performance management in the wider marketplace, the cloud community would be well-served to coordinate cloud SLA development across organizations such as the IEEE, Open Grid Forum, and the TeleManagement Forum.

Highlights

  • Service level agreements (SLAs) are used to define the necessary Quality of Service (QoS) for an application or user in an IT system

  • Summary and recommendations This paper has reviewed the basic requirements for providing dynamic service-level agreements, and developed a draft plan for implementing and evaluating such dynamic service level agreements (SLAs) in OpenStack

  • This SLA architecture does require that applications understand what their own resource requirements are

Read more

Summary

Introduction

Service level agreements (SLAs) are used to define the necessary Quality of Service (QoS) for an application or user in an IT system. For the SLA mechanisms that have been identified, we can define the following Server Load Types that can be used by the Cloud Scheduler and SLA Manager to enforce SLAs (as illustrated in Figure 3): Type I Service Loads are Best Effort, i.e., application VMs that are allocated using existing methods with no SLAs. As a practical matter, not all user applications may need or want an SLA, and the cloud provider may not want to require that all tenants must specify an SLA. Processes and VMs of each Load Type must be represented in some number and distribution whereby a cloud scheduler can effectively use them to manage the overall cloud utilization, while ensuring that individual application performance requirements are being met. Demonstrate process throttling with cgroups Demonstrate processes and VMs live migration

Demonstrate End-to-End Integrations
Develop and Evaluate Learning Algorithms
Develop and Evaluate Distributed SLA Managers
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call