Rollout: Vizioncore Rides To The Rescue Of Overburdened VMs - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Software // Enterprise Applications
06:15 PM

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.

CLAIM:  Vizioncore's vRanger aims to double the speed of hot backups of VMware ESX virtual machines. In concert with VMware's Virtual Consolidated Backup, or VCB, vRanger snapshots the VM, then moves the backup onto a proxy server. The proxy writes the backup into storage, leaving ESX hosts free to serve up VMs.

CONTEXT:  You'll need another backup product to swipe VM backups off the proxy server. EMC NetWorker, Symantec Backup Exec, Tivoli Storage Manager, and Veritas NetBackup can all integrate with VCB, but vRanger is small, lightweight, and inexpensive, worth adding even if you have a big storage management gun in place.

CREDIBILITY:  Backing up a 10-GB, single-volume Windows XP Pro VM took 4.5 minutes, a speedy 67 Mbps. The product still has kinks to work out, including an irritating inability to adjust backup settings once a job is scheduled. Shops with just a few dozen VMs can work around these issues, but enterprises may want to steer clear until they're resolved.

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.


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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
1 of 2
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

Becoming a Self-Taught Cybersecurity Pro
Jessica Davis, Senior Editor, Enterprise Apps,  6/9/2021
Ancestry's DevOps Strategy to Control Its CI/CD Pipeline
Joao-Pierre S. Ruth, Senior Writer,  6/4/2021
IT Leadership: 10 Ways to Unleash Enterprise Innovation
Lisa Morgan, Freelance Writer,  6/8/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Planning Your Digital Transformation Roadmap
Download this report to learn about the latest technologies and best practices or ensuring a successful transition from outdated business transformation tactics.
Flash Poll