Welcome back to vSphere 8 in the real world. Let's look at Advanced Storage Features.
So data in transit encryption. So what we're talking about here, we're talking about vSAN.
So with vSAN, traditionally we've always been able to encrypt or, you know, for most of the time
you've had vSAN be able to encrypt the data while it's on the disk. And that's obviously a really
important feature, something you want to be able to do. You should always encrypt your data when
it's, you know, sitting on disk. But it's becoming more and more common where these, you know,
people coming in and getting into our environments are getting more and more advanced tools. And so
data in transit now is also equally as important to encrypt as data at rest. So we also, you know,
obviously want to have that capability. The reason why it hasn't always been something that people
have done as much is because it's very resource intensive and hardware just wasn't really able
to keep up with that amount of encryption and decryption. And we don't want to encrypt the data
using the same keys that we use when it's at rest on our disk as it is when it's in transit
from one host to another, whether it be replication or what have you. So this is something that's a
somewhat newer feature, being able to encrypt data while it's in transit over our network.
It's obviously something that's, you know, again, very important. That's why HTTPS has become,
you know, the default protocol on the internet versus the standard unencrypted HTTP,
because more and more people are able to see more and more in our networks. Our tools are getting
better that they use to hack us. And so data, while it's moving between hosts from source to
target over the network, it's important to have that encrypted as well. So if we want to start
encrypting data on our vSAN, if we didn't enable it during the configuration when we rolled it out,
we can go to the configuration tab for the cluster, go to vSAN, go to services,
go to data in transit, and we're going to edit that. And then we want to enable
data in transit encryption, right? We can say the rekey interval, how can we want to rekey that,
change the key. So if something does happen to the key, it gets compromised,
then they only have it for a shorter period of time. We don't want to use that same key,
you know, infinitely. Maybe you want to change it every couple of days, every week or something
like that, and then we can click apply. So now our vSAN data, when it's moving between hosts,
will be encrypted using AES-256, and we can configure some kind of forwarding secret on there.
So what else is encrypted besides just data between vSAN replication? Between the host and
the witness is also encrypted. And what a witness is, with vSphere 8, we're able to have vSAN
clusters with less than three hosts. Traditionally, we always wanted, you know, have to have at least
three, preferably four, five, six, seven. We can do it now with two and a witness. So what that
does, unfortunately, is it makes our clusters less redundant and less recoverable by, you know,
that very nature. But we can do it, and the witness basically will happen, because we only have two,
and one goes down, then the other one would have to take over the entire load.
But what happens if they don't go down, the communication between the two fails for some
reason. Now they don't know who is the master and who's the one that should keep running,
who became isolated. So what that means is, a third one can be a witness, and if A and B all
of a sudden can't talk to each other anymore, then A can try to talk to the witness. The witness
can say, yep, I see you, but I don't see B. Okay, then that means I'm still up, I'm going to keep
functioning and doing my job. B says I can't see A, it'll try and talk to the witness. If it can't
see the witness either, then it can say, oh, I'm the one that's isolated, and so I need to stop
taking changes, I need to fail this over to A. All right? So that's what a witness is basically for.
So data between them would be also replicated. And then the VDFS, what this is basically for,
is a virtual distributed file system, and this is used for services like NFS. So with vSphere 8,
we can create NFS shares, SMB shares, things like that, and use our vSAN storage and not have to
create a Windows VM and then share that information or a Linux VM and then create an NFS share for
that. I can create either an SMB share or an NFS share right from my vSAN now, and the
services used to synchronize that information is also encrypted now.
So vSAN storage, so we're going to go to our cluster, right, go to the configuration tab,
services and encryption, we're going to choose edit. Our vSAN services page, we want to go in
there and enable encryption. We want to give it a KMS key, right, and we can probably have created
that in advance before we obviously get to this page. And do you need to remove residual data
before encrypting? You want to wipe residual data. Residual data, this really means on a particular
disk group, that data is going to be wiped out. And so that's kind of important to do,
especially on a flash disk. So with flash disks, what can happen is you don't want there to say,
okay, we're going to start encrypting data, and there's blocks that didn't get wiped out.
Remember flash, actually, let's say you have a 512-gig flash disk. It's actually larger than
that, right, because pages on those flash disks can go bad. And so there's going to be a lot more
pages on there than just that 512 gigs. And the system is going to read and write randomly to
them. And so that way, we kind of get a more even wear across those flash pages, so they don't all
start, you know, certain ones are failing before other ones. We can kind of get a more consistent
age on them. But it's only going to let you use the 512 that you paid for and that you bought,
right. The controller for that is going to make sure that you only use the 512. But they actually
give you more for wearing. So if there's a bunch of pages out there that have information written
to them, and then when you encrypt, it's written to other pages, those pages that have residual
data on there, if something were to be compromised, those aren't encrypted until they get
rewritten over at some point in the future, right. And also cache pages may not be written over until
some point in the future. So what you can do is say, I want to get rid of all residual data. I
want to format all the different pages and rewrite this data clean from scratch, right, in an
encrypted state. So that's with residual data. And you will want to say yes to that. So if you're
doing a cluster upgrade, first you need to upgrade your vCenter server. Then you need to
upgrade your ESXi hosts. Then the last thing you're going to do is you're going to upgrade the vSAN
disk format. So if you are running an older version of vSAN and you upgrade to a new version,
like say version 8 of vSphere, then – and by the way, vSAN versions don't match ESXi versions.
There's actually been quite a few upgrades in vSAN along the way, whereas vSphere went from,
you know, 6 to 6.5 and to 7 and 7.2 and, you know, and then to 8. vSAN has had a lot more
upgrades during that time. So it actually is a much higher version. I don't want to start
quoting exact versions because they keep changing. And by the time this comes out, you might even
see newer versions. But there are more – the version numbers are higher on vSAN than they are
on vSphere or ESXi. But when you're upgrading, you can't just upgrade vSAN and not have upgraded
your host first. Your host needs to support the version of vSAN you're running. You can't upgrade
your host and not upgrade vSAN. Your vSAN needs to support your host. So vSAN can support,
you know, ESXi 8 and ESXi 7 and ESXi 6.5. And ESXi 8 can support older versions of vSAN or
the current version to it, but it can't support versions newer than it is. So vSphere first,
vCenter, then ESXi, then your vSAN. Okay? So some hardware needs verified that the vSAN supports
the hardware you have. Make sure all your hardware is on the HCL, your controllers,
your disks, things like that. Make sure you have the latest vSAN version available because
it will if you have the most current version of vSXI, you know, vCenter available, vSphere.
Enough disk space. So disk space is important. If you have really large disk groups, like maybe
a small number of large disk groups, you might find you don't have enough space to upgrade vSAN.
And that's one of the reasons why it's a good idea to go with a larger number of small disk
groups. So when we have our disks, maybe I have in my host, I have, I've mentioned this before in
another lesson, 16 drives. I don't want to create a disk group of 16 drives or two disk groups of
eight drives. You might want to create four disk groups of four drives, and then we can replicate
those. Right? So this will allow us to, when we go to upgrade vSAN, I need to have enough space,
free space across my host to support the failure of one disk group. Because what's going to happen
is it's going to take down a disk group, wipe it out, upgrade it, then do the next,
and then do the next, and do the next, and do the next. If I don't have enough room on my vSAN
to copy the data off of one of the disk groups, then I won't have enough room to update a disk
group. And therefore, I can't upgrade any of my vSAN. So we need enough space. You want enough
space equal to one disk group. And your disk groups are hopefully all the same size across
all your vSAN silos. Disk format, you know, capacity and reduced redundancy. So when you
go to do your upgrades, the capacity of your vSAN during that time is going to go down because you
lost disk groups. And the redundancy is going to go down because you've lost disk groups. Let's be
aware of that. So hopefully you didn't do like an N plus one. Hopefully you've done like an N plus
two or even an N plus three. So if you did N plus one and you lose one, there's not redundancy
there, right? If I did an N plus two and I've lost one, then I have a redundancy of one.
And if your corporate policy, your corporate strategy is that your failover needs to be an
N plus two, your vSAN should be an N plus three, right? So if your overall compute and everything
else, you know, policy is an N plus two, your vSAN, you probably want to be N plus three
because you're going to be frequently, you know, patching your host, upgrading your host,
things like that. And during that time, you'll only be at an N plus two. So even during patching
and upgrading and all that, when you're doing all that, you still are in compliance with your
corporate policy of being N plus two if you do an N plus three. So that's just something to keep in
mind because that is normal scheduled maintenance. It's not like a failure. So if you're doing your
regular scheduled maintenance, you should still be in compliance with your corporate
policy as far as like fault tolerance and failure tolerances, okay? You'll put a vSAN
host in the maintenance mode when you're doing these upgrades and you want all your VMs backed
up. So hopefully you have a backup, you know, schedule in place running something like Veeam,
for example, and you just want to make sure that all your VMs are backed up, all your backups have
been successful so you have, you know, you're at your retention policy there.
Storage hardware acceleration. So storage hardware acceleration is a way of using APIs
so you can offload certain paths to the SAM. If you're using vVols, then you're always offloading
these paths to the SAM. But if you're running VMFS data stores, then you could be doing a lot
of the work with the host communicating with the SAM to say, you know, processing this work.
If you're using storage APIs, what we can do is we can offload tasks to the SAM from the host.
So if I want to create a new thick provisioned virtual disk, I could tell the SAM, create me a
eager zero thick provisioned virtual disk that's 500 gigs. And the host has to send that API
command and it's done. The SAM takes over and says, okay, yep, got it, that path is complete
and it does the work. If you want to copy a disk, if you want to reclaim space from a virtual disk
that's been zeroed, you can either have the host do all that work itself manually and it takes a
lot of CPU, a lot of memory, a lot of network bandwidth, or if you have APIs available to you,
you can offload that work. So all of that stuff is just a way of offloading paths
from the host to the storage. It's supported on the VMs, but it's not supported on the VMs.
It's supported on block storage device, meaning block local disk, iSCSI, fiber channel, NAS
devices. Migrating VMs can be offloaded. Cloning VMs can be offloaded. Cloning,
creating from templates can be offloaded. Locking VMFS clusters. So if you need to, for example,
grow a file or if you grow a file, it will now lock the file and not the entire data store. If
you want to grow a data store, it's going to put a lock on that data store. You can offload those
kinds of tasks to the SAM using the APIs. Provisioning virtual disks, you know, thick
formatted, eager zeroed. If you're doing thick provision but lazy zeroed, then it's not as big
a job, but it still is creating a large file, but it's less work if you're not zeroing out the
blocks first. Fault tolerance, if you have running fault tolerance solutions, again, you can offload
a lot of this type of stuff like replication and things like that to the SAM. Vendor independent.
So different vendors may or may not support all these requirements. You need to check with your
vendor. Does your vendor support all the VAI APIs or does it only support certain ones, right? So
you need to know what APIs that your storage vendor is fully compliant with or only partially
or not compatible with at all. Most storage vendors pride themselves on, you know, being
VMware compatible and things like that. If you're dealing with a lower end, like maybe a small
business, medium-sized business storage array, maybe they didn't have the dollars to invest or maybe
it wasn't profitable for them to invest to develop all the APIs. And creating the APIs is not the only
piece of it. It's also getting it certified by VMware as being, you know, fully compatible and
all the APIs are compatible and things like that. And that is also definitely a cost that they need
to consider. So just check with your vendor before you make a purchase and make sure that's compatible.
So thick and thin provisioned. So a thick provisioned virtual disk,
VMDK, is basically meaning that if I create a VMDK virtual disk for a virtual machine,
and let's say I'm going to make it 500 gigs. 500 gigs is allocated when I create that. It's
got zero data. When I first allocate it, it's zero, you know, bytes in size other than just
the file that is used to hold it on the disk, you know, the target. But if it's thick provisioned,
it actually takes up all 500 gigs on that storage. If it's thin provisioned, then it's just an empty
file sitting there. And it is, you know, a couple bits on there plus the descriptor file that is,
you know, identifies, you know, all the geometry and things like that, the virtual disk for the VM
to see. But thin provision grows over time. And so you can easily over allocate. Whereas thick
provision means you're taking up all that space at once. Now, thick and thin provision also can be
interpreted by the storage array. You could go in and say, I want to create a thick provision disk
that is 500 gigs in size. And your storage array could say, okay, done, and then not actually
create that thick provision disk. It will tell you it's thick provision, and the storage array
will handle growing and things like that. The host doesn't have to worry about any of that
because the host thinks it's done on the storage array side. It could be thin. Whereas if you have
a thin provision disk, you could create a small file, and the storage array is going to even,
you know, make it additionally a small, even smaller file, only allocate what's actually
needed. So storage, thick and thin is also a storage level. You could create a LUN that is
thin provisioned and say, you want to initially make it 500 gigs, but present it as being 50
terabytes. And when the host mounts it, it's like, oh, I got 50 terabytes. And it starts writing
things to it thinking it's got 50 terabytes, but you only made it, you know, 500 gigs or one
terabyte or something like that. And it just simply grows and grows and grows. Now, if you are a brave
SAM admin and you're like, okay, I know they're not going to use more than the two terabytes that
we actually have available right now in the next year, and next year we have budget to add the
additional 48 terabytes, and it's already, you know, in place. We already got orders, you know,
quotes, you know, created and things like that. The budget's already approved. So when I get that
additional new shelf and the new disk, I'll just go ahead and then increase that LUN size and make
it available to grow and pick up those disks. You can do that. And that's what sometimes happens,
is that admins are projecting what they're going to have for budget, what their purchases are going
to be next quarter and things like that, and they provision now thin based upon what they expect to
have in the future. So storage arrays do the same kind of thing. To create a thin provisioned
virtual disk, when you create the VM, you can just go to the, you know, go through the hardware,
you're going to customize the hardware, create a new disk. You can say if you want what size you
want it, I want to make it, you know, 500 gigs. And then you can say if you want to make it a
thick or thin provision, you can say thick eager zero, thick lazy zero, or you can make it thin.
And then you click finish. Right? So it's really simple. It's just when you create the VM or even
if you're not creating the VM, if you are adding the virtual disk to the VM. Now let's say you
chose thick. You thick provisioned the disk and the VM's been created. And now all of a sudden
you're like, you know what, I need that space back. I actually don't have as much space as I
thought. I need more VMs than I thought. You can shrink the disk really easy if you have storage
vMotion. If you have storage vMotion, then you can just simply say move the VM from this data store
to this data store. And in the process of moving it, you can re-provision it. You can make it
thick to thin or thin to thick. So you can change house provision. The easiest way is through a
storage vMotion. There are other ways that are much more difficult. The most common easiest way
is to storage vMotion from one data store to another and change the provisioning while you're
doing that. VMKFS tools. So this is just a command line tool that you can use to create and manage
your data stores. You can go in there, you can create new data stores, you know, format your
data stores, things like that. Just a command line tool that you can use for, again, provisioning
data stores. So if you want to script the creation of data stores, you know, VMFS data stores,
you can do that using the VMKFS tools command. So IO choices. There's a lot of different things
that can affect your IO performance on your storage array. Replication, for example, can
affect your storage performance. So replication would mean that writing, you know, data gets
written to disk, and as it gets written to disk, it's going to be copied to another storage array.
Maybe we write in, you know, every 15 minutes or once an hour, we replicate whatever is the
current state of the data from one storage array to another. What that means is that the disk that
I'm writing my data to, when replication occurs, there's going to be read operations on those disks
and they're going to be written to another storage array and there's write operations on those disks.
Read operations are less resource intensive typically, not by a huge amount, but less
resource intensive than write operations. So the SAN, that's my production SAN, where I'm
replicating from, doesn't take as big a hit as the storage array I'm writing to, but it still
definitely impacts performance. It takes up network bandwidth on the storage controllers,
and there's some CPU overhead in that as well. So replication can affect your IO. So replicating
less often, even though it might mean a slightly larger replication job, replicating less often
is less overhead on the storage controllers. Also replicating like maybe like in the evenings
after hours and things like that could help too, but that might not always be practical. You have
to have a, you know, you have a restore point objective of one hour. That means you need to
replicate at least once every hour, right, in order to accomplish that. Encryption, so encryption
being very important, having encryption on your data at rest on your SAN is obviously a really
important, you know, security feature to consider. It does add overhead on the storage processors.
It's going to add more workload on the disk because they're actually writing slightly more
data to write that encrypted data. So encryption will definitely impact the performance of your
storage array because also when you read that data back, you have to decrypt it. So the encryption
and decryption process adds latency. So all those things need to be considered when you're looking
at your IO performance. Caching is actually something that impacts your storage performance
in a positive way. We can take spinning disks, and we have spinning disks that are typically slow,
and we need to make them seem a little faster, and we don't have money to spend to get all new
flash disks. What I can do is I can put some flash storage in front, a smaller amount of flash
storage in front, and data gets written to that cache. Then it gets written from the cache when
it's available to the spinning disk. So the spinning disks are behind. It can just sit on
the flash drives and live there temporarily until the spinning drives get caught up, and then it
gets written from that cache to your spinning disk. So that's called tiered storage. You hear
people about tiered storage. What that usually means is that they have faster disks in front
and slower disks in back. Some storage arrays will actually even have flash in front and data
can live there. If it's often accessed, it just lives there. Then it gets written, if it's less
often accessed, to slower disks, maybe like 15,000 RPM spinning disks. Then I can have even slower
drives behind those that are even cheaper, and they're maybe huge, massive 30-terabyte drives
that are really slow, but data that's almost never accessed, I can archive away, can get
written to those. So having cache in the front and then slower disks and slower disks can actually
help your performance quite a bit. If you decide to access the data that's on those really slow
drives in the back, it will be slower, but it wouldn't be too bad because data over there is
rarely accessed, so those drives aren't doing a lot. The flash drives are accessing data that's
accessed often, and it's going to be called on a lot, so they need to be really, really fast to get
that data to you. So these are different things that can all affect your I.O. performance, some in a
good way, some in a bad way. Storage I.O. control isn't really necessarily a storage consideration
as far as it's going to make your storage perform faster or worse. It actually is just a way of
giving I.O. to virtual machines in a fair way. So what happens is if you have VMs that are using a
lot of I.O. and other VMs that are needing I.O., but they're not as busy, what can happen is the
real busy VMs can overwhelm the storage and the slower VMs don't get access. Storage I.O. control
kicks in when latency hits a certain number. Then all of a sudden it'll say, oh, I'm seeing there's
contention for that storage. Latency has reached a certain point, so there's contention for the
storage. So storage I.O. control kicks in and it adjusts the HBA's queue depth and can make it so
that certain VMs that are maybe using a lot of I.O. don't use as much and the VMs that aren't
getting as much can get more. It makes it more fair. It's not going to take it from the VMs that
are using a lot and say now you get none unless you give them a lower priority. If you give them
fewer shares and VMs that are not using as much but have higher shares, all of a sudden they'll
get a big bump in performance. So the access to the storage is going to be based on shares
and is controlled by the queue depth, the VM kernel for the HBA that's connected to the storage.
Let's go ahead and jump over to our demo environment and I'll show you how to set
up a thick provisioned and a thin provisioned VMDK file. So here we are back in our demo
environment. I'm just going to go ahead and click and create a new virtual machine.
I'm going to say create a new virtual machine. I'm going to give it a name.
There. Choose the host. It's fine. What storage I'm going to put on? Let's just throw it on there.
It's fine. Compatibility is fine. Guest OS, Windows, and all that's good.
Now the hardware. For my virtual disk, I could go in there and say, here,
disk provisioning. This is thick provision lazy zero. This is what we have on here by default.
So if I say 90 gigs, it's going to create a 90 gig file. On my storage, I will see a 90 gig file
being used. I could go in there and change that to any number I want, 500 gigs, whatever I want.
But I don't want it to actually use 500 gigs of space.
Because not enough capacity for that. My data store is only a couple hundred gigs.
So what I can do is I can thin provision that. Now I'm going to get a warning because when it's
thin provisioned, I'm not going to see a 500 gig file. I'm going to see a file that's only a few
K in size. And the maximum it can grow to is 198 gigabytes, 198.34 gigs right now. If I wanted to
try and thick provision that, I couldn't. So I'd have to reduce that down back to, say, for example,
that 90 gigs. Now I need to know if I'm going to thick provision it. Do I want it lazy zeroed
or eager zeroed? Lazy zeroed means that before the system can write to a block, it has to zero
that block. And when it's lazy zeroed, it's going to zero out the block right before it's
So I create the disk. I take up those 90 gigs of space I'm showing here. But I don't zero the blocks.
When the VM says write to this block for the first time, then that block gets zeroed. But that means
there's a delay in writing the data I said to write, because first I have to zero the block,
then I can write the data. If I go to the next block, I've got to zero the block, then I can write the data.
So I don't want that. I don't want that. I don't want that. I don't want that. I don't want that.
the data. If I go to the next block, I've got to zero the block, then I can write the data.
So lazy zeroed is a way of basically reserving the space, but not really helping my performance a lot
the first time a block gets written to. If I eager zero, then it's going to write that 90 gig file
and zero all the blocks in advance. So before I present it to the VM to start using, I've zeroed out
all those blocks. Now when the OS says write to this block for the first time, it can just write to it.
So for the very best performance, you want thick provisioned, eager zeroed. The worst performance
will be thin provisioned, because every time we have to grow the file and the file gets to be a certain size
and now it's full, now all of a sudden data is having to be queued while the file grows, then blocks get
zeroed, then the data can be written. All right? So thin provision will give you the worst performance,
but for best performance, thick provision, eager zeroed, and lazy zeroed is the default, because
it only has a zero in the first time it writes to them, so it's not going to, you know, if you overwrite blocks,
they don't get zeroed again, just the first time you write to them. So that is how you would create a virtual disk
and how you can choose if you want to make it thick provisioned or thin provisioned, if you want it lazy zeroed
or eager zeroed.