locked
How well does AlwaysOn work over a WAN RRS feed

  • Question

  • I've got a DR requirement to replicate up to 100 databases over a WAN separated by approximately 800 miles. The network circuit will be 100mb and not totally dedicated for DR. Transaction volumes are generally light but with occasional moderate bursts. Lag time on the DR databases needs to be kept to a few seconds at most so log shipping is not an option. My first inclination is to use mirroring but I was also considering 2012 AG's and wondering if anyone has had any experience with using them over a WAN. How well it has worked out. What are the gotcha's to look out for?

    I realize that 2012 AG's require a clustered environment and I have no experience with clustering over a WAN either. I know it's supported,  but what special considerations are there for this? For example I would not expect the heartbeat network to have the same low latency as a one running over a dedicated VLAN. 


    Chuck

    Tuesday, July 31, 2012 2:27 PM

Answers

  • This is precisely the scenario that AlwaysOn Availabiliy Groups was designed for.  You use a Failover Clustered Instance for local High Availability and AGs for remote DR.  Since it is all based on a multi-site cluster, the configuration takes a lot of planning, but once it is set up correctly it is very easy to manage.  The dashboard will quickly show whether everything is working or not.  Here are few key data points:

    Remote Replicas should be async.  This will prevent automatic failover, which is desirable.

    The data stream is automatically compressed if it is at least 40% reduced, so it is highly efficient on bandwidth.

    Plan for future replicas even if you won't use them.  This will force you to reserve IP addresses.

    Good luck.


    Geoff N. Hiten Principal Consultant Microsoft SQL Server MVP

    • Proposed as answer by amber zhang Wednesday, August 1, 2012 8:55 AM
    • Marked as answer by chuckh1958 Wednesday, August 1, 2012 12:50 PM
    Tuesday, July 31, 2012 7:31 PM

All replies

  • Hi,

    Have you thought about SQL replication? Preferably some of the transactional ones (not snapshots)


    Sebastian Sajaroff Senior DBA Pharmacies Jean Coutu

    Tuesday, July 31, 2012 3:16 PM
  • I'm not a big fan of replication. I prefer a low maintenance solution that replicates everything automatically. Hence I prefer log based solutions. I use log shipping extensively to copy databases from a remote location to a local data center to run tape backups.

    With replication if someome creates a new table or index, it doesn't get picked up automatically. With log based solutions, it does.

    I also need my DR database to have extremely low latency. With replication or even log shipping the DR database is only as current as the last time the agent job(s) that refreshes it ran. With mirroring or alwayson we're talking maybe a second or two of latency.

    My biggest concern with AlwaysOn is the WAN. I just don't know how reliable well clustering will be over a WAN.


    Chuck

    Tuesday, July 31, 2012 3:48 PM
  • Hi!

    The main thing you have to ensure is that your cluster quorum is set up correctly. (mostly in your scenario this means having no votes for the DR site, so link loss does not impact your primary site.) Other than that ASync secondary over WAN works quite well, many people are using it.

    Lucifer

    Tuesday, July 31, 2012 5:08 PM
  • Thanks. 

    My setup will likely be 2 local nodes in the same chassis with traditional SQL clustering, shared storage, etc; and one node at the remote site for DR. I still need to figure out the logistics but it sounds like it's both do-able and desirable.


    Chuck

    Tuesday, July 31, 2012 5:29 PM
  • This is precisely the scenario that AlwaysOn Availabiliy Groups was designed for.  You use a Failover Clustered Instance for local High Availability and AGs for remote DR.  Since it is all based on a multi-site cluster, the configuration takes a lot of planning, but once it is set up correctly it is very easy to manage.  The dashboard will quickly show whether everything is working or not.  Here are few key data points:

    Remote Replicas should be async.  This will prevent automatic failover, which is desirable.

    The data stream is automatically compressed if it is at least 40% reduced, so it is highly efficient on bandwidth.

    Plan for future replicas even if you won't use them.  This will force you to reserve IP addresses.

    Good luck.


    Geoff N. Hiten Principal Consultant Microsoft SQL Server MVP

    • Proposed as answer by amber zhang Wednesday, August 1, 2012 8:55 AM
    • Marked as answer by chuckh1958 Wednesday, August 1, 2012 12:50 PM
    Tuesday, July 31, 2012 7:31 PM
  • What will happens if primary site lose connectivity to DR site in this scenario? (One sync local secondary, and one async remote secondary)?

    Losing WAN connectivity for a mins, it should pick it up.

    How about losing WAN connectivity for several hours or days? Will SQL suspend the DR replica itself after certain timeout?

    Thanks,

    Kuzey

    Friday, May 29, 2015 10:04 PM
  • What is the recommended bandwidth for such case?
    Thursday, March 2, 2017 9:30 AM