Increasing And Optimizing Your Storage Components

By Steve Duplessie
Expert Author
Article Date: 2009-06-01

Sometimes we do things "just because" it's how we've always done things - regardless of whether or not it makes sense to do. It seems to me that all the excitement, money, and noise around Flash these days is creating one of those vacuums that sucks everyone along, but I'm not sure the end game is going to make life better.

Here's what I mean; Flash or SSDs make an "element" of infrastructure faster. It makes it faster because the sub-component of the element in question has I/O done on mechanical disk - and Flash/SSD is memory, which is much faster than disk. That part I get - and - I'm all for it. Go nuts. Kill the disk. Sorry Seagate. I am not at all saying faster stuff is bad. I'm saying that in context, it isn't as good as it needs to be.

Why do we need those elements to go faster? The answer is - eventually - that we want an application to go faster - which means, eventually - that what we REALLY want is the USER (be it a person, server, process, etc.) to be able to access (to manipulate or display) the DATA associated with the application being run.

Therefore - the only relationship we should ultimately be concerned with is the relationship between the requester (user) and their data. Everything else in the middle is infrastructure. Infrastructure breaks into zillions of ELEMENTS. Thus, making some of the elements faster CAN be good - but unless you make EVERY element faster, it won't ever be perfect or optimized.

Thus, my contention is that Flash/SSDs are great as a natural evolutionary component upgrade in the sub-relevant world of gizmos, but will never be completely relevant to the real mission of globally enhancing and automatically optimizing the performance (and availability) of the primary relationship between the user and their associated data. Read that again if you must. It can be a piece of the puzzle, but will never be the whole enchilada, therefore, it should not carry such outrageous exuberance beyond its legitimate business opportunities.

Case in point - the processor. Do you need bigger, faster processors today? Not really. Does the fact that the economics of processors is such that we can afford to have super mega huge processors on every element in the infrastructure guarantee that the HOLISTIC infrastructure dynamically optimizes the performance/availability relationship between the user and their data? No. That's not to say processors are bad - far from it - but it makes the point that you never solve any systemic issue with only a single view. Faster processors and VMware enable us to get rid of many elements!!! But if/when we do, we expose all sorts of new problems that didn't exist prior - like I/O, and all the operational baggage that goes along with any change in the data center.

If you are a company with over 100TB of file data, growing at 50% or more per year, our research says that you support a single critical application with 39 file serving devices on average. The reason you have 39 of these file serving devices is because A: that's just the way it happened, B: you need all of these for performance/load balancing, C: capacity requirements caused it, or D: see A. The ONE application using this data may have 39 of its own servers associated with it - supporting X number of users. Adding Flash/SSD to 1 of the file servers might make the data on that 1 server faster - fact. But it won't do jack for the other 38 file servers, nor will it do diddly for the application servers, nor will it do diddly to reconfigure the network to take advantage of it. It will make the files that sit on that one file server accessible faster if the data you stuff into the Flash or SSD happens to be there.

I would argue that stuffing Flash into that 1 file server/array/gizmo will cause MORE work to be done operationally - because now you have to move and migrate things to take advantage of that new sub-component - and every time you change anything, you open yourself up to new SYSTEMIC issues. Data/System migrations for capacity optimization or load balancing is a never-ending tactical nightmare of IT operations. Flash maybe kept someone sane by masking the need to do one of these migrations on that system, but only for a little while. In reality, it probably causes more work to leverage the benefits of the Flash than it's worth.

Thus, since no human can really optimize the overall environment the way things currently happen, the only real way to drive value from this exercise seems to be that you would have to make sure you upgrade the sub-component that you believe causes you the problem du jour - storage I/O for example - systemically (add it to EVERY file server), and then manually tune/alter the rest of the network and server infrastructure accordingly.

I contend that there must be a better way. It is simply not practical or reasonable to systemically apply higher performing sub-components at all levels in today's world and expect the ultimate issue to be solved. Even if you could afford to do so, the incremental operational burden of manually optimizing the environment would take an army of PhDs in a STATIC environment - and I don't think it's possible in the real world dynamic, always changing, never ending data growth world in which we live.

Therefore, what we need is a way to automatically/dynamically optimize the connection performance/availability of the user/data relationships on what we have today, tomorrow, and the next day - no matter what changes or when. The only way I can think that can happen is to CENTRALIZE the control (for availability and routing - and application prioritization/policy) and the performance. We need to take the intelligence from all the elements and create uber control and cache systems. Central Flash married with real application/infrastructure intelligence - sort of how a contained system operates. Sort of what VMware aspires to do. The problem is that even if VMware pulls off the data center coup of the century, they can only puppet master the individual elements - not control the optimization flow between those elements.

So, there you have it. Go make that. Send me a check.

Comments

About the Author:
Steve Duplessie is the author of the "Steve's IT Rants" blog, and the founder and Sr. Analyst of the Enterprise Strategy Group.