1 00:00:01,000 --> 00:00:06,170 Helen will come back with more with more AWOS or descaling fun. 2 00:00:06,220 --> 00:00:07,650 So let's see what we have now. 3 00:00:08,460 --> 00:00:13,920 While troubleshooting a problem in your application so you had an application and you were troubleshooting 4 00:00:13,920 --> 00:00:14,390 a problem. 5 00:00:14,400 --> 00:00:19,830 You have stopped and restarted an instance multiple times to try to fix the problem. 6 00:00:19,830 --> 00:00:22,430 There was one instance where the problem was defined. 7 00:00:22,620 --> 00:00:28,740 And then you started restarting stopping and restarting the instance multiple times after the problem 8 00:00:28,740 --> 00:00:29,340 was fixed. 9 00:00:29,340 --> 00:00:30,250 Good news. 10 00:00:30,440 --> 00:00:36,690 You then nontheist that the associated the associated odors killing group has determined the instance 11 00:00:36,690 --> 00:00:43,470 that you you're troubleshooting restarting stopping as unhealthy and marketed to be replaced. 12 00:00:43,560 --> 00:00:44,500 Oops. 13 00:00:44,550 --> 00:00:47,000 So you were trying to troubleshoot the problem. 14 00:00:47,220 --> 00:00:51,600 You did not know that there is something called Stand by state. 15 00:00:51,600 --> 00:00:56,630 You could have taken the instance out into the done by state troubleshoot whatever you like. 16 00:00:56,670 --> 00:01:02,760 Still it is managed by auto scaling but skinning when not check the health of of the instance. 17 00:01:02,760 --> 00:01:09,530 So that's that's the right procedure to troubleshoot a problem to instance and avoid having auto scanning 18 00:01:09,540 --> 00:01:13,340 considered it considers it as an unhealthy one. 19 00:01:14,300 --> 00:01:16,970 Ok now it is Mark like you didn't know that. 20 00:01:16,980 --> 00:01:23,280 Now you figured that out from the auto scaling dashboard that these two instances marked for termination 21 00:01:24,090 --> 00:01:28,810 you do not want Skilling to terminate at these instance he's healthy there's nothing wrong about it. 22 00:01:28,830 --> 00:01:35,550 And you where the the reason why it was considered by easy to status checks and is it the status checks 23 00:01:35,910 --> 00:01:39,930 then told auto scaling that this instance is unhealthy. 24 00:01:40,200 --> 00:01:46,500 What can you do to ensure the instance is back to healthy state and will not get terminated. 25 00:01:46,540 --> 00:01:51,150 A You cannot take it back to the state once it's marked for placement. 26 00:01:51,570 --> 00:01:57,160 As we know from the auto scaling that this is not quite accurate. 27 00:01:58,640 --> 00:02:03,070 What about the instance the other Skilling will then added back to the healthy state instances. 28 00:02:03,120 --> 00:02:10,580 Wrong because of scaling if any easy to instance is reported by easy to status checks as anything the 29 00:02:10,580 --> 00:02:17,290 status the state of that is it for instance is reported to be anything except for running state. 30 00:02:17,280 --> 00:02:23,080 So if it is pending If it is stopped if it is rebooted if they've terminated all that. 31 00:02:23,090 --> 00:02:25,190 That means Skilling will market for me. 32 00:02:26,770 --> 00:02:32,860 See manually add the instance back into the auto skating group if the oldest killing determined an instance 33 00:02:32,860 --> 00:02:38,230 to be more marketed for termination doesn't mean that it has expelled it from the upskilling group for 34 00:02:38,230 --> 00:02:47,640 you to hit that game market means it is scheduled for termination during a very limited time you can 35 00:02:47,640 --> 00:02:56,120 use the command line interface command auto scaling said instance health to mark the instance as healthy. 36 00:02:56,220 --> 00:02:57,750 And this is the correct answer. 37 00:02:57,750 --> 00:02:59,350 So this is wrong. 38 00:02:59,790 --> 00:03:00,770 This is wrong. 39 00:03:00,990 --> 00:03:03,200 And this is wrong so this is the correct answer. 40 00:03:03,330 --> 00:03:05,830 But it is a very short period of time. 41 00:03:05,940 --> 00:03:13,230 And here since the question did not mention that it started to be terminated because if auto scaling 42 00:03:14,000 --> 00:03:22,890 more except for termination it waits for a very limited timeframe before it starts terminating the instance. 43 00:03:22,950 --> 00:03:29,670 If you were able to issue that command within that limited timeframe then the instance would be set 44 00:03:29,670 --> 00:03:33,450 back to healthy and the market for emulation will go away. 45 00:03:33,780 --> 00:03:41,600 If you did the command after it started to terminate you would receive an error back of that. 46 00:03:41,640 --> 00:03:43,050 And since he's already terminating 47 00:03:45,880 --> 00:03:53,400 Cato is incorrect B is incorrect C is incorrect and D is the correct answer. 48 00:03:53,580 --> 00:03:59,250 And if we know why is incorrect because within a very short period of time it is marked for replacement. 49 00:03:59,250 --> 00:04:05,280 You can't you can bring it back to healthy b is incorrect because once it's labeled for replacement 50 00:04:05,400 --> 00:04:07,100 we'll soon start to terminate. 51 00:04:07,110 --> 00:04:08,660 So rebidding does not help. 52 00:04:09,060 --> 00:04:15,570 Incorrect for C because you can do this you can manually add it because it's not expelled to start with 53 00:04:15,690 --> 00:04:21,300 and the is your correct answer and things to remember once marked for placement the oldest getting service 54 00:04:21,300 --> 00:04:25,950 will shortly after that start to terminate the instance and then replace it with another. 55 00:04:25,950 --> 00:04:31,890 So if it is marked for replacement for termination and then remember that if an instance is defined 56 00:04:31,950 --> 00:04:43,310 as unhealthy auto scaling will first terminate and to launch new instances this is for unhealthy instances 57 00:04:43,460 --> 00:04:46,730 but for rebalancing it was the other way around. 58 00:04:46,960 --> 00:04:55,040 So number one is launch in the instance in the it is on that do not have enough instances and then terminate 59 00:04:56,510 --> 00:04:58,330 from the ones that were available. 60 00:04:58,440 --> 00:05:00,240 It's a completely different approach. 61 00:05:00,620 --> 00:05:07,580 During the very short time when do you can use the said instance health command as we mentioned. 62 00:05:07,730 --> 00:05:12,140 And if there are two Skilling groups started it tell me the instance you would get an error back when 63 00:05:12,140 --> 00:05:13,360 you issue the command 64 00:05:16,790 --> 00:05:23,000 and last advice that when troubleshooting an easy to instance if that is it to a status check reported 65 00:05:23,000 --> 00:05:28,780 the instance as anything the state of the instance as anything except the running state or scaling will 66 00:05:28,790 --> 00:05:32,180 process or just getting process were considered as unhealthy. 67 00:05:32,300 --> 00:05:33,470 And one market for replacement. 68 00:05:33,470 --> 00:05:34,760 What's the solution. 69 00:05:34,760 --> 00:05:42,050 Move the instance into a standby state under the auto scaling group do your troubleshooting and then 70 00:05:42,050 --> 00:05:43,180 put it back through. 71 00:05:43,190 --> 00:05:46,860 It will go through pending auto scanning will do a health check. 72 00:05:47,060 --> 00:05:56,530 And if healthy is going to be again in service under the water skinning group Greg next question an 73 00:05:56,590 --> 00:06:02,650 instance in an auto Skilling group has been reported by easy to status checks to the auto scaling process 74 00:06:02,680 --> 00:06:08,050 as unhealthy or just killing the market for replacement. 75 00:06:08,050 --> 00:06:16,300 Which of the below statement is correct and it is two answers in auto scaling will start shortly after 76 00:06:16,300 --> 00:06:19,960 that to terminate they see to instance we just discussed that in the previous question. 77 00:06:19,960 --> 00:06:20,830 This is correct. 78 00:06:20,830 --> 00:06:25,140 I have two answers and here we said which of the below statements is correct. 79 00:06:25,150 --> 00:06:26,420 We did not mention anything. 80 00:06:26,430 --> 00:06:27,260 There is no not. 81 00:06:27,280 --> 00:06:34,540 So those three magical letters of not that can make that white color black and the black color white 82 00:06:34,540 --> 00:06:41,050 are basically invert the question completely is not here and that's why it is correct. 83 00:06:41,160 --> 00:06:46,450 The oldest killing it has to launch a replacement first then terminate the unhealthy instance. 84 00:06:46,450 --> 00:06:47,530 This is wrong. 85 00:06:47,590 --> 00:06:55,050 This happens during that launching a new one first and then terminating happens you rebalancing sea 86 00:06:55,100 --> 00:06:59,290 otter skin has to be to do a rebalancing first then terminate the instance wrong. 87 00:06:59,290 --> 00:07:04,100 We're not talking about rebalancing situation or talking about unhealthy instances. 88 00:07:04,270 --> 00:07:09,910 The auto scanning will terminate the instance first then launch a new one and that is correct because 89 00:07:09,910 --> 00:07:15,740 there is no point in keeping an unhealthy instance it's not going to carry your load. 90 00:07:15,760 --> 00:07:21,520 It's going to be healthy for your production traffic and that's why it makes more sense to terminate 91 00:07:21,520 --> 00:07:26,110 it and then launch a new one. 92 00:07:26,210 --> 00:07:27,280 So is correct. 93 00:07:27,290 --> 00:07:31,090 B and C are wrong and the. 94 00:07:31,130 --> 00:07:38,470 Is correct and and the are correct answers and for our refresher for rebalancing a new instance is launched 95 00:07:38,470 --> 00:07:45,420 first then the ones causing the imbalance get terminated for unhealthy instances. 96 00:07:45,420 --> 00:07:46,240 The other way around. 97 00:07:46,260 --> 00:07:50,760 All this killing has to terminate the unhealthy first because you don't need them and they are not going 98 00:07:50,760 --> 00:07:59,100 to do you any benefit then launch a new one or new ones based on how many were marked as unhealth next 99 00:07:59,100 --> 00:08:02,060 question you are newly hired too. 100 00:08:02,070 --> 00:08:03,180 You can do it too. 101 00:08:03,190 --> 00:08:10,840 Incorporated as the years as I mean you were tasked to review the AWOS environment and recommend enhancements 102 00:08:10,840 --> 00:08:16,950 so you have an environment set up and now you are the expert and you were given a task to review the 103 00:08:16,950 --> 00:08:22,400 environment and come up with any enhancements as applicable. 104 00:08:22,410 --> 00:08:29,050 One of the resulting recommendations that you had was to merge the three different single easy authors 105 00:08:29,060 --> 00:08:30,360 getting groups into one. 106 00:08:30,420 --> 00:08:38,440 So there were three different authors getting groups if one in one everybody's on is G-2 in another 107 00:08:38,440 --> 00:08:44,840 I believe it is on is G-3 in a third I believe it is on how can this be achieved. 108 00:08:45,300 --> 00:08:50,890 Delete two of the groups and the third will automatically be configured to stretch and cover the other 109 00:08:50,890 --> 00:08:51,310 two. 110 00:08:51,330 --> 00:08:52,820 I mean it is wrong. 111 00:08:54,190 --> 00:08:56,350 This is not how it is getting worse. 112 00:08:56,350 --> 00:09:01,810 It's not automated stretching into area it is on you have to manually define the outer skin in groups 113 00:09:02,260 --> 00:09:09,460 of the group and where it is applicable which I mean it is isn't be used and it has command line interface 114 00:09:09,460 --> 00:09:12,370 command to stitch the three groups into one. 115 00:09:12,490 --> 00:09:17,330 There is no such a thing a command that will stitch all those groups together. 116 00:09:17,440 --> 00:09:24,150 See define one of the three other Skilling groups to cover their availability zones of the other two. 117 00:09:24,150 --> 00:09:28,040 I believe it all just getting groups and then delete the other two. 118 00:09:28,060 --> 00:09:30,030 And that's how it works. 119 00:09:30,260 --> 00:09:35,060 The create a Forth group that covers all three of everything and then delete the original three. 120 00:09:35,080 --> 00:09:40,730 This is wrong because when you merge auto scaling groups you basically pick one of them. 121 00:09:40,750 --> 00:09:42,670 Make sure that it is effective. 122 00:09:42,670 --> 00:09:45,690 Now in the other two I believe it is on. 123 00:09:45,850 --> 00:09:51,490 And then you can delete the old ones but the one that you will choose to be the umbrella across the 124 00:09:51,490 --> 00:09:58,300 different everybody's and must be one of the preexisting single everybody's owns or just getting groups 125 00:09:58,300 --> 00:10:00,320 that you wanted to merge. 126 00:10:00,530 --> 00:10:11,170 Right so the correct answer is see Google pressure to merge existing single everybody's own or just 127 00:10:11,180 --> 00:10:18,270 killing groups one of them must be updated to spend the set of I it is zones of all groups. 128 00:10:18,620 --> 00:10:24,590 Then delete the remaining other skinning groups except the one that you have configured to span or storage 129 00:10:24,590 --> 00:10:27,680 to all of the zones manually. 130 00:10:27,800 --> 00:10:33,700 The final one the one that represents the merge must be one of the original authors killing groups and 131 00:10:33,710 --> 00:10:35,350 not a new one. 132 00:10:35,360 --> 00:10:35,960 All right. 133 00:10:36,060 --> 00:10:42,150 So let's take a quick break and then we'll come back for more on descaling fun. 134 00:10:42,230 --> 00:10:43,230 I'll see you shortly.