Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method for Auto-Tuning Elastic Scaling Policy Parameters Based on Past Scaling Events

IP.com Disclosure Number: IPCOM000240659D
Publication Date: 2015-Feb-16
Document File: 4 page(s) / 107K

Publishing Venue

The IP.com Prior Art Database

Abstract

This invention proposes a heuristic method to adjust the elastic scaling parameters based on the short term history of scaling events for a given application.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 49% of the total text.

Page 01 of 4

Method for Auto -

Events

Background:

One of the key advantages of using cloud computing is the ability to provide elastic resources that can be provisioned on demand within a short period of time. The goal is to provide an adequate level of service while utilizing the minimum of physical resources as possible . Performance metrics (e.g., CPU utilization, response time) are monitored and used by a controller as criteria to decide when to provision or remove resources for the workload. The elasticity behavior is defined by a set of parameters included in a policy that normally uses fixed values. Example of such parameters include: thresholds defined for the selected metric, period of time that these thresholds should be exceeded in order to trigger the scaling , number of instances to add or remove.

This type of static policy cannot avoid or minimize some undesirable situations that can happen depending on the nature of the traffic and the values selected when defining the policy. Following are 2 examples of such situations, using the CPU Utilization as the criteria for horizontal scaling , where a new virtual machine instance is created along side the original one :

Scenario 1

11::: Cycle of "scale outs" followed by "scale ins" or vice

Cycle of "scale outs" followed by "scale ins" or vice - -versa

versa

When the load has a bursty nature (i.e., high number of requests for a short period of time), it may trigger the scale out of a new instance but it may take several minutes from the moment the CPU usage exceeds the threshold for the new instance to be ready. The new instance may be too late to help with the extra load and soon it will be removed as it is not needed anymore. If this behavior is cyclical, controller resources are spent creating and deleting VMs without any benefit.

Possible misconfigurations:

scale in threshold is too high and/or scale out threshold is too low

trigger time is too short

1

-Tuning Elastic Scaling Policy Parameters Based on Past Scaling

Tuning Elastic Scaling Policy Parameters Based on Past Scaling



Page 02 of 4

Scenario 2

22::: Sequence of "scale outs" or "scale ins" Sequence of "scale outs" or "scale ins"

When the load has a surge that requires a lot of CPU power for a longer period of time, the elastic scaling may be too slow to provide the required resources. Likewise, when the workload drops drastically, there will be a several "scale ins" until the CPU utilization stays above the scale in threshold .

Possible misconfiguration:

number of instances to add or remove is too low

Problem Statement :
Traditional auto-scaling decisions can be categorized in two types : (1) Proactive: where scaling decisions involve predicting the workload demand and preparing the resources ahead of time , and (2) Reactive: where scaling decisions are made based on static settings (e.g., utilization etc.) and new instances are

2


Page 03 of 4

created after the static setting limits (e.g., utilization threshold) are exceeded....