Using Cloud Assembly Native Auto-Scale Functionality (SKKB1048)

In this blog post we are going to look at how to use VMware Cloud Assembly auto-scale functionality when building AWS Native Blueprints

 

Update Log:

Introduction

Assembly offers integration with AWS
Auto-Scale functionality. You can set it up from your Blueprint editor. It
enables you to set for an auto scaling group for machines, which automatically
increases or decreases resources based on policies.

Configuring Auto-Scale in your Blueprint

Lets configure an example scale policy for a machine.
In your BP editor under machine properties you can find the autoScaleConfguraiton Machine property . This is where you can configure desiredCapacity, maxSize, metricScaleRules, minSize, policy and scheduledScaleRules.


Instead if configuring all of the settings in the yaml code editor lets to it from the Properties tab.

Once on the Properties tab in your editor until you find Rules of the METRIC policy

And Rules of the Scheduled policy. As you can se you can configure a policy for a metric or a scheduled policy that will run on a given interval. Let’s build a Metric policy.

Here are the action of the scale operation you can configure:
• The type of action that should occur when the scale rule fires. – The scaling action that occurs when triggered
• The amount by which to scale, based on the specified adjustment type – The amount by which to scale up or down. Positive values add, and negative values subtract.
• The amount of time, in seconds, after a scaling activity completes and before the next scaling activity can start. – The minimum time, in seconds, between scaling actions.

Here is the trigger of the scale operation you can configure:
• Тhe metric that defines what the rule monitors. – The metric that is the catalyst for a scaling action.
• The period, in seconds, over which the specified statistic is applied – The period, in seconds, at which the metric is evaluated. Valid values are 10, 30, and any multiple of 60.
• The operator that is used to compare the metric data and – The comparison operator that is used when evaluating the collected metric data against the threshold.
• The metric statistic type – How metrics from multiple instances are combined.
• The threshold of the metric that triggers the scale action – The threshold that, when reached, triggers the scaling action.
• The number of periods over which data is compared to the specified threshold – The number of periods over which to measure data. The total evaluation time cannot exceed one day, so this number multiplied by the period cannot exceed 86,400 seconds.

Lets say for this example we want to :
• Change the count property of the machine resource upon scale. Therefore, adding additional machine resource.
• We want to add 2 machines each time the policy gets triggered.
• Wait 60 seconds before performing another scale activity.
• I want to scale when average CPU Utilization metric goes above 1
• Measure the average CPU based over 3 periods x 60 seconds = 180 seconds

Usually some of these settings will be higher, , but for the sake of the lab.

My policy looks like this:


The yaml representation of this policy in my code editor would be :

[sourcecode language=”yaml”]

autoScaleConfiguration:
policy: Metric
metricScaleRules:
– action:
type: ChangeCount
value: 2
cooldown: 60
trigger:
metric: CPUUtilization
period: 60
operator: GreaterThan
statistic: Average
threshold: 1
evaluationPeriods: 3
maxSize: 3
minSize: 1

[/sourcecode]

Note that I also have specified the minimum and maximum number of nodes in the scaling group. The whole BP example can be found in my gitlab repo at bit.ly/The-Gitlab

To stress the VM once deployed I run this as a cloud-init script:

[sourcecode language=”yaml”]

cloudConfig: |
#cloud-config
repo_update: true
repo_upgrade: all
packages:
– git
runcmd:
– sudo -s
– yum install -y epel-release
– yum install -y stress
– stress –cpu 4 –timeout 4m

[/sourcecode]

Now lets go in AWS under EC2 and select the Auto Scaling Groups tab
Initially we see only one instance of the deployed VM

After the policy gets triggered based on the CPU stress we can see a scale-out taking place

 

 

Final Step

If all went well, go grab a beer.

Leave a Reply

Your email address will not be published. Required fields are marked *