AT FIRST GLANCE, server virtualization technology is a way to consolidate physical servers and improve utilization. Beyond that, server virtualization is also emerging as an elegant alternative to traditional disaster recovery (DR) methods.
Comarco, an Irvine, CA-based electronics manufacturer, undertook a project last year to protect against a catastrophe that would take out its Exchange, SQL Server and file servers. Sean Anderson, the firm's IT manager, initially looked at hosting four hot servers at a nearby SunGard facility, but the asking price for that setup was approximately $10,000 per month.
Instead, Anderson cobbled together a DR solution out of a Hewlett-Packard (HP) server, VMware server virtualization software and Double-Take replication software--all for about $60,000 in capital costs plus $600/month in bandwidth charges. The HP server resides in Anderson's office in Spokane, WA, and is running four virtual machines, one for each server replicated in Irvine. Replication is a few seconds behind the main site, but the T1 line connecting the two offices has never been saturated.
Comarco "isn't getting all the bells and whistles that we would have gotten with SunGard," notes Anderson, such as a traveling DR site that will drive to your parking lot or a replacement phone system. "But I've been doing things the expensive way for a long time; now I'm into doing things on the cheap," he says.
What makes server virtualization good for DR is how it abstracts the underlying hardware infrastructure, says Bob Roudebush, director of solutions engineering at Double-Take Software. As such, the guest servers running on top of VMware ESX Server are hardware-agnostic. "You can just move them around independent of the hardware resources," he says. That frees users from needing identical hardware at their disaster recovery sites.
At first, Double-Take was taken aback by the interest VMware shops have shown in its replication software. This spring, Double-Take announced pricing for VMware environments with software licensed per physical machine, rather than per guest operating system. Going forward, the firm plans to support native replication at the VMware ESX Server layer, the so-called "hypervisor."
In the short term, that will entail taking a snapshot of the VMDK file (i.e., the virtual machine) and replicating its redo logs as they're applied. That way, "we can essentially do near real-time replication," says Roudebush. In a second stage, the company may port Double-Take to run natively on the VMware ESX Server platform. That would give them filter-based replication where "when a write occurs, we pick up a copy and apply it to the target server," he says. But that might take a while. Right now, ESX Server doesn't have the necessary plumbing to make that possible, and it's unclear whether or not VMware will agree to build it in. "VMware ultimately gets to make that choice because it's their product," says Roudebush.