It's kind of appropriate to be blogging about matters of policy the day before a general election in the UK. However, the inspiration for this blog is not the UK general election but some comments made about automated optimisation and predictable performance. In my previous blog here, I think the comment from Hector about automated movement being not desirable in conservative environments is only half right.
Firstly we need to examine the current situation and for this I am going to make one assumption; your environment is not so conservative that you dedicate an array per application; if you are that paranoid about predictable performance, you probably do not want to be running shared infrastructure of any sort. So taking away that edge-case, we should consider what is now normal in large environments and that is shared infrastructure; certainly shared network and storage infrastructure is pretty much the rule.
Once we accept that fact; we no longer really have a predictable environment, complex interactions between applications can cause unpredictable outcomes. You push down here and something pops up there. The more applications we add, the more complex and chaotic the system becomes. So what do we do?
Traditionally, we have relied on human intervention to manually optimise the environment; endless poring over spreadsheets and manual moves. Storage performance tuning is a black art but with storage infrastructures now measuring in many thousands of spindles and application instances heading that way too; even the most efficient and effective storage expert can only struggle.
The first tranche of storage optimisation tools were never really trusted and were generally only run in an advisory mode; still requiring a human to make the decision. But with infrastructures so complicated, can a human really out-think a machine? I am no longer convinced.
However, I am also not convinced that telling an array to just 'optimise' itself will work either. An array has no idea about the priorities and the value of the various applications on it, what it believes is balanced may well not meet the service levels required. Some applications will be more tolerant of latency than others, some might need more throughput that IOPs etc.
What is needed is a policy engine; you set the policies for the applications as agreed by the business and the array does it's best to meet them. Defining these policies will become the new black art; it will require a deeper understanding of many aspects of the Business and the end-users than simply making the array go fast.
Triage policies will need to be defined for exception handling i.e. in the event of the array not being able to meet the policies defined does it
a) degrade all applications equally?
b) degrade some applications significantly and leave others unaffected?
And these policies may well be time-based; at two o'clock in the morning, your performance requirements may well be significantly different to that at nine o'clock when everyone is trying to log-on.
Policies can be event-driven; a file-based restore/backup will have a very different I/O profile to normal processing, so perhaps you want to turn off any kind of optimisation for that application when that is happening? Perhaps you might even have a special policy to cater for restores? An application upgrade, a data refresh, a data fix; all will have different impacts on the array.
In fact, the whole area of policy-based storage management will not devalue or even de-skill the storage performance expert; it will allow them to focus on what really matters and respond more quickly to business demands.
Policy-based storage management does not need to be any less conservative than manual optimisation; you set the policies as conservatively or liberally as you like. Your policy might just be let the array do its own thing. Or it might be to legislate for every eventuality. But in the background, the array will be doing it's best to comply and at least it'll tell you when it's in breach of the policies set down!
Pity our politicians rarely do the same!
