Enterprise-class organizations invest heavily in technologies to help them remain functional during a data center-level...
disaster, while hoping such a situation never occurs. But what if it does? What if your data center burns to the ground tomorrow? Does your IT department have a failover plan, and would they know what to do to maintain operations?
Hopefully, failing over to an alternate data center is something your organization has rehearsed countless times. If not, here are some things to consider as you develop a failover plan of your own.
Verify the scope of the disaster
Is the situation dire enough to warrant a full data center failover, or are some systems still functional? Are key staff members available to help with the failover plan? The answers to these questions will help determine the most suitable course of action.
Be aware of application dependencies
There is usually a lot more to a data center-level failover plan than bringing virtual machines (VMs) online in a remote data center.
Your ultimate goal is to keep mission-critical applications running. VMs are the infrastructure components in which your applications run. It is the applications themselves that matter. Getting all your VMs to run in a remote data center does not guarantee application functionality. Applications often have dependencies to address before an application can run.
Some of the more common dependencies include domain name system (DNS), Active Directory or a database. Microsoft Exchange Server cannot function without access to Active Directory, and Active Directory cannot function without DNS. You may have to reconfigure some of your VMs to point to a different DNS server before you can use Active Directory or Active Directory-dependent applications.
Consequences of running applications in the primary data center
If the primary data center has been reduced to a smoking hole in the ground, it's probably safe to assume that no services are running there. If the event is slightly less catastrophic, a few resources may remain online. This probably seems OK, but having a few random services running in their original location when everything else has failed over to an alternate location can cause problems.
For example, mailbox servers such as Exchange Server 2013 use an Active/Passive availability model. If one or more of them are still running in the primary data center, those servers could cause problems when moving Exchange-related services between data centers. In fact, Microsoft recommends terminating any remaining Exchange Server services in the primary data center.
Understand application-specific requirements
Even after you have moved virtualized application servers to a secondary data center, there may be application-specific requirements for returning some applications to a healthy state. In the case of Exchange Server, there is a manual activation process that must be used to activate the mailbox servers and client access servers. Other distributed application servers may have similar requirements.
Transitioning workloads to a secondary data center following a disaster can be a complicated process, so it is important to have a failover plan and understand this process before disaster strikes. There is more to the transition than just restoring service. Once your applications are up and running, monitor the system for any potential problems and establish mechanisms that can protect applications and data if a disaster strikes before the primary data center is back online.
Data center DR template, best practices
Failover server clustering not the same as business continuity
Try pulling plug on data center for DR test