In-Depth
Virtualization, The Implementation
Getting your virtualization effort is more than just flipping manual pages and following the steps. Here's how to get from P to V in no time.
- By Greg Shields
- 07/26/2007
In the first two parts of our series on virtualization, we talked about
the things you need to consider before you ever start your rollout. In
Part 1, we discussed some things that could prevent a physical server
from being a good virtualization candidate, like attached peripheral devices
or a bad performance profile. We then dovetailed that information into
Part 2, where we talked about some of the virtualization products on the
market that you may or may not have considered.
Let's now discuss your virtualization implementation. Why is the implementation
so important? Don't you just print out the administrator's guide and flip
to the chapter on installation? Yes, but the engineering of a good virtualization
implementation involves so much more than just clicking "next." There
are three critical components of any virtualization rollout you should
take advantage of if you're to get the biggest bang for your virtual dollar:
Your P2V tool, your backups and your disaster recovery plans.
I Heart P2V
P2V, which stands for "Physical to Virtual," is an acronym that gets thrown
around a lot in the virtualization space. P2V is the process of moving
your server instances off of their existing physical platforms and into
the virtualization environment. There are numerous tools on the market
that can perform this task, and we'll talk about them in a minute. But
first, what exactly is the P2V process?
Think of the composition of your servers. They're little more than
a series of files on a hard drive. A few of those files make up the registry
of your computer and the driver sets that run the physical components.
In the virtualization environment, it is really no different. For most
virtualization solutions, those files that make up your computer are instead
squished together into a single file. The only difference between the
physical and virtual machines is the drivers needed to run the physical
equipment. All the P2V tools on the market do is move those files from
the physical server into the virtual server's file and change the
driver sets.
The installation of the virtual server product is typically very quick
and easy. You can get an initial build up and running in 20 minutes. The
time-consuming part is in P2V'ing your existing servers into the virtualization
environment once it's created. Depending on the speed and congestion of
your network, the size of the drives on your physical machines, the speed
of the hosts in the virtualization environment and the type of P2V software
you purchase, that process can take between three to five hours or more
per physical machine. That means a lot of late nights.
A number of tools are available that automate this process. VMware has
VMware
Converter that allows for a single, no-cost P2V for each installation.
A purchase is needed if you want to do more than one. PlateSpin,
LeoStream and Acronis
also have enterprise-worthy tools for P2V'ing large numbers of machines.
Some freeware tools also exist like EZP2V
for BartPE
and Ultimate
P2V. Or, you always have the option of rebuilding the server instance
from scratch inside the virtualization environment. If a physical server
exhibits behavior that makes you doubt the stability of its configuration,
a complete rebuild is often the best idea. As they say, garbage in, garbage
out.
Backups Both Ways
Once you move to virtualization, backups get slightly more complicated.
The compression of a server's files into a single file at first blush
makes the whole process seem really easy. You back up that server's
disk file and you're ready to go. If your machine crashes, the restore
involves a single file rather than the millions of files that make up
the server.
For servers that store static data -- data not housed in transactional
databases -- this is an excellent mechanism for getting the server back
in line in a flash. Modern applications for virtual machine disk backups
use snapshot technology to quiesce the file before backing it up. This
ensures that the restored file is what we call "O/S consistent," meaning
that the O/S will successfully come back alive once restored. However,
sometimes the database residing on that server may have been in the middle
of a transaction or other activity. In this case, when the disk file is
quiesced by the backup software the disk file is consistent but the database
is not.
Databases like Exchange, Active Directory and SQL can come back after
a restore in an inconsistent state. In those cases, you should consider
also incorporating system-level backups inside the virtual machine like
Symantec
Backup Exec, Veritas
NetBackup or the native NTBackup to back those databases up separately.
These tools incorporate agents that ensure the database itself is quiesced
before the backup starts. Some backup tools at the virtual machine layer
are beginning to develop capabilities to do this, negating this extra
step, but these tools are still forthcoming.
In either case, as you plan your virtualization rollout, take a look
into tools like VMware VCB or Vizioncore esxRanger to do backups from
the virtual server level in conjunction with your backup clients inside
the virtual machine itself.
DR Consistency
The National Academy of Archives and Records states that 96 percent of companies
that lose access to their data center for 10 days or longer are out of
business within a year. It's the fear of data loss that keeps many
business owners and IT managers awake at night. But until recently, the
creation and management of a full backup site for disaster recovery was
out of the realm of possibility for many businesses. With virtualization,
that need no longer be the case.
The same problems with database consistency hold true when considering
virtualization for disaster recovery. Many companies move to virtualization
because of the added bonus of easily and inexpensively bolting on disaster
recovery capabilities. Once the virtualization environment is installed
and all systems are P2V'ed, the virtual server-level backup software can
very easily move those backups to an off-site data storage location. If
you ever lose your primary site, restoring its servers is as easy as connecting
them to another virtualization environment at the backup site and "pressing
the green VCR button" to power them up. Right?
That's partially true. The problem with database consistency is
exacerbated in a DR situation. If you're not using quiescing tools
like those discussed in the previous section to snapshot your transactional
databases before they're backed up and shipped off to a remote site,
a restoration may not be that clean and easy. So, when considering disaster
recovery plans in your virtualization rollout, make sure that you also
consider the same problems as with backups.
Some tools are available that make the DR process quite easy. Among others,
two tools can provide automated shipment of virtual machine backups off-site
while still enabling consistency. Double-Take Software has a product called
Double-Take
for Virtual Systems that will automatically do the quiescing, the
backup and the shipment of the backups to the remote site as often as
you want. Some of the neat features of the Double-Take product are the
ability to ship only the changes across the wire, reducing your bandwidth
needs. Also with their software, you can store up to 64 incremental backups
and roll back or forward to any of them during a restore event. This is
useful in the case where your primary site gets hit with a massive virus
attack and you want to roll back to just before the attack started. Double-Take
for Virtual Systems, however, does not currently have the capability of
quiescing databases inside virtual machines. So, for those machines, you'll
need to also purchase Double-Take's host-based application, Double-Take
for Windows.
Vizioncore has a tool called esxReplicator
that has a similar feature set to Double-Take's product. It can perform
many of the same functions as the Double-Take product. However, Vizioncore
has mentioned that they are working on adding database consistency into
their product in a future release.
Either product enables your business to stand up a virtual "warm
site" at a remote location ready to be powered on in the case of
a primary site failure. This reduces the overall cost and management headache
of supporting the remote site, as changes to production machines are automatically
replicated as they occur. The costing on these products also brings real
DR designs into the realm of possibilities for even the smallest networks.
Virtually Wrapping it Up
So that's our series on virtualization. We've taken the time to understand
how performance management weighs heavily into the success or failure
of your virtualization investment. We've talked about the contenders in
the market, and how the hype may not necessarily drive you to the solution
you think you need. And in this, our third installment we've worked on
the add-on products for P2V, backups and disaster recovery that enable
a holistic solution for systems management and protection.
The next steps are up to you. Getting through your virtualization assessment,
determining the best product to suit your needs and adding in the feature
sets needed by your business are all critical parts of your virtualization
project plan. And more than a few late nights watching servers finish
the P2V process while catching up on all the old reruns you've been missing.