Separating VMDKs what are the draw backs?

[Steve2point0]

We are redesiging our vSphere environment, there's disgussion about splitting VMDKs onto different LUNs of different tiers. I've been reading this is not a recommended practice. I've attempted to locate this using google but I haven't found any hard and fast rules.

I'm looking for the features that you loose when seperating the disks on separate LUNs.

As a side note we are an IaaS company and I'm concerened about the management of seperating client information over various LUNs. We also would like to leverage SDRS.

Thank you kindly,

Steven

[Josh26]

You fast create a management nightmare for absolutely no gain.

The biggest drawback you run into is when you snapshot a server, and the snapshot disks don't end up where you're expecting. I've seen more than one outage due to a full LUN in this scenario.

[chriswahl]

I'd say that's a bit of a legacy approach to storage architecture, such as having a single VM with a system VMDK on NL-SAS or SATA and an application VMDK on SAS. The idea these days is to put some sort of cache or tiering mechanism (such as EMC FAST) in front of the disk to handle performance differences for you.

[TedH256]

The only real down-side to having VM disks on separate datastore is the potential management headache.

If you have a system, including a naming system, that is faithfully executed then it should be no big deal. For some implementations we have created  datastores just for OS disks (because they are low iops and grouping them plays into deduplication strategies) and different datastores for "data" disks. It allows us the flexibility of shaping the iops characteristics of each datastore/lun. But that's pretty detailed planning and management and all one company (not a hosted or multi-tenant environment).

I am curious what storage you are utilizing?