Many companies are using virtualization technology somewhere in their environment, but may wonder about using virtualization in data center disaster recovery planning. Learn how virtualization in disaster recovery can be a great asset, as well as the limits of the technology.
It seems that virtualization in the commodity server world continues to spread like wildfire. The return on investment (ROI) achieved through consolidation of older servers onto newer multi-core, multi-processor powerful servers is so compelling that many IT organizations cannot virtualize their servers fast enough.
I have talked to a number of IT managers, directors, and CIOs in seminars and meetings around the world on the subject of business continuity and disaster recovery (DR). While doing so, I've performed some straw polls on the use of commodity server virtualization, and found some interesting anecdotal trends. About 75% of those I've talked to share that they are using virtualization somewhere in their environment; including test, development, and production. About 33% indicate that they are using virtualization in production systems, and of those, close to 100% implemented the solution to reap the benefits of server consolidation alone. Surprisingly, very few (less than 5% -- even no one in some audiences) indicated that they are using advanced features such as VMware's Distributed Resource Scheduler (DRS) or Vmotion.
In each audience, I've been shocked to find that less than 10% are using some form of high availability clustering to protect their virtual machine infrastructure. Equally few are actively leveraging virtual machine technology for DR. Many have indicated they would like to see how virtualization can help with DR, but have yet to implement anything.
The few IT organizations that have implemented advanced virtualization features for DR h...
To continue reading for free, register below or login
To read more you must become a member of SearchDataCenter.com
ave unanimously sworn by it. So what's so great about virtualization when it comes to DR? Let's take a look:
Hardware independence: DR solutions built around physical systems require identical hardware be maintained at the recovery site or necessitate complicated and time robbing steps to rebuild server operating systems on newer or different hardware. There have been incidents where the recovery server was the same hardware model, but included updated hard disk controller firmware that caused delays in bringing up the server image. Virtualization abstracts the hardware from the operating system and normalizes the device drivers used in the operating system to a common set used across all virtual machines regardless of the underlying hardware model. This removes the hassles associated with matching device drivers of an installed server image to a new server, greatly reducing recovery time and risks of configuration errors.
Virtual machine disk format files: Virtual machines store their guest operating systems, application, storage, and configuration (such as IP addresses) in a file. This file -- virtual machine disk format (VMDK) or virtual hard disk (VHD) file -- contains the whole operating system environment to enable simple loading and saving of the virtual machine. Not only does this file contain the image of the operating system and application code, it also describes the required configuration of the virtual machine, including virtual processors, memory, and devices. This serves as a very simple and portable single file that contains everything necessary to describe the server environment and the actual code and data that makes up that server. Launching the virtual machine from a virtual machine disk file automatically configures all parameters on the fly. Recovering at a DR site becomes a simple start-up of the VMDK or VHD.
Physical to virtual tools: Virtual machine solutions require management tools for creating, starting, stopping, and saving virtual machine images. To aid in the creation of virtual machines, a number of tools exist for analyzing a physical server and creating a VMDK or VHD from that server. VMDK or VHD files created from physical systems can be quickly deployed at the recovery site.
Hardware re-use: Virtual machine hardware at the recovery site doesn't have to be sitting idle while waiting for a disaster at the primary site. It can be used for development, testing, or other purposes. In the event of a disaster, the testing or development virtual machines are shut down and the production virtual machines are started; a process that can take only seconds.
DR solutions built around virtualization technologies sound great. But there has to be a catch, doesn't there? These solutions work for a majority of workloads but not for all. Demanding applications, such as high I/O databases, may find that the extra overhead of virtualization hampers their performance. Most database vendors currently do not support their products in virtual environments (but this is on the cusp of changing -- so stay tuned to the market). Additionally, applications or services that require specialized hardware devices may not have those devices supported in virtual environments. In these special cases, you will still be forced to build DR solutions with identical physical hardware and suffer more complex recovery procedures.
