(If this was a car we are talking about putting the correct amount of air in tyres and removing unnecessary items from the car to reduce weight. Neither action changes the car's operation but can improve MPG which could be used to described how efficient the car is)
All filers are FAS3070 running DoT 7.3
The production site is DC01 and has VMware datastores in FCP LUNs. These volumes are snapmirrored to a standby site DC02.
Thin Provision – DC02
It is not possible to thin provision the snapmirror destinations as the volumes can not automatically grow. The volumes must therefore be configured to the maximum size they could ever become and the volume space reservation set to "none". This way only the blocks containing data will be used in the aggregate.
snapmirror quiesce dc02vol1
snapmirror break dc02vol1
vol options dc02vol1 guarantee none
vol options dc02vol1 fs_size_fixed off
vol size dc02vol1 1000g (dc01vol1 has a max size of 999g)
Thin Provision – DC01
In order to get the blocks released back to the aggregate, both the fractional and snap reserves must be removed. The volume can then be reduced in size to release the unused blocks. However at some point the the future (near) the volume may need to write to extra blocks so the volumes should be configured to automatically grow to allow for this. If not the LUNs will go offline with an unable to write error which would be a bad this for the VMDKs and any VMs…
The auto delete is an optional extra. The steps below tell the volume to grow until max size and then start removing the Snapmanager for Virtual infrastructure (SMVI) backups until there is enough free space. It will not delete the snapmirror baseline snapshot.
lun set reservation /vol/dc01vol1/lun1.lun disable
Turn on the snapmirror once you are happy production is still working
snapmirror resync dc02vol1
SIS 'Dedupe' – DC01
It is possible to turn on the NetApp deduplication tool SIS and return even more blocks to the aggreagtes. VMware volumes with high numbers of VMs in them have VERY high dedupe ratios. We have seen 59% on some volumes but 0% on some CIFS data volumes, so only testing can show what is possible. Dedupe is not free in that it will cost some extra CPU cycles on the filer, about another 3% on our FAS3070 and some extra IO while the SIS engine is running. The blocks are NOT released to the aggregate until after the last snapshot which uses them is deleted. So if you keen 3 weeks of snaps, it is 3 weeks until the dedupe savings can used for another application.
sis on /vol/dc01vol1
sis start -s /vol/dc01vol1 (do this during a low IO period as the process uses all the free IO. See SIS on now site for other options)
The snapmirror process will send the deduped blocks to the 2nd site. No action is required on filer2.
After a couple of weeks return to production filer and shrink the volumes to bank the savings.
vol size dc01vol1 -Xg
We use Operations Manager to monitor and alert via email on the volume autogrow events. The filers only sent SNMP traps for these events, so if your Operations manager is only configured for HTTP comms you will not get them. TEST!
Now that we have alerting when volumes grow, we can manage the volume size vs max growth allowed and total space in the aggregate.
Was it worth it? – We have an aggregate used for just VMware volumes. It was 93% full, out of space and 13 Tb in size. The same data and aggregate but it is only 60% full with 5+ Tb of free space.
Hope this blog post helps you
VMware's thin provisioning
Becuase the SAN is thin provisioned and deduped, we have set our VM disks to be thick. This is to reduce management and make life simple. To convert the VM storage I used VMware's storage vmotion to migrate from thin to thick, for the few disks which needed changing. There may be better methods but this worked for me and it was simple.
The storage used by VMware is recovered by NetApp later so why create the extra workload from managing the same storage twice…
109 Responses to “Free Storage – Storage Efficiency”