Datastore planning and configuration question

[mpaez]

Whats up.

I'm looking to get some info/suggestions on the best way to handle datastores in an evironment such as the one in where I work. Currently we have 226 VMs spread out across SAN based 14 datastores. 10 of which are Calriion FC-SCSI (R5 with 9 disks and 2 datastores per raid group) drives sized out to1.05TB each, the other 4 are Clariion FC-SATA drives sized at 1.12TB.

What we've tried to do is have all the production VMs be on FC-SCSI and all of the development VMs be on the FC-SATA. In the very near future we will be replacing our EMC Clariion Cx3-40F with an NS480 array(s). My main question are there any white papers on datastore configuration for optimal perfromance? Does anyone think that the current setup is appropriate or are there some things we can/should tweak?

Any suggestions would be appreciated.

If anyone need more details, please let me know

[jasoncllsystems]

Hi,

The each datastore size is too big for me. Most of the storage vendor recommended around 600G - 800G each.

Regards,

Jas

MALAYSIA VMware Communities

http://www.malaysiavm.com

'If you found this or any other answer useful please consider allocating points for helpful or correct answers ***

[AntonVZhbankov]

>My main question are there any white papers on datastore configuration for optimal perfromance?

No, there are not.

It totally depends on storage performance and VM I/O load.

---

MCSA, MCTS Hyper-V, VCP 3/4, VMware vExpert

http://blog.vadmin.ru

[Varunsh]

For performance benchmark you can try http://blogs.vmware.com/performance/ It is not exactly the same you are looking for but the resources used to define a benchmark can give you an idea of tweaking your virtual infrastructer.

Also refer to http://communities.vmware.com/message/1553246#1553246 quite simmilar to your query

[mreferre]

As Anton said there isn't any "rule to rule them all". It largely depends on what your workload is and also, more pragmatically, what your VMDK file size is.

I.e. if for some reason you create 300GB VMDK files I'd rather not go with a 600GB LUN (you couldn't fit 2 and it would be a big waste for one). Just an example.

I think Duncan's quick and dirty take would work in many situations: http://www.yellow-bricks.com/2009/06/23/vmfslun-size/

If you want to go more ballistic there is a nice paper that goes into IOPS and things like that to nail down the suggested # of VMs per datastore and hence calculate the size of the datastore: http://www.vmware.com/resources/techresources/1059

1TB LUNs doesn't scare me. I think in general you have a good plan.

HTH

Massimo.

[savantsingh]

Your configuration seems ok you have split the high IO VMs on FC disks..

Are you facing any IO issues???

Let me put it this way .. there are a lot of ways to configure storage but they depend on the infrastructure and its requirments..

So if you are not facing any issues i think you have the right basic config ... but if you are facing issues i would recommend to have more filters on Datastores by not having 2 high IO VMs on the same LUN, spliting the swap files i have seen that making performance impact etc....

Hope this makes sense

If you found this information useful, please consider awarding points for "Correct" or "Helpful".

[mpaez]

Im getting the feeling that I need to get a little more granular in my outlook of the current configs to see what to do/reconfigure in the future.

My main concern is having disk contention issues bewtween VMs on a datastore. The yellowbrick site looks like a good formula to get an idea on how to handle it. The other problem I have with the whole planning is that as VMs are becoming increasingly popular, its kind of hard for there to be a standard disk size for the VMs. On averag I think we are at 45-80GB total on a standard VM.

There are a few abirations of large VMs (about 6) that are over 200GB total size. My other concern is we are looking to use Commvault (simpana) solution to back up the VMs natively. The thing with that is that when you run the backup, a full snapshop is created of the VM and stored with it. That whole balooning of disk space, increase in IOps and disk contention are serious factors to consider.