Exchange 2007 CCR - VMware HA and DRS?

[jbaxter714]

I know that you can't put a traditional Microsoft Cluster in a VM Cluster for HA/DRS. I've seen a couple of different reasons for that posted..

Does this change with an Exchange 2007 CCR (Cluster Continuous Replication)? There's no shared storage (each maintains individual storage), and there's an independent file share witness to avoid split-brain...

Same sort of question for database mirroring with SQL 2005...

[TomHowarth]

Appart from the fact that it would be completely unsupported by microsoft (unless you are a very large customer) I can't see any reason why not. by the way, it is not the shared storage that stops the ability to do HA/DRS on MSCS but the necessity to have the nodes on local storage rather than SAN.

Therefore if you can create a CCR exchange07 enviroment on Shared Storage then there is no reason why HA/DRS would not work. however if there is the dependancy on local storage for the nodes then no you will not be able to utilise HA/DRS, You would not be able to Vmotion either.

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

Kind Regards

Tom,

[jbaxter714]

Is that an MCCS requirement for local storage, or a VMware requirement? I've never done a Microsoft cluster on VMware, so I hadn't even looked into it yet.

We're an iSCSI shop, so I could always put a software initiator inside the virtual machine if necessary?

[Dave_Mishchenko]

It's a VMware requirement. The below is taken from this thread: http://communities.vmware.com/thread/83511

Hi Mike, it's not simply a trouble shooting issue.

And it has nothing to do with paging either.

Simply put MSCS is a bit "itchy" when it comes to timeouts.

If there is a SAN fabric event like a fail-over,

we have to put the VM to sleep until we can handle the IO.

(remember, no caching in the vmkernel)

This can be longer that the failover time, causing the standby node to try take control of the cluster resources.

When the originating cluster owner is rescheduled to run again,

it has no concept of time passing nor that it's resources are now owned by the other server, if sucsessful in grabbing them.

We then have a split brain cluster.

Now this is a unforseen side effect of virtualization,

but MS puts similar restrictions in regular HW.

Not 100% sure about boot from SAN,

but you do need separate HBA for OS and data/quorum.

MS is going away from SCSI reset for control mechanics for this exact reason in Lonhorn.

"No longer uses SCSI Bus Resets which can be disruptive on a SAN"

- Anders <!-- BEGIN attachments ><! END attachments ><! BEGIN content details -->