vSAN Lab on Ravello – Part 2

In this second and last part (you can find the first one here) we’ll talk about claiming disks to compose a vSAN from the available ones from every host, then we’ll analyze a main component of vSAN configuration, vSAN Storage Policy, and finally a couple of interesting options.

Claim disks

vSAN is made of 2 different groups of disks: capacity tier (usually traditional HDD) and caching tier (only SSD, or “flash” as displayed in vCenter). So from the list of the available disks of the hosts we’ll choose which disks will do what:

And this is the result of our choice:



Now we can enable DRS and HA on the cluster


vSAN Storage Policy

VM Storage policies are crucial for a vSAN system. They are chosen during a VM deployment, and they’re made of special characteristics of the storage used. They are placed in the Home page of vCenter


The defautl settings of a vSAN policy are shown below:


  • Primary level O Failures To Tolerate = 1 – no. of host, disk or network failures a storage object can tolerate. If mirroring: 2n+1 for 1 fault, writing data on n+1 hosts. If erasure coding: 4 hosts for 1 failure.
  • Number of disk stripe per object = 1 – no. of HDD across which each replica of a storage object is striped. If >1, performances are better at the cost of more resources used.
  • Force provisioning = No – The object can be provisioned ONLY if it satisfies all the policy
  • Object space reservation = 0% – Storage reserved in thick provisioning for the VM. The rest will be thin.
  • Flash read cache reservation = 0% – Flash storage reserved for read for the storage object

For any change the system will recalculate the needed storage space needed for an exampe of a 100GB virtual disk (in this example we increased the value of primary level of failures to tolerate to 2):


These are the standard rules. But many other can be added, let’s see which ones:


  • Secondary level of failures to tolerate, in case of a second fault domain
  • Failure tolerance method (RAID – mirroring or erasure coding)
  • Data locality
  • IOPS limit per object
  • Disable object checksum

Cluster options

When we previously set up the cluster, we had (and still have) the opportunity to make some choice for our vSAN:

in short:

  • Manual or automatic disk addition
  • Deduplication and compression (only for all-flash groups)
  • Encryption (with possibility to erase disks before use)
  • Allow Reduced Redundancy (lower VM protection level if SP setup is at the limit of protection level)

Stretched cluster

First of the 2 advanced option to realize a strong vSAN configuration, the streched cluster is useful to have a second cluster for better data protection, tipically available where the distance between data centers is limited (we don’t have a second remote cluster right now…):

Fault domains

The second option is used to protect against rack or chassis failure. Grouping is driven by physical location of the hosts. Failure toleration is the one specified by the relative SP:


Creating a  domain is quite intuitive: just name the domain and check the belonging hosts.

I probably forgot something on this overview, so feel free to comment, add and argue writing in the space below.


One thought on “vSAN Lab on Ravello – Part 2”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s