VMFS Design Question

[LanceSimpson]

We are in the process of re-designing our VMFS datastores to allign with some storage replication strategies. As part of the strategy we will leverage SRM to build some recovery plans, but we will also have some VMFS replication done at an array level independant of SRM. The design will cover several different VM Host clusters, all in a primary data center. In thinking thru the options available, it seems easier to me to create storage profiles and assoicated datastores what will span the various clusters, as opposed to creating seperate datastores and storage profiles for each cluster.

I am curious what others have done, by in relation to designs for replication as well as just basic VMFS storage design. Is spanning clusters with storage a bad idea? What is the community doing as far as VMFS size/VM's per Datastore best practices. I have done quite a bit of reading but look forward to a discussion with those in the trenches.

[MauroBonder]

Hello,

I hope that this link can be useful for you - http://www.yellow-bricks.com/2009/06/23/vmfslun-size/

Additionally you should take into account how many machines will be put on each VMFS overhead for no I / O, the same goes for how the machines will be allocated by volume, for example do not put a lot of heavy VMS with BD in the same LUN.
Take into account where 20% free as safety and good practice is that the swap + memory size set the virtual machine that is created when you power on the VM.

[ranjitcool]

Okay,

It is a bad idea to have datastores shared across clusters. Reason is hypervisor locks the meta data (the datastore file) when doing a write and multiple hypervisors in different clusters can cause some major issues randomly wanting to own the datastore.

Unless it is only for a few copy operations, I wouldn't do that.

My question here is why would you need to share a datastore across clusters - what are you trying to acheive here - can't all these hyps be in one cluster?

R

[LanceSimpson]

The primary reason for the separate clusters is 1.) difference in hardware/CPU , 2.) Difference in network connectivity. There are not enough physical NIC’s on the server to connect all of the networks on which we support VM and still maintain a sufficient level of redundancy.

In response to file locking, how would two hosts in different clusters act differently than two hosts in the same cluster in regards to data locks?

Lance Simpson

Storage / Virtual Infrastructure Support

[ranjitcool]

Okay, the hypervisors not being the cluster doesn't make any difference.

Only issue comes when you have many hyps and vms accessing the datastore across clusters - you will run into queueing problems and consequently resulting in storage network performance issues.

If the network through put is low enough, have you considered vlans as an alternate to adding more nics (considering you are not wanting to spend the bucks for the nics - vlans can do the job as well)

R

[LanceSimpson]

We use VLAN’s already, we require different physical interfaces because the different hosts connect to physical switches with different networks/vlans, a single interface could not service all of the VLAN’s because they are routed from the same physical device.

I still don’t see how spanning a datastore across clusters is inherently the problem, all of your points are around multiple hosts and VM’s connecting to a datastore, this takes place in clustering already. My initial concern was now that datastores are used for heart beating, how would that affect having a datastore used by more than one cluster.

The idea here is to simplify the implementation on the storage front, if I can avoid having multiple datastore clusters and numerous datastores by using a single set(s) of datastores across multiple clusters that seems preferable.

Lance Simpson

Storage / Virtual Infrastructure Support