Helen will come back with the author's killing health checks.
So getting health checks we have learned a little bit about it throughout the previous lectures and
we knew that by default auto scaling depends primarily on easy to status checks or health checks in
order to decide whether an instance defined under that or just getting group is healthy or unhealthy.
Why is that important because it is the duty of the artist killing group that instance is part of to
ensure that the available fleet is healthy and if not terminate the unhealthy one or ones and create
another one or launch other two instances to replace them.
How about if I had bought elastic load balancing also working closely tied to the other or skinning
and by the way I can I can add one or more elastic load balancers to an artist killing group.
So when you have an elastic load balance or or or balance or added to the killing group you have the
choice of whether you consider so the oldest killing will consider the Elby health checks or the elastic
lock balancers health checks as part of the process so each time we define Elby you have the choice
to push out a skill and group to accept the health checks or they will be as well.
Why is that important.
You have multiple sources of health checks and that means more pointers on that if you do instances
and different sources of alarm's to the other Schelling group that an instance is not responding well
good.
Now this also ties into the fact that they will be not just going to have to work very closely in harmony
together.
Remember when we said that any instance added under the other Skilling group will be registered with
they will be any new instance launched will be registered with theyll be any instance terminated it
will be did we just tell you they will be.
So why not use that youll be a health check also to feed into the health check process.
The just killing together.
And along with the easy to say we are not replacing the easy to set us checks.
Please bear that in mind we are not replacing it with status checks we are providing more sources such
that if the easy to service or and ill be or the second deal we are going to be any one of them if it
detects a problem when they see to instance that is enough for the artist and group to act on that instance
scheduled for terminations start terminating.
Easy to instance and then launching another one health check grace period.
No question if an instance is launched by an artist getting grilled by just getting service itself through
an upskilling group would the instance once it comes in service immediately becomes senator for health
checks.
And the answer is by default no after that instance comes up boots up and it is in service under that
or just getting group that upskilling group by default will wait for five minutes 300 seconds and during
the 300 seconds it's just a grace period I'm giving to instance enough period to load any apps any patches
any software updates anything.
Once it comes up and then it will be judged for whether it is healthy or unhealthy.
So doing the 300 seconds easy to instance is not judged for whether it's healthy or unhealthy by killing
even if complains about the fact that she's unhealthy come from the easy to status checks or from any
other Elby is configured to work with the older sibling group so completely ignored to complete grace
period given to instance to finish everything it is supposed to finish and hopefully within that five
minutes it is going to be all sound and good and then judged to be healthy or unhealthy.
So the grace period is that time alters killing weeds from the time an instance comes into service becomes
in service under the skin before checking its health status.
Can you disable it.
Yes if a value is set to zero that means there is no grace period.
And as soon as it becomes inservice its health will be checked and it will be judged for whether it's
healthy or unhealthy based on the feedback from the 82 status checks and any Albee's if they are defined
under the ceiling.
So until they get this period expired if there is one or if it is left to the default then any unhealthy
reports are ignored.
And after it expires or just getting treated as normal and how can can judge whether it is healthy or
unhealthy.
When will it be defined as unhealthy if they're easy to instance.
The reports that the instance is unhealthy because of what because of an impaired situation because
of a software or hardware problem on the physical host where that easily easy to instance is virtually
located
or it could be if I have been defined and I have configured or tick the box that they will be health
checks are also taken into account that we're just getting group then if any report from out of service
comes from any of the it'll be defined under the Skilling group then also it will be marked as unhealthy.
And then what one source.
Any source of reporting that is to instance as unhealthy is enough for the other Skilling to market
for replacement.
What does that mean.
That means it will do it for domination and terminate the two to instance and then launch a new one
should it get scheduled for termination.
Unhealthy is it to instance and then it will never recover automatically.
So the health will never be recovered once marked for termination by the other group because of a report
from easy to or from an Elby that it's unhealthy.
It will be marked for determination to be scheduled for the nation and it will not recover again.
Is there a way and that is a potential exam question.
Is there a way when it is scheduled for demolition before the auto scaling starts terminating to bring
it back into a healthy status.
Yes.
Manually using the command line and this is the command set instance health to set it back to health.
This is a very short time period between the time it is scheduled to determination and when the termination
starts if the termination has started and you issue this command you will get an error back because
the instance is terminating.
So scheduled for demolition that means.
OK.
Now after these few seconds you will be terminated.
During that period of time then you can place the set are just getting said instance health you can
ensure that command the command line interface and not from not from the company.
And if it starts to do anything for instance you will get an error if you try to apply this command.
So if you apply this command quickly enough after it was scheduled for demolition it you will put it
back into a healthy status when when you do that when it was decided that it was unhealthy because you
were troubleshooting or doing something restarting the rebooting the easy to install.
And you know there is something there is nothing wrong with that is it for instance.
So in that situation you want to put it back as healthy because you're done with what you were doing
and you don't want it to be terminated.
If you are late and you didn't notice that then it will be terminated and your instance will be launched.
Now if I want to avoid such a situation what do I do.
Remember when we talked about the Stand by stand by what you can always put an instance into it but
sent by Muite troubleshoot and install software and do whatever you want.
Reconfigure it and then put it back through pending and it will be health checked and back into inservice
one very important and again exam question.
Remember when we talked about the easy rebalancing we said first of all just killing will and or launch
two instances.
I believe it is one that had let's say two instances.
So it will increase the fleet and then terminate in the LTVs on that had more instances.
Right.
So that's how the balancing happens.
So first launch then removed from the existing in different instances detected as unhealthy to exactly
the opposite.
Let me get rid of the unhealthy first and then launch a new one.
And what's the logic behind that.
Think about if it was marked as an unhealthy and it true was unhealthy then what's the point of keeping
it right.
So you have a bad apple in a box of good apples.
Why do you keep this up.
You just get rid of it and hopefully you get a replacement.
And that's exactly what happens here.
So it will first terminate the unhealthy instance and then onto scaling attempt to launch new instances
to replace a new instance to replace the one delaminated or new instances to replace the ones terminated.
OK.
So it makes perfect sense here and also makes perfect sense in that rebalancing to first launch new
ones before terminating the healthy ones.
One additional important thing that you need to remember here is elastic IPs and EBAs volumes that are
on the instant that is being terminated will be attached from the terminated instance and you need to
manually attach them to the new instance.
So this is very important for because it is going to be manually done and we need to remember that as
volumes Plus the IPs will need to be attached to the new instance manually.
OK.
So let's take a quick break and we'll come back to their next lecture with Otis killing.
We're still with upskilling group so don't go anywhere.
I'll see you in the next lecture.