Storage

A minor blog/twitter-skirmish Dimitris and Chuck with regards to a survey comissioned by EMC into the relative simplicity/usability of  their respective storage administration tools brings up the historically parlous state of Storage Management tools.

Storage Management tools have generally been pretty poor and I have gone on record a number of times castigating vendors and especially EMC about the usefulness of their tools. I do believe that the situation has got better, especially with regards to the tools which are used to administer individual arrays. And more interestingly, what we have seen especially in the administration areas has flipped the relative positions of the vendors round a bit.

IBM for example with their XIV purchase have come to realised that usability is actually a feature which will sell an array; for all the mud and FUD that can be thrown at XIV, one thing which all of their competitors have acknowledged is that the user interface pushed the envelope as what users should expect.

So IBM have pushed that interface to both the DS8000 and the SVC/V7000 range, providing a common look and feel across their own block storage range; it cannot be long before SONAS falls into into line and gets a similar make-over.

IBM were starting from a pretty poor base-line and hence the improvement has been pretty startling.

EMC, have made major strides in the simplicity of the Clariion/Celerra interface and the latest versions of UniSphere are much simpler; the VNX has benefited from this especially and it is arguable that this is probably the most visible advantage to many customers. A Unified interface across the mid-range. Unfortunately, EMC have an number of additional storage products which are not part of this common administration tool.

EMC’s improvements are not as dramatic as IBM’s and they still have some way to go to get to the clarity of  IBM’s UI. The VNXe interface is close but actually at the expense of hiding functionality from the customer. Still, I think EMC have benefited massively from their Iomega purchase in understanding how to make something really simple to configure and manage; you will fail in this space if it isn’t.

And this brings me onto NetApp; when I started blogging, I would have argued that NetApp were very much the front runner. I managed without any training or documentation to configure their simulator and start configuring the simulated Filers; I also managed to cluster them and fail them over. This was all done from their Web GUI but I suspect that previous storage and Unix experience somewhat helped.

But the Web GUI is now looking very dated and it feels that many features are hidden in less than intuitive places. I am not sure that a storage novice could get it configured as quickly as easily as either IBM’s or EMC’s devices these days. I think NetApp are more than aware of this and their first attempt to address t his was the initial release of the NetApp System Manager; a Windows Management Console plug-in, a good first attempt but it lacks features and there is much you can’t do. And it is Windows only, which is not going to earn brownie points with many.

NetApp System Manager 2.0 has gone into beta and this looks more promising and it is both Windows and Linux; (why no Mac version??).  NetApp also have to work out how to integrate E-Series into their configuration tools.

HP have a multitude of products as well; many of the interfaces are ageing when compared to their competitors but they have 3Par; which is an awesome interface, not as pretty as the new IBM interfaces but simple to use and feature packed. My recommendation to them is to take that interface and work out how to make all of their interfaces similar.

So things are getting better on the usability front; certainly from the administration point of view, even if the large-scale storage management tools are still not there in my opinion (I’ll address that in a later blog). As interfaces get better, they are becoming differentiators between arrays and vendors but….

Do not confuse simplicity with usability and effectiveness. You can configure a very simple interface but if I can’t configure a feature I need to use; it is not an effective interface.  I do not want to be told that to configure a particular feature that I need to use the CLI…I do not want to be told that to turn on a particular flag, that I must use the CLI…this happens all too often, especially with the newest features which the vendors are most proud of.

It seems that UI is still very much an after thought;   it’s not, it’s what allows me to make effective use of your products. We don’t have time these days to work out the arcane syntax that your propeller-headed engineers thought cool! And I might tolerate it for a particularly unique feature/capability but I won’t love your product and I’ll be plotting on how to put it on the pavement once everyone else catches up.

As we talk about archiving digital media and data forever; this is a salutary reminder of the risk of going digital; technology changes so fast that we risk loosing today’s cultural heritage.

The original Domesday book is over 900 years old and is still readable today in it’s original format; it is unlikely that the information we record today will still be readable in it’s original format in 900 years time and for it to be preserved for future generations, it will have to be migrated on a regular basis to new formats and media.

And as we create more and more data, this migration effort is going to become a major challenge. Does this matter, do we need to store only that which is important and let most of the data we create simply become a data midden? Simply discarded and forgotten? Only to be discovered and pawed over by future generations of digital archaeologists?

This would be fine but we are not talking about data which is hundreds of generations old; we are talking about data created now, in living memory which is potentially ending up the midden.

It is ironic that the technology which has allowed many of us to trace our family trees many generations by allowing easier access to the analogue record by digitising it, could be a major factor in preventing future generations in doing the same.

So NetApp are in the process of creating a new category of storage to stop it looking like that they are going back on their principles of Unified SAN storage; Shared DAS storage! Shared DAS storage is basically as far as I can see SAN storage without a switch; in fact, it looks very much like the arrays of the past where access was via SCSI. What appears to make it shared is that the LUNs might be shared between multiple hosts; so in old money, that’d be ‘twin tailing’.

Of course, you can do this with any array out there, we have a number of small arrays which we do this with; often in small campus equipment rooms where we cannot justify a full fibre infrastructure but for various reasons the users want the server infrastructure as close to them as possible.

It’s a bit sad that NetApp have to play games to try to justify the change in focus or at least the maturing in strategy. It is also unfortunate that in many cases, you will want your ‘Shared DAS’ on a SAN; for example, one of the popular use cases for the Engenio disk which makes up this new ‘Shared DAS’ is in massively scalable clustered file-systems where you might well want meta-data and real data separated onto different arrays. If you take the ‘Shared DAS’ approach, you are going to start running out of ports on your hosts very quickly.

So instead of inventing new terms, can we just stick the old terms? The Engenio arrays are no-frills, performance-orientated SAN arrays which work well in specific environments and actually due to their no-frills nature lend themselves very nicely to clustered file-systems and indeed to storage virtualisation products such as NetApp’s vSeries.

I think NetApp’s acquisition of Engenio is quite a canny move but really guys, be a bit bolder….don’t become an enormous marketing company!

Every time I see an article like this; it makes me sigh and pity the poor fool who decides that the performance increase given by RAID-0 is worth it. And with four 3 terabyte drives no less, a single drive failure would cause up to 12 terabytes of data loss.

Please, friends don’t let friends use RAID-0 unless said friend really knows what they are doing and has a rigorous back-up routine. Running 3 terabyte drives in a RAID-5 configuration is risky enough with rebuild times going be horrible….but RAID-0, you’ve got to be nuts!

If you rely on the data to do your job, you’ve got to be doubly nuts! Buy yourself an SSD or two and archive files to large properly protected disks when you’ve finished working with them. Don’t kid yourself that you are only storing ‘working files’ on your RAID-0; those working files, the time you really need them…is when you are working on them.

Chuck’s blog about user interfaces made me review what my team has to deal with on a day-to-day basis.

From IBM, we have three different interfaces; one for the DDN-based arrays, one for the LSI-based arrays and one for NetApp filer-based arrays. Of these, arguably the filer-based tools are the most mature and featured but the DS Manager for the LSI-based arrays is not horrible and works pretty well. The DDN management tools are possibly the worst I’ve come across in years and it does not help that they tend to use a completely different terminology to everyone else.

From EMC, we have Unisphere for the Clariions; this is a major improvement on their previous offerings. We also have Isilon which has a pretty nice Web GUI.

And for BackUp and Archive, we have both TSM and NetBackUp. TSM’s CLI is great and very powerful; the GUI is horrible and you would not really want to use it; whereas NetBackUp’s GUI is good and there is not a huge reason to use the CLI unless you are some kind of CLI junkie or need to write custom reporting scripts.

So on a daily basis, the guys are coping with seven different interfaces for Storage/BackUp; I must be forgetting something…oh yes, we have both Brocade and Cisco SAN switches, so that’s up to nine.

And that’s before we start dealing with clustered file-systems and the like. We could certainly do with some kind of umbrella tool but we are resigned to the fact that we are never really going to get one.

One thing which would make life easier would be for the various vendors to agree terminology and at least remove the need for a Rosetta Stone. Product differentiation by terminology is not the best way to go.

I don’t think we have a favourite tool though; we just have those which we tolerate more than others. Things I would like to see improved though are

• Fully scriptable CLIs; DDN, I am looking at you here
• Consistency in command syntax and modifier order.
• GUIs should be fully functional and you be able to do everything from the GUI or the CLI. It would be nice if we had an ‘F6’ SMIT-type function which reveals the underlying  command being run from the GUI; it can then be captured and used in scripts
• No Windows only management tools; do it via the Web GUI. Look at IBM’s XIV and SVC interfaces for best of breed; with EMC’s Unisphere running them close.

I’m sure people have their own ideas and please note this is just the basic configuration/management tools; I have a whole different bunch of requirements for reporting tools.