In my last post I talked about storage tiering and how it has evolved with the advent of new technology and of course the arrival of flash storage to mainstream deployments. One of the comments on that post indicated that I’d excluded Cloud as a tier of storage. Now, there are two ways to look at storage in the cloud, one of which could be to treat it as a tier, the other is to treat it just like on-premises storage.
Cloud as a Tier
If we look at pure storage offerings in the cloud, then these solutions definitely can be treated as a tier of storage in their own right. Broadly speaking, offerings are divided into primary storage (block, file and object) and backup.
On the file and block front, there are products like Nasuni & StorSimple that allow data to be moved from onsite appliances into cloud service providers. All of the file-syncing providers, such as Dropbox, Box, Google Drive, Microsoft SkyDrive could also be viewed in the same way, although not all of them might be called enterprise class and aren’t suitable for production data storage.
For object storage, there is of course Amazon’s S3 (Simple Storage Service), Google’s Cloud Storage and Microsoft Azure Storage. Some of the smaller vendors also provide object stores, such as Rackspace’s Cloud Files and HP’s Helion Public Cloud Object Storage. There is a subtle difference between object and file stores that needs to be articulated. Object stores don’t provide all of the features of SMB or NFS servers; they won’t manage object locking or store standard file-based metadata. They also don’t offer a security model integrated with standard tools such as Active Directory. This is of course why the file gateway providers exist and is the value they bring.
For secondary storage (i.e. backup and archive), there are many providers in the market place. All of the object storage providers see their platforms as suitable for archive and backup, with Amazon taking things a step further with Glacier; low-cost archive storage allegedly based on optical disks. Rackspace offers Cloud Backup and there are many consumer-grade backup solutions to choose from.
Tiering in The Cloud
The other option to consider is tiering of storage within the cloud itself. Object stores aren’t designed with I/O performance characteristics in mind, so I’ll exclude these from the discussion. Where tiering is important is in performance metrics applied to block storage in the cloud, used for storing virtual machines and application data. Starting with AWS, Amazon EBS (Elastic Block Store) now has three levels of storage, General Purpose (SSD), Provisioned IOPS (SSD) and Magnetic. Naturally, prices vary by type, as does performance, which is specified as a maximum number of IOPS per volume, where a volume can scale to a maximum of 1TB. The new SSD-backed Elastic Storage was only introduced last week and brings with it the capability to burst I/O demand once “credits” are accumulated through use. This is an interesting idea and I wonder how AWS will evolve this, perhaps allowing customers simply to pay for their burst capacity.
Not to be outdone, Google of course had their own announcement. Google Compute Platform now supports SSD Persistent Storage with a performance level ten times that of AWS standard SSD devices, or the same performance as AWS Provisioned IOPS (SSD) volumes. This feature is however, still in limited preview.
Rackspace block storage offers an SSD tier, simply called SSD volumes, although there are no obvious details on performance available on their website. Microsoft’s Azure platform currently has no support for SSD-based volumes.
The Architect’s View
Does tiering fit with Cloud Storage? Absolutely. However even with pure cloud solutions, the technology still refers to hardware devices rather than being 100% service based. The above solutions, for example recommend joining multiple volumes together to achieve higher performance levels.
We are definitely “getting there”, with more discussion on IOPS than physical device characteristics, so hopefully we’re moving closer to the idea of “infinite tiers” where we don’t even care what hardware the vendor is using, but simply set the requirements by dialling in an IOPS figure per GB of storage, our so called IOPS Density requirement. At this point Storage Tiering 5.0 will have arrived and we can move on.
- Moving on from Storage Tiering
- Understanding Storage Tiering
- New SSD-Backed Elastic Block Storage (AWS Blog, 17 June 2014)
- Introducing HTTP Load Balancing and SSD Persistent Disk on Google Cloud Platform (Google Cloud Platform Blog, 16 June 2014)
Comments are always welcome; please read our Comments Policy. If you have any related links of interest, please feel free to add them as a comment for consideration.
Copyright (c) 2009-2018 – Post #183D – Chris M Evans, first published on https://blog.architecting.it, do not reproduce without permission.