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?
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.
I came across an interesting article recently at IT World entitled Microsoft adds load balancing as Azure availability stutters. The unfortunate part of the story is that Azure storage and SQL services suffered a 1 hour outage at all regions, but the positive news was that Microsoft is trying to catch up to Amazon Web Services […]
A common inquiry we receive is whether or not any of our solutions have the capability to automate switching inbound traffic between common office WAN Internet connections, such as DSL, Cable and T1 lines. The quick answer is “absolutely!” Total Uptime Failover solutions are perfect for automatically failing inbound traffic over these types of WAN […]
When implementing a failover solution, the most common questions we receive are: How can we architect a failover solution for our application? How quickly can we failover from the primary site to the secondary site? How quickly can it fail back when the primary comes back online? Is there a way to prevent automatic failback […]
As we talk to people during the week, we periodically make suggestions for using Cloud Load Balancing or Failover that are often met with surprise, such as “Oh, I didn’t know it could be used for that”. So we thought it might be helpful to compile a list of 8 potential uses. Of course, it […]