Chris Poelker’s Blog

In light of the events at the recent VMworld conference, this post should be timely.  In my travels lately I have been bumping into a lot of organizations suffering the pain and turmoil of moving from a physical environment at their production datacenter, to a virtual environment for DR. The typical process is to build out a SAN and some more powerful servers at the remote site, make copies of the production servers, bring the copies to the DR site, and then use the VMware converter to create a new VM of the machine. Once the VM is created at the DR site, they typically use a convoluted process to continually inject any changes from the physical servers at the production site to the virtual servers at the DR site. 

I wish you could have been with me to see the face of one datacenter manager as I showed him how he could:

1) Eliminate the SAN at the DR site

2) Continually replicate delta versions of production changes, including the C:\ drive changes to the DR site, using 80% less WAN

3) Leverage VMware RDM and 10GB-E at the DR site to assure application responsiveness when using virtual servers

4) Bring up his SQL server in 10 min. at the DR site from the replicated production data. We actually timed this.    

The process is fairly simple, and all the tools to create the VM are within VMware. All you need is an efficent mechanism to holistically accelerate protection and replication of the at the production site.  I showed this with FalconStor DiskSafe running on the SQL server to efficiently replicate delta version changes on the C:\ drive to give me an up to the second image of the root volume at the DR site. The data drives were protected by a CDP appliance, which MicroScanned the data to send only updated 512 byte sectors that were changed to another CDP appliance at the DR site.

The CDP applaince at the DR site was then used to provision both the replicated C:\ drive and the data drives from a consistent shapshot over 10GB-E. Simply mount the replicated C:\ drive to the DR server, inject the SCSI drivers using the VMware toolkit, and bring up your new SQL VM. Once you are set up, you can down the VM, and any changes to the physical side will be continually replicated to the virtual side automatically.

This entry was posted on Tuesday, September 8th, 2009 at 4:55 pm and is filed under Storage Utility, storage virtualization, Data Deduplication, VMware, Virtualization, ROI, Storage, FalconStor. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.