sqlskills-logo-2015-white.png

AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using AlwaysOn Availability Groups

The new “AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using AlwaysOn Availability Groups” white paper was just published by Microsoft over the weekend.

I co-authored this white paper with Sanjay Mishra, Senior Program Manager in the Microsoft SQL Customer Advisory Team.

This paper covers one of the three common customer HA and DR design patterns discussed in Sanjay’s SQL Server 2012 AlwaysOn High Availability and Disaster Recovery Design Patterns post.  You can download the new white paper here.

A big thanks to Glenn Minch, the Content Program Manager for keeping the various aspects of the project going and also to the host of participating technical reviewers. The paper had 17 technical reviewers – including Lindsey Allen (MS), Juergen Thomas (MS), Mike Weiner (MS), Prem Mehra (MS), Yorihito Tada (MS), Curt Matthews (MS), Amitabh Tamhane (MS), Aditya Samant (MS), Daniel Janik (MS), Jimmy May (MS), David P Smith (ServiceU), Richard Waymire (SolidQ), Brent Ozar (Brent Ozar PLF), Wolfgang Kutschera (bwin.party), Paul S. Randal (SQLskills.com), Gianluca Hotz (SolidQ) and Ayad Shammout (Caregroup).

4 thoughts on “AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using AlwaysOn Availability Groups”

  1. Joe,

    First, thanks for your excellent job on that white paper. We used it and successfully set up and FCI + AG solution for HA and DR. Now for another client we are setting up an asymmetric cluster between two data centers. A standalone sql install in each center with Always On synchronous replica between the two (the latency is very low). I am a bit confused on how to set the quorum for this. The recommendation is Node + File Share. I am not sure where to put the file share? If I put it in the primary data center and the whole DC goes down, will I still fail over to the secondary DC automatically? What about putting it in the secondary data center? Do you have any suggestions or resources you could help me find. My Google skills are failing me on this one.

    Thanks

    1. Hi John,

      For AGs on FCIs – automatic failover is not an option (needs to be manual).

      Regarding File Share location – the answer really depends on several factors – but in summary you want to make sure that you don’t have false-loss of quorum if your file share is placed somewhere unstable. I would be biased towards placing it in the same DC, given that automatic failover isn’t an option anyhow. This differs from DBM advice – where having the witness outside of the DC might be beneficial (third data center, for example, or cloud-solution).

      Best Regards,

      Joe

      1. Thanks Joe. To clarify on this setup we are not doing a FCI + AG. That was our first setup. On this one we are doing a standalone sql install in each DC and using automatic failover. So it looks like somewhere outside the both dc’s would be the best?

        1. Hi John,

          I think it all depends on stability of connection between the voting members and ensuring you don’t get false loss of quorum and votes.

          One quote from Microsoft is “The file share witness can be located at a third site, that is, a different location from the main site and secondary site, so that it is not lost if one of the other two sites has problems.” But if your third site is spotty or connectivity is bad, then local to the primary DC would be another choice I would consider.

Comments are closed.

Other articles

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.

Collaborate With Us
Choose a Course