Virtualization Strategies for the CIO
For optimal Hyper-V cluster performance -- especially in multi-site disaster recovery configurations -- you'll have to tweak the default settings.
This configuration requires extensive
Requires Free Membership to View
work in the Windows Failover Cluster console, but it's the final step in a Hyper-V disaster recovery implementation. Previously, we covered the various types of virtual machine (VM) protections, how to choose a secondary site and the installation of components. So if you made it this far, you're almost done with the process of setting up Hyper-V disaster recovery sites .
To improve Hyper-V cluster performance first install the Failover Clustering service onto nodes in the secondary site, then run the Validate a Configuration wizard.
 |
||||
|
|
|||
|
||||
Next, add the new nodes to the cluster. When extending a cluster to multiple sites, consider these additional configurations for the best Hyper-V cluster performance.
Ensure that IP address dependencies are joined with the conjunction "or"
Multi-site clusters that stretch across multiple subnets force virtual machines (VMs) to change IP addresses during failovers. The new subnet in the secondary site will have a different range of IP addresses than those in the original site's subnet. So two steps are necessary to ensure that the VMs remain operational after a failover.
First, VMs should be configured to respond to addresses at both locations either through direct addressing or Dynamic Host Configuration Protocol assignment. Second, update the VM's cluster resource to join its two potential IP addresses with an "or" to ensure that a VM is not considered a failed resource when its IP address changes after a failover.
Adjust health checks for latency
Generally, the greater the distance between sites, the greater the latency. Latency can affect the cluster's built-in health checks. You can use four configurations with the cluster.exe tool or, more appropriately, the following Windows PowerShell commands to monitor latency:
- SameSubnetDelay (in seconds);
- SameSubnetThreshold (in number of heartbeats);
- CrossSubnetDelay (in seconds); and
- CrossSubnetThreshold (in number of heartbeats).
If you encounter VMs that fail over at inappropriate times, adjust these four metrics to tolerate greater latency.
Reconfigure network name properties
Not only does a failover force a VM to change its IP address, but it takes time for clients to recognize that a VM's IP address has changed.
You can fix this by running the ipconfig.exe /flushdns command on every client, or you can adjust either of the following options through Windows PowerShell:
- RegisterAllProvidersIP (which defaults to 0 for FALSE) determines whether all the VM's potential IP addresses for its Network Name resource are registered in domain name server (DNS) instead of just its primary address. This step ensures that the DNS has all of the necessary IP addresses for the VMs.
- HostRecordTTL (which defaults to 1,200 seconds), on the other hand, adjusts the time-to-live value for the DNS record. Dialing down this number reduces the time it takes for clients to flush their cache and request updated record information.
Encrypt cluster communication
By default, cluster communication is transferred in cleartext. Usually, this isn't a problem in a protected local area network, but trouble can arise when you pass cluster traffic over shared Internet connections, such as Multiprotocol Label Switching. With Windows PowerShell, you can instruct the cluster to encrypt its intra-cluster traffic with the command Get-Cluster | ForEach-Object { $_.SecurityLevel = 2 }. Using the cluster.exe tool, the command is cluster /prop SecurityLevel=2.
Guarantee a local failover first
Unless you provide an ordered list of preferred owners, a cluster will fail over a resource to the next available node. In the Failover Cluster Management console, this list is configured under the General tab in the VM's resource properties. Then look for the list of preferred owners. It's a best practice to configure this ordered list for all VMs to ensure that they fail over only when there aren't available nodes at the local site (e.g., during a disaster).
Update the cluster quorum model
When extending a cluster to a second site, a single-site quorum model may affect Hyper-V cluster performance. There are four cluster quorum models and each slightly changes how a quorum is defined. In multi-site clusters, the quorum model of choice is the Node and File Share Majority model. This model requires a file share on a file server for the quorum data storage. The best possible configuration has that node located at a different site than your other cluster nodes.
Ultimately, setting up and improving Hyper-V cluster performance isn't that difficult, and it doesn't need to be costly either. After these clusters have been deployed, you'll have guaranteed protection against virtual machine downtime and data loss.
|
|
|
|
|
|
This was first published in May 2010
Join the conversationComment
Share
Comments
Results
Contribute to the conversation