Thursday, October 14, 2010

Typically, servers are left ‘un-virtualized’ for a variety of reasons. These stand-alone servers often run applications that are the lifeblood of the company, providing truly mission critical services. One of the reasons they don’t get virtualized is that there’s a concern about how the virtual environment would impact their performance and availability. There is also the concern about how those servers would in turn, impact the virtual environment itself. If they’re running I/O intensive applications, as an example, they may consume all the available IOPS bringing down the performance of the other VMs that share server resources.

The value and importance of these stand-alone servers, however, may be all the more reason to make sure they are part of a virtual DR strategy. Instead of having two separate strategies, integrating stand-alone servers into virtual DR plans can reduce costs and increase overall effectiveness of the organization’s disaster recovery efforts.

Converting Physical Machines to Virtual Machines

The first step to including non-virtualized servers into the virtual disaster recovery process is being able to convert the physical systems to virtual systems without having to actually run them as VMs. Essentially, the goal is to leverage the encapsulation capabilities of the virtualization process without having to actually use the server in that virtualized state.

The move to a virtualized state can be done with physical-to-virtual conversion software. While there are several of these migration applications available, including some built into the virtualization products themselves, something more than a one-time conversion utility is needed. In this case a product that will do that conversion on a scheduled, continual basis is ideal. These conversion products can use a form of ‘block-differencing’ technology to only update the parts of the server image that have changed since the last update. This capability, available in products like vConverter5 from Quest Software, provides the capabilities to rapidly update the virtual versions of physical servers which minimizes network traffic and the time required to update the image.

The Value of a Virtualized Physical Server

Once the virtual image of the physical server is captured or updated, it can then return to its normal operations. The value to IT is that with this virtual image it can now be replicated to the DR site for off-site protection of the server just like any other virtual machine.

A recent Storage Switzerland article “Virtual To Physical Machine Conversion To Mitigate Risk” discussed the advantages of being able to move virtual machines to physical systems, the focus of that article being when the systems are already virtualized. In the case of moving from physical to virtual there are advantages to this process beyond the more critical as a disaster recovery use case. For example, if the physical server fails, a near real-time instance of that server can be brought up as a virtual machine and the business can return to operations quickly. While the application owner, under normal circumstances, would have been concerned about performance in the virtual environment, any potential performance loss pales in comparison to having a system that’s down, waiting until the stand-alone server can be repaired. This image could also be used to start a test virtual instance of the application. Finally, another key area is to be able to prove that the application can run, and run acceptably, in a virtual environment without risking a complete commitment to virtualization.

The key advantage of physical-to-virtual migration is its ability to include the physical server’s image in the virtual DR process. This enables a single DR strategy all leveraging virtualization, instead of two separate DR strategies, one for physical systems and one for virtual.

Converting from Physical to Virtual

One of the downsides to typical migration utilities is their inability to move data from the virtual instance back to a physical server. The problem is that once in DR mode the physical systems that were protected as a virtual server had to stay virtual at the DR site. This was a “deal breaker” for many that were considering integrating physical servers into a virtual DR strategy. For a DR strategy that leverages the virtual infrastructure but integrates physical servers, the software needs to provide the capability to move a virtual machine back to a physical server like vConverter 5 can.

With the ability to move virtual machines out of the virtual environment and run them on physical, stand-alone systems the IT team has maximum flexibility. The DR site can be assembled with a minimal hardware investment by allowing for denser populations of virtual machines than in the primary production data center, since for the majority of the time they will be idle or turned off. There could be a few physical systems sitting idle for mission critical applications or they could be ordered at the moment the disaster is declared. The high priority physical systems could run in a virtual mode until the new servers arrive. When the new servers arrive these high priority applications could be shifted from virtual mode to physical mode, returning operations to a more normal status.

Most disasters that are declared don’t result in the destruction of the original data center, rather an inability to get to it. In this case, once the disaster has passed, the same process could be reversed. The physical machines at the DR site could be virtualized, replicated back to the original site and the images pushed out to physical servers, retuning operations completely to normal.

Easy Testing

The most important part of any disaster recovery plan is testing it, something made easier by virtualized DR strategies. All that’s required is to have the remote instance of the virtual machine start. If this VM and its corresponding application can be activated in the remote site then chances are high that the DR site will work when needed. The simplicity of this testing also brings confidence to the overall recovery process. There is no better verification of recovery than being able to see it happen.

Integrating stand-alone servers into virtual DR plans can lead to reduced costs at the DR site, more rapid recoveries and greater testing flexibility. The result means more servers can now be included in the DR strategy with limited additional CAPEX or OPEX costs. Most importantly, if disaster ever really does strike, there is greater confidence in the ability to recover and keep the business alive.

George Crump, Senior Analyst