What’s New in Windows 8 for Hyper-V Based Cloud Computing (Part 10) - Hyper-V Disaster Recovery Features

by [Published on 3 Oct. 2012 / Last Updated on 3 Oct. 2012]

In this article, you learn about new disaster recovery features in Windows Server 2012 Hyper-V that you can leverage to provide high performance and scalable cloud environments.

If you would like to read the other parts in this article series please go to:

Background

A good IT disaster recovery plan includes both procedures and technology that allow a company to efficiently recover from events (e.g., natural disasters or others) that have the potential of halting or critically diminishing daily computing operations. Across the business spectrum, disaster recovery is an area whose profile continues to rise for institutions that want to avoid finding themselves in a situation where the loss of critical computing resources seriously impacts business production and revenues. In the case of small and medium businesses, implementing disaster recovery has been an even more challenging proposition because of the cost of the data replication and storage technology solutions. This challenge is further complicated by the shift to virtualized or cloud computing environments. The good news is that Windows Server 2012 includes a data replication component that helps to lower the technology component costs of disaster recovery implementations for virtual machine deployments based on Hyper-V.

Windows Server 2012 Hyper-V Replica

Windows Server 2012 enhances the failover clustering feature to provide a high-availability solution for Hyper-V based virtual machines within a single physical site or across geographically dispersed sites. With the new Hyper-V Replica feature, Windows Server 2012 now also provides a solution to replicate a virtual machine across geographically dispersed sites over a Wide Area Network (WAN) using a host-based, asynchronous process such that the replicated virtual machine is no more than 5 minutes behind the source virtual machine. In addition, Microsoft developed the Hyper-V replica feature to be both application and storage independent. This means that any application running in a virtual machine is supported because the replication occurs at the virtual machine level. Furthermore, different storage solutions can be used at different sites such that even if an expensive Storage Area Network (SAN) is used at the primary site for performance reasons, the disaster recovery site can use cheaper storage solutions, helping to reduce the hardware implementation costs.

Hyper-V Replica Functionality

Hyper-V Replica uses asynchronous replication between the primary and replica virtual machines. Hyper-V Replica duplicates writes to the primary virtual machine VHD file into a log file, and ships the log file to the replica virtual machine on a 5 minute cycle. While the primary virtual machine log file is replicated, new writes are duplicated into a new log file. In order to provide a robust transportation protocol that functions across LANs and WANs and that does not require major reconfigurations of firewalls, Hyper-V Replica uses HTTP for the replication traffic.

Because replicas are more likely to be configured to replicate to a server that is geographically distant from the primary virtual machine server, Hyper-V Replica is resilient to WAN failures through retry, resume, and resynchronization operations that attempt to bring the primary and replica virtual machine back in sync after network outages. Another Hyper-V Replica mitigation measure is to constrain the log files that contain the writes to be no larger than half of the size of the original VHD file. By default the log files are stored in the same location as the primary virtual machine VHD file, so this avoids filling up the physical storage device.

Hyper-V Replica also supports virtual machine mobility through Live Migration, Storage Migration, and Quick Migration within and across failover clusters to ensure that the migration of a primary or replica virtual machine does not compromise active Hyper-V Replica links. This does require that all primary virtual machine servers in the migration path are authorized on the replica servers such that as a primary virtual machine migrates to another server, the Hyper-V Replica link can be automatically reestablished with the replica server. Hyper-V Replica requires a Hyper-V Replica Broker to be configured if the primary or replica Hyper-V server is part of a cluster. The Hyper-V Replica Broker role is configured as part of a Failover Cluster. The Hyper-V Replica Broker interacts with Failover Clustering and Hyper-V networking to redirect virtual machine events to the appropriate node in a replica cluster. The Hyper-V Replica Broker accomplishes this through cluster database queries to determine the node that should handle a specific event.

Network Configuration for Virtual Machine Replicas

Because primary and replica virtual machines are likely to be located on different subnets, you have to select a strategy to deal with IP address changes that does not leave the replica virtual machine unreachable when it is brought online. The three choices that are available include using a static IP address, using auto assignment via DHCP, or using the new Windows Server 2012 Network Virtualization feature. Network Virtualization provides a hypervisor-level mapping between the network address assigned inside a virtual machine (Customer Address or CA) and a unique host-based network address (Provider Address or PA) which is used to route the packets on the physical networks. Of crucial importance is the update and propagation of the virtual machine replica DNS records throughout the infrastructure to reflect the IP address by which it is accessible.

Hyper-V Replica Server and Virtual Machine Replica Configuration

In order to use the Hyper-V Replica feature, a server must be enabled as a replica server. You can configure a replica server using PowerShell or the Hyper-V settings in the Hyper-V Manager console as shown in Figure 1. The replica server configuration requires defining the authentication type (Kerberos or Certificate) and port, whether any authenticated servers or only a specific set of servers are allowed to replicate virtual machines to the replica server, and the storage location for the replicated virtual machine files.


Figure 1: Hyper-V Settings in the Hyper-V Manager Console

A Hyper-V Replica can be configured for a virtual machine using Hyper-V Manager (as seen in Figure 2), Failover Cluster Manager, PowerShell, or System Center Virtual Machine Manager 2012 SP1. The Hyper-V Replica configuration process is unified across the Hyper-V Manager, Failover Cluster Manager, and System Center Virtual Machine Manager 2012 SP1.


Figure 2: Hyper-V Replica Configuration in the Hyper-V Manager Console

The Hyper-V Manager console leverages the Enable Replication Wizard which guides you through the selection of the replica server (the destination server), the configuration of the replica server port and authentication type (Kerberos or Certificates), the selection of the virtual machines to replicate, the configuration of the latest or multiple recovery points for the replicated virtual machine (recovery points are based on virtual machine snapshots), and the initial replication method and schedule. The initial replication is performed through a network copy, by using external media, or from an existing virtual machine on the replica server. Selecting the initial replication from an existing virtual machine assumes that you already have a backup of the virtual machine files on the destination server. In this case, only the incremental changes to the virtual machine files are replicated to create the initial Hyper-V replica. However, be aware that this option is only valid for enlightened virtual machines.

Monitoring Hyper-V Replica

There are multiple options to monitor Hyper-V Replica. In the Hyper-V Manager console, as shown in Figure 3, there is a replication tab in the virtual machine pane that allows you to review the replication type, state, and health. You can also view the primary server, replica server, and the time at which the latest synchronization took place.


Figure 3: Replication Monitoring in the Hyper-V Manager Console

In order to get more information about the replication health for a particular virtual machine, you can right-click on the virtual machine, select the replication option from the menu, and then select View Replication Health, as shown in Figure 4.


Figure 4: Replication Health Selection in the Hyper-V Manager Console

The Replication Health dialog provides status and statistics that assist you in assessing the condition of a virtual machine replica, including the number of errors encountered, the number of successful replication cycles, and the time of the last synchronization. As shown in Figure 5, if more than 20 percent of the replication cycles are missed for a virtual machine, the replication health status reflects a warning state, which should prompt you to investigate the cause of the unsuccessful replication cycles.


Figure 5: Replication Health Dialog in the Hyper-V Manager Console

PowerShell is also available to monitor Hyper-V Replica. Figure 6 shows a list of the cmdlets that are associated with Hyper-V replication.


Figure 6: PowerShell Cmdlets for Hyper-V Replica

Conclusion

In this article, you learned about the new Windows Server 2012 Hyper-V Replica feature that supports disaster recovery scenarios for virtual machines within a site and geographic location, or across sites and geographic locations. In the last part of this series, Part 11, you will learn more about the Hyper-V Replica scenarios that Microsoft supports with Windows Server 2012.

If you would like to read the other parts in this article series please go to:

Advertisement

Featured Links