Posts Tagged ‘CloudArray’

« Older Entries

Of 3PAR, blocks and cloud storage

Friday, September 3rd, 2010

No doubt you may have heard about the bidding war for SAN storage vendor 3PAR between HP and Dell. In case you missed it, a high-end block storage vendor (3PAR) is fetching a spectacular acquisition price that has continued to climb in a bidding frenzy, perhaps culminating this week at an astronomical $2.4B.

While there is certainly more to 3PAR than block storage, all this fuss may lead you to ask what makes block storage so desirable in customer data centers. And in the same vein, does block-access make sense for cloud storage? After all, file storage can run on similarly fast networks and offers native file sharing capability. Who needs blocks, right?

Well, the reality is that thousands of customers are purchasing block storage with good reason. While the argument between block and file can sometimes be as insightful (or uninsightful) as arguing about what type of bag to package your groceries in,  I offer three of the inherent advantages of block storage that make it attractive for a variety of customer environments:

1. The ability to support any file system

Block storage supports any file system: NTFS, ZFS, Ext3, NFS, CIFS. The choice is yours for a filesystem optimized to your applications. If you are considering an on-premise gateway to cloud storage, wouldn’t you prefer to keep using the file systems  you already have? With block storage, you can do just that as no “rip and replace” is required.

2. The ability to provision raw data volumes directly to applications

Many applications such as databases benefit from raw volumes that do not have the overhead of a file system. In fact, without the additional overhead, performance naturally improves. If you are using local copies of data that are replicated to cloud, it makes sense to optimize the performance of local access. If you are using server virtualization, VMware allows raw device mappings (RDM) from SAN attached raw volumes that minimize the I/O stack to maximize performance.

3. Benefits of block level granularity

When you are replicating data, say from a local copy of data to cloud copy, it is not always efficient to copy entire files to the cloud when only a small portion of the file is modified. For larger files especially, it is more efficient to send block level updates where a block represents only a small portion of the file. Also, with technology such as deduplication, it is more efficient to identify and consolidate duplicate blocks within files than duplicate files. See our deduplication performance blog post for more about this.

In summary, when considering deploying cloud SAN solutions or cloud storage gateway solutions, you’d be wise to consider the solution that has the maximum flexibility to meet all of your application needs, both present and future.

File or block storage? Which works best for you?

Tags: , , ,
Posted in Uncategorized | No Comments »

Mezeo Software Announces TwinStrata as a Mezeo Ready Solution Partner at HostingCon 2010

Tuesday, July 20th, 2010

Yesterday, Mezeo Software announced that it was adding TwinStrata as a  Mezeo Ready Solution Partner.  Read Mezeo’s in-depth  interview with our CEO, Nicos Vekiarides, who discusses the importance of the Mezeo partnership, the intelligent storage cloud and how it helps accelerate cloud storage adoption.

In short, this partnership expands the ecosystem available to TwinStrata and Mezeo customers in important ways, offering more choice and flexibility to customers around the world.  Others  talk about choices and flexibility while TwinStrata and it’s partners deliver them.

“As a Mezeo Ready solution, customers and service providers can be assured that TwinStrata’s CloudArray has been carefully evaluated and tested and seamlessly integrates with the Mezeo Cloud Storage Platform,” said Steve Lesem, President and CEO of Mezeo Software. “CloudArray easily connects any Mezeo Ready storage cloud to existing infrastructure in a manner that is familiar to System Administrators and seamless to end users. The TwinStrata technology will enable customers to realize significant cost savings over tape solutions and a reduction in capital and administrative costs when it comes to backup and disaster recovery.”

“Together, Mezeo and TwinStrata allow organizations to respond quickly to changes in business environments, better map business objectives to IT, optimize IT operational efficiency and improve IT cost controls,” said TwinStrata CEO Nicos Vekiarides. ”We’re proud of the designation as a Mezeo Ready Cloud Gateway Solution Partner and that Mezeo has chosen TwinStrata CloudArray SAN software as a key element in its cloud storage offering. CloudArray will deliver solid value to the companies that depend on Mezeo to provide a complete cloud storage solution.”

Tags: , , , ,
Posted in Intelligent Storage Cloud, Uncategorized | 1 Comment »

Announcing the immediate availability of CloudArray 1.1

Wednesday, July 14th, 2010

Woohoo! We’ve completed test and development of CloudArray 1.1, which we’ve dubbed the “Extended” release. No, it’s not “Extended” because of the development schedule; it’s taking the core features of CloudArray 1.0 and making them better.

  • We’ve increased the maximum volume size: in version 1.0, we had a two terabyte limit on the maximum size of the volume. Now, we can create and present single volumes of up to 384TB. That boggles my mind. Think about it: you can make a five volume RAID-5 device that is 1.5 petabytes. I’m tempted to do that on my own machine, just to be able to say that I have 1.5 petabytes attached to it. Of course, with thin provisioning, I wouldn’t actually have to pay for all of that…
  • We run in the cloud: we’ve extended CloudArray so that it can actually run in the cloud compute space. The same feature set that you use in your local data center is available, so that you can replicate, thin provision, snapshot, share, and encrypt storage to disk images in the cloud, too. With the launch of our ComputeAnywhere™ initiative, you can even share entire data volumes between local data center servers and cloud compute servers. Presently, we’ve got an EC2 AMI available, and more on the way,
  • We’ve extended our provider policy support: you can use policies like RRS on Amazon S3 to substantially reduce storage costs, or Synaptic’s increased redundancy policies to get even higher availability,
  • A host of smaller changes: we’ve tossed in lots of usability improvements, like easier cache creation and capacity management, snapshot checkpoint integration, more precise error reporting, and increased integration with our web portal services.

All-in-all, a nice set of changes, and I’m thrilled to be able to release it.

You can download it here.

Tags: , ,
Posted in Uncategorized | 1 Comment »

5 Reasons to Back Up Your Data Remotely with CloudArray

Tuesday, July 6th, 2010

With a variety of ways to back up your data off-site, ranging from tape transport to online backup software, why back up to cloud storage via CloudArray™? If you consider all options, there a number of good reasons to choose CloudArray for off-site backup and we thought we would share five of them:

5) It works with your existing backup software. You’ve already made the investment in backup software because it meets most of your needs. Why change your backup process, deal with a learning curve and risk losing functionality? Simply point your backup jobs to CloudArray disks, which appear local, and CloudArray takes care of securely moving the data off-site.
4) Network bandwidth is expensive. Even if you have lots of external bandwidth, you don’t want backup to monopolize it. Cloudarray caching minimizes the amount of bandwidth that goes through your external internet connection. The cache can use any type of local storage with cache sizes ranging from a few GB to a full local copy, providing a very fast first line of restore without going to the external network. Compression/deduplication further reduce your bandwidth requirements and some of our upcoming technology that minimizes bandwidth may just knock your socks off.
3) Your data needs security. With CloudArray, data is not only encrypted in-flight via SSL, but it is also encrypted at-rest when it is stored at your provider. That means every bit of data that leaves your premises is encrypted and stays that way until you need it back.
2) Access your data when you need it, where you need it. When we say Compute Anywhere™ access, we mean your data is instantly available on-site, off-site or even in cloud compute, such as Amazon EC2. All you need is an instance of CloudArray software, your configuration credentials and our one-button restore process. Unlike most online backup, your data is not just stored in a one-way vault that requires hours or days to retrieve a single file. Unlike tape, your data is available immediately, not just for disaster recovery, but also for validation, test or development purposes. When was the last time you validated your backups?
1) Cost savings and choice. There are no capital or administrative expenses for the off-site data stored by CloudArray; no dedicated hardware or facilities. CloudArray gives you a choice of cloud storage providers so you always have access to the best pricing on the planet. Want Amazon RRS starting at $0.10 GB/mo? No problem. Want to rotate backups across multiple providers? We can do that, too.

Finally, CloudArray is simple to use. It’s a downloadable virtual appliance you can start using in 30 minutes.

Still need convincing? Try CloudArray free for 30-days. It’s on us, including all the cloud storage you need.

Tags: , , , , , , , , ,
Posted in backup | 1 Comment »

5 Considerations for Cloud SAN Software– Part 2

Thursday, July 1st, 2010

By Greg Roody

In Part 1 of this posting, I discussed considerations around portability and security of a Cloud SAN software product.   In this post, I’ll discuss the related issues of performance and consistency.

3. Performance and Consistency

Performance is one of the subjects I normally answer with the phrase “it depends”.  You usually can’t get around it because there are so many different factors to consider, it’s hard to answer a simple question with a single answer.  In cases involving replication, it gets even worse.

After you have compressed, deduped, and encrypted your local data, you still have to move it over a physical network to its eventual home.  If you aren’t using a hybrid Cloud configuration, that can mean long latencies for your local application server.     With no local cache, every write has to go out to the Cloud Service Provider, and an acknowledgement has to come back before the next write can occur.  Reads would suffer a similar fate.  In the worst case scenario, that could amount to hundreds of milli-seconds of lag time between i/o’s.   That’s not very good for local application performance.

The solution to this problem is to make certain that your Cloud SAN software has a local cache to not only buffer reads and writes, but to also perform more advanced caching functions like LRU/MRU page management and pre-fetch.  By storing the data which is most frequently used in a local cache, write (and read) performance is greatly improved.  In fact, if the software supports a variable caching policy, the entire target volume can be cached locally, creating a second local copy of your data that is then asynchronously replicated to your Cloud Storage Provider.   With variable caching, you can even  establish QoS criteria for each volume you replicate.

Another consideration is what happens to performance when the network link to your remote Cloud Storage provider drops?  In the case of a non-hybrid solution, or when you are only partially caching your writes, your applications will likely slow down significantly and eventually stop responding while they wait for the network connection to be restored.  Applications might simply pause or they might timeout.  Fully cached volumes would simply keep operating normally but the dirty page pool would continue to grow and the amount of data which would need to be replicated would also continue to grow.

By using fully cached volumes, you can actually achieve local performance levels for data writes that are being replicated to offsite storage.

So what about the consistency of all that data?  How is consistency maintained during normal write operations and during bulk updates?

Remember that the local cache is storing all writes prior to them being asynchronously replicated to the cloud.  However, unless the Cloud Storage pool itself is protected during these updates, it’s possible that some writes will either be received out of sequence due to network issues or that some data could be lost in transit.   This can be accomplished in a number of ways, either by write ordering (which is data intensive) or by batching up the writes and sending them off as a consistent group, which will save bandwidth.  In either case, it’s important that the Cloud SAN software manages the updates so they can assure the full ordered update or rollback incomplete or out of sequence updates.  This capability should exist independently of the cache function within the Cloud SAN software (the Cloud copy must be protected against cache failure or network errors).

The level of consistency this provides is sometimes called “crash consistent”.   There may be some small amount of data loss in the event of a catastrophic event (the data that was in transit or that is still resident in cache when the host is lost) but the Cloud resident data volume will be fully consistent.

So to summarize, two critical attributes of Cloud SAN software should be a variable local intelligent caching policy to boost performance and the ability to ensure consistency at all points in the data path; for local writes, updates to the cloud, and during recovery of failed updates.

Tags: , , ,
Posted in Uncategorized | 1 Comment »

5 Considerations for Cloud SAN Software– Part 1

Thursday, June 17th, 2010

by Greg Roody

I’m not sure why, but people seem to like lists.  I suppose it’s the same reason presenters like to use PowerPoint, it simplifies the discussion in a controlled way.  But whatever the reason, I was asked recently to give my opinion on the top 5 items that should be considered when sorting through the seemingly endless choices customers face when considering how and why to use Cloud Storage.

So without any further ado, here are points 1&2 in my non-partisan and completely unbiased opinion.  Points 3, 4, and 5 will come in a follow-up post

1.      Portability

This may seem like an odd choice, but it really gets to the heart of why people consider a move to Cloud Storage in the first place, especially when they consider BC and DR as part of their rationale.

Portability in this case refers to your ability to quickly restart your Cloud San gateway from another location, or from the Cloud itself, in the event of a site disruption, relocation, or even just moving locations within a data center.  Hardware based appliances won’t provide any level of portability unless you keep spares on hot standby either in the data center or at another facility (or both).   Additionally, some Software based appliances don’t provide the flexibility to “split” a configuration, with some devices being moved to one location or instance and others being moved to a different location or instance.

You might also need to connect new platforms, such as Windows, Unix/Linux, Novell, or even Macintosh servers (or any combination of them at once) to your Cloud Storage devices. Your gateway should be flexible enough to cover any configuration at any location.

As a Virtual Machine that can be run on VMware, Hyper-V, Citrix XEN or Amazon EC2, CloudArray™ is fully portable and highly available, and can be deployed in minutes at any site needing access to the data stored in the Cloud, including snapshots of the data.  CloudArray also has a “one button” backup/restore capability which can be used in conjunction with restarts in a new location.  Additionally, CloudArray provides a mechanism to export specific volumes to other instances of CloudArray.  It is not an “all or nothing” architecture, and this is what we refer to as “Compute Anywhere”™ .

2.      Security

As a CISSP, I have some unique perspectives on security and the cloud.  A lot has been written about Cloud Security, and it is all valid, but a great deal of it is written from a perspective of running your entire compute infrastructure in the public cloud.  In the broader domain of Public Cloud Computing, all of your systems are vulnerable because more doors exist, the walls become a lot lower and a lot more porous, and you have a lot less direct control or even oversight.

In the case of data center connecting to protected Cloud Storage however, especially where the gateway is safely within your firewall and data center control, the unique security concerns become much more narrowly focused.   You now become primarily concerned with the transport and storage of your data; traditional concerns over the access controls, leakage prevention, audit, scanning, and other infosec controls will still be covered by your internal policies and systems.

Here, you can get by with a single compensating control:  encryption.

If the data you store at a Cloud Storage Provider is encrypted and you hold the keys on-premises, then there is no risk of loss or disclosure through the Cloud itself.  In fact, every public-sector regulation that controls the loss of private data has a provision to exclude the loss of encrypted data from disclosure requirements or penalties.    Certain government agencies have different requirements of course, notably those dealing with State Secrets and Military/Intelligence data, but that data would never be stored on a public cloud anyway.

With encrypted data, it doesn’t matter who the other tenants of the CSP are, it doesn’t matter where they (the CSP) store your data, it doesn’t matter what they do with their failed disk drives, it doesn’t matter whether or not they sanitize their drives before re-assigning them someone else, and it doesn’t matter how well they audit what their administrators are up to.

Keep in mind that if the keys are managed not by you, but by your CSP or by the infrastructure of the Gateway provider, you could lose data if they have a security lapse on their end. Also, encrypting your data doesn’t relieve you of having a well planned and well implemented Security Policy within your data center itself, but you need that regardless of whether you use Cloud Storage

CloudArray supports AES 256 bit encryption (with HMAC) for data in flight and at rest, SSL for data in flight, and IPsec for local communication security.  All keys are managed and controlled locally.   You control the front door from within your data center and there is no back door.

Be sure to verify that you can backup and secure your keys.  Losing the keys to encrypted data, or having them lost on your behalf, won’t do much for your professional well being.

Coming up:

3.       Performance and Consistency

4.      Scalability

5.      Flexibility and Ease of Management

Tags: , , ,
Posted in Uncategorized | 5 Comments »

VMware Backup: VDR to Cloud Storage might be just right for you

Friday, June 4th, 2010

by Greg Roody

VMware Data Recovery (VDR) isn’t new, it’s been around since the release of vSphere as a no-charge option, but it is gaining some new attention as a means of not only doing de-duplicated B2D but also as a means of storing those backups remotely to Cloud Storage.  In effect, combining VDR with a Cloud Storage option like CloudArray™ will achieve B2D2C in a simple, secure, and cost effective way.

VDR has its limitations to be sure; it only supports 100 VM’s and 2TB of de-du[ped/compressed target data (VMware does see up to a 10:1 comptression ratio however) per VDR instance and it doesn’t support linked vCenter servers or linked clones.  But even within those limitations (it’s a first generation product, and you can be sure VMware will improve it and expand its reach), it can be a very viable solution to real headaches you are fighting today.

One big win for VDR is that not only does it perform de-duplication, but it also does changed track updates.  What this means is that the notion of Weekly Full backups and Nightly Incremental is gone.   After you create the first image backup (and remember, it is doing block level de-dupe so even that is a much smaller image than your source), every backup after that only sends the changed data which is again also de-duped.   VDR also maintains restore points based on every backup run, so you still have multiple restore points to choose from, just like with traditional backup solutions.  Of course, it’s all disk based so there is no need to manage tapes.

Now combine that capability with CloudArray, and you can remotely replicate those backups to a Cloud Storage provider (Public or Private).   This provides a critical element for a BC/DR strategy without the direct expense of maintaining a second location.

With CloudArray, you have the option to maintain a full local copy in CloudArray cache, or a partial copy. The advantage of maintaining a full local copy is that you will never have to go to cloud storage to retrieve your backed up VM's unless you have a major site disruption. In either case, you have the option to take snapshots in the cloud, thus preserving older restore points and allowing you to maintain the consistency of the backup set in the event something happens to your on-line copy.

If needed, these remote backups can be restored to any location you choose, even from instances running on Amazon EC2.  This greatly expands your options if a disaster recovery site ever needs to be stood up.

Of course, being a B2D2C solution, the need for tape is eliminated, as is the need to manage those tapes or transport them to offsite storage facilities.  And since the backups are on-line, you can restore from either local cache or the Cloud without having to schedule a truck to go and try to find them.

It’s non-disruptive

There is no need to upgrade or rebuild your current environment to start using VDR.  It’s a simple appliance deployment and a plug-in, both included with vCenter and vSphere.  From the CloudArray side, it’s a simple appliance deployment and client UI install.  Along with some simple configuration steps, that’s all you need to start backing up your VM’s to cloud storage.  You can even retain your current backup environment, using VDR on only those VM’s you want at any given time and slowly converting over.

Fast. Simple. Secure.

You  can literally go from no solution to a complete VDR solution with CloudArray in under 30 minutes.   Included will be full AES 256 bit encryption to the target Cloud Service Provider.   You can watch a short 10 minute demo here (http://www.twinstrata.com/VideoCloudArrayVMwareVDR) of the major steps required to configure and use it.

And once you have CloudArray installed, you can also use it as primary VMFS storage or as RDM devices for any use with VMware.  That means that you can use SVmotion, cloning templates to cloud storage for safe keeping, or just build new VM’s directly onto cloud storage.

More Information.

Visit http://www.twinstrata.com/VMwareVDR.html for more information on using Cloud Storage with VMware, including customer use cases and real world applications.  You can learn more about VMware Data recovery at http://www.vmware.com/products/data-recovery/ , and you can follow discussions about VDR at VMware’s blog, http://blogs.vmware.com/uptime/.


Tags: , , , ,
Posted in Uncategorized | 5 Comments »

« Older Entries