WEBVTT 00:00:00.000 --> 00:00:06.440 Welcome back to vSphere 8 in the real world. Let's discuss vSAN. 00:00:06.440 --> 00:00:14.800 So vSAN is a way of, again, VMware wants to software define the entire data center and this is their way of software defining storage. 00:00:14.800 --> 00:00:25.639 It also allows us to use local storage in our hosts and treat it as shared storage or a storage area network. 00:00:25.639 --> 00:00:35.080 So basically, we take the storage in our hosts and we're going to break those disks that are up in the host into what they call disk groups. 00:00:35.080 --> 00:00:40.480 Now, if I only have maybe four disks in my host, I'm probably going to have one disk group. 00:00:40.480 --> 00:00:48.200 But if I've got a larger number, if I've got 12 or 16 or 20 or 32, I'll have multiple disk groups. 00:00:48.200 --> 00:00:54.480 So let's just say I had 16 disks in all my hosts, then I'll probably have four disk groups of four disks. 00:00:54.480 --> 00:01:02.119 That's a pretty common breakout. Then I'll do the same thing on my next host, my next host, my next host, right? 00:01:02.119 --> 00:01:12.519 And I want them all to be the same. I don't really want to take a bunch of hosts that are completely different in storage and try to create vSAN with them. 00:01:12.519 --> 00:01:24.760 I don't want this host to have, you know, 16, you know, 6-terabyte drives and this guy over here has 8, you know, 2-terabyte drives and mix all that up. 00:01:24.760 --> 00:01:29.120 Because what will happen is, what happens if this big guy over here fails, right? 00:01:29.120 --> 00:01:33.919 All of a sudden, this one guy failing is the equivalent of three of these guys failing or something like that, right? 00:01:34.160 --> 00:01:46.559 So it's really important that we, kind of when it first came out, the idea was, I'm going to take my existing servers and their existing storage and create vSAN. 00:01:46.559 --> 00:01:53.480 But as vSAN has grown and matured, you really want to target hardware with the intention of vSAN. 00:01:53.480 --> 00:01:57.000 It's not a secondary, oh, let's go ahead and also do this. 00:01:57.000 --> 00:02:01.680 We're going to buy the hardware with the idea that we're going to deploy vSAN. 00:02:01.680 --> 00:02:06.919 We want, you know, controllers on those servers that will support vSAN. 00:02:06.919 --> 00:02:09.919 One, we want them on the VMware, you know, HDL. 00:02:09.919 --> 00:02:17.000 But also, we want, for example, controllers that we can say, this is not a RAID controller, this is simply a pass-through. 00:02:17.000 --> 00:02:21.679 I want my ESXi host to see all 16 drives in that host. 00:02:21.679 --> 00:02:31.360 I don't want to go into my RAID controller card and say, I'm going to take these four and create, you know, a RAID 5 and these four and create a RAID 5. 00:02:31.360 --> 00:02:33.520 Or a RAID 1, or whatever I'm doing. 00:02:33.520 --> 00:02:35.000 I don't want to do that. 00:02:35.000 --> 00:02:39.199 I want to say, no, the RAID controller is not doing RAID. 00:02:39.199 --> 00:02:47.039 It's pass-through and send all the disks to the operating system so that ESXi can see all 16 drives. 00:02:47.039 --> 00:02:50.240 Because that's how the vSAN is going to want to write virtual machines. 00:02:50.240 --> 00:02:54.199 It's going to want to write virtual machines based upon the drive that's in that vSAN. 00:02:54.199 --> 00:02:57.240 And then replicate that to other hosts. 00:02:57.240 --> 00:03:01.600 Meaning, replicate those VMs, you know, whatever data is on those disks to other hosts. 00:03:01.600 --> 00:03:07.679 So, it's not necessarily something you want to piece together with a bunch of odd-sized disks. 00:03:07.679 --> 00:03:15.759 One thing that comes up often in discussion of vSAN is, of course, well, I'm going to have so many spinning disks and I'm going to have a cache disk, right? 00:03:15.759 --> 00:03:17.800 Which means I'm going to have a flash disk. 00:03:17.800 --> 00:03:22.199 That is absolutely true with pretty much all the different versions of vSAN, except vSER 8. 00:03:22.199 --> 00:03:23.600 That's not required. 00:03:23.600 --> 00:03:29.000 I can actually do an all-flash vSAN and not have a cache disk. 00:03:29.000 --> 00:03:37.360 With older versions, like, you know, vSphere 7, even if all my disks were flash, I still needed a caching flash disk also. 00:03:37.360 --> 00:03:38.360 That's not true with 8. 00:03:38.360 --> 00:03:42.559 So, I can actually use that disk as an additional disk for what's called capacity. 00:03:42.559 --> 00:03:48.600 There was capacity drives and then there was cache drives, and the cache drives had to be flash. 00:03:48.600 --> 00:03:56.600 My capacity drives could be flash, they could be spinning disk, they could be, you know, SATA, they could be SAS, they could be, you know, a bunch of different things. 00:03:56.600 --> 00:04:01.600 But that caching disk needed to be a flash disk. 00:04:01.600 --> 00:04:04.600 With vSphere 8, that's not necessary. 00:04:04.600 --> 00:04:12.600 I can do, if I choose to, an all-flash, all-capacity vSAN deployment. 00:04:12.600 --> 00:04:22.600 For most of the conversations we'll have, we'll talk about capacity disks and cache, and we'll discuss, like, you know, if you have spinning disks and cache and things like that. 00:04:22.600 --> 00:04:35.600 Just realize that there is that possibility to do all-flash without the cache, and it's a newer feature in 8, and it's something that you're going to maybe start seeing more and more of. 00:04:35.600 --> 00:04:49.600 But if you're upgrading from an older version of vSAN, then unless you want to completely just wipe it out and start over again, you're going to have, even if you have all-flash, you're going to have a cache disk and you're going to have a capacity disk. 00:04:49.600 --> 00:04:50.600 All right? 00:04:50.600 --> 00:04:59.600 So, tied to hybrid, so hybrid means you have flash, you know, for your memory, you have magnetic drives, you can do all-flash. 00:05:00.600 --> 00:05:15.600 So, managing vSAN, you can create storage policies and you can use your storage policies, like we learned in a previous lesson, to manage vSAN, as well as you would with a more traditional physical storage array that you bought from some enterprise storage vendor. 00:05:20.600 --> 00:05:21.600 So, some important concepts. 00:05:21.600 --> 00:05:23.600 One of the most important ones are disk groups. 00:05:23.600 --> 00:05:36.600 So, as we mentioned, you are going to take the disks that are in your host and you're going to want to break them up into disk groups, because that is how you're going to look at things like, okay, we need to recover, or we need to do some patching. 00:05:36.600 --> 00:05:51.600 We're going to need to be able to recover a disk group, or we're going to need to be able to, if we're going to do upgrading, we need to have enough capacity to take a disk group offline and not overwhelm the rest of the disk groups. 00:05:51.600 --> 00:06:07.600 Well, if I create one large disk group with all 16 of my drives, then if I want to patch that host, I've got to patch that entire host, all the disk groups at one time, which means I've got to move all that data to another host. 00:06:07.600 --> 00:06:18.600 So, if I only have three nodes, in order to take this guy down, the other two have to be able to handle all of its data and still function, not be overloaded and overwhelmed. 00:06:19.600 --> 00:06:32.600 If I were to instead break those 16 drives up into groups of four and four disk groups, and I want to start upgrading and patching, I only have to have enough capacity to upgrade one disk group at a time. 00:06:32.600 --> 00:06:38.600 So, I have to be able to move the data from those four drives to the other host, not all 16 drives. 00:06:38.600 --> 00:06:42.600 So, for upgrading, for patching, things like that, disk groups are important. 00:06:42.600 --> 00:06:44.600 Backup and recovery disk groups are important. 00:06:44.600 --> 00:06:47.600 A lot of disk groups do have a downside. 00:06:47.600 --> 00:06:52.600 The downside being that it does take more resources to manage, and there's going to be more overhead. 00:06:52.600 --> 00:07:02.600 Within a disk group, you're going to have some fault tolerance in there, so you're going to have more overhead as far as what capacity you might have lost. 00:07:02.600 --> 00:07:03.600 So, there is downsides. 00:07:03.600 --> 00:07:09.600 There's a lot of overhead to additional disk groups, but it does make for the most flexible deployment. 00:07:09.600 --> 00:07:13.600 It makes for the most recoverable deployment, the easiest to patch, the easiest to upgrade. 00:07:14.600 --> 00:07:24.600 You don't want to put yourself into a situation where I can't patch, I can't upgrade, I can't do anything because my disk groups are so big that I can't offload them anywhere else in my infrastructure. 00:07:24.600 --> 00:07:25.600 Okay? 00:07:25.600 --> 00:07:31.600 So, disk groups are just literally physical grouping of physical disks, all right, or I should say loss of grouping of physical disks. 00:07:31.600 --> 00:07:39.600 So, a data store, once you have your vSAN configured, then your vSAN is going to present to your ESXi host as that data store. 00:07:39.600 --> 00:07:51.600 And we discussed data stores in previous lessons where I had, you know, a LUN on a SAN presented, and I took that LUN and I created a partition and I formatted it as vMFS, all right? 00:07:51.600 --> 00:07:56.600 In this situation, it's going to present itself as vSAN, all right? 00:07:56.600 --> 00:07:58.600 Consumed capacity. 00:07:58.600 --> 00:08:07.600 So, we're going to talk about, when we discuss vSAN, what is its actually consumable capacity? 00:08:07.600 --> 00:08:15.600 I might say, okay, I've got, just trying to make some easy math here, I've got, you know, 10 drives and they are a terabyte each in this box. 00:08:15.600 --> 00:08:17.600 So, that's, you know, 10 terabytes. 00:08:17.600 --> 00:08:22.600 And I've got three hosts that are exactly the same, so that means I've got 30 terabytes. 00:08:22.600 --> 00:08:25.600 But how much space do I have to use? 00:08:25.600 --> 00:08:28.600 What's my consumable space in this cluster? 00:08:28.600 --> 00:08:32.599 Because, for one thing, I want to have an N plus one. 00:08:32.599 --> 00:08:37.599 So, I won't be able to afford to lose a host and my system keeps going. 00:08:37.599 --> 00:08:43.599 So, that means that whenever data gets written to one of these guys, I'm going to have to have a copy of it someplace else, right? 00:08:43.599 --> 00:08:48.599 So, right there, I've already lost, you know, a third of the space of my storage array if I'm doing an N plus one and I have three hosts. 00:08:48.599 --> 00:08:52.599 Now, if I have eight hosts, I only lost 12.5%, right? 00:08:52.599 --> 00:08:54.599 I lost a much smaller number. 00:08:54.599 --> 00:09:01.599 So, the more hosts you have, then the smaller your overhead is for that N plus one. 00:09:01.599 --> 00:09:04.599 The less you have, the bigger percentage it becomes, obviously. 00:09:04.599 --> 00:09:08.599 There's also going to be some other things you're going to want to take into consideration. 00:09:08.599 --> 00:09:13.599 So, you're going to not only are you going to take into consideration your fault tolerance, 00:09:13.599 --> 00:09:19.599 but you also need to have space available for things like, you know, again, upgrading and patching and moving things around. 00:09:19.599 --> 00:09:25.599 So, there's going to be maintenance involved on the hosts themselves that they kind of need to do. 00:09:25.599 --> 00:09:29.599 They need to have reserved space for that, and we'll discuss that in a little bit. 00:09:29.599 --> 00:09:39.599 So, your consumable space, though, the thing to note, is not going to be necessarily the size of your disk times how many disks times how many hosts 00:09:39.599 --> 00:09:41.599 because there's a lot of overhead involved. 00:09:41.599 --> 00:09:48.599 So, just like if you have just a traditional server and you have 10 disks in there that are a terabyte each, 00:09:48.599 --> 00:09:51.599 10 terabytes, well, if you do a RAID 0, you do. 00:09:51.599 --> 00:09:57.599 But if you do a RAID 1, you're going to have half of that, right? 00:09:57.599 --> 00:10:00.599 If you do a RAID 5, then you'll have 90% of that. 00:10:00.599 --> 00:10:02.599 If you do a RAID 6, you'll have 80% of that. 00:10:02.599 --> 00:10:09.599 So, you have overhead with pretty much any way you do storage if you want any kind of fault tolerance and redundancy in that. 00:10:09.599 --> 00:10:10.599 And vSAN is the same. 00:10:10.599 --> 00:10:14.599 vSAN is just going to consume disks a lot in different ways. 00:10:19.599 --> 00:10:23.599 So, the vSAN is object-based storage, right? 00:10:23.599 --> 00:10:26.599 So, there's, you know, block-based and there's object-based. 00:10:26.599 --> 00:10:27.599 It's object-based storage. 00:10:27.599 --> 00:10:29.599 This means it focuses on files. 00:10:29.599 --> 00:10:35.599 When you are looking at it and you're managing it, that's why you always kind of see it, but it manages things at a file level. 00:10:35.599 --> 00:10:39.599 And so, a file is going to live someplace, whereas just like blocks live in some place. 00:10:39.599 --> 00:10:42.599 So, your VM home namespace. 00:10:42.599 --> 00:10:45.599 So, you're going to be a folder created for every virtual machine. 00:10:45.599 --> 00:10:51.599 And in that virtual machine, you're going to have your VMX file, which is going to be the file that actually defines what the VM is. 00:10:51.599 --> 00:11:01.599 And that VMX file is going to say how many virtual CPUs it has, how much RAM it has, is the virtual CPUs, you know, multi-core, how many cores they have. 00:11:01.599 --> 00:11:03.599 Where are your VMDK files? 00:11:03.599 --> 00:11:05.599 In that same folder are your VMDK files. 00:11:05.599 --> 00:11:11.599 So, the virtual machine has VMDKs, which are those virtual disks where all the data for the VM is stored. 00:11:11.599 --> 00:11:15.599 And the VMX file says this is where the VMDK files are, right? 00:11:15.599 --> 00:11:17.599 This has all the defining features. 00:11:17.599 --> 00:11:19.599 You know, do you have a CD-ROM drive? 00:11:19.599 --> 00:11:21.599 Is that CD-ROM drive connected to an ISO? 00:11:21.599 --> 00:11:22.599 Do you have a sound card? 00:11:22.599 --> 00:11:26.599 What kind of disk controller are you using? 00:11:26.599 --> 00:11:32.599 You know, which one did you say you wanted to virtualize in this host or this virtual machine? 00:11:32.599 --> 00:11:34.599 All that stuff is defined in the VMX. 00:11:34.599 --> 00:11:36.599 Your log files are in that home directory. 00:11:36.599 --> 00:11:38.599 Your VMDK files are in that home directory. 00:11:38.599 --> 00:11:45.599 VMDK, as we just said, that's the file that basically stores all the data that would be in the virtual hard drive. 00:11:45.599 --> 00:11:46.599 And then you have swap. 00:11:46.599 --> 00:11:50.599 And so, when you turn on a VM, it creates swap, right? 00:11:50.599 --> 00:11:57.599 And that swap is going to be created when you turn it on, and it gets deleted when you turn it off. 00:11:57.599 --> 00:12:01.599 Now, I've seen it before where data starts to get really full. 00:12:01.599 --> 00:12:03.599 And you have some bigger VMs. 00:12:03.599 --> 00:12:04.599 They have lots of RAM. 00:12:04.599 --> 00:12:05.599 And you go to power it on. 00:12:05.599 --> 00:12:07.599 It says, I can't power on the VMs. 00:12:07.599 --> 00:12:08.599 I can't create the swap. 00:12:08.599 --> 00:12:12.599 There's not enough space to create your swap, and so it can't power on the VM. 00:12:12.599 --> 00:12:19.599 So, make sure that when you're planning how much space do I need, you're not just saying, okay, well, I need five VMs, 00:12:19.599 --> 00:12:22.599 and they each need a terabyte of space. 00:12:22.599 --> 00:12:24.599 Each one needs five terabytes. 00:12:24.599 --> 00:12:28.599 And so, I only allocate five terabytes. 00:12:28.599 --> 00:12:30.599 First of all, there are log files. 00:12:30.599 --> 00:12:31.599 There is the VMX file. 00:12:31.599 --> 00:12:34.599 There's, you know, all these different things like that. 00:12:34.599 --> 00:12:37.599 And, you know, besides the VMDK. 00:12:37.599 --> 00:12:39.599 So, already you're out of space. 00:12:39.599 --> 00:12:45.599 Then you go to create power on that first VM, and that first VM may not power on because you don't have enough space to create the 00:12:45.599 --> 00:12:47.599 first VM swap file, right? 00:12:47.599 --> 00:12:48.599 So, just be careful of that. 00:12:48.599 --> 00:12:50.599 Make sure you're planning. 00:12:50.599 --> 00:12:57.599 Whatever you're thinking you need for your VMDK files, you want to add, you know, maybe a 30% on top of that number to make 00:12:57.599 --> 00:13:04.599 sure you have enough room for everything. 00:13:04.599 --> 00:13:05.599 Those are requirements. 00:13:05.599 --> 00:13:10.599 So, again, a caching disk, generally speaking, is considered required. 00:13:10.599 --> 00:13:15.599 You can do an all flash, though, with that being said. 00:13:15.599 --> 00:13:20.599 Traditionally, we can look at vSAN, we need a caching disk, and we need capacity disk, right? 00:13:20.599 --> 00:13:25.599 So, for our caching disk, we need a flash disk that will be used just for capacity. 00:13:26.599 --> 00:13:33.599 That is our hybrid kind of deployment where we have a flash disk for our caching disk, and then we have capacity drives. 00:13:33.599 --> 00:13:40.599 And those can be spinning disks, they can be flash disks, they can be, you know, pretty much whatever you have in that box. 00:13:40.599 --> 00:13:44.599 You want it to be, you know, of course, on the HCL and all that kind of stuff, right? 00:13:44.599 --> 00:13:49.599 So, VM data storage or VM data in a hybrid configuration. 00:13:49.599 --> 00:13:55.599 So, basically what happens is you create a VM, it's going to live on a disk, right, on a spinning disk. 00:13:55.599 --> 00:14:01.599 And then you'll be replicated to other systems in that vSAN deployment, all right? 00:14:01.599 --> 00:14:09.599 All flash, you have what's called a disk group, and basically that's going to equal a SSD drive or a flash drive. 00:14:10.599 --> 00:14:16.599 So, for controllers, you're going to get at least one HBA, right? 00:14:16.599 --> 00:14:21.599 Or it can be a RAID controller, but the RAID controller needs to be in pass-through mode. 00:14:21.599 --> 00:14:26.599 So, that way the OS sees the disks themselves and doesn't see RAID groups, okay? 00:14:26.599 --> 00:14:32.599 You don't want to start mixing different controller types and modes and this and that on a host or cross host. 00:14:32.599 --> 00:14:40.599 You want to have the same controller in all the hosts performing the same way, all the disks in all the hosts configured the same way. 00:14:40.599 --> 00:14:46.599 You don't want to start mixing things around because you want to be able to predict what's going to happen in case of a failure. 00:14:46.599 --> 00:14:52.599 You want to predict what's going to happen when you upgrade a disk group, how is the rest of the cluster going to perform. 00:14:52.599 --> 00:15:00.599 If it's really like a bunch of random sizes and random configurations, you can't predict very easily what's going to happen, all right? 00:15:00.599 --> 00:15:10.599 So, for flash, for your host, if you have over 512 gigabytes of RAM in that system, which is pretty common. 00:15:10.599 --> 00:15:15.599 I'm not saying everybody does or all of them do, but it's not an uncommon thing anymore, right? 00:15:15.599 --> 00:15:21.599 And you have external memory that's less than or equal to 4 gigabytes. 00:15:21.599 --> 00:15:23.599 So, that's kind of a weird configuration there. 00:15:23.599 --> 00:15:26.599 Basically, you can do a boot from external USB. 00:15:26.599 --> 00:15:28.599 It's really not suggested anymore. 00:15:28.599 --> 00:15:36.599 VMware really kind of stopped supporting back in, I think it was like 7, update 2 or update 3, 00:15:36.599 --> 00:15:42.599 where they did support booting up from either little SD cards or from USB drives and things like that. 00:15:42.599 --> 00:15:44.599 They have stopped supporting that. 00:15:44.599 --> 00:15:49.599 They do not want you using SD drives or USB drives and things like that. 00:15:49.599 --> 00:15:56.599 The most common way that you see is a point now when you have local storage is that they will have a controller card in there 00:15:56.599 --> 00:16:05.599 that has some little NVMe drives on it, and you'll boot from an NVMe drive. 00:16:05.599 --> 00:16:07.599 You can get a small NVMe. 00:16:07.599 --> 00:16:09.599 Maybe it's 256 gigs. 00:16:09.599 --> 00:16:12.599 I've seen 512 a lot, which is a huge waste. 00:16:12.599 --> 00:16:15.599 And then just basically just mirror those, right, on that controller card. 00:16:15.599 --> 00:16:18.599 That card is basically just there for installing ESXi. 00:16:18.599 --> 00:16:19.599 It's a card. 00:16:19.599 --> 00:16:21.599 It has two NVMe drives. 00:16:21.599 --> 00:16:26.599 They're mirrored to each other, and really all you're doing with that is installing ESXi and booting it, 00:16:26.599 --> 00:16:29.599 which is why I say 512 is a waste. 00:16:29.599 --> 00:16:33.599 That extra space that's not used on those NVMe drives can be used for ISOs. 00:16:33.599 --> 00:16:34.599 It can be used for templates. 00:16:34.599 --> 00:16:36.599 There's a purpose for it. 00:16:36.599 --> 00:16:44.599 But normally you do put that on the SAN somewhere on just really inexpensive low-end storage if you have that in there. 00:16:44.599 --> 00:16:46.599 But you do see it different ways. 00:16:46.599 --> 00:16:53.599 And booting to USB and things like that is not really supported in more VMWare. 00:16:53.599 --> 00:16:55.599 So SAN design. 00:16:55.599 --> 00:16:57.599 So basically we're seeing here we have VMs. 00:16:57.599 --> 00:17:00.599 Those VMs live on vSAN, right? 00:17:00.599 --> 00:17:03.599 So the hosts are, you know, vSAN. 00:17:03.599 --> 00:17:06.599 It's not like you can say vSAN is on this one or vSAN is on that one. 00:17:06.599 --> 00:17:08.599 They both are running vSAN. 00:17:08.599 --> 00:17:10.599 Data is being replicated. 00:17:10.599 --> 00:17:16.599 In a practical environment, you probably have at least three, probably four, five, six, seven, eight hosts or more, 00:17:16.599 --> 00:17:19.599 or it can be considerably more if you're running vSAN. 00:17:19.599 --> 00:17:23.599 And so those VMs could live on multiple of those. 00:17:23.599 --> 00:17:26.599 There will be a copy of it on the host that's running the VM. 00:17:26.599 --> 00:17:27.599 You know one copy is there. 00:17:27.599 --> 00:17:29.599 And the other ones can be spread around, right? 00:17:29.599 --> 00:17:34.599 And they can be spread around based upon how the vSAN algorithm determines they need to be placed. 00:17:34.599 --> 00:17:39.599 Those hosts are connected to hard disk drive magnetic storage probably. 00:17:39.599 --> 00:17:41.599 That's a pretty common way of doing it. 00:17:41.599 --> 00:17:44.599 But it could be all flash as well. 00:17:44.599 --> 00:17:46.599 You have that SSD flash drive for your cache, right? 00:17:46.599 --> 00:17:48.599 That is your disk group, right? 00:17:48.599 --> 00:17:54.599 So every disk group is going to have your flash drive, and it's going to have your capacity drives, right? 00:17:54.599 --> 00:18:00.599 Altogether, those disks and all the different disk groups make up your vSAN. 00:18:00.599 --> 00:18:07.599 So those VMs living on vSAN really kind of are living on all the hosts in that vSAN cluster 00:18:07.599 --> 00:18:12.599 or any of them, and that's like all of them at the same time, but it could be any of them. 00:18:12.599 --> 00:18:14.599 So you can kind of look at it like being all of them. 00:18:14.599 --> 00:18:20.599 If a host that was running a VM or had a VM's redundant disks on it somewhere were to fail, 00:18:20.599 --> 00:18:29.599 vSAN is going to immediately try to make copies of that someplace else so we can keep that redundancy going. 00:18:29.599 --> 00:18:34.599 So keep in mind when you're discussing your design, your vSAN, all right? 00:18:34.599 --> 00:18:37.599 So you're going to decide things on like the size, capacity, 00:18:37.599 --> 00:18:40.599 what kinds of things are we going to take into consideration when we think about capacity. 00:18:40.599 --> 00:18:45.599 Remember, I'm not going to say I think I need 5 terabytes, so I'm going to buy 5 terabytes. 00:18:45.599 --> 00:18:50.599 I think I need 5 terabytes of storage, so I'm going to buy 7, right? 00:18:50.599 --> 00:18:52.599 And that actually would be a tiny, tiny, tiny vSAN, right? 00:18:52.599 --> 00:18:58.599 If I needed, you know, in reality I need 50 terabytes of storage, I'm probably going to buy like 60 or 70 at least. 00:18:58.599 --> 00:19:00.599 And that is what I'm thinking about. 00:19:00.599 --> 00:19:01.599 I'm not going to grow. 00:19:01.599 --> 00:19:08.599 If I'm thinking about future growth and capacity and things like that, then I might be looking at more like 100 or 120 00:19:08.599 --> 00:19:12.599 because I know I need, you know, for the additional files. 00:19:12.599 --> 00:19:13.599 I need it for swap. 00:19:13.599 --> 00:19:19.599 I need, you know, additional capacity for powering on and powering off, you know, VMs 00:19:19.599 --> 00:19:24.599 and then patching hosts, upgrading hosts, all that kind of stuff, right? 00:19:24.599 --> 00:19:26.599 All those things mean additional disk space. 00:19:26.599 --> 00:19:30.599 So when you think about capacity, those are the kinds of things you need to consider, right? 00:19:30.599 --> 00:19:34.599 So you plan your expectations of consumption around the capacity. 00:19:34.599 --> 00:19:40.599 The VMs consume calculation, which, again, that's going to be like it's disk, it's logs, it's swap. 00:19:40.599 --> 00:19:43.599 All of that has to be calculated in. 00:19:43.599 --> 00:19:46.599 Then, of course, whatever the data store, you know, capacity ends up being. 00:19:46.599 --> 00:19:48.599 And then vSAN has its own overhead, right? 00:19:48.599 --> 00:19:54.599 vSAN itself has tasks that it runs, and those tasks create overhead also. 00:19:54.599 --> 00:19:59.599 So that's why they're saying you want to leave at least like 30% of your vSAN empty, you know, 00:19:59.599 --> 00:20:01.599 when you're doing your design. 00:20:01.599 --> 00:20:06.599 You want to consider all the different things you need and then add 30% to that. 00:20:06.599 --> 00:20:09.599 So you expect to get what you need and reserve additional capacity. 00:20:09.599 --> 00:20:14.599 So make space for the VMs, snapshots, swap files, all that kind of stuff. 00:20:14.599 --> 00:20:19.599 And, again, maintenance, hosts going down, on and on and on top of that. 00:20:19.599 --> 00:20:21.599 So what is your tolerance level going to be? 00:20:21.599 --> 00:20:23.599 Are you going to do an N plus one? 00:20:23.599 --> 00:20:28.599 So, you know, I need to have, you know, three hosts. 00:20:28.599 --> 00:20:30.599 So I'm going to do three plus one more, that's four. 00:20:30.599 --> 00:20:32.599 Am I going to do an N plus two, right? 00:20:32.599 --> 00:20:36.599 To run all my workloads and all my capacity, I need, you know, three hosts. 00:20:36.599 --> 00:20:39.599 I'm going to do an N plus two, that needs five hosts. 00:20:39.599 --> 00:20:41.599 So plan for things like that as well. 00:20:41.599 --> 00:20:42.599 Think about your tolerance. 00:20:42.599 --> 00:20:47.599 Think about your VMs' capacity needs and things like that. 00:20:48.599 --> 00:20:53.599 So PCIe or Flash, so for your caching, for your capacity, 00:20:53.599 --> 00:20:56.599 what are you going to use for your caching disk? 00:20:56.599 --> 00:20:59.599 You're going to have to use Flash for caching if you're doing caching. 00:20:59.599 --> 00:21:01.599 For capacity, you could do Flash. 00:21:01.599 --> 00:21:04.599 You could do, you know, you could do a spinning disk. 00:21:04.599 --> 00:21:07.599 You could do, like, magnetic, you know, spinning disks, things like that. 00:21:07.599 --> 00:21:11.599 But you know for your cache, it has to be Flash, right? 00:21:11.599 --> 00:21:16.599 For your RAID disk, it can be SAS or Nearline SAS. 00:21:16.599 --> 00:21:20.599 Your controller design, you might want multiple controllers in your design, 00:21:20.599 --> 00:21:23.599 but if you do have multiple controllers, you want to be in the same model, 00:21:23.599 --> 00:21:25.599 same configuration, all of that. 00:21:25.599 --> 00:21:29.599 And if your controllers, they need to be in pass-through mode, 00:21:29.599 --> 00:21:32.599 not any kind of RAID configuration, okay? 00:21:32.599 --> 00:21:35.599 You're not in a RAID, you know, oh, I'm going to make this more redundant. 00:21:35.599 --> 00:21:38.599 I'm going to create on my RAID controller, 00:21:38.599 --> 00:21:41.599 a RAID 1 or something like that. 00:21:41.599 --> 00:21:42.599 You don't want to do that. 00:21:42.599 --> 00:21:47.599 You want to pass it through, let the vSAN see all the disks, 00:21:47.599 --> 00:21:52.599 and then let it manage the redundancy and things like that. 00:21:52.599 --> 00:21:55.599 So consideration for the host, how much memory. 00:21:55.599 --> 00:21:59.599 You need VM, you know, memory for the VMs themselves, you know, 00:21:59.599 --> 00:22:00.599 for us just to run them. 00:22:00.599 --> 00:22:01.599 You need memory for the host. 00:22:01.599 --> 00:22:04.599 vSAN takes a lot of additional overhead as well, right? 00:22:04.599 --> 00:22:07.599 So you need to take into consideration the vSAN overhead, 00:22:07.599 --> 00:22:08.599 as well as the virtual machine overhead, 00:22:08.599 --> 00:22:12.599 as well as the ESXi host overhead, all those kinds of things, right? 00:22:12.599 --> 00:22:14.599 Host networking. 00:22:14.599 --> 00:22:18.599 So here it says, you know, you've got an adapter, of course, 00:22:18.599 --> 00:22:21.599 isn't that because we're going to be exchanging information on IP. 00:22:21.599 --> 00:22:23.599 One gigabyte minimum. 00:22:23.599 --> 00:22:29.599 Really, in today's day and age, 10 gig for vSAN is kind of your minimum. 00:22:29.599 --> 00:22:33.599 And what I mean by that is you want a dedicated network for your vSAN. 00:22:33.599 --> 00:22:36.599 You want these hosts to be communicating on a dedicated network. 00:22:36.599 --> 00:22:38.599 Can you do it on shared NICs? 00:22:38.599 --> 00:22:44.599 Can you have VMs running on the same NICs that you are, you know, 00:22:44.599 --> 00:22:47.599 replicating and managing vSAN on? 00:22:47.599 --> 00:22:48.599 You can. 00:22:48.599 --> 00:22:49.599 You should not. 00:22:49.599 --> 00:22:51.599 Okay, you absolutely should not. 00:22:51.599 --> 00:22:53.599 You should have dedicated NICs. 00:22:53.599 --> 00:22:56.599 They should be at least 10 gig NICs in reality. 00:22:56.599 --> 00:22:59.599 25 gig NICs are really, really common now. 00:22:59.599 --> 00:23:01.599 It's not that uncommon to see, you know, 00:23:01.599 --> 00:23:06.599 enterprise switches with several 25 gig interfaces, cards and servers, 00:23:06.599 --> 00:23:07.599 25 gig. 00:23:07.599 --> 00:23:12.599 I mean, it's not that uncommon in the enterprise to see, you know, 00:23:12.599 --> 00:23:16.599 40, 50, 100 gig all the time, like in enterprise data centers. 00:23:16.599 --> 00:23:20.599 Recently I've seen some demonstrations from Cisco where they're showing 00:23:20.599 --> 00:23:22.599 their 200 gig interfaces. 00:23:22.599 --> 00:23:27.599 For your vSAN deployments in most situations, you want 10 gig minimum, 00:23:27.599 --> 00:23:29.599 probably at least, you know, 25 gig. 00:23:29.599 --> 00:23:30.599 It's going to depend on your budget. 00:23:30.599 --> 00:23:32.599 Twenty-five gig is more expensive. 00:23:32.599 --> 00:23:34.599 It definitely is a cost difference there, 00:23:34.599 --> 00:23:37.599 but it's not as drastic as it was just, you know, 00:23:37.599 --> 00:23:39.599 three or four years ago even. 00:23:39.599 --> 00:23:42.599 So consider really minimum probably, you know, 00:23:42.599 --> 00:23:47.599 a 10 gig connection between your ESXi host dedicated just for vSAN. 00:23:47.599 --> 00:23:49.599 And you want that to be redundant, too. 00:23:49.599 --> 00:23:50.599 You don't want just one. 00:23:50.599 --> 00:23:51.599 You want at least two. 00:23:51.599 --> 00:23:57.599 So multiple disk groups, there are pros to multiple disk groups, right? 00:23:57.599 --> 00:24:01.599 That is improved performance, you know, better failover capabilities. 00:24:01.599 --> 00:24:03.599 Recovery times are lower. 00:24:03.599 --> 00:24:06.599 Cons is it consumes more memory. 00:24:06.599 --> 00:24:08.599 Controller increase, you know, 00:24:08.599 --> 00:24:12.599 so you may have additional controllers for additional redundancy with your 00:24:12.599 --> 00:24:13.599 disk groups, things like that. 00:24:13.599 --> 00:24:17.599 You need more drive bays because you have more disks. 00:24:17.599 --> 00:24:19.599 If you had fewer disk groups and bigger disks, 00:24:19.599 --> 00:24:21.599 you would need fewer controllers. 00:24:21.599 --> 00:24:23.599 You'd need fewer drive bays, fewer hot swap, you know, 00:24:23.599 --> 00:24:25.599 trays, all that kind of stuff. 00:24:25.599 --> 00:24:31.599 More disk groups probably means smaller, but more disks, right, 00:24:31.599 --> 00:24:35.599 which again means more controllers, more drive bays, bigger physical servers 00:24:35.599 --> 00:24:38.599 to hold all the additional drives, that kind of stuff. 00:24:38.599 --> 00:24:41.599 So what is your primary level of failure to tolerance, 00:24:41.599 --> 00:24:44.599 meaning how much are you willing to say you can handle failing? 00:24:44.599 --> 00:24:49.599 If you're like, I'm fine if I can only handle one device failing, 00:24:49.599 --> 00:24:53.599 then that would mean you have, you know, you're basically an N plus one. 00:24:53.599 --> 00:24:56.599 If you want to say, I want to be able to handle surviving two fail. 00:24:56.599 --> 00:24:59.599 And, again, the more hosts you have, 00:24:59.599 --> 00:25:02.599 the more you probably want to be able to say you can handle failing, right, 00:25:02.599 --> 00:25:04.599 because the more hosts you have, the more devices, 00:25:04.599 --> 00:25:06.599 the more probable you have multiple failures. 00:25:06.599 --> 00:25:10.599 It's not very common that you have two NICs and two different hosts go bad 00:25:10.599 --> 00:25:12.599 at the same time, but things happen, right? 00:25:12.599 --> 00:25:15.599 So you need to evaluate your environment. 00:25:15.599 --> 00:25:17.599 What can you stand? 00:25:17.599 --> 00:25:20.599 What can you handle, all right, for fault tolerance? 00:25:24.599 --> 00:25:26.599 So for networking, you have failover and load balancing. 00:25:26.599 --> 00:25:30.599 So, again, this is going to be VMware ESXi networking, right? 00:25:30.599 --> 00:25:33.599 You're going to have a virtual switch, whether it be a distributed virtual switch 00:25:33.599 --> 00:25:38.599 or a standard virtual switch, and you're going to have physical NICs 00:25:38.599 --> 00:25:41.599 attached to this virtual switch, and you're going to create port groups. 00:25:41.599 --> 00:25:43.599 You're going to create VM kernel ports. 00:25:43.599 --> 00:25:47.599 You're going to need to create a VM kernel port that has vSAN enabled on it 00:25:47.599 --> 00:25:49.599 and with an IP address and all of that. 00:25:49.599 --> 00:25:52.599 So those NICs, hopefully you have multiple NICs. 00:25:52.599 --> 00:25:55.599 How are you going to load balance across those NICs? 00:25:55.599 --> 00:26:00.599 And you have the same algorithms available with vSAN networking that you would 00:26:00.599 --> 00:26:05.599 have on a traditional, you know, port group for virtual machines 00:26:05.599 --> 00:26:08.599 or for any other VM kernel service you're running. 00:26:08.599 --> 00:26:10.599 So you can say a route based on the original virtual port, 00:26:10.599 --> 00:26:13.599 so the virtual port on that virtual switch, you know, 00:26:13.599 --> 00:26:16.599 will determine you'll create an algorithm based upon that route. 00:26:17.599 --> 00:26:23.599 On an IP hash or based on a physical network adapter load, 00:26:23.599 --> 00:26:29.599 that's if you're doing distributed virtual switches, not standard switches, right? 00:26:29.599 --> 00:26:32.599 So after 6.7, unicast traffic is sufficient. 00:26:32.599 --> 00:26:35.599 You don't need to have multicast with vSAN anymore. 00:26:35.599 --> 00:26:36.599 You want to mark the SAN traffic. 00:26:36.599 --> 00:26:42.599 So basically what we really want to do, we want a dedicated segment, right? 00:26:42.599 --> 00:26:47.599 We want vSAN traffic on a dedicated segment, on a dedicated VLAN, 00:26:47.599 --> 00:26:50.599 on dedicated NICs with switch ports that we're not sharing a bunch of 00:26:50.599 --> 00:26:51.599 those services with, right? 00:26:51.599 --> 00:26:54.599 We want all of this to be dedicated for vSAN, all right? 00:26:54.599 --> 00:26:59.599 You don't want to be sharing a bunch of different types of traffic 00:26:59.599 --> 00:27:02.599 and have vSAN competing with other services on those ESXi hosts 00:27:02.599 --> 00:27:08.599 or with virtual machines on those ESXi hosts. 00:27:08.599 --> 00:27:10.599 You place hosts on the same subnet. 00:27:10.599 --> 00:27:13.599 You don't want to be routing your vSAN traffic. 00:27:13.599 --> 00:27:14.599 It's kind of surprising. 00:27:14.599 --> 00:27:16.599 I've been, like, on calls with Cisco. 00:27:16.599 --> 00:27:19.599 I've been on calls with different vendors designing, you know, 00:27:19.599 --> 00:27:20.599 different storage networks. 00:27:20.599 --> 00:27:23.599 Maybe we're, you know, doing a Cisco UCS deployment. 00:27:23.599 --> 00:27:26.599 And I've literally had Cisco, and I swear this is true, 00:27:26.599 --> 00:27:35.599 want to put the storage adapters for our storage array on the core switch 00:27:35.599 --> 00:27:38.599 because it gets it closer to the routing interface. 00:27:38.599 --> 00:27:40.599 And I'm like, who's routing this storage? 00:27:40.599 --> 00:27:42.599 There's no routing happening here at all. 00:27:42.599 --> 00:27:47.599 So you want all your vSAN traffic to be on the same subnet connected, you know, 00:27:47.599 --> 00:27:53.599 to one switch as close to the host as we can get, fast interfaces, no routing. 00:27:53.599 --> 00:27:55.599 It's just all right there. 00:27:55.599 --> 00:27:58.599 That is obviously ideal, right? 00:27:58.599 --> 00:28:00.599 You want dedicated bandwidth. 00:28:00.599 --> 00:28:03.599 Probably, again, you want at least 10 gigabit. 00:28:03.599 --> 00:28:04.599 One is acceptable. 00:28:04.599 --> 00:28:05.599 VMware will accept that. 00:28:06.599 --> 00:28:08.599 You really want at least 10, maybe even more, 00:28:08.599 --> 00:28:12.599 depending on how much you use that storage, right? 00:28:12.599 --> 00:28:14.599 Configure the port group, right? 00:28:14.599 --> 00:28:17.599 Set whatever policies mean, your load balancing policies 00:28:17.599 --> 00:28:19.599 and all that kind of stuff on there. 00:28:19.599 --> 00:28:22.599 Set the VLAN tag for that virtual switch. 00:28:22.599 --> 00:28:25.599 It will be on your physical network. 00:28:25.599 --> 00:28:29.599 And then make sure that on the ESXi host firewall that vSAN traffic is 00:28:29.599 --> 00:28:32.599 allowed through, all right? 00:28:32.599 --> 00:28:34.599 So requirements to create a vSAN. 00:28:34.599 --> 00:28:35.599 So what do you need? 00:28:35.599 --> 00:28:37.599 You need at least three ESXi hosts. 00:28:37.599 --> 00:28:43.599 You can do it with eight, with two, if you have a third witness. 00:28:43.599 --> 00:28:45.599 You need a third device for a witness, all right? 00:28:45.599 --> 00:28:49.599 And that's going to be a virtual machine that you can get from VMware for a witness. 00:28:49.599 --> 00:28:51.599 But, really, you probably want at least three. 00:28:51.599 --> 00:28:54.599 But just so you know, if you have a real small deployment for, like, 00:28:54.599 --> 00:28:57.599 a little branch or something like that, you can do it with two and a witness, right? 00:28:57.599 --> 00:28:59.599 At least eight gigs of RAM in the host. 00:28:59.599 --> 00:29:02.599 Obviously, you're probably going to have a lot more than that. 00:29:02.599 --> 00:29:07.599 You need your disk controller to be in pass-through mode, all right? 00:29:07.599 --> 00:29:10.599 You need a cache disk and capacity disk. 00:29:10.599 --> 00:29:12.599 Now, you need at least one of each. 00:29:12.599 --> 00:29:17.599 Again, you can do it without the flash or the caching disk in version 8, 00:29:17.599 --> 00:29:20.599 but it needs to be a new deployment, and you'll need to check, 00:29:20.599 --> 00:29:22.599 you know, choose the option for that. 00:29:22.599 --> 00:29:26.599 Most deployments are going to have a caching disk 00:29:26.599 --> 00:29:30.599 and capacity drives per disk group, all right? 00:29:30.599 --> 00:29:33.599 A host, of course, needs a network adapter, obviously. 00:29:33.599 --> 00:29:36.599 You need a VMkernel port for vSAN. 00:29:36.599 --> 00:29:38.599 Now, it says you may need a vMkernel network. 00:29:38.599 --> 00:29:43.599 So, what they're talking about there is having a dedicated network for the vMkernel. 00:29:43.599 --> 00:29:45.599 You don't necessarily need that, 00:29:45.599 --> 00:29:51.599 but you will need a vMkernel adapter port, right, configured for vSAN. 00:29:51.599 --> 00:29:58.599 But it doesn't have to be a dedicated VLAN for that, necessarily. 00:29:58.599 --> 00:30:01.599 So, let's go ahead and jump over to our demo environment, 00:30:01.599 --> 00:30:05.599 and I'll walk you through setting up vSAN. 00:30:05.599 --> 00:30:06.599 So, here we are. 00:30:06.599 --> 00:30:10.599 We're back in VMware's hol.vmware.com lab environment. 00:30:10.599 --> 00:30:12.599 So, it's VMware hands-on labs. 00:30:12.599 --> 00:30:14.599 So, it's hol.vmware.com. 00:30:14.599 --> 00:30:18.599 And what we have is we have vCenter. 00:30:18.599 --> 00:30:21.599 We have a data center and a cluster. 00:30:21.599 --> 00:30:25.599 And this cluster happens to have three ESXi hosts in here. 00:30:25.599 --> 00:30:31.599 So, what I want to do to configure vSAN is I want to choose my cluster, 00:30:31.599 --> 00:30:34.599 and I'm going to go to configure. 00:30:34.599 --> 00:30:39.599 I am going to scroll down to vSAN, and I'm going to choose services. 00:30:39.599 --> 00:30:41.599 And because I don't have vSAN configured, 00:30:41.599 --> 00:30:45.599 all I have right now is just that services option. 00:30:45.599 --> 00:30:48.599 And when this comes up, I'll see I have some different options here. 00:30:48.599 --> 00:30:52.599 And in these options, I can do a standard vSAN cluster. 00:30:52.599 --> 00:30:54.599 I can do a two-node cluster. 00:30:54.599 --> 00:30:58.599 And the reason why you see that little VM in the middle there is because that would be a witness. 00:30:58.599 --> 00:31:02.599 We need a third location or third device that would run that witness 00:31:02.599 --> 00:31:04.599 so we would know if vSAN is up and running or not. 00:31:04.599 --> 00:31:06.599 Or we could do a stretch cluster. 00:31:06.599 --> 00:31:07.599 But we're not going to do any of those. 00:31:07.599 --> 00:31:12.599 We're going to just do a standard vSAN cluster. 00:31:12.599 --> 00:31:18.599 And I'm going to say configure. 00:31:18.599 --> 00:31:24.599 And one of the first things it wants to know is do we want to do an ESA vSAN or not. 00:31:24.599 --> 00:31:27.599 And it's telling me I can't do an ESA vSAN. 00:31:27.599 --> 00:31:30.599 And if you wonder, Walt, why can I not do an ESA vSAN? 00:31:30.599 --> 00:31:38.599 If I scroll down, I'll see that my NVMe devices are not on VMware's hardware compatibility list. 00:31:38.599 --> 00:31:43.599 Now, the device itself may be on the hardware compatibility list, and actually probably is, 00:31:43.599 --> 00:31:46.599 but the driver that's currently using is not. 00:31:46.599 --> 00:31:49.599 And there are some third-party drivers loaded, I know, in VMware's lab environment. 00:31:49.599 --> 00:31:55.599 You might think it's kind of odd that VMware's labs have devices, drivers being used that aren't certified by them, 00:31:55.599 --> 00:31:57.599 but that's the case here. 00:31:57.599 --> 00:32:00.599 I'm going to go ahead and say next. 00:32:00.599 --> 00:32:03.599 And now here I can enable services, right? 00:32:03.599 --> 00:32:07.599 I can enable compression, or I can say I want to do deduplication and compression. 00:32:07.599 --> 00:32:09.599 I can also enable encryption. 00:32:09.599 --> 00:32:14.599 I could do data at rest encryption, which means I need to have a key provider configured already, 00:32:14.599 --> 00:32:16.599 or I could do data in transit encryption. 00:32:16.599 --> 00:32:20.599 And if I do data in transit, I can say how often do I want to rekey this. 00:32:20.599 --> 00:32:22.599 By default, it's one day. 00:32:22.599 --> 00:32:30.599 If I were to choose custom, then I would say how many minutes I wanted a key to be good for before I had to rekey. 00:32:30.599 --> 00:32:31.599 Okay. 00:32:31.599 --> 00:32:34.599 But we're not going to do that right now. 00:32:34.599 --> 00:32:41.599 And so I'm just going to leave everything at its defaults, and I'm going to say next. 00:32:41.599 --> 00:32:50.599 Now it's asking what disks I want to use, and it's telling me on three hosts I have one disk each for my caching tier, 00:32:50.599 --> 00:32:55.599 and on my three hosts I have two disks each for my capacity tier. 00:32:55.599 --> 00:33:00.599 And I can expand here and take a look and see what I've got configured. 00:33:00.599 --> 00:33:03.599 Now these are all flash. 00:33:03.599 --> 00:33:08.599 These happen to be all flash. 00:33:08.599 --> 00:33:10.599 But they're still going to my capacity tier, right? 00:33:10.599 --> 00:33:12.599 These above are going to go to my caching tier. 00:33:12.599 --> 00:33:19.599 Now for some reason, if that's not what I wanted them to do, if I wanted one to be one way or the other, I can choose to change it. 00:33:19.599 --> 00:33:21.599 Okay. 00:33:21.599 --> 00:33:23.599 I'm going to leave everything the way it is at the defaults. 00:33:23.599 --> 00:33:25.599 Again, that works. 00:33:25.599 --> 00:33:28.599 I'm going to say next. 00:33:28.599 --> 00:33:34.599 And now it's just telling me, okay, so my fault-tolerant domain, I have one domain that these three hosts are going to live in, 00:33:34.599 --> 00:33:38.599 so this is going to be one fault-tolerant domain. 00:33:38.599 --> 00:33:40.599 And I can review my settings, right? 00:33:40.599 --> 00:33:43.599 I'm not doing any data at rest encryption. 00:33:43.599 --> 00:33:49.599 I'm not going to do anything special to reclaim space, meaning I'm not going to enable compression 00:33:49.599 --> 00:33:51.599 or deduplication or anything like that. 00:33:51.599 --> 00:33:59.599 I'm just going to go ahead and say finish. 00:33:59.599 --> 00:34:03.599 And now this is going to run through creating my vSAN cluster. 00:34:03.599 --> 00:34:09.600 And you can see it kicks off a bunch of different jobs. 00:34:09.600 --> 00:34:13.600 We'll go ahead and let this run through, and we'll just continue as soon as it's done in this configuration. 00:34:13.600 --> 00:34:21.600 This can actually take, you know, five, ten minutes. 00:34:21.600 --> 00:34:22.600 All right. 00:34:22.600 --> 00:34:23.600 It looks like it's done running tasks. 00:34:23.600 --> 00:34:29.600 What you can do, if you scroll through here, you would see that it went through and, you know, went to create vSAN. 00:34:30.600 --> 00:34:34.600 When it created a bunch of disk groups, it added – you know, after it created the vSAN cluster, 00:34:34.600 --> 00:34:38.600 it created the disk groups, and then it added disks to the disk groups. 00:34:38.600 --> 00:34:45.600 And now we know it's done because it did that scan for our vSAN health check. 00:34:45.600 --> 00:34:48.600 So, what the vSAN health check is going to be doing, now that it's kicked this off, 00:34:48.600 --> 00:34:52.600 let's go ahead and wait for this to continue – or, I'm sorry, to complete. 00:34:52.600 --> 00:35:00.600 So, once this is completed, I'll show you what this is – what this is building. 00:35:00.600 --> 00:35:07.600 So, now that health check is completed, let me get this out of the way. 00:35:07.600 --> 00:35:17.600 So, now for my cluster, I'm going to go to monitor, scroll down to vSAN, and check on health. 00:35:17.600 --> 00:35:21.600 And this will give me a Skyline health check. 00:35:21.600 --> 00:35:22.600 Oops, I'm sorry. 00:35:22.600 --> 00:35:23.600 Skyline here. 00:35:23.600 --> 00:35:26.600 vSAN Skyline health check. 00:35:26.600 --> 00:35:28.600 So, my health is at 96%. 00:35:28.600 --> 00:35:30.600 That's not horrible. 00:35:30.600 --> 00:35:31.600 It's not ideal. 00:35:31.600 --> 00:35:32.600 Of course, you want it to be 100. 00:35:32.600 --> 00:35:34.600 But if I want to know, well, why am I not at 100? 00:35:34.600 --> 00:35:35.600 100 would be better. 00:35:35.600 --> 00:35:38.600 Let's scroll down. 00:35:38.600 --> 00:35:41.600 And it'll tell me because my vSAN cluster isn't consistent yet. 00:35:41.600 --> 00:35:47.600 So, if I let this run a little bit longer, that will probably get better just because it's a brand-new cluster still being, you know, 00:35:47.600 --> 00:35:49.600 still syncing itself up. 00:35:49.600 --> 00:35:51.600 Also, does not like my NVMe devices. 00:35:51.600 --> 00:35:54.600 That's a problem. 00:35:54.600 --> 00:36:01.600 And this performance service status here, what this is talking about is that basically all the devices in my vSAN cluster are 00:36:01.600 --> 00:36:03.600 really small devices. 00:36:03.600 --> 00:36:08.600 They're under – you know, my whole cluster is under 256 gigs, and it's not happy about that. 00:36:08.600 --> 00:36:12.600 It doesn't like those tiny devices. 00:36:12.600 --> 00:36:15.600 Let's scroll back up here. 00:36:15.600 --> 00:36:18.600 Let's see if we do a retest, if that improves my score, 00:36:18.600 --> 00:36:22.600 and if it has a chance to synchronize up a little bit more. 00:36:22.600 --> 00:36:23.600 Okay, got a little bit better. 00:36:23.600 --> 00:36:24.600 Went to 97. 00:36:24.600 --> 00:36:25.600 All right. 00:36:25.600 --> 00:36:26.600 So, it's starting to sync up. 00:36:26.600 --> 00:36:31.600 Now, what we want to do is some time's gone by, and we're using our vSAN. 00:36:31.600 --> 00:36:32.600 Everything's going great. 00:36:32.600 --> 00:36:34.600 We've been throwing VMs in there. 00:36:34.600 --> 00:36:38.600 And now we decide we need to add more capacity to our vSAN cluster. 00:36:38.600 --> 00:36:41.600 Maybe we need to add more compute and things like that to our hosts. 00:36:41.600 --> 00:36:44.600 So, I'm going to add a host to this vSAN cluster. 00:36:44.600 --> 00:36:50.600 So, I'm going to take this host and just drop it on that cluster. 00:36:50.600 --> 00:36:57.600 I'm going to say go ahead and bring all the virtual machines that are on that host along with you. 00:36:57.600 --> 00:36:58.600 All right. 00:36:58.600 --> 00:37:02.600 So, now my host, this new host, is in this cluster. 00:37:02.600 --> 00:37:13.600 And if I go back to the cluster and to monitor skyline health, wow, it got way worse. 00:37:13.600 --> 00:37:14.600 Now it's 92. 00:37:14.600 --> 00:37:16.600 Why did it get so low? 00:37:16.600 --> 00:37:17.600 What happened there? 00:37:17.600 --> 00:37:21.600 Let's scroll down. 00:37:21.600 --> 00:37:26.600 And it's saying that not all the hosts have a vSAN VM kernel adapter configured. 00:37:26.600 --> 00:37:28.600 Well, that could be a problem. 00:37:28.600 --> 00:37:31.600 So, let's scroll a little bit and just try and get some more information about this. 00:37:31.600 --> 00:37:34.600 I say troubleshoot, and it tells me it's host 4. 00:37:34.600 --> 00:37:38.600 So, okay, I know host 4 doesn't have the VM kernel configured for vSAN. 00:37:38.600 --> 00:37:40.600 So, I'm going to click on that. 00:37:40.600 --> 00:37:42.600 Now I'm on host 4. 00:37:42.600 --> 00:37:48.600 I'm going to go to configuration, and I'm going to go to VM kernel adapters. 00:37:48.600 --> 00:37:51.600 I'm going to add a VM kernel adapter for vSAN. 00:37:51.600 --> 00:37:54.600 So, I'm going to say add networking. 00:37:54.600 --> 00:37:59.600 My VM kernel adapter. 00:37:59.600 --> 00:38:05.600 I'm going to use my vSAN port group. 00:38:05.600 --> 00:38:08.600 I'm going to say next. 00:38:08.600 --> 00:38:11.600 And I'm going to say I want to add the vSAN service. 00:38:11.600 --> 00:38:15.600 Everything else is fine on this screen. 00:38:15.600 --> 00:38:18.600 I'm going to assign it a static IP address. 00:38:18.600 --> 00:38:27.600 And the IP address I'm going to give it is 192.168.130.54. 00:38:27.600 --> 00:38:34.600 And so that masks 255.255.255.0. 00:38:34.600 --> 00:38:37.600 And I'm going to override the default gateway. 00:38:37.600 --> 00:38:42.600 And I want that to be 192.168.130.1. 00:38:42.600 --> 00:38:44.600 I'm going to say next. 00:38:44.600 --> 00:38:46.600 And it'll ask me are all my settings correct. 00:38:46.600 --> 00:38:50.600 Yep, I don't want to enable any other services other than vSAN. 00:38:50.600 --> 00:38:54.600 This is the IP address I wanted, 192.168.130.54. 00:38:54.600 --> 00:38:55.600 Yep, 24-bit mask. 00:38:55.600 --> 00:38:57.600 Everything looks good there. 00:38:57.600 --> 00:39:01.600 I'm going to say finish. 00:39:01.600 --> 00:39:05.600 And so now I have a VM kernel port enabled for vSAN, 00:39:05.600 --> 00:39:08.600 and it happens to be on the correct network for vSAN. 00:39:08.600 --> 00:39:16.600 So if I go back to my cluster 00:39:16.600 --> 00:39:21.600 and jump back to my Skyline Health, let's retest that. 00:39:21.600 --> 00:39:23.600 Let's give that a moment to run. 00:39:23.600 --> 00:39:26.600 And now I'm at 98%, much better. 00:39:26.600 --> 00:39:29.600 And the problems I have, that VM kernel adapter once gone, 00:39:29.600 --> 00:39:32.600 but my NVMe devices have not changed. 00:39:32.600 --> 00:39:35.600 All right, my vSAN max component size hasn't changed. 00:39:35.600 --> 00:39:38.600 So it's much, much better. 00:39:38.600 --> 00:39:44.600 But now that I've added that, what I haven't done is actually added 00:39:44.600 --> 00:39:47.600 any storage to vSAN. 00:39:47.600 --> 00:39:50.600 Now I go back down to vSAN, and now that I've installed vSAN on here, 00:39:50.600 --> 00:39:57.600 other than just services, I also have disk management. 00:39:57.600 --> 00:40:01.600 And under disk management, if I scroll down, I'll see my host is here, 00:40:01.600 --> 00:40:04.600 but there's no disk in use. 00:40:04.600 --> 00:40:07.600 Zero of the three disks it has are being used by vSAN. 00:40:07.600 --> 00:40:14.600 So what I want to do is go and claim unused disks. 00:40:14.600 --> 00:40:17.600 And it's showing me what's available to be claimed. 00:40:17.600 --> 00:40:23.600 One cache disk is available, and two capacity disks are available. 00:40:23.600 --> 00:40:29.600 So I'm going to add those. 00:40:29.600 --> 00:40:34.600 This actually goes through pretty quick. 00:40:34.600 --> 00:40:40.600 Let's just refresh the screen. 00:40:40.600 --> 00:40:45.600 And now on host four, I actually have three of three disks in here. 00:40:45.600 --> 00:40:52.600 If I go to my summary, I can see the capacity, right, 00:40:52.600 --> 00:40:55.600 how much storage I've got going on here. 00:40:55.600 --> 00:40:59.600 I can see my DRS score for this. 00:40:59.600 --> 00:41:04.600 This is just a summary for the cluster. 00:41:04.600 --> 00:41:16.600 And I can also go into my data stores, choose my vSAN data store. 00:41:16.600 --> 00:41:20.600 And I can see the storage that's being used on that because there's overhead 00:41:20.600 --> 00:41:24.600 just to create vSAN from those disks, right, the allocation here, 00:41:24.600 --> 00:41:30.600 scroll down a little bit, see if there's any other good information. 00:41:30.600 --> 00:41:35.600 Here I can see a little graph of my vSAN's 2% used. 00:41:35.600 --> 00:41:38.600 All right. 00:41:38.600 --> 00:41:40.600 We want to say view capacity. 00:41:40.600 --> 00:41:45.600 We can get a little more information from here. 00:41:45.600 --> 00:41:51.600 All right. 00:41:51.600 --> 00:41:55.600 So we have gone in. 00:41:55.600 --> 00:42:00.600 We created a vSAN cluster in the vSAN data store. 00:42:00.600 --> 00:42:02.600 We added a host and increased it. 00:42:02.600 --> 00:42:13.600 And now we also know how to go in and monitor the health using Skyline of 00:42:13.600 --> 00:42:21.600 our vSAN. 00:42:21.600 --> 00:42:24.600 And we know how to configure the vSAN services. 00:42:24.600 --> 00:42:33.600 So if I want to do something like go into vSAN services and I want to enable 00:42:33.600 --> 00:42:40.600 file services so that I can do something like create an SMB or an NFS share, 00:42:40.600 --> 00:42:42.600 I can enable those services there. 00:42:42.600 --> 00:42:49.600 I can also go in to data services, edit my data services, 00:42:49.600 --> 00:42:56.600 and all the same options I had to configure when I was configuring that vSAN, 00:42:56.600 --> 00:42:58.600 I can do it from here. 00:42:58.600 --> 00:42:59.600 I can go in. 00:42:59.600 --> 00:43:02.600 I can enable compression only, deduplication and compression. 00:43:02.600 --> 00:43:07.600 I can enable encryption for data at rest or encryption for data in transit. 00:43:07.600 --> 00:43:10.600 All the same options are here as when I was going through the installation. 00:43:10.600 --> 00:43:12.600 So during the install, if you're not really sure what you want to use 00:43:12.600 --> 00:43:15.600 and don't use, or if you change your mind later, 00:43:15.600 --> 00:43:18.600 you can go in there and do those things here, right? 00:43:18.600 --> 00:43:20.600 Don't forget about your file services from here. 00:43:20.600 --> 00:43:23.600 And also don't forget about your data services. 00:43:23.600 --> 00:43:29.600 And you can also enable iSCSI targets from here as well. 00:43:29.600 --> 00:43:34.600 So that is configuring a vSAN cluster in vSER. 00:43:34.600 --> 00:43:39.600 So, again, this is done at hol.vmware.com, and there's a lot more options, 00:43:39.600 --> 00:43:42.600 a lot more things you can configure in that lab. 00:43:42.600 --> 00:43:44.600 You can configure storage policies and things like that. 00:43:44.600 --> 00:43:48.600 So I encourage you to go to hol.vmware.com and try these labs for yourself. 00:43:48.600 --> 00:43:50.600 So I hope you enjoyed that demo. 00:43:50.600 --> 00:43:51.600 It was informative for you. 00:43:51.600 --> 00:43:56.600 So let's go back to continuing our lecture on vSAN. 00:43:56.600 --> 00:44:02.600 So to create vSAN like you saw in the demo, there's different ways of doing it. 00:44:02.600 --> 00:44:05.600 You definitely need to go to, you know, select your cluster, 00:44:05.600 --> 00:44:07.600 and then you're going to want to go to configuration, 00:44:07.600 --> 00:44:10.600 go down to vSAN, and you can create your cluster from there. 00:44:10.600 --> 00:44:12.600 There are other options, other ways of doing it, 00:44:12.600 --> 00:44:15.600 but the most common and easiest way is just from your inventory, 00:44:15.600 --> 00:44:19.600 selecting your cluster, going to your configuration tab, 00:44:19.600 --> 00:44:24.600 then going down to the vSAN option, and then choosing your services, 00:44:24.600 --> 00:44:28.600 and you can run through the whole vSAN wizard there like we did in our demo. 00:44:28.600 --> 00:44:33.600 You can also edit the vSAN settings by, again, you can choose your cluster, 00:44:33.600 --> 00:44:36.600 go to the configuration tab, selecting services, 00:44:36.600 --> 00:44:39.600 and then you can go in there and just choose what option you want to edit. 00:44:39.600 --> 00:44:41.600 Do you want to edit your file services? 00:44:41.600 --> 00:44:43.600 Do you want to edit iSCSI and make this an iSCSI target? 00:44:43.600 --> 00:44:47.600 Do you want to edit data services and enable compression? 00:44:47.600 --> 00:44:49.600 Or, you know, what exactly are you looking to do? 00:44:49.600 --> 00:44:54.600 But you can do that, again, by choosing your cluster, going to configuration, 00:44:54.600 --> 00:44:56.600 going down to vSAN, choosing services, 00:44:56.600 --> 00:44:59.600 and then editing the option for each of our components you're looking to edit. 00:44:59.600 --> 00:45:05.600 So there's also performance, you know, services. 00:45:05.600 --> 00:45:10.600 So, for example, you can make an iSCSI target, enable file services, 00:45:10.600 --> 00:45:12.600 not only the data services, which would be your compression, 00:45:12.600 --> 00:45:14.600 your deduplication, and your encryption. 00:45:14.600 --> 00:45:16.600 You can also enable file services, 00:45:16.600 --> 00:45:21.600 which allow you to enable either an NSS share or an SMB share. 00:45:21.600 --> 00:45:24.600 And you can also do capacity reservations from there, too. 00:45:24.600 --> 00:45:28.600 So you can say capacity reservations are basically a way of saying that you 00:45:28.600 --> 00:45:32.600 need to reserve a certain amount of capacity that's not going to be used 00:45:32.600 --> 00:45:34.600 because vSAN might need that. 00:45:34.600 --> 00:45:38.600 For example, if you know coming up pretty soon you're going to be doing an 00:45:38.600 --> 00:45:42.600 upgrade, and so when you do your upgrade, you're going to upgrade vSAN, 00:45:42.600 --> 00:45:48.600 and you're like, I'm getting really close on my capacity being utilized, 00:45:48.600 --> 00:45:51.600 because you need at least one data store and available capacity, right? 00:45:51.600 --> 00:45:54.600 You can actually reserve that capacity so people can't be throwing things on 00:45:54.600 --> 00:45:57.600 there, like, say, for example, the shares or things like that, 00:45:57.600 --> 00:46:00.600 and limit that usage. 00:46:00.600 --> 00:46:05.600 The capacity reservations can give you the ability to save free space that's 00:46:05.600 --> 00:46:10.600 actually in the vSAN capacity area so that you can upgrade data stores 00:46:10.600 --> 00:46:15.600 or patch and things like that. 00:46:15.600 --> 00:46:19.600 So some other vSAN settings, object repair timer, 00:46:19.600 --> 00:46:22.600 so that's a way you can go in there and just schedule maintenance on your 00:46:22.600 --> 00:46:25.600 vSAN cluster, read a location. 00:46:25.600 --> 00:46:27.600 So what you can do if you have a stretch cluster, 00:46:27.600 --> 00:46:31.600 a stretch cluster means you have members in different locations, right? 00:46:31.600 --> 00:46:39.600 And so relocation will be which location do you want to be the primary space 00:46:39.600 --> 00:46:41.600 where, like, a VM is read from. 00:46:41.600 --> 00:46:44.600 Because if your hosts are going to be in a certain location running a certain 00:46:44.600 --> 00:46:48.600 VM, you don't want them going to another member of vSAN to try 00:46:48.600 --> 00:46:49.600 and run that, right? 00:46:49.600 --> 00:46:53.600 So you can say which location you want the VM to be running from. 00:46:53.600 --> 00:46:56.600 Thin swap provisioning, so you can make your swap space, right? 00:46:56.600 --> 00:47:00.600 But thin swap provisioning means that rather than normally it makes a thick 00:47:00.600 --> 00:47:03.600 file but uses a whole space for that file, it will thin provision it 00:47:03.600 --> 00:47:05.600 and grow it as needed. 00:47:05.600 --> 00:47:09.600 It's just a way of saving space for your VMs because every time the VM powers 00:47:09.600 --> 00:47:11.600 on, it creates that swap file. 00:47:11.600 --> 00:47:13.600 You can also say you want to allow large cluster support, 00:47:13.600 --> 00:47:17.600 which means clusters of up to 64 hosts, so it's a pretty large vSAN cluster. 00:47:18.600 --> 00:47:24.600 And automatic rebalance would just basically mean if the data stores aren't 00:47:24.600 --> 00:47:28.600 balanced and, like, say one host is getting way more utilization than another, 00:47:28.600 --> 00:47:33.600 you can automatically rebalance the data stores to even out the load 00:47:33.600 --> 00:47:38.600 across the hosts. 00:47:38.600 --> 00:47:39.600 So you view vSAN. 00:47:39.600 --> 00:47:41.600 So vSAN has storage policies. 00:47:41.600 --> 00:47:44.600 You're enabled a storage policy for vSAN the same way as you did in our 00:47:44.600 --> 00:47:46.600 previous lesson. 00:47:46.600 --> 00:47:50.600 Basically, you just go to your little Big Mac icon at the top, click on that, 00:47:50.600 --> 00:47:54.600 and you're going to say your policies option, 00:47:54.600 --> 00:47:56.600 and then there you'll have your storage policies. 00:47:56.600 --> 00:47:58.600 You'll see ones for vSAN. 00:47:58.600 --> 00:48:00.600 There's a default vSAN policy. 00:48:00.600 --> 00:48:02.600 You can create custom vSAN policies, right? 00:48:02.600 --> 00:48:05.600 You can also get properties about the vSAN itself. 00:48:05.600 --> 00:48:08.600 Before you create policies for vSAN, you probably want to know what 00:48:08.600 --> 00:48:09.600 the capabilities are. 00:48:09.600 --> 00:48:13.600 You don't want to create a policy that requires encryption 00:48:13.600 --> 00:48:15.600 and you have it enabled encryption, right? 00:48:15.600 --> 00:48:21.600 So you can just browse to your vSAN data store, right, 00:48:21.600 --> 00:48:23.600 and then you can go through and look and see what you've configured 00:48:23.600 --> 00:48:24.600 or you can go to the summary 00:48:24.600 --> 00:48:27.600 and you can see also from summary what you've configured. 00:48:27.600 --> 00:48:33.600 So you can either do it from the configuration or from the summary. 00:48:33.600 --> 00:48:36.600 Uploading and downloading files from vSAN. 00:48:36.600 --> 00:48:38.600 So just like you would do from any other data store, 00:48:38.600 --> 00:48:42.600 you can just browse to the vSAN data store and you can right-click on it 00:48:42.600 --> 00:48:44.600 until you want to browse data store. 00:48:44.600 --> 00:48:48.600 And from within there, you can choose to upload files to it 00:48:48.600 --> 00:48:50.600 or download files from it. 00:48:50.600 --> 00:48:54.600 So when you upload to the vSAN data store, 00:48:54.600 --> 00:48:58.600 whatever you're uploading to there is going to inherit the properties 00:48:58.600 --> 00:49:01.600 of the vSAN itself regardless of where it came from. 00:49:01.600 --> 00:49:04.600 It's going to now have, if vSAN has encryption enabled, 00:49:04.600 --> 00:49:05.600 it will be encrypted. 00:49:05.600 --> 00:49:09.600 If it has compression enabled, it will be compressed, things like that. 00:49:09.600 --> 00:49:11.600 You can also choose to download from there. 00:49:11.600 --> 00:49:14.600 So let's say there's an ISO file you want up there. 00:49:14.600 --> 00:49:16.600 You can click on it and choose to download it. 00:49:16.600 --> 00:49:21.600 You can also download VMs themselves, but downloading VMs can get tricky 00:49:21.600 --> 00:49:23.600 because even like thin provisioned VMs, 00:49:23.600 --> 00:49:25.600 when you download them they become thick provisioned. 00:49:25.600 --> 00:49:28.600 There's a bunch of things in there that make it kind of complicated. 00:49:28.600 --> 00:49:31.600 It's not as straightforward as just right-clicking on it 00:49:31.600 --> 00:49:33.600 and you get exactly what you're seeing. 00:49:33.600 --> 00:49:36.600 So just be careful about that when you're trying to download from a data store. 00:49:37.600 --> 00:49:40.600 You're probably better off going to the VM itself 00:49:40.600 --> 00:49:43.600 and exporting it as like an OVA file. 00:49:43.600 --> 00:49:47.600 That's usually a better way of getting a VM onto your hard drive 00:49:47.600 --> 00:49:50.600 of your local computer versus in the storage on the host 00:49:50.600 --> 00:49:53.600 is using like an OVA or OVF file. 00:49:53.600 --> 00:49:55.600 But you can browse the data store 00:49:55.600 --> 00:50:01.600 and you can download files from there directly too. 00:50:02.600 --> 00:50:07.600 You can add storage to an existing disk group 00:50:07.600 --> 00:50:08.600 or you can create new disk groups. 00:50:08.600 --> 00:50:11.600 So if you're adding just disks to your existing host, 00:50:11.600 --> 00:50:13.600 you can go in there and claim those disks 00:50:13.600 --> 00:50:16.600 and add them to a data store or to a disk group, 00:50:16.600 --> 00:50:19.600 or you can also create a new disk group. 00:50:19.600 --> 00:50:21.600 You can also add a host. 00:50:21.600 --> 00:50:23.600 If you add in a host, you can bring the disks from that host in 00:50:23.600 --> 00:50:27.600 and you're adding additional capacity to vSAN by adding a host with the disks 00:50:27.600 --> 00:50:31.600 in there and that will create new disk groups for that host. 00:50:31.600 --> 00:50:35.600 When you add disks, you can add either flash disks or capacity disks. 00:50:35.600 --> 00:50:38.600 If you're adding capacity, you might want to also add flash, 00:50:38.600 --> 00:50:41.600 which means you might be creating another disk group. 00:50:41.600 --> 00:50:45.600 Remember, you want to ratio about 30% of flash to capacity. 00:50:45.600 --> 00:50:47.600 So you don't want to start adding a bunch of capacity disks 00:50:47.600 --> 00:50:50.600 and not upgrading your flash capacity as well. 00:50:50.600 --> 00:50:54.600 Another way you can add capacity is to add controllers, 00:50:54.600 --> 00:50:57.600 which then allows you to add more disks. 00:50:57.600 --> 00:51:00.600 Also, adding more controllers and moving existing disks to there 00:51:00.600 --> 00:51:04.600 won't increase your capacity, but it might help with performance. 00:51:04.600 --> 00:51:07.600 So that's another issue there. 00:51:07.600 --> 00:51:09.600 Most controllers are, you know, 00:51:09.600 --> 00:51:12.600 enterprise-grade brand-name controllers, they're very fast. 00:51:12.600 --> 00:51:17.600 They can handle loading up the disks on them to their capacity. 00:51:17.600 --> 00:51:20.600 But if you are seeing some kind of performance issue with caching on the 00:51:20.600 --> 00:51:23.600 HBAs or their disk controllers or something like that, 00:51:23.600 --> 00:51:25.600 then adding another controller might help. 00:51:25.600 --> 00:51:28.600 And then, again, you can also add capacity. 00:51:28.600 --> 00:51:34.600 You can also add caching by adding a host. 00:51:34.600 --> 00:51:38.600 So adding device to vSAN, kind of like we saw before, you're going to go in, 00:51:38.600 --> 00:51:44.600 you can add the disk to the devices, go to your configuration tab, 00:51:44.600 --> 00:51:46.600 choose the vSAN, go to disk management, 00:51:46.600 --> 00:51:49.600 and then you can either go to disk groups and add disks, 00:51:49.600 --> 00:51:51.600 or you can say you want to just reclaim 00:51:51.600 --> 00:51:54.600 or claim the unused disks that are in there. 00:51:54.600 --> 00:51:57.600 When you are reclaiming or claiming disks, 00:51:57.600 --> 00:52:00.600 you will get some questions like, do you want to clear residual data? 00:52:00.600 --> 00:52:03.600 What that means basically is if you want to clear, 00:52:03.600 --> 00:52:06.600 especially on a flash drive, 00:52:06.600 --> 00:52:09.600 data that might be on pages that are in that flash disk, 00:52:09.600 --> 00:52:12.600 generally considering it's a good idea to do that. 00:52:12.600 --> 00:52:14.600 It might take a little bit longer because you're going to go through 00:52:14.600 --> 00:52:17.600 and do a more thorough wiping, 00:52:17.600 --> 00:52:19.600 but it's considered a good idea to do that, 00:52:19.600 --> 00:52:22.600 to clear the residual data on there, right? 00:52:22.600 --> 00:52:24.600 You might check any partition information. 00:52:24.600 --> 00:52:26.600 And then you want to do a disk balance health check 00:52:26.600 --> 00:52:28.600 because if you're adding disks to one host and not to another, 00:52:28.600 --> 00:52:32.600 you might start seeing some imbalances on the number of VMs on a host 00:52:32.600 --> 00:52:36.600 versus another and what the disk can handle for IO and things like that. 00:52:36.600 --> 00:52:38.600 It's generally a good idea, though, 00:52:38.600 --> 00:52:42.600 to keep all your hosts pretty much configured hardware-wise 00:52:42.600 --> 00:52:45.600 and then for software vSAN-wise the same. 00:52:45.600 --> 00:52:49.600 So you don't really want to have a host that's got three times the capacity 00:52:49.600 --> 00:52:51.600 to the next closest host. 00:52:51.600 --> 00:52:55.600 You want them to be balanced out as much as you can. 00:52:55.600 --> 00:53:00.600 So vSAN policies, you can define storage policies for vSAN 00:53:00.600 --> 00:53:05.600 just like you would do for a SAN storage or something like that. 00:53:05.600 --> 00:53:08.600 And then you can assign storage policies to your VMs. 00:53:08.600 --> 00:53:11.600 You can do it when they're created, when you go to create a new VM. 00:53:11.600 --> 00:53:13.600 You can assign a storage policy. 00:53:13.600 --> 00:53:15.600 You can also assign it to a virtual disk for a VM. 00:53:15.600 --> 00:53:19.600 So two different virtual disks on a VM can have different storage policies 00:53:19.600 --> 00:53:22.600 because maybe one's for the OS and that doesn't have to be on quite as fast 00:53:22.600 --> 00:53:27.600 or backed up as often, whereas another disk maybe is for a SQL database 00:53:27.600 --> 00:53:31.600 that needs to be very fast and you need it backed up much more frequently, 00:53:31.600 --> 00:53:32.600 things like that. 00:53:32.600 --> 00:53:36.600 So you can put different policies for different types of disks on a VM. 00:53:36.600 --> 00:53:41.600 Service levels for the VMs, so that would just mean what services you want 00:53:41.600 --> 00:53:42.600 available like we saw before. 00:53:42.600 --> 00:53:46.600 Are we going to do compression, deduplication, things like that? 00:53:46.600 --> 00:53:50.600 You can use it as a wizard to allow you to go through and enable rules 00:53:50.600 --> 00:53:52.600 and things like that for your vSAN storage. 00:53:52.600 --> 00:53:56.600 So your attributes are going to be very standard to what we saw before. 00:53:56.600 --> 00:53:58.600 You can do dual-site mirroring. 00:53:58.600 --> 00:54:05.600 So we want basically it to be replicated to a vSAN member at another location. 00:54:05.600 --> 00:54:07.600 So we have a stretched vSAN cluster. 00:54:07.600 --> 00:54:10.600 Stretched vSAN clusters do require really good network throughput, 00:54:10.600 --> 00:54:12.600 so be careful about configuring things like that. 00:54:12.600 --> 00:54:18.600 You want very low IO latency and very high throughput. 00:54:18.600 --> 00:54:22.600 And then advanced storage policy rules, you can go through 00:54:22.600 --> 00:54:25.600 and you can create any kind of additional rule that you really need. 00:54:25.600 --> 00:54:28.600 Again, you don't want to go through and create policies, though, 00:54:28.600 --> 00:54:30.600 until you are sure what your vSAN is configured for. 00:54:30.600 --> 00:54:33.600 Again, don't want to create policies that require a service, say, 00:54:33.600 --> 00:54:39.600 for example, encryption, and you haven't enabled that yet. 00:54:39.600 --> 00:54:41.600 Space efficiency. 00:54:41.600 --> 00:54:43.600 So there's unmap. 00:54:43.600 --> 00:54:45.600 Unmap is one of those things that's been around forever. 00:54:45.600 --> 00:54:49.600 Everyone who's a storage admin working with VMware especially is aware of it, 00:54:49.600 --> 00:54:52.600 but not all VMware admins are really familiar with unmap. 00:54:52.600 --> 00:54:58.600 So basically, unmap is a SCSI command that will go in and zero out blocks. 00:54:58.600 --> 00:55:03.600 So if in a VMDK file within a VM you delete a bunch of files, 00:55:03.600 --> 00:55:05.600 the VMDK file is still there. 00:55:05.600 --> 00:55:09.600 The VM knows in this file allocation table, so let's say it's a Windows VM, 00:55:09.600 --> 00:55:14.600 in the NTFS file allocation table, it's like, oh, yeah, those blocks are available. 00:55:14.600 --> 00:55:17.600 But on the VMDK file, they're zeroed. 00:55:17.600 --> 00:55:22.600 So you can run unmap in a Linux VM or a Windows VM, 00:55:22.600 --> 00:55:27.600 and that will zero out the blocks or the data that it has deleted. 00:55:27.600 --> 00:55:31.600 That might be a task you have to be able to run maybe once in the evening 00:55:31.600 --> 00:55:34.600 or once a week on the weekend or something like that. 00:55:34.600 --> 00:55:37.600 Maybe so often so that it zeroes out the blocks. 00:55:37.600 --> 00:55:41.600 So that way your storage knows it can reclaim that space 00:55:41.600 --> 00:55:43.600 and it can actually shrink the VMDK files. 00:55:43.600 --> 00:55:46.600 Other things you can do to help make your space more efficient besides, 00:55:46.600 --> 00:55:49.600 you know, running a task like unmap, you can enable compression. 00:55:49.600 --> 00:55:51.600 You can enable deduplication. 00:55:51.600 --> 00:55:53.600 Those are both possible. 00:55:53.600 --> 00:55:57.600 Your fault tolerance method will determine also your capacity, right? 00:55:57.600 --> 00:56:03.600 RAID 5 writes parity once, which means if you can lose one drive and you're okay. 00:56:03.600 --> 00:56:05.600 You lose two, you've lost all your data. 00:56:05.600 --> 00:56:08.600 RAID 6 writes the parity twice. 00:56:08.600 --> 00:56:11.600 So you can lose two drives and still be okay. 00:56:11.600 --> 00:56:14.600 You lose a third, you've lost your data, right? 00:56:14.600 --> 00:56:19.600 So you don't actually configure RAID on your drives with vSAN, 00:56:19.600 --> 00:56:23.600 as we discussed before, but you can configure vSAN to allow, you know, 00:56:23.600 --> 00:56:26.600 the loss of a single host or the loss of multiple hosts, 00:56:26.600 --> 00:56:28.600 like two hosts, things like that. 00:56:28.600 --> 00:56:30.600 So your fault tolerance level, the higher it is, 00:56:30.600 --> 00:56:32.600 the more hosts you can afford to lose, 00:56:32.600 --> 00:56:36.600 then the less space you have available for actual capacity for storing 00:56:36.600 --> 00:56:38.600 VM information. 00:56:38.600 --> 00:56:41.600 So this kind of depends there on what your needs are, 00:56:41.600 --> 00:56:44.600 what your corporate policy is as far as fault tolerance levels 00:56:44.600 --> 00:56:47.600 and things like that. 00:56:47.600 --> 00:56:49.600 And SAN encryption. 00:56:49.600 --> 00:56:51.600 So we can do encryption, right? 00:56:51.600 --> 00:56:53.600 We can encrypt the data at rest. 00:56:53.600 --> 00:56:56.600 We can also encrypt data in transit. 00:56:56.600 --> 00:56:59.600 If we want to encrypt our data at rest, we need to show it a key. 00:56:59.600 --> 00:57:01.600 So we need to configure a key provider, right? 00:57:01.600 --> 00:57:03.600 We need to configure a key store. 00:57:03.600 --> 00:57:06.600 So if you're going to configure KMS key services, 00:57:06.600 --> 00:57:10.600 then that key, you can be requested, 00:57:10.600 --> 00:57:12.600 vCenter can have it installed on there, 00:57:12.600 --> 00:57:14.600 then vCenter is going to push it to the host, 00:57:14.600 --> 00:57:17.600 and the host will then know they have keys available for configuring 00:57:17.600 --> 00:57:19.600 services like vSAN. 00:57:19.600 --> 00:57:24.600 So you need a key management server that sends the key services to vCenter, 00:57:24.600 --> 00:57:28.600 and vCenter will get them to the EFXI host so that we can encrypt our data. 00:57:28.600 --> 00:57:31.600 So it's not just a matter of checking a box, 00:57:31.600 --> 00:57:34.600 there's actually a whole entire KMS infrastructure behind it. 00:57:34.600 --> 00:57:40.600 So some quick well-known issues. 00:57:40.600 --> 00:57:45.600 HAVM failover or failures. 00:57:45.600 --> 00:57:49.600 So what basically means if you remove a disk group from a host and then all 00:57:49.600 --> 00:57:53.600 of a sudden you can't migrate the VMs and it fails to try to migrate, 00:57:53.600 --> 00:57:55.600 you need to add the disk group back, right? 00:57:55.600 --> 00:57:57.600 You need that storage available. 00:57:57.600 --> 00:58:05.600 Post adapter to a cluster without a disk group cannot save via VSVM 00:58:05.600 --> 00:58:07.600 deployment to the host. 00:58:07.600 --> 00:58:13.600 What they're saying is we can't create an NFS share or we can't create an 00:58:13.600 --> 00:58:17.600 SMB share on this host because we don't have disks on it. 00:58:17.600 --> 00:58:19.600 We need to add a disk group and add disks to it. 00:58:19.600 --> 00:58:20.600 That's all there is to it. 00:58:20.600 --> 00:58:22.600 It needs disks in order to use those services, right? 00:58:23.600 --> 00:58:28.600 Post-recovery VMs lose HA protection. 00:58:28.600 --> 00:58:32.600 So what basically means is if a VSAN has gotten full, 00:58:32.600 --> 00:58:35.600 then all of a sudden HA and things like that aren't going to work. 00:58:35.600 --> 00:58:38.600 Then you add capacity, and after you've added capacity, 00:58:38.600 --> 00:58:41.600 HA still isn't working, the HA services still aren't there. 00:58:41.600 --> 00:58:46.600 You can go through and reconfigure HA or just remove and add back HA, 00:58:46.600 --> 00:58:51.600 and that will reset the HA services, and that should fix the problem. 00:58:51.600 --> 00:58:55.600 So just, you know, again, if a disk is full, HA is going to be kind of, 00:58:55.600 --> 00:58:57.600 I don't want to say disabled, not working. 00:58:57.600 --> 00:59:02.600 But when you add capacity, it doesn't also fix your HA, and it doesn't. 00:59:02.600 --> 00:59:07.600 You just disable HA and add HA back, and that will usually fix that problem.