2008r2 cluster w/SD across 2 esxi 4.1 hosts

[daniel_kaiser]

Hi,

Can someone clarify the below text that was pulled out of the SD 6.3 admin guide.

"Microsoft virtual machine clusters cannot be part of a VMware cluster." - We have a 5 node esxi cluster. If we wanted to implement 2008r2 clustering w/SD, we would have to build two separate esxi servers that sits outside of the vsphere cluster?  Am i interpreting this correctly?

"A single initiator group must be created for both nodes in the cluster." - Currently we have a 5 node esxi cluster and a single igroup.  Does this mean I have to create a separate igroup for the esxi nodes that's hosting the 2008r2 clusters?

Any clarification on this is greatly appreciated.  My interpretation of what's in the admin guide and also the release notes means that I would have to have two dedicated ESXi hosts just for a 2 node 2008r2 cluster (hosting sql).  If this is the case then what's the point of setting up two dedicated esxi servers for clustering vs setting up two physical servers.

This is also in the release notes for 6.3

"SnapDrive also has the following ALUA support requirements and limitations:
• You can use SnapDrive to create LUNs and then map them manually to existing ALUA-enabled
igroups.
• You cannot use the same FC initiator for both ALUA enabled and ALUA disabled igroups.
• ALUA is not supported on a VMware MSCS cluster.
If SnapDrive is used to create a shared disk on an ESX 4 VMware MSCS cluster, ALUA is
disabled on the igroup that SnapDrive automatically creates.
If you use SnapDrive to create a shared disk in a VMware MSCS cluster when an FC igroup
already exists with ALUA enabled, SnapDrive automatically creates an igroup with ALUA
14 | SnapDrive 6.3 for Windows Release Notes
disabled, and logs an error in the Event Viewer indicating that ALUA is enabled for one of the
initiators on the storage system."

admin guide pg. 52

Microsoft virtual machine clusters cannot be part of a VMware cluster.
• You must use VCenter credentials and not ESX credentials when you install SnapDrive for
Windows on virtual machines that will belong to a Microsoft cluster.
• A single initiator group must be created for both nodes in the cluster.
You can create the initiator group automatically during disk creation or connection using the
SnapDrive MMC. SnapDrive automatically selects an FC initiator from each of the ESX servers
in the cluster. You can also create the initiator groups manually. If initiator groups do not already
exist, you must create one manually on the storage system.

Message was edited by: daniel_kaiser

[mbonneau79]

Thtat's correct, the ESXi servers hosting the clustered guests cannot be a part of an HA cluster.

The point is more about resource utilization and centralized management more than anything, we've got 2-node Exchange DAG, 2 CAS+Hub servers, 2-node DHCP cluster, and a 2-node SQL 2008 cluster running on a trio of servers outside our HA cluster along with a pair of domain controllers.

For my 3-node non-cluster, I just made the iGroup manually and added all of the initiators. Map the iGroup to the RDMs and configure the VMs through the vSphere client.

I was going to try installing a 2-node test cluster onto an HA cluster with HA configured to not restart the VMs and leave them powered on, as well as turning off DRS migrations for those servers, but haven't gotten around to trying it. It's definitely unsupported and not recommended, but I don't know how that would behave.

[daniel_kaiser]

"For my 3-node non-cluster, I just made the iGroup manually and added all  of the initiators. Map the iGroup to the RDMs and configure the VMs  through the vSphere client." -Are you using SnapDrive for your 2-node SQL cluster and any of your other clusters? Per the NetApp release notes for SD 6.3, it states that you cannot use the same FC initiator for both ALUA enabled and ALUA disabled igroups, plus MSCS only supports ALUA disabled igroups.

We only have a total of 5 ESXi servers in an HA vSphere cluster and I would hate to take two servers out of this setup and make them independent just for VM clustering (MSCS).

[mbonneau79]

Sorry for the delay, yes that's correct. ALUA is set on the igroup, so you have to choose when you build the server if you're going to use MSCS on it or not.Two ESX hosts with clustered SQL server guests will not use ALUA on their igroup as it can cause problems/corruption during storage failover.

Now, I have *heard* that you can actually still enable ALUA on the igroup for the MSCS hosts, but the pathing policy has to be set to Most Recently Used. I have not been able to verify or test this statement at all.

My problem with not enabling ALUA is it seems as though Virtual Storage Console can only optimize the MPIO settings if ALUA is enabled, otherwise you're stuck configuring fixed pathing.

But then again, I have 6 clustered hosts and two unclustered hosts specifically reserved for MSCS guest VMs (Exchange DAG and SQL failover cluster) so the limitations don't affect me noticeably.

[sbrooks15]

http://www.vmware.com/pdf/vsphere4/r41/vsp_41_mscs.pdf

Read Section - Use MSCS in an HA/DRS Environment

Maybe you can give me an answer, how do I make an RDM in NetAPP?  I would go into the CLI, and type lun setup.  Then what do I format it to?

[mbonneau79]

You need to choose the format which corresponds to the guest OS you're using. If you are creating a LUN for a windows server cluster, you choose Windows for the LUN format, and then map the igroup to that LUN. On the VMware side you refresh the storage settings and the new LUN should be available, then you add an additional hard disk to the virtual machine and choose the LUN to mount as an RDM (Physical compatibility). The guest OS can then initialize and format the LUN and use the space. Be sure to set SCSI bus sharing to Physical and make sure the RDM is attached to it's own SCSI adapter.