Virtualization has been making significant inroads as a viable technology in
a variety of applications, not least of which is business continuity and disaster
recovery. Virtualization's intrinsic features of encapsulation, consolidation,
and independence from the hardware platform can make disaster recovery solutions
more manageable, flexible, and less costly.
Thanks to a virtual machine's (VM's) encapsulation properties—in which
the complete computing environment contains the OS, BIOS, applications, data,
and virtualized hardware—you can recover VMs to any supported AMD- or
Intel-based server without worrying about the differences in the underlying
physical hardware. Thus, the physical-world necessity to restore to an identical
server (i.e., make, model, and configuration) doesn't apply: System-compatibility
concerns between the hardware and OS at the recovery site are eliminated, making
recovery much more reliable. Another virtualization benefit is the ability to
consolidate servers at the recovery site by hosting multiple VMs on one physical
server. During a failover scenario, it's often acceptable to temporarily provide
somewhat lower application performance. This ability to oversubscribe hardware
with multiple workloads with minimal performance impact makes this disaster
recovery model economically attractive. During day-to-day operations, you can
also use the servers at the recovery site to handle test and development workloads.
Then, when a disaster occurs, you can repurpose those servers by shutting down
those jobs and starting up the recovery VMs. In this way, resources are fully
utilized and system reconfiguration is kept to a bare minimum.
So, how do you start utilizing virtualization as part of
your company's disaster recovery process?
Getting Started
Let's assume that your business is running several Windows applications, each
on a dedicated server with local SCSI storage. You have no shared storage devices—Fibre
Channel SAN, NAS, or ISCSI—in your environment. Your applications are
tiered in terms of how critical they are to your business. For this exercise,
let's suppose you'd like to initially focus on your second-tier applications,
which have less stringent Recover Point Objective (RPO) and Recovery Time Objective
(RTO) requirements. Your current environment and business requirements will
determine the mechanisms that are viable for replicating the data from the production
site to the recovery site.
Microsoft's Virtual Server and VMware's ESX Server
lead the market in the server virtualization space. Both
offer comparable functionality, and although this article
references the ESX Server virtualization platform, you could
adapt the process workflow to apply to a Virtual Server
environment. Virtual Server installs on an existing Windows
host OS, such as Windows Server 2003 and Small Business
Server (SBS) 2003. In contrast, ESX Server installs directly
on your server hardware—or "bare metal"—and inserts
a virtualization layer between the hardware and the individual guest OS. ESX Server partitions a physical server into
multiple secure and portable VMs that run side by side on
the same physical server. The virtualization layer abstracts
the underlying processor, memory, storage, and networking
resources into the multiple VMs.
Once you have a virtualization platform in place, you need to consider the
three general methods for moving data from a source site to a recovery site:
backup/restore, host- or server-based replication, and storage
array–based replication. Table 1
shows the replication options that can meet various recovery objectives. Your
options for which data-protection mechanism is applicable in your environment
will also depend on where you locate the ESX Server system and VM files (as
you see in Table 2). Because you have only
local SCSI drives in our example, the options for shared storage don't apply.
Thus, in this article, we'll consider only backup/restore and host-based replication
scenarios.
With virtualization as part of your disaster recovery
solution, there are two general architectures that you can
deploy: physical-to-virtual and virtual-to-virtual. Let's walk
step by step through the implementation of both architectures. I'll start with the backup/restore scenario and follow
that with host-based replication.
Physical-to-Virtual Architecture
In the physical-to-virtual architecture, the source (i.e., production) applications
will continue to run on existing physical servers. The recovery platform will
have the applications running in VMs on ESX Server. The replication mechanism
will use the traditional backup/ restore methodology.
To set up the environment, you first need to identify the applications that
you want to include in the disaster recovery plan. Then, you confirm that the
current file-level backup policy (e.g., full, incremental, differential, frequency)
for each physical server meets your recovery objectives. For the recovery target,
you select the physical server on which you want to install ESX Server. Before
you take this step, be sure to check the "VMware Systems Compatibility Guide
for ESX Server 3.x" (http://www.vmware.com/pdf/vi3_systems_
guide.pdf) for compatibility information. Now, you're ready to install ESX
Server 3.x Standard on your physical server.
Once installation is complete, you need to convert selected physical servers
to VMs. To do so, you can use VMware Converter 3.0, which converts Windows-based
physical machines and third-party image formats to VMware VMs. The VMware VM
that the Converter creates will contain an exact copy of the disk state from
your source physical machine, with the exception of some hardware-dependent
drivers (and sometimes the mapped drive letters). Settings from the source computer
that remain identical include OS configuration (e.g., computer name, security
ID, user accounts, profiles and preferences), applications and data files, and
each disk partition's volume serial number.
When you download VMware Converter, you have the option of installing it either
on the machine you're converting or on a separate computer. You'll be converting
several physical machines, so I recommend installing it on a separate machine
so that you need perform only one installation.
In VMware Converter, click Import Machine, then select a physical computer
as your source. Follow the wizard by selecting either a remote or local machine.
If you select a remote machine, you'll need to enter its computer name or IP
address and proper authentication credentials. Choose the disks to import and
indicate the desired volume size. You can maintain the disk size, minimize it,
or specify an exact size. Choose a destination for the new VM, and follow the
wizard steps to select the ESX Server system. You'll need to log on to it and
assign a VM name, then specify a data store to contain the VM's configuration
files and disks.
Previous
Register
