WEBVTT 00:00.360 --> 00:05.890 Resiliency is the ability of something to withstand a negative impact. 00:06.090 --> 00:11.230 And what I want to talk about this episode in particular is system resiliency. 00:11.280 --> 00:17.880 So what can we do to make individual systems resilient to whatever naughtiness is that take place out 00:17.880 --> 00:18.580 there. 00:18.600 --> 00:22.200 Now the first thing I want to stress more than anything else what do people think about resiliency on 00:22.200 --> 00:25.920 a system they tend to say the word backups now backups are important. 00:26.100 --> 00:32.220 And I would not argue that they aren't a part of what resiliency means but it's a lot more than just 00:32.220 --> 00:35.940 backup so there's going to be some turns you're going to see and security plus and I want to make sure 00:35.940 --> 00:37.110 we've got these covered. 00:37.380 --> 00:44.640 So what I want to do to get started is let's imagine what we want to do is come up with ways to create 00:44.640 --> 00:48.450 resiliency so one of the things we can do is scalability. 00:48.750 --> 00:55.200 No you don't just make the machine bigger what you can do is that let's say for example that that machine 00:55.230 --> 01:01.470 is a server and that server is serving up some new Mike Myers widget and all of a sudden lots of people 01:01.470 --> 01:02.660 want to attack that server. 01:02.670 --> 01:03.960 They want to get to that server. 01:03.990 --> 01:05.490 They just want to order widgets. 01:05.640 --> 01:10.920 Scalability simply means we can add more servers we can just keep piling them up until we have enough 01:10.920 --> 01:15.080 servers to take care of the demand of whatever might be taking place. 01:15.300 --> 01:19.470 Now let's go back to our one little machine one more time because the next term I want to talk about 01:19.470 --> 01:22.380 is elasticity elasticity. 01:22.410 --> 01:28.380 Let's go with that same analogy of web service except these web servers are selling tickets to a really 01:28.380 --> 01:30.210 really popular musical group. 01:30.210 --> 01:31.690 I'm not going to name any because I'm old. 01:31.950 --> 01:37.590 So what's going to happen here is that when a show comes up we're going to have to scale up and all 01:37.590 --> 01:41.880 of a sudden here come lots of new servers they're ready to take care of it. 01:41.940 --> 01:47.790 But plasticity is different than scalability in that alas history also means that after the sale we 01:47.790 --> 01:54.200 can drop down to as little as another single server again because we just don't have that many orders. 01:55.020 --> 02:00.930 The important thing about scalability and elasticity is that it sounds almost impossible I mean how 02:00.930 --> 02:01.680 would we do that. 02:01.680 --> 02:07.860 Well the beautiful part is things like infrastructure as a service and software as a service make these 02:07.860 --> 02:16.560 things fairly easy for example Amazon S3 tools allow us to with a simple turn of a knob and some drainage 02:16.560 --> 02:22.590 on my credit card to be able to quickly populate new servers that are absolutely identical to my virtual 02:22.710 --> 02:25.590 server that I'm already hosting on that service. 02:25.620 --> 02:28.780 So that place it works really really well. 02:28.850 --> 02:33.990 Now similar to this is something that is called redundancy. 02:33.990 --> 02:39.400 Now if you've been watching other episodes you know that redundancy just means more than one of the 02:39.570 --> 02:41.170 exact same thing. 02:41.190 --> 02:43.370 So redundancy is very very important. 02:43.370 --> 02:48.630 So if I've got some low it's making a little bit simpler in this case let's say I've got a domain controller 02:48.630 --> 02:49.790 here in my office. 02:49.950 --> 02:52.330 If that domain controller goes out I'm in trouble. 02:52.380 --> 02:57.960 So what we can do is add a second domain controller or even a third if we wanted to and then that way 02:57.960 --> 03:03.360 if any one of those go out we have a redundant system ready to go. 03:03.450 --> 03:10.930 Now the only downside to redundancy is that it doesn't define much more than having more than one. 03:10.950 --> 03:17.070 So let's say we have another situation where we have accounts receivable databases and I have a far 03:17.070 --> 03:22.050 flung company that's all over the United States and I will say We're based out of Houston Texas. 03:22.080 --> 03:28.280 So if I just have one server in Houston Texas everybody all over the country. 03:28.290 --> 03:33.600 So people from California and people from New York as well as people from Texas are all trying to get 03:33.600 --> 03:34.790 to that server. 03:34.880 --> 03:36.840 Now I could make more servers. 03:36.840 --> 03:38.400 That's easy enough to do. 03:38.610 --> 03:43.200 But what would might be even better is if I perform a distributive allocation. 03:43.230 --> 03:49.240 Really that's a nice word of saying more than one server be redundant but spread them out so that there 03:49.250 --> 03:55.500 is if I had a bad hurricane here in Houston we would still have good redundancy but we would also have 03:55.500 --> 03:57.030 geographical distance. 03:57.030 --> 04:02.280 So in this case I could put a server in California keep my server in Houston and put another one on 04:02.280 --> 04:06.900 the East Coast and I'd now have really good distributed allocation. 04:08.190 --> 04:11.360 Now these are all really really important things. 04:11.370 --> 04:17.460 But there's one more aspect to system resiliency that I want to talk about and that is the very interesting 04:17.460 --> 04:19.350 topic of non-persistent 04:22.430 --> 04:26.310 non-persistent simply means that it isn't persistent. 04:26.540 --> 04:34.070 And when I say persistent I mean permanent within the I.T. world many configurations and set ups once 04:34.070 --> 04:40.640 established don't really have a way for you to take them away other than wiping things clean reinstalling 04:40.730 --> 04:43.450 or if we're lucky returning from a backup. 04:43.610 --> 04:50.030 So if we could avoid these more aggressive steps and create non-persistent within our systems it gives 04:50.030 --> 04:51.620 us great resiliency. 04:51.620 --> 04:54.470 Now there's a gazillion ways to do non-persistent. 04:54.650 --> 04:56.540 The exam talks about just a few of them. 04:56.540 --> 04:58.720 So let's go through those very very quickly. 04:59.000 --> 05:05.720 The first one is the term snapshot a snapshot simply means to take the current state of something at 05:05.720 --> 05:09.110 a binary level and keep a copy of it. 05:09.110 --> 05:14.450 Now this happens in a lot of different aspects within systems but probably the most common is within 05:14.450 --> 05:15.600 a virtual machine. 05:15.770 --> 05:17.990 Now if you take a look at my VM right here. 05:18.200 --> 05:20.640 So I've got this VM it's Ubuntu and it's up and running. 05:20.630 --> 05:22.430 I've got a terminal open. 05:22.580 --> 05:25.580 I've got certain pieces of software installed on here. 05:25.580 --> 05:31.880 I've got this configured the way I want and I want to keep a copy of this just like it is. 05:31.880 --> 05:37.690 So what I can do here is I go over to settings and I can take a snapshot. 05:37.790 --> 05:38.980 So I give it some name 05:45.230 --> 05:47.070 Mike's perfect setup. 05:47.090 --> 05:48.230 This is actually a snapshot. 05:48.230 --> 05:49.710 I do a lot with DMD's. 05:49.940 --> 05:55.620 Once I've got a new VM configured just the way I want it I'll make a snapshot of it and I'll put it 05:55.620 --> 05:58.000 here just fine. 05:58.110 --> 05:59.800 Now what I'm going to do is just hit OK. 06:01.000 --> 06:07.480 And what I've done here is I'm saving a copy of this system exactly as it is now. 06:07.600 --> 06:08.950 Notice the system still running. 06:08.950 --> 06:15.310 The snapshot is a second copy and I can go ahead and install software do whatever I want to do if anything 06:15.310 --> 06:17.100 happens from this point forward. 06:17.200 --> 06:20.260 I can just fall back to that original snapshot. 06:20.530 --> 06:23.240 So I'm going to just close this ugly way. 06:26.430 --> 06:32.260 And when I go back into here this is Mike's perfect setup. 06:32.370 --> 06:36.290 If you take a look here it's under machine tools under snapshots. 06:36.480 --> 06:41.020 I can just go here right now and I can fire this snapshot backup. 06:41.070 --> 06:44.970 I can say fire up the VM but don't use what I have. 06:44.970 --> 06:46.790 Revert to a snapshot. 06:46.860 --> 06:51.930 So snapshots are incredibly powerful and expensive within the world of CMS. 06:52.020 --> 06:55.140 They're pretty standard equipment now. 06:55.200 --> 06:59.490 Non-persistent isn't limited to simply things like snapshots. 06:59.490 --> 07:07.590 Another great example is if I got something in a known state and I'd like to get back to that now you 07:07.590 --> 07:09.570 would think Well Mike isn't that a snapshot. 07:09.660 --> 07:13.170 A snapshot tends to talk about an entire machine. 07:13.380 --> 07:17.810 What we're talking about in this particular case is one small aspect of a machine. 07:17.820 --> 07:23.430 So a great example of that would be here on my system right here I've got Windows Update. 07:23.460 --> 07:28.620 Now Microsoft does a pretty good job with updates but old codgers like me can tell you stories about 07:28.620 --> 07:32.790 five or six Microsoft updates that came out over the years that we ended up going. 07:32.820 --> 07:37.300 Oh please take this update off so we can get back to a known working state. 07:37.410 --> 07:39.540 And Windows has always had this. 07:39.570 --> 07:40.840 I'm using Windows 10 here. 07:40.980 --> 07:47.530 But if you take a look I can click under View installed update history and I can actually go in and 07:47.620 --> 07:51.310 uninstall any particular updates I might have installed. 07:51.310 --> 07:57.400 So it's a very great way to simply be able to go back to a known state to do whatever you need to do 07:57.670 --> 08:02.270 now in no way is this limited to just Windows operating systems and other places. 08:02.320 --> 08:09.100 All my Cisco routers when I set up a Cisco router ice store everything in one configuration file and 08:09.160 --> 08:14.410 I keep that configuration file if I make changes on the router I make a copy of the configuration file 08:14.410 --> 08:16.870 so I've got a copy of the old configuration. 08:16.960 --> 08:21.400 That way if I ever have a problem I can just restart the router by using one of the older configuration 08:21.400 --> 08:22.160 files. 08:22.210 --> 08:26.870 So that's another great example of where you can return to a known state. 08:27.110 --> 08:32.430 The last term we see on the security plus is something called rollback. 08:32.470 --> 08:38.320 Now rollback tends to zero in on a very very small part of the system. 08:38.470 --> 08:43.930 So within the Windows world probably the most classic rollback is good old drivers. 08:43.960 --> 08:47.650 Now if you take a look here on Device Manager under display adapters. 08:47.740 --> 08:49.150 So I've got this old Intel. 08:49.150 --> 08:51.260 Don't tease me about my old driver here. 08:51.520 --> 08:54.040 My old graphics card the drivers fine. 08:54.100 --> 09:01.110 So if I take a look under properties all I have to do is look a driver here and you'll see I have an 09:01.110 --> 09:04.050 option called rollback driver. 09:04.190 --> 09:09.050 I'm going to be in scenarios where I've installed a driver and suddenly things aren't going the way 09:09.050 --> 09:10.140 I want them to. 09:10.460 --> 09:12.090 Windows and not just Windows. 09:12.320 --> 09:14.580 Other Operating systems are pretty good about this too. 09:14.720 --> 09:18.730 I can simply go into an individual driver and I can roll it back. 09:18.800 --> 09:23.480 Even some applications will have this where you update a particular application and suddenly you've 09:23.480 --> 09:24.460 got a problem. 09:24.500 --> 09:30.410 Even applications will often have a rollback feature which simply lets you go back to the previous version. 09:31.410 --> 09:38.030 Now there's one more really great example of not persistence and take a look at that. 09:38.100 --> 09:40.310 We need something called a Live-CD. 09:40.380 --> 09:42.080 So let me pull up for you. 09:44.600 --> 09:46.110 Right here what you're looking at. 09:46.130 --> 09:47.640 Let me make this big so we can see it. 09:49.270 --> 09:56.320 What I've done is I started up a virtual machine and I threw in a Ubuntu installation disk. 09:56.320 --> 10:02.440 Well not really a desk I'm using an ISO file but what we can do with installation media for operating 10:02.440 --> 10:09.370 systems is I can throw one of these in and generate what I'm going to call a live-CD what we're talking 10:09.370 --> 10:13.580 about that is Live-CD or does it have to be a CD it can be a thumb drive also. 10:13.810 --> 10:15.690 You have this live boot media. 10:15.730 --> 10:20.980 So what's happening here if you take a look on the screen it says try Ubuntu on one side and install 10:20.980 --> 10:22.080 Ubuntu on the other. 10:22.210 --> 10:25.150 If I install Ubuntu I am creating persistence. 10:25.150 --> 10:29.290 It's going to actually install itself onto the hard drive and it's just going to be that way. 10:29.470 --> 10:33.900 However if I want to I can just run it from the live media. 10:33.940 --> 10:36.590 It will literally boot this operating system. 10:36.610 --> 10:40.990 Ubuntu in this case it'll use my RAM it will use everything but my hard drive. 10:40.990 --> 10:46.600 The only downside is if I shut that system down it's going to disappear but it's a great way if you 10:46.600 --> 10:47.910 just want to try something. 10:48.010 --> 10:53.860 Or if you don't want to put hard drives into a system these are really great ways to provide non-persistent 10:53.860 --> 10:56.290 States for good system resiliency 11:00.660 --> 11:04.410 and.