Thick disks on deuped storage ? performance penalty on migration?

[BrownUK]

We thick provisioned disks on our infrastructure as we thought it would enable us to more easily see if we were runnnig out of space and as the back end is deduped what would be the problem?  Having Esxi thin provision the disk and then having the netapp deduplicate the storage as well seemed to be overkill.

So if I migrate a server from one datastore to another and the disk is thick provisioned, deduped on the storage, is the drive expanded, copied and then eventually deduped ?

So would it actually make more sense to thin provision on deduped storage?

Hope this makes sense

Cheers

Al

[a_p_]

Welcome to the Community,

as you mentioned correctly migrating the VM with thick provisioned disks will require the provisioned disk space, because NetApps deduplication usually runs in a nightly task. IMO deduplication may be useful in some scenarios, but may impact performance and could cause issues with disk space if you don't plan and monitor carefully. Think of backup and restore. In case of a disaster you'd probably not be able to restore all your data in a single run in case the storage has been overprovisioned!

André

[jdptechnc]

From a pure space savings perspective, dedupe certainly would not be overkill; just think about the case where you have 10 Windows VM's on the same datastore.  Thin provisioning (whether implemented on the SAN or in VMware will allocate space as it is required.  But then dedupe would consolidate all those blocks used for Windows system files that are in common between the VM's.

You do need to put thought and planning into it if you go that route though, as a.p. said.  It's not something that you just enable without understanding the implications and accounting for them.

[BrownUK]

I am beginning to think that it is more appropriate to go thin and dedupe.  The main reason for thick and dedupe was so that somewhere along the way it was possible to roughly have some idea of how much space could be used.

I think I need to get my head round this so that it is possible to work it out.  It is actually even more complicated than this after speaking to our storage guy,  The Netapp stoage is also thin provisioned as well as being deduped

So I just ned to work out how much thin, deduped,thin space we are actaully using or I may just look at the committed space as being the best guide.

Cheers Chaps

[jdptechnc]

BrownUK wrote:

I am beginning to think that it is more appropriate to go thin and dedupe.  The main reason for thick and dedupe was so that somewhere along the way it was possible to roughly have some idea of how much space could be used.

I think I need to get my head round this so that it is possible to work it out.  It is actually even more complicated than this after speaking to our storage guy,  The Netapp stoage is also thin provisioned as well as being deduped

So I just ned to work out how much thin, deduped,thin space we are actaully using or I may just look at the committed space as being the best guide.

Cheers Chaps

Check out the Storabe Best Practices for VMware guide from NetApp if you haven't already:

http://media.netapp.com/documents/tr-3749.pdf