1. Home
  2. Training Library
  3. Alibaba Cloud
  4. Courses
  5. Using Auto Scaling to Support Your Alibaba Cloud Workloads

Triggered Tasks

Contents

keyboard_tab

The course is part of this learning path

Start course
Overview
Difficulty
Intermediate
Duration
49m
Students
10
Ratings
5/5
starstarstarstarstar
Description

This course explores Alibaba Auto Scaling. We'll look at the main applications of the Auto Scaling service and you'll follow along with practical demonstrations direct from the Alibaba Cloud platform to learn how to use each auto scaling service.

Learning Objectives

  • Get a basic understanding of Alibaba Auto Scaling
  • Learn about key auto scaling concepts
  • Understand the core functions of auto scaling, including scaling group,s scaling configurations, and scaling rules
  • Learn how to trigger scaling manually and how to create triggers for automatic scaling events

Intended Audience

This course is intended for anyone looking to use auto scaling to manage their Alibaba Cloud workloads, as well as anyone studying for the ACP Cloud Computing certification exam.

Prerequisites

To get the most out of this course, you should have a basic understanding of the Alibaba Cloud platform.

Transcript

Welcome back. So in the last section, we saw how we can manually trigger scaling rules to add or remove instances from our scaling group. So what are the automated ways that we can trigger scaling rules? Well, the first is scheduled tasks. You can create up to 20 scheduled tasks, according to input parameters. If a scheduled task fails to trigger the execution of a scaling rule because the scaling group is executing a scaling activity, or because the scaling group is disabled, then the scheduled task will be automatically retried.

There's something called the launch expiration time. Inside of this time window, scheduled tasks will keep periodically retrying. Once you've exceeded that launch expiration time window, the scheduled task will be abandoned. It will be considered to have failed. If multiple tasks are scheduled at similar times to execute a scaling rule for a particular scaling group, the earliest task triggers the scaling activity first, other tasks will attempt to execute the rule within their launch expiration time. But a scaling group can only execute one scaling activity at a time. So this other tasks might have to retry several times. If another scheduled task is still triggering attempts within its launch expiration time after the scaling activity has finished, the scaling rule will be executed, and the corresponding scaling activity is triggered.

Just to make that a little clearer. If you have multiple scheduled tasks that occur very near to each other in time, the first task that's scheduled will of course execute first, while the scaling activity that, that first task has triggered is going on, your other scheduled scaling tasks may have to wait. They might have to retry several times, but as long as your first scaling task happens before the launch expiration time expires for your other scaling tasks, then there'll be able to continue retrying and, eventually. successfully execute. If multiple tasks are scheduled at the same time, the latest scheduled task is the one that will be executed. So if you have multiple tasks that are supposed to happen at the same point in time, the one you created last will be the first to execute. That's how scheduled tasks work.

In a moment, we'll take a look at that in the console, but before we do that, let's see how we can create and manage event-triggered tasks. So event-triggered tasks do not need to be unique. Event-triggered tasks can not execute during a scaling group's cool down period. Unlike manual or scheduled task, an event-triggered task will be rejected if the scaling group is already executing another scaling activity, they will just not run. So if another activity is executing, then an event-triggered task will give up. It doesn't have a retry window like a scheduled task does it will simply fail. And the next time the alarm is triggered to run that task, then it will run again. Let's take a look at both of these types of tasks in the Alibaba cloud console.

So here we are back in the console. Let's go ahead and try creating some scheduled tasks. First, we'll save our event-triggered tasks for later. So here under Scaling Tasks, I have this Scheduled Tasks section. I'll click on that and I'll create two. I'll create one scheduled task to add two instances and another to remove two instances. So I'll click on Create Scheduled Tasks and I'll create one called "add_2" that should execute today at let's say 5:43 pm. So in just a few minutes, then I will apply it to our test scaling group. And I will use an existing scaling rule because we already have a rule to scale up our group by two, and then I'll choose that rule. And then I have to say, what is the time interval within which this rule should retry if it fails on its first run? And I'll say it should keep retrying for 600 seconds, if it fails to execute the first time. And I'll click OK, and now that rule is ready, And then I'll create another one to scale the group back down that should trigger a few minutes later. I'll call that "remove_2", remove two instances. The description is not mandatory, but you can add one if you want. And again, I will set that for, let's say we set our original, let's say 5:45, and then the scaling group will be test scaling group and we'll use an existing rule, which is "scale_down_2", and I'll click OK, to create that rule.

So, in just a few seconds here, it will be 5:43 pm where I am, and then I should see this first rule execute. So let's go back to the scaling group view and go to the dashboard for our test scaling group. And let's see if we can watch this activity get triggered. We should see an activity get created in just a few seconds. That should add two more instances for the group. It's now 5:43. So let's go ahead and refresh. And sure enough, you can see there's an activity triggering right now, executing right now, called "add_2" instances. So that means our scheduled task has triggered our scaling rule that adds two instances, and that rule has created a scaling activity, but it's adding the two instances for us. And that should take a few moments. Let's wait for that.

All right, that task was successfully executed. It's now 5:44 pm. And in just a moment, in just a minute, we should see our removed two instances task trigger. So the "add_2" instances task has succeeded. Meaning our group total is now four instances. If we wait about another 40 seconds or so then we should see the "remove_2" instances scaling activity get triggered, because remember we have a scheduled task here to remove two that's set to run at 5:45. So let's go back to scaling groups, go back to the overview and I'll wait for that. We can fast forward through that. And when that happens, I'll come back to the video. All right, so it's now 5:45. Let's refresh and see if our task is executing.

Sure enough, "remove_2" is executing right now. There's a total of four in the group, but two of them are being removed and two are in service. In just a moment, the total should go down to two. And sure enough, we are now at two instances. So that worked. Now that we've tried scheduled tasks, let's try creating some event-triggered tasks. So I'll go over to Event-Triggered Tasks here in the left-hand menu, and we'll create two event-triggered tasks. I'll call this one "scale_out" and it will look at average CPU usage. It will monitor all of the instances in this scaling group. And if the average CPU usage is over 80% for one minute, one time, then we'll trigger the "scale_up_2" rule. And I'll click OK to create that rule. And then we'll create another event-triggered task that does the opposite. This one would be "scale_in". And what he will do, is again, monitor the instances in the test scaling group. But now when the CPU usage for those instances drops below 20% for one time at a one minute monitoring interval, he will scale the group down. So we'll click OK to create those two rules.

These two rules have now taken effect. And actually our instances right now are not doing anything at all. So what will happen is that the "scale_in" rule will continuously try to trigger and will continuously fail because we're already at the group minimum size. So if I were to go back to my scaling group and look at the scaling activities, we should start seeing these "remove_2" task get triggered, but they won't have any effect because we're already at the minimum size here. So, now that we've got those two tasks set up and ready to trigger, we need to find a way to increase the CPU load of our instances. So let's do that.

So I'll open the ECS console and I'll find a way from the ECS console to log into my instances and install a stress testing tool. Once I've done that, we can start monitoring the instances in cloud monitor and look at their CPU utilization to see if we're likely to trigger our "scale_out" rule. Let's fast forward through some of this configuration and I'll come back once the stress test is running. So after a little bit of behind the scenes work, we've set up a cloud monitor dashboard where we can see the CPU usage and other metrics for our auto-scaling group ECS instances. And we're running a stress test in the background that should start to show up on these charts in just a minute. You can also see that while we were waiting, we have several projected scaling activities. These were probably triggered by this task here "scale_in", which would have been triggered by the low CPU usage on our two ECS instances.

Remember this task will run any time average CPU usage is below 20% before our ECS instances were doing nothing. So that would have triggered an alarm for this event-triggered task here that would have tried to run the "remove_2" scaling rule that would have failed because our scaling group has at its minimum size of two. So let's go back to the cloud monitor console and see how our CPU stress test is fairing here. You can see that CPU usage is rapidly increasing for our two ECS instances. In a moment, that should cause our "scale_out" event-triggered task to run. So let's wait for that.

Here in scaling activities, we can see that the "scale_down" was rejected. Let's wait for these "scale_up" to occur. We should scale up to four instances in just a moment here. So let's fast forward a little bit in time to when that starts to take place. And sure enough, after a brief wait, we can see that we're now executing an "add_2" instances scaling activity as a result of our event-triggered task, having been triggered by our monitoring metric. So our CPU usage, our average CPU usage is now above 80% and it has been for more than one minute, which triggers an alarm that causes this "scale_out" triggered task to run our "add_2" scaling rule, and then "add_2" scaling rule triggers a scaling activity that adds two instances to the pool.

So now there's a total of four instances in service. And if we go back to the console, we can see our CPU usage is still pretty high, but if we wait another minute or so, it should drop back down. And once that happens, the "scale_in" rule should trigger, which will remove two of the instances from the pool. So let's go back and wait for that. And sure enough, after waiting a little while, we can see we're now removing two ECS instances. And if we go look at our event-triggered task list, we can see there's an alarm set here on "scale_in" and because our CPU usage is now below 20%. I'm not sure if we'll be able to see that here. There's a little delay in the monitoring metrics. Yes, actually, sure enough, you can see our usage is back near zero.

So our CPU usage has dropped and that has caused our scaling activity to trigger. And our group size should now be back to two. There's just one thing left that we should cover. How do you delete all of this? So let's try deleting our scaling group. Again, the delete mode that's used when you delete from the console from the web interface is what we call forced delete. What that should do is, automatically, delete both the ECS instances as well as both of our scaling rules. So let's try that.

So I'll click on Delete here and you'll see you'll get a warning. It will remove all ECS instances and I'll click OK. And keep in mind that if you did do this and some of your instances were manually added to the scaling group, those instances you manually added will not be deleted. They'll still live on, but it's just the automatically created ECS instances that will be removed. So you can see the group is now in the deleting state. What's interesting though, is here I can see I still have my two scheduled tasks and I still have my event-triggered tasks. Oh, excuse me. The event-triggered tasks were cleared for me, automatically, by the scaling group deletion process, but the scheduled tasks still remain in the console and I can delete those by hand. So let's go ahead and do that. Delete both of those and then go back to scaling groups, and sure enough, our scaling group is gone and that's it for this section of the course. Thank you for joining me for this demo.

About the Author
Avatar
Alibaba Cloud
Cloud Provider
Students
277
Courses
18
Learning Paths
2

Alibaba Cloud, founded in 2009, is a global leader in cloud computing and artificial intelligence, providing services to thousands of enterprises, developers, and governments organizations in more than 200 countries and regions. Committed to the success of its customers, Alibaba Cloud provides reliable and secure cloud computing and data processing capabilities as a part of its online solutions.