time of changing vSAN policy for VM

[nblr06]

I'm planning to switch the vSAN policy for VMs.

The current policies applied to the VMs are "no redundancy" and/or "FTT=1(raid1)" mixed, and I would like to make the protection on these VMs consistent by using the FTT=1(raid5) to all the objects. These are located in a single vSAN cluster site.

Before doing this, I started to think about how long will the task spend(change to policy FTT=1 of raid5) to complete?

I guess the factors that determine the time that vSAN cluster complete the replication of data shall be:

VM size, amount of vmdk, HY/AF configuration, performance of each disks, bandwidth of network path(cable, switch...etc), the available space of vSAN cluster and each vSAN hosts' compute resources/performance.

I can't find official document about how to estimate the time that changing VM's vSAN storage policy will take, does anyone know please?

[paudieo]

Yes there are too many variables to have an offical documented time or time to estimate

what is the hardware configuration of a given vSAN cluster, to add to your list, existing IO load , version of vSAN , what data services enabled (dedup and compression, encryption etc) 

Yes, and I will unfortunately use the dreaded phrase, it depends
the re-synch dashboard does give some indication as to how long it will take an object to return to compliance after a policy change

[TheBobkin · Accepted solution]

As @paudieo  said 'it depends' (or 'how long is a piece of string' in GS parlance 😄 ) as this is entirely dependent on the data components being changed, the existing IO (e.g. the workload using the cluster while this is ongoing) and the capabilities of the storage devices that comprise this cluster.

@nblr06 , You mentioned 'HY/AF configuration' while mentioning a single cluster in use - is this an All-Flash (AF) or Hybrid (HY) cluster here? Reason asking is that only AF clusters (with Advanced vSAN or higher licensing) can avail of FTM=RAID5.
If it is an AF cluster with sufficient license then reconfiguring the SP shouldn't be an issue but we would advise that you do this in a tested/understood/controlled manner.

For example, changing the Storage Policy of an Object (e.g. a vmdk) or a VM from FTT=1,RAID=1 to FTT=1,RAID=5 requires what we call a deep-reconfig - the vmdk/VM will use the space they currently use + the space they will use in the new layout, once this is done copying the data from the original R1 layout to the new R5 it will remove the original R1 data but while it is reconfiguring it will require additional space to do this (e.g. a vmdk using 100GB of space = 200GB with FTT=1,FTM=R1, during deep-reconfig will need to make an additional 133GB of FTT=1,FTM=R5 data and temporarily consume a total of 333GB, then once reconfiguration is complete it will remove the original R1 data and consume 133GB on disk).

This is the main reasoning behind it not being advisable to changing the rules on a Storage Policy and clicking 'Apply now' - the better way is to create a new Storage Policy with the new layout/rules you want and apply these to VMs/vmdks in your own time and while monitoring the impact of the re-layout resync on the cluster (e.g. do it in small amounts at first, if the cluster can easily handle it then apply it to greater amounts of data, throttle it if you go too far during business hours maybe).