WEBVTT 1 00:00.000 --> 00:03.860 So friends to begin, this particular skill, the very first thing that I want to 2 00:03.860 --> 00:06.400 talk to you about is something known as red. 3 00:06.400 --> 00:10.640 And no, I'm not talking about when a SWAT team happens to raid someone's house. 4 00:10.640 --> 00:15.260 What we're actually talking about here is a redundant array of independent 5 00:15.260 --> 00:16.080 discs. 6 00:16.080 --> 00:20.380 Now the core component of this technology is in that first letter right here, 7 00:20.380 --> 00:21.280 redundant. 8 00:21.280 --> 00:25.520 What we're talking about here is how we can actually implement redundancy. 9 00:26.000 --> 00:29.830 Now, raid in the context that we're talking about, one of the primary 10 00:29.830 --> 00:33.040 advantages is that it gives us fault tolerance. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:29.830 --> 00:33.040 advantages is that it gives us fault tolerance. 11 00:33.040 --> 00:37.040 So maybe you've heard the expression two is one and one is none. 12 00:37.040 --> 00:39.040 What exactly are we referring to here? 13 00:39.040 --> 00:43.170 Well, quite simply, what we would like to have would be at least two copies of 14 00:43.170 --> 00:43.920 our data. 15 00:43.920 --> 00:47.600 And the reason why we say two is one is because we can't treat that as a 16 00:47.600 --> 00:48.080 minimum. 17 00:48.080 --> 00:52.000 Whereas when we say one is none, if you only have one copy of your data, 18 00:52.000 --> 00:55.660 whether right or wrong it is kind of assumed that you have no copies of your 19 00:55.660 --> 00:57.600 data because that is the nature of computing. 20 00:57.600 --> 01:00.640 Things become corrupt. Things get overwritten accidentally. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 20 00:57.600 --> 01:00.640 Things become corrupt. Things get overwritten accidentally. 21 01:00.640 --> 01:05.280 If you only have one copy, well, that is a very fragile state of affairs. 22 01:05.280 --> 01:09.030 Now realistically, do you absolutely have to have multiple copies of all the 23 01:09.030 --> 01:10.320 data in your possession? 24 01:10.320 --> 01:14.670 Well, the reality is not really, but if that data is valuable to you or if that 25 01:14.670 --> 01:16.240 data happens to be sensitive, 26 01:16.240 --> 01:18.480 then this is certainly a strategy that we want to employ. 27 01:18.480 --> 01:23.590 Now very often, what people might do is maybe they go and they have a USB stick 28 01:23.590 --> 01:25.040 and any data they want backed up, 29 01:25.040 --> 01:28.720 they just copy to this removable drive so that if their primary computer 30 01:28.720 --> 01:29.600 happens to break, 31 01:29.600 --> 01:32.480 then they still have access to that data via the USB. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 31 01:29.600 --> 01:32.480 then they still have access to that data via the USB. 32 01:32.480 --> 01:36.640 Similarly, another well-known and well-used strategy is to utilize the cloud. 33 01:36.640 --> 01:39.960 So this could be pictures on your phone that you want to backup and save to 34 01:39.960 --> 01:40.640 your cloud account. 35 01:40.640 --> 01:43.440 Maybe it's some sensitive documents that type of thing. 36 01:43.440 --> 01:46.080 The cloud provides us a solution for fault tolerance. 37 01:46.080 --> 01:49.440 But as you may expect, that is not the only solution that we can use and the 38 01:49.440 --> 01:49.920 one that we're 39 01:49.920 --> 01:52.640 going to be focusing on is this one right here, reds. 40 01:52.640 --> 01:56.820 Now the way red is going to operate is that it's going to have to use multiple 41 01:56.820 --> 01:58.720 discs in conjunction together. 42 01:58.720 --> 02:02.240 Now how many discs do you need? Well, that really depends on the type of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 01:58.720 --> 02:02.240 Now how many discs do you need? Well, that really depends on the type of 43 02:02.240 --> 02:05.350 rate that you want to be implementing. Now straight up, just to say that you 44 02:05.350 --> 02:05.840 can have 45 02:05.840 --> 02:08.720 red controlled via something known as a hardware controller. 46 02:08.720 --> 02:12.320 This tends to offer better performance, but in the case of what we are doing 47 02:12.320 --> 02:12.720 right here, 48 02:12.720 --> 02:17.030 we're going to be implementing RAID in software pretty much by using the Linux 49 02:17.030 --> 02:17.440 kernel. 50 02:17.440 --> 02:20.320 So let me just talk to you very briefly about some of the different RAID 51 02:20.320 --> 02:22.080 implementations that we can use, 52 02:22.080 --> 02:25.680 as well as why we would want to use them before we actually get to implementing 53 02:25.680 --> 02:26.800 the solution via 54 02:26.800 --> 02:30.140 Ansible. So the very first implementation that I want to talk to you about is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 54 02:26.800 --> 02:30.140 Ansible. So the very first implementation that I want to talk to you about is 55 02:30.140 --> 02:32.080 one called RAID 0. 56 02:32.080 --> 02:36.560 This is otherwise known as striping your data. You may hear this term. 57 02:36.560 --> 02:40.880 And the thing about this particular implementation is that it happens to give 58 02:40.880 --> 02:41.440 you 59 02:41.440 --> 02:44.560 zero fault tolerance. So that sounds like a bit of a bummer. 60 02:44.560 --> 02:48.700 Why then would we want to have a solution that is not going to give us any 61 02:48.700 --> 02:49.440 backups? 62 02:49.440 --> 02:53.200 Well, in the case of RAID 0, whilst it does not give us any backups, 63 02:53.200 --> 02:57.360 it does give us a performance boost. Let me show you how this actually operates 64 02:57.360 --> 02:57.520 . 65 02:57.520 --> 03:01.910 Let's say we have one hard disk right here. And over here, we have a second WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 65 02:57.520 --> 03:01.910 Let's say we have one hard disk right here. And over here, we have a second 66 03:01.910 --> 03:02.800 hard disk. 67 03:02.800 --> 03:07.040 Now traditionally, if you just happen to be working with one disk on its own, 68 03:07.040 --> 03:10.640 then as the data is being written to disk piece by piece by piece, 69 03:10.640 --> 03:13.700 then what is happening is that the data is effectively being written sequ 70 03:13.700 --> 03:14.160 entially 71 03:14.160 --> 03:18.810 one by one by one by one. Now imagine we wanted to write that data across two 72 03:18.810 --> 03:19.840 different drives. 73 03:19.840 --> 03:23.710 The cool thing is that what we can actually do is we can have partial pieces of 74 03:23.710 --> 03:24.400 the data 75 03:24.400 --> 03:28.960 be written to two different drives in parallel. So a piece of the data gets 76 03:28.960 --> 03:29.840 written here and at 77 03:29.840 --> 03:33.840 the same time a piece of the data gets written here. Similarly, when we want to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 03:29.840 --> 03:33.840 the same time a piece of the data gets written here. Similarly, when we want to 78 03:33.840 --> 03:34.640 read that particular 79 03:34.640 --> 03:40.310 piece of data, we can connect to both drives at the same time and access that 80 03:40.310 --> 03:41.440 data in parallel. 81 03:41.440 --> 03:45.600 But of course, the big disadvantage is is let's maybe say this particular drive 82 03:45.600 --> 03:46.400 fails 83 03:46.400 --> 03:51.420 and it becomes unusable, then effectively you happen to have lost all the data 84 03:51.420 --> 03:52.240 on both drives 85 03:52.240 --> 03:57.430 because quite simply one device has only got partial data. So if you destroy 86 03:57.430 --> 03:58.400 one, then effectively 87 03:58.400 --> 04:02.090 you're left with this kind of useless drive with half written data. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 87 03:58.400 --> 04:02.090 you're left with this kind of useless drive with half written data. So 88 04:02.090 --> 04:02.960 certainly this is not the 89 04:02.960 --> 04:06.880 type of read that you would use if you wanted to preserve sensitive and very 90 04:06.880 --> 04:07.920 important data. 91 04:07.920 --> 04:12.320 What you could do is maybe use the next implementation. This one is known as 92 04:12.320 --> 04:17.830 RAID 1 and pretty much what this does is this gives us one copy of our data. 93 04:17.830 --> 04:18.640 This is otherwise 94 04:18.640 --> 04:23.870 known by the name of mirroring pretty much we're going to have an exact mirror 95 04:23.870 --> 04:24.880 of the data of one 96 04:24.880 --> 04:29.520 disk. So again, let's say we have one disk right here and a second disk right 97 04:29.520 --> 04:30.640 here as one piece of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 97 04:29.520 --> 04:30.640 here as one piece of 98 04:30.640 --> 04:34.660 data is written onto this particular disk. The exact same data is then written 99 04:34.660 --> 04:35.680 onto this disk 100 04:35.680 --> 04:40.400 and pretty much this process just continues on and on and on. So say for 101 04:40.400 --> 04:41.360 example, you happen to 102 04:41.360 --> 04:44.860 write a very important document and you save that document, it's going to be 103 04:44.860 --> 04:46.160 written to this drive 104 04:46.160 --> 04:51.440 as well as this drive right here. The effect of that therefore is that let's 105 04:51.440 --> 04:52.800 maybe say this drive 106 04:52.800 --> 04:56.510 happens to fail, it becomes completely unusable, then the good news is is that 107 04:56.510 --> 04:57.600 you have an exact 108 04:57.600 --> 05:02.900 copy of all of the data on this disk which is still in play and as such you can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 108 04:57.600 --> 05:02.900 copy of all of the data on this disk which is still in play and as such you can 109 05:02.900 --> 05:03.760 just throw this 110 05:03.760 --> 05:09.360 old drive away by a brand new one and then write a copy of that data onto this 111 05:09.360 --> 05:10.320 drive right here. 112 05:10.320 --> 05:13.740 So again, we have two copies once more. Now, another very popular 113 05:13.740 --> 05:15.680 implementation is one known as 114 05:15.680 --> 05:21.970 RAID 5 and this one actually requires not two disks but at least three disks 115 05:21.970 --> 05:23.040 and pretty much this data 116 05:23.040 --> 05:26.610 is going to be written in a round Robin format. What does that actually mean? 117 05:26.610 --> 05:27.680 So let's maybe say we 118 05:27.680 --> 05:31.810 have our three disks, let's go with disk number one here, here we have disk WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 118 05:27.680 --> 05:31.810 have our three disks, let's go with disk number one here, here we have disk 119 05:31.810 --> 05:33.520 number two and at the 120 05:33.520 --> 05:37.210 very end we have disk number three. So let's say we have a whole bunch of data 121 05:37.210 --> 05:38.560 that we want to write, 122 05:38.560 --> 05:42.980 what we don't want to do is to write the first chunk of data here and then the 123 05:42.980 --> 05:43.840 second one and 124 05:43.840 --> 05:48.080 then the third so on so forth instead like I say we want to implement that 125 05:48.080 --> 05:48.800 round Robin 126 05:48.800 --> 05:52.090 functionality. So pretty much what we would do is we would write the first 127 05:52.090 --> 05:53.360 chunk of data here, 128 05:53.360 --> 05:57.920 then we would move to the next device and write the second piece of data here 129 05:57.920 --> 05:58.960 and then we would 130 05:58.960 --> 06:02.730 write the third piece of data here. This is what I mean with a round Robin WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 130 05:58.960 --> 06:02.730 write the third piece of data here. This is what I mean with a round Robin 131 06:02.730 --> 06:04.080 format. So we're splitting 132 06:04.080 --> 06:08.190 the data up across the three drives. Now the crucial point to note is that the 133 06:08.190 --> 06:09.200 next piece of data 134 06:09.200 --> 06:13.150 written is something going to be known as a parity bit and this really is just 135 06:13.150 --> 06:14.080 a special piece of 136 06:14.080 --> 06:18.270 data that is going to be used for the reconstruction of the full data should 137 06:18.270 --> 06:19.760 one drive happen to fail. 138 06:19.760 --> 06:22.490 You don't have to worry about the specifics of how this is implemented, just 139 06:22.490 --> 06:23.360 understand is that 140 06:23.360 --> 06:28.060 this is what it does. So basically the fourth time we write a parity bit here 141 06:28.060 --> 06:28.880 and then we go and 142 06:28.880 --> 06:32.990 write the fourth piece of data and then the fifth piece of data and then the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 142 06:28.880 --> 06:32.990 write the fourth piece of data and then the fifth piece of data and then the 143 06:32.990 --> 06:34.320 sixth piece of data 144 06:34.320 --> 06:38.290 and then what is going to come next? We're going to write our parity bits right 145 06:38.290 --> 06:39.440 here and again this 146 06:39.440 --> 06:43.390 just keeps repeating. We write the seventh bit here, the eighth bit of data 147 06:43.390 --> 06:44.640 here, the ninth bit of 148 06:44.640 --> 06:48.980 data here and then you guessed it, we're going to write our parity bits and 149 06:48.980 --> 06:50.000 this is just going to 150 06:50.000 --> 06:53.600 keep repeating and repeating. So the advantage of this implementation is that 151 06:53.600 --> 06:54.720 it's going to give us 152 06:54.720 --> 06:58.680 great performance because the data is written across multiple disks and it's 153 06:58.680 --> 06:59.680 still going to give us 154 06:59.680 --> 07:03.690 that fault tolerance. Now the reality is there are many more types of read WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 154 06:59.680 --> 07:03.690 that fault tolerance. Now the reality is there are many more types of read 155 07:03.690 --> 07:04.800 implementation. We can 156 07:04.800 --> 07:08.740 have read 10, read 6, so on and so forth but these are just some of the more 157 07:08.740 --> 07:10.080 well-known implementations 158 07:10.080 --> 07:13.950 that are commonly seen. So now we have a rough idea about the type of read 159 07:13.950 --> 07:15.040 levels that we have 160 07:15.040 --> 07:19.260 as well as the general purpose and functionality of reads. How about we begin 161 07:19.260 --> 07:20.160 implementing read 162 07:20.160 --> 07:22.960 on our devices utilizing Ansible?