Welcome back to vSphere 8 in the real world.
Now we're going to discuss RDMs, our raw device maps, and vVols.
So, a raw device map is basically a way of taking a LUN that's from your storage, your storage network, your SAM,
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,
it actually gets written to the LUN that's on that SAM.
So, what will happen is when you create a raw device map, the ESXi host, when it creates the virtual machine,
it's also going to create a VMDK file, but the VMDK file only is the descriptor file.
It doesn't also create that VMDK file where all the data is written to.
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.
Now, the virtual machine doesn't know it's a LUN on the SAM, but when it writes, it writes to disk,
and what happens is when the virtual machine says, okay, we're going to format this virtual – this disk as NTFS,
the LUN on the SAM gets formatted as NTFS, and when the virtual machine, you know, goes to write a file,
that file is written two blocks on the LUN, and it's not inside of the VMDK file.
There's two different types of raw device maps.
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,
the hypervisor still goes in and translates that and interprets those SCSI commands and sends them to the SAM,
and in physical compatibility mode, they get written directly the way that the virtual machine says to write them.
So, what that means is that when we're in virtual compatibility mode, we can do snapshots,
and when we're in physical compatibility mode, we can't snapshot that disk.
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,
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.
But if it was in virtual compatibility mode, it would, right?
So, that's the difference between the virtual compatibility mode and the physical compatibility mode is we cannot snapshot in physical compatibility mode, right?
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,
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.
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.
That's the benefit there.
So, VBAL.
So, VBAL is relatively newer-ish.
It's been around since like, I think it was version 6, I want to say, VBAL came out in.
Might have been 5.5, but I think it was 6.
And VBAL, basically, it abstracts the storage layer even further in your vSphere environment.
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,
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.
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.
With VBALs, we no longer have a VMFS file system, and we don't even have a partition.
What happens is we take a pool of storage, and we present that storage to the ESXi host.
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.
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.
All that is handled by the SAN.
And actually, a lot of the workload is offloaded from the host onto the SAN when we use VBALs.
So, when we go in and we say we want to create a virtual disk, we tell the SAN to create it.
The SAN knows how to create our virtual disk.
It knows how to create, you know, these files for the VMs.
Of course, the host has to tell it what to write in the file, so not everything can be offloaded like that.
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.
We're no longer having a traditional file system, and the host is saying, write this and write that.
We can offload a bunch of tasks.
We want to reclaim space.
We can offload all that to the SAN as they reclaim that space.
But we need to have a SAN that supports the VAI, right, APIs for vSphere and supports VBALs, right?
And the whole VAI and VBALs kind of are synonymous there.
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.
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.
Or I would dedupe an entire LUN, and all the VMs on there were deduped.
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.
So, the SAN admin would say what LUNs had encryption, which LUNs had deduped, which LUNs were replicated.
All that kind of stuff was all managed by the SAN admin.
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.
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.
I'm managing individual VMs, and I can create a storage policy.
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.
Those files that represent that VM, those get replicated.
Oh, and those files need to be encrypted.
So, you can create storage policies.
Now, I, the vSphere admin, I decide what's encrypted, what's replicated, what gets deduped, all that kind of stuff.
All that's managed by me, the ESXi admin, not the SAN admin anymore.
And it's not at a LUN level, it's on a VM by VM level.
So, it makes for a much more granular level of control and the controls with the vSphere admin.
So, it's a really cool way of doing storage.
So, replication again.
So, I, the vSphere admin, create policies that I can say I want replication done, and I can create different types of policies.
I can create policies for different schedules.
I can create policies for different frequencies.
I can say what I want the target to be.
Right now, of course, in order for replication to occur from one target to another, the SAN admin has to configure that replication.
It has to configure SAN A to replicate to SAN B, and, you know, things like that.
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.
And this one I want replicated from SAN A to SAN C.
And so, maybe I have these SANs in different geographic locations.
And then I can say, okay, this is my primary data center that I'm running whatever workloads on.
But if there's a failure here, I want this VM to start up on SAN B that is in the same data center.
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.
And so, I'm going to offload that workload someplace else if, you know, if there's a failure over here.
Right. Okay.
So, I can set, you know, targets.
I can set the secondary site, which might be based upon where the SAN is located.
And then deletion or retention policies.
How long I want to keep those things for.
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.
So, it's a really, really cool way of doing that.
There is wizards we can use for creating replication policies, right, for creating these different storage-based policies.
Right.
I can go in.
I can create rules.
I want to add a rule and just build a rule saying I want it to be, you know, encrypted.
I want it to be replicated from SAN A to SAN, you know, B.
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.
Well, then what happens if I wanted to replicate back from SAN B to SAN A in case it's recovered?
SAN A comes back up again.
I want a policy that says if it's running on SAN B, I want it to replicate back to SAN A also.
I can create replication policies in both directions at a VM level.
That's a pretty cool thing that you can do there, too.
Right.
So, data store services, you're not going to just find it at the data store.
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.
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.
And then the SAN can also expose what things it's capable of doing to the vSphere host.
So, it can tell you if the VM is compliant or not.
Because maybe you said I want to replicate from SAN A to SAN B, but replication is not configured from A to D.
Then you'll say this is not in compliance because I don't have replication to that SAN.
I only have replication to SAN B and C, and you chose one that doesn't work.
Then your VM would be out of compliance.
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.
So, here we are in our vSphere environment.
So, I'm going to go ahead and expand my vCenter.
I'm going to go ahead and go to my cluster.
I'm sorry, this data center, and then my cluster.
In my cluster, I'm going to go ahead and go to storage and say new data store.
I'm going to do a vBall data store and not a VMFS or NFS data store.
I'm going to go ahead and say next.
I have to give my vBall data store a name, and I'm going to call this vBall.
And say next.
Now, I need to choose which hosts I want to be able to see this.
So, I'm going to choose these hosts, these four hosts.
Say next, and finish.
I see my task has already been completed.
So, if I were to go to my storage here, here is that vBall app 01 that I created.
A little bit different name than the other ones.
And I could scroll down here and see it's from my peer storage.
I see the endpoint protocols, which mean endpoint protocols are simply work from the
different endpoints that are able to be recognized here.
What they're talking about with the endpoint protocol is, remember, we're not using fiber
channel or iSCSI, right?
We're doing vBalls.
And with vBalls, we're not sending SCSI commands over the cable to the storage array.
All the communication is done through APIs, right?
So, the protocol endpoints are the iSCSI host, where does the API end, and it ends with the
storage array pointing at the volume or the vBall that it wants this work done on.
So, when they talk about a protocol endpoint, they're talking about the API protocol, but
the host used to communicate to the SAN, and it's going to end on one of these virtual
volumes that we have configured here.
So, that's what they talk about, or mean when they talk about a protocol endpoint.
We can go to our storage array.
Let me go ahead and open a new tab.
Go ahead and log in to the storage array.
And let's go to storage, go to pods.
And we can see the different storage arrays – I'm sorry, the different virtual volumes
that we have configured on this storage array.
And this happens to be storage array A, right?
So, we can go to one of these virtual volumes.
Let's go ahead and say, show our protocol endpoints.
And now what is shown us here is this host group.
And if I click on host group – I'm sorry, my apologies.
That was the volume that was in there.
When I click on the volume from here, I can see the host group.
And the host group has all the hosts that are associated with that.
So, again, under pods, I can choose the volume.
And if I say I want to see my protocol endpoints, it's going to show me the volume, right,
that's associated here.
Then my host group, and here are my hosts.
So, these are all the hosts that are able to communicate with that protocol endpoint,
the protocol endpoint being the volume, right?
The protocol endpoint being the volumes that we have configured for the ESXi host to talk to.
All right.
So, just, again, I think this guy said that wrong the first time.
I want to make sure I'm really clear that the protocol endpoints are – where does
the ESXi host communication stop?
The ESXi host communication talking to the storage array, the endpoint for that is that
virtual volume.
That is where the API calls are going to be targeting to, saying what volume we want this
work done on.
And then from there, we can see what hosts are allowed to communicate to that virtual
volume or that protocol endpoint, right?
And hosts 1, 2, 3, and 4, they're going to communicate to the pure storage array to that
volume.
The other way of looking at those endpoints, those protocol endpoints, is when we click
on this region or this cluster at the data stores, these are also the protocol endpoints.
So, those are the same vVols that we saw in our storage array, our pure storage storage
array, and that is what they're talking to, right?
They're talking to the – through the storage array and saying the communication is pointing
to one of these vVols.
If I go to here and go to pure storage, because I have the pure storage, you know, basically
the API plug-in configured, I can see the storage arrays that I'm configured to talk
to.
Here, pure storage site A is the name of the array.
There's the URL for it.
I can add additional ones.
I can also edit the ones that are here, and you probably aren't going to really very often
change that, but this is the name of the array.
Here's the URL for the communication to go to, and from here, I can also remove those
storage arrays.
So, there you can see basically how easy it is to – sorry, let's do this again.
So, you can see there how easy it is to add a vVol volume to your vSphere environment.
This entire demo has been done in VMware's hands-on lab environment.
You can go to hol.vmware.com and log in with your own VMware account, and from there, you
can go through this whole demo yourself and configure the storage array, create the vVols,
and configure replication and create VMs.
It's a very detailed, like, 90-minute lab you can go through.
I encourage you to go to hol.vmware.com and log in and do this lab yourself.