1 00:00:00,770 --> 00:00:04,980 Helen will come back with the author's killing health checks. 2 00:00:05,150 --> 00:00:10,620 So getting health checks we have learned a little bit about it throughout the previous lectures and 3 00:00:10,620 --> 00:00:21,390 we knew that by default auto scaling depends primarily on easy to status checks or health checks in 4 00:00:21,390 --> 00:00:27,330 order to decide whether an instance defined under that or just getting group is healthy or unhealthy. 5 00:00:27,330 --> 00:00:35,070 Why is that important because it is the duty of the artist killing group that instance is part of to 6 00:00:35,070 --> 00:00:43,800 ensure that the available fleet is healthy and if not terminate the unhealthy one or ones and create 7 00:00:43,830 --> 00:00:53,140 another one or launch other two instances to replace them. 8 00:00:53,460 --> 00:01:00,490 How about if I had bought elastic load balancing also working closely tied to the other or skinning 9 00:01:00,660 --> 00:01:08,260 and by the way I can I can add one or more elastic load balancers to an artist killing group. 10 00:01:08,280 --> 00:01:14,520 So when you have an elastic load balance or or or balance or added to the killing group you have the 11 00:01:14,520 --> 00:01:22,760 choice of whether you consider so the oldest killing will consider the Elby health checks or the elastic 12 00:01:22,760 --> 00:01:28,950 lock balancers health checks as part of the process so each time we define Elby you have the choice 13 00:01:29,100 --> 00:01:34,560 to push out a skill and group to accept the health checks or they will be as well. 14 00:01:35,100 --> 00:01:36,590 Why is that important. 15 00:01:36,630 --> 00:01:42,270 You have multiple sources of health checks and that means more pointers on that if you do instances 16 00:01:42,840 --> 00:01:49,290 and different sources of alarm's to the other Schelling group that an instance is not responding well 17 00:01:49,680 --> 00:01:50,300 good. 18 00:01:50,310 --> 00:01:55,710 Now this also ties into the fact that they will be not just going to have to work very closely in harmony 19 00:01:55,740 --> 00:01:56,220 together. 20 00:01:56,220 --> 00:02:03,090 Remember when we said that any instance added under the other Skilling group will be registered with 21 00:02:03,090 --> 00:02:09,930 they will be any new instance launched will be registered with theyll be any instance terminated it 22 00:02:09,930 --> 00:02:11,950 will be did we just tell you they will be. 23 00:02:11,970 --> 00:02:16,460 So why not use that youll be a health check also to feed into the health check process. 24 00:02:16,510 --> 00:02:18,820 The just killing together. 25 00:02:18,840 --> 00:02:22,890 And along with the easy to say we are not replacing the easy to set us checks. 26 00:02:22,890 --> 00:02:29,610 Please bear that in mind we are not replacing it with status checks we are providing more sources such 27 00:02:29,610 --> 00:02:38,640 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 28 00:02:38,760 --> 00:02:44,850 detects a problem when they see to instance that is enough for the artist and group to act on that instance 29 00:02:45,380 --> 00:02:48,190 scheduled for terminations start terminating. 30 00:02:48,540 --> 00:02:52,430 Easy to instance and then launching another one health check grace period. 31 00:02:52,620 --> 00:02:58,500 No question if an instance is launched by an artist getting grilled by just getting service itself through 32 00:02:58,500 --> 00:03:05,400 an upskilling group would the instance once it comes in service immediately becomes senator for health 33 00:03:05,400 --> 00:03:06,630 checks. 34 00:03:06,630 --> 00:03:14,460 And the answer is by default no after that instance comes up boots up and it is in service under that 35 00:03:14,460 --> 00:03:21,090 or just getting group that upskilling group by default will wait for five minutes 300 seconds and during 36 00:03:21,090 --> 00:03:27,810 the 300 seconds it's just a grace period I'm giving to instance enough period to load any apps any patches 37 00:03:27,870 --> 00:03:30,030 any software updates anything. 38 00:03:30,390 --> 00:03:35,900 Once it comes up and then it will be judged for whether it is healthy or unhealthy. 39 00:03:36,180 --> 00:03:42,300 So doing the 300 seconds easy to instance is not judged for whether it's healthy or unhealthy by killing 40 00:03:42,390 --> 00:03:49,410 even if complains about the fact that she's unhealthy come from the easy to status checks or from any 41 00:03:49,410 --> 00:03:55,270 other Elby is configured to work with the older sibling group so completely ignored to complete grace 42 00:03:55,270 --> 00:04:00,960 period given to instance to finish everything it is supposed to finish and hopefully within that five 43 00:04:00,960 --> 00:04:07,260 minutes it is going to be all sound and good and then judged to be healthy or unhealthy. 44 00:04:07,320 --> 00:04:14,220 So the grace period is that time alters killing weeds from the time an instance comes into service becomes 45 00:04:14,310 --> 00:04:17,890 in service under the skin before checking its health status. 46 00:04:18,030 --> 00:04:18,840 Can you disable it. 47 00:04:18,840 --> 00:04:22,760 Yes if a value is set to zero that means there is no grace period. 48 00:04:22,770 --> 00:04:28,350 And as soon as it becomes inservice its health will be checked and it will be judged for whether it's 49 00:04:28,350 --> 00:04:35,910 healthy or unhealthy based on the feedback from the 82 status checks and any Albee's if they are defined 50 00:04:35,910 --> 00:04:37,570 under the ceiling. 51 00:04:37,980 --> 00:04:45,240 So until they get this period expired if there is one or if it is left to the default then any unhealthy 52 00:04:45,900 --> 00:04:47,630 reports are ignored. 53 00:04:50,460 --> 00:04:55,800 And after it expires or just getting treated as normal and how can can judge whether it is healthy or 54 00:04:55,800 --> 00:04:56,250 unhealthy. 55 00:04:56,250 --> 00:05:00,850 When will it be defined as unhealthy if they're easy to instance. 56 00:05:00,860 --> 00:05:06,270 The reports that the instance is unhealthy because of what because of an impaired situation because 57 00:05:06,270 --> 00:05:12,480 of a software or hardware problem on the physical host where that easily easy to instance is virtually 58 00:05:12,480 --> 00:05:12,950 located 59 00:05:15,760 --> 00:05:22,090 or it could be if I have been defined and I have configured or tick the box that they will be health 60 00:05:22,090 --> 00:05:28,720 checks are also taken into account that we're just getting group then if any report from out of service 61 00:05:28,720 --> 00:05:36,010 comes from any of the it'll be defined under the Skilling group then also it will be marked as unhealthy. 62 00:05:36,220 --> 00:05:38,230 And then what one source. 63 00:05:38,260 --> 00:05:42,850 Any source of reporting that is to instance as unhealthy is enough for the other Skilling to market 64 00:05:42,850 --> 00:05:44,200 for replacement. 65 00:05:44,350 --> 00:05:45,300 What does that mean. 66 00:05:45,310 --> 00:05:51,770 That means it will do it for domination and terminate the two to instance and then launch a new one 67 00:05:54,590 --> 00:05:56,550 should it get scheduled for termination. 68 00:05:56,570 --> 00:06:01,380 Unhealthy is it to instance and then it will never recover automatically. 69 00:06:01,400 --> 00:06:07,790 So the health will never be recovered once marked for termination by the other group because of a report 70 00:06:07,790 --> 00:06:11,290 from easy to or from an Elby that it's unhealthy. 71 00:06:11,510 --> 00:06:16,510 It will be marked for determination to be scheduled for the nation and it will not recover again. 72 00:06:16,520 --> 00:06:19,110 Is there a way and that is a potential exam question. 73 00:06:19,130 --> 00:06:26,270 Is there a way when it is scheduled for demolition before the auto scaling starts terminating to bring 74 00:06:26,270 --> 00:06:28,070 it back into a healthy status. 75 00:06:28,520 --> 00:06:29,150 Yes. 76 00:06:29,150 --> 00:06:37,030 Manually using the command line and this is the command set instance health to set it back to health. 77 00:06:37,640 --> 00:06:45,380 This is a very short time period between the time it is scheduled to determination and when the termination 78 00:06:45,380 --> 00:06:51,050 starts if the termination has started and you issue this command you will get an error back because 79 00:06:51,050 --> 00:06:53,490 the instance is terminating. 80 00:06:53,940 --> 00:06:55,840 So scheduled for demolition that means. 81 00:06:55,860 --> 00:06:56,370 OK. 82 00:06:56,490 --> 00:07:00,600 Now after these few seconds you will be terminated. 83 00:07:00,860 --> 00:07:08,470 During that period of time then you can place the set are just getting said instance health you can 84 00:07:08,470 --> 00:07:13,460 ensure that command the command line interface and not from not from the company. 85 00:07:13,540 --> 00:07:18,060 And if it starts to do anything for instance you will get an error if you try to apply this command. 86 00:07:18,220 --> 00:07:24,250 So if you apply this command quickly enough after it was scheduled for demolition it you will put it 87 00:07:24,250 --> 00:07:30,340 back into a healthy status when when you do that when it was decided that it was unhealthy because you 88 00:07:30,340 --> 00:07:35,120 were troubleshooting or doing something restarting the rebooting the easy to install. 89 00:07:35,350 --> 00:07:38,530 And you know there is something there is nothing wrong with that is it for instance. 90 00:07:38,530 --> 00:07:42,670 So in that situation you want to put it back as healthy because you're done with what you were doing 91 00:07:42,850 --> 00:07:45,020 and you don't want it to be terminated. 92 00:07:45,130 --> 00:07:50,430 If you are late and you didn't notice that then it will be terminated and your instance will be launched. 93 00:07:50,440 --> 00:07:54,120 Now if I want to avoid such a situation what do I do. 94 00:07:54,160 --> 00:07:58,870 Remember when we talked about the Stand by stand by what you can always put an instance into it but 95 00:07:58,870 --> 00:08:02,750 sent by Muite troubleshoot and install software and do whatever you want. 96 00:08:02,830 --> 00:08:09,100 Reconfigure it and then put it back through pending and it will be health checked and back into inservice 97 00:08:11,630 --> 00:08:15,070 one very important and again exam question. 98 00:08:15,560 --> 00:08:21,080 Remember when we talked about the easy rebalancing we said first of all just killing will and or launch 99 00:08:21,330 --> 00:08:22,550 two instances. 100 00:08:22,680 --> 00:08:25,620 I believe it is one that had let's say two instances. 101 00:08:25,630 --> 00:08:32,420 So it will increase the fleet and then terminate in the LTVs on that had more instances. 102 00:08:32,420 --> 00:08:32,710 Right. 103 00:08:32,710 --> 00:08:35,360 So that's how the balancing happens. 104 00:08:35,360 --> 00:08:43,430 So first launch then removed from the existing in different instances detected as unhealthy to exactly 105 00:08:43,430 --> 00:08:44,480 the opposite. 106 00:08:44,480 --> 00:08:48,100 Let me get rid of the unhealthy first and then launch a new one. 107 00:08:48,110 --> 00:08:49,280 And what's the logic behind that. 108 00:08:49,280 --> 00:08:56,270 Think about if it was marked as an unhealthy and it true was unhealthy then what's the point of keeping 109 00:08:56,270 --> 00:08:57,160 it right. 110 00:08:57,320 --> 00:09:00,650 So you have a bad apple in a box of good apples. 111 00:09:00,650 --> 00:09:02,230 Why do you keep this up. 112 00:09:02,330 --> 00:09:05,490 You just get rid of it and hopefully you get a replacement. 113 00:09:05,570 --> 00:09:07,140 And that's exactly what happens here. 114 00:09:07,160 --> 00:09:13,510 So it will first terminate the unhealthy instance and then onto scaling attempt to launch new instances 115 00:09:13,520 --> 00:09:21,280 to replace a new instance to replace the one delaminated or new instances to replace the ones terminated. 116 00:09:21,660 --> 00:09:22,110 OK. 117 00:09:22,280 --> 00:09:29,330 So it makes perfect sense here and also makes perfect sense in that rebalancing to first launch new 118 00:09:29,330 --> 00:09:31,430 ones before terminating the healthy ones. 119 00:09:31,430 --> 00:09:36,800 One additional important thing that you need to remember here is elastic IPs and EBAs volumes that are 120 00:09:36,890 --> 00:09:43,340 on the instant that is being terminated will be attached from the terminated instance and you need to 121 00:09:43,370 --> 00:09:45,920 manually attach them to the new instance. 122 00:09:45,920 --> 00:09:51,730 So this is very important for because it is going to be manually done and we need to remember that as 123 00:09:51,770 --> 00:09:57,150 volumes Plus the IPs will need to be attached to the new instance manually. 124 00:09:57,270 --> 00:09:57,680 OK. 125 00:09:57,710 --> 00:10:02,640 So let's take a quick break and we'll come back to their next lecture with Otis killing. 126 00:10:02,660 --> 00:10:05,480 We're still with upskilling group so don't go anywhere. 127 00:10:05,480 --> 00:10:06,700 I'll see you in the next lecture.