7

I've seen two approaches to handling the presentation of shared storage to Windows Server 2008 R2 cluster VMs on VMWare vSphere. One is the traditional method of carving out a LUN on your SAN and presenting it to both hosts through the Microsoft ISCSI software initiator. The other method is to make a vmdk on an existing LUN and attach it to both hosts and made it an independent disk so that it isn't affected by snapshots.

Is one way the "correct" way, or are both viable? Is there any advantage or disadvantage to doing either?

8
  • 2
    oh such a good question... I hope we get a damn good answer Mar 28, 2012 at 14:29
  • While I'm not sure if one way is truly more "correct", I've always gone with a separate LUN, if only for the benefit of using the features of my SAN on the volume (snapshots, etc.)
    – Jim G.
    Mar 28, 2012 at 16:01
  • @JimG. Wouldn't a snap of the volume that the VMDK is on work just as well?
    – MDMarra
    Mar 28, 2012 at 16:15
  • VMware has a whitepaper here: vmware.com/pdf/vsphere4/r40/vsp_40_mscs.pdf Mar 28, 2012 at 18:29
  • Sure it would, but you may want to snapshot on a different schedule than your normal VMFS LUN, or just have a much smaller snapshot if you need to transfer. It's how I do it, but not sure if one way is technically better than another.
    – Jim G.
    Mar 28, 2012 at 19:08

2 Answers 2

1

The "traditional method" is supported when the cluster is across physical machines. The other method is supported when the cluster is on a single VMware host.

1

Both are viable, but as you say there are advantages and disadvantages.

One way to illustrate the difference is to think about vMotion-ing one of the machines in the cluster from one ESXi server to another. In the MS iSCSI initiator case, vMotion will not do anything with the disk. It's just treated as another process on the machine it is moving. However, in the VMDK case, vMotion knows it is a disk and can manage the disk migration along with the machine migration. VMDK has features that make vMotion work better that are not present in the MS iSCSI initiator case.

In the VMDK case, each ESXi server needs to have access to the VMDK if you want to vMotion between them.

I guess if we are talking traditional, the VMDK case is traditionally suited to VMware HA and no MS clustering. The MS iSCSI initiator case is traditionally suited to MS clustering and no VMware HA.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .