Cloud storage 2013: Nirvanix dies, others bloom
A comprehensive collection of articles, videos and more, hand-picked by our editors
TwinStrata Inc. today added Disaster Recovery as a Service capability to its CloudArray gateway, along with volume migration to improve performance and an automated snapshot scheduler.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
TwinStrata began selling its CloudArray iSCSI cloud storage gateways in 2010, allowing customers to cache frequently accessed data on-premises while storing their data in the cloud.
CloudArray Disaster Recovery as a Service (DRaaS) works with SoftLayer compute services to spin up VMware-based vSphere servers in the cloud and recover a live copy of applications and data so customers don't have to rebuild servers for disaster recovery.
TwinStrata will do an active recovery assessment for customers to determine recovery time objectives and recovery point objectives for data on CloudArray. DRaaS supports VMware vSphere replication and virtual machine (VM) backup software from Veeam Software. TwinStrata plans to eventually support other hypervisors and backup apps.
Previously, the CloudArray device only recovered data from Google Cloud Storage and Durable Reduced Availability Storage, Amazon S3 and Reduced Redundancy Storage, and AT&T Synaptic Storage as a Service.
TwinStrata began addressing DR last year by adding the ability to place a virtual appliance CloudArray inside the cloud to recover data if an on-premises server failed.
"Today we provide data recovery only," TwinStrata CEO Nicos Vekiarides said. "But a lot of customers want both data and application recovery, and they want recovery in an hour, not days."
Faster recovery comes from automating the process.
"Previously, it was a do-it-yourself approach. Customers could recover data in the cloud but they had to spin up the VMs," Vekiarides said. "They had to do the orchestration themselves. Now, it's more of a turnkey approach. It's an application service where we spin up the VMs in three to four hours."
TwinStrata CloudArray 4.5 also features an automated snapshot scheduler so customers can create a recurring schedule of snapshots with integrated, age-based retention policies. Previously, the snapshot interface was set up through scripting.
"They made it a lot more useable than in the past," said Marc Staimer, founder and senior analyst at Beaverton, Ore.-based Dragon Slayer Consulting. "Scripting is not for the faint of heart."
TwinStrata added volume migration based on policy so hot volumes are moved to a larger and faster cache with solid-state drives and more cold volumes for archiving are moved to a slower cache using SATA drives.
"This is done on a per-volume basis. You can load balance the volume across the cache," TwinStrata's Vekiarides said. "Right now, the process requires human intervention to determine what data is hot; but in the future, there will be a customized tool."
TwinStrata's new bandwidth throttling allows users to set recurring weekly schedules for high-usage times and days. Bandwidth usage can be tuned for 15-minute intervals and 1 megabit per second increments. This procedure previously was done through scripting.
"We had a scripting interface that could do bandwidth throttling at a coarse level," Vekiarides said. "It did not have the fine-tuning control. Now it's a more flexible interface."
Dragon Slayer Consulting's Staimer said storage puts a lot of demand on bandwidth, and this bandwidth throttling capability allows customers to set up policies on when to scale back bandwidth usage for other applications that have lower storage demands.
"This is a good evolution of the product," he said. "It's much stronger than it used to be."
TwinStrata's CloudArray caters to small- to medium-sized businesses. The DRaaS is available today, while CloudArray 4.5 will go live May 28. DRaaS is offered as a licensed option with CloudArray. It's priced based on the amount of compute and storage needed, as well as how many VMs must be recovered.