Tiered storage is a data-storage environment consisting of two or more kinds of storage delineated by differences in at least one of these four attributes: price, performance, capacity, and function. Any significant difference in one or more of the four defining attributes can be sufficient to justify a separate storage tier.

We explained that although tiered storage is currently a hot topic, it has actually been deployed in the mainframe environment for the last fifty years. This week we examine management issues of a successful tiered storage implementation.

Luckily, the criteria by which data is managed in a tiered storage environment can be simply stated. In fact, there are only three criteria:

Allocate the data to the correct tier

Move the data between tiers when appropriate

Delete the data when it is no longer needed

In the mainframe environment, implementing these rules is quite simple using the facilities of Systems Managed Storage (SMS). The execution of these activities is much more difficult in an open systems environment because of the wide variation in platforms and the lack of standardized tools and automation.

SMS enables the storage administrator to define “pools of storage” and to direct allocations into those pools, logical entities defined by the storage administrator containing multiple volumes.

Using the SMS Storage Group construct, the storage administrator can create volume pools that match the physical tiers as well as subdivide storage systems into smaller and more manageable groupings.

While managing the data is relatively easy, correctly categorizing the data is difficult in both the mainframe and open environments. Data categorization is often times the “missing link” that should align the enterprise storage strategy with business requirements.

We suggest the following steps to align enterprise storage strategy with business requirements:

Step 1: Assemble a Team

Clearly there needs to be a central authority—such as the storage manager or other designated individual leading the data classification effort. Other members of this core team should include representatives from operations, business continuity and disaster recovery, compliance/risk management and possibly a technical advisor and project manager.

Keep the core team relatively small—no more than 5-8 people will help ensure that rapid progress can be made.

Supplemental resources, including those from the business units can be either ad-hoc or matrixed to assist the core team. Specialties should include application support, data security, DBA, architecture and perhaps even legal & compliance resources.

Step 2: Define Your Classification Criteria

Once the physical storage tiers have been defined (based on price, performance, capacity, and function), define broad classes of service that map to the various tiers. Business requirements, rather than IT terms, should be used when describing a class of services. These requirements should include:

Availability and performance

Resilience, retention, and regulatory compliance

Security

The application or business owner can then map the business requirements (performance, downtime, RTO, and RPO, and special regulatory requirements) to a specific class of service.

Using this methodology, the data classification effort should NOT have to be readdressed as storage tiers change. The physical hardware and associated storage tiers will change over time, but new storage tiers can be simply mapped to the appropriate class of service.

[Steps continue on the next page]

Step 3: Classify Your Data

The value of any particular piece of data tends to be either constant or decrease over time. There is little or no data that becomes more important as it ages.

Review current data placement and identify opportunities to satisfy business requirements in a more cost-effective fashion. Is the data of constant or decreasing value to the organization? Is it initially allocated in the correct tier? If the data’s value decreases over time, is it appropriately migrated to lower-cost storage? Is it eventually archived and/or deleted?

Further, evaluate the risk and effort of implementing changes against the expected benefits; partner with the data owners to establish a storage policy that is consistent, supports business requirements, and is in the best interests of the enterprise.

During this process, additional opportunities (such as redundant, unnecessary, or missing backups) will be identified. Document these additional benefits of the data classification effort.

Step 4: Create a Proof of Concept

Once some high-impact applications have been identified as candidates, perform a proof of concept. Using the information collected during the classification process, select a target application that demonstrates high-potential savings and relatively low risk. Also, take care to select the right business partner for the proof of concept. If possible, select an application whose owner has a history of working with your team and can help you to succeed.

Implementing the changes requires little fanfare. Once the changes have been deployed, the data should flow to the new locations according to plan.

The final step of the proof of concept is to verify that the data has been fully moved to the proper destinations. Document the cost savings and processing improvements achieved.

Step 5: Move Forward

Publish news of the successful proof of concept to the business client management teams as well as within IT. Use this as a means of advertising and gaining support for the processing improvements as they are rolled out to the rest of the enterprise.

Internally, document any “lessons learned” and blend this information into the standard storage management processes.

Finally, repeat the application selection, classification, and implementation steps as necessary until you have satisfied the IT goals.