In the previous article of this series we examined both the benefits of and obstacles to implementing a data tiering solution for storage of your business data. The benefits of data tiering are clear, namely:

You can reduce storage sprawl, which makes storage easier to manage and therefore reduces cost.

You can more easily avoid overprovisioning storage, which helps keep storage costs under control.

You can boost performance of business-critical applications, which means happier customers and more profit.

You can realize better backup and recovery times, which means less downtime (and less lost profit) when your business infrastructure is interrupted.

You can find data more easily, which improves worker productivity and makes customers happier.

The bottom line of course is that data tiering can save your business money which you can then use elsewhere in order to boost profit.

But who really cares about money?

Timesheets and other fantasies

Many years ago I used to work as a technical trainer for a company that trained IT staff in the latest technologies. At the end of each week, I had to fill out a timesheet that summarized how many hours of work I performed for each cost center the company tracked. These cost centers included such things as classroom training, prep time for classes, setup time for classroom computers, time spent at a customer site, time spent doing required paperwork, time spent in meetings, time spent on professional development, and so on. There should have been a cost center for time spent filling out timesheets too.

Many of the trainers at this company found this whole timesheet thing a joke. As a result, they simply made up entries for the number of hours spent in each cost center when they filled in their timesheets for the week. Others like myself took the practices more seriously and tried to provide an accurate estimate of how they used their time.

Either way, we never heard any more about these timesheets. They seemed to simply fall into a black hole and disappear. Of course, there was probably a clerk who diligently entered each timesheet into a database so the data could be analyzed (we used paper timesheets back in those days) but once that was done it seemed like the data was never actually analyzed in any meaningful way.

But what does this have to do with data tiering? Well, if the business units in your organization are under the impression that storage is free, then they'll have no motivation to accept the necessity of implementing a data tiering solution. In fact, they'll simply want to keep all their business data on Tier 1 storage because it provides the best performance, greatest reliability, and highest level of availability compared to other forms of storage.

But if business units actually get billed for the amount of storage they use on each tier, then they'll likely be highly motivated to have their stale data migrated to Tier 2 storage and their unneeded data to archival Tier 3 storage because they can reduce their storage bills that way and use the money saved to fulfill their particular mission.

Driving data tiering forward using SLAs and bill-back

You can help drive acceptance of a proposed data tiering solution by following the process shown in Figure 1.

Figure 1: How to drive acceptance of a data tiering solution.

The sections that follow describe each step in the process in detail.

Step 1: Establish SLAs for each data tier

Before you can implement a bill-back solution for use of storage resources by the business units in your organization, you need to establish a service level agreement (SLA) for each data tier that you're planning on implementing. In fact, the best time to define your SLAs is during the process of planning how you'll implement a data tiering solution as that way you can use your SLAs together with mock bill-back to help drive acceptance of your planned data tiering solution.

The elements of an SLA can vary depending on the nature of the business and the type of technology implemented, but in general you'll want your data tier SLAs to include at least the following:

Uptime - This is often expressed in 9's (e.g. 99.999% guaranteeing uptime) but a better way is to specify the maximum number of minutes or hours of expected downtime per year.

Performance - This should include guaranteeing such things as minimum throughput in Mbytes/sec and maximum latency in milliseconds of delay for data transfer to or from storage.

Recovery - This involves guaranteeing both the recovery point objective (RPO) and recovery time objective (RTO) for performing backup and restore operations.

Provisioning - This involves guaranteeing the maximum time needed to respond to a request from the business unit for additional storage capacity.

Management - This involves providing business units with some kind of control panel so they can request or self-provision additional storage, view uptime and performance, verify RPO and RTO, and track their storage costs.

Ownership - This involves identifying who owns the stored data and who can access it. Typically the business unit owns the data and IT can only access it when given permission, but law enforcement agencies can also have access under court orders or subpoenas.

Limitations - This involves describing what forms of service interruption are not covered by the SLA, for example the failure of a router that connects the business unit's servers to cloud storage.

Maintenance - This involves notifying business units of planned or unplanned maintenance operations so they can evaluate the possible impact of such operations.

Support - This involves identifying who the business unit should contact in case of a problem or service interruption, the process for issuing and responding to support tickets, the escalation procedure, and the expected response time for different levels of problems.

Cost - This involves summarizing the cost of storage and is typically specified in dollars (or some other appropriate currency) per terabyte (TB) per year.

Reimbursement - This involves describing how billing will be adjusted in the event that certain guarantees in the SLA are not met.

What is not necessary in a data tiering SLA is a technical description of the types of storage devices and architecture used to provide storage services for that data tier. Such technical information should be the concern of IT only, and is not relevant to a business unit requiring the provisioning of data storage for their operations. IT is responsible for ensuring the performance, availability, scalability, and security of storage resources. Business units merely need to know they can access their data when they need it at the costs outlined in the SLA.

Step 2: Implement mock bill-back

Once you've defined SLAs for each planned data tier in your storage infrastructure, you can start providing business units with mock bills for the storage they're presently consuming. They'll likely be shocked, especially if they're are currently using highly availability, high-performance storage for all of their business applications.

Step 3: Compare the costs

Once the business units have had a chance to digest the mock costs you've billed them for their current storage use, call a meeting with the operational head of each business units and do a presentation that shows them how much money they can save if they migrate their stale data to Tier 2 once IT has implemented the data tiering solution they've been planning. They'll be surprised and relieved to hear that they won't have to pay so much for storage, and most will happily embrace the idea of migrating their stale data to Tier 2 storage and beyond.

Step 4: Implement data tiering

The next step is to implement your data tiering solution as planned and migrate to Tier 2 the data that each business unit identifies as stale.

Step 5: Publish SLAs and implement bill-back

The final step is to publish your SLAs on the company intranet and implement actual bill-back for use of storage by each business unit. Of course, there may be some tweaking you'll need to do later, and you should survey each unit to ensure they're happy with the new solution.

Conclusion

In the next article of this series we'll examine some common forms of storage failures that happen in enterprise IT environments, how to avoid them, and how to deal with them when they occur.

See Also

The Author — Mitch Tulloch

Mitch Tulloch is a well-known expert on Windows Server administration and cloud computing technologies. He has published over a thousand articles on information technology topics and has written, contributed to or been series editor for over 50 books.

Preserving server hardware (Part 3)

This article examines some of the causes of and effects from overheating for business server systems, PCs, and laptops... Read More

Building a PowerShell GUI (Part 11)

I have two goals for this article. My primary goal is to modify the code we've created so far so that it displays some basic configuration information for the selected virtual machine. My secondary goal is to show you a couple of new techniques for displaying the script’s output... Read More