FalconStor Software Inc. rolled out a new scaled-down version of its IPStor software that will run on VMware's ESX server as a virtual appliance and marketed to small and midsized businesses (SMB) as a cheaper alternative to the full IPStor package.
The new product, called the FalconStor Continuous Data Protection (CDP) Virtual Appliance for VMware, packages IPStor's CDP, snapshots, Oracle and SQL integration, remote and local replication, and failover onto an instance of ESX Server, rather than the traditional appliance method of installing the application on commodity server hardware. The virtual appliance version of IPStor does not support storage virtualization, which the hardware-based appliance includes.
With its pared-down feature set, the virtual appliance is cheaper. FalconStor officials gave the price for the virtual version of IPStor at between $8,000 and $10,000, as opposed to $15,000 to $20,000 for the hardware-based appliance. It is also more limited in scale, supporting a maximum of 16 host connections -- physical or virtual -- 128 LUNs and 255 snapshots per volume.
FalconStor maintains the feature and scale limitations aren't an issue for the SMB market it is targeting and has added SMB-friendly features, like a setup wizard. "We wanted to provide this below the $10,000 barrier to smaller IT shops, so we eliminated hardware costs," said Diamond Lauffin, technology evangelist for FalconStor, adding "It is tailored for that market in some aspects."
Entry level pricing starts with a 2 terabytes (TB) configuration, but licenses are available for 1 TB and 4 TB, as well.
Since it's based on a virtual machine, the box can also be used in some creative ways for disaster recovery. FalconStor's CDP feature backs up system images, as well as data, so a secondary instance of the virtual appliance can be deployed at a secondary site where it can be used to store replicated data from the primary site and promoted to primary in the event of a disaster using the failover built into the appliance. The IPStor software can also perform physical-to-virtual and virtual-to-physical conversions for restoring data between heterogeneous devices.
"People forget that disaster recovery is one of the biggest reasons users deploy server virtualization," said Arun Taneja, founder and consulting analyst with the Taneja Group. Virtual servers take away one of the most common reasons for disaster recovery failure, which is mismatched hardware and OS patches between primary and secondary sites.
W. Curtis Preston, GlassHouse Technologies Inc. vice president of data protection services, pointed out that CDP, or in the case of IPStor, near-CDP consisting of frequent snapshots with bare-metal restore capabilities, is a good fit with virtual servers. "When you back up at the ESX level and take images, you end up with a huge full backup every time. Since FalconStor's CDP takes system state information at the ESX level but stores only the incremental changes, you kind of get the best of both worlds." Both Preston and Taneja said this capability currently makes FalconStor's CDP unique in the industry.
Analysts: Caveats when deploying virtual appliances
FalconStor is also one of the earliest out of the gate with appliances built to run on VMware virtual servers; VMware has been encouraging independent software vendors (ISV) to build such appliances through its Certified Virtual Appliance program and similar appliances are in the works. FalconStor's approach to CDP for VMware won't remain unique for long, according to Taneja. "Nobody in the industry wants to be left out of the VMware craze."
But while there will be no shortage of virtual appliances available, analysts urge caution when deploying them, depending on the environment. There are some performance limitations to consider when deploying virtual appliances. The term "virtualization drag," is sometimes used to describe the inherent delays in switching between the OS of the virtual machine and the main "brain" of the server virtualization software called the hypervisor.
"There are some applications and appliances that are never going to find their way onto virtual appliances," said Steve Norall, analyst with the Taneja Group. Applications like storage virtualization, as in the case of IPStor, will probably never find the virtualization drag negligible enough to port it to virtual appliances, Norall said, and appliances like network attached storage (NAS) filers are also too I/O intensive.
As for the rest, analysts said the sky's the limit, but that users should learn from the storage pitfalls already identified when it comes to deploying server virtualization. "Users should be careful not to cause performance problems by over consolidating," according to Greg Schulz, founder and analyst with the StorageIO Group.
Since more than one application tends to live on the same host when servers are virtualized, Taneja said that it's important to recognize the different I/O needs of each application and balancing them against their virtual machine neighbors to avoid creating bottlenecks on shared storage. This problem can be compounded by the fact that while most CPUs on physical machines have cycles to spare, memory runs out much sooner on a shared system, requiring more I/O from disk.
Also complicating matters is the fact that VMware's rule of thumb on storage allocation is to allocate 2 TB for every 1 TB of actual space needed. "While VMware is solving the server utilization problem, it's making the storage utilization problem worse," Taneja said, strongly recommending that users attach virtual servers to storage systems that offer thin provisioning or use a storage virtualization layer to approximate thin provisioning to combat this problem.
"FalconStor can't control what storage customers are going to end up attaching to this," Taneja said. "Users need to be extra careful and be aware of the storage challenges that come with server virtualization."