1. Hybrid data storage environments combining cloud storage with existing storage. For most companies, the notion of moving all of their data to the cloud is not fathomable. However, continuously expanding data storage needs are fueling a need for more capacity. What better way to address this need than with cloud storage? The benefits include access to a secure, limitless pool of storage capacity, no future need for upgrade or replacement and reduced capital expenses. Look for auto-tiering technologies to seamlessly combine hybrid cloud and on-premise environments in a way that operates with existing applications.
2. Private cloud environments in enterprise companies. Enterprises looking to leverage the economies, efficiencies and scale of cloud providers are adopting cloud models in-house, such as OpenStack, for both compute and storage environments. These private clouds offer scale, agility and price/performance typically unmatched by traditional infrastructure solutions and can reside inside a company’s firewall. In the storage space, look for technologies that can combine existing SAN infrastructure and private cloud storage into a unified Cloud SAN.
3. Disaster recovery to the cloud as a viable option. Traditionally, companies that need disaster recovery (DR) and business continuity (BC) have relied on dedicated replicated infrastructure at an offsite location to be able to recover from physical disaster. This means paying for idle hardware that’s waiting for a disaster. DR in the cloud, on the other hand, means not having to pay for this infrastructure except when it is needed. The tradeoff? While not necessarily a zero-downtime solution, look for cloud DR with recovery time objectives (RTOs) in a matter of hours.
4. Disaster recovery from the cloud as a new need. What happens to business data stored by SaaS application in the case of a disaster? The truth is most SaaS providers do have a DR strategy, but many businesses will demand a recovery strategy under their control. Look for emergence of solutions that backup SaaS data either locally or to an alternate provider as an extra level of protection.
5. Simplified onboarding of applications to the cloud. Certain business applications can move entirely to the cloud, thereby saving the administrative and maintenance headaches of their hardware/software platforms onsite. Many IT-strapped businesses can benefit from tools to make this migration viable. Look for robust tool sets that can migrate applications to a choice of cloud providers – and also bring those applications back on-premise should the need arise.
6. Non-relational databases for big data. NoSQL databases, like Apache CouchDB, enable tremendous scalability in order to meet the needs of Terabytes and Petabytes of data accessed by millions of users. Big data will force many companies to consider these alternatives to traditional databases and cloud deployment models will simplify the roll-out. Look for vendors providing supported NoSQL solutions.
7. Use of the cloud for analytics. Analytics tend to require a scalable compute and storage environment as well as rather expensive software. Similar to idle hardware for disaster recovery purposes, analytics for many businesses may represent a seasonal need that only runs in short bursts and may not justify purchasing a dedicated software/hardware environment. Analytic environments in the cloud can turn the expense into a “pay-per-use” bill, meeting business goals at a far lower price point.
8. SSD tiers of storage in the cloud. Moving higher performance applications into the cloud doesn’t always guarantee that they will get the level of performance they need from their data storage. By offering high-performance tiers of storage that are SSD-based (i.e. flash), cloud providers will be able to address the needs for predictable and faster application response times.
9. Improvements in data reduction technology. With cloud storage commanding a per GB operating expense, deduplication and compression technologies have become rather ubiqitous in minimizing costs. While some may argue the capacity optimization game has played out, there is still the challenge of capacity optimization on a more global scale across multiple tenants and a challenge for rich media content which does not fare particularly well with today’s reduction technologies. Look for the introduction of new data reduction technologies that address both needs.
10. “Cloud-envy” from cloud laggards. While many companies have already adopted the cloud and many more will adopt in 2012, others may still wait and ponder well past 2012. Regardless of which category a company falls into, the economics and efficiencies of the cloud have become irrefutable. As a result, some of the laggards will likely seek ways to leverage cloud methodologies that improve IT efficiency on-premise. Undoubtedly, some will fall prey to cloudwashing by purchasing traditional IT infrastructure named “cloud” in an attempt to satisfy their “cloud-envy.”

Bottom line? Cloud deployments are becoming simpler and more secure and the economics continue to improve. Which of these trends will your business follow in 2012?

Bookmark to:
Del.icio.us | digg | Twitter | MySpace |
FaceBook | reddit | Stumble Upon |

As mentioned in Part I, traditional data storage deployments typically require new storage array purchases every 3 to 5 years and also require the decommission of old storage arrays at the same time. The area chart below graphically illustrates some of the economic inefficiencies of this deployment model. While most organizations consume storage at a near linear rate over time, the required initial pre-purchase of capacity results in a relatively disproportionate up-front investment. The blue area on the chart shows how total cost of ownership (TCO) increases over time with traditional storage deployment – note the spikes at every purchase cycle (Q1 Y1 & Q1 Y4). The yellow bars on the chart illustrate how TCO increases with a pay-as-you-go cloud storage model. Even in this simplistic case where the TCO of both models is identical after 3 years, you can easily spot the inefficiencies of traditional storage which requires pre-payment for unused capacity.

TCO of traditional 3-yr life cycle versus pay-as-you-go cloud storage

Now keep in mind, this is a very basic analysis. In practice, there are many additional costs that factor into traditional storage deployments including:

• administrative costs of the migrations from old arrays to a new arrays
• potential overlap where both arrays must be maintained simultaneously
• potential downtime and productivity loss during the migration process

Furthermore, the analysis does not capture some of the additional cost savings of cloud storage that include:

• economies of scale in pricing and administration as a result of leveraging large multi-tenant cloud environments
• price per GB erosion over time

Factoring these additional costs of traditional storage and additional savings of cloud storage may convince you that it is time to introduce cloud storage into your existing IT infrastructure. But where do you begin?

Given most storage consumed by businesses is either block-based or NAS-based, an on-premise cloud storage appliance or gateway that converts cloud storage to a block or NAS protocol can greatly simplify deployment. When choosing a solution, keep in mind that, unlike NAS, block-based solutions have the advantage of supporting both block-based access and any file system protocol. Block-based iSCSI solutions, such as CloudArray, support Petabytes of storage and provide thin-provisioning, caching, encryption, compression, deduplication and snapshots, matching feature sets of sophisticated SAN storage arrays. These solutions can readily reside alongside existing SANs and are available in both software and hardware form factors.

Cloud storage appliances can grow to a virtually unlimited storage capacity without the need to ever upgrade, eliminating many administrative burdens and risks of the storage array life cycle. Since cloud storage is pay-as-you-go, cost adjustments occur automatically, eliminating the economic inefficiencies of the storage array life cycle.

While cloud storage may not necessarily meet all on-premise storage needs, it can still augment existing storage infrastructure. A hybrid local-cloud storage environment can streamline storage operations and can even extend the life cycle of traditional storage through selective data offload.

Want to learn more about efficient hybrid storage environments? Look for Part III of this series where we examine how to enhance storage infrastructure using a combination of on-premise and cloud storage.

Bookmark to:
Del.icio.us | digg | Twitter | MySpace |
FaceBook | reddit | Stumble Upon |

Although decommissioning and upgrading a storage array may not appear all that daunting, the process includes a number of cumbersome aspects:

• First, the migration process from old to new storage arrays could last months, creating an overlap when both the old and a new storage array must be maintained. In some enterprise environments, the migration could even cost thousands of dollars per Terabyte (read “Reducing Costs and Risks for Data Migrations” research paper by Hitachi Data Systems for more on the topic of costs)
• Second, when purchasing a new storage array, its sizing is selected based on anticipated future growth, resulting in an initial capacity “over-purchase” and an underutilized storage array for most of its life cycle.   Result?  Pre-payment for capacity you may not need over the next 2 years
• Third, software and architectural changes associated with each storage array upgrade may compromise stability or, at a minimum, require staff retraining on new tools, policies and features

So why decommission arrays at all? Why not simply expand storage capacity by adding new storage arrays instead of replacing them? Well, with storage densities and capacities growing every year and cost per GB dropping every year, the economics provide the answer.

Let’s say you own a 10TB storage array from 3 years ago that cost $50K to purchase and has a total annual maintenance cost (vendor maintenance fee, administration, floor space, power, cooling, etc) of $25K per year. Now let’s say today you purchase a new 25TB storage array for $50K. Thanks to improved storage density, you may find it carries the same total annual maintenance cost of $25K per year.

If you choose to keep both arrays active, you would now have data residing on the old storage array at $2.50/GB in annual maintenance cost and data residing on the new storage array at only $1/GB in annual maintenance cost (with plenty of capacity to spare). This economic inefficiency makes a pretty strong business case for decommissioning the old array and moving all data to the new array as quickly as possible.

So is there any hope of breaking this storage array cycle?

There is indeed hope with on-demand cloud storage. Cloud storage substantially changes the economics and deployment of data storage and makes some of the aspects of the storage array life cycle start to disappear entirely.

• With a pay-as you-go model, there is no longer a need to ever pre-purchase or over-purchase capacity
• The yearly cost per GB drops every year as cloud providers continue to lower costs every 6-12 months
• Storage capacity is virtually limitless, so there is never a need to decommission or upgrade any hardware

Sound appealing? Look for part II of this series, where we’ll examine exactly how cloud storage can start to break this storage array life cycle.

Bookmark to:
Del.icio.us | digg | Twitter | MySpace |
FaceBook | reddit | Stumble Upon |

Is Data Growth Getting You Down? Then Look Up To the Cloud!

• Thursday, February 10, 2001 
• TwinStrata Offices
• 24 Prime Parkway, Suite 301A
• Natick, MA 01760
• 9:30 AM to 1:00 PM 

TwinStrata Can Help Colleges & Universities Capitalize on Cloud Storage…Simply, Securely, and Affordably

Are you looking for ways to battle shrinking budgets yet still address the need for ever-increasing storage capacity, efficient off-site data protection and affordable disaster recovery across your campuses?

Using TwinStrata CloudArray®, an affordable iSCSI data protection and disaster recovery cloud storage solution, can bring relief. It’s non-intrusive and non-disruptive, requiring no “rip and replace” of any existing application or infrastructure. 

Attend our Higher Education Lunch session on Thursday, February 10, 2011 and learn how TwinStrata can help you:

• Turn capex into opex  
• Balance your capacity demand and cost
• Seamlessly scale IT using cloud storage
• Reduce IT complexity and increase IT efficiency

The program will include:

• Lunch
• A $25 VISA Gift card for attending
• An opportunity to meet our Development and Management Teams
• Participation in a CloudArray workshop
• A grand prize drawing (must be in attendance to win)

Bookmark to:
Del.icio.us | digg | Twitter | MySpace |
FaceBook | reddit | Stumble Upon |

One of the first decisions you will need to make when tuning your environment for Cloud Storage I/O is what page size you will use to perform writes to your Cloud Storage Provider (CSP).  This is one of the configuration parameters you will enter when configuring a new volume in CloudArray. 

Page sizing is an important consideration, and represents the smallest unit of data that will be sent to your CSP from your CloudArray appliance, or read back when needed. Choose a size that is too small and you may have to do a lot more I/Os if you need to move a lot of data in bulk.  Choose a size that’s too big and you will move more data than you need to.

For example, if your application needs to read a lot of small chunks of data that don’t already reside in your CloudArray cache, then CloudArray will have to issue read requests to the CSP for each of those chunks.  If each chunk was 64K in length, and they weren’t contiguous, then CloudArray might have to issue 4 separate read requests for that data.  If the data were contiguous, then only 1 read request would need to be made.

Larger Page Sizes will result in more data being read than is needed for the current operation, but it may help performance if that data is needed at any point while it is still in cache. In CloudArray, you can choose variable page sizes from 128 KB (default) all the way to 2 MB.  512 KB is the recommended value for backups and in cases where there is a lot of sequential I/O. 

If you do a lot of random small block I/O, you should choose the smaller default page size.  This will prevent having to move a lot of empty data between your CSP and the CloudArray appliance.  A large page size here will cause slower overall performance since a lot more pages will have to be written to accommodate the data requirements. Likewise, if you are doing backups, you will want the 512 KB (or larger) page size.  This will result in fewer overall writes compared to a smaller block size and performance will increase.

This can have an impact in your cost model as well, but nowhere nearly as much as some vendors selling file system-based appliances would have you believe.  Some CSP’s will charge a small per transaction fee for each read or write request you make.   For Amazon S3 for example, the charge is $0.00001 per write transaction.  And so for a 1TB backup, that amounts to 8,388,608 x 128KB transactions, or $83.  If you used a 512KB page size, that would amount to 2,097,152 write transactions, or $20 for the write transaction costs.  Reads are cheaper by an order of ten.  That’s a far cry from the $1K+ figure for a 100GB write that another vendor would cost you.

Visit www.TwinStrata.comfor more info about CloudArray.

Bookmark to:
Del.icio.us | digg | Twitter | MySpace |
FaceBook | reddit | Stumble Upon |

Businesses continue to rely on tape for its unique role of providing long term archival and replication of data. Tape spans the entire continuum of data centers, from the self maintained racks in a storage closet to multi-million dollar facilities with multi-homed infrastructure and large organizations supporting them. It’s used and accepted up and down the economic ladder and isn’t going to go away any time soon.

So why should you consider an alternative?

There are actually several good reasons to either augment your current use of tape or eliminate it altogether. But it all comes down to recovery. Nobody backs up data thinking they will never need it again. It’s not just an exercise in compliance.

You back up to tape because at some point, you will need to restore data that isn’t recoverable any other way. But in most cases, you will do that restore within 30 days of when you wrote it. That small fact, which ESG confirmed in a recent survey that showed that 95% of all restores are done within 30 days, belies the rationale most people use to write to tape in the first place.

The reason for that is that tape is a terrible medium to use for short term backups. It stretches, it breaks, it has a high error rate per tape, they get lost and a lot of the time and in many cases data can’t be recovered from a tape because it was either never written or because the tape has too many errors. These problems are only going to get worse as tape densities and length increase and as you put multiple TB’s worth of data on each one.

But you still need long term, as in 7-10 years worth, storage requirements for both policy and regulatory compliance issues. You are caught between two competing operational goals and are forced to accept a one solution fits all answer.

Or are you?

The answer lies in your ability to separate short term data recovery and offsite storage needs from long term archival. If you could find a way to keep a near-line copy of your data, you could satisfy your short term recovery needs. If you can retain tape as a long term archival method, even if it is at a reduced retention schedule, you can meet your long term goals and greatly reduce your costs. If you can do both, your operational readiness will increase drastically and your costs will dive.

The good news is that you can do both. By deploying CloudArray along with a tape backup solution, you can meet your short term recovery goals with on-line copies of your backups locally while at the same time keeping copies in the cloud to meet your short term offsite retention requirements, and tape copies in a warehouse to meet your very long term archival requirements.

Most backup products will allow you to keep both a tape and a disk based copy of the same data set. So your basic policy would be to do daily backups to CloudArray, thus preserving your ability to restore data meeting both RPO and RTO objectives, while at the same time running 30 day full backup cycles to tape for long term storage requirements. You can set your CloudArray backups to any schedule you choose, so you can retain daily, weekly, or monthly backups for any amount of time. If you kept daily backups for 60 days, then weekly backups for one year, and monthly backups for two years, the tape copies would never have to be touched inside of that 2 year window. 

It’s the best of both worlds. Do you agree? Visit www.TwinStrata.com for more information and a free 30 day trial.

Bookmark to:
Del.icio.us | digg | Twitter | MySpace |
FaceBook | reddit | Stumble Upon |

Interest in the cloud storage is exploding. Even though cloud storage promises unlimited and elastic capacity, faster provisioning, and pay-as-you-go, it’s probably helpful to first figure out which data makes sense to move to the cloud that won’t necessarily cause high concern about data privacy and security and can set you on a path to shift storage costs from a capital expenditure to an operational expenditure, freeing capital to support other parts of the business.  

A few data types for your consideration include:

• Backup services (disk-disk and disk-tape)
• Archive files and older project data
• Disaster recovery
• Capacity expansion/file storage
• SaaS application data
• Media distribution data
• Large scale analytic data
• Development and test data

Cloud storage isn’t a slam dunk. Moving to a tiered cloud storage strategy involves careful consideration of business objectives, financial analysis, and effective capacity planning.

TwinStrata CloudArray can shorten your decision process and help make your transition to a cloud storage strategy seamless, non-intrusive, and efficient. Many have done so already. Using CloudArray’s innovative caching, flexible deployment models, and automated policy-driven data protection features, CloudArray can help you protect and store more data while lowering your capex and provision more storage faster and easier as you grow.

Check out CloudArray: www.twinstrata.com

Take advantage of the CloudArray free 30 day trial: www.twinstrata.com/cloudarray_evaluation

Bookmark to:
Del.icio.us | digg | Twitter | MySpace |
FaceBook | reddit | Stumble Upon |

The recent announcement that CloudArray has been qualified to work out-of-the-box with VMware HA solutions allows you to better protect your busines information 24×7 without major investments in costly resources. With support for multiple VMware availability options, TwinStrata’s CloudArray ensures your off-site data protection operations are uninterrupted and cost-effective with continuous data access in the cloud.

Additionally, when CloudArray is configured with VMware HA or Fault Tolerance you can also think about eliminating complex manual recovery steps (staff), reducing storage acquisitions (capacity), and flat out improve productivity (tools).

Sounds like you may not need to worry too much about shrinking IT budgets afterall.

Bookmark to:
Del.icio.us | digg | Twitter | MySpace |
FaceBook | reddit | Stumble Upon |

 
What if a developer came to you and wanted a 350TB volume for a day?  They wouldn’t actually need to write a lot of data to it, but they need to prove their app would be compatible.  How would you accomplish that?

With Thin Provisioning of course.

Thin provisioning is a form of storage virtualization that is implemented as a basic function within CloudArray.

What it does is allocate physical storage on-demand, only consuming real  resources at your cloud storage provider (CSP) when you actually write something.  Merely creating and provisioning a volume in CloudArray doesn’t consume physical resources in the Cloud until you write some data to it.

As a result, you can easily create that 350TB volume, which will appear to your servers as physical storage, but which consumes no real storage at your CSP (and thus doesn’t generate a large bill). As you layer a file system or volume manager on it, a small amount of storage would be consumed for metadata directories and inodes.  As you write new data to the volume, it will grow accordingly and you will pay for what you actually use.

For example, here is a screenshot after creating a 350TB volume in CloudArray.

Notice that it is utilizing  zero MB.   Until we actually mount it and write some metadata to it, it is nothing more than an empty shell, yet any server mounting it would see what looks like a 350TB physical volume.  In CloudArray, each volume can be as large as 384 TB, and you can configure as many volumes as you need.  Of course, you will have to manage your cache accordingly, so there are limits, but not in what you can create.

This has a very positive effect on performance (as well as economics).  You don’t have to read back unallocated blocks when an application calls for a range of blocks for example.  Less data to read and write is very good for Cloud Storage performance.

This sounds great on the surface (and actually is very powerful), but there are some cautions you need to take to make the most of the functionality.

More after the fold…

If you write it, you own it

For example, you will want to avoid running any tools or utilities which perform a lot of unnecessary writes to large portions of a volume.

Defragmenters are a good example of this type of tool.  They will try to optimize the layout of data on a physical disk for optimal performance, except that in the case of Cloud Storage the concept of a physical disk is highly abstracted, and thin provisioning means that a large number of the blocks a defragmenter will write have never been provisioned on physical storage.  Defragmenters provide no performance benefit in a Cloud Storage environment, and can actually hurt performance by causing unnecessary reads and writes.

You will end up inflating the volume in these cases, and once written, you will not be able to reclaim the storage and free it up without additional processes.  There is no reason to run a defragmenter, and they should be disabled for any volume that ultimately resides on Cloud Storage.

As discussed in a Wikibon article on Thin Provisioning, other things to avoid include File Systems that write to unused blocks as opposed to reusing storage, or using applications that spread metadata across an entire volume (some database applications will do this, effectively allocating 100% of your volume in physical storage).

These limitations will affect the amount of storage you physically write and the amount you are charged by your CSP.  Also, if the blocks have never been written, any application that attempts to read them (yes, some will)  or search a range of blocks at the physical level, will not have to recall those blocks from the cloud.  They will be supplied by CloudArray as all zeros.  Otherwise you will have to transfer a lot more blocks of data, and this will increase your data transfer times and increase your latencies.

You can easily try all of this for yourself by downloading a Free Trial of CloudArray.  Visit www.TwinStrata.com for more information.

Bookmark to:
Del.icio.us | digg | Twitter | MySpace |
FaceBook | reddit | Stumble Upon |

We recently used Clarity AP to conduct a total cost of ownership (TCO) analysis of cloud storage as an offsite replicated tier of storage accessible via our cloud gateway, CloudArray. For the analysis, we assume a company with a single site for data storage and linear capacity growth over 3 years. We calculated the 3 year TCO of an in-house implemented offsite tier of replicated storage versus replicated storage to the cloud. We plotted the capacity crossover point up to which cloud storage holds a cost advantage.

While we invite everyone to look at the full report, here’s a brief summary:

Cloud storage may make sense for capacities up to 60TB for replicated data. At these capacities, cloud storage benefits from a pay as you go model that does not suffer the underutilization experienced in storage arrays. As a remote site data protection solution, cloud storage substantially reduces the need for offsite infrastructure and management.

The chart below illustrates the crossover point:

3-yr TCO for offsite replicated storage

For the initial TB of capacity, costs for an in-house solution over a 3 year period are $233,492, compared to $79,794 for cloud storage. For 20 TB, there is a $100,000 savings when data is replicated to a cloud provider.

The report lists results, configurations and cost assumptions. The analysis purposely neglects to factor local site floor/power/cooling since some may argue these are sunk costs. It also does not address application/compute failover which is a separate analysis.

Conclusion

Based on the results of this analysis, cloud storage can be very compelling for companies replicating up to 60 TB to a public cloud. For a mid-sized company or departments within a larger organization, this represents a substantial capacity range across which cloud storage presents a strong ROI. Watch for this range to expand even higher over the course of the next 3 years with more favorable cloud pricing and tiers of service.

Can your business benefit from cloud storage? Let us know.

Bookmark to:
Del.icio.us | digg | Twitter | MySpace |
FaceBook | reddit | Stumble Upon |