Hello TomThwaites,
"I like to enable this, but im not sure of the impact on doing this."
It basically does a rolling disk-format - removes all the data off each disk-group (one at a time) on each host (one at a time), removes the disk-group and recreates them anew with dedupe & compression enabled.
How it proceeds with this depends which option you select:
If you do it as standard it evacuates all the data off (technically it just makes a new copy somewhere else), similar to how you would remove a disk/disk-group with 'Full Data Migration' or place host in maintenance mode.
The alternative is to use 'Reduced Redundancy' option which doesn't move/copy the data, just ensures that the remaining copy (assuming FTT=1 or higher) is accessible, removes the disk-group, recreates it with dedupe & compression enabled.
It won't rebuild the remaining copies of the data for 60 minutes when using the default clom repair delay timer (which you can change) or when 'repair immediately' button is pressed via the Health UI (or via RVC: vsan.health.cluster_repair_immediately).
"The vSan has about 400TBs available and currently using around 100TB, so am i ok to just enable this or will this impact the VMs running on the vSAN"
This depends on numerous factors, not just current data % usage.
The more hosts and disk-groups you have in the cluster, the less likely it will be to have impact as the large rebuild/move operations are spread over a greater area. If you have well-sized caches and capacity drives (not SATA etc.), lots of disk-groups per host etc. , these will do better than the opposite. If you have ever seen your cluster under-going a relatively large resync (e.g. the size of the used space on a current single disk-group) then this would be a comparable situation (but for a prolonged period - up to days depending on size of the cluster) - you can see how your cluster handles this on a smaller scale/duration by evacuating a single disk and compare to baseline using vSphere Performance graphs/vSAN Observer (e.g. do the caches get starved, is the de-stage poor etc.).
It boils down how fast/well your cluster can resync 100TB worth of data while also serving IO to the current workload running on it.
Enable Deduplication and Compression on Existing vSAN Cluster
VSAN 6.2 Part 1 - Deduplication and Compression - CormacHogan.com
Question though: what is your current disk-group sizes and per host configuration and what ratio do you reckon your data will dedupe by?
Better to enable this earlier rather than later if you are certain you want to use this but everything is a trade-off.
Are you expecting to have this cluster fuller and/or a lot busier in the near future and what does the IO profile of the workload look like?
Bob
