WEBVTT 00:00:00.000 --> 00:00:03.840 Welcome back to vSphere 8 in the real world. Let's look at Advanced Storage Features. 00:00:06.400 --> 00:00:11.760 So data in transit encryption. So what we're talking about here, we're talking about vSAN. 00:00:11.760 --> 00:00:17.680 So with vSAN, traditionally we've always been able to encrypt or, you know, for most of the time 00:00:17.680 --> 00:00:22.000 you've had vSAN be able to encrypt the data while it's on the disk. And that's obviously a really 00:00:22.000 --> 00:00:26.080 important feature, something you want to be able to do. You should always encrypt your data when 00:00:26.080 --> 00:00:31.280 it's, you know, sitting on disk. But it's becoming more and more common where these, you know, 00:00:31.280 --> 00:00:36.639 people coming in and getting into our environments are getting more and more advanced tools. And so 00:00:36.639 --> 00:00:43.759 data in transit now is also equally as important to encrypt as data at rest. So we also, you know, 00:00:43.759 --> 00:00:48.799 obviously want to have that capability. The reason why it hasn't always been something that people 00:00:48.799 --> 00:00:53.360 have done as much is because it's very resource intensive and hardware just wasn't really able 00:00:53.360 --> 00:00:59.040 to keep up with that amount of encryption and decryption. And we don't want to encrypt the data 00:00:59.040 --> 00:01:04.000 using the same keys that we use when it's at rest on our disk as it is when it's in transit 00:01:04.000 --> 00:01:10.800 from one host to another, whether it be replication or what have you. So this is something that's a 00:01:10.800 --> 00:01:15.680 somewhat newer feature, being able to encrypt data while it's in transit over our network. 00:01:16.400 --> 00:01:21.839 It's obviously something that's, you know, again, very important. That's why HTTPS has become, 00:01:21.839 --> 00:01:26.400 you know, the default protocol on the internet versus the standard unencrypted HTTP, 00:01:27.279 --> 00:01:32.800 because more and more people are able to see more and more in our networks. Our tools are getting 00:01:32.800 --> 00:01:39.040 better that they use to hack us. And so data, while it's moving between hosts from source to 00:01:39.040 --> 00:01:44.800 target over the network, it's important to have that encrypted as well. So if we want to start 00:01:44.800 --> 00:01:50.720 encrypting data on our vSAN, if we didn't enable it during the configuration when we rolled it out, 00:01:50.720 --> 00:01:56.239 we can go to the configuration tab for the cluster, go to vSAN, go to services, 00:01:56.239 --> 00:02:00.400 go to data in transit, and we're going to edit that. And then we want to enable 00:02:01.360 --> 00:02:06.239 data in transit encryption, right? We can say the rekey interval, how can we want to rekey that, 00:02:07.040 --> 00:02:10.960 change the key. So if something does happen to the key, it gets compromised, 00:02:10.960 --> 00:02:14.639 then they only have it for a shorter period of time. We don't want to use that same key, 00:02:14.639 --> 00:02:18.639 you know, infinitely. Maybe you want to change it every couple of days, every week or something 00:02:18.639 --> 00:02:24.399 like that, and then we can click apply. So now our vSAN data, when it's moving between hosts, 00:02:24.399 --> 00:02:29.919 will be encrypted using AES-256, and we can configure some kind of forwarding secret on there. 00:02:30.880 --> 00:02:37.119 So what else is encrypted besides just data between vSAN replication? Between the host and 00:02:37.119 --> 00:02:43.759 the witness is also encrypted. And what a witness is, with vSphere 8, we're able to have vSAN 00:02:43.759 --> 00:02:48.399 clusters with less than three hosts. Traditionally, we always wanted, you know, have to have at least 00:02:48.399 --> 00:02:55.759 three, preferably four, five, six, seven. We can do it now with two and a witness. So what that 00:02:55.759 --> 00:03:02.000 does, unfortunately, is it makes our clusters less redundant and less recoverable by, you know, 00:03:02.000 --> 00:03:08.479 that very nature. But we can do it, and the witness basically will happen, because we only have two, 00:03:09.039 --> 00:03:13.039 and one goes down, then the other one would have to take over the entire load. 00:03:13.039 --> 00:03:18.240 But what happens if they don't go down, the communication between the two fails for some 00:03:18.240 --> 00:03:22.320 reason. Now they don't know who is the master and who's the one that should keep running, 00:03:23.360 --> 00:03:31.039 who became isolated. So what that means is, a third one can be a witness, and if A and B all 00:03:31.039 --> 00:03:35.759 of a sudden can't talk to each other anymore, then A can try to talk to the witness. The witness 00:03:35.759 --> 00:03:41.440 can say, yep, I see you, but I don't see B. Okay, then that means I'm still up, I'm going to keep 00:03:41.440 --> 00:03:46.880 functioning and doing my job. B says I can't see A, it'll try and talk to the witness. If it can't 00:03:46.880 --> 00:03:52.720 see the witness either, then it can say, oh, I'm the one that's isolated, and so I need to stop 00:03:52.720 --> 00:03:58.559 taking changes, I need to fail this over to A. All right? So that's what a witness is basically for. 00:03:59.279 --> 00:04:05.039 So data between them would be also replicated. And then the VDFS, what this is basically for, 00:04:05.119 --> 00:04:13.360 is a virtual distributed file system, and this is used for services like NFS. So with vSphere 8, 00:04:13.360 --> 00:04:21.440 we can create NFS shares, SMB shares, things like that, and use our vSAN storage and not have to 00:04:21.440 --> 00:04:25.839 create a Windows VM and then share that information or a Linux VM and then create an NFS share for 00:04:25.839 --> 00:04:34.959 that. I can create either an SMB share or an NFS share right from my vSAN now, and the 00:04:34.959 --> 00:04:39.920 services used to synchronize that information is also encrypted now. 00:04:42.720 --> 00:04:47.760 So vSAN storage, so we're going to go to our cluster, right, go to the configuration tab, 00:04:47.760 --> 00:04:53.200 services and encryption, we're going to choose edit. Our vSAN services page, we want to go in 00:04:53.200 --> 00:04:59.600 there and enable encryption. We want to give it a KMS key, right, and we can probably have created 00:04:59.600 --> 00:05:04.880 that in advance before we obviously get to this page. And do you need to remove residual data 00:05:04.880 --> 00:05:10.000 before encrypting? You want to wipe residual data. Residual data, this really means on a particular 00:05:11.600 --> 00:05:15.359 disk group, that data is going to be wiped out. And so that's kind of important to do, 00:05:15.359 --> 00:05:21.119 especially on a flash disk. So with flash disks, what can happen is you don't want there to say, 00:05:21.119 --> 00:05:24.399 okay, we're going to start encrypting data, and there's blocks that didn't get wiped out. 00:05:25.279 --> 00:05:33.600 Remember flash, actually, let's say you have a 512-gig flash disk. It's actually larger than 00:05:33.600 --> 00:05:39.119 that, right, because pages on those flash disks can go bad. And so there's going to be a lot more 00:05:39.119 --> 00:05:47.200 pages on there than just that 512 gigs. And the system is going to read and write randomly to 00:05:47.200 --> 00:05:52.320 them. And so that way, we kind of get a more even wear across those flash pages, so they don't all 00:05:52.320 --> 00:05:56.000 start, you know, certain ones are failing before other ones. We can kind of get a more consistent 00:05:56.000 --> 00:06:00.160 age on them. But it's only going to let you use the 512 that you paid for and that you bought, 00:06:00.160 --> 00:06:03.920 right. The controller for that is going to make sure that you only use the 512. But they actually 00:06:03.920 --> 00:06:09.519 give you more for wearing. So if there's a bunch of pages out there that have information written 00:06:09.519 --> 00:06:16.079 to them, and then when you encrypt, it's written to other pages, those pages that have residual 00:06:16.079 --> 00:06:20.239 data on there, if something were to be compromised, those aren't encrypted until they get 00:06:20.239 --> 00:06:25.600 rewritten over at some point in the future, right. And also cache pages may not be written over until 00:06:25.600 --> 00:06:30.239 some point in the future. So what you can do is say, I want to get rid of all residual data. I 00:06:30.239 --> 00:06:36.160 want to format all the different pages and rewrite this data clean from scratch, right, in an 00:06:36.160 --> 00:06:43.839 encrypted state. So that's with residual data. And you will want to say yes to that. So if you're 00:06:43.839 --> 00:06:49.440 doing a cluster upgrade, first you need to upgrade your vCenter server. Then you need to 00:06:49.440 --> 00:06:53.920 upgrade your ESXi hosts. Then the last thing you're going to do is you're going to upgrade the vSAN 00:06:53.920 --> 00:06:58.480 disk format. So if you are running an older version of vSAN and you upgrade to a new version, 00:06:58.480 --> 00:07:05.839 like say version 8 of vSphere, then – and by the way, vSAN versions don't match ESXi versions. 00:07:06.399 --> 00:07:11.359 There's actually been quite a few upgrades in vSAN along the way, whereas vSphere went from, 00:07:11.359 --> 00:07:18.799 you know, 6 to 6.5 and to 7 and 7.2 and, you know, and then to 8. vSAN has had a lot more 00:07:18.799 --> 00:07:23.600 upgrades during that time. So it actually is a much higher version. I don't want to start 00:07:23.600 --> 00:07:27.359 quoting exact versions because they keep changing. And by the time this comes out, you might even 00:07:27.359 --> 00:07:32.399 see newer versions. But there are more – the version numbers are higher on vSAN than they are 00:07:32.399 --> 00:07:38.239 on vSphere or ESXi. But when you're upgrading, you can't just upgrade vSAN and not have upgraded 00:07:38.239 --> 00:07:42.000 your host first. Your host needs to support the version of vSAN you're running. You can't upgrade 00:07:42.000 --> 00:07:46.399 your host and not upgrade vSAN. Your vSAN needs to support your host. So vSAN can support, 00:07:47.119 --> 00:07:56.160 you know, ESXi 8 and ESXi 7 and ESXi 6.5. And ESXi 8 can support older versions of vSAN or 00:07:56.160 --> 00:08:01.679 the current version to it, but it can't support versions newer than it is. So vSphere first, 00:08:01.679 --> 00:08:08.720 vCenter, then ESXi, then your vSAN. Okay? So some hardware needs verified that the vSAN supports 00:08:08.720 --> 00:08:13.200 the hardware you have. Make sure all your hardware is on the HCL, your controllers, 00:08:13.200 --> 00:08:18.799 your disks, things like that. Make sure you have the latest vSAN version available because 00:08:18.799 --> 00:08:23.119 it will if you have the most current version of vSXI, you know, vCenter available, vSphere. 00:08:23.679 --> 00:08:30.399 Enough disk space. So disk space is important. If you have really large disk groups, like maybe 00:08:30.640 --> 00:08:37.440 a small number of large disk groups, you might find you don't have enough space to upgrade vSAN. 00:08:37.440 --> 00:08:42.960 And that's one of the reasons why it's a good idea to go with a larger number of small disk 00:08:42.960 --> 00:08:49.520 groups. So when we have our disks, maybe I have in my host, I have, I've mentioned this before in 00:08:49.520 --> 00:08:55.520 another lesson, 16 drives. I don't want to create a disk group of 16 drives or two disk groups of 00:08:55.520 --> 00:09:01.919 eight drives. You might want to create four disk groups of four drives, and then we can replicate 00:09:01.919 --> 00:09:07.919 those. Right? So this will allow us to, when we go to upgrade vSAN, I need to have enough space, 00:09:08.719 --> 00:09:15.359 free space across my host to support the failure of one disk group. Because what's going to happen 00:09:15.359 --> 00:09:20.080 is it's going to take down a disk group, wipe it out, upgrade it, then do the next, 00:09:20.080 --> 00:09:25.599 and then do the next, and do the next, and do the next. If I don't have enough room on my vSAN 00:09:25.599 --> 00:09:31.200 to copy the data off of one of the disk groups, then I won't have enough room to update a disk 00:09:31.200 --> 00:09:36.559 group. And therefore, I can't upgrade any of my vSAN. So we need enough space. You want enough 00:09:36.559 --> 00:09:42.640 space equal to one disk group. And your disk groups are hopefully all the same size across 00:09:42.640 --> 00:09:51.200 all your vSAN silos. Disk format, you know, capacity and reduced redundancy. So when you 00:09:51.200 --> 00:09:55.520 go to do your upgrades, the capacity of your vSAN during that time is going to go down because you 00:09:55.520 --> 00:09:59.679 lost disk groups. And the redundancy is going to go down because you've lost disk groups. Let's be 00:09:59.679 --> 00:10:04.000 aware of that. So hopefully you didn't do like an N plus one. Hopefully you've done like an N plus 00:10:04.000 --> 00:10:09.760 two or even an N plus three. So if you did N plus one and you lose one, there's not redundancy 00:10:09.760 --> 00:10:15.359 there, right? If I did an N plus two and I've lost one, then I have a redundancy of one. 00:10:15.359 --> 00:10:21.440 And if your corporate policy, your corporate strategy is that your failover needs to be an 00:10:21.440 --> 00:10:26.960 N plus two, your vSAN should be an N plus three, right? So if your overall compute and everything 00:10:26.960 --> 00:10:32.479 else, you know, policy is an N plus two, your vSAN, you probably want to be N plus three 00:10:32.479 --> 00:10:37.039 because you're going to be frequently, you know, patching your host, upgrading your host, 00:10:37.039 --> 00:10:43.119 things like that. And during that time, you'll only be at an N plus two. So even during patching 00:10:43.119 --> 00:10:47.200 and upgrading and all that, when you're doing all that, you still are in compliance with your 00:10:47.200 --> 00:10:52.159 corporate policy of being N plus two if you do an N plus three. So that's just something to keep in 00:10:52.159 --> 00:10:58.559 mind because that is normal scheduled maintenance. It's not like a failure. So if you're doing your 00:10:58.559 --> 00:11:01.520 regular scheduled maintenance, you should still be in compliance with your corporate 00:11:01.599 --> 00:11:08.880 policy as far as like fault tolerance and failure tolerances, okay? You'll put a vSAN 00:11:08.880 --> 00:11:14.000 host in the maintenance mode when you're doing these upgrades and you want all your VMs backed 00:11:14.000 --> 00:11:18.799 up. So hopefully you have a backup, you know, schedule in place running something like Veeam, 00:11:18.799 --> 00:11:23.440 for example, and you just want to make sure that all your VMs are backed up, all your backups have 00:11:23.440 --> 00:11:27.520 been successful so you have, you know, you're at your retention policy there. 00:11:27.760 --> 00:11:32.880 Storage hardware acceleration. So storage hardware acceleration is a way of using APIs 00:11:32.880 --> 00:11:40.640 so you can offload certain paths to the SAM. If you're using vVols, then you're always offloading 00:11:40.640 --> 00:11:46.640 these paths to the SAM. But if you're running VMFS data stores, then you could be doing a lot 00:11:46.640 --> 00:11:50.880 of the work with the host communicating with the SAM to say, you know, processing this work. 00:11:51.039 --> 00:11:57.359 If you're using storage APIs, what we can do is we can offload tasks to the SAM from the host. 00:11:57.359 --> 00:12:04.159 So if I want to create a new thick provisioned virtual disk, I could tell the SAM, create me a 00:12:04.159 --> 00:12:09.200 eager zero thick provisioned virtual disk that's 500 gigs. And the host has to send that API 00:12:09.200 --> 00:12:14.960 command and it's done. The SAM takes over and says, okay, yep, got it, that path is complete 00:12:15.119 --> 00:12:19.919 and it does the work. If you want to copy a disk, if you want to reclaim space from a virtual disk 00:12:19.919 --> 00:12:25.119 that's been zeroed, you can either have the host do all that work itself manually and it takes a 00:12:25.119 --> 00:12:31.039 lot of CPU, a lot of memory, a lot of network bandwidth, or if you have APIs available to you, 00:12:31.039 --> 00:12:37.039 you can offload that work. So all of that stuff is just a way of offloading paths 00:12:37.039 --> 00:12:43.039 from the host to the storage. It's supported on the VMs, but it's not supported on the VMs. 00:12:43.760 --> 00:12:52.479 It's supported on block storage device, meaning block local disk, iSCSI, fiber channel, NAS 00:12:52.479 --> 00:13:00.320 devices. Migrating VMs can be offloaded. Cloning VMs can be offloaded. Cloning, 00:13:00.320 --> 00:13:07.359 creating from templates can be offloaded. Locking VMFS clusters. So if you need to, for example, 00:13:07.359 --> 00:13:13.760 grow a file or if you grow a file, it will now lock the file and not the entire data store. If 00:13:13.760 --> 00:13:18.479 you want to grow a data store, it's going to put a lock on that data store. You can offload those 00:13:18.479 --> 00:13:24.000 kinds of tasks to the SAM using the APIs. Provisioning virtual disks, you know, thick 00:13:24.000 --> 00:13:30.320 formatted, eager zeroed. If you're doing thick provision but lazy zeroed, then it's not as big 00:13:30.320 --> 00:13:36.239 a job, but it still is creating a large file, but it's less work if you're not zeroing out the 00:13:36.239 --> 00:13:41.840 blocks first. Fault tolerance, if you have running fault tolerance solutions, again, you can offload 00:13:41.840 --> 00:13:46.799 a lot of this type of stuff like replication and things like that to the SAM. Vendor independent. 00:13:46.799 --> 00:13:50.960 So different vendors may or may not support all these requirements. You need to check with your 00:13:50.960 --> 00:13:57.919 vendor. Does your vendor support all the VAI APIs or does it only support certain ones, right? So 00:13:57.919 --> 00:14:03.359 you need to know what APIs that your storage vendor is fully compliant with or only partially 00:14:03.359 --> 00:14:09.440 or not compatible with at all. Most storage vendors pride themselves on, you know, being 00:14:09.440 --> 00:14:13.760 VMware compatible and things like that. If you're dealing with a lower end, like maybe a small 00:14:13.760 --> 00:14:18.640 business, medium-sized business storage array, maybe they didn't have the dollars to invest or maybe 00:14:18.640 --> 00:14:23.919 it wasn't profitable for them to invest to develop all the APIs. And creating the APIs is not the only 00:14:23.919 --> 00:14:30.320 piece of it. It's also getting it certified by VMware as being, you know, fully compatible and 00:14:30.320 --> 00:14:36.239 all the APIs are compatible and things like that. And that is also definitely a cost that they need 00:14:36.239 --> 00:14:40.640 to consider. So just check with your vendor before you make a purchase and make sure that's compatible. 00:14:42.719 --> 00:14:47.280 So thick and thin provisioned. So a thick provisioned virtual disk, 00:14:47.840 --> 00:14:54.880 VMDK, is basically meaning that if I create a VMDK virtual disk for a virtual machine, 00:14:54.880 --> 00:15:00.640 and let's say I'm going to make it 500 gigs. 500 gigs is allocated when I create that. It's 00:15:00.640 --> 00:15:06.559 got zero data. When I first allocate it, it's zero, you know, bytes in size other than just 00:15:06.559 --> 00:15:12.400 the file that is used to hold it on the disk, you know, the target. But if it's thick provisioned, 00:15:12.400 --> 00:15:19.119 it actually takes up all 500 gigs on that storage. If it's thin provisioned, then it's just an empty 00:15:19.119 --> 00:15:25.039 file sitting there. And it is, you know, a couple bits on there plus the descriptor file that is, 00:15:25.039 --> 00:15:29.119 you know, identifies, you know, all the geometry and things like that, the virtual disk for the VM 00:15:29.119 --> 00:15:37.679 to see. But thin provision grows over time. And so you can easily over allocate. Whereas thick 00:15:37.679 --> 00:15:43.840 provision means you're taking up all that space at once. Now, thick and thin provision also can be 00:15:44.239 --> 00:15:50.719 interpreted by the storage array. You could go in and say, I want to create a thick provision disk 00:15:50.719 --> 00:15:56.799 that is 500 gigs in size. And your storage array could say, okay, done, and then not actually 00:15:57.440 --> 00:16:02.400 create that thick provision disk. It will tell you it's thick provision, and the storage array 00:16:02.400 --> 00:16:05.919 will handle growing and things like that. The host doesn't have to worry about any of that 00:16:05.919 --> 00:16:12.880 because the host thinks it's done on the storage array side. It could be thin. Whereas if you have 00:16:12.880 --> 00:16:19.280 a thin provision disk, you could create a small file, and the storage array is going to even, 00:16:19.280 --> 00:16:24.080 you know, make it additionally a small, even smaller file, only allocate what's actually 00:16:24.080 --> 00:16:32.159 needed. So storage, thick and thin is also a storage level. You could create a LUN that is 00:16:32.159 --> 00:16:38.719 thin provisioned and say, you want to initially make it 500 gigs, but present it as being 50 00:16:38.719 --> 00:16:44.400 terabytes. And when the host mounts it, it's like, oh, I got 50 terabytes. And it starts writing 00:16:44.400 --> 00:16:49.119 things to it thinking it's got 50 terabytes, but you only made it, you know, 500 gigs or one 00:16:49.119 --> 00:16:55.520 terabyte or something like that. And it just simply grows and grows and grows. Now, if you are a brave 00:16:55.520 --> 00:17:00.880 SAM admin and you're like, okay, I know they're not going to use more than the two terabytes that 00:17:00.880 --> 00:17:05.760 we actually have available right now in the next year, and next year we have budget to add the 00:17:05.760 --> 00:17:10.880 additional 48 terabytes, and it's already, you know, in place. We already got orders, you know, 00:17:10.880 --> 00:17:15.680 quotes, you know, created and things like that. The budget's already approved. So when I get that 00:17:15.680 --> 00:17:20.079 additional new shelf and the new disk, I'll just go ahead and then increase that LUN size and make 00:17:20.079 --> 00:17:25.040 it available to grow and pick up those disks. You can do that. And that's what sometimes happens, 00:17:25.040 --> 00:17:30.959 is that admins are projecting what they're going to have for budget, what their purchases are going 00:17:30.959 --> 00:17:37.920 to be next quarter and things like that, and they provision now thin based upon what they expect to 00:17:37.920 --> 00:17:45.119 have in the future. So storage arrays do the same kind of thing. To create a thin provisioned 00:17:45.119 --> 00:17:50.160 virtual disk, when you create the VM, you can just go to the, you know, go through the hardware, 00:17:50.160 --> 00:17:54.640 you're going to customize the hardware, create a new disk. You can say if you want what size you 00:17:54.640 --> 00:17:58.560 want it, I want to make it, you know, 500 gigs. And then you can say if you want to make it a 00:17:58.560 --> 00:18:04.560 thick or thin provision, you can say thick eager zero, thick lazy zero, or you can make it thin. 00:18:04.560 --> 00:18:09.040 And then you click finish. Right? So it's really simple. It's just when you create the VM or even 00:18:09.040 --> 00:18:15.760 if you're not creating the VM, if you are adding the virtual disk to the VM. Now let's say you 00:18:15.760 --> 00:18:22.959 chose thick. You thick provisioned the disk and the VM's been created. And now all of a sudden 00:18:22.959 --> 00:18:26.400 you're like, you know what, I need that space back. I actually don't have as much space as I 00:18:26.400 --> 00:18:32.239 thought. I need more VMs than I thought. You can shrink the disk really easy if you have storage 00:18:32.239 --> 00:18:38.560 vMotion. If you have storage vMotion, then you can just simply say move the VM from this data store 00:18:38.560 --> 00:18:43.599 to this data store. And in the process of moving it, you can re-provision it. You can make it 00:18:43.599 --> 00:18:49.040 thick to thin or thin to thick. So you can change house provision. The easiest way is through a 00:18:49.040 --> 00:18:53.760 storage vMotion. There are other ways that are much more difficult. The most common easiest way 00:18:53.760 --> 00:18:59.199 is to storage vMotion from one data store to another and change the provisioning while you're 00:18:59.199 --> 00:19:09.760 doing that. VMKFS tools. So this is just a command line tool that you can use to create and manage 00:19:09.760 --> 00:19:13.439 your data stores. You can go in there, you can create new data stores, you know, format your 00:19:13.439 --> 00:19:18.560 data stores, things like that. Just a command line tool that you can use for, again, provisioning 00:19:18.560 --> 00:19:23.680 data stores. So if you want to script the creation of data stores, you know, VMFS data stores, 00:19:23.680 --> 00:19:30.319 you can do that using the VMKFS tools command. So IO choices. There's a lot of different things 00:19:30.319 --> 00:19:36.479 that can affect your IO performance on your storage array. Replication, for example, can 00:19:36.479 --> 00:19:41.920 affect your storage performance. So replication would mean that writing, you know, data gets 00:19:41.920 --> 00:19:46.319 written to disk, and as it gets written to disk, it's going to be copied to another storage array. 00:19:46.319 --> 00:19:52.160 Maybe we write in, you know, every 15 minutes or once an hour, we replicate whatever is the 00:19:52.160 --> 00:19:57.520 current state of the data from one storage array to another. What that means is that the disk that 00:19:57.520 --> 00:20:03.839 I'm writing my data to, when replication occurs, there's going to be read operations on those disks 00:20:03.839 --> 00:20:07.760 and they're going to be written to another storage array and there's write operations on those disks. 00:20:08.800 --> 00:20:14.079 Read operations are less resource intensive typically, not by a huge amount, but less 00:20:14.079 --> 00:20:18.719 resource intensive than write operations. So the SAN, that's my production SAN, where I'm 00:20:18.719 --> 00:20:24.239 replicating from, doesn't take as big a hit as the storage array I'm writing to, but it still 00:20:24.239 --> 00:20:28.800 definitely impacts performance. It takes up network bandwidth on the storage controllers, 00:20:29.520 --> 00:20:36.400 and there's some CPU overhead in that as well. So replication can affect your IO. So replicating 00:20:36.400 --> 00:20:41.920 less often, even though it might mean a slightly larger replication job, replicating less often 00:20:41.920 --> 00:20:48.160 is less overhead on the storage controllers. Also replicating like maybe like in the evenings 00:20:48.160 --> 00:20:52.400 after hours and things like that could help too, but that might not always be practical. You have 00:20:52.400 --> 00:20:57.199 to have a, you know, you have a restore point objective of one hour. That means you need to 00:20:57.199 --> 00:21:02.959 replicate at least once every hour, right, in order to accomplish that. Encryption, so encryption 00:21:02.959 --> 00:21:08.239 being very important, having encryption on your data at rest on your SAN is obviously a really 00:21:08.319 --> 00:21:16.079 important, you know, security feature to consider. It does add overhead on the storage processors. 00:21:16.079 --> 00:21:20.239 It's going to add more workload on the disk because they're actually writing slightly more 00:21:20.239 --> 00:21:25.520 data to write that encrypted data. So encryption will definitely impact the performance of your 00:21:25.520 --> 00:21:30.319 storage array because also when you read that data back, you have to decrypt it. So the encryption 00:21:30.319 --> 00:21:34.800 and decryption process adds latency. So all those things need to be considered when you're looking 00:21:34.800 --> 00:21:39.920 at your IO performance. Caching is actually something that impacts your storage performance 00:21:39.920 --> 00:21:45.599 in a positive way. We can take spinning disks, and we have spinning disks that are typically slow, 00:21:45.599 --> 00:21:51.199 and we need to make them seem a little faster, and we don't have money to spend to get all new 00:21:51.199 --> 00:21:59.199 flash disks. What I can do is I can put some flash storage in front, a smaller amount of flash 00:21:59.199 --> 00:22:04.400 storage in front, and data gets written to that cache. Then it gets written from the cache when 00:22:04.400 --> 00:22:09.599 it's available to the spinning disk. So the spinning disks are behind. It can just sit on 00:22:09.599 --> 00:22:15.280 the flash drives and live there temporarily until the spinning drives get caught up, and then it 00:22:15.280 --> 00:22:19.520 gets written from that cache to your spinning disk. So that's called tiered storage. You hear 00:22:19.520 --> 00:22:24.319 people about tiered storage. What that usually means is that they have faster disks in front 00:22:24.319 --> 00:22:30.719 and slower disks in back. Some storage arrays will actually even have flash in front and data 00:22:30.719 --> 00:22:35.439 can live there. If it's often accessed, it just lives there. Then it gets written, if it's less 00:22:35.439 --> 00:22:44.160 often accessed, to slower disks, maybe like 15,000 RPM spinning disks. Then I can have even slower 00:22:44.160 --> 00:22:50.959 drives behind those that are even cheaper, and they're maybe huge, massive 30-terabyte drives 00:22:50.959 --> 00:22:55.760 that are really slow, but data that's almost never accessed, I can archive away, can get 00:22:55.760 --> 00:23:01.520 written to those. So having cache in the front and then slower disks and slower disks can actually 00:23:01.520 --> 00:23:06.640 help your performance quite a bit. If you decide to access the data that's on those really slow 00:23:06.640 --> 00:23:11.520 drives in the back, it will be slower, but it wouldn't be too bad because data over there is 00:23:11.520 --> 00:23:16.160 rarely accessed, so those drives aren't doing a lot. The flash drives are accessing data that's 00:23:16.160 --> 00:23:21.439 accessed often, and it's going to be called on a lot, so they need to be really, really fast to get 00:23:21.439 --> 00:23:26.400 that data to you. So these are different things that can all affect your I.O. performance, some in a 00:23:26.400 --> 00:23:34.719 good way, some in a bad way. Storage I.O. control isn't really necessarily a storage consideration 00:23:34.719 --> 00:23:41.439 as far as it's going to make your storage perform faster or worse. It actually is just a way of 00:23:41.439 --> 00:23:48.319 giving I.O. to virtual machines in a fair way. So what happens is if you have VMs that are using a 00:23:48.319 --> 00:23:53.920 lot of I.O. and other VMs that are needing I.O., but they're not as busy, what can happen is the 00:23:53.920 --> 00:23:59.520 real busy VMs can overwhelm the storage and the slower VMs don't get access. Storage I.O. control 00:23:59.520 --> 00:24:06.079 kicks in when latency hits a certain number. Then all of a sudden it'll say, oh, I'm seeing there's 00:24:06.079 --> 00:24:10.319 contention for that storage. Latency has reached a certain point, so there's contention for the 00:24:10.319 --> 00:24:17.839 storage. So storage I.O. control kicks in and it adjusts the HBA's queue depth and can make it so 00:24:17.839 --> 00:24:24.560 that certain VMs that are maybe using a lot of I.O. don't use as much and the VMs that aren't 00:24:24.560 --> 00:24:29.680 getting as much can get more. It makes it more fair. It's not going to take it from the VMs that 00:24:29.680 --> 00:24:34.160 are using a lot and say now you get none unless you give them a lower priority. If you give them 00:24:34.160 --> 00:24:39.680 fewer shares and VMs that are not using as much but have higher shares, all of a sudden they'll 00:24:39.680 --> 00:24:45.439 get a big bump in performance. So the access to the storage is going to be based on shares 00:24:45.439 --> 00:24:50.079 and is controlled by the queue depth, the VM kernel for the HBA that's connected to the storage. 00:24:53.119 --> 00:24:57.839 Let's go ahead and jump over to our demo environment and I'll show you how to set 00:24:57.839 --> 00:25:03.520 up a thick provisioned and a thin provisioned VMDK file. So here we are back in our demo 00:25:03.520 --> 00:25:07.920 environment. I'm just going to go ahead and click and create a new virtual machine. 00:25:08.479 --> 00:25:12.000 I'm going to say create a new virtual machine. I'm going to give it a name. 00:25:19.599 --> 00:25:26.880 There. Choose the host. It's fine. What storage I'm going to put on? Let's just throw it on there. 00:25:26.880 --> 00:25:32.880 It's fine. Compatibility is fine. Guest OS, Windows, and all that's good. 00:25:33.760 --> 00:25:38.160 Now the hardware. For my virtual disk, I could go in there and say, here, 00:25:39.839 --> 00:25:44.160 disk provisioning. This is thick provision lazy zero. This is what we have on here by default. 00:25:44.160 --> 00:25:49.839 So if I say 90 gigs, it's going to create a 90 gig file. On my storage, I will see a 90 gig file 00:25:49.839 --> 00:25:54.959 being used. I could go in there and change that to any number I want, 500 gigs, whatever I want. 00:25:56.079 --> 00:25:59.680 But I don't want it to actually use 500 gigs of space. 00:25:59.680 --> 00:26:04.640 Because not enough capacity for that. My data store is only a couple hundred gigs. 00:26:04.640 --> 00:26:10.079 So what I can do is I can thin provision that. Now I'm going to get a warning because when it's 00:26:10.079 --> 00:26:16.479 thin provisioned, I'm not going to see a 500 gig file. I'm going to see a file that's only a few 00:26:16.479 --> 00:26:25.680 K in size. And the maximum it can grow to is 198 gigabytes, 198.34 gigs right now. If I wanted to 00:26:25.680 --> 00:26:31.760 try and thick provision that, I couldn't. So I'd have to reduce that down back to, say, for example, 00:26:31.760 --> 00:26:38.880 that 90 gigs. Now I need to know if I'm going to thick provision it. Do I want it lazy zeroed 00:26:38.880 --> 00:26:46.160 or eager zeroed? Lazy zeroed means that before the system can write to a block, it has to zero 00:26:46.160 --> 00:26:50.959 that block. And when it's lazy zeroed, it's going to zero out the block right before it's 00:26:50.959 --> 00:26:58.959 So I create the disk. I take up those 90 gigs of space I'm showing here. But I don't zero the blocks. 00:26:58.959 --> 00:27:04.959 When the VM says write to this block for the first time, then that block gets zeroed. But that means 00:27:04.959 --> 00:27:08.959 there's a delay in writing the data I said to write, because first I have to zero the block, 00:27:08.959 --> 00:27:12.959 then I can write the data. If I go to the next block, I've got to zero the block, then I can write the data. 00:27:12.959 --> 00:27:16.959 So I don't want that. I don't want that. I don't want that. I don't want that. I don't want that. 00:27:16.959 --> 00:27:20.959 the data. If I go to the next block, I've got to zero the block, then I can write the data. 00:27:20.959 --> 00:27:26.959 So lazy zeroed is a way of basically reserving the space, but not really helping my performance a lot 00:27:26.959 --> 00:27:32.959 the first time a block gets written to. If I eager zero, then it's going to write that 90 gig file 00:27:32.959 --> 00:27:38.959 and zero all the blocks in advance. So before I present it to the VM to start using, I've zeroed out 00:27:38.959 --> 00:27:44.959 all those blocks. Now when the OS says write to this block for the first time, it can just write to it. 00:27:44.959 --> 00:27:50.959 So for the very best performance, you want thick provisioned, eager zeroed. The worst performance 00:27:50.959 --> 00:27:56.959 will be thin provisioned, because every time we have to grow the file and the file gets to be a certain size 00:27:56.959 --> 00:28:02.959 and now it's full, now all of a sudden data is having to be queued while the file grows, then blocks get 00:28:02.959 --> 00:28:07.959 zeroed, then the data can be written. All right? So thin provision will give you the worst performance, 00:28:07.959 --> 00:28:13.959 but for best performance, thick provision, eager zeroed, and lazy zeroed is the default, because 00:28:13.959 --> 00:28:19.959 it only has a zero in the first time it writes to them, so it's not going to, you know, if you overwrite blocks, 00:28:19.959 --> 00:28:24.959 they don't get zeroed again, just the first time you write to them. So that is how you would create a virtual disk 00:28:24.959 --> 00:28:30.959 and how you can choose if you want to make it thick provisioned or thin provisioned, if you want it lazy zeroed 00:28:30.959 --> 00:28:31.959 or eager zeroed.