This is Part 12 of Azure tutorial. In our previous video, we discussed
how to create a virtual machine skill set. In this video, we'll discuss the scaling options we have,
that is, how to increase or decrease VM instances in a scale set. At this point, if you're thinking,
why do we even need to increase or decrease VMs in a scale set. Well, there are a number of reasons.
One reason could be most of your customers use your application during specific times of a day.
Maybe 10 am to 12 noon and then again from 3 pm to 5 pm for example. During these two windows,
you want your application to be fast and performant. So, you may want to increase
the number of VM instances that run your application. Outside of these two windows,
your application does not have that much demand. So, to save on cost, you want to reduce the number
of VMs that run your application. Another reason could be, next week you are launching
a new product or a business line. So, starting next week, you're going to have a heavy peak,
maybe for three days. So, during the heavy peak season, you want more VMs to run your application.
Once the peak subsides, again to save on cost, you want to fall back to your baseline configuration,
and another reason could be, you're in a situation where you cannot predict the demand for your
application. So, you don't really know, when you need more processing power and when you can
fall back to that baseline configuration. Well, for this we can use metric based auto scaling.
Now, in azure there are three options for scaling VM instances up and down. Manually, through the
azure portal. Auto scale based on metrics or auto scale based on a defined schedule. You
can configure all these scaling options either at the time of creating the virtual machine scale set
or after it is created. At the time of creating the scale set, you configure scaling on the
"Scaling" tab as you can see right here. Now, in our case, we already created the virtual machine
scale set in our previous video. At the moment, we are looking at that scale set and as you can see
in this scale set, we have got three virtual machine instances. Now, to configure scaling
for the virtual machine scale set that is already created, we do that on the "Scaling" tab.
Notice, we have two choices for scaling - manual scale and custom auto scale.
With custom auto scale, again we have two choices. We can scale on any defined schedule
or based on any metric. We'll look at custom auto scale in just a bit. First, let's take a
look at this manual scale. So, at the moment we have manual scale selected and in our scale set
we have three VMs. Now, let's increase this to six. So, let's change the number to six and then
quickly click this button to save and then immediately, let's flip over to "Instances".
Notice, we have three VMs already and we want that to be increased to 6 VMs and you can see it's
creating another five instances. Probably this is a bit misleading. I'm sure after this process is
completed you know it's gonna take a few minutes, it's going to create another 3 VMs, taking the
total VMs count to 6. So, let's give it a few minutes. There we go. Our deployment is complete
and as expected the number of VMs in our skill set is 6. Now, let's go back to the "Scaling"
tab. At the moment, as you can see we are using manual scale. In a real world, it's a bit tedious
and time consuming if we have to manually scale out and scale in every time the demand for our
application changes. However, it's an option just in case if you want to manually scale.
Now, let's take a look at custom auto scaling. Notice, as soon as I select this radio button
we have a default auto created scale condition, and we have two choices here - scale based on
a metric or scale to a specific instance count. First, let's look at scale based on a metric. Here
we have instance limits. The minimum number of VMs we want, the maximum number of VMs and the
default. Let's change the default to 2. This default setting is interesting. At the moment,
we are scaling based on a metric. Let's say, for example, we are scaling based on CPU utilization,
but what if azure is not able to read CPU utilization metric. Well, we don't want our
system to crash. We want our system to be still highly available. Now, let's say at the moment,
within our scale set, we have one VM and then we have specified the default count as 2 and
we are scaling based on CPU utilization and azure is not able to read that metric. So what azure is
going to do is, automatically increase the number of VM instances to the default number
that is 2 in case it is not able to read the metric based on which we are scaling, in this case
CPU utilization, but the opposite is not going to happen, meaning, let's say in our scale set,
we already have three VMs and we have specified the default as 2 and in case if we are not able
to read the metric based on which we are scaling, in this case CPU utilization, it will not decrease
the VM instances from 3 to 2. It will only scale out not scale back in. Now, let's add a scale
rule. As you can see from the message here - no metric rules defined. So, let's add a rule.
At the moment, metric source for this scale rule as you can see is our virtual machine
scale set itself, vmss-demo. We have other metric sources if we want to. Next, time aggregation.
We have average because our metric at the moment is percentage CPU utilization and for percentage
CPU utilization average makes sense. We don't want minimum or maximum. So let's stick to average.
If we scroll down a bit, notice, at the moment average CPU percentage is 0.47% and that makes
sense, because, our VMs in the scale set are not doing much. So, if average CPU percentage
is greater than 70% for a duration of 10 minutes, that is, for continuously 10 minutes
the average CPU percentage is greater than 70% then we want to increase the instance count
by one, and then we have something called cool down time here, and it's in minutes, and at the
moment the value is five minutes and this is an interesting setting, because after a scale
operation is performed, in this case the instance count is increased by one, we're going to give it
five minutes to cool down, so the metrics can stabilize before another scale operation can
be performed. So let's add the scale rule. There we go, our scale out rule is added and notice the
message that we have here - it is recommended to have at least one scale in rule. Now,
when there's a lot of demand for our application, we want more VMs, so we have a scale out rule.
We need to do the opposite as well. When the demand subsides, we want to reduce the number
of VMs that run our application to save on cost. So, it is recommended to have at least
one scale in rule. So, let's add that. Again, same idea. If the average CPU percentage is less than,
maybe 25%, then we want to decrease the instance count by one, again,
the cooldown time is five minutes. Let's add this scaling rule. There we go. We have a scale
out rule and scale in rule. Let's save these changes. There is an error saving changes.
Here is the error. This subscription must be registered to use namespace "microsoft.insights".
To fix this, let's fire up another browser tab and navigate to portal.azure.com.
Once you're logged in, click on "Subscriptions".
At the moment, I only have one subscription. So, let's click on that
and on the "Subscription" blade, scroll all the way down and look for resource providers,
and the resource provider that we want to register is "microsoft.insights".
Here it is. Select that and then click this "Register" button.
There we go. Registration complete. Now, let's try to save our changes.
There we go, our scale condition is successfully saved.
We can also scale to a specific instance count. Let's actually add another scale condition,
and this time, select this radio button "Scale to a specific instance count".
In the text box here, you specify the instance count you want to scale to. So,
on 24th of December 2020 at 12 AM, increase the instance count to 10
and on the same day that is on 24th of December 2020 at 11:59 PM, fall back to the baseline
configuration. You can repeat this scale condition on a specific days of the week if you want to.
So, bottom line, if your application demand increases, the load on the VM instances
in your scale set also may increase. If this increased load is consistent rather than just
a brief demand, you can configure auto scale rules both to increase and reduce the number
of VM instances in the scale set. That's it in this video. Thank you for listening.