Windows Server 2008 R2 : High Availability, Live Migration, and Snapshots

1. High Availability, Live Migration, and Snapshots

Windows Server 2008 R2 fail-over clustering options can be used to provide high availability services to a Hyper-V host. By creating a fail-over cluster, you can ensure that all VMs running on a Hyper-V host remain online in the event a host failure. Fail-over clustering is also a requirement for Live Migration.

Live Migration

Windows Server 2008 R2 includes a much welcomed feature to enhance the process of moving VMs from one Hyper-V host to another. Windows Server 2008 R1 included a feature known as Quick Migration, which suspended VMs and quickly transferred them to another host. This process did however cause a brief outage to any VMs being moved. When using Quick Migration to move a VM, some applications on that VM might time-out and need to be restarted because of their sensitivity to network or machine disruptions.

Live Migration allows Hyper-V to overcome the limitations found in Quick Migration when moving VMs by removing the need for them to be temporarily suspended. This removes the requirement for brief downtime for applications running on the VMs being moved. Live Migration uses a process to transfer memory pages from the current host to the destination host and then simply transfers ownership of the VM’s virtual disks to the destination host. The Live Migration process is depicted in Figure 1.

Figure 1. Hyper-V Live Migration process.

Live Migration allows administrators to easily, on the fly, add new hosts to a Hyper-V cluster instantly increasing resources used by VM workloads. Live Migration can also be used to allow administrators to service hosts during normal business hours without impacting on business services and applications. For example, an administrator might want to add additional memory to a Hyper-V host. He could use Live Migration to move any active VMs from the host to another host in the cluster. He could then turn off the host to add additional memory. After adding memory, the administrator could use Live Migration to move the VM workloads back to the host.

Configuring Hyper-V to support Live Migration

Live Migration requires that Hyper-V be deployed on a Windows Server 2008 R2 fail-over cluster. Additionally, Live Migration requires a dedicated network adapter on each Hyper-V host for migration traffic. It is also recommended that processors on all hosts are from the same manufacturer and of the same processor family. This ensures that all processor features can be used.

We will now go through the process of setting up Hyper-V to support Live Migration. We will assume that Hyper-V is already set up on a Windows Server 2008 R2 fail-over cluster. 

Snapshots

Snapshots allow an administrator to create a point-in-time capture of a VM. This includes the configuration, power, and disk states of the VM. Snapshots are very valuable in several situations such as development and test environments. For example, a developer could create a snapshot of a test VM prior to installing a newly developed application. After creating the snapshot, the developer could install the application and verify the process. To perform the same process, the developer could simply revert to the snapshot instead of uninstalling the application. By reverting the snapshot the machine will be returned to the exact state that it was in at the time the snapshot was taken. Snapshots can also be used prior to performing a “risky” procedure to a VM. For example, you could take a snapshot prior to installing a new service pack. If the service pack installation failed or had adverse effects, the machine could be reverted to the state prior to installing the hotfix.

Best Practices

Best practices for snapshots of production servers

Creating snapshots of servers causes a decrease in server performance. For this reason, you should only snapshot production servers during off peak hours or a maintenance period. You do not want to run a production workload on a snapshotted VM for an extended period of time. If a snapshot remains for an extended period of time, it can grow to a level that may require several hours to remove. This is because removing a snapshot forces all the changes to be committed back to the original disk behind the scenes. Additionally reverting back to a snapshot may cause unwanted effects such as the VM losing connectivity with the domain. This is because computer accounts change their Active Directory password on a regular basis. If the password has been changed and the machine has been reverted back to a previous snapshot, it will also revert the password to the one that was used at the time the snapshot was taken creating a mismatch between the computer and the computer account in Active Directory.

Microsoft does not recommend taking snapshots of Active Directory domain controllers. Reverting to a previous snapshot of a DC could cause unwanted effects on your domain and could possibly cause versioning issues with the Active Directory database.

2. Introduction to System Center Virtual Machine Manager 2008 R2

If you are responsible for a medium-sized to a large virtualized enterprise, then at some point you will likely realize that the management of multiple virtual host machines can be very cumbersome and time-consuming when using the standard console for each machine. VMM simplifies their management by consolidating everything you need into one console. In fact, you can manage your Hyper-V, Virtual Server, and even VMware ESX hosts all via VMM.

If you are already using SCOM, you can use the data it collects via its monitoring capabilities to further advantage. Performance and Resource Optimization (PRO) leverages it and recommends actions to be taken to improve the performance of your VMs. You can even configure it to automatically make certain adjustments on your behalf in order to maintain the level of performance your customers require.

VMM not only consolidates the functionality built into Hyper-V but also adds to it. With VMM performing, physical-to-virtual (P2V) migrations is greatly simplified and can be done without service interruption. VMM will also convert your VMware machines to VHDs, using a similar technique called virtual-to-virtual transfers.

For development and testing environments, VMM provides a self-service Web portal you can configure to delegate VM provisioning while maintaining management control of the VMs.

By implementing a centralized library for the storage VM components, you can leverage these building blocks to quickly stand up new VMs as demand dictates.

You can also create scripts to increase your level of automation, because VMM is built on Windows PowerShell. The various wizards included in VMM are typically just a pretty interface to generate a PowerShell script. VMM provides the functionality to view the code behind these scripts to help expand your knowledge of the scripting language.

System requirements for system center virtual machine manager

Before designing your VMM architecture, you should decide whether you want to implement VMM on a single server or share the load of VMM’s multiple components across separate servers. As a rule of thumb, if you need to support twenty or fewer VM hosts, you can use a smaller single processor server. If you suspect that you will eventually have a greater number, up to 150 or more servers, then consider a multiple processor server. If you will be supporting groups of VM hosts in diverse locations, you might want to use a multiple-server approach. For a complete list of hardware requirements and software prerequisites for either deployment option, visit the TechNet Web site at http://www.microsoft.com/systemcenter/virtualmachinemanager/en/us/system-requirements.aspx#Server.