Rollout: Vizioncore Rides To The Rescue Of Overburdened VMs

By easing the strain of virtual machine backups, vRanger Pro saves time and processing power in ESX clusters.

Vizioncore's new VRanger Professional 3.2 is a backup and restore product for VMware environments that complements an enterprise backup system. It can speed backup and restore times and offers additional features, including scheduling; reporting; file-level restores; and compatibility with a range of storage destinations, including NTFS, Linux, or VMware's Virtual Machine File System (VMFS) formats.

Backup and restore products typically require an agent for each virtual machine, but vRanger Pro acts as a go-between, eliminating the need to burden VMs with separate agents. Vizioncore's software is designed for VMware's ESX and Virtual Consolidated Backup, or VCB.

Vizioncore touts vRanger as enterprise-ready, but while it works as advertised, the management interface isn't up to snuff. It lacks flexibility in scheduling and organizing backups, for example, which may hinder IT departments working with large numbers of VMs.

BACK ME UP HERE

As you phase VMware into your infrastructure, usually through server consolidation, VM backups via typical agent-based mechanisms are appropriate for the short term. Simply keep the same agent-to-server ratio as you migrate physical servers to ESX, without additional licensing costs.

As your virtualized environment grows, however, you'll need to get more cost effective while relieving ESX servers of the load incurred by backup agents as they bang away at your VMs and ESX cluster. This is where vRanger comes into play.

Like rival products, vRanger uses VMware's VCB, the backup enabler for ESX, to give third-party applications access to VMs. Using a process called "I/O Intercept," data arriving at the proxy server is compressed and written straight to the storage location. The proxy bears the backup burden, freeing ESX hosts to serve up VMs.

In tests, we designated a physical server as our VCB proxy server and installed VMware's VCB client and vRanger, in that order. Ensure that each ESX server in your cluster acknowledges that VCB is licensed and enabled.

We also highly recommend developing a thorough understanding of VCB's functionality, infrastructure needs, and architectural requirements before diving in to any third-party backup tool. You'll save everyone a slew of time. For example, in an ESX cluster with a SAN in the back end, the VCB proxy needs to see the same logical unit numbers, or LUNs, as your ESX hosts do. While VMware and Vizioncore documentation state that your VMFS LUNs also need to have the same ID for both ESX and the proxy, our tests show this isn't completely necessary. We simply connected the proxy server to the same SAN fabric to which the cluster was attached, and it worked just fine. This means you don't have to expose your VMFS volumes directly to your proxy--a situation with the potential for disaster if an uninformed admin were to try and mount the volumes to the proxy.