Step-by-Step: Configuring a 2-node multi-site cluster on Windows Server 2008 R2 – Part 2

Integrating your storage replication with Failover Clustering


In Part 1 of this series, we took a look at the first steps required for building a multi-site cluster. We got to the point where we had a two node cluster that used a node and file share majority quorum, with no resources yet defined. In this section we will start where we left off and look at how your replication solution will integrate with your failover clustering. Because each vendor’s replication solution will be implemented differently, it is hard to have one document that describes them all. The important thing to remember is that you want to purchase a replication solution that integrates with failover clustering and is certified by Microsoft. Your choices are basically array based, appliance based or host based replication solutions. EMC makes both appliance-based and array-based replication solutions and seem to do a great job at both. EMC’s John Toner maintains a blog that is dedicated to Geographically Dispersed Clusters and if you are going the EMC route, I’m sure he could lead you in the right direction. All the major vendors have solutions, you will just need to contact them to get the details.

For this demonstration, I’m going to use a host based replication solution, SteelEye DataKeeper Cluster Edition, from my company, SteelEye Technology. It is so easy, that I thought instead of doing a long article, I would just record the steps and share it with you in a video. One of the advantages of host based replication is that you can utilize your existing storage, whether it is just some local attached disks, iSCSI or an expensive SAN. Host based replication can replicate across any storage devices.

Here is a summary of what you will see in the video.

  • Launch the SteelEye DataKeeper MMC Snap-in
    • Create a new DataKeeper job, define mirror end points, network, compression, etc.
  • Launch the Failover Cluster MMC Snap-in
    • Create a Hyper-V resource
    • Add a DataKeeper Volume Resource
    • Edit the properties of the DataKeeper Volume resource to associate it with the mirror created earlier
    • Make the Virtual Machine configuration dependent upon the new DataKeeper volume resource

That’s it! You are now done. Sit back and enjoy your new Hyper-V multi-site cluster.


In Part 3 of this series, we will tackle SQL 2008 multi-site clusters on Windows Server 2008 R2. There are a few more steps and some tips and tricks you will definitely need to know, so make sure you check back to get all of the details. In the meantime, if you need assistance, leave me a comment or contact me through SIOS and I’d be glad to help you out.

16 thoughts on “Step-by-Step: Configuring a 2-node multi-site cluster on Windows Server 2008 R2 – Part 2

  1. Pingback: Step-by-Step: Configuring a 2-node multi-site cluster on Windows Server 2008 R2 – Part 3 « Clustering For Mere Mortals

  2. Hi Admin
    thanks for unique info publishing on Integrating the storage replication with Failover Clustering. more help and informative page
    thanks again…………..really unique

  3. Pingback: 2010 in review « Clustering For Mere Mortals

    • Thanks for letting me know. The link referenced a site that was re-launched last week and apparently dropped some of my videos. I have asked them to put them back up, hopefully I’ll have it fixed before the end of next week.

      • Thats cool :) great content by the way, explains multi-site clustering really well.

        Am just wondering out of interest, what do you think are the advantages of doing a multi-site cluster architecture over mirroring with a witness in terms of availability and automated failover strategy?

        I do appreciate that disk replication through SteelEye is probably quicker than doing Synchronous Mirroring, and also you have the added over-head of redesigning application logic to allow for failover to mirror server (which is generally just a change of the connection string in most cases), but what am worried about with storage replication (independent of the DB) is that it will replicate integrity errors in the DB as well, basically its a server-level availability & automatic failover solution, not DB-level one, with mirroring it seems that you could get both.

        Also, with mirroring you get the added advantage that both servers are available for querying (the primary and mirror), with clustering the 2nd server (node) is on stand-by until it becomes primary, so you cant get any use out it.

        Am swaying towards mirroring, but maybe am missing something!.


      • Database mirroring is good in many circumstances. The biggest difference is database mirroring replicates a single database where multisite clusters replicate the entire SQL instance. Some of the limitations of database mirroring are that it does not support databases that participate in distribute transactions and not all applications support the failover mechanism associated with database mirroring. Also, database mirroring addesses just SQL replication; if you have other data outside of SQL that needs replication and failover you will need to find a solution for that as well.

    • I just tried to email you with the email you supplied in your comment but it bounced back as undeliverable. Comment again with an active email address and I will send you an email.

  4. Pingback: infrastructure | Pearltrees

  5. Hi Daveberm
    could you recommended a similar document for windows 2012 r2 ? or general design doc for windows 2012 r2 hyper-v multi site cluster

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s