VM /ETC

This is something I commonly see, and is widely mis-understood. You have the answer partly there. Since MS does support iSCSI as a connection method to shared resources in an MS Cluster, you can use iSCSI to accomplish this easily. However, you don’t have to virtualize your storage in a VMDK to do this. Just think outside the box.

Just put a VM Network Port group on the same VSwitch where you have VMKernel for iSCSI. Then put a Virtual NIC attached to your iSCSI VSwitch. Load the MS iSCSI 2.0x init in the Guest VM, map your iSCSI volumes correctly and you can cluster away. Since at this point VMWare doesn’t know anything about a cluster at all, ESX just sees TCP/IP traffic. Something they are really good at as we all know, is networking.

Now you can have a multi-Node cluster, a VM to VM cluster on different machines, or a Physical to Virtual Cluster.

I have several customers already doing this. Works great!

Just come see me on Friday morning, since I’m going to be in your office with Kevin in the lab.

Wade

There are number of requirements both from a support and physical perspective that makes MS-Clustering and VMware Clustering affectively incompatiable. To be supported the VM’s boot disk must be on local storage – this kills VMotion, DRS and HA. Additionally, the second SCSI adapter has be set to be either “Virtual” bus sharing or “Physical” bus sharing. VMware appear to have a condition statement in DRS/VMotion – to the affect that IF=(Bus Sharing is enabled, Stop VMotion, Allow VMotion).

I’ve done some wacky configurations. Such as the quorum and shared volumes should be RDM’s for a cluster-across-boxes – and I’ve breached that and used virtual disks. Additionally, I’ve put nodeA and nodeB boot disks on shared storage, when to meet the support requirement they should be local. What did I find? Well, VMotion/DRS still didn’t work because of the condition statement – about the only part of DRS that did work was initial placement (keep apart) during power on. Interesting HA+MS clustering in this configuration did “work”. In the sense I that I had nodeA on ESX1 and nodeB on ESX2 – and when I pulled power-cord failover did occour. However, as far as VMware and MS is concerned this breach the support requirement of local storage. There are some good reasons for this requirement, not least that MS don’t support boot-from-SAN clusters in the physical world, never mind the virtual world.

The way forward I feel is increased and improved clustering support from VMware. To tell you the truth I loathe and dispise MS clustering with a passion. But if VMware can release “continious” HA this opens the door to clustering applications that can’t be clustered with conventional MS clustering software. They have already announced the ability to power-cycle a VM that BSODs. So we are also begin to see better VM-awareness of the GOS from a VMware Clustering perspective…

We’ve left the VM side out of the cluster equation and settled on a L4 device to do the load balancing for us. Gives us the ability to have the load go to the “other” node if one goes offline, while providing the ability to load balance traffic when both (or more) nodes are available. By taking the cluster side out of the virtual world and putting it on the network guys, as long as we have traffic flowing to the VMs, then we’re in a highly available configuration from a service standpoint, and our VM configurations are still capable of using all the great toys found in the Virtual Infrastructure. If we loose a ESX server, then we suffer a boot time event for one of the nodes. By using the L4 device, we can take the service degradation long enough for HA to kick in on the failed node. As a side note, this configuration also gives us the ability to do much more than a dual node cluster on some SOA levels. Case in point is that I’ve got 6 IIS servers providing balanced traffic to 20 application servers. The L4 lets us direct the traffic to the least busy IIS nodes while providing the insurance of service protection.

The one thing we don’t do effectively with this configuration is answer the database layer question. Still working on that one.

Some things work great in the virtual world, somethings still work easier outside of it. This in my opinion is one of them.

After discussing this with some contacts at VMware, the main issue here is whether or not a config like this can be or will be supported under a client’s SNS agreement. Bottom line though is that if a VM boots from a LUN that is on a storage device that is currently on VMware’s HCL than that’s all VMware requires. It should also be mentioned that even in a non-supported scenario VMware is usually good about providing best effort support. I would be surprised if the helpdesk did not try to help.

fixed link to image in post.

This post has been around for a while so I thought I would ask if these limitations are still present with the current version of ESX 3.5 Update 2?

I’m running ESX with an EqualLogic SAN. In fact I do believe that Wade in the first post was one of the presenters at our office last year It’s a small world!

Anyway, I’m looking for a solution that will allow me to setup VM’s in a cluster to support our SQL Server databases.

So far I have not found the “eureka” solution, but I’m still optimistic that it’s out there!

Richard,

MSCS support is basically still the same as it was since ESX version 3.0.1.

Duncan over at yellow-bricks.com posted about v 3.5 changes at http://www.yellow-bricks.com/2008/04/02/support-for-microsoft-cluster-server-mscs-in-35-update/

I believe the latest VMware .pdf on this topic is still http://www.vmware.com/pdf/vi3_35/esx_3/vi3_35_25_u1_mscs.pdf

I always loved this kind of IT stuffs and now I don’t know what to think about the career I decided to chose. I’m a Content freelancer writer and for a while I have to admit that this satisfied to me. But now I’m planing to learn something else and start new all over again.