WEBVTT 00:00:00.000 --> 00:00:04.320 Welcome back to vSphere 8 in the real world. Now we're going to do an introduction to virtual storage. 00:00:07.640 --> 00:00:12.460 So, some common vocabularies, some simple vocabulary to get started here. 00:00:12.880 --> 00:00:20.719 Local storage. Local storage is storage that will be local to the ESXi host, meaning it's literally in the ESXi host. 00:00:21.200 --> 00:00:26.360 So other hosts can't see it. It's going to be only available to that particular instance of ESXi. 00:00:27.080 --> 00:00:36.759 SAN storage. SAN is storage area network. And a SAN storage is block level access to storage that can be accessed over a network. 00:00:36.759 --> 00:00:41.599 So that's where the storage area network comes from. And it will be block level access, as I said. 00:00:41.840 --> 00:00:49.040 So with SAN storage, you will have either an iSCSI or a fiber channel. 00:00:49.720 --> 00:01:02.320 It can be fiber channel over Ethernet device that is connected to your ESXi host either directly, like fiber channel can be connected directly to the host, or it can be done through a switch. 00:01:02.320 --> 00:01:08.239 And fiber channel will be done through a fiber channel switch. And iSCSI will be done through a regular Ethernet switch. 00:01:08.559 --> 00:01:20.680 And you'll be sending packets over a network to a storage device that will then de-encapsulate those, either take out the iSCSI or take out the fiber channel. 00:01:20.959 --> 00:01:27.360 And you will then have SCSI commands that the storage array can then execute for you. 00:01:28.440 --> 00:01:32.320 iSCSI is sending SCSI commands over an IP network. 00:01:33.040 --> 00:01:42.279 It says here Internet base. So it's Internet with a small i, and that means that it's not like the Internet, because the latency would probably be far too high. 00:01:42.839 --> 00:01:47.000 You wouldn't probably have enough bandwidth in most instances, but the latency would really kill you. 00:01:48.160 --> 00:01:56.040 But it's sending these SCSI packets encapsulated in IP. So that's where the lowercase i for Internet is coming from with iSCSI. 00:01:56.040 --> 00:02:03.599 It says that it's over an IP network. Normally, your iSCSI traffic or any storage traffic is not going to be routed at all. 00:02:03.599 --> 00:02:09.720 You don't want to have your VMs going through some kind of a routing device to get from the host to the storage array. 00:02:09.960 --> 00:02:14.759 You want it to be on the same network for the minimal amount of latency that is possible. 00:02:15.199 --> 00:02:22.679 There are new technologies out there for like metro storage clusters and things like that that make that not quite as true. 00:02:22.720 --> 00:02:31.199 But those require very low latency still, even if you're going from one building to the next, it's going to be very, very low latency. 00:02:31.240 --> 00:02:36.000 And so you need to be very careful about that. So it's not saying any WAN connection is going to work. 00:02:36.039 --> 00:02:42.639 It's going to be a very expensive, high throughput, very low latency connection for those types of technologies. 00:02:43.399 --> 00:02:48.199 A LUN is what a SAN is going to present to the iSCSI host. 00:02:48.399 --> 00:02:56.199 So on your storage array, you're going to have a group of disks and most storage arrays are going to ask you to take those group of disks and create a pool. 00:02:56.399 --> 00:03:00.080 And then you can carve up that pool into smaller blocks called LUNs. 00:03:00.440 --> 00:03:07.360 Then you're going to present that LUN to whichever device server on the other side of the network is going to be using that LUN. 00:03:07.759 --> 00:03:10.119 And then those devices will partition it up. 00:03:10.160 --> 00:03:14.479 So for the Windows server, you might make it a dynamic disk and carve it up. 00:03:14.559 --> 00:03:18.679 Or if it would be a basic disk, you could create partitions on it and things like that. 00:03:19.000 --> 00:03:29.119 eSXI also can create partitions, but it is considered a best practice, a good practice to only have one partition on a LUN. 00:03:29.160 --> 00:03:36.440 Or if it's going to be multiple partitions, it's all for the same data store, meaning that you're going to have extension or have a LUN on there with a data store. 00:03:36.479 --> 00:03:39.720 And then you're going to add an extent onto that same data store. 00:03:39.919 --> 00:03:45.000 You don't want to carve up a LUN into a bunch of partitions and then put a bunch of different data stores on there. 00:03:45.039 --> 00:03:50.880 Ideally, you want it to be just one storage device that's presented to the eSXI host. 00:03:52.279 --> 00:03:57.320 Virtual disks in a VMware environment, a virtual disk is a VMDK file. 00:03:57.720 --> 00:04:02.880 And so this virtual disk or this VMDK file is going to be two files. 00:04:02.880 --> 00:04:13.759 So it would be one VMDK file that is a descriptor, it's a small little like maybe like 1K file that describes the geometry and things like that of the virtual disk that the eSXI host should be expecting to see. 00:04:14.279 --> 00:04:21.040 The second file is going to be a much larger file, and that is where the data is going to be stored by the VM. 00:04:21.079 --> 00:04:30.160 When the VM says write this to disk, when it thinks it's sending commands to write to a hard drive, that data gets written to that VMDK file. 00:04:30.200 --> 00:04:32.799 And that is the virtual disk for that virtual machine. 00:04:33.480 --> 00:04:37.040 VMFS, so we have a LUN, right? 00:04:37.079 --> 00:04:40.600 We present that LUN to the host, the host now needs to write to it. 00:04:40.600 --> 00:04:43.279 Before it can write to it, it has to format it. 00:04:44.000 --> 00:04:46.040 That is what VMFS is. 00:04:46.040 --> 00:04:55.559 VMFS is the file system that eSXI uses to format both local storage and your network attached storage, meaning your SANs. 00:04:56.440 --> 00:05:03.600 If you have a SAN and you're using vBall, then you don't actually have that VMFS file system, but that's a whole different conversation. 00:05:03.600 --> 00:05:08.200 And vBall requires a SAN that supports vBall specifically. 00:05:08.559 --> 00:05:10.079 Not everyone uses vBall. 00:05:10.359 --> 00:05:14.760 You need a certain license level to use vBall, and so we'll talk about that in a later lesson. 00:05:15.040 --> 00:05:19.519 But VMFS is the file system, the native file system for eSXI. 00:05:19.519 --> 00:05:27.600 So if you're formatting a local disk or you're formatting a LUN that looks like a disk that eSXI hosts, you're formatting that as VMFS. 00:05:28.200 --> 00:05:31.279 So NFS is a NAS protocol. 00:05:31.279 --> 00:05:41.760 So we have SAN, right, which is a storage area network, and we're sending SCSI commands over a network, you know, block commands to a block device on the network. 00:05:42.399 --> 00:05:45.720 NFS is a file level protocol. 00:05:46.000 --> 00:05:49.320 So we don't send SCSI commands and think that we're working at a block level. 00:05:49.320 --> 00:05:54.000 We're going to say, I want to access that file or write this file, copy this file. 00:05:54.200 --> 00:05:55.359 It's all file based. 00:05:55.640 --> 00:05:57.600 So that's kind of what you're used to looking at. 00:05:57.600 --> 00:06:01.600 When you go to Windows Explorer, you don't look at the blocks on the disk, you look at the file. 00:06:01.600 --> 00:06:04.839 So NFS presents to the eSXI host the same way. 00:06:04.839 --> 00:06:06.200 It presents at a file level. 00:06:06.559 --> 00:06:12.320 So the eSXI host will just say, here's my VMFS file, here's my VMX file. 00:06:12.519 --> 00:06:13.839 It's a file level storage. 00:06:14.040 --> 00:06:15.079 It's like SMB. 00:06:15.079 --> 00:06:17.519 So if you're used to Windows shares, Windows shares are SMB. 00:06:18.279 --> 00:06:21.480 Only NFS is what would be native to like a Unix system. 00:06:21.480 --> 00:06:31.359 And eSXI being, you know, Linux space, NFS is the network protocol that it uses for file level communication over a network. 00:06:31.959 --> 00:06:32.959 And a raw device map. 00:06:32.959 --> 00:06:35.559 So a raw device map means we have a SAN. 00:06:35.880 --> 00:06:37.640 The SAN has a pool and it has a LUN. 00:06:37.880 --> 00:06:39.200 The LUN is presented to the host. 00:06:39.480 --> 00:06:48.239 But rather than format that LUN with VMFS, we present it to the virtual machine and that VM is going to own that LUN. 00:06:48.640 --> 00:06:50.519 And then that VM can format it. 00:06:50.519 --> 00:06:56.959 So with a Windows server, for example, the Windows server would format that LUN as NTFS. 00:06:57.320 --> 00:07:06.320 And we would still have a VMX file that's attached to the virtual machine that describes and identifies that LUN that is that raw device map. 00:07:06.679 --> 00:07:18.480 But the raw device map allows the Windows system or Linux, whatever the guest OS of that VM is, to write commands, SCSI commands to the LUN. 00:07:18.799 --> 00:07:22.000 So there's different types of raw device maps. 00:07:22.440 --> 00:07:25.519 There's one type where there is no interpretation. 00:07:25.519 --> 00:07:27.440 There's no pair of virtualization happening. 00:07:28.040 --> 00:07:35.399 So the Windows machine or the Linux machine, whatever the VM is, is going to send commands directly uninterpreted by the eSXI host. 00:07:36.320 --> 00:07:38.320 To the SAN for that LUN. 00:07:38.839 --> 00:07:50.720 And there's another version that will allow us to actually interpret that eSXI host interprets the SCSI commands from the virtual machine and then translates them and sends them to the storage array. 00:07:51.040 --> 00:07:57.079 And it's still formatted as NTFS or, you know, ESP3 or ESP4 or whatever it is. 00:07:57.399 --> 00:08:06.119 But with the virtualized one where the host can do some interpretation, we can do things like snapshots and things like that. 00:08:06.320 --> 00:08:11.359 When it's just a true raw device map, then we can't take snapshots or anything like that for the virtual machine. 00:08:11.600 --> 00:08:15.160 So it's just going to be writing raw right directly to that disk. 00:08:18.600 --> 00:08:21.760 So shared storage design, vSAN. 00:08:21.760 --> 00:08:27.559 So what vSAN is, we have a group of eSXI hosts that are, you know, in a cluster. 00:08:28.119 --> 00:08:33.000 And maybe these hosts all have a lot of storage available on them. 00:08:33.000 --> 00:08:34.679 And we want to utilize that storage. 00:08:34.679 --> 00:08:39.039 And we don't want to go spend, you know, a million dollars on a SAN. 00:08:39.359 --> 00:08:42.799 We want to just use the storage that's in these hosts. 00:08:43.239 --> 00:08:52.000 And maybe the hosts all have 16 hard drives each and the hard drives are, you know, three or four or five terabytes each or whatever size. 00:08:52.000 --> 00:08:52.760 They could be huge. 00:08:53.159 --> 00:08:55.960 And they're all the same across all the hosts. 00:08:56.960 --> 00:09:06.080 So now what I want to do is I want to take it and have it all look like it's shared SAN storage to my eSXI host. 00:09:06.080 --> 00:09:14.880 Even though it's local storage on this host and it's local storage on this host and, you know, each one has their own local storage, it's going to look like a virtualized SAN. 00:09:15.239 --> 00:09:22.640 So what's going to happen, and this is kind of important to remember for later lessons, is with a vSAN, we create what are called disk groups. 00:09:22.919 --> 00:09:26.679 So on one host, maybe I have 16 drives. 00:09:26.919 --> 00:09:30.599 So maybe I'm going to create four disk groups of four disks each. 00:09:31.280 --> 00:09:33.679 And I will also have a flash drive. 00:09:33.719 --> 00:09:48.080 And before version 8, you had to have at least one flash disk for cache because these spinning disks might not be fast enough to process, you know, and give you the kind of performance you need for virtual machines on this shared storage like this. 00:09:48.320 --> 00:09:59.640 So you have a flash disk that the system writes to, and then it gets offloaded from the flash drive, which is cache, to the actual disks that are going to be used for the actual storage long term. 00:10:00.520 --> 00:10:09.719 So this host has the 16 drives, the four storage groups, or four disk groups of four, you know, four disks each, and they're all the same, right? 00:10:09.719 --> 00:10:17.200 They all are configured with four storage, four disk groups of four disks each across all 15 of my hosts. 00:10:17.239 --> 00:10:26.039 And so I actually end up having 60 different disk groups across these 15 hosts with all these different disks. 00:10:26.559 --> 00:10:36.880 Then it can take these disk groups, and it can virtualize them into a partition of this virtual SAN, and all of the hosts do the same thing. 00:10:38.359 --> 00:10:46.960 So now when I have a VM, I think I'm going to create a new VM, and I'll put it on, you'll hear on my vSAN, the system will say, OK, what are the rules you use when you create a vSAN? 00:10:47.119 --> 00:10:49.320 I said I wanted a N plus one. 00:10:49.640 --> 00:10:57.400 N plus one simply means that when I create a virtual disk on this host, I'm going to create a copy of it someplace else. 00:10:57.919 --> 00:11:04.719 I give you an N plus two, which means when I create a virtual disk on this host, I create two more copies somewhere on this network. 00:11:05.000 --> 00:11:11.000 So I always have three copies, the active one that I'm working on, plus two additional ones that are available. 00:11:11.000 --> 00:11:17.039 So if this one goes down, then it immediately spins up on another host, right? 00:11:17.039 --> 00:11:26.239 I'll move the VM to another host, and I'll run that VM on that host, and I have my other copy, and it's going to say, well, my rule is I want N plus two. 00:11:26.280 --> 00:11:28.400 And right now I have my N, and I have one. 00:11:28.760 --> 00:11:34.320 So now it's going to make another copy on another host, because I have 15 hosts in this big network. 00:11:34.359 --> 00:11:36.599 I have plenty of room to create additional. 00:11:36.919 --> 00:11:41.760 But one important thing to remember is a host is not a disk group necessarily. 00:11:41.760 --> 00:11:43.039 You could create one disk group. 00:11:43.039 --> 00:11:43.799 You probably won't. 00:11:44.080 --> 00:11:49.520 You'll create multiple disk groups on a host, breaking all those disks up into smaller groups of disk groups. 00:11:49.840 --> 00:11:56.919 And that'll be important later on when you're looking at things like fault tolerance, when you're looking at upgrading, when you're making changes to your vSAN. 00:11:57.479 --> 00:12:06.400 Having smaller chunks in these disk groups is going to make it really helpful, because let's say on here I had 16 terabytes all in one disk group. 00:12:06.760 --> 00:12:18.039 And I want to make an upgrade to a file system, or I want to upgrade vSAN, or I want to start encrypting my data, I have to have 16 terabytes of free space someplace on my network to do that with. 00:12:18.679 --> 00:12:29.440 If I have four disk groups of four terabytes each, now I only have to have four terabytes of free disk space in my vSAN to start doing upgrades and things like that. 00:12:29.479 --> 00:12:36.880 So, small disk groups make it easier for things like, like I said, upgrading to new versions of vSAN and enabling encryption and things like that. 00:12:37.239 --> 00:12:44.919 So, vSAN is a way to allow you to take local storage and present it to this ESXi host, and it looks like it's iSCSI storage. 00:12:45.320 --> 00:12:54.440 And some of the more recent versions, like with 8, you can actually create sys shares on these and present them to Windows machines, and you can do all kinds of things like that too. 00:12:54.719 --> 00:13:06.640 But the really important thing, I think it's going to be most often used for, is I'm able to use local storage on my hosts to store my virtual machines, and there'll be copies on other hosts. 00:13:06.719 --> 00:13:16.760 And I can still do DRS, I can do HA, I can do vMotion, I can do all these things that we require a more expensive shared storage, you know, SAN device. 00:13:17.119 --> 00:13:17.479 All right. 00:13:18.000 --> 00:13:20.320 So, here we're seeing we have a bunch of VMs. 00:13:20.359 --> 00:13:22.080 The VMs live on vSAN. 00:13:22.559 --> 00:13:24.919 vSAN, this looks like vSAN. 00:13:24.960 --> 00:13:30.679 You don't, you won't see that, oh, well, this VM lives on this host, and that's a copy here and here. 00:13:31.080 --> 00:13:37.080 You can dig in and get that information, but when you just look at it, you'll see a data store and you'll see a VM on it. 00:13:37.440 --> 00:13:43.559 And just from that, you know, regular, this initial view, you're not going to see all the hosts it's on and things like that. 00:13:43.599 --> 00:13:45.919 But you can obviously dig in and get information about it. 00:13:46.440 --> 00:13:48.960 So, we're going to have that vSAN. 00:13:48.960 --> 00:13:54.559 We show the SSD, the SSD drive is going to be my cache disk, and I have regular hard disk. 00:13:54.919 --> 00:13:56.280 That's my disk group. 00:13:56.760 --> 00:14:04.799 And then I'll have multiple disk groups, hopefully, probably multiple disk groups per host, but they all get put together and I create a data store from that. 00:14:05.719 --> 00:14:07.359 So, it's a pretty cool, it's a pretty cool concept. 00:14:07.400 --> 00:14:14.119 I remember when it first came out, I think it was like vSphere 5.5, I could be wrong, I think it was somewhere around 5.5. 00:14:14.479 --> 00:14:15.840 It was a really, it was 6, something like that. 00:14:15.880 --> 00:14:17.080 It was a really big deal. 00:14:17.080 --> 00:14:30.520 And honestly, like a lot of traditional SAN vendors, EMC, Hitachi, NetApp, a bunch of them, their sales plummeted that following year as people started looking at vSAN more closely. 00:14:30.559 --> 00:14:38.799 And they started looking at how can they get into the hyper-converged business because they saw their SAN business was going to start shrinking. 00:14:38.840 --> 00:14:44.159 And they're all still around, they all still sell SANs, but their business definitely took a hit. 00:14:44.280 --> 00:14:46.640 And I know that because I worked for our SAN vendor during that time. 00:14:48.080 --> 00:14:53.359 So, local storage design, this is a local disk on a host. 00:14:53.400 --> 00:14:56.599 So, again, I have my ESXi host that's running the VM. 00:14:56.960 --> 00:14:59.119 That VM has that VMDK file. 00:14:59.400 --> 00:15:03.880 That VMDK file is going to be written on a VMFS volume. 00:15:04.080 --> 00:15:09.080 That VMFS volume is on a disk that's on that host, that local attached disk. 00:15:09.640 --> 00:15:10.000 All right. 00:15:10.239 --> 00:15:15.520 So, the ESXi does support a lot of different drives than what it used to. 00:15:15.520 --> 00:15:17.640 When it first came out, it only supported SCSI drives. 00:15:18.000 --> 00:15:20.479 Then they added IDE drives. 00:15:20.520 --> 00:15:27.960 And then they support SAS, they support SATA, they even now support USB devices, not for production VMs and things like that, but they support USB. 00:15:28.000 --> 00:15:29.400 They didn't for a long time. 00:15:29.960 --> 00:15:43.760 So, we are able to connect to external storage devices like SAS and SATA storage devices, and they can be treated like they're local internal storage on those machines. 00:15:43.760 --> 00:15:50.719 We can also have SCSI devices or, you know, SATA device, SAS devices in that machine as well, in that box. 00:15:51.679 --> 00:15:53.599 So, examples of some simple storage design. 00:15:53.599 --> 00:15:56.359 So, again, your ESXi host is running your VM. 00:15:56.400 --> 00:16:01.960 The VM is on a SCSI disk that's formatted as a VMFS, and it has that VMDK file. 00:16:02.000 --> 00:16:04.640 VMDK is just one file of many. 00:16:04.919 --> 00:16:09.359 We talk about that with disks the most often because that is what is that virtual disk for the VM. 00:16:09.640 --> 00:16:14.919 But the VM also has, you know, VMX files, and it has swap files, and it has a lot of different files associated with it. 00:16:15.400 --> 00:16:18.799 All of them are going to live on that VMFS datastore with that VM. 00:16:22.039 --> 00:16:23.880 So, storage characteristics. 00:16:23.919 --> 00:16:28.880 So, once you create a block device, you're going to want to get some information about that block device, right? 00:16:29.119 --> 00:16:30.039 So, you're going to give it a name. 00:16:30.039 --> 00:16:31.520 You want to know what the name is. 00:16:31.760 --> 00:16:33.880 You'll have an identifier. 00:16:33.919 --> 00:16:35.359 It's going to be a unique identifier. 00:16:35.520 --> 00:16:42.119 Your universally unique identifier needs to be unique to the device, but you're going to want it to be the same to all the ESXi hosts. 00:16:42.119 --> 00:16:44.000 They're all going to see it with the same name. 00:16:45.119 --> 00:16:46.080 Operational state. 00:16:46.280 --> 00:16:48.000 So, is it attached or is it detached? 00:16:48.520 --> 00:16:49.599 The LUN number. 00:16:49.640 --> 00:16:54.599 You want your LUNs to all be seen by your ESXi host with the same LUN number. 00:16:54.880 --> 00:16:58.559 If it's LUN 5 on one host, you want it to be LUN 5 on all the hosts. 00:16:58.599 --> 00:17:04.119 You want all the identifiers for your disks to be the same across all your hosts. 00:17:04.160 --> 00:17:12.839 Because if a VM needs to move from one host to another or be picked up from one host to another, like, for example, in an HA situation, you want the host to know where to find it. 00:17:13.280 --> 00:17:16.119 And so, you want those identifiers to always be the same. 00:17:16.599 --> 00:17:17.920 So, what type of device? 00:17:17.959 --> 00:17:18.760 Is it flash? 00:17:18.800 --> 00:17:20.760 Is it a hard disk drive, meaning a spinning disk? 00:17:20.839 --> 00:17:23.680 Is it a CD-ROM drive or something like that? 00:17:25.920 --> 00:17:29.719 Again, if it is a disk versus like a CD-ROM drive, what kind of disk is it? 00:17:29.760 --> 00:17:30.880 Is it flash or hard disk? 00:17:31.839 --> 00:17:32.479 Transport. 00:17:32.479 --> 00:17:33.839 So, what transport protocol are you using? 00:17:33.839 --> 00:17:34.719 Is it a fiber channel? 00:17:34.719 --> 00:17:35.520 Is it iSCSI? 00:17:35.520 --> 00:17:37.479 Are you using iSCSI, the software initiator? 00:17:37.520 --> 00:17:38.560 How are you connecting to it? 00:17:39.359 --> 00:17:39.920 Capacity. 00:17:39.920 --> 00:17:40.680 How big is it? 00:17:40.680 --> 00:17:42.040 Who owns it? 00:17:42.040 --> 00:17:44.439 By owner, they mean the plug-in that's managing it. 00:17:44.719 --> 00:17:53.560 So, it could be a native plug-in for the ESXi host or it could be a third-party plug-in that's managing the access to that disk device, that LUN. 00:17:54.439 --> 00:17:55.400 Hardware acceleration. 00:17:55.439 --> 00:17:57.680 Does this device support hardware acceleration? 00:17:57.680 --> 00:18:05.599 Meaning, does the storage array support vSphere APIs for managing the disk? 00:18:05.599 --> 00:18:15.079 And by hardware acceleration, we're saying we want to offload tasks from the host to the hardware to the storage array to make things go faster. 00:18:15.439 --> 00:18:24.800 So, for example, it used to be like back in the 3, 5 days and 4 that, let's say, I have a hard disk and I want to make a copy of that. 00:18:25.319 --> 00:18:33.680 I could just copy it on the ESXi host and the ESXi host would read the block and write the block and read the blocks and write the blocks all over your network. 00:18:34.239 --> 00:18:42.319 Now, what it can do is it can just tell the storage array, make a copy of that and make a copy of it from this LUN to that LUN if both LUNs are on the same storage array. 00:18:42.719 --> 00:18:53.119 Or if you want to create a new virtual disk, this is probably the most common reasons or times you'll see this, is when you're creating a new virtual disk, you can either make it thin provisions, 00:18:53.119 --> 00:18:55.439 which means it'll just be a really simple, empty file. 00:18:55.439 --> 00:18:57.920 And as you write to it, the file grows, grows, grows, grows. 00:18:58.479 --> 00:19:07.359 So, in that scenario, every time the file grows, we're going to put a lock on that virtual file. 00:19:07.520 --> 00:19:15.359 We used to have to write a lock to the entire LUN, but VMware improved that and now we can just lock files and not have to lock the entire LUN. 00:19:15.680 --> 00:19:27.520 The reason why that's important is because if I had two different virtual machines on the same LUN, only one of them can grow at a time because there'd be a lock on it, I'd grow that file, and then the lock would be released. 00:19:27.520 --> 00:19:33.520 And then another host might need to put a lock on it, grow a file, the file's done, then that lock could be released. 00:19:33.520 --> 00:19:40.239 But only one device can have a lock on a storage device like the LUN at a time. 00:19:41.199 --> 00:19:46.000 So, now we put locks at the file level and we offload that to the storage array. 00:19:46.000 --> 00:19:52.719 The storage array can create a lock, grow a file, release a lock much faster internally than the host is going to do it over the network. 00:19:53.280 --> 00:19:57.520 So, we can offload things like that, copying files, growing files. 00:19:57.520 --> 00:20:05.199 If we have a thick provisioned file, then that means when we create the virtual disk, we're going to create it all in one time, all one great big file. 00:20:05.760 --> 00:20:07.680 It's all allocated at the beginning. 00:20:07.680 --> 00:20:14.719 And if we want to make it either zeroed, that means we want to zero out all the blocks on that virtual disk when we create it. 00:20:14.719 --> 00:20:23.599 The SXI host used to go in and create a 700-gig file and then write 700 gigs of zeros, and it would take a long time. 00:20:23.599 --> 00:20:31.680 Now, if we have hardware acceleration enabled with our SAN vendor, the SXI host can communicate to the SAN and say, 00:20:31.680 --> 00:20:37.599 on this data store, create this file, make it this size, and zero out all the blocks. 00:20:37.599 --> 00:20:40.719 And now the host is done. The host is no longer worried about that. 00:20:40.719 --> 00:20:44.160 The SAN is taking care of it, and the SAN will let it know, I completed that task. 00:20:44.160 --> 00:20:47.359 You go back to doing what you were doing, and the host can just keep trucking along. 00:20:47.359 --> 00:20:48.560 So, that's hardware acceleration. 00:20:48.560 --> 00:20:56.719 We're offloading tasks the host used to have to do itself to the storage array to speed up the performance of the VMs and the ESXi hosts. 00:20:57.680 --> 00:20:58.880 Sector format. 00:20:58.880 --> 00:21:03.119 So, sector format is talking about – there's different types of sectors. 00:21:03.119 --> 00:21:06.560 And so, you can see the sectors – basically, you're talking about the size of the sector. 00:21:07.119 --> 00:21:12.880 And with disks getting so huge and LUNs getting so huge and, you know, storage getting so massive, 00:21:13.439 --> 00:21:18.719 it used to be that we could only write one file per sector, right? 00:21:19.439 --> 00:21:22.719 But now what we're able to do is we create larger sectors. 00:21:22.719 --> 00:21:28.959 Our sectors are always 4K now, but we can break that sector up into smaller virtual pages, 00:21:28.959 --> 00:21:31.520 and I can write a file to a virtual page. 00:21:31.520 --> 00:21:39.199 So, I don't have to think of a 4K sector to write a simple little, you know, file that only has, 00:21:39.199 --> 00:21:42.800 you know, a small bit of text and bits of information in it. 00:21:42.800 --> 00:21:48.640 So, we can break it up, and we can write multiple small files inside those sectors, right? 00:21:48.640 --> 00:21:52.400 So, basically, we can have these little virtual pages inside of a sector. 00:21:52.400 --> 00:21:54.319 So, it looks like they're small sectors. 00:21:54.319 --> 00:21:59.119 The reason why that matters is because you only have so many sectors on a disk. 00:21:59.119 --> 00:22:02.800 And so, if you have small sectors, that means they're the maximum size that your disk can be. 00:22:02.800 --> 00:22:05.760 If you have larger sectors and the same number, 00:22:05.760 --> 00:22:08.880 obviously, your disk can be much, much larger now, right? 00:22:08.880 --> 00:22:10.479 So, that's what we're talking about. 00:22:11.920 --> 00:22:16.000 Partition format – is it an MBR, GUID, or GPT? 00:22:17.280 --> 00:22:19.599 Is it a primary or logical partition? 00:22:19.599 --> 00:22:21.839 Used to be you can only create one primary partition. 00:22:21.839 --> 00:22:22.239 That was it. 00:22:22.239 --> 00:22:24.560 Now, you know, VMware gives us all these options. 00:22:24.560 --> 00:22:28.800 But best practice is you want to create as few partitions as possible. 00:22:28.800 --> 00:22:31.199 If you have multiple partitions, you want them for one data store. 00:22:31.199 --> 00:22:33.520 So, like, you need to add an extent to a data store. 00:22:33.520 --> 00:22:34.959 So, maybe you created a LUN. 00:22:34.959 --> 00:22:37.199 The LUN was 500 gigs. 00:22:37.199 --> 00:22:38.880 The data store is starting to fill up. 00:22:38.880 --> 00:22:42.239 So, you can increase the size of the LUN on the storage array. 00:22:42.239 --> 00:22:44.000 That doesn't increase your file system. 00:22:44.000 --> 00:22:47.439 And I can go ahead and add an extent to that file system. 00:22:47.439 --> 00:22:49.439 So, now it's a terabyte, right? 00:22:49.839 --> 00:22:56.239 But the whole entire LUN is only controlled by one VMFS data store. 00:22:58.000 --> 00:23:02.959 Multipathing policies – so, multipathing policies is basically 00:23:02.959 --> 00:23:04.719 VMware allows some different policies. 00:23:04.719 --> 00:23:08.160 There's ones where we can do – which is kind of like a very common one 00:23:08.160 --> 00:23:10.079 most people try to do – is a round-robin. 00:23:10.079 --> 00:23:13.680 So, if you have multiple data paths, it sends packets down one path, 00:23:13.680 --> 00:23:15.520 and then packets down the next, and packets down the next, 00:23:15.520 --> 00:23:16.719 and packets down the next. 00:23:16.719 --> 00:23:19.359 And this keeps going around and around on those paths. 00:23:20.079 --> 00:23:23.199 Because it can only send so many before it has to get an acknowledgment back. 00:23:23.199 --> 00:23:25.599 So, while I'm waiting for the acknowledgment back, I'll use the next path. 00:23:25.599 --> 00:23:28.319 And I'll wait for an acknowledgment back, and I'll use the next path. 00:23:28.319 --> 00:23:30.880 Otherwise, I have to send down a path, and I'll wait, 00:23:30.880 --> 00:23:32.239 got an acknowledgment, send some more, 00:23:32.239 --> 00:23:33.920 got an acknowledgment, send some more. 00:23:33.920 --> 00:23:37.040 If that path goes down, I can fail over to a backup path. 00:23:37.680 --> 00:23:40.400 But I then only have, again, that one path. 00:23:40.400 --> 00:23:44.479 So, round-robin gives you more paths, gives you more bandwidth, okay? 00:23:44.479 --> 00:23:55.280 So, we've covered some basic vocabulary of VMware storage, ESXi storage. 00:23:55.280 --> 00:23:57.280 We covered, like, what is a SAN? 00:23:57.280 --> 00:23:58.880 What is a storage area network? 00:23:58.880 --> 00:24:02.079 What is a network-attached storage? 00:24:02.079 --> 00:24:03.599 We covered data stores. 00:24:03.599 --> 00:24:04.800 We covered file systems.