The Sands are Shifting on the Desert - DrunkenData.com - Jon Toigo
Robert Pearson just submitted a response to a long thread that has been going on here for the last couple of days
that was stimulated by IBM?s speeds-and-feeds bragging around a new storage platform.
Read the original post and commentary here if you want to get caught up.
(I've set the link to open in a new window so you won't lose your place here.)
Anyway, I believe that Pearson's comments merit front page attention because they cut to the heart of several
timely issues -- timely to me, at least, because I am waist deep in work trying to synthesize the responses to
a lengthy survey we just completed of storage managers and administrators on the topic of the state of storage
into a set of use cases.
These cases will become part of a requirements specification for the folks at Hermes SoftLabs to consider as
they help the StorageRevolution create version one of its free CAPSAIL framework for open storage management.
Here is the quote, which was in part prompted by some excellent opinions offered by Pq65 and Chuck Hollis
from EMC.
This thread is the real Storage Revolution!!!!!!!!!
Is anyone listening to what Pq65 is saying? Or are they just hearing the words?
Chuck touched on the key point in his paragraph:
"The previous comments of need to use snaps could be augmented by need to vary workloads over time,
need to change access patterns, need to fill arrays up, need to replicate, need to figure out what happens
when a drive is rebuilding, what happens when cache gets full, etc. etc. which are all very real-world performance
issues that SPC (or any other standardized test) can't capture."
What would it take for EMC (substitute your favorite vendor here) to capture this Performance information?
Everybody in the trenches knows SNIA, SMI-S, SPC, TPC and others are very primitive and crude attempts to
establish some very necessary "Speed Limit of the Information Universe" baselines.
Like cutting butter with a sledge hammer.
We need a way to gather Performance information about the requirements of the Managed Unit of Information.
Not the Managed Unit of ?Enabling? Technology. Who cares? I never saw a blank disk drive that made any money.
If you are in the trenches, where you really need this information, you know the same thing that all vendors know.
You can never performance test the "real" environment. It is too risky or too expensive. For a vendor, it might show
that the design tradeoffs in your Unit of "Enabling" Technology are not the best fit for that Unit of Information.
The vendors do the minimum out of regard for the loss risk.
The trench people do the minimum because they don't have the resources.
All we get are minimums.
We need a Fundamental Shift in the Storage Paradigm. We need to be able to give Pq65 what he wants, needs
and deserves. At the same time we don?t want to threaten the vendors who could help but are lost in their own fog.
What is the feature/function set for the Unit of "Enabling" Technology for defined Units of Information?
Is it a Performance or a Bandwidth Unit of Information? Once these relationships are defined "for your IT shop"
then you can specify the generic Unit of Technology. Once the generic requirements for your Units of Information
are known you can figure out some way to benchmark specific Units of "Enabling" Technology.
Maybe we should reverse the Storage acquisition process.
The customers create representative Units of Information and the vendors have to show that their Units of
"Enabling" Technology will meet that IT shops "Speed Limit of the Information Universe" requirements.
Robert, with your permission, we are going to borrow some of your terms in my spec.
But let's dig into what they mean.
You refer to "Unit of Enabling Technology for defined Units of Information." I confess that I originally bristled
when I read your first mention of these terms many posts back. With all due respect, they sounded like just so much
more tech doublespeak. But, now, the sands have shifted on the desert. Within the context of performance testing,
I think I finally understood what you were talking about. So forgive my earlier blockheadedness and read on.
I would like to understand, as you would, what describes a Unit of Enabling Technology:
- what are its component features
- functions
- how do we measure them
- how could we represent them on a "dashboard" or display console for anyone who gives a hoot.
If these units of enabling technology could be defined, we might be able to manage IT much as we manage inventory.
Never buying what we don?t need and buying resource just in time to meet business requirements.
This would have great merit also as a means of gauging the efficacy of IT investments.
We could calculate how the expense of a unit of enabling technology mapped back to the value provided to the
business that purchased the unit.
We also seem to be in agreement that an understanding of Units of Information is a prerequisite for buying
the correct unit of enabling technology. As you wrote, "Once the generic requirements for your Units of Information
are known you can figure out some way to benchmark specific Units of "Enabling" Technology".
In short, we can't tell vendors what we need to buy if we don?t understand the requirements ourselves.
But that begs the question of how we define units of information.
I would very much like to hear your thoughts on this.
From a procurement standpoint, you are spot on when you say "Maybe we should reverse the Storage acquisition
process. The customers create representative Units of Information and the vendors have to show that their
Units of "Enabling" Technology will meet that IT shops "Speed Limit of the Information Universe" requirements".
I have made this same point (albeit, without the "units" terminology) over and over on this blog.
Are you sure my dad didn't know your mom somewhere along the way?
Anyway, I think this blog (and the StorageRevolution effort) could do a great service if we could do the
following:
- Define what a unit of information is and how a consumer can, procedurally speaking, characterize his data.
- We need to make the definition and the process "drool proof simple".
- Identify opportunities for automating the process by which we define the information unit so that anyone can do it.
- Define what a unit of enabling technology is:
- the procedure for defining such a unit,
- or at a minimum a checklist or breakdown of features/functions to consider.
Starting with these two concepts, we could begin
- Establishing worthwhile testing regimes for use in comparing the wares of vendors seeking our dollars.
- Monitor and perhaps manage the operations of infrastructure so that they better serve the company.
- Measure the performance of IT investments over time.
- Begin doing some modeling to anticipate future needs and their associated costs.
A noble objective and maybe too much for a blog. However, I find it interesting that once we hung this issue on a
"What is IBM smoking?" rant, everyone inadvertently put on their thinking caps?
Can we possibly do, in a conversation here, what SNIA has failed to do with its big brainiacs behind closed doors
for the past seven years?
It will be interesting to see the responses to this post.
| 
