The Storage Economist

Have you ever had those kind of dreams where you are told that you did not finish a sophomore math class in high school, and unless you re-take the class, all your subsequent high school and college degrees will be null-and-void? I used to have a lot of these dreams after finishing my MBA. Well not to torment you in your dreams, but you may recall a few blogs ago, we discussed lesson #5, reducing storage opex with tiered storage architectures. We are not-redoing lesson 5, but there is so much more to say on this topic of segmenting data in such a way the CAPEX and OPEX costs are reduced.

You might be lead to believe that a comprehensive data and application characterization is needed before any tiered storage considerations are made, that is not true. We are seeing many examples of clients around the world moving into tiered-storage-by-accident. That is they create logical pools of storage, on different types of arrays, different connection protocols, management SLA, etc. through an integrated virtualization architecture. If the architecture is forgiving, then mistakes made with putting data on the inappropriate tier can be remedied my migrating or moving (application unaware) to the right tier. If your architecture is not forgiving, then moving data is painful and you had better put some serious time into data mapping and characterization. Your approach to the type of architecture, and type of virtualization to support this architecture, is a vital part of your move to tiered storage.

I subscribe to the appraoch of performing data and application characterization studies, but balance the time leaning about your data against implementing a flexible and forgiving tiered architecture. I would like to hear your comments or experiences with tiered architectures with FC or NAS storage.

If you want more, there is an excellent seminar (no, I am not speaking) around the US on Tiered Storage and alignment with business requirements. See the link to register and for dates/locations.