In part 5 of my VCAP7-DTM Design exam series I already posted some YouTube videos about vSAN in case you prefer videos instead of reading. To further proof my vSAN knowledge I decided to take the vSAN Specialist exam which focuses on the version 6.6.
vSAN Basics – Facts and Requirements
Out in the field not every EUC guy has enough sic knowledge about vSAN and I want to provide some facts about this technology here. This is no article about all the background information and detailed stuff you can do with vSAN, but it should help you to get a basic understanding. If you need more details about vSAN I highly recommend the vSAN 6.7 U1 Deep Dive book and the content available on storagehub.vmware.com.
- The vSAN cluster requires at least one flash device and capacity device (magnetic or flash)
- A minimum of three hosts is required except you go for a two-node configuration (requires a witness appliance)
- Each host participating in the vSAN cluster requires a vSAN enabled VMkernel port
- Hybrid configurations require a minimum of one 1GbE NIC, 10GbE is recommended by VMware
- All-Flash configurations require a minimum of one 10GbE NIC
- vSAN can use RAID-1 (mirroring) and RAID5-/6 (erasure coding) for the VM storage policies
- RAID-1 is used for performance reasons, erasure coding is used for capacity reasons
- Disk groups require one flash device for the cache tier and one or more flash/magnetic device for the capacity tier
- There can be only one cache device per disk group
- Hybrid configuration – The SSD cache is used for read and write (70/30)
- All-Flash configuration – The SSD cache is used 100% as a write cache
- Since version 6.6 there is no multicast requirement anymore
- vSAN supports IPv4 and IPv6
- vSphere HA needs to be disabled before vSAN can be enabled and configured
- The raw capacity of a vSAN datastore is calculated by the number of capacity devices multiplied by the number of ESXi hosts (e.g. 5 x 2TB x 6 hosts = 60 TB raw)
- Deduplication and compression are only available in all-flash configurations
- vSAN stores VM data in objects (VM home, swap, VMDK, snapshots)
- The witness does not store any VM specific data, only metadata
- vSAN provides data at rest encryption which is a cluster-wide feature
- vSAN integrates with CBRC (host memory read cache) which is mostly used for VMware Horizon
- By default, the default VM storage policy is assigned to a VM
- Each stretched cluster must have its own witness host (no additional vSAN license needed)
- Fault domains are mostly described with the term “rack awareness”
vSAN for VMware Horizon
The following information can be found in the VMware Docs for Horizon:
When you use vSAN, Horizon 7 defines virtual machine storage requirements, such as capacity, performance, and availability, in the form of default storage policy profiles, which you can modify. Storage is provisioned and automatically configured according to the assigned policies. The default policies that are created during desktop pool creation depend on the type of pool you create.
This means that Horizon will create storage policies when a desktop pool get created. To get more information I will provision a floating Windows 10 instant clone desktop pool. Before I’m doing that, let’s have a look first at the policies which will appear in vCenter depending on the pool type:
Since I’m going to create a floating instant clone desktop pool I assume that I should see some the storage policies marked in yellow.
First of all we need to take a quick look again at instant clones. I only cover instant clones since it’s the recommended provisioning method by VMware. As we can learn from this VMware blog post, you can maissvely reduce the time for a desktop to be provisioned (compared to View Composer Linked Clones).
The big advantage of the instant clone technology (vmFork) is the in-memory cloning technique of a running parent VM.
The following table summarizes the types of VMs used or created during the instant-cloning process:
Horizon Default Storage Policies
To add a desktop pool I have created my master image first and took a snapshot of it. In my case the VM is called “dummyVM_blog” and has the “vSAN Default Storage Policy” assigned.
How does it go from here when I create the floating Windows 10 instant clone desktop pool?
The second step in the process is where the instant-clone engine uses the master VM snapshot to create one template VM. This template VM is linked to the master VM. My template VM automatically got the following storage policy assigned:
The third step is where the replica VM gets created with the usage of the template VM. The replica VM is a thinprovisioned full clone of the internal template VM. The replica VM shares a read disk with the instantclone VMs after they are created. I only have the vSAN datastore available and one replica VM is created per datastore. The replica VM automatically got the following storage policy assigned:
The fourth step involves the snapshot of the replica VM which is used to create one running parent VM per ESXi host per datastore. The parent VM automatically got the following storage policies assigned:
After, the running parent VM is used to create the instant clone, but the instant clone will be linked to the replica VM and not the running parent VM. This means a parent VM can be deleted without affecting the instant clone. The instant clone automatically got the following storage policies assigned:
And the complete stack of VMs with the two-node vSAN cluster in my home lab, without any further datastores, looks like this:
Now we know the workflow from a master VM to the instant clone and which default storage policies got created and assigned by VMware Horizon. We only know from the VMware Docs that FTT=1 and one stripe per object is configured and that there isn’t any difference except for the name. I checked all storage policies in the GUI again and indeed they are all exactly the same. Note this:
Once these policies are created for the virtual machines, they will never be changed by Horizon 7
Even I didn’t use linked clones with a persistent disk the storage policy PERSISTENT_DISK_<guid> gets created. With instant clones there is no option for a persistent disk yet (you have to use App Volumes with writable volumes), but I think that this will come in the future for instant clones and then we also don’t need View Composer anymore. 🙂
App Volumes Caveat
Don’t forget this caveat for App Volumes when using a vSAN stretched cluster.