Yeah, whole story in the subject, I know... but in bottomline it is what is is all about
We are currently running a vSAN 6.2 environment, and we have some storage capabilities issues.
We have a vSAN of 27TB of storage. Currently we have 9.5TB Free space.
The main issue we have is that most of the machines (45), are auto created by Horizon, and thus have a FTT=0, which means whenever a disk fails, these VM's become defective.
The biggest disadvantage is that these systems are RDS host... with 50 users on each. The impact is huge whenever a failure occurs.
What we like to do is change the OS_Floating Storage Policy (Created by View) from FTT=0 to FTT=1.
When I look at a typical (by Horizon) created VM is consists of 4 Disks (each with the same OS_Floating Storage Policy):
- Disk 1 20 MB (16MB in Use) - Bootloader (I think )
- Disk 2 100GB (25GB in Use) - OS Disk (presumable the Replica! We are using replica's, the replica's itself are FTT=1 :smileyalert: )
- Disk 3 30 GB (10GB In Use) - Data Disk
- Disk 4 25 GB (15 GB In Use) - OS Swap Disk
So, turning on FTT=1 will result in : 16MB + 25GB + 10GB + 15GB = 50GB Per VM Extra storage * 45 (the number of VM's) = 2.2TB :smileyalert:
Is this a correct calculation? Because the Replica is already FTT=1, does this Disk 2 will be "extra" Protected then? I assume yes, but hopefully vSAN is capable of knowing what to Replicate and do only the Delta FTT=1 (but where is the Delta? )
The first step we want to do in our vSAN is turning on Sparse Swap, as we do not overcommit memory, we can save about 1.5 ~ 2 TB of storage due to Sparse Swap enablement.
Any idea's / thoughts about this situation?
Your calculation is correct. When you enable FTT to 1, you will use twice as much storage. The 25GB for disk 2 is a delta checkpoint vmdk and includes only changes that differ from the replica disk for that VM. So there must be 25GB of change to the OS disk. That will be replicated to the other fault domain. The replica disk itself is assigned Replica_Disk storage policy.