VMGuru.com - Home of the Virtualization Gurus

I was recently asked a question by a reader that made me realize some further explanation was required. The question as posted to me was the following:

Why should a zoned lun not be shared between clusters? I tried to find an official stance from VMWare on the communities section and the only information I could find was that you could share a lun between clusters or more accurately between all ESX host in multiple clusters. I would rather not share the luns between clusters, but a team member seems to be bent on doing it. What reasons personal, political, or technical led to the statement in the book about not having luns cross environmets?

There are several reasons I would never do it in an environment that I was designing.

1) You want to limit the number of hosts connecting to any particular storage volume. This is primarily for performance reasons. If you have say, 20 hosts, each with 2 data paths, all talking to the same LUN for multiple virtual machines, you likely have a lot of disparate I/O going on between host and array. VMFS as a file system cannot effectively handle more than 16-20 hosts all talking to the same LUN at the same time actively (Although the cluster limit was bumped from 16 to 32). The idea here, is you will never have all 32 hosts of a cluster communicating to a single LUN at the same time due to how you spread your VM load.

2) Assigning all LUNs to all hosts is a management nightmare. Services such as VMotion, DRS, and HA cannot function across multiple clusters, so the primary driver of "shared storage" no longer exists. Forcing the ESX Admin into ugly management of determining "Where can I put particular VMs for a particular cluster without impacting another's performance?" will become extremely tedious. Simply not zoning a LUN to a group of servers is something a storage admin SHOULD be familiar with and should have no impact on the backend infrastructure... Managing a nasty spider web of data paths is hard enough within a single cluster...let alone multiple. I consider this on par with why you would VLAN a network. Just because you CAN create a giant class A for every node in your network, why in the world would you?

3) Data security is another reason. If your clusters serve particular purposes such as DMZ vs Internal vs Partner/Customer clusters or simply Prod vs Dev, you don't want to have the ability for someone to accidentally map storage of an internal or partner system onto a DMZ server. While controls should be in place to prevent it from a process perspective, you will never be able to fix "human error", unless you simply make it impossible to do.