Cloud Optimized Storage Solutions: Part 3a – Tiering & Expectations

by dave on January 12, 2009


In Parts 1 & 2 of the Cloud Optimized Storage Solutions series, we took a look at the content being storage on COSS as well as how it is stored.  In Part 3 (split into two parts), we’ll examine the concepts of Tiering and also Service Level Agreements (SLAs) and their impact on COSS.  To that end, let’s get on with the show…

Storage within the cloud is meaningless without a measurable level of performance that it can be compared against. Since there are no established benchmarks that determine performance of storage within a cloud infrastructure, it is reasonable to apply tiering metrics to storage based on content valuation and service level agreements (SLAs) and utilize this as an overarching methodology to judge COSS storage capabilities based on application set.

Within the concept of Information Lifecycle Management (ILM), there exists the idea that storage can be “tiered” based on criticality of need, application storage performance, or other derived metrics that couple relative responsiveness and bandwidth to serviceability. Layered over the top of this metric is the concept of aggrandized Service Level Agreements that cover compliance, data protection, and data access (to name a few). To bring things into more direct focus, there are 4 direct “Tiers” that are recognized (or promoted) within the storage community: Tier 0, Tier 1, Tier 2, Tier 3. While it is worthwhile to note that these Tiers are arbitrary in nature, they do provide a baseline framework upon which to build a more robust data service model.

The Data Tier Models

Tier 0 & 1: Performance & Availability Guaranteed Storage

Tier 0 is a relatively recent addition to the ILM tiering schema and is based solely on the emergence of Solid State Devices (Fusion I/O, EMC/STEC EFDs, et al.). These storage devices feature sub-millisecond access times coupled with extremely high bandwidth to the storage subsystems, thus driving a higher level of storage access and bandwidth metrics for applications such as Online Transaction Processing (OLTP) and Data Warehousing. The criticality of response to these applications is of a higher priority than Tier 1.

Tier 1 was originally established to service high availability, high bandwidth, low response time application and storage needs that tied directly to OLTP/OLAP, DSS, Data warehousing, etc. type workloads. Typically applications in this Tier have a sub-20ms response time requirement (or best practice) and are more sensitive to latency issues than, perhaps, Tier 2 workloads.

Tier 2: Availability Guaranteed Storage

Tier 2 is commonly referred to a transitional data tier, namely due to the nature of data that lives within it. Common data placement within Tier 2 centers on file systems or data that has a change rate that is based on occasional access within a fixed window of time (e.g. 30-60-90 days). It has a decided focus and tuning towards making sure that data is “online” and accessible without stringent latency or performance criteria.

Tier 3: Accessibility Guaranteed Storage

The last noted Tiering level for data is Tier 3. Tier 3 can best be described as an archive level for stagnant or “stale” data that has infrequent access. Historically, Tier 3 has been policy driven, that is, the recipient for some sort of data migration movements versus being a primary storage Tier for end-user access. Within the COSS environment, however, Tier 3 becomes as crucial of a storage target as Tier 1 or 2 simply due to the large preponderance of unstructured data within the cloud space.

Expectations of Data Tiering

The somewhat open-ended definitions to these data tiering levels are purposeful. In defining the principles of a COSS, there is an inherent need to keep them somewhat fluid especially as content continues to change and develop more complexity. Additionally, while the cloud currently has a majority stakeholder in unstructured data, there is no reason why structured data (and associated programmatic hooks and layers) cannot regain ground. As stated previously, these data tiers, while arbitrary, still provide an essential top-down view of how data can be categorized when planning for a COSS implementation. As an extension of data tiering, it’s also important to understand how global and particular Service Level Agreements (SLAs) can and will affect the data stored on COSS.


ILM, to the best of my knowledge, is not an EMC-designed concept. Whether or not storage tiers existed BEFORE EMC popularized the term is indisputable and inherently inconsequential to this discussion.

 

Reblog this post [with Zemanta]
Share
  • Pingback: MOMENTS IN TIME: Storage Solutions()

  • rjhintz

    Are you going to talk about how an OLTP transaction gets committed to persistent storage in a cloud setting? I'm thinking of, say, a specific airline seat or a financial transaction that represents an equity buy/sell pair.

    I (more or less) understand some of the strategies that you outline here and other places once it's ready for commit and what happens to the persistent data after commitment. It's getting to the commit point in a cloud I'm not clear on. Some variant of 2 phase commit? Something with lower latency that's not blocking? Something that's optimistic and only rolls back if X happens?

    In this context I guess cloud is synonymous with federated database. I'm asking the federated database people similar questions, but I've bogged them down with security/compliance questions and they've gone stumm.

  • rjhintz

    Are you going to talk about how an OLTP transaction gets committed to persistent storage in a cloud setting? I'm thinking of, say, a specific airline seat or a financial transaction that represents an equity buy/sell pair.

    I (more or less) understand some of the strategies that you outline here and other places once it's ready for commit and what happens to the persistent data after commitment. It's getting to the commit point in a cloud I'm not clear on. Some variant of 2 phase commit? Something with lower latency that's not blocking? Something that's optimistic and only rolls back if X happens?

    In this context I guess cloud is synonymous with federated database. I'm asking the federated database people similar questions, but I've bogged them down with security/compliance questions and they've gone stumm.

  • Pingback: Update your bookmarks: Dave Graham » Yellow Bricks()

  • Pingback: Cloud Optimized Storage Solutions: Part 3b - Service Level Agreements — Dave Graham's Weblog()

  • Informative stuff, thanks for sharing, just bookmarking you, will sure be back again.