WEBVTT 00:00:00.000 --> 00:00:02.940 Welcome back to vSphere 8 in the real world. 00:00:02.940 --> 00:00:08.300 Now we're going to discuss RDMs, our raw device maps, and vVols. 00:00:08.300 --> 00:00:17.299 So, a raw device map is basically a way of taking a LUN that's from your storage, your storage network, your SAM, 00:00:17.299 --> 00:00:28.240 and you can present that LUN or present it to the virtual machine in such a way that when the VM goes to write to its virtual disk, 00:00:28.240 --> 00:00:31.600 it actually gets written to the LUN that's on that SAM. 00:00:31.600 --> 00:00:36.840 So, what will happen is when you create a raw device map, the ESXi host, when it creates the virtual machine, 00:00:36.840 --> 00:00:42.200 it's also going to create a VMDK file, but the VMDK file only is the descriptor file. 00:00:42.200 --> 00:00:46.439 It doesn't also create that VMDK file where all the data is written to. 00:00:46.439 --> 00:00:55.599 It just creates the VMDK file that describes the virtual disk, and it says the virtual disk is a raw device map that points to the LUN on the SAM. 00:00:55.660 --> 00:01:02.340 Now, the virtual machine doesn't know it's a LUN on the SAM, but when it writes, it writes to disk, 00:01:02.340 --> 00:01:09.440 and what happens is when the virtual machine says, okay, we're going to format this virtual – this disk as NTFS, 00:01:09.440 --> 00:01:15.900 the LUN on the SAM gets formatted as NTFS, and when the virtual machine, you know, goes to write a file, 00:01:15.900 --> 00:01:23.559 that file is written two blocks on the LUN, and it's not inside of the VMDK file. 00:01:23.559 --> 00:01:25.620 There's two different types of raw device maps. 00:01:25.620 --> 00:01:33.760 There's virtual mode and there's physical mode, and in virtual mode, what happens is when the virtual machine issues a SCSI command to write to its disk, 00:01:33.760 --> 00:01:41.199 the hypervisor still goes in and translates that and interprets those SCSI commands and sends them to the SAM, 00:01:41.199 --> 00:01:47.459 and in physical compatibility mode, they get written directly the way that the virtual machine says to write them. 00:01:47.459 --> 00:01:52.760 So, what that means is that when we're in virtual compatibility mode, we can do snapshots, 00:01:52.760 --> 00:01:57.019 and when we're in physical compatibility mode, we can't snapshot that disk. 00:01:57.019 --> 00:02:04.959 So, if my virtual machine has a C drive, the C drive is a traditional VMDK file, and a D drive, and the D drive is a raw device map, 00:02:04.959 --> 00:02:12.619 I go to snapshot the VM, the C drive would get snapshotted, but that raw device map that is in physical compatibility mode, it wouldn't. 00:02:12.619 --> 00:02:16.020 But if it was in virtual compatibility mode, it would, right? 00:02:16.020 --> 00:02:24.320 So, that's the difference between the virtual compatibility mode and the physical compatibility mode is we cannot snapshot in physical compatibility mode, right? 00:02:24.320 --> 00:02:32.520 But we can present that virtual machine with a disk that actually is on the SAM, and really the benefit isn't so much to the VM, 00:02:32.520 --> 00:02:39.679 the benefit is to the SAM because the SAM can now see the file system of the virtual machine and see the files of that virtual machine. 00:02:39.679 --> 00:02:47.639 So, it might help you if you have like a plug-in for your SAM for Exchange, and this is an Exchange server or something like that. 00:02:47.639 --> 00:02:51.419 That's the benefit there. 00:02:51.419 --> 00:02:52.139 So, VBAL. 00:02:52.139 --> 00:02:56.080 So, VBAL is relatively newer-ish. 00:02:56.080 --> 00:03:00.940 It's been around since like, I think it was version 6, I want to say, VBAL came out in. 00:03:00.940 --> 00:03:02.820 Might have been 5.5, but I think it was 6. 00:03:02.820 --> 00:03:12.320 And VBAL, basically, it abstracts the storage layer even further in your vSphere environment. 00:03:12.320 --> 00:03:23.460 So, before, with, you know, VMFS data stores and more traditional, the way the ESXi host accesses storage before VBALs, we would go in and we'd create a LUN, 00:03:23.460 --> 00:03:31.160 and we'd present that LUN to the ESXi host, and the ESXi host could then go in and format it with VMFS and start writing files to it. 00:03:31.160 --> 00:03:41.460 And I might have one, you know, large partition formatted as VMFS, and then all these files live on that physical container of that LUN on that host. 00:03:41.460 --> 00:03:47.960 With VBALs, we no longer have a VMFS file system, and we don't even have a partition. 00:03:47.960 --> 00:03:56.919 What happens is we take a pool of storage, and we present that storage to the ESXi host. 00:03:56.919 --> 00:04:07.679 And then, when the ESXi host, say, create a virtual machine, the SAN creates a bunch of small logical containers in that VBAL to put the files in for that virtual machine. 00:04:07.679 --> 00:04:16.160 And when we go to create another VM, we have a bunch of other logical containers, but we don't actually have traditional partitions in a traditional file system. 00:04:16.160 --> 00:04:18.760 All that is handled by the SAN. 00:04:18.760 --> 00:04:25.619 And actually, a lot of the workload is offloaded from the host onto the SAN when we use VBALs. 00:04:25.619 --> 00:04:30.119 So, when we go in and we say we want to create a virtual disk, we tell the SAN to create it. 00:04:30.119 --> 00:04:32.160 The SAN knows how to create our virtual disk. 00:04:32.160 --> 00:04:34.920 It knows how to create, you know, these files for the VMs. 00:04:34.920 --> 00:04:39.980 Of course, the host has to tell it what to write in the file, so not everything can be offloaded like that. 00:04:39.980 --> 00:04:47.859 But basically, a lot of the workload for managing, you know, the blocks being written and things like that, it's all being done by the SAN in that VBAL now. 00:04:47.859 --> 00:04:53.179 We're no longer having a traditional file system, and the host is saying, write this and write that. 00:04:53.179 --> 00:04:54.480 We can offload a bunch of tasks. 00:04:54.480 --> 00:04:56.019 We want to reclaim space. 00:04:56.019 --> 00:04:59.019 We can offload all that to the SAN as they reclaim that space. 00:04:59.019 --> 00:05:07.739 But we need to have a SAN that supports the VAI, right, APIs for vSphere and supports VBALs, right? 00:05:07.739 --> 00:05:11.179 And the whole VAI and VBALs kind of are synonymous there. 00:05:11.179 --> 00:05:20.980 So, you need to have, you know, your VASA provider for your VAI offloading other VBALs, and then the SAN manages all that for us. 00:05:20.980 --> 00:05:35.679 What that also means, a really cool thing, is that before, if we were to say we want to do replication, for example, or we want to do deduping, or we want to do an encryption, I would encrypt that entire LUN, and all the VMs on there became encrypted. 00:05:35.679 --> 00:05:41.040 Or I would dedupe an entire LUN, and all the VMs on there were deduped. 00:05:41.040 --> 00:05:49.119 I could also, you know, if I say I want to do replication, I would replicate an entire LUN to another SAN, and all the VMs on that LUN became replicated. 00:05:49.119 --> 00:05:57.619 So, the SAN admin would say what LUNs had encryption, which LUNs had deduped, which LUNs were replicated. 00:05:57.619 --> 00:06:01.420 All that kind of stuff was all managed by the SAN admin. 00:06:01.420 --> 00:06:18.019 Now, what the SAN admin does is presents VBAL to the ESXi environment, to the vSphere environment, and now the vSphere admin says I want this virtual machine to be replicated, or I want this virtual machine to be, you know, encrypted. 00:06:18.019 --> 00:06:24.420 And it's all done at the VM level, because I don't have LUNs and large file systems I'm managing a bunch of VMs on. 00:06:24.420 --> 00:06:27.760 I'm managing individual VMs, and I can create a storage policy. 00:06:27.760 --> 00:06:41.220 If I supply the storage policy to a VM, then the APIs from the ESXi host communicate to the SAN, tell the SAN, oh, by the way, that particular VM is going to be replicated. 00:06:41.220 --> 00:06:44.720 Those files that represent that VM, those get replicated. 00:06:44.720 --> 00:06:46.980 Oh, and those files need to be encrypted. 00:06:46.980 --> 00:06:48.480 So, you can create storage policies. 00:06:48.480 --> 00:06:56.179 Now, I, the vSphere admin, I decide what's encrypted, what's replicated, what gets deduped, all that kind of stuff. 00:06:56.179 --> 00:07:01.079 All that's managed by me, the ESXi admin, not the SAN admin anymore. 00:07:01.079 --> 00:07:05.579 And it's not at a LUN level, it's on a VM by VM level. 00:07:05.579 --> 00:07:11.179 So, it makes for a much more granular level of control and the controls with the vSphere admin. 00:07:11.179 --> 00:07:15.579 So, it's a really cool way of doing storage. 00:07:15.579 --> 00:07:16.880 So, replication again. 00:07:16.880 --> 00:07:26.880 So, I, the vSphere admin, create policies that I can say I want replication done, and I can create different types of policies. 00:07:26.880 --> 00:07:28.779 I can create policies for different schedules. 00:07:28.779 --> 00:07:32.179 I can create policies for different frequencies. 00:07:32.179 --> 00:07:34.179 I can say what I want the target to be. 00:07:34.179 --> 00:07:41.079 Right now, of course, in order for replication to occur from one target to another, the SAN admin has to configure that replication. 00:07:41.079 --> 00:07:45.980 It has to configure SAN A to replicate to SAN B, and, you know, things like that. 00:07:45.980 --> 00:07:56.179 But if the SAN admin has configured SAN A to replicate to SAN B and to SAN C, I can create a storage policy and say this VM I want replicated from SAN A to B. 00:07:56.179 --> 00:07:58.980 And this one I want replicated from SAN A to SAN C. 00:07:58.980 --> 00:08:02.179 And so, maybe I have these SANs in different geographic locations. 00:08:02.179 --> 00:08:06.779 And then I can say, okay, this is my primary data center that I'm running whatever workloads on. 00:08:06.779 --> 00:08:12.579 But if there's a failure here, I want this VM to start up on SAN B that is in the same data center. 00:08:12.579 --> 00:08:20.880 But if this other VM fails, I want it to start up from SAN C, which maybe I have in a different data center someplace else. 00:08:20.880 --> 00:08:26.380 And so, I'm going to offload that workload someplace else if, you know, if there's a failure over here. 00:08:26.380 --> 00:08:27.079 Right. Okay. 00:08:27.079 --> 00:08:29.079 So, I can set, you know, targets. 00:08:29.079 --> 00:08:33.280 I can set the secondary site, which might be based upon where the SAN is located. 00:08:33.280 --> 00:08:35.280 And then deletion or retention policies. 00:08:35.280 --> 00:08:36.979 How long I want to keep those things for. 00:08:36.979 --> 00:08:47.380 I, as a vSphere admin, can create policies for those things and then tell the SAN what I want for this VM, not for the data store, for the VM. 00:08:47.380 --> 00:08:51.580 So, it's a really, really cool way of doing that. 00:08:51.580 --> 00:08:59.780 There is wizards we can use for creating replication policies, right, for creating these different storage-based policies. 00:08:59.780 --> 00:09:00.380 Right. 00:09:00.380 --> 00:09:00.979 I can go in. 00:09:00.979 --> 00:09:02.080 I can create rules. 00:09:02.280 --> 00:09:08.679 I want to add a rule and just build a rule saying I want it to be, you know, encrypted. 00:09:08.679 --> 00:09:12.780 I want it to be replicated from SAN A to SAN, you know, B. 00:09:12.780 --> 00:09:19.780 What I can also do is if I'm expecting that when it replicates a SAN B, there's a failure, it runs on SAN B. 00:09:19.780 --> 00:09:26.479 Well, then what happens if I wanted to replicate back from SAN B to SAN A in case it's recovered? 00:09:26.479 --> 00:09:28.179 SAN A comes back up again. 00:09:28.179 --> 00:09:34.179 I want a policy that says if it's running on SAN B, I want it to replicate back to SAN A also. 00:09:34.179 --> 00:09:37.880 I can create replication policies in both directions at a VM level. 00:09:37.880 --> 00:09:40.080 That's a pretty cool thing that you can do there, too. 00:09:40.080 --> 00:09:41.179 Right. 00:09:41.179 --> 00:09:45.580 So, data store services, you're not going to just find it at the data store. 00:09:45.580 --> 00:09:54.580 You're going to find it at the VM level, and then we can specify, but there are services that might be more commonly associated with your data stores. 00:09:54.580 --> 00:10:03.179 And we can create these custom policies, again, for the VMs, and we can push them back and forth from the vSphere environment to our SANs. 00:10:03.179 --> 00:10:07.080 And then the SAN can also expose what things it's capable of doing to the vSphere host. 00:10:07.080 --> 00:10:09.979 So, it can tell you if the VM is compliant or not. 00:10:09.979 --> 00:10:17.280 Because maybe you said I want to replicate from SAN A to SAN B, but replication is not configured from A to D. 00:10:17.280 --> 00:10:20.979 Then you'll say this is not in compliance because I don't have replication to that SAN. 00:10:20.979 --> 00:10:25.080 I only have replication to SAN B and C, and you chose one that doesn't work. 00:10:25.080 --> 00:10:28.880 Then your VM would be out of compliance. 00:10:28.880 --> 00:10:37.380 So, let's go ahead and jump over to our demo environment, and I will walk you through configuring some vBalls and some vBall policies. 00:10:37.380 --> 00:10:39.580 So, here we are in our vSphere environment. 00:10:39.580 --> 00:10:42.280 So, I'm going to go ahead and expand my vCenter. 00:10:42.280 --> 00:10:45.380 I'm going to go ahead and go to my cluster. 00:10:45.380 --> 00:10:47.880 I'm sorry, this data center, and then my cluster. 00:10:47.880 --> 00:10:55.780 In my cluster, I'm going to go ahead and go to storage and say new data store. 00:10:55.780 --> 00:11:00.479 I'm going to do a vBall data store and not a VMFS or NFS data store. 00:11:00.479 --> 00:11:03.580 I'm going to go ahead and say next. 00:11:03.580 --> 00:11:16.979 I have to give my vBall data store a name, and I'm going to call this vBall. 00:11:16.979 --> 00:11:20.179 And say next. 00:11:20.179 --> 00:11:24.479 Now, I need to choose which hosts I want to be able to see this. 00:11:24.479 --> 00:11:28.880 So, I'm going to choose these hosts, these four hosts. 00:11:28.880 --> 00:11:39.880 Say next, and finish. 00:11:39.880 --> 00:11:43.979 I see my task has already been completed. 00:11:43.979 --> 00:11:57.380 So, if I were to go to my storage here, here is that vBall app 01 that I created. 00:11:57.380 --> 00:11:59.979 A little bit different name than the other ones. 00:11:59.979 --> 00:12:08.280 And I could scroll down here and see it's from my peer storage. 00:12:08.280 --> 00:12:13.380 I see the endpoint protocols, which mean endpoint protocols are simply work from the 00:12:13.380 --> 00:12:18.280 different endpoints that are able to be recognized here. 00:12:18.280 --> 00:12:23.380 What they're talking about with the endpoint protocol is, remember, we're not using fiber 00:12:23.380 --> 00:12:25.380 channel or iSCSI, right? 00:12:25.380 --> 00:12:26.679 We're doing vBalls. 00:12:26.679 --> 00:12:32.179 And with vBalls, we're not sending SCSI commands over the cable to the storage array. 00:12:32.179 --> 00:12:35.479 All the communication is done through APIs, right? 00:12:35.479 --> 00:12:43.179 So, the protocol endpoints are the iSCSI host, where does the API end, and it ends with the 00:12:43.179 --> 00:12:49.479 storage array pointing at the volume or the vBall that it wants this work done on. 00:12:49.479 --> 00:12:53.380 So, when they talk about a protocol endpoint, they're talking about the API protocol, but 00:12:53.380 --> 00:12:59.179 the host used to communicate to the SAN, and it's going to end on one of these virtual 00:12:59.179 --> 00:13:01.479 volumes that we have configured here. 00:13:01.580 --> 00:13:05.679 So, that's what they talk about, or mean when they talk about a protocol endpoint. 00:13:05.679 --> 00:13:09.080 We can go to our storage array. 00:13:09.080 --> 00:13:10.679 Let me go ahead and open a new tab. 00:13:18.080 --> 00:13:20.679 Go ahead and log in to the storage array. 00:13:25.979 --> 00:13:30.380 And let's go to storage, go to pods. 00:13:30.380 --> 00:13:35.179 And we can see the different storage arrays – I'm sorry, the different virtual volumes 00:13:35.179 --> 00:13:37.380 that we have configured on this storage array. 00:13:37.380 --> 00:13:40.679 And this happens to be storage array A, right? 00:13:40.679 --> 00:13:43.380 So, we can go to one of these virtual volumes. 00:13:45.380 --> 00:13:49.880 Let's go ahead and say, show our protocol endpoints. 00:13:49.880 --> 00:13:53.880 And now what is shown us here is this host group. 00:13:53.880 --> 00:13:57.979 And if I click on host group – I'm sorry, my apologies. 00:13:57.979 --> 00:14:01.979 That was the volume that was in there. 00:14:01.979 --> 00:14:05.979 When I click on the volume from here, I can see the host group. 00:14:08.280 --> 00:14:12.580 And the host group has all the hosts that are associated with that. 00:14:12.580 --> 00:14:18.979 So, again, under pods, I can choose the volume. 00:14:18.979 --> 00:14:24.780 And if I say I want to see my protocol endpoints, it's going to show me the volume, right, 00:14:24.780 --> 00:14:27.179 that's associated here. 00:14:27.179 --> 00:14:30.679 Then my host group, and here are my hosts. 00:14:32.780 --> 00:14:38.080 So, these are all the hosts that are able to communicate with that protocol endpoint, 00:14:38.080 --> 00:14:40.880 the protocol endpoint being the volume, right? 00:14:40.880 --> 00:14:47.179 The protocol endpoint being the volumes that we have configured for the ESXi host to talk to. 00:14:48.380 --> 00:14:48.880 All right. 00:14:48.880 --> 00:14:54.380 So, just, again, I think this guy said that wrong the first time. 00:14:54.380 --> 00:14:58.080 I want to make sure I'm really clear that the protocol endpoints are – where does 00:14:58.080 --> 00:15:00.080 the ESXi host communication stop? 00:15:00.080 --> 00:15:05.080 The ESXi host communication talking to the storage array, the endpoint for that is that 00:15:05.080 --> 00:15:06.080 virtual volume. 00:15:06.080 --> 00:15:10.880 That is where the API calls are going to be targeting to, saying what volume we want this 00:15:10.880 --> 00:15:12.479 work done on. 00:15:12.479 --> 00:15:17.080 And then from there, we can see what hosts are allowed to communicate to that virtual 00:15:17.080 --> 00:15:19.679 volume or that protocol endpoint, right? 00:15:19.679 --> 00:15:25.979 And hosts 1, 2, 3, and 4, they're going to communicate to the pure storage array to that 00:15:25.979 --> 00:15:28.080 volume. 00:15:28.080 --> 00:15:34.280 The other way of looking at those endpoints, those protocol endpoints, is when we click 00:15:34.280 --> 00:15:43.479 on this region or this cluster at the data stores, these are also the protocol endpoints. 00:15:43.479 --> 00:15:50.179 So, those are the same vVols that we saw in our storage array, our pure storage storage 00:15:50.179 --> 00:15:52.780 array, and that is what they're talking to, right? 00:15:52.780 --> 00:15:56.280 They're talking to the – through the storage array and saying the communication is pointing 00:15:56.280 --> 00:15:58.280 to one of these vVols. 00:16:05.080 --> 00:16:12.280 If I go to here and go to pure storage, because I have the pure storage, you know, basically 00:16:12.280 --> 00:16:16.880 the API plug-in configured, I can see the storage arrays that I'm configured to talk 00:16:16.880 --> 00:16:17.880 to. 00:16:17.880 --> 00:16:20.880 Here, pure storage site A is the name of the array. 00:16:20.880 --> 00:16:22.080 There's the URL for it. 00:16:22.080 --> 00:16:25.179 I can add additional ones. 00:16:25.179 --> 00:16:29.580 I can also edit the ones that are here, and you probably aren't going to really very often 00:16:29.580 --> 00:16:32.880 change that, but this is the name of the array. 00:16:32.880 --> 00:16:37.179 Here's the URL for the communication to go to, and from here, I can also remove those 00:16:37.179 --> 00:16:41.179 storage arrays. 00:16:41.179 --> 00:16:47.179 So, there you can see basically how easy it is to – sorry, let's do this again. 00:16:47.179 --> 00:16:52.179 So, you can see there how easy it is to add a vVol volume to your vSphere environment. 00:16:52.179 --> 00:16:57.179 This entire demo has been done in VMware's hands-on lab environment. 00:16:57.179 --> 00:17:03.380 You can go to hol.vmware.com and log in with your own VMware account, and from there, you 00:17:03.380 --> 00:17:09.579 can go through this whole demo yourself and configure the storage array, create the vVols, 00:17:09.579 --> 00:17:11.780 and configure replication and create VMs. 00:17:11.780 --> 00:17:14.979 It's a very detailed, like, 90-minute lab you can go through. 00:17:14.979 --> 00:17:20.579 I encourage you to go to hol.vmware.com and log in and do this lab yourself.