Multi Site Exchange DAG Failover - Solving WAN IP Availability
So you decided to deploy a high availability Microsoft Exchange environment. You created a Database Availability Group for the databases on the Mailbox servers, carefully thought out the mailbox server roles and even deployed multiple Client Access Servers at two different sites with a nice WAN connection between them for timely synchronization. Your Exchange DR strategy is looking pretty good and you’ve begun testing.
But now your big problem is how to make the Client Access Servers highly available. When one site goes down, how do the users connect to the other site? Internally, on the network, there are a few ways to get around this, but externally where mobile users always reside, it becomes rather tricky. If the users are using a Fully Qualified Domain Name (FQDN) that points to an IP address at your primary site, how do you update it to the address of your DR site when the primary is unavailable?
Sure, you could configure a single namespace for your Client Access Servers instead of a separate FQDN for each and then set Outlook Anywhere to use that instead. With that approach, the namespace gives out multiple IPs in DNS. This all works reasonably well when all servers are up, except that some traffic still routes through your DR site causing extra latency for 50% of the users as they traverse the WAN, and if one site goes down Outlook will eventually try another, but this is far from ideal due to the reattempt time. Plus, it does nothing for mobile devices, and with the CIO constantly checking email on her mobile, you know firsthand that Murphy’s Law guarantees she’ll be checking email the moment the primary goes down and have a few words for you.
Yes, you could remove or change the DNS record of the primary site when down, but even with a low TTL, it doesn’t always work quite the way you want it to, even if you go the extra mile and use a DNS Failover Service or some sort of automation tool to make it as fast as possible. We’ve seen cases were mobile networks, especially Verizon Wireless, simply cache the DNS record for hours, even though you had the TTL set to 60 seconds. So what’s the solution?
The Killer Exchange Load Balancer in the Cloud
Our answer to all of the above: Implement Total Uptime Cloud Failover
I know, you’re thinking “Cloud, I hate everything named Cloud”. But hear us out for just a minute. For $49/month or less, we give you a static virtual IP (VIP) attached to multiple high-end Layer-7 load balancers in datacenters all over the world. This is not the Cloud you’re thinking about. It is a purpose-built Network-as-a-Service platform designed to solve problems exactly like this Exchange WAN Failover challenge.
You take the VIP assigned to your configuration and publish your OWA, ActiveSync, Autodiscover and other DNS hostnames to this IP address. Now, you head over to our management interface and configure “routing”, for lack of a better term, to determine exactly where you want traffic to go. When completed, traffic that enters our network on your VIP goes exactly where you want it to go…. either manually, or automatically based on CAS health using Exchange’s built in health check page that we can poll every minute.
Of course, you can take it a step further too! Perhaps you want to load balance traffic over all active CAS, and when one is detected as down, automatically remove it from the pool so it no longer receives traffic. Or, maybe you want (or need) your DR site to sit idle, waiting for your primary CAS to become unreachable, and when it happens (because you know it will eventually!), we automatically send traffic there, ensuring you maintain the availability your CIO demands.
Sounds too good to be true? It really isn’t, and is actually attainable right now. This is what Total Uptime’s Network Failover Solution is exactly designed to do. And not just for Microsoft Exchange either. Remote Desktop Servers, Citrix XenDesktop, VMWare View, you name it. If it needs to be accessible externally, we can help you maintain availability.
Other posts you might like...
Downtime costs $7900 per minute, on average
The cost of datacenter downtime has increased more than 40% for many companies over the last 3 years, according to a recent study by Ponemon Institute, sponsored by Emerson Network Power. The report analyzes 67 datacenters...read more
What are the key differences between DNS Failover and Cloud Failover so I can better understand which one is right for my application?
Both solutions require that you tell us what the IP address(es) are for your ‘real servers’. That way we know how to alter DNS or route traffic...read more
Apple Suffers $32 Million Dollar DNS Outage
Yes, even the biggest and best organizations can suffer tremendous losses due to something as simple as a DNS issue. Unless you are immersed in DNS and it is one of your core competencies, it is easy to make a mistake, and that may be what transpired at Apple.read more