Console Annoyances

March 5th, 2011

Using the console is getting pretty frustrating. Often, there seems no viable alternative though – For example, in FilerView it appears for some reason that creating a new igroup doesn’t present you with a list of valid WWNN’s, instead it’s a list of WWPN’s (or, was it the other way round?) Either way, the wrong data is given, which makes the data unusable.

Ops Manager is a halfway decent attempt at a centralised management solution, but it appears to introduce other problems. The biggest being that it’s a single point of failure – When we asked our value added reseller about high availability options for Ops Manager, we were told we could virtualise. But for that, you need shared storage, the very storage you’re managing. I’m sure you can see the problem here. Maybe our value added reseller isn’t really adding value, here. It appears that if you allow your Ops Manager to manage your storage, then you lose things should Ops Manager be unavailable. For instance, it appeared that Snap Mirror relationships are all managed by the Ops Manager install. Lose your Ops Manager install, and your snaps stop. Not an ideal situation, if we’re honest.

So, you’re stuck with using the CLI. Using the CLI is not a bad thing, just a massively inconsistent interface is somewhat annoying. Setting up a snap mirror relationship for a new volume is fairly straight forward, you’ve just got to use the (quite frankly disgusting) rdfile and wrfile programs. That’s assuming you know where the files are that you want to edit, no such luxuries as ls within Data ONTAP.

We’re in 2011, and out the box you can’t have concurrent logins to the CLI. I’m not sure if there’s an option to allow more than one person to log in at the same time. From what I can work out, Data ONTAP is based on (or takes code from) BSD. I’m fairly sure that out the box, all the major BSD’s allow more than one root login at the same time.

According to Wikipedia (which is obviously always fact-perfect), tab completion has been around since the 1960′s. Not on the filers, though! Maybe it’s something that’s been introduced in Data ONTAP 8.0, I’m not sure as I’ve not had chance to look at it yet.

I can’t decide if I’m disappointed, or frustrated.

Consistently Inconsistent

October 12th, 2010

I’m getting frustrated with a lack of consistency for the filer interface. When using ‘clever stuff’ in the past, I’ve tended to find that the CLI is complete with a half-baked GUI added on later. This, I would guess, from a developer coming up with an idea and hacking away at code. They write a CLI product, as that’s the environment they’re most used to using, or simply prefer the CLI. I see the CLI as one of the strengths of Linux and UNIX – You can do pretty much everything at the command line, and do it well. Then comes along the marketing department who insist on a GUI as it looks pretty and keeps people happy.

I have nothing against a GUI interface, when it works.

With the filers though, the CLI seems a little half-baked with the GUI (FilerView and Operations Manager) being half-baked also. If you’re not on the CLI, then it appears that not all options are available to you. Operations Manager won’t seem to allow the creation of a synchronous relationship, for instance.

I get the feeling that either there have been a couple of different (groups of) people that have written the programs that run on the CLI, or there are simply no design guidelines for Data ONTAP within NetApp, which has resulted in the syntax being inconsistent. It’s annoying, to say the very least.

To take a look at your aggregates, you use aggr status.
To take a look at your volumes, you use vol status.
To take a look at your LUNs, you use lun show.

Why is interrogating a LUN different to a volume or aggregate? You want essentially the same type of information, surely?

There is no doubt an argument that a LUN is different to a volume, which is in turn different to an aggregate. Ok, give me an argument and I’ll listen. How about interrogating only a volume? I’d expect that to be consistent.

vol size [volume name] happily shows the size of the volume. You can use the /vol/ if you wish.
vol status [volume name] happily shows the configuration options of the volume. You can use the /vol/ if you wish.
sis status [volume name] will show you the SIS status for a volume, only if you include the /vol/ prefix. I’m not sure of the thinking behind this. As I understand it, deduplication happens at the volume level, so it’s implicit that the [volume name] you throw at the sis status is the name of a volume, therefore will reside within /vol/. Like all other volumes do. I can’t get my head around the thinking.

How about getting some extended information about things? Traditionally, you’d use a v switch. v being short for verbose. So, tell me everything you know about [volume name]. Simple: vol status -v [volume name]. How about verbose information for SIS? sis status -v /vol/[volume name]. No, no, you don’t want verbose information, you want long output. sis status -l /vol/[volume name].

It seems painful, and poorly thought out at best, to sometimes have a -v modifier and sometimes use -l. To sometimes require /vol/ when working on volumes, and for it to sometimes be optional.

I hope this isn’t a reflection on the quality of the code that sits behind Data ONTAP.

  • About

    A website about my learning experience with implementing a couple of NetApp devices.

  • Admin
Rackspace Hosting