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.
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.
Live Migration and Hyper-V processor compatibility mode
Though it is recommended that all hosts in a Hyper-V
cluster have the same processors, Windows Server 2008 R2 Hyper-V
includes a new feature known as processor compatibility mode. Processor
compatibility mode allows you to include computers with various
processor types in a Hyper-V cluster. Processor compatibility mode turns
off features of newer processors so that all processors in the cluster
use the same features as the processor with the least number of
features. This allows you to add older hosts to Hyper-V clusters, but
will also cause newer hosts to run with a reduced set of processor
features.
|
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 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.