vSAN1

Hi,

Can you confirm that disabling dedup and compression with VMs up and running on the same vSAN datastore is supported?

My understanding is that this works on a disk group at a time by evacuating data, turning off dedup and compression and migrating the data back and then moving on to the next disk group.

Is this correct? Any other observations?

Thanks

Hello andvm​,

Yes, it is supported.

Can it have knock-on impacts on performance? Yes, of course it can - you are doing a potentially massive read and write job of ALL the data on the vsanDatastore.

Thus it should be monitored accordingly and throttled if necessary.

Your points about what the process entails are roughly correct, but it isn't going to necessarily move the data back onto the same recreated Disk-Group (DG) - e.g. if you choose 'Full Data Migration' option it will move the data to all of the other available DGs and then when it goes to move the next one it will predominantly place the data on the newly recreated DG (as this has the most available free space), that is of course if doing so isn't violating some other aspect of the Storage Policy with regard to co-location of replicas.

Bob

Also, do ensure that you have adequate space on the vsanDatastore to house the data - estimate of this is the used space multiplied by the current dedupe ratio, minus dedupe overhead.

Bob

Thank you, what is interesting is that after disabling dedup and compression I got less storage space used. (Roughly 50% less space used)

Can you clarify the meaning of the following (I know some of these sound obvious but did not imagine I could get more free space after doing such action)?

Used

Actually Written

Dedup and Compression Savings: x.xxTB (Ratio ..)

For instance on a dedup and compression enabled vSAN datastore I see

Used: 7.5TB

Actually Written: 7.5TB

Dedup and compression savings. 7.30TB (Ratio 3x).  

What is not clear to me from the above is why Used and Written are the same if there was Dedup and compression savings?

I am thinking that this could be due to the low disk usage < 10TB and the fact that disabling dedup and compression takes off its overhead of a few TB's

Thanks

Hello andvm​,

Sure, it is possible to have less used space after disabling dedupe if the overhead exceeded the savings (e.g. if you had very low savings due to not much data on each Disk-Group, data that had high uniqueness or data that was Thick (at the vmdk primitive or SPBM level)). That being said, your output doesn't appear to make complete sense - is this during enabling/disabling dedupe?

It could be as you said due to overhead which should be visible from the Capacity breakdown in the UI.

It isn't really feasible to troubleshoot this further from just screenshots etc. as we need to look at the data more granularly, thus I would advise opening a Support Request with us at GSS vSAN if more insight is required.

Bob