Tip

Disaster recovery implementation with Hyper-V

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

    Requires Free Membership to View

(VMs) and selecting a secondary site's infrastructure -- it's time to execute a disaster recovery plan.

For more information on Hyper-V disaster recovery, check out the following resources.
Citrix Essentials for Hyper-V automates disaster recovery  

Disaster recovery strategies for Hyper-V

Virtual disaster recovery and server backup case study

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.

Greg Shields is an independent author, instructor, Microsoft MVP and IT consultant based in Denver. He is a co-founder of Concentrated Technology LLC and has nearly 15 years of experience in IT architecture and enterprise administration. Shields specializes in Microsoft administration, systems management and monitoring, and virtualization. He is the author of several books, including Windows Server 2008: What's New/What's Changed, available from Sapien Press.


This was first published in May 2010

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.