Much has been written about the Amazon failure that really put the enterprise adoption to Cloud a bit on the back foot. Amazon's outage was caused by a failure of the underlying storage - the Elastic Block Storage.

The Elastic Block Store (EBS) is a distributed and replicated storage optimized for consistent and low latency I/O from EC2 instances. EBS runs on clusters that store data and serve requests and a set of control services that coordinate and propagate I/Os.

The following are the mechanisms that are supposed to protect the durability of data in Amazon EBS.

• AmazonEBS volumes are placed in a specific Availability Zone and can then be attached to instances also in that same Availability Zone.
• Each storage volume is automatically replicated within the same Availability Zone. This prevents data loss due to failure of any single hardware component.
• AmazonEBS provides the ability to back up point-in-time snapshots of your data to Amazon S3 for durable recovery.
• AmazonEBS provides the ability to create point-in-time consistent snapshots of your volumes that are then stored in Amazon S3, and automatically replicated across multiple Availability Zones.
• So, taking frequent snapshots of your volume is a convenient and cost-effective way to increase the long term durability of your data. In the unlikely event that your AmazonEBS volume does fail, all snapshots of that volume will remain intact, and will allow you to recreate your volume from the last snapshot point.

So it is clear that Durability of the EBS data lies in the hands of the Cloud Consumer too in terms of how the inter availability and intra availability backups are planned.

While we are seeing this problem is getting solved for now, this would create a long term impact about the Storage fundamentals for the Cloud. In this context it is desirable to look into the Storage Fundamentals of Mainframe Era and  Non Stop Computers Era which has got several good practices to follow.

Mainframes and System Managed Storage
Decoupling the storage management activities from the rest of the applications and systems is not a new concept, legacy MVS Mainframe systems have an automated storage management system called SMS/DFSMS.

On April, 1988 DFSMS for the mainframe computers was announced. Commonly called "SMS," this architecture consisted of a set of related software products that marked the most comprehensive set of policy driven storage and data management capabilities for disk storage introduced up to that point of time.

We find SMS has abstracted lot of Storage management functions from the applications much like the modern Cloud Storage management systems like EBS do. Here are some of the features of the SMS.

• Application is relieved of making decisions about resource allocation of data sets
• Provides ability to handle storage across multiple devices
• Avoids erroneous deletion of files created using SMS and support durability
• There are features like MGMTCLAS, which is used to control migration of files (data sets) created using SMS. It controls details like frequency of back ups and number of back up versions. This also determines whether a data set should be retained indefinitely and backup up every day. This can also determine if a data set can be delete if not accessed for a while.
• SMS also supports commands for Disaster Recovery to back up all data sets associated with a particular application by using features like logical data dump
• Extended remote copy (XRC) is a hardware and software solution disaster recovery solution. It provides an asynchronous copy operation of both system-managed and non-system-managed data to a second, remote location. Remember EBS by default can backup within a given Availability Region only.
• Also for supporting multi tenancy and backup and recovery for individual client needs, SMS implements features like, Aggregate Groups and Tape Storage Groups
• Aggregate backup and recovery is a process to back up and recover user-defined groups of data sets vital to your business. During aggregate recovery, backed-up data sets are recreated at the recovery site.

Storage Management in Non-Stop Systems
Much like the storage management in mainframes, we have also seen a strong storage management fundamentals on Non Stop Servers. We have seen that this product announcement dates back to 1997.

With the combination of NonStop Storage Management Foundation (NonStop SMF) software, and Integrated Research offers Automated Storage Manager (ASM) software, we have the power to administer hundreds of disks from a single graphical console. We set the storage policy; NonStop SMF software manages your physical files, and ASM software ensures that the policy is upheld.

Much like its mainframe DFSMS counterpart, NonStop Storage Management which again a candidate from legacy era has several best practices for large storage management.

• Flexible storage policies tailored for each enterprise requirements
• User-specified storage management
• Simplified operations and management
• Location-independent naming and storage pools for better storage utilization
• The Non Stop SMF product allows you to group physical disks into a storage pool. Applications read and write to virtual disks associated with the storage pool, which appears to applications as if it were a single physical disk.

Summary

This article is not meant to be a tutorial on DFSMS or Non Stop Storage Management. However, we have seen that several underlying principles of the cloud:

• Early adopters of Virtualization
• Multi Tenancy
• Charge back accounting

have been the fundamentals of the mainframe computing in the past. While the cost efficiencies of the commodity hardware that Cloud Computing players like Amazon are bringing cannot be discounted; however, there should be zero tolerance on the availability and fault tolerance.

Exponential growth of storage will be a key challenge for Cloud Computing to face immediately, some reports suggest that the size of the "digital universe" will swell so rapidly this year that it will pass the "zettabyte" barrier for the first time. So efficient Storage managers are the most important need of the day, Amazon EBS and S3 are all very good thought processes to support a public Cloud infrastructure; however, as seen now there are shortcomings in the implementation and repeated failures will erode the confidence in the Cloud platform as a whole.

On the contrary we have seen the older storage management systems like DFSMS or Non Stop SMF have a very good track record for managing large amount of storage with relatively less failure rates; however, it is true that their cost of operations are very high. So if the newer cloud platforms try to bring in the same level of reliability while keeping the costs low, that would be a most useful value proposition for cloud consumers.

• Amazon Web Services Launches the Amazon Elastic Block Store for Amazon EC2
• BitNami Releases Free Amazon EBS-Backed AMIs, Enables Production Deployments of Open Source Applications on the Amazon Cloud
• Cloud Computing: Amazon Launches the Amazon Elastic Block Store for Amazon EC2