Disaster recovery implementation requires precise planning and numerous interconnected components.
After you've hammered out the disaster recovery logistics as discussed in parts one and two of this series -- such as how to protect virtual machines (VMs) and selecting a secondary site's infrastructure -- it's time to execute a disaster recovery plan.
In this portion of our series, we cover three steps for adding the necessary hardware, connecting networks and implementing replication to a secondary disaster recovery site with Microsoft's Hyper-V.Disaster recovery implementation step one: Add servers and storage
The first step is to deploy servers and storage at your remote site, which does not have to be in a third-party's data center. If your organization has remote offices or additional branches that can host servers and storage, using this branch-office space may significantly reduce the disaster recovery implementation costs.
Remote sites tend to have the necessary networking technology and sufficient bandwidth to handle VM replication activities. If you calculated bandwidth as you planned the secondary site's infrastructure, you will have the right networking ready to go.
Also note that a Windows Failover Cluster can use a variety of storage replication mechanisms. Some storage replication technologies directly plug into Windows Failover Clustering, creating a new disk resource type. Others, however, may accomplish the replication without notifying Hyper-V.
Additionally, your Hyper-V cluster "believes" that it's attaching to shared storage that is divided equally among cluster nodes. It's up to you and the replication technology to ensure that the two storage devices remain equal.Disaster recovery implementation step two: Interconnect the networks
Windows Failover Clustering in Windows Server 2008 no longer requires that every node reside on the same subnet. This new capability reduces the cost and complexity of extending a virtual local area network across multiple sites, but it also introduces complexity in terms of virtual machine IP addressing.
Additionally, both primary and secondary site nodes have the same multiple-network requirements. One network is required for internal cluster communication, and the second is for production networking. If your cluster storage runs atop iSCSI, a third network may be required. Segregating these networks onto different subnets, or network paths, ensures that one network's communication doesn't affect the others. This is particularly true with iSCSI's high levels of network utilization in Hyper-V environments.
It doesn't matter whether a node is located at a primary or a secondary site; Hyper-V clusters need this separation for proper network traffic isolation.Disaster recovery implementation step three: Configuring replication and connecting servers to storage
The instructions in step one are vitally important for connecting servers to the storage in this step. Before you connect servers and extend a cluster to a secondary site, ensure that replication is correctly configured and operational
The steps involved in implementing replication depend on the solution you select. Before proceeding, replication at the storage level requires full synchronization between sites. Depending on the amount of storage that requires synchronization and the connection speed, the process can take time. Once it's synchronized, however, maintaining that mirror requires far less throughput.
After the first synchronization, add the necessary storage logical unit numbers (LUNs) to the cluster nodes in the secondary site. Remember: A replicated storage LUN operates just like an existing disk, which means you need to set up the correct path to the server (via an iSCSI or Fibre Channel connection). Depending on the technology, you also may need to bring these disks online and initialize them to make a LUN usable by the server. As a rule, disks must be visible within Disk Management on cluster nodes for the cluster installation to succeed.
Finally, two-way replication is a requirement for Hyper-V clusters because clustered VMs can migrate between the primary and backup sites at any point. A failure to implement two-way replication prevents the VMs from migrating back to their original nodes afterdisaster operations have ceased.
After these disaster recovery implementation steps, you're ready to work within Microsoft's Failover Cluster Management console. Adding servers into your now-extended cluster is the exciting part.
In the final article in this disaster recovery implementation series, we'll cover key tips and important commands to ensure that a cluster behaves the way you want.