Primary Storage Optimization

There is now a lot of talk in the industry on Primary Storage Optimization.  I would define Primary Storage Optimization (PSO) as reducing the amount of physical capacity used compared to the amount of actual data in your primary storage.

Techniques used for this include compression, de-duplication, single instancing, etc.  

PSO is tough though.  It is easy to optimize non-primary storage using Storage Capacity Optimization techniques similar to above, but primary storage has different requirements and properties.

First of all you can get more optimization out of backup storage because there is more redundancy.

The PSO solution must run with minimum latency so it doesn't affect the application.  This has been a sticking point.

Who wants to add another point of failure or dynamic to the simple act of reading and writing storage?

There are some solutions out there, mostly software solutions that can do PSO.  To get around the latency I believe some of them do it post processing compared to in real-time.

To me it makes sense to do this on the SAN level.  Pop in an SSM blade and de-duplicate the storage on the network level.  I also think this is the best way to virtualize storage.  They can work hand-in-hand.

Storage Transformation

I have completed many storage transformations for many large organizations. I think most companies need one. To me a storage transformation is taking a look at multiple areas: Tiering (Storage services catalog), application alignment, storage cost optimization, storage utlization, backup and recovery assessment and archive.

Basically coming in using a tool such as ECC to collect data on all of the SAN attached hosts, meet with the business/application folks with a questionnaire to talk about the application and its requirements and do an infrastructure assessment.

For the storage infrastructure, create a storage services catalog that will meet all of the business requirements, fill in any gaps that exist. Use the business data to align applications to the appropriate tier.

Before you actually align the tier, come up with a good utilization target. 80% is a good one. With thin provisioning this step becomes much easier to implement, but assuming this doesnt exist, when you tier you move the data to smaller LUNs to improve utilization.

A backup and recovery assessment can be as simple as looking at all of the exisiting jobs and infrastructure and match the backups to the requirements previously collected. Maybe you really dont need to keep 1 year of data online, maybe you only need one backup a week, etc.
Normally it is good to talk about archive at this stage. This applies from structured to unstructured archive. Database archiving or moving files to an archive platform based on age, type, etc. This is harder than it sounds because of the available tools. Some of them slow down the system during high I/O's (DX).

This all becomes easier if you have a storage virtualization engine on top. Being able to move the data in the background to different tiers, increase utilization and auto0-archive makes it all the more easy.