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?

MDMarra
  • 100,734
  • 32
  • 197
  • 329
  • 2
    oh such a good question... I hope we get a damn good answer – SpacemanSpiff Mar 28 '12 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 '12 at 16:01
  • @JimG. Wouldn't a snap of the volume that the VMDK is on work just as well? – MDMarra Mar 28 '12 at 16:15
  • VMware has a whitepaper here: http://www.vmware.com/pdf/vsphere4/r40/vsp_40_mscs.pdf – JakeRobinson Mar 28 '12 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 '12 at 19:08
  • Ah, I understand what you were getting at now. It seems that there's no "definitive" answer for this. – MDMarra Mar 28 '12 at 19:53
  • I was under the impression that MSCS is only supported when you use physical RDM mappings – pauska Mar 31 '12 at 22:34
  • You can do "Cluster in a box" with a VDMK. Is RDM supported across separate hosts in a cluster? – MDMarra Apr 01 '12 at 01:20

2 Answers2

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.

Scott McKenzie
  • 11
  • 1
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.

Tom Ligda
  • 183
  • 1
  • 6