So as usual
@chrismevans latest blog post
here raises some good points that need discussing. In a
previous post a while ago I highlighted some of these but I think Chris brings a number clearly to the fore.
FlexVols are inherently a good thing (although some of the sales use cases are rather flawed - eg copy prod to dev/test, which of course ignores all the information security issues), similarly so is the concept of Aggregates - but the issue for me is that these features haven't moved with the times. Some points below...
Aggregates limited to 16TB - this is an increasing issue for several reasons. Firstly the simple point that as disks increase in capacity we have fewer drives that can participate within an aggregate, impacting performance and risk. Secondly the first impact also impacts costs - as NetApp themselves are having to recommend smaller disk sizes with aggregates, which of course prevents any cost/gb benefits of larger disk sizes. Thirdly of course there are times when the actual capacity of an aggregate is just needed to be bigger than this limit.
Full support - so as Dimitris points out, in 8.0 a FlexVol can now be the same size as an aggregate (a good thing) but there is a new restriction, this cannot be a dedupe/ASIS volume (they are still limited in size). So a case of 'feature marketing' - in that most customers will now be using dedupe on their storage, meaning this new limit increase is pure theoretical at this point.
Mixed disks - The fact that today aggregates can only include a single disk type (ignoring PAM) is frankly painful, heck even EMC have understood this message and delivered upon it (still more work need Boston based dues!). But not to see this in OnTap after all this time is depressing to say the least.
Non-disruptive - for me this comes in two main areas that still appear to be missing :-
- Non-disruptive move of volumes between disk types and/or aggregates within the same array
- Non-disruptive in-place upgrade from 32bit to 64bit aggregates
NameSpace abstraction in the NAS area is still a major issue - primary for technology refresh & migrations, yes vFilers help for some of it but really just snowplough the problem around rather than actually remove the problem. I think NetApp certainly do need to spend more time looking at the migration & tech refresh areas, and spend time looking at environments where customers run a variety of ages of platform - to see what can be done to improve these parts. Otherwise they'll find that customers invest in the heterogeneous namespace virtualisation areas (eg F5 ARX, EMC RainFininty etc) rather than the persistence layer.
Reducing the size of an aggregate - hasn't been an issue in the past but will most certainly be an issue with larger aggregate sizes for companies with decent sized estates that need to move their storage hardware and/or capacities around within their estate.
Legacy Management - in talking of versions of OnTap we naturally get into the topic of estate management - by this I mean two key areas. Firstly the interop with & between various versions of OnTap - for many customers this will be a key factor, how to move over time to newer releases and how functionality works/is constrained by backwards & forwards compatibility. Secondly but related, is the equipment that the latest versions of OnTap are actually supported on, as much as vendors would like a new OS release to drive hardware refresh this just isn't possible or realistic in any well managed storage estate. So a key factor is that a current release is provided and supported on previous generations of hardware and that it is clear & flexible how the deployments of software interact with each other from a functionality perspective.
Multi-Protocol - yes this is interesting and can be of use, but reality is that is reasonable sized data-centres instance deployments of arrays still then to be protocol aligned (eg a 3160 for NAS, a different 3160 for FC etc). For me the bigger benefit is that the same interface and firmware/software is used over the different platforms as opposed to the myriad of platform software from other vendors.
But for me the greatest issue is that we're still discussing the same points re OnTap that we were 4 years ago, and little real progress has been made. I'm certainly not going to hold my breath for the v8.1 release that people allude to including lots of stuff that was needed 3 years ago. The talk of future releases is always bothersome, and is a standard sales tactic 'ignore the construction debris, look at possible the shiny future' - look at the disclaimers on any presentation on futures and then ask "why should I believe any of this is actually going to happen when & how stated?". I'm increasingly of the view that the OnTap code-chest is getting too old, too complex and too over-stuffed from an architectural clarity perspective for NetApp to be able to make sensible progression, and I'm wondering a) when it needs a tear down & rebuild with full architectural clarity? (as I don't believe 8 release is that) and b) what the next set of innovations are coming from?
Are they still better than the competitors? In a number of areas clearly & most definitely yes (eg MetroCluster, Failover between arrays, MultiStore etc), have they innovated ahead of others? yes (eg ASIS), but increasingly far too rarely & slowly and the market is rapidly catching up and will pass them very soon.
It's positive to see NetApp people commenting positively on Chris's blog, but NetApp if you want to improve things for the future? Run some a customer council sessions, listen to your customers discussing between them in a forum, take the information and act rapidly upon it - heck EMC did and they made big strides forward...
Overall - my view is that NetApp product management, particularly the WAFL & OnTap strategy teams have been asleep at the wheel for a few years and they, but more importantly their customers, are now paying a heavy price for this failure.