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.
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
When we previously set up the cluster, we had (and still have) the opportunity to make some choice for our vSAN:
- 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)
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…):
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.