Comments on: Virtual Storage Design: Application Consolidation

By: Technology Short Take #13 - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers

Mon, 05 Sep 2011 06:19:29 +0000

[...] post on application consolidation by Scott Drummonds is an old post (from January 2010), but it’s still a good one. In this [...]

By: Scott

Scott — Tue, 19 Jan 2010 21:47:06 +0000

Yes, this data assumes one LUN per RAID group.

Scott

By: Nakoosa

Nakoosa — Tue, 19 Jan 2010 19:20:59 +0000

Thanks for sharing another thought provoking post.

“sequential access pattern files should be separated to their own LUNs”

Is this assuming 1 lun per raid group?
-Nakoosa

By: Scott

Scott — Mon, 18 Jan 2010 17:57:52 +0000

Didier,

The paper details the impact of sequential and random access workloads on each other and its basic conclusion is that only sequential workloads are harmed. That means that backup behavior, initiated by the guest and resulting in sequential IO, would be slow when mixed with random workloads. The random workloads would be unaffected, assuming adequate spindle count.

vscsiStats can be used to collect the access profile of a VMDK, but data collection and analysis can take many minutes per VMDK. So, it is difficult to do for hundreds of VMDKs. Here is information on vscsiStats:

http://communities.vmware.com/docs/DOC-10095

VMware and its storage partners are each working on tools that will automate the placement of VMDKs and hot blocks on faster storage. I have heard that EMC’s V-Max will do this but I will have to refer you to EMC (or the other storage vendors) for more information. It will take some time before VMware includes this type of feature in vSphere.

Scott

By: PiroNet

PiroNet — Sat, 16 Jan 2010 10:39:06 +0000

Hi Scott, great post, looking forward the others…

What’s the impact of (on) backups which are heavily sequential on (of) those random access VMDKs?

What are the tools available to find out what are the random and sequential access VMDKs?

In my environment, the VMDKs are so dynamic, some of them may appear random but sequential at month or quarter ends, for others it’s just the opposite. Anyway at any givent time the users needs their data without delays!

What I would need, is a storage that evolves dynamically along with my VMDKs, something behind the scene that move the VMFS to proper metavolumes… Does that exist?

Thx,
Didier