FalconStor Software has 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 virtualisation, 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 virtualisation," 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 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 "virtualisation 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 virtualisation 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
virtualisation, as in the case of IPStor, will probably never find
the virtualisation 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 virtualisation. "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 virtualised, Taneja said that it's important to
recognise 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
utilisation problem, it's making the storage utilisation problem
worse," Taneja said, strongly recommending that users attach
virtual servers to storage systems that offer thin provisioning or
use a storage virtualisation 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 virtualisation."