This is part 2 of the vSAN storage policies posts, If you have not touched the previous post, you can find it here. We discussed the “Site Disaster Tolerance” option in the Availablity tab and we’ll continue with the “Failure to Tolerate” option.
We used to configure RAID levels when installing a new server or setting up a new storage system, here with vSAN we have the same concept but differently. Along with 4 RAID levels (0, 1, 5, 6), there is another option called Failures to Tolerate or FTT which dictates the number of failures a storage object can tolerate.
No data redundancy: This is equal to RAID level 0, and any failure will result in data inaccessibility, you might want to use it for VMs in a test environment.
No data redundancy with host affinity: You might have some applications that take care of replication and disaster recovery at the application layer like Microsoft SQL or other apps that ensure data redundancy at the application layer. with this policy, you can store VM’s data on the local host with no replication at the vSAN layer. there are certain requirements to deploy this policy. For further information, please refer to VMware documentation.
1 failure – RAID-1 (Mirroring):
This option only protects from one failure at the moment, meaning storage objects can survive if there is only one failure. The amount of storage used will be doubled. If a VMDK is 100GB, the actual usage will be 200 GB.
1 failure – RAID-5 (Erasure Coding):
This option also protects from one failure at the moment with a difference from the previous option. a VMDK of 100GB will consume 133.33 GB
2 failures – RAID-1 (Mirroring):
If your business continuity strategy enforces a higher level of protection, you can use RAID 1 with an FTT of 2, meaning, if two hosts experience a failure at the same time, you’ll still have your data. That means, 100GB VMDK will consume 300GB.
2 failure – RAID-6 (Erasure Coding):
If you want to maintain the FTT of 2 while saving some storage space and also cost. you can use RAID6. We only have 50% capacity overhead, and a 100GB VMDK only uses 150GB in effect.
3 failures – RAID-1 (Mirroring):
You might have certain applications with a higher degree of importance and want to ensure better availability, you can use RAID 1 with the FTT of 3, which means a 100GB VMDK will use 400 GB.
keep in mind that, RAID5/6 is only available in vSAN all-flash version.
Storage Rules
Before jumping into the options in the Storage Rules tab, let’s touch on some concepts beforehand. VMware offers two attractive services on Space Efficiency and Security. If the all-flash is the option of your desire, you’ll have to purchase a couple of flash disks which is not cheap at all, and we’ll see if we can save some space to avoid more costs and present our design in a way that can justify stakeholders. vSAN offers a service named Compression and Deduplication. Starting from vSphere 7.0 and later versions you can enable these options separately which was not possible on vSphere 6.7 and sooner. Needless to say that these options are only available in all-flash deployments.
Deduplication
As its name represents, it avoids redundant blocks of data to be stored in the underlying storage. There are various deduplication techniques like File-based and Block-based deduplication as well as fixed-length and variable-length deduplication algorithms which we’ll not get into details about now. But consider that there is an engine that looks for redundant blocks of data and avoids writing the same block twice. Instead, it sets a pointer to the original block to be able to service the read requests.
Compression
Compression is similar to deduplication with a difference that it gets a bit deeper and looks for redundant data within each block and avoids redundant copies. The picture below represents a cluster that has benefited greatly from Compression and Deduplication features.
The ratio 1.8X shows that it worked great and 31.20 TB strage capacity has been saved.
Encryption Service
vSAN supprts two flavor of encryption, both Data@Rest and Data-in-transit encryption. Each tackles a certain level of security concern.
Data@Rest encryption requires a KMS whether an external provider or the native vSphere key provider. AES-256 standard is used and the use of different keys like KEK (Key Encryption Key) and DEK (Data Encryption Key) is required.
On the other hand, you can enable Data-in-Transit encryption which secures transimission of data and metadata between hosts within a cluster. This also used AES-256 encryption.
These two variation of encryption can be enabled individually and they’re cluster-wide settings.
Let’s get back to the policy options, in the Storage Rules tab as depicted below you can specify options of your desire to place the VM on complied cluster.
If you like to have your VM placed in a datastore where Compression is enabled, you need to choose compression only. For all three options, if it’s not important for you to decide what feature is enabled or not, choose No Preference.
We’ll see other options in later posts. I hope this’s been informative for you.
